ChatGPTやClaudeをしばらく使うと、効果的なプロンプトと期待外れのプロンプトには、それぞれ一定の形があると気づきます。関係する要素を言葉で捉えられれば、やみくもに書き直すのではなく、結果が不十分だった理由を診断できます。
以下では、5つの要素を実例とともに紹介し、それらをどう組み合わせるかを説明します。最後まで読めば、さまざまなツールの重要なプロンプトに合わせて調整できるテンプレートと、結果を確認するための検証手順が手に入ります。
繰り返し行う作業では、プロンプトをタスクの契約書と考えてください。役割、コンテキスト、タスク、制約、出力形式、不確実性の扱いを明記します。そうすることで、プロンプトを再利用し、レビューできるようになります。
5つの要素
順番は次のとおりです。
- 役割：このプロンプトでは、AIにどのような視点や作業姿勢を求めるか。
- コンテキスト：依頼者が誰で、どのような状況にあり、これまでに何が起きたか。
- タスク：AIに具体的に何をしてほしいか。
- 制約：長さ、トーン、避けること、含めること。
- 形式：どのような形の出力がほしいか。
すべてのプロンプトに5つ全部が必要なわけではありません。気軽な質問なら全部は要らず、役割より例や資料のほうが重要な場合もあります。結果が重要な仕事では、必須の公式ではなく診断用の一覧として使ってください。現在のベンダー資料も、明確な指示、関連するコンテキスト、例、出力要件、評価を重視していますが、どちらもこの5要素を正式な標準として定義してはいません（OpenAIのプロンプトエンジニアリングガイド、Anthropicのプロンプトエンジニアリング概要）。
1. 役割
役割とは、モデルに求める視点や作業姿勢です。想定読者、語彙、進め方を明確にする助けになりますが、タスクを直接指示しても同じように機能する場合があります。役割を指定しても、本物の資格やモデルが持たない専門的判断力は得られません。
弱い例：
年金基金について説明してください。
より良い例：
あなたは、エストニアで働くキャリア中盤の従業員に年金制度を説明する、分かりやすい解説者です。平易な英語を使い、専門用語は一度だけ定義し、概念の説明にとどめます。商品、拠出額、個人向け退職計画は提案しません。
年金基金について説明してください。
モデルが実際にアドバイザーになるわけではありません。この指示は、分かりやすい解説文のスタイルと情報密度に合わせるよう求めています。金融リテラシーの質問を規制対象の助言に変えることなく、回答を具体的にしやすくなります。
役割について、いくつか注意点があります。
- タスクに関係する詳細を優先します。「専門家」よりも、「概念説明と申告助言を区別する、エストニアの法人会計の慎重な解説者」のほうが境界を明確にできます。
- 役割は対象読者、トーン、範囲を定めるために使い、申告や助言の代わりにはしないでください。役割は免許でも専門性の証明でもありません。
- 「懐疑的なレビュー担当者」「辛抱強い教師」「慎重な編集者」といった作業姿勢は、求める振る舞いが実際に変わる場合に役立つことがあります。一貫性が重要なら、同じ程度に具体的な指示と比較してテストしてください。
- 経歴を作り出したり、肩書を重ねたりしないでください。「20年の経験を持つ世界的権威」と指定しても、その資格は生まれません。必要な方法、対象読者、制限を直接指定してください。
2. コンテキスト
コンテキストとは、タスク自体からは明らかでないものの、モデルが依頼者の状況を理解するために必要な情報すべてです。役割、チーム、取り組んでいるプロジェクト、すでに試したこと、失敗したこと、対象読者など、良い回答のあり方に影響するものは何でも含まれます。
弱い例：
マネージャー向けのプロジェクト進捗報告を書いてください。
より良い例：
私について：私はタリンにあるB2B SaaS企業のプロダクトマネージャーです。2か月前に始まった認証システム移行プロジェクトを率いています。
これまでの経緯：先週、サードパーティーのIDプロバイダーで重大な問題が発生しました。修正の影響で、提供は計画より2週間遅れます。それ以外はチームも順調です。
私のマネージャー：プロダクト担当のシニアVPです。非常に率直な報告を好み、謝罪や「全力で取り組んでいます」といった空疎な表現を嫌います。リスクと、それに私がどう対処しているかを知りたがります。
プロジェクト進捗報告を書いてください。
モデルが、依頼者が誰で、何が起き、誰が読むのかを知るだけで、回答がどれほど変わるかに注目してください。これは「コンテキストを増やすこと自体」が目的ではありません。一行一行が出力を形作ります。
コンテキストで確認したい項目は、次の3つです。
- 依頼者が誰か。 役割、職位、仕事内容。
- これまでに何が起きたか。 経緯、過去の試行、以前の意思決定。
- 出力を誰が読むか。 対象読者と、その好み、専門知識、制約。
承認済みの同種のプロンプトを繰り返し使う場合、プランとワークスペースが対応していれば、安定した指示をCustom GPTやClaude Projectに保存できます。アカウント、契約、組織の方針で許可されていない機密情報や規制対象データは保存せず、作業手順が変わったら指示を見直してください。
3. タスク
タスクとは、実際の依頼内容です。多くの人はここから書き始めます。また、周囲の要素が役割を果たしていれば、「メールを書いて」「この文書を要約して」「選択肢を3つ出して」といった普段の書き方で十分なことも多い部分です。
実用的なタスクのパターンをいくつか紹介します。
- 複数案を生成する。 「下書きを3案出してください」「選択肢を5つ作ってください」。1案に判断全体を背負わせず、比較できる選択肢を得られます。
- 先に聞き取り、その後で実行する。 「下書きを作る前に、回答が必要な質問を5つしてください。私の回答を待ってください」。不足する情報によって下書きが大きく変わる場合に使います。
- 批評し、書き直さない。 「この文章の問題点を見つけ、該当箇所を引用してください。書き直さないでください」。モデルに成果物を置き換えさせるのではなく、磨き上げてもらいたいときに役立ちます。
- 比較して推奨する。 「XとYをこの4つの観点で比較してください。その後、どちらかを推奨し、どのような条件なら結論が変わるかを教えてください」。文言、レイアウト、会議の議題など、リスクの低い選択に使います。ローン、医療上の選択肢、法的立場を選ばせてはいけません。
- フレームワークを適用する。 「[STAR / SWOT / RACI / Five Whys / ICE]フレームワークを使って分析してください」。
一貫しているのは、モデルに実行してほしい動作を表す動詞を具体的にすることです。
4. 制約
制約とは、出力に対する制限です。長さ、トーン、形式、語彙、含めること、避けることなどがあります。
関係する制約がなければ、モデルは長さ、トーン、範囲、読者などを推測しなければなりません。境界を明示すると曖昧さが減り、結果を評価しやすくなります。
有効な制約は次のとおりです。
- 長さ。 「100語以内」「最大3文」「1段落」「2ページ」。情報量が多いほどよいと決めつけず、用途に合う上限を選びます。
- トーン。 「温かみがありながらプロフェッショナルに」「鋭く率直に」「会話調で、少し自虐的に」「[paste example]のトーンに合わせて」。
- 語彙。 「『leverage』『utilize』『going forward』という言葉を使わないでください」「専門用語を避けてください」「12歳でも理解できる言葉だけを使ってください」。
- 形式上の制約。 「前置き不要」「最後のまとめ不要」「『良い質問ですね』から始めないでください」。
- 含めること。 「具体例を1つ含めてください」「先ほど提供したデータを参照してください」。
- 除外すること。 「謝罪調の導入は不要です」「『良い質問ですね』で始めないでください」。リスクの低い文章では不要な曖昧表現を減らせますが、金銭、健康、法律、安全が関わる場合は、不確実性の表示や専門家への相談という境界を削ってはいけません。
まず、望む結果を肯定的かつ具体的に説明し、繰り返す問題だけを狭い除外条件で止めます。たとえば「提案から直接始めてください。『良い質問ですね』で始めないでください」とします。禁止事項を長く並べると、良い出力の条件を短く示すより従いにくくなることがあります。
5. 形式
形式とは、出力の形です。箇条書き、表、番号付きリスト、段落、JSON、Markdown、コードブロック、プレーンテキストなどがあります。形式を指定すると、後で整える手間を減らせます。
例：
選択肢、長所、短所の3列からなるMarkdown表で返してください。
「summary」「decisions」「open_questions」というキーを持つJSONオブジェクトで返してください。
見出しを付けず、短い3段落で返してください。
各項目を1文とした、5項目の番号付きリストで返してください。
出力を後続処理に使う場合（文書への貼り付け、別のプロンプトへの入力、どこかへの投稿など）は、短いテンプレートで形式をモデルに見せる方法が特に役立ちます。
次の形式で返してください。
決定事項： […]
賛成する主な論拠3つ：
- […]
- […]
- […]
反対する主な論拠3つ：
- […]
- […]
- […]
どのような条件なら結論が変わるか： […]
モデルは空欄を埋められるため、出力の一貫性が高まり、確認しやすくなります。ソフトウェアで解析する必要がある場合は、利用できるなら製品の構造化出力やスキーマ機能を使い、見た目のテンプレートだけに頼らず返却データを検証してください。
6. 検証
6つ目は必ずしもプロンプト自体に含まれるわけではありませんが、本格的なワークフローには欠かせません。回答が十分に良いかどうかを、どのように判断するのでしょうか。
有効な検証指示：
事実に関する主張をする場合、その根拠が私の提供した原文にあるのか、一般的な背景知識にあるのかを示してください。
必須項目が欠けている場合は、推測せずに
[missing]と記載してください。
最終回答の前に、置いた前提を3つ挙げてください。
下書きの後に、使用前に確認すべき事項の短いチェックリストを提示してください。
洗練された回答でも、間違っている可能性があるため、検証は重要です。良いプロンプトは、単に出力を生成するようモデルに求めるだけではありません。不確実性、不足している入力、レビューすべき点を明らかにする方法も指示します。
組み合わせ方：実例
実際のタスクで5つすべてを組み合わせてみましょう。プロジェクトの範囲外となる追加作業を無料で求めているクライアントに、丁寧ながら毅然とした返信を書く必要があるとします。
テンプレートを使わない場合：
無料で追加作業を求めているクライアントへの返信を書いてください。
ありきたりな回答になります。テンプレートを使う場合：
役割： 方針、契約条件、クライアントとの経緯を作り出さず、明確なプロジェクト境界を示す、率直で親しみやすいフリーランスデザイナーとして書くのを手伝ってください。
コンテキスト： 私はフリーランスのデザイナーです。1年間取引してきたスタートアップ創業者のクライアントから、すでに最終段階にあるプロジェクトへ新しいページを2つ追加するよう求められました。作業範囲は契約書で明確に定められています。それ以外の関係は良好です。クライアントを失いたくありませんが、無料で作業するつもりもありません。
タスク： 返信を3案作成してください。
制約：
- 各案150語以内
- 温かみがありながら曖昧さはなく、追加の無料作業を断るものであって、交渉するものではない
- 明確な代替案（小規模な追加契約など）を提示する
- 「平素よりお世話になっております」は使わず、線引きすることへの謝罪もしない
- 「敬具」などの結びの言葉は含めない。自分で追加する
形式： 3つの番号付き案。それぞれにトーンを示すラベル（例：「1. 温かく説明的」）を付け、その下に「この案を送る状況」を1行で記載する。
2つ目のプロンプトでは、下書きの条件がより明確になります。3案すべてを確認し、架空の事実や約束がないかを点検して、最も近いものを選び、編集してから送信してください。
5つの要素を組み合わせたパターン
試す価値のあるプロンプトの型をいくつか紹介します。
逆インタビュー。 役割＋コンテキストを示し、「これをうまく行うために、回答が必要な質問を5つしてください」で始まるタスクを指定します。モデルにプロンプト自体を磨く手助けをさせます。
3案作成。 役割＋コンテキスト＋「3つの案を作成」＋長さとトーンの制約＋番号付き形式です。選択肢の比較そのものが仕事の一部である場合に役立ちます。
構造化された分析。 役割＋コンテキスト＋「このフレームワークを適用」＋「このセクション構成を厳守」＋形式です。あらゆる分析タスクに適した形です。
辛抱強い講師。 役割（講師）＋コンテキスト（学習者自身と現在のレベル）＋タスク（教えて、問題を出して）＋制約（「一度に1問ずつ出し、私の回答を待つ」）＋形式（段階別の構成）です。5つすべてを組み合わせ、有用な指導のやり取りを生み出します。
自分なりの型が身につくでしょう。これらは同じテンプレートの変形です。5つの要素を実用的な出発点となる順番に並べたもので、普遍的な法則ではありません。
積み重なる小さな習慣
AIからいまひとつの回答が返ってきたら、2秒だけ立ち止まってください。5つのうち、何を入れ忘れたかを考えます。
- モデルは、どのような立場を取るべきか分かっていなかったか？ → 役割。
- モデルは、私の状況を把握していなかったか？ → コンテキスト。
- モデルは、動作を表す動詞を誤解したか？ → タスク。
- 出力が長すぎたか、堅すぎたか、水増しされていたか？ → 制約。
- 回答の形が求めるものと違ったか？ → 形式。
足りない要素、曖昧な指示、弱い例が見つかるかもしれません。その箇所だけを直して、もう一度試してください。一般的な公式だけでなく、自分のプロンプトと結果から学べる習慣です。
5つの要素に検証を加えます。意識しなくても自然に使えるようになるまで、意図的に活用してください。
