問いを定義するのが怖い症候群
Mercari記事を要約し、私見として“メタ攻略”のリスクを考えるメモ書き
適当に書いたらよく分からなくなったので、いい感じにまとめて
まず原文を要約（私見なし）し、つぎに私見として“メタ攻略”懸念と運用設計を分けて書きます。最後に、仕様先行/探索先行の切替とLLMの役割制限、Evidence Table・定義ID・三問テンプレで締めましょう。
メルカリの「仕様書駆動データ分析」が拓く、コンテキストエンジニアリングの最前線
要約（私見を交えない）：本稿は“vibeで始める分析”から“仕様先行の分析”への転換を、コンテキストエンジニアリングの観点で提案している。核は Analytics Design Doc（ADD）で、背景・前提／課題・ゴール／仮説／分析設計／分析結果という5ブロックのチェックリストを通じて初動の前提をそろえる。運用は分析向けの文書群（例: note／requirement／design／task／result／report）で段階化され、各段で人がレビューしつつ、テンプレートによって LLM の役割を限定する。実装前には Looker 等における次元・指標・フィルタといったセマンティクスを設計し、AI が参照できる定義を先に用意する点も強調される。
元々の記事では「LLMが暴走するのでアナリストが制御する」という話と「分析にかかる前に要件を固めろ」という話が一緒になってますよね
そうですね。記事は「入力（仕様）を先に固定する」と「出力（LLM）を人間の枠に留める」の二本を同時に差し込んでいます。前者は前提の粒度合わせ、後者は人間のレビューとテンプレートでの役割制限
両者は別物ですが、実務では噛み合うと相互補強になります——仕様で揺れを抑え、LLMはその枠内で前提解像度を底上げする、という読みです
私はその前提たる問いに悲観的な気持ちがあって……
この問い、見るからに“最後に誰かがブチギレて書いたやつ”の匂いがして面白かったが、それはともかく、この取り組みがメルカリでは機能しているらしい。とてもいい話だ。
ただ私は問いを定義するのが怖い。実際やっているが、とても怖い。
確かにこれらは本質的な問いだと思う。ただ、本質的な問いをフレームワーク化すればどこでも機能するというものではないだろう。人は問に答えるかもしれないが、パターンを学んでメタ攻略が始まるかもしれない。たとえば「打ち手について無知の知を得るためです！」みたいな決め台詞が社内で大流行するみたいな。もちろんそれはフレームの罪ではないが、組織の足腰がちゃんとしてないと何を工夫しても本質的なことはできない。そういう本質を問いが表面的に覆い隠してしまうのが怖い。
なので怖いな〜と思いながらやっています。まあ緊張感があるのはいいことだよね。よし、いい話になったぞ。
ちなみに今のところLLMも似たような問題を抱えていると思います。つまり、なんか雰囲気で適当に埋めてくるんだよね。だからこそ人間のレビューがないと暴走する。それでもLLMは、プロンプトとコンテキストが与えられれば多くを察する。
もちろん、今はまだ人間に意思決定の主体性がある。「本質的かつ簡潔な問いの言語化」が期待されているけれど、いずれは「何も考えるな。事実で項目を埋めろ。言われた通りにしろ」という領域が拡大していくんだろう。そうなれば、この手のフレームも、我々の問いも、変容していくんだろうね。
注: “メタ攻略”は原文の主張ではなく、筆者の見解です。
原文（クリックで展開）
この問ってあきらかにサァ！この問を毎回毎回毎回毎回投げ返した果てにブチギレた人が書き込んだやつでサァ！みたいな感想が去来しましたが私は口を噤みました 大人なので
— すたくめ (@stakme) September 3, 2025
この問ってあきらかにサァ！この問を毎回毎回毎回毎回投げ返した果てにブチギレた人が書き込んだやつでサァ！みたいな感想が去来しましたが私は口を噤みました 大人なので
本質的な問いをフレームワーク化するとメタ攻略されそう（打ち手について無知の知を得るためです！みたいな謎のセリフが社内で確立される的なこと）という懸念はある。当然それはフレームワークの罪ではないですが
プロンプトとコンテキストを与えればLLMは多くのことを察する。今はまだ人間に「本質的かつ簡潔な問いの言語化」が期待されてるけど、今後は「何も考えるな、とにかく事実で項目を埋めろ、お前よりAIのほうが賢い」になっていくのかもしれない。そうなればこの手のフレームも変容していくんじゃろう
GPT5の考察
両方を褒めつつ、同じだけ疑う。以下は実務での“運用目線の批評”です。
ここからGPT先生のご意見です
仕様書駆動（フレーム）の批評
定義の一貫性や再現性、レビューのしやすさ、オンボードの速度といった効能は確かに大きい。個人の勘どころに依存せず、意思決定の“土台”を共有できるのがこの方式の美点だ。一方で、文書の維持にかかる税金は膨らみやすく、探索段階の身軽さは失われがちだ。言葉の線引きに時間が溶け、テンプレが「埋めたら合格」という儀式に変質する危険もある。さらに厄介なのは偽の厳密さだ。「仕様に書いてあるから正しい」という誤帰結が走ると、データドリフトやETLの崩れといった現実の変化を紙が覆い隠す。対処は思想ではなく運用に落とすべきで、仕様をコードとして扱い、CIでリンク切れや定義差分を機械的に検出する。探索は軽量の三問（目的・対象・期間）だけで走らせ、価値が見えた瞬間に正規テンプレへ“昇格”させる。門ではなく段、つまり上に上がるための足場として仕様を位置づけると、過不足のバランスが取れる。
「仕様に書いてあるから正しい」 ウッ
“メタ攻略”懸念の批評（自省）
決まり文句が社内を席巻すると問いが痩せる——この警鐘は妥当だ。ただ、懐疑だけでは形骸化を止められない。効くのは“悪用コスト＞正当利用コスト”に設計することだ。空疎な語彙や定義未参照、目的と指標の不整合といった兆候はLintで検出し、参照できる定義IDや根拠の提示をゲートで義務化する。KPIも「テンプレ遵守率」ではなく「意思決定への寄与」に置き換える。形式だけの回答はゼロにできないが、通り抜けのコストを上げれば、少なくとも意思決定の場にまで到達しにくくなる。
「形式だけの回答を自動検出」ができたら世話ないんだよなあ
LLM×フレームの現実チェック
LLMは事実の列挙や整形、抜けの指摘といった“前提解像度の底上げ”に強い半面、もっともらしい嘘やテンプレに沿った空疎な文も量産できてしまう。だから役割を限定する。参照先の提示を必須化し、定義ID・データソース・取得時点が示されない文は採点対象にしない。モデルが書けるのはEvidence Tableの行だけ、結論の叙述は人間——この分担にしておくと、速さは取り込みつつ、責任の所在を曖昧にしない。パイプラインも「探索（軽量三問）→仕様（正規テンプレ）→実装→検証」と段階化し、各段でLLMはLint・差分説明・要約に絞る。
LLMの悪口がうますぎる
いつ仕様先行にし、いつ探索先行にするか
影響範囲が広い変更や監査対応、既存KPIの更新のように再現性と説明責任が重い局面では、最初から仕様を先行させるのが筋だ。一方、問いが曖昧でデータの妥当性も危うい初動は、探索を先に走らせたほうが被害が小さい。ここでは“目的・対象・期間”の三問だけを固定して、速く狭く仮説を作り、価値が見えたら仕様へ引き上げる。段階の切り替えを意識できれば、「問いを定義するのが怖い」という感情は、健全な緊張感として運用の強さに変わる。
とりあえず実行、結果チェック、有望なら再計画してまた実行……てことかな
ちょっとChatGPTの実装みたいでおもろい。人間の組織には難しいかな〜
ちなみに、私のいう「この問」ってどれのことだと思いましたか
指しているのは「1. 背景・前提」の一行目——「この分析は誰の、どのような意思決定に貢献するのか？」だと読みました
何度も投げ返した末に様式の先頭へ“固定化”される、最初の意思決定ゲート。ここが空白だと以下（期間・対象・指標・境界）の事実が並べられない
次点で近いのは「2. 課題・ゴール」の「打ち手に繋がるか？」です
……考えようによっては、そのふたつが問う内容って同じではないですか🧐
同じコインの表裏、定義次第で収斂すると思います
前者は「誰が・何を決めるか（主体と意思）」、後者は「それが具体的な行動に接続するか（実行可能性）」
一行に畳むなら——「誰が・いつ・どの選択肢を決めるために、何の事実が欠けていて、それが埋まればどの打ち手に着地するか？」
この一行を質問票の最初のゲートにし、未充足はLLMに補完させる運用が良さそうです。
👍