答えるためではなく考えるための8つのプロンプトパターン

なぜ多くのプロンプトは考えることではなく答えを返すのか

AIについて人々が口にする不満があります。「自信たっぷりで、ありきたりで、ちょっとだけ間違っているものをくれる」と。本能的にはモデルを責めがちです。正直な答えは、多くのプロンプトがアウトプットを求めており、モデルはアウトプットを返しているということです。要約を求めれば、要約が返ってきます。5つのヒントのリストを求めれば、5つのヒントのリストが返ってきます。結果が浅く感じられるのは、リクエストが浅かったからです。

プリンストンの研究者たちは、KDD 2024のプロンプト構造の引用挙動に関する論文（Aggarwal et al.）で、まさにこのギャップを研究しました。彼らが見つけたのは、プロンプト構造はモデルが言うことだけでなく、モデルが何に注意を向けるかを変えるということです。フレーミングの小さな変化が、どのソースが引用されるか、どの反論が浮上するか、どの前提が明示化されるかを変えるのです。言い換えれば、プロンプトは検索クエリではありません。それはフレームなのです。

この記事はフレームのカタログです。特定の思考の仕事のための、具体的で名前が付いていてコピペできる8つのプロンプトパターンです。隣には2つの関連するGlaspの記事が並びます。Context engineeringは、AIが働く部屋を組み立てることについてです：ドキュメント、ソース、制約。The AI thinking trapは、AIがあまりにスムーズに感じ始めたときに自分のクリティカルな態度を維持することについてです。この記事は動きのカタログそのものです。部屋、態度、動き。

下の各パターンは同じ構造を持ちます。いつ使うか、どこから来たか、正確なプロンプト、返ってくるものの例、そしてなぜそれが効くか。チェックリストではなく、語彙として扱ってください。

パターン1：スティールマン

スティールマン (Steel-Man) は、反対意見に対して反論する前に、その最も強いバージョンを構築する規律です。藁人形の対極で、弱い戯画を攻撃するのではなく、最強のバージョンを打ち負かそうとします。

いつ使うか：立場を擁護する前、議論を公開する前、あるいはすでに大方心が決まっている高ステークスな判断をする前に。

由来：通常は1960年代のAnatol Rapoportの建設的議論のルールに辿られます。これは相手の立場をあまりに上手に再述するため、相手が「ありがとう、そういう言い方をすればよかった」と言うことを要求します。

プロンプト：

Steel-man the opposing view of [my position]. Make the strongest possible
case, including any evidence or framing I'm likely missing. Don't hedge.
Don't add a "but actually" at the end. Just make the case.

出力例：「今週MVPを出荷すべき」のような立場に対して、スティールマン化された応答はこう言うかもしれません：「今週出荷することは、修正可能な打ち上げと永続的な第一印象を交換することになります。週1で離脱した顧客が戻ってくることはまれです。2週間遅らせるコストは小さいです。傷ついた評判に対して再ローンチするコストは大きいです」。

なぜ効くか：多くの人は、相手が賢いから議論に負けるのではありません。馬鹿なバージョンに対して準備したから負けるのです。スティールマンは、自分の側に公的にコミットする前に、賢いバージョンに直面することを強制します。

パターン2：プリモータム

プリモータム (Pre-Mortem) は事後分析を時間的に反転させたものです。プロジェクトがなぜ失敗したかを分析する代わりに、すでに失敗したと想像し、そこに至った道筋を再構築します。

いつ使うか：計画、プロジェクト、または機能をローンチする前、特にチームがすでに自信を持っているときに。

由来：Gary Klein、「Performing a Project Premortem」、Harvard Business Review、2007年。Kleinは、失敗がすでに現実だと仮定したとき、チームが潜在的な失敗の理由を30%多く生成することを発見しました。

プロンプト：

It's [date 6 months from now]. The plan I'm about to describe failed
badly. Walk me through the most likely sequence of events that led
to failure. Be concrete about what we missed, who pushed back too late,
and what early signal we ignored.

Plan: [paste plan here]

出力例：「2ヶ月目までに、ローンチトラフィックは週ごとに60%下落していました。チームは紹介からのオーガニック成長を仮定していましたが、紹介ループには遅れて出荷された機能が必要でした。4ヶ月目までに、パートナー会社の元のチャンピオンは退社し、後任との関係を築いた人は誰もいませんでした」。

