すべてのナレッジワーカーが知っておくべき10のプロンプトパターン

「プロンプトエンジニアリング」という言葉からは、1つの専門分野のような印象を受けます。実際には、少数のパターンをまとめたものです。パターンを理解すれば、プロンプトを毎回ゼロから書く必要はありません。状況に合うパターンを選び、その場に合わせて調整できます。

この記事では、実務でほぼ毎日のように登場する10のパターンを紹介します。そのほとんどは、文章作成、分析、意思決定、学習、コーディングに広く応用できます。10個すべてを覚えれば、今後必要になる実践的なプロンプトエンジニアリングの大部分を身につけたことになります。

パターンは意図を保てるため、コピーしたプロンプトの定型文より安全です。作業に合うパターンを選び、その具体的なタスクに必要な文脈、制約、検証を追加してください。

1. 質問を受けるパターン

モデルに何かを手伝ってほしいものの、自分の希望をまだ十分に言語化できていない場合は、モデルから質問してもらいます。

下書きを始める前に、この作業を適切に行うために回答が必要な質問を[N]個してください。私が回答するまで、先に進まないでください。

これは、初心者が最も活用できていないパターンです。また、最短時間で品質を最も大きく引き上げるパターンでもあります。多くのプロンプトが失敗するのは、依頼する側が自分の状況をまだ把握できていないからです。質問を受けるパターンでは、モデルにプロンプトの焦点を絞る手伝いをさせることで、この問題を解決します。

用途：複雑な文章の下書き、プロジェクトの計画、意思決定の行き詰まりの解消、あらゆる設計。

2. 批評して修正するパターン

自分で書いたものでもAIが生成したものでも、下書きがある場合は「より良い版」を求めないでください。まず批評を依頼し、その後、具体的な修正を依頼します。

この下書きを注意深く読んで、次の点を教えてください。

1. うまくできている点 — 変更すべきでない部分。
2. 弱い点 — 具体的な行や段落を、文章を引用して示してください。
3. 欠けている点。
4. 内部で矛盾している点、または不自然に感じられる点。

まだ何も書き直さないでください。

批評を受けた後は、自分で修正するか、モデルに具体的な修正を依頼できます（「ほかの段落はそのままにして、批評に基づき第2段落を書き直してください」）。

用途：あらゆる文章の改善、コードレビュー、分析のレビュー、スライドのレビュー。

3. 3案を出すパターン

正解が判断に左右されるものについては、3つの選択肢を生成して選びます。

3つの案を作成してください。

• 案A：[具体的な制約。例：短く率直に、50語]
• 案B：[具体的な制約。例：温かみを持たせて説明的に、150語]
• 案C：[具体的な制約。例：正式かつ詳細に、250語]

それぞれに明確なラベルを付けてください。

「最善の案」を求めるより、3つの選択肢を比較する方が速く、最終的な仕上がりも良くなります。また、暗黙のうちに行っていたトレードオフも明らかになります。

用途：メール、ソーシャルメディアの投稿、見出し、キャッチコピー、スライドのタイトル、コードのアプローチ、採用判断、複数の妥当な捉え方があるもの。

4. 反対意見を述べるパターン

モデルは相手を喜ばせようとします。初期状態では、利用者の提案を支持する論拠を示しがちです。これを抑えるには、次のように依頼します。

[回答を得た後。] 今度はあえて反対の立場を取ってください。自分の回答に対して、信頼できる最も強力な反論を示してください。この立場に対し、最も聡明な批判者なら何と言うでしょうか。

これにより、自分の考えが薄い部分や、モデルの回答が楽観的な部分を見つけられます。自分が聞きたい内容を言われているだけではないかと疑う場合に、特に役立ちます。

用途：意思決定、戦略、事業計画、モデルの発言に基づいて行動しようとしているあらゆる場面。

形だけの議論として使わないでください。事実に基づく判断や規制対象の判断では、反論を生成しても、情報源、方針、法的要件の確認に代わるものにはなりません。

5. 構造化テンプレートのパターン

特定の出力形式が必要な場合は、その形を説明するのではなく、実際に示してください。

次の形式に厳密に従って回答してください。

判断： [推奨案]

賛成する主な3つの理由：

1. […]
2. […]
3. […]

反対する主な3つの理由：

1. […]
2. […]
3. […]

この回答が変わる条件： […]

確信度： [低 / 中 / 高]。その理由は[…]です。

モデルは角括弧内を埋めます。構造は予測可能で解析しやすく、実行を重ねても一貫します。類似した多数のプロンプトの出力を比較したい場合に、特に便利です。

用途：分析的な判断、構造化レポート、一貫した形式が必要な一括処理、文書に貼り付けた際に統一感を持たせたいもの。

6. 一歩引くパターン

具体的な質問をする前に、まず、より広い問いを尋ねます。

私の具体的な質問に答える前に、一歩引いて、ここに当てはまる一般原則またはフレームワークを教えてください。その後、私の具体的な事例に適用してください。

経験的には、難しい分析上の質問で回答品質が向上します。モデルが具体的な主張をする前に、フレームワークを定めるためです。「この場合は、そうですね…」という曖昧な但し書きが減り、原則に基づく回答が増えます。

用途：技術的な質問、戦略的な意思決定、学習、一般原則を具体的な状況に正しく適用できるかどうかで答えが決まるもの。

7. ペルソナのパターン

モデルに具体的な役割を与えると、回答のスタイルと情報密度が大きく変わります。

あなたは[特定分野の専門家]で、[具体的な経歴]を持っています。[具体的なスタイル]で伝え、必ず[具体的な習慣]を実践します。

安定して役立つ例をいくつか挙げます。

