Instruction・Knowledge・Evidenceの責務分離

種別：設計原則 / 責務分離 / Context設計適用対象：生成AI、RAG、QAチャット、AIエージェント対象工程：Instruction設計 / Knowledge管理 / 検索 / 生成 / 検証

AIへ渡す情報は、すべて最終的にはモデルが読み取るコンテキストになります。

しかし、AIシステムを設計する際には、その情報を役割ごとに分けて考えた方が、更新・検証・障害分析をしやすくなります。

この資料では、AIへ与える情報を次の三つに整理します。

Instruction：何をさせるか
Knowledge：何を前提とするか
Retrieved Evidence：今回、何を根拠として使うか

ここで注意したいのは、これは情報を完全に三分割する理論ではないということです。

実装上は、三つとも一つのプロンプトやコンテキストへ格納される場合があります。重要なのは保存場所ではなく、その情報が何の役割を担っているかです。

数式で見た三つの役割

入力を $X$ 、指示を $I$ 、継続的な知識を $K$ 、検索によって取得した根拠を $Z$ 、出力を $Y$ とします。

AIの出力は、単純化すると次の条件付き確率として考えられます。

P(Y \mid X, I, K, Z)

同じ入力 $X$ であっても、指示、前提知識、取得した根拠が変われば、出力分布も変わります。

より一般化すれば、モデル $M$ 、学習時点までに獲得した知識 $D$ 、会話履歴やToolの実行結果なども条件に含まれます。

P(Y \mid X, I, K, Z, M, D)

この式はAIの内部を完全に説明するものではありません。設計上、何を変えると出力が変わり得るのかを整理するためのモデルです。

1. Instruction：何をさせるか

Instructionは、AIへ今回の仕事と振る舞いを伝える情報です。

例えば、次のような内容が含まれます。

質問へ回答する
設計をレビューする
根拠を引用する
不明な場合は推測せず、その旨を示す
JSON形式で出力する
個人情報を回答へ含めない

Instructionは、主にAIの行動や出力形式を方向付けます。

ただし、自然言語で「してはいけない」と指示しても、禁止された出力の確率が数学的にゼロになるわけではありません。

P(\text{禁止された出力} \mid I) \neq 0

そのため、権限制御、入力検証、出力スキーマ、実行前承認など、必ず守る必要がある条件はプログラム側でも制御します。

Instructionは重要ですが、セキュリティ機構そのものではありません。

2. Knowledge：何を前提とするか

Knowledgeは、複数の処理で継続的に利用する知識です。

例えば、次のような情報です。

用語の定義
製品の基本仕様
業務ルール
設計原則
判断基準
禁止事項
エスカレーション条件
過去に確定した意思決定

Knowledgeは「AIの自由を狭める情報」だけではありません。

AIが組織固有の前提を理解し、同じ基準を繰り返し利用するための情報です。制約もKnowledgeに含まれますが、事実、定義、判断基準も含まれます。

また、Knowledgeはモデルが学習時に獲得した一般知識とは区別して管理する必要があります。

社内ルールや現在の仕様は、モデルが最初から知っているとは限りません。知っているように見えても、古い情報や一般論である可能性があります。

3. Retrieved Evidence：今回、何を根拠として使うか

Retrieved Evidenceは、今回の入力に応じて検索し、回答の根拠候補として取り出した情報です。

例えば、次のようなものがあります。

該当する仕様書の一節
現在有効な社内規程
過去の類似障害
対象コードと関連ファイル
顧客との議事録
データベースの検索結果

RAGは、この根拠候補を検索し、生成時のコンテキストへ渡す仕組みです。

検索対象から根拠 $Z$ を取得し、それを使って回答 $Y$ を生成する流れは、簡略化すると次のように表せます。

P(Y \mid X) = \sum_Z P(Z \mid X)P(Y \mid X, Z)

ここで重要なのは、RAGは情報の種類ではなく、必要な情報を検索して渡す仕組みだという点です。

また、検索された文書がそのまま正しい事実になるわけでもありません。

古い文書が取得される
関係の薄い箇所が取得される
複数の文書が矛盾する
必要な文書が検索対象に存在しない
正しい文書が検索結果から漏れる

といった問題があり得ます。

Retrieved Evidenceは「真実」ではなく、回答時に利用する根拠候補です。

三つは、保存場所ではなく役割で分ける