なぜ効くか：将来の後知恵は脳の探索方法を変えます。「何が間違いうるか？」と尋ねると、ぼんやりした答えが返ってきます。「何が間違ったのか？」と尋ねると、具体的な答えが返ってきます。架空の確実性が本物の具体性を解錠するのです。

パターン3：荷重前提

荷重前提 (Load-Bearing Assumption) は、あなたの議論が依存する沈黙の主張を浮き彫りにします。多くの議論には、もし偽なら全構造が崩れる前提が1つか2つあります。多くの人はそれらを決して名指しません。

いつ使うか：判断に行き詰まったとき、予算や人員を投じる前、あるいは計画が明らかに正しく感じられるが理由が言えないとき。

プロンプト：

Identify the 3 load-bearing assumptions in this argument. For each, tell me:
1. What evidence would falsify it
2. How I could check in under a day
3. What changes if it turns out to be false

Argument: [paste argument]

出力例：「前提1：ユーザーは初回訪問で10秒のロード時間を許容するだろう。反証：ランディングページの直帰率が60%超。1日チェック：プロトタイプURLの先週のアナリティクスを引っ張る。偽の場合：オンボーディングフロー全体に高速パスが必要」。

なぜ効くか：前提は、見えないほど危険になります。声に出して名指すことが呪文を解きます。「1日以内にチェック」の制約が演習を正直に保ちます。チェックできないなら、主張もできないのです。

パターン4：インバージョン

インバージョン (Inversion) は質問を逆向きに尋ねます。「Xでどう成功するか？」の代わりに、「Xの最悪のバージョンをどう保証するか？」と尋ねるのです。それからそれらを避けます。

いつ使うか：問題が行き詰まって感じられるとき、テーマに関する助言が決まり文句で満ちているとき、あるいはやることよりも避けることのほうを早くリストできるとき。

由来：Charlie Mungerが19世紀の数学者Carl Jacobiから借りたもので、Jacobiの助言は「Invert, always invert（反転せよ、常に反転せよ）」でした。Mungerはこれを最も有用なメンタルモデルの一つと呼びました。

プロンプト：

Instead of solving [problem], list every action that would guarantee
the worst version of this outcome. Be specific and concrete. Then
we'll work backwards from your list to figure out what to actually do.

出力例：「優れたオンボーディングメールをどう書くか？」に対して、インバージョンはこう生み出します：「800語書け。会社の歴史でリードせよ。アクションボタンをフォールドの下に埋めよ。『私たちは興奮しています』を2回使え。金曜日午後5時に送れ。名前だけパーソナライズしてテストし忘れろ」。

なぜ効くか：人々は成功を設計するより失敗を認識するほうが上手です。インバージョンは、脳に実際に得意な具体的なターゲットを与えます。最悪のバージョンが紙に出たら、より良いバージョンはほぼその否定になります。

パターン5：デビルズ・オーディット

