プロンプトベストプラクティス
プロンプト設計のベストプラクティスは、各社が独自に発見した「秘伝のノウハウ」ではなく、 OpenAI Prompt Engineering Guide、 Anthropic Prompting Best Practices、 Google Gemini Prompting Strategies など、各 LLM 提供元の公開ガイドにほぼ共通する形で整理されています。本記事では、これらの最新ガイドと、Anthropic「Building effective agents」（2024-12）/「Reasoning Models Don't Always Say What They Think」（2025-04）など 2024-2026 の一次資料を突き合わせ、業務利用で再現性のある 9 原則と具体例にまとめます。
OpenAI / Anthropic / Google の公開ガイドは、用語こそ違いますが、(a) 明確に書く、(b) 文脈を渡す、(c) 例示する、(d) 構造を明示する、(e) 役割を与える、(f) 思考過程を引き出す、(g) 出力を固定する、(h) 長文を扱う、(i) 評価で反復改善する、の 9 点に収れんしています。新人に業務指示書を渡す感覚で組み立てるのが、最も再現性の高い設計です。
01.まず結論：3社のガイドはほぼ同じことを言っている
OpenAI / Anthropic / Google の公開ガイドの中身を見比べると、用語こそ違いますが、推奨している設計の柱はほぼ重なります。これは個別ベンダーの好みではなく、Transformer ベースの LLM 全般に共通する性質に基づくため、特定のモデルに依存しない設計の出発点として扱えます。
| 観点 | OpenAI | Anthropic | |
|---|---|---|---|
| 明確な指示 | Write clear instructions | Be clear and direct | Give clear, specific instructions |
| 文脈 | Provide reference text | Add context to improve performance | Provide context and constraints |
| 例示 | Few-shot examples | Use examples (multishot) | Use few-shot examples |
| 構造 | Use delimiters | Use XML tags | Structure with delimiters |
| 役割 | Use system messages | Give Claude a role | Set persona / system instructions |
| 思考 | Give the model time to think | Let Claude think (CoT) / Adaptive thinking | Encourage step-by-step reasoning |
| 出力固定 | Structured Outputs / function calling | Structured Outputs / tool use | Function calling / JSON mode |
| 評価反復 | Test changes systematically | Define success criteria and build evaluations | Iterate with eval sets |
02.原則1: 明確に・具体的に書く
プロンプトは「読み手が新人の同僚」と想定して書くのが、3 社のガイドに共通するアドバイスです。Anthropic の Prompting Best Practices は「同じプロンプトを最小限の文脈しか持たない同僚に渡して、彼らが迷わずに作業できるか」を判定基準として挙げています。OpenAI のガイドも、最初の戦略を Write clear instructions（明確な指示を書く）に置いています。
| 弱い指示 | 強い指示 |
|---|---|
| 資料をいい感じに要約して | 役員会で 3 分説明する前提で、意思決定事項のみを 5 項目以内・各 1 文で要約 |
| SEO 記事を書いて | 対象 KW・読者像・競合との差分・使う一次ソースを指定し、H2 を 6 本出してから本文を書く |
| コードをリファクタして | 命名規則を camelCase に統一し、重複ロジックを関数化し、振る舞いは変えない |
03.原則2: 文脈と参照テキストを渡す
モデルは事前学習データに含まれない情報を持っていません。社内固有・最新・ニッチな情報は、プロンプトの中で参照テキストとして渡します。OpenAI は Prompt Engineering Guide で「Provide reference text（参照テキストを提供する）」を 6 戦略のひとつに掲げ、ハルシネーションの最も基本的な低減策として位置付けています。
実務では、参照テキストを (a) プロンプトに直接貼る、(b) RAG で動的に検索して挿入する、(c) ツール経由で取得する、の 3 通りで運用します。文書が大きい場合は、後述の長文配置・引用抽出と合わせて設計します。
04.原則3: 例示（Few-shot）で出力を揃える
「こういう入力には、こういう形で答えてほしい」というペアを 1〜数個並べる few-shot プロンプトは、分類・抽出・フォーマット変換のような形式が決まったタスクで特に効きます。Anthropic は 3〜5 個の多様な例示を推奨しており、例示の質が出力の安定性を大きく左右することを指摘しています。
2026 年現在の推論モデル（Claude 4.7 / GPT-5 / Gemini 2.5 系）は内部推論で複雑なタスクを処理できる一方、few-shot を多く渡すと推論経路がぶれることがあります。Anthropic / OpenAI のガイドも「シンプルな指示＋必要なら 1〜数例」を推奨しており、例示の数より「典型例 + エッジケース」のカバー範囲を意識する設計が現実的です。
05.原則4: 構造を XML / JSON / 区切りで明示する
プロンプトの中に指示・文脈・例示・入力が混在すると、モデルは境界を誤解しやすくなります。Anthropic は Prompting Best Practices で、<instructions> / <context> / <example> のような XML タグで明示的に区切る設計を推奨しています。OpenAI / Google の各ガイドも、三重バッククォートや見出しなどの区切り（delimiter）の使用を推奨しており、構造を明示する点は共通しています。
| 区切り方法 | 得意な用途 | 提供元の推奨 |
|---|---|---|
| XML タグ | 複雑なプロンプト、複数文書、入れ子 | Anthropic（Claude） |
| 三重バッククォート / Markdown 見出し | コード・短文・1 文脈 | OpenAI / Google |
| JSON / YAML | API 連携・社内システム入力 | 全社 |
06.原則5: 役割（role）を設定する
システムプロンプトに役割を 1 文書くだけで、口調・優先順位・暗黙の前提が安定します。Anthropic の Prompting Best Practices は「Give Claude a role（役割を与える）」を独立した節として扱っており、たとえば「BtoB SaaS のプロダクトマネージャーとして」と書くだけで、視点や前提が変わることを示しています。OpenAI / Google も system message / system instructions として同じ機能を提供しています。
BtoB の業務エージェントでは、役割は「誰の立場で」「何を達成するために」「何をしない前提か」の 3 点を 1〜2 文で明示するのが運用しやすいパターンです。
07.原則6: 思考過程を引き出す（Chain-of-Thought）
2024 年後半以降、Chain-of-Thought（CoT）はプロンプトで都度引き出すものから、モデル自身が学習段階で内部化したものへと位置づけが変わりました。OpenAI の o1 系列（2024-09 公開）に続き、o3 / GPT-5、Anthropic Claude 4 系、Google Gemini 2.5 系などの推論モデルは、明示的に「ステップごとに考えて」と書かなくても、複雑タスクに対して内部で推論を走らせます。
プロンプト側で意識すべきことも変わりました。Anthropic の Claude Prompting Best Practices は、Claude Opus 4.7 などの推論モデルに対して、思考強度を adaptive thinking と effort パラメータで制御することを推奨しています。OpenAI の reasoning model 向けガイドも、推論モデルでは過剰な few-shot を避け、問題そのものを明確に渡すことを基本としています。
ただし、出力された「思考過程」が実際の内部推論を忠実に反映しているとは限りません。Anthropic の Reasoning Models Don't Always Say What They Think（2025-04） は、推論モデルが回答のヒントを実際には使っていても、その依存を出力中で開示しないケースが多いことを実証しました（Claude 3.7 Sonnet で平均 25%、DeepSeek R1 で 39% の開示率）。CoT を「説明として読む」のではなく、最終出力の品質と整合性で評価する運用が現実的です。
08.原則7: 出力フォーマットを固定する（Structured Outputs）
AI の出力を社内システムに流し込むときは、自然文ではなく JSON Schema で固定する設計が標準です。OpenAI の Structured Outputs、Anthropic の Structured Outputs / Tool Use、Google の Structured output はどれも、フィールド名・型・必須項目をスキーマで強制する機能を提供しており、後工程の不安定さを大幅に減らせます。
OWASP LLM05「Improper Output Handling」の観点でも、AI 出力をパース可能な構造で受け取ることは、出力をそのままシェルや SQL に流す事故を防ぐ第一歩です。
09.原則8: 長文は配置と引用で扱う
1M トークン級のコンテキストを使える 2026 年のモデルでも、長文をそのまま流し込めば精度が出るわけではありません。NVIDIA の RULER（What's the Real Context Size of Your Long-Context Language Models?） など 2024 年以降の長文評価ベンチマークも、宣伝上のコンテキスト長と、実際に正答できる実効コンテキスト長には乖離があることを示しています。Anthropic の Claude Prompting Best Practices も、長文を扱う際は配置と引用抽出を明示するよう推奨しており、配置の設計が前提となります。
| 長文プロンプトの設計 | 中身 | 効く理由 |
|---|---|---|
| 重要情報は冒頭か末尾に置く | 結論・指示・出力指定はプロンプトの両端に | 長文の中央位置で精度が落ちる傾向への対処（RULER 等で再現） |
| 引用優先で答えさせる | 「文書から関連箇所を {<quotes>} に抜き出してから答える」と指示 | ノイズを切り、忠実度（faithfulness）が上がる |
| 文書を XML で構造化 | {<documents>} / {<document index=1>} の入れ子で渡す | Anthropic Best Practices が推奨 |
| 長文より RAG | 全部渡さず関連範囲だけを動的に挿入 | コスト・精度・速度の全方位で有利 |
10.原則9: 評価セットで反復改善する
プロンプトは「最後の 1 回でビシッと決める」ものではなく、評価セットで反復改善するものです。Anthropic Prompting Best Practices の冒頭は Define success criteria and build evaluations を出発点として明示しており、OpenAI Prompt Engineering Guide も「Test changes systematically」を 6 戦略の最後に挙げています。
実務では、代表タスク 30〜200 件で評価データセットを作り、(1) ベースライン測定、(2) プロンプト変更、(3) 再評価、(4) 差分が有意かを確認、のループを回します。社内タスクが少ない初期は LLM-as-a-Judge（別 LLM に採点させる手法）で粗く回し、後で人手評価に置き換える進め方が現実的です。
11.BtoB 業務でよく使う組み立てパターン
9 原則を実務に落とすときの定型パターンを 4 つ示します。詳細は別記事「プロンプトの基礎」と組み合わせると、設計の全体像がつかみやすくなります。
| パターン | 用途 | 中身 |
|---|---|---|
| 業務指示書テンプレ | 問い合わせ分類、要約、メール起案 | 目的 / 背景 / 材料 / 制約 / 出力形式 / 例示 / 確認条件 の 7 ブロック |
| RAG + Structured Outputs | FAQ・ナレッジ検索 | 検索結果を文脈、回答は JSON スキーマで固定 |
| CoT + 自己検証 | 見積もり・与信・計算 | 思考過程 → 最終答 → 自己点検の 3 段 |
| Few-shot + Tool Use | 業務システム更新の下書き | 例示で形式を見せ、ツールで構造化更新案を返す |
12.やってはいけないこと
| やりがちな失敗 | なぜダメか | 代替 |
|---|---|---|
| 曖昧な表現を重ねる | 「いい感じ」「丁寧に」「分かりやすく」は判断基準にならない | 数値・例示・構造で具体化 |
| 禁止事項を否定形だけで書く | 「〜しないで」は守られにくい | Anthropic が指摘するように肯定形で書き換える |
| 全文書を毎回コンテキストに詰める | コスト増・長文中央位置で精度低下 | RAG で関連範囲だけ渡す |
| 1 度のプロンプトで決め打ち | 再現性が無く改善ループが回らない | 評価セットで反復改善 |
| 「呪文集」コピペ運用 | 業務固有の前提が抜け、品質が安定しない | 業務指示書テンプレ＋RAG＋構造化出力 |
プロンプトとは｜指示・文脈・例示の3要素とAI回答の決まり方
プロンプトそのものの構成要素と基本概念は別記事で詳しく整理しています。あわせてご覧ください。
AI出力の品質管理｜ハルシネーション・出典確認・人間レビューの実務チェック
評価セット運用と品質保証の実務は別記事で整理しています。あわせてご覧ください。
AIセキュリティ・権限設計｜エージェントに何を触らせ、何を触らせないか
プロンプトインジェクション対策と権限設計は別記事で整理しています。あわせてご覧ください。
13.よくある質問（FAQ）
ベストプラクティスはモデルごとに違いますか？
細部は違いますが、9 原則レベルではほぼ共通です。OpenAI Prompt Engineering Guide / Anthropic Prompting Best Practices / Google Gemini Prompting Guide は、用語こそ違うものの、明確に書く・文脈を渡す・例示する・構造を明示する・役割を与える・思考過程を引き出す・出力を固定する・長文を扱う・評価で反復改善する、の方向で揃っています。XML タグの推奨度（Claude が高い）など、モデル固有のクセはそれぞれの公式ガイドで補強します。
Chain-of-Thought（CoT）は今でも有効ですか？
明示的に「ステップごとに考えて」と書く CoT の効果は推論モデルでは小さくなっていますが、原理は健在です。Claude 4 系 / GPT-5 / Gemini 2.5 系は CoT を学習に組み込んでおり、明示しなくても内部推論が走ります。一方、Anthropic の Reasoning Models Don't Always Say What They Think（2025-04） は、推論モデルが出力する「思考過程」が実際の内部推論を忠実に反映していない場合があることも示しています。プロンプト側では、思考強度を adaptive thinking のような効率パラメータで制御し、出力は思考過程ではなく最終結果の品質で評価するのが現代的な使い方です。
「呪文プロンプト集」を社内で配るのは良くないですか？
業務固有の前提が抜け、再現性が低くなるため推奨しません。2022〜2023 年に流行した「魔法のプロンプト集」は個人利用には便利でしたが、組織で使うなら、業務指示書テンプレ＋RAG＋構造化出力＋評価セットの 4 点セットで運用するのが、現在の標準的な進め方です。
プロンプトの長さはどのくらいが良いですか？
用途次第ですが、長ければ良いわけではありません。NVIDIA の RULER など長文評価ベンチマークは、宣伝上のコンテキスト長と、実際に正答できる実効コンテキスト長に乖離があることを示しています。重要情報（指示・出力指定）は両端に置き、本体は RAG で関連範囲だけ動的に挿入するのが安定します。1M トークン級のコンテキストでも、配置設計の重要性は変わりません。
Structured Outputs と Function Calling はどちらを使うべきですか？
目的が違います。Structured Outputs は「最終出力を JSON スキーマに揃える」機能、Function Calling は「外部関数 / ツールを呼ぶ判断と引数を返す」機能です。BtoB 業務では、後工程システム連携には Structured Outputs、ツール利用エージェントには Function Calling と使い分けます。両者は併用も可能で、Function Calling の引数や戻り値を Structured Outputs で固定する設計が一般的です。
評価セットを作る余裕がない場合はどうすれば良いですか？
まずは代表タスク 10〜30 件の小さな評価セットから始めます。完璧を目指さず、ベースライン → 変更 → 再評価のループが回ることを優先します。初期は LLM-as-a-Judge（別 LLM に採点させる手法）で粗く回し、品質が見えてきた段階で人手評価とエッジケース追加に置き換える進め方が現実的です。
14.まとめ
プロンプト設計のベストプラクティスは、OpenAI / Anthropic / Google の公開ガイドと CoT 系の研究に共通する 9 原則に集約できます。明確に書き、文脈と例示を渡し、構造と役割と思考過程を引き出し、出力を固定し、長文を扱い、評価セットで反復改善する。これらを業務指示書として組み立てるのが、特定モデルに依存しない再現性の高い設計です。
モデルの世代が変わっても、原則そのものは大きく変わりません。プロンプトを業務システムの一部として扱い、社内テンプレート・RAG・構造化出力・評価セットの 4 点セットで運用するのが、2026 年時点の標準的な進め方です。
プロンプト設計を業務に組み込みませんか
AI 活用や AI エージェント導入のご相談、PoC、伴走支援をご検討の方は、お気軽にお問い合わせください。