例えば、ある社内規程が常にAIへ与えられるなら、継続的なKnowledgeとして扱えます。

同じ規程でも、質問に応じて検索して取得するなら、実行時にはRetrieved Evidenceとして働きます。

また、それらをAIへ渡す際には、すべて一つのプロンプトへ組み立てられることがあります。

Instruction
「取得した根拠だけを使い、出典を示して回答する」

Knowledge
「社内で使う用語、回答方針、エスカレーション条件」

Retrieved Evidence
「今回の質問に該当した規程の第12条」

            ↓

実行時コンテキスト

            ↓

AIの回答

したがって、「プロンプト」「Knowledge」「RAG」を別々の箱として考えるだけでは不十分です。

プロンプトは情報を渡す形式でもあり、KnowledgeはRAGで取得される場合もあります。

分けるべきなのは物理的な格納場所ではなく、次の責務です。

役割	設計上の問い	主な管理対象
Instruction	AIへ何をさせるか	タスク、振る舞い、出力形式
Knowledge	何を継続的な前提とするか	定義、規則、判断基準、確定事項
Retrieved Evidence	今回どの根拠を使うか	検索対象、検索条件、鮮度、出典

なぜ役割を分けるのか

三つを分ける目的は、AIを必ず正しく動かすことではありません。

出力に問題があったとき、原因を切り分けられるようにするためです。

例えば、誤った回答が生成された場合でも、原因は一つとは限りません。

指示が曖昧だった
        ↓
Instructionの問題

前提となる社内ルールが古かった
        ↓
Knowledgeの問題

正しい文書を検索できなかった
        ↓
Retrievalの問題

正しい根拠を渡したが誤読した
        ↓
Generationの問題

この区別がなければ、問題が起きるたびに「プロンプトを直す」「モデルを変える」といった対処に偏ります。

しかし、検索漏れはプロンプトだけでは直らず、古い規程はモデルを変えても新しくなりません。

役割を分けることで、次の設計が可能になります。

情報ごとに責任者と更新頻度を決める
Instruction、検索、生成を別々に評価する
根拠へアクセスできる利用者を制御する
誤りの原因を記録し、改善先を特定する
モデルを交換しても業務上の前提を維持する

QAチャットで考える

社内規程に答えるQAチャットを例にします。

Instruction

質問に関係する規程を根拠として回答する。
根拠の文書名と条項を示す。
根拠を取得できない場合は、回答を推測しない。

Knowledge

社内用語の定義
規程間の優先順位
回答できない情報の分類
人事部門へ移管する条件

Retrieved Evidence

利用者の質問に応じて検索された、現在有効な規程の該当箇所

ここでAIが回答を生成しても、そのまま給与変更や権限変更を実行させる必要はありません。

実行権限や承認は、AIへ与える情報の分類とは別の問題です。影響の大きい操作には、認証、認可、人間の承認、監査ログなどを組み合わせます。

三つを分けても、正しさは保証されない

Instruction、Knowledge、Retrieved Evidenceを整理すると、AIシステムは理解しやすくなります。

しかし、それだけで回答が正しくなるわけではありません。

出力品質には、少なくとも次の要素が影響します。

入力が十分か
Knowledgeが正しく更新されているか
必要な根拠を検索できたか
不要な根拠を混ぜていないか
モデルが根拠を適切に解釈したか
出力を検証できるか
誤った場合に停止または移管できるか

三つの役割を分けることの価値は、正解を保証することではなく、どの条件で出力が作られ、どこを検証すべきかを見えるようにすることです。

まとめ

AIへ渡す情報は、設計上、次の三つの役割に整理できます。

Instruction：何をさせるか
Knowledge：何を継続的な前提とするか
Retrieved Evidence：今回、何を根拠として使うか

RAGは「事実そのもの」ではなく、必要な根拠候補を検索してコンテキストへ渡す仕組みです。

また、三つを分ければAIが必ず正しく動くわけではありません。

それでも分けるのは、指示、知識、検索、生成を個別に管理し、評価し、改善できるようにするためです。

AI設計で重要なのは、情報を一つのプロンプトへ詰め込むことではない。

何を指示し、何を前提とし、今回どの根拠を使ったのかを追跡できるようにすることである。

参考資料

Brown et al., Language Models are Few-Shot Learners
Lewis et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks