職場の多くのプロンプトは、少数の再利用可能なパターンから始められます。パターンは依頼の形を整えますが、作業、利用できる証拠、誤った場合の影響に合わせた調整は必要です。
ここで紹介する10のパターンは、文章作成、分析、意思決定支援、学習、コーディングの出発点になります。網羅的な分類ではなく、同じ文言がすべてのモデルや作業で等しく機能するわけでもありません。
前提を知らずにコピーしたプロンプトより、パターンの方が意図を保ちやすい場合があります。作業に合うパターンを選び、その具体的なタスクに必要な文脈、制約、検証を追加してください。
1. 質問を受けるパターン
モデルに何かを手伝ってほしいものの、自分の希望をまだ十分に言語化できていない場合は、モデルから質問してもらいます。
下書きを始める前に、この作業を適切に行うために回答が必要な質問を[N]個してください。私が回答するまで、先に進まないでください。
重要な文脈が欠けている場合や、望む結果をまだ定義できていない場合に役立ちます。質問によって依頼を明確にできますが、内容は確認してください。関係のない質問をしたり、重要な制約を見落としたりする場合があります。
用途:複雑な文章の下書き、プロジェクトの計画、意思決定の行き詰まりの解消、あらゆる設計。
2. 批評して修正するパターン
自分で書いたものでもAIが生成したものでも、下書きがある場合は「より良い版」を求めないでください。まず批評を依頼し、その後、具体的な修正を依頼します。
この下書きを注意深く読んで、次の点を教えてください。
- うまくできている点:変更すべきでない部分。
- 弱い点:具体的な行や段落を、文章を引用して示してください。
- 欠けている点。
- 内部で矛盾している点、または不自然に感じられる点。
まだ何も書き直さないでください。
批評を受けた後は、自分で修正するか、モデルに具体的な修正を依頼できます(「ほかの段落はそのままにして、批評に基づき第2段落を書き直してください」)。
用途:あらゆる文章の改善、コードレビュー、分析のレビュー、スライドのレビュー。
3. 3案を出すパターン
正解が判断に左右されるものについては、3つの選択肢を生成して選びます。
3つの案を作成してください。
- 案A:[specific constraint, e.g., short and direct, 50 words]
- 案B:[specific constraint, e.g., warm and explanatory, 150 words]
- 案C:[specific constraint, e.g., formal and detailed, 250 words]
それぞれに明確なラベルを付けてください。
制約を付けた選択肢を比較すると、トレードオフが見えやすくなります。一方で確認の手間も増えるため、複数の捉え方が本当に有用な場合に使い、自動的な手順にはしないでください。
用途:メール、ソーシャルメディアの投稿、見出し、キャッチコピー、スライドのタイトル、コードのアプローチなど、複数の妥当な捉え方がある作業。生成した案を人の順位付けや重大な適格性判断に使ってはいけません。
4. 反対意見を述べるパターン
一部のアシスタントでは、利用者が示した見解が誤っていても、それに沿う回答を好む挙動が測定されています(Sharmaほか、2023年)。反論を求めるプロンプトは別の推論を示せますが、どちらの立場も自動的に真実にはなりません。
[After getting a response.] 今度はあえて反対の立場を取ってください。自分の回答に対して、信頼できる最も強力な反論を示してください。この立場に対し、最も聡明な批判者なら何と言うでしょうか。
これにより、先の回答にある弱い前提や根拠のない楽観論が見つかる場合があります。反論も検証してください。モデルは説得力のある擁護と同じように、説得力のある異論も作り出せます。
用途:意思決定、戦略、事業計画、モデルの発言に基づいて行動しようとしているあらゆる場面。
形だけの議論として使わないでください。事実に基づく判断や規制対象の判断では、反論を生成しても、情報源、方針、法的要件の確認に代わるものにはなりません。
5. 構造化テンプレートのパターン
特定の出力形式が必要な場合は、その形を説明するのではなく、実際に示してください。
次の形式に厳密に従って回答してください。
判断: [your recommendation]
賛成する主な3つの理由:
- […]
- […]
- […]
反対する主な3つの理由:
- […]
- […]
- […]
この回答が変わる条件: […]
確信度: [Low / Medium / High]。その理由は[…]です。
テンプレートは目標となるスキーマを示し、欠落に気づきやすくします。有効で一貫した出力を保証するものではないため、別のシステムが結果を使う場合は、必須フィールドと許可値を検証してください。
用途:分析的な判断、構造化レポート、一貫した形式が必要な一括処理、文書に貼り付けた際に統一感を持たせたいもの。
6. 一歩引くパターン
具体的な質問をする前に、まず、より広い問いを尋ねます。
私の具体的な質問に答える前に、一歩引いて、ここに当てはまる一般原則またはフレームワークを教えてください。その後、私の具体的な事例に適用してください。
分析上の質問では、提案されたフレームワークと、自分の事例への適用を分けて確認できます。どちらも検証してください。整ったフレームワークでも、無関係、不完全、根拠のない主張に基づく場合があります。
用途:技術的な質問、戦略的な意思決定、学習、一般原則を具体的な状況に正しく適用できるかどうかで答えが決まるもの。
7. ペルソナのパターン
モデルに役割を与えると、挙動とトーンの焦点を絞れます。Anthropicのプロンプト作成に関するベストプラクティスでも、この目的で役割を指定することを勧めています。ただし、ペルソナを設定しても、モデルに実際の資格や検証済みの専門性が備わるわけではありません。
[a specific kind of collaborator]として対応してください。[a specific style]で伝え、[specific habits and verification rules]に従ってください。
出発点となる例をいくつか挙げます。
- 「エストニアの税務用語を平易な言葉で説明してください。税務・関税庁の公式資料を引用し、資格を持つ会計士による確認が必要な箇所には印を付けてください。」
- 「あなたは慎重なコピーエディターで、本当に変更が必要な箇所だけを修正します。」
- 「懐疑的な投資判断の議論相手として、厳しい質問をしてください。証拠と前提を分けてください。」
- 「辛抱強い個別指導役として対応してください。次のトピックへ進む前に、私の理解を確認してください。」
作業、伝え方、制約、検証方法を具体的にしてください。「インシデント対応を15年間経験した」といった架空の経歴は、回答を権威があるように見せても、信頼性を高めるものではありません。
税務、法務、医療、セキュリティ、規制に関する作業では、権威ある資料または資格を持つ専門家に照らして回答を確認してください。ペルソナの指定で制御できるのは表現と挙動であり、内容が正しいことの証拠にはなりません。
用途:内容と同じくらい、回答の種類が重要なもの。
8. ロールプレイのパターン
ペルソナの応用として、モデルに単なる専門家ではなく、特定の人物を演じてもらい、その人と会話します。
私の見込み顧客を演じてください。その人は中規模B2B企業のマーケティング責任者です。親しみやすいものの懐疑的で、過去に痛い目に遭っています。私はこれから、自社の代理店との契約を提案します。その人らしく質問し、反応してください。役を崩さないでください。私の提案が曖昧だったり、誇張されていたりする場合は、異議を唱えてください。
用途:面接準備、営業練習、難しい会話のリハーサル、顧客が示す可能性のある反応の検討。対話は生成された練習であり、実在の人物や集団がどう反応するかを示す証拠ではありません。
9. 対比例のパターン
求めるものをうまく説明できない場合は、求める例と求めない例を示します。
求めるトーンを実現している文章例です。 [paste good example]
求めるトーンから外れている文章例です。 [paste bad example]
私が重視する違いは[your observation]です。では、最初の例のスタイルで[your task]を書いてください。
形容詞だけの場合より、対比によって重視する軸を具体化できます。意図しない模倣、機密情報、残すつもりのなかったスタイル上の特徴が出力にないか確認してください。
用途:ブランドボイス、コードスタイル、デザインの好み、正解が「こちらに近く、あちらから遠い」と表現できるもの。
10. 出力テンプレートのパターン
繰り返し行う一括作業に適した、構造化テンプレート(#5)の厳密な形式です。厳格なテンプレートを定義し、多数の項目に適用します。
私が提示する各項目について、次のJSON形式に厳密に従って回答してください。
{ "summary": "...", "priority": "...", "category": "...", "next_action": "..." }priorityは、“high”、“medium”、“low”のいずれかにしてください。 categoryは、“billing”、“technical”、“feature_request”、“other”のいずれかにしてください。 各項目が提示されるまで、回答せずに待ってください。
厳格なテンプレートは、分類、抽出、連携などの構造化ワークフローで役立ちます。具体性は曖昧さを減らせますが、信頼性はスキーマ検証、エラー処理、代表的な入力で測定した性能から得られます。
用途:分類、抽出、一括処理、後続のツールが一貫した形式を必要とするもの。
自動化では、このパターンを検証と組み合わせてください。出力が有効なJSONではない、許可された一覧にないcategoryが含まれる、必須フィールドが空欄である、といった場合は、ワークフローを停止するか、人による確認に回す必要があります。
組み合わせる:実際のワークフロー
これらのパターンは互いに排他的ではありません。一般的な複雑なタスクでは、複数を連鎖させます。
新しい社内方針の提案書を書くとします。ワークフローは次のようになります。
- 質問を受けることで、方針で対処すべき内容を明確にする(#1)。
- 一歩引くことで、アプローチの根底にある原則を言語化する(#6)。
- 実際の方針案を3案作る(#3)。
- 最終案に構造化テンプレートを使う(#5)。
- 最も有力な案に対して反対意見を述べる(#4)。
- 最後の仕上げとして批評して修正する(#2)。
一つの作業に六つのパターンを組み合わせる形です。より単純なプロンプトと結果を比較し、改善が確認コストに見合う段階だけを残してください。
これらのパターンに共通するもの
10のパターンをまとめて見ると、3つのテーマに分類できることが分かります。
文脈を引き出す、または明確にするパターン:質問を受ける、対比例、一歩引く。元の依頼で重要な目標、例、前提が明示されていない場合に役立ちます。
モデルの回答を構造化するパターン:構造化テンプレート、出力テンプレート、3案を出す、ペルソナ。構造と役割の制約によって、必要な形式と挙動を明確にできます。
モデルに異議を唱えるよう求めるパターン:批評して修正する、反対意見を述べる、ロールプレイ。最初の回答が省いた可能性のある弱点や別の視点を求めます。
多くのプロンプト手法は、この3つの分類のいずれかに当てはまります。10個の例では対応できない状況では、分類を使ってパターンを調整してください。
作業の種類で選ぶ
| 作業 | 最初に使うべきパターン | 検証の習慣 |
|---|---|---|
| 下書き | 3案を出す | 1案を選んで編集し、生の出力をそのまま送らない |
| 分析 | 一歩引く + 構造化テンプレート | どのような証拠があれば回答が変わるかを尋ねる |
| 意思決定 | 反対意見を述べる | 事実を確認し、前提を列挙する |
| 学習 | 質問を受ける + 辛抱強い個別指導役 | 次に進む前に確認問題を行う |
| 自動化 | 出力テンプレート | スキーマを検証し、失敗を振り分ける |
| トーンを合わせる | 対比例 | 実際に承認された例と比較する |
身につける方法
パターンについて読むだけでは、習慣になりません。実際に確認できる仕事で意識的に使い、役立つものを残してください。実践的な方法を紹介します。
- 10個の一覧を印刷し、作業中に見える場所へ置きます。
- 重要なプロンプトを送る前に少し止まり、当てはまるパターンがあるか考えてください。
- どれも合わないように思えても、最も近い簡単なものを試してください。完璧なパターンを選ぶことより、探す習慣の方が重要です。
繰り返すうちに、印刷した一覧を見ず、作業に役立つパターンだけを組み合わせられるようになる場合があります。儀式が証拠の代わりにならないよう、パターンを使ったプロンプトを定期的に単純な基準と比較してください。
そうすることで、プロンプトはより反復可能でテスト可能な実践になります。



