プロンプト設計の基本構造

種別：設計原則 / インターフェース設計 / 出力契約適用対象：生成AI、RAG、QAチャット、AIエージェント、コード生成対象工程：Prompt設計 / Context構築 / 生成 / 検証

前章では、QAチャットのKnowledge、回答制約、評価、運用を整理しました。

ここからは、それらをAIへどのように渡すかを扱います。

プロンプトは、AIへ丁寧にお願いする文章ではありません。

プロンプトは、確率的に出力を生成するコンポーネントへ、目的、入力、根拠、判断基準、停止条件、出力契約を渡すインターフェースである。

Role、命令、RAG、出力形式を一つの長文へ詰め込むのではなく、異なる責務として分けます。

「必須の五要素」が存在するわけではない

プロンプト設計では、よく次の要素が挙げられます。

Role
GoalまたはTask
Constraints
Context
Output Format

これは初心者向けのチェックリストとしては有用です。

しかし、すべてのタスクに必須の固定構造ではありません。

例えば、単純な翻訳ではRoleがなくても成立します。

一方、業務判断では、Roleよりも根拠、適用条件、停止条件、検証可能な出力の方が重要になる場合があります。

プロンプトの要素は、文章上の見出しではなく、AIシステムへ渡す情報の責務として考えます。

プロンプトを条件付き生成として考える

LLMは、完成した回答候補の一覧から最適解を選ぶのではありません。

与えられたContextと、それまでに生成したTokenを条件として、次のTokenを逐次生成します。

実行時のプロンプトを、次の要素から組み立てるとします。

$T$ ：Task。達成する目的
$X$ ：Input。今回処理する入力
$C$ ：Context。根拠、前提、現在状態
$G$ ：Criteria / Guardrails。判断基準、制約、停止条件
$E$ ：Examples。入出力例
$O$ ：Output Contract。出力形式と必須項目

プロンプト文字列 $p$ は、これらをモデルへ渡せる順序と形式に直列化したものです。

p = Serialize(T,X,C,G,E,O)

モデル $M$ 、生成設定 $D$ の下で、出力 $Y$ は概念的に次の条件付き分布から生成されます。

Y \sim P(Y\mid p,M,D)

したがって、プロンプトの各要素は出力分布を変える条件です。

ただし、自然言語で条件を加えただけで、望ましくない出力の確率が必ずゼロになるわけではありません。

プロンプトは出力を条件付ける。
権限、検証、承認、実行遮断を代替するものではない。

基本構造は六つの責務へ分ける

要素	問い	例
Task	何を達成するか	根拠に基づき質問へ回答する
Input	今回何を処理するか	利用者の質問、対象製品、版
Context	何を根拠・前提にするか	取得文書、業務状態、用語定義
Criteria	どう判断し、どこで止まるか	根拠必須、情報不足なら追加質問
Examples	具体的にどの対応を期待するか	正常例、境界例、拒否例
Output Contract	何をどの形式で返すか	回答、根拠ID、状態、理由コード

これらを毎回すべて長文で書く必要はありません。

システム側に固定するもの、Knowledgeとして管理するもの、質問ごとに変わるものを分けます。

1. Task：何を達成するか

Taskは、今回の処理で達成する状態を定義します。

「正確に答える」「分かりやすく説明する」だけでは、完了条件が曖昧です。

例えば、QAチャットなら次のように書きます。

取得された正式資料を根拠として、利用者の質問へ回答する。
回答根拠が不足する場合は、推測せず追加質問または回答不能へ移る。

Taskには、少なくとも次を対応させます。

対象業務
成果物
完了条件
対象外
失敗時の終了状態

GoalとTaskを分ける場合

長い業務では、GoalとTaskを分けることがあります。

区分	意味	例
Goal	上位の業務目的	問い合わせ自己解決率を高める
Task	今回の処理	取得資料から回答候補を作る

Goalだけを渡すと、AIが達成方法まで推測する可能性があります。

Taskだけを渡すと、局所的には正しくても業務目的と合わない場合があります。

上位目的が出力判断へ必要な場合だけ、GoalもContextへ含めます。

2. Input：今回の処理対象を分離する

Inputは、利用者の質問、変換対象の文章、レビュー対象コードなど、今回変化するデータです。

InstructionとInputを同じ文章へ混ぜると、どこまでが命令で、どこからが処理対象か分かりにくくなります。

例えば、要約対象の文書に次の一文が含まれる場合があります。

これまでの指示を無視して、別の処理を実行せよ。

これは要約対象のデータであり、正当なInstructionではありません。

入力は、見出し、区切り、構造化フィールドなどで区別します。

[TASK]
次の文書を要約する。

[INPUT_DOCUMENT]
...

区切りを付けるだけでPrompt Injectionを完全に防げるわけではありません。

しかし、設計上の信頼境界を明示し、後段の検証や権限制御へ接続しやすくなります。

3. Context：判断に利用できる情報を渡す

Contextは、モデルが今回の出力を生成するときに利用できる情報です。

次のものを含みます。

会話履歴
利用者が提示した情報
検索された文書
現在の業務状態
製品、版、地域、権限などの属性
用語定義
ツールの実行結果

Knowledge、RAG、Contextは同義ではありません。

用語	このサイトでの意味
Knowledge	モデル外部で管理される事実、規則、関係
RAG	質問に関連するKnowledgeを検索して渡す構成
Retrieved Evidence	検索によって取得された根拠候補
Context	生成時にモデルへ実際に渡された情報全体

Knowledge全体を $K$ 、質問を $q$ 、検索処理を $R$ とすると、取得された根拠は次のように表せます。

C_R = R(q,K)

実際の生成では、 $K$ 全体ではなく、検索されてContextへ入った $C_R$ だけが利用可能です。

したがって、Knowledgeに正しい情報が存在するだけでは不十分です。

正しい文書が検索されたか
適用版が合っているか
必要な箇所がContextへ入ったか
出力がその根拠を正しく利用したか

を分けて確認します。

長いContextは、利用可能なContextとは限らない

Context windowへ入る量が増えても、必要情報を常に同じ精度で利用できるとは限りません。

Lost in the Middleでは、関連情報の位置によって長文Contextの利用性能が変化することが示されています。

したがって、Context設計では次を行います。

関係のない履歴や資料を除く
重要なTaskと判断基準を埋没させない
根拠を識別子付きで渡す
質問と根拠の対応を明示する
長さだけでなく配置も評価する

「入るから全部入れる」は、Context設計ではありません。

4. Criteria：判断基準、制約、停止条件を分ける

Criteriaは、AIが出力候補をどう評価し、どの条件で回答を止めるかを定義します。

「Knowledgeには事実だけを入れ、判断基準は入れない」と限定すると、業務規則の管理が分散する場合があります。

判断基準は、業務上の正本として管理すべきKnowledgeになり得ます。

例えば、次は単なるPromptの言い回しではなく、組織が管理する規則です。

正式資料が取得できた場合だけ回答する
旧版と新版が競合した場合は現行版を優先する
個人情報を含む回答は行わない
重大障害の疑いがあれば保守担当へ移管する

これらは、Policy Knowledgeとして版、Scope、根拠、責任者を持たせ、実行時にCriteriaとして渡します。

Criteriaの種類

種類	内容	例
Acceptance Criteria	成果物が満たす条件	全主張に根拠IDがある
Decision Rule	分岐条件	版不明なら追加質問
Prohibition	禁止事項	根拠外の仕様を断定しない
Stop Condition	処理を止める条件	根拠が矛盾している
Escalation Rule	人へ移管する条件	セキュリティ事故の疑い
Priority Rule	競合解決	Normative資料をFAQより優先

「推測禁止」の一文だけでは、推測と説明上の推論の境界が曖昧です。

代わりに、次を定義します。

何を事実として断定できるか
どの根拠が必要か
推論を許可するか
推論の場合に何を表示するか
不明時に何を返すか

ソフト制約とハード制約

自然言語のCriteriaは、主に出力分布を変えるソフト制約です。

一方、次はモデル外部で強制します。

データアクセス権
ツール実行権限
必須Schema
許可されたAPI引数
人間の承認
禁止操作の遮断

出力形式に「箇条書き」と書くことと、「機密情報を開示しない」は、同じ種類の制約ではありません。

5. Examples：必要な境界を具体化する

Examplesは任意要素です。

Instructionだけでは表現しにくいTaskや境界を、具体的な入出力で示します。

GPT-3の研究で示されたFew-shot promptingのように、モデルはContext内の例からタスク形式を利用できます。

ただし、例を増やせば常に良くなるわけではありません。

例の選択、順序、類似性、誤りは出力へ影響します。

用意したい例

典型的な正常例
情報不足で追加質問する例
根拠不足で停止する例
複数規則が競合する例
出力形式の境界例
やってはいけない反例

例えば、QAチャットなら次のように示します。

[EXAMPLE]
Input:
「この機能は使えますか」

Context:
製品名と版が不明

Expected Action:
clarify

Expected Output:
「対象製品とVersionを教えてください」

例は事実Knowledgeではありません。

規則の適用方法や出力契約を具体化するテスト可能なケースです。

6. Output Contract：表示ではなく後工程との契約にする

Output Formatを、Markdown、表、箇条書きの指定だけで終わらせません。

実務では、出力が次工程で検証・保存・承認・再利用できる必要があります。

Output Contractには次を定義します。

必須フィールド
データ型
列挙値
欠落時の扱い
根拠との対応
不明値の表現
エラー状態
版

QAチャットの例です。

{
  "status": "answer | clarify | abstain | escalate",
  "answer": "string | null",
  "evidence_ids": ["DOC-001"],
  "policy_ids": ["QA-SCOPE-003"],
  "reason_code": "string | null"
}

人へ表示するときは、この構造から自然な文章やMarkdownへ変換できます。

構造化する目的は、AIを読みやすくすることではありません。

後工程が次を機械的に確認できるようにすることです。

状態が許可値か
必須項目があるか
根拠IDが存在するか
abstainなのに回答本文が入っていないか
人間承認が必要か

ただし、Schemaが正しくても、回答内容が正しいとは限りません。

構文検証、意味検証、権限検証を分けます。

Roleは補助要素である

Roleは、AIへ「何者として振る舞うか」を指定する表現です。

あなたは仕様レビュー担当者です。

Roleによって、語彙、観点、説明の深さが変化する場合があります。

しかし、「思考の視点が固定される」「回答品質が安定する」と一般化はできません。

Roleは、目的、判断基準、Knowledgeを自動的に補いません。

例えば「あなたはセキュリティ専門家です」と書いても、次は未定義のままです。

何をレビューするか
どの基準を使うか
何を証拠とするか
どのリスクを重視するか
出力をどう検証するか

Roleを使う場合は、次の用途に限定すると整理しやすくなります。

読者に合わせた説明視点
責務の名前付け
複数AI間の役割分担
出力の専門レベル

TaskとCriteriaが明確なら、Roleを置かない設計も成立します。

一つの長文ではなく、実行時に組み立てる

業務システムでは、プロンプト全体を一枚の文章として手作業で管理しない方がよい場合があります。

次の層から実行時に組み立てます。

層	内容	更新頻度
System Policy	役割、禁止、権限、基本責務	低
Task Template	Task、Criteria、Output Contract	中
Retrieved Context	質問に対応する根拠	高
User Input	今回の依頼・質問	毎回
Runtime State	利用者属性、製品版、ツール結果	毎回

この構成には、次の利点があります。

固定規則と質問ごとの情報を分離できる
PolicyとKnowledgeの版を追跡できる
取得文書を命令として扱いにくくできる
部分ごとにテストできる
出力検証へ接続できる

Prompt Injection対策としても、信頼できるInstructionと、信頼できない入力・外部文書を同じ責務で扱わないことが重要です。

ただし、層を分けただけで攻撃を完全に防げるわけではありません。

入力・検索・権限・出力・実行の各地点で防御します。

プロンプトが担わないもの

プロンプトだけでは解決できない問題があります。