デビルズ・オーディット (Devil's Audit) は、誰もまだ見ていない自分のドラフトに対して実行する動きです。モデルに敵対的なレビュアーを演じてもらい、具体的にすることを求めます。

いつ使うか：ドラフトを書いた後、議論を完成させた後、あるいはデックを組み立てた後。送信、公開、またはプレゼンテーションの前に。

プロンプト：

Audit this draft as a hostile but smart reviewer. List specifically:
1. The weakest claim
2. The most unfair generalization
3. The part where I'm assuming the reader agrees with me
4. The part most likely to be cut by an editor

Be specific. Quote the exact sentences.

Draft: [paste draft]

出力例：「最も弱い主張：『多くのチームは文化のせいで失敗する』（段落3）は引用がなく、後で引用しているマッキンゼー2023年の研究と矛盾している。最も不公平な一般化：『エンジニアはドキュメントを読まない』。同意の仮定：段落5は非同期作業を明らかに優れたものとして扱っているが、多くの読者はそうは思わないだろう」。

なぜ効くか：あなたが書いたものと、見知らぬ他人が読むものの間のギャップは巨大です。多くの書き手は自分の前提が見えません。前提が彼らの呼吸する空気のように感じられるからです。敵対的なレビュアーは空気を可視化します。「正確な文を引用する」という制約が具体性を強制し、そこに価値が宿ります。

パターン6：事前ブリーフ

事前ブリーフ (Pre-Reading Brief) は、コンテンツを消費する前にあなたの心を準備します。受動的に読む代わりに、すでに何を探すべきか知っている人として読みます。

いつ使うか：長い記事、密度の高い論文、重要な動画、または本当に保持する必要のある本の章の前に。

プロンプト：

Before I read this, give me:
1. Three questions I should hold in mind while reading
2. The strongest counterargument I should look out for
3. The three sentences I should remember if I forget the rest

Source: [paste or link]

出力例：「これらの質問を保持してください：(1) 著者の最強の証拠は何か？ (2) 出来事のタイムラインがあいまいになるのはどこか？ (3) 誰の視点が欠けているか？ 注意すべき反論：著者は引用された2つ目の研究で相関を因果と扱っている。覚えるべき3つの文：[...]」。

なぜ効くか：これは認知のプライミングです。Mayerの認知マルチメディア学習理論は、構造的なプレビューを得る学習者は、読んだり見たりしたものを約30%多く保持することを示しています。なぜなら、入ってくる情報を、ワーキングメモリで冷たく保持するのではなく、足場に取り付けることができるからです。ブリーフがその足場なのです。

パターン7：Synthesis-from-N

Synthesis-from-N は、テーマに関するいくつかのソースを集め、それらを横断する構造を抽出する必要があるときのパターンです。各ソースの要約ではありません。コンセンサス、対立、共有された盲点を浮かび上がらせる統合です。

いつ使うか：あるテーマについて複数の記事、論文、またはトランスクリプトを読んだ後。特にGlaspで集めてきたハイライトのライブラリがあるときに有用です。

プロンプト：

Synthesize these N sources into:
1. The core consensus (what they all agree on)
2. The loudest disagreement (where they explicitly contradict each other)
3. The assumption all sources share that nobody questions

Sources: [paste highlights, links, or quotes]

出力例：「中核のコンセンサス：5つすべてのソースが、ワーキングメモリが学習のボトルネックであることに同意している。最大の不一致：ソース2と4は、間隔反復がインターリービングを上回るかどうかで分かれている。共有された問われていない前提：すべてのソースが動機を外因的なものとして扱い、フォーマット自体がエンゲージメントをどう形作るかを無視している」。

なぜ効くか：多くの人はN個のソースを読んでN個の要約に終わります。Synthesis-from-Nは単一の地図を強制します。3つ目の項目、問われていない前提こそ、実際の洞察が宿る場所です。なぜならそれは、その分野で誰もまだ尋ねていない問いだからです。読む・ハイライトする・統合するサイクルのより長い扱いについては、the synthesis loopをご覧ください。

パターン8：フェイラーモード・ハンター

フェイラーモード・ハンター (Failure-Mode Hunter) はシステム思考のパターンです。物事が壊れる方法をリストし、確率と深刻度でランク付けし、それぞれを早期に捕まえるものは何かを尋ねます。

いつ使うか：信頼性が新規性より重要なシステム、プロセス、製品、ツールを設計するときに。

プロンプト：

List the top 7 failure modes for [system]. For each, give me:
1. Probability (low / medium / high)
2. Severity (low / medium / high)
3. The cheapest detection mechanism that would catch it within an hour

System: [describe system]

出力例：「障害モード1：トラフィックスパイク下でデータベース接続プールが枯渇。確率：中。深刻度：高。検出：接続待ち時間が200msを超えたらアラート。障害モード2：サードパーティAPIがエラーなく静かにレート制限。確率：高。深刻度：中。検出：5分ごとに既知のフィクスチャと応答ペイロードを比較する合成チェック」。

なぜ効くか：障害モードは通常、誰かに知られています。問題は、それが起こる前にあなたに知られているかです。確率、深刻度、安価な検出メカニズムを強制することは、あいまいな心配を優先順位付けされたチェックリストに変えます。「1時間以内」の制約が、本物のモニタリングを劇場から分けるのです。

1ページのチートシート（とパターンを覚える方法）

カタログ全体をひとつにまとめます。

これらを覚えるコツは、自分の作業の中で名前を付けることです。次に立場への最強の反論を求めるとき、ただタイプするのではなく、「これにスティールマンを実行している」と言ってください。ドラフトを完成させたら、「デビルズ・オーディットを実行中」と言ってください。動きに名前を付けることは、それを使い捨てのプロンプトから、安定して手に取れるツールに変えます。

GlaspのWebハイライターとよく合う実用的なリズム：ハイライト先、パターン後。読みながら、重要に感じる箇所を保存してください。それから、ハイライトのライブラリにパターンを実行します：意見の異なるソースからのハイライトを使って自分の立場にスティールマンを、集めたハイライトに対してドラフトにデビルズ・オーディットを、テーマクラスタを横断してSynthesize-from-Nを実行します。ハイライトは原料です。パターンは素材に対してあなたが行う動きです。GlaspのAIチャット機能はこのリズムを中心に作られています。あなたのハイライトはすでにコンテキストの中にあるので、パターンはモデルが推測するものではなく、あなたが実際に読んだものに対して動作します。

これに上手くなる人々の多くは、1週間に8つすべてを使うことはありません。自分の考え方に合う2つか3つを選び、流暢になります。それが目標です。8つのパターンを暗記することではなく、2つか3つのパターンを自動運転で動かすことです。

よくある質問

これらのパターンはどんなLLMでも機能する？

はい。GPT-5、Claude 4.6、Gemini 2.5でテストされており、モデル固有のトリックではなくプロンプト構造に関するものなので、同じように成り立ちます。上の出力例は3つすべてで同様の品質で生成されました。より小さなモデルは同じ形のより浅いバージョンを生成しますが、形は通用します。

8つすべてを覚えるべき？

いいえ。2つから始めてください。多くのナレッジワークで最も高いレバレッジを持つ2つは、スティールマンとプリモータムです。スティールマンは、実際に圧力テストしていない立場を擁護することからあなたを救います。プリモータムは、振り返ってみればすでに障害モードが明らかな計画をローンチすることから救います。状況が出てきたら他を加えてください。多くの人が3つ目に採用するのはインバージョンです。

これは単なるプロンプトエンジニアリング？

関連はしていますが、目標が違います。プロンプトエンジニアリングはモデルのアウトプットを最適化します：より良い答え、より少ないハルシネーション、よりきれいなフォーマット。思考のパターンはあなたの認知を最適化します：自分の盲点を捕まえる、自分の前提を浮上させる、自分の議論を鋭くする。アウトプットは副作用です。要点は、パターンを実行するときにあなたの頭の中で起こることです。

Chain-of-thoughtやステップバイステップのプロンプトはどうなの？

Chain-of-thoughtはこれらと積み重ねられるメタパターンです。上の8つのパターンのいずれにも「ステップバイステップで考えてください」を追記でき、特にデフォルトで推論しないモデルでは、たいていより厳密な応答が得られます。しかしCoT単体では、特定のターゲットに向けられていない冗長な思考を生み出しがちです。上の8つのパターンは思考を具体的な何かに向けます。ステークスが余分なトークンを正当化するときに、一緒に使ってください。

おわりに

AIが「浅い」という不満は、ほとんどの場合、浅いプロンプトについての不満です。上のパターンはモデルを賢くするわけではありません。あなたのリクエストを賢くします。実際にレバレッジが宿るのはそこです。

名前付きの8つの動き。反対意見にはスティールマン。計画にはプリモータム。判断には荷重前提。行き詰まったらインバージョン。ドラフトにはデビルズ・オーディット。コンテンツには事前ブリーフ。ソース横断にはSynthesis-from-N。システムにはフェイラーモード・ハンター。名前が大事なのは、瞬間に実際に思い出せるからです。「これにスティールマンを実行する」は、自分に向かって言える言葉です。「プロンプトでもっとクリティカルなフレーミングを使う」はそうではありません。

このカタログから一つだけ持ち帰るなら、これにしてください：目標はAIからより良い答えを得ることではありません。目標は、自分が尋ね忘れた問いを尋ねるパートナーとしてのAIとともに、あなたから鋭い思考を生み出すことです。8つのパターンは、そのパートナーシップを機能させる、信頼できる8つの方法です。2つ選んでください。流暢になってください。仕事が要求するときにもっと加えてください。