• 「あなたはエストニアの上級税務会計士です。率直に話し、私には十分な理解力があることを前提にしてください。」
• 「あなたは慎重なコピーエディターで、本当に変更が必要な箇所だけを修正します。」
• 「あなたは悪いアイデアをあまりにも多く見てきた、懐疑的な投資家です。厳しい質問をしてください。」
• 「あなたは、このトピックを10年間教えてきた辛抱強い個別指導役です。」

役割は具体的にしてください。「専門家」より、「インシデント対応を15年間経験してきた上級サイバーセキュリティエンジニア」の方が効果的です。

用途：内容と同じくらい、回答の種類が重要なもの。

8. ロールプレイのパターン

ペルソナの応用として、モデルに単なる専門家ではなく、特定の人物を演じてもらい、その人と会話します。

私の見込み顧客を演じてください。その人は中規模B2B企業のマーケティング責任者です。親しみやすいものの懐疑的で、過去に痛い目に遭っています。私はこれから、自社の代理店との契約を提案します。その人らしく質問し、反応してください。役を崩さないでください。私の提案が曖昧だったり、誇張されていたりする場合は、異議を唱えてください。

用途：面接準備、営業練習、難しい会話のリハーサル、顧客への共感を深める作業。2026年時点では、モデルが役を維持する能力は、本当に役立つ準備ができるほど優れています。

9. 対比例のパターン

求めるものをうまく説明できない場合は、求める例と求めない例を示します。

求めるトーンを実現している文章例です。 [良い例を貼り付ける]

求めるトーンから外れている文章例です。 [悪い例を貼り付ける]

私が重視する違いは[自分の考察]です。では、最初の例のスタイルで[自分のタスク]を書いてください。

これは、形容詞でスタイルを説明するより効果的です。対比により、重視する軸が明確になります。また、モデルは説明に合わせるより、例に合わせる方がはるかに得意です。

用途：ブランドボイス、コードスタイル、デザインの好み、正解が「こちらに近く、あちらから遠い」と表現できるもの。

10. 出力テンプレートのパターン

繰り返し行う一括作業に適した、構造化テンプレート（#5）の厳密な形式です。厳格なテンプレートを定義し、多数の項目に適用します。

私が提示する各項目について、次のJSON形式に厳密に従って回答してください。

{
  "summary": "...",
  "priority": "...",
  "category": "...",
  "next_action": "..."
}

priorityは、“high”、“medium”、“low”のいずれかにしてください。 categoryは、“billing”、“technical”、“feature_request”、“other”のいずれかにしてください。 各項目が提示されるまで、回答せずに待ってください。

厳格なテンプレートは、パイプライン、自動化、ほかのツールとの連携など、構造化ワークフローでAIを使うための基盤です。テンプレートが具体的であるほど、出力の信頼性が高まります。

用途：分類、抽出、一括処理、後続のツールが一貫した形式を必要とするもの。

自動化では、このパターンを検証と組み合わせてください。出力が有効なJSONではない、許可された一覧にないcategoryが含まれる、必須フィールドが空欄である、といった場合は、ワークフローを停止するか、人による確認に回す必要があります。

組み合わせる：実際のワークフロー

これらのパターンは互いに排他的ではありません。一般的な複雑なタスクでは、複数を連鎖させます。

新しい社内方針の提案書を書くとします。ワークフローは次のようになります。

1. 質問を受けることで、方針で対処すべき内容を明確にする（#1）。
2. 一歩引くことで、アプローチの根底にある原則を言語化する（#6）。
3. 実際の方針案を3案作る（#3）。
4. 最終案に構造化テンプレートを使う（#5）。
5. 最も有力な案に対して反対意見を述べる（#4）。
6. 最後の仕上げとして批評して修正する（#2）。

1つの作業に対する45分間のセッションで、6つのパターンを使います。その結果は、「Xに関する方針を書いてください」と頼む場合より格段に優れたものになります。

これらのパターンに共通するもの

10のパターンをまとめて見ると、3つのテーマに分類できることが分かります。

自分からより多くの文脈を引き出すパターン — 質問を受ける、対比例、一歩引く。通常、ボトルネックはモデルではなく利用者側にあるため、効果を発揮します。

モデルの回答を構造化するパターン — 構造化テンプレート、出力テンプレート、3案を出す。モデルは初期状態では無難で曖昧な回答をするため、構造によって具体性を引き出せます。

モデルに異議を唱えさせるパターン — 批評して修正する、反対意見を述べる、ロールプレイ。初期状態では同意しすぎる傾向があるため、モデルに弱点を探させることで、より良い思考につながります。

オンラインで目にする「プロンプトエンジニアリングのコツ」のほぼすべては、この3つの分類のいずれかに当てはまります。この3つを理解すれば、ここで紹介した10個では対応できない状況に合わせて、独自のパターンを考案できます。

作業の種類で選ぶ

身につける方法

パターンについて読むだけでは、習慣になりません。解決策は、2週間ほど意識的に使うことです。実践的な方法を紹介します。

• 10個の一覧を印刷し、作業中に見える場所へ置きます。
• 重要なプロンプトを送る前に、2秒間止まります。「どのパターンが当てはまるか」と考えてください。
• どれも合わないように思えても、最も近い簡単なものを試してください。完璧なパターンを選ぶことより、探す習慣の方が重要です。

使い続けるうちに、パターンは反射的に使えるようになります。印刷した一覧に手を伸ばさなくなり、自然に組み合わせていることに気づきます。そして、自分がパターンを使い忘れたときも分かるようになります。質問を受けるべきだった、反論を求めるべきだった、例を示すべきだった、と気づけます。

その段階になると、AIはチャットボットではなく、自分が本当に使い方を理解しているツールのように感じられます。その違いを生むのが、これらのパターンです。