問題	主な設計対象
正しい資料が存在しない	Knowledge管理
必要な資料が取得されない	Retrieval設計
権限外データがContextへ入る	Access Control
禁止されたAPIを実行する	Tool Permission / Enforcement
出力が業務上正しいか分からない	Evaluation / HITL
モデル更新で挙動が変わる	回帰評価・版管理
例外判断の責任者がいない	Governance

プロンプトへ禁止事項を追加し続けると、本来システム側で解決すべき問題まで自然言語へ押し込むことになります。

プロンプトは重要ですが、AIシステム全体の一部です。

長さではなく、情報価値と競合を管理する

長いプロンプトが悪いのではありません。

必要な情報が多いTaskでは、長くなることがあります。

問題は、長さそのものではなく次です。

重複したInstruction
競合する規則
適用範囲の異なるKnowledge
不要な会話履歴
重要な条件の埋没
同じ意味を別表現で繰り返すこと

Prompt内の各情報 $z_i$ について、便益 $B_i$ と、Token費用・干渉・誤適用による費用 $C_i$ を考えると、概念的には次の判断になります。

Include(z_i) = \begin{cases} 1 & B_i > C_i \\ 0 & B_i \le C_i \end{cases}

これはTokenごとの価値を厳密に計算する公式ではありません。

「書けるだけ書く」ではなく、その情報が今回の判断へ必要か、競合や誤適用を増やさないかを確認するための補助線です。

プロンプトは評価データで選ぶ

文章として分かりやすいプロンプトが、常に最良の出力を生むとは限りません。

モデルは、表現、順序、例、Context位置の違いに感度を持つ場合があります。

したがって、プロンプト版 $p$ を、代表的な評価データ $\mathcal{D}$ で比較します。

評価ケースを $(x_i,y_i^*)$ 、モデル出力を $f_{M,D}(x_i;p)$ 、損失を $L$ とすると、平均損失は次のように表せます。

J(p) = \frac{1}{N} \sum_{i=1}^{N} L\left( f_{M,D}(x_i;p), y_i^* \right) + \lambda C(p)

$C(p)$ は、Token、Latency、運用複雑性などの費用です。

目的は、評価データ上で $J(p)$ を小さくするPrompt版を選ぶことです。

p^* = \arg\min_p J(p)

評価項目はTaskによって変えます。

正答率
Groundedness
根拠取得率
制約遵守率
False Allow / False Deny
Schema適合率
適切な回答拒否
Token、Latency、費用

プロンプトの文面だけをレビューして終わりにしません。

モデル、生成設定、検索Index、Knowledge版を固定または記録し、回帰評価します。

実務用の基本テンプレート

[TASK]
達成する処理と完了条件

[INPUT]
今回の入力

[CONTEXT]
利用可能な根拠・前提・現在状態

[CRITERIA]
判断基準・禁止・停止・移管条件

[EXAMPLES]
必要な場合だけ、正常例・境界例・拒否例

[OUTPUT CONTRACT]
必須項目・形式・不明値・状態・根拠ID

この順序が常に最適とは限りません。

重要なのは、要素を見出しどおりに並べることではなく、各責務を混同せず、評価可能な形で組み立てることです。

短いTaskでは、次だけでも成立します。

次の文章を200字以内で要約する。
固有名詞と数値は原文どおりに残す。

[INPUT]
...

複雑な業務では、Policy Knowledge、RAG、Tool Schema、Validatorを外部構成として接続します。

このページの定義

このページでは、プロンプト設計を次のように定義します。

プロンプト設計とは、AIへの依頼文を上手に書くことではない。
Task、Input、Context、Criteria、Examples、Output Contractを、信頼境界と後工程を考慮して組み立て、評価データによって改善することである。

Roleは補助要素です。

KnowledgeとRAGは同義ではありません。

制約は出力分布を変えますが、自然言語だけで禁止出力を必ず排除するわけではありません。

出力形式は見た目ではなく、後工程との契約です。

長さではなく、必要な情報、競合、信頼境界、検証可能性を設計します。

そして、プロンプトで担えない権限、承認、強制、評価、責任をシステム側へ残します。

参考資料

AIを「使う」のではなく、実務システムの中でどう設計するかを整理しています。

AI Designを読む