Skip to Content
Docs03. 実装プロンプトエンジニアリングの上級パターン
上級prompt-designfew-shotprompt-caching更新: 2026-09-10この記事の誤りを報告

この記事の音声は準備中です。

音声の一覧・再生リストへ

プロンプトエンジニアリングの上級パターン

この記事の目的

基礎技法で名前と使いどころを掴んだ技法を、なぜ効くか(仕組み)・どう設計するか(詳細)・どう検証するかまで掘り下げます。難しいタスクのプロンプトを設計し、うまくいかないプロンプトを原理から診断できる状態がゴールです。

対象読者

  • 基礎技法では足りない複雑なタスク(長文書・厳密な形式・揺れる判断)のプロンプトを設計するエンジニア
  • 「動いているが理由が説明できない」プロンプトを、根拠のある設計に作り直したい人

前提知識

本文

概要: 基礎技法との分担

層正本本記事
名前と使いどころ基礎技法—
技法の詳細設計と検証本記事構造化・例示・思考・出力・長文・頑健性の 6 領域
システムプロンプト(長期間・多状況)Agent 向けプロンプト設計—
モデル別の具体的な推奨Claude / OpenAI / Gemini の特化ガイド本記事はモデル中立の原理まで

構造化の詳解: 配置には 3 つの力学がある

プロンプトの構造(何をどの順で置くか)は、キャッシュの仕様と、配置を変えたときの品質を合わせて決めます。以下は比較実験を始めるための 3 つの観点で、すべてのモデルに共通する最適配置ではありません。

プロンプトエンジニアリングの上級パターン: 構造化の詳解: 配置には 3 つの力学があるの図プロンプトエンジニアリングの上級パターン: 構造化の詳解: 配置には 3 つの力学があるの図
プロンプトエンジニアリングの上級パターン: 構造化の詳解: 配置には 3 つの力学があるの図
図を元の大きさで表示

図の中をスクロールして読めます。キーボードでは図の領域へ Tab で移動し、矢印キーを使います。読み終わったら、この見出しをもう一度選ぶと閉じます。

プロンプトエンジニアリングの上級パターン: 構造化の詳解: 配置には 3 つの力学があるの図プロンプトエンジニアリングの上級パターン: 構造化の詳解: 配置には 3 つの力学があるの図
  • レイヤ構造: 役割・制約・手順(固定)→ 例(半固定)→ 資料(タスクごと)→ ユーザー入力(可変)は、前方一致方式のキャッシュを利用しやすい配置例です(注意機構とコンテキストウィンドウの仕組み)。長文内の位置で品質が変わることは Lost in the Middle でも報告されていますが、末尾が常に最良とは限りません。資料の前後に置いた指示を比較評価します
  • 区切りの設計: 領域(指示・資料・例・出力欄)を開始・終了が明確なタグで囲み、対応関係を示します。資料側に同じ区切りが含まれる場合のエスケープも設計します。タグは認可や信頼境界の強制手段ではありません。記法の効果は利用中モデルで確認します
  • 役割・視点の設計: 役割の付与は語彙・粒度・前提の選択を条件付けます(生成の条件が変わる、という 10 章の原理そのもの)。効かせ方の要点は「肩書き」ではなく判断基準と読者像を与えることです(「あなたは専門家」より「◯◯の観点で、△△な読者向けに」)。過剰な人格設定は口調にばかり効いて判断品質に効かないことが多く、トークンの無駄になります

例示(few-shot)の詳解: 例は第 2 の仕様書

  • 選択: 例セットは「分布の代表 + 境界例 + 否定例」を候補にします。「該当なし」「回答を拒否すべき入力」も対象に含め、常に肯定的な結果を出す偏りがないか確認します。分類では例のラベル比率を変えた場合の誤判定も測ります
  • 順序: 例の順序だけで性能が大きく変わる結果が Lu らの原論文 で報告されています。最後の例が出力形式を決めるという一律の規則ではありません。順序を入れ替えて比較し、指示の明文化・例の選択・モデル差を切り分けます
  • 形式の伝染: 例の長さ・文体・構造は内容と独立に出力へ伝染します。これは意図的に使えば強力な形式制御(スタイルを例で示す)であり、無自覚だと事故(例が全部短いので出力も短くなる)になります
  • 動的選択: 入力に類似した例を検索して差し込む方式は、多様な入力分布で精度を上げますが、(1) 例がプロンプトの可変部分になるためキャッシュと衝突する(後方に置く)、(2) 検索品質が新たな故障点になる、という代償があります。静的な例で足りるかをまず検証します

思考の制御: モデルと検証手段で使い分ける

出力の制御: 「お願い」を物理的な制約に近づける

  • 応答の書き出し指定(prefill): アシスタント応答の冒頭を開発者側で与えてから続きを生成させる技法です。前置きの除去(いきなり JSON から始めさせる)・形式の強制・役割の維持に効きます。生成は与えた書き出しの続きとして条件付けられるため、指示より強い形式制御になります(対応可否・作法はモデルにより異なります)
  • 停止シーケンス: 「ここで止まる」を文字列で指定し、余計な続きを構造的に断ちます。区切り記法と組にすると安定します
  • 構造化出力LLM の出力を JSON Schema などの機械可読なスキーマに従わせる技術。後続の処理がコードである出力(分類・抽出・スコア)に使う。との併用: 機械処理する形式は構造化出力(構造化出力)で強制するのが正本です。プロンプト側の仕事は「フィールドに何を入れるか」の内容品質に集中させます
  • 長さの制御: 最大トークン数は「打ち切り」であって長さ指定ではありません(LLM はどうやってテキストを生成するか)。長さは指示(「3 点、各 1 文」)と例で制御し、上限はあくまで安全弁にします

長文・大量データのパターン

頑健性: きれいな入力を前提にしない

パターンの検証方法

上級技法ほど「効いた気がする」に陥りやすいため、検証の規律が本体です。

  1. 変更の寄与を分ける: 最初は 1 変更ずつ比較します。複数を組み合わせた場合は、要素を外す比較実験で個別の効果と組み合わせの効果を確認します
  2. ペア比較 + 複数回実行: 変更前後を同じ評価セットで、非決定性を踏まえ複数回比較します(Agent 評価の基礎)
  3. 説明と証拠を分ける: 10 章の仕組みは仮説作りに使います。「なぜ効いたか」の説明がもっともらしくても因果関係の証明にはなりません。未使用の判定セットやモデル更新後の再評価で効果が残るか確認します
  4. 記録: 採用したパターンと検証結果を資産として残します(プロンプト資産の管理とバージョニング)

実務での注意点

アンチパターン

  • 技法を足し算で盛り込む → 役割 + 例 8 個 + 思考指示 + 制約 30 行…と積むほど干渉し、どれが効いているか不明になる → 最小構成から 1 変更ずつ検証して足す
  • 例を増やせば精度が上がると考える → 効くのは数ではなく選択(代表・境界・否定例)と一貫性。増えた例はコストと干渉になる → 例セットを設計し、順序シャッフルで頑健性を確認する
  • 検証器のない自己検証で品質を保証する → 「もう一度考えて」は正解を壊すこともある → 自己検証には検証可能な基準(チェックリスト・照合手段)を渡す
  • prefill・区切り記法を別モデルへ無検証で移植する → 対応・効き方はモデル依存で、静かに無効化される → 移行時に公式ガイド確認 + 回帰評価を行う(バージョニング・デプロイ・モデル更新追従)
  • きれいな入力だけでテストする → 実入力の言い換え・崩れで一気に劣化する → パラフレーズ・破損入力をテストセットに含める

チェックリスト

  • プロンプトがレイヤ構造(固定 → 半固定 → 可変)になっており、配置の理由を説明できる
  • 例セットに境界例・否定例が含まれ、ラベル分布を確認した
  • 考察と結論の生成順序が、品質要求と整合している
  • 機械処理される出力は構造化出力 + プロンプトは内容品質、と分担している
  • 長文処理の方式(全文・分割統合・逐次)を資料の性質から選んだ
  • パラフレーズ・崩れた入力での挙動を検証した
  • 採用パターンごとに「なぜ効くか」と検証結果が記録されている

関連トピック

参考資料

TODO・未確認事項

プロンプトエンジニアリングの基礎技法プロンプト最適化(評価駆動の改善と自動化)