LLMエージェントの「思い込み判断」をプロンプト設計で防ぐ
LLMエージェントを実際のワークフローに組み込んでいると、ある段階で必ず直面する問題があります。「なぜそう判断したのか根拠が分からないまま処理が進んだ」「提供したはずのデータを無視して独自の結論を返してきた」——こうした”思い込み判断”は、エージェントの信頼性を大きく損ないます。本記事では、プロンプトエンジニアリングの観点から、この問題を実装レベルで軽減する手法を順序立てて解説します。
LLMエージェントが起こしやすい「思い込み判断」3パターン
問題に対処する前に、どのような”思い込み”が起きているのかを整理しておきます。代表的なパターンは以下の3つです。
1. 知識のハルシネーション 学習データに存在しない、あるいは曖昧な情報を、確実な事実であるかのように生成するケースです。APIのバージョン番号、ライブラリのメソッド名、社内固有のドメイン知識などで特に起きやすい傾向があります。
2. コンテキスト無視 ツール呼び出しの結果やシステムプロンプトで明示した制約を、後続のステップで適用しないまま処理を続けてしまうパターンです。コンテキストが長くなるほど発生しやすくなります。
3. 過信による早期収束 複数の可能性があるにもかかわらず、最初に生成した仮説を検証せずに確定答えとして扱ってしまう問題です。思考プロセスの途中で「これで合っている」と自己確認してしまうことが原因の一つと考えられます。
これら3つは複合的に絡み合うことも多いため、対策も多層的に設計する必要があります。
不確実性を言語化させる：確信度と根拠の構造出力
コストパフォーマンスの高いアプローチは、LLM自身に不確実性を言語化させることです。
プロンプトに以下のような構造出力の指示を加えるだけで、モデルは確信度と根拠を分けて報告するようになります。
あなたは以下の質問に答える前に、必ず次の形式で出力してください。
### 確信度
0〜100の整数で表してください。
- 80以上: 根拠のある事実に基づいている
- 50〜79: 推測を含む可能性がある
- 49以下: 不確かな情報を含む
### 根拠
判断の根拠となった情報源または推論の過程を箇条書きで示してください。
### 回答
上記を踏まえた回答を記述してください。このアプローチのポイントは「数値を出させること」ではなく、出力前に根拠を列挙させることにあります。思考プロセスを先に言語化させると、モデルが持っていない情報を「持っているふり」をしにくくなる傾向があります。
確信度はダウンストリームの処理にも活用できます。確信度が50未満の場合はツール呼び出しにフォールバックするロジックをオーケストレーター側に実装しておけば、ハルシネーション対策として二重のセーフティネットになります。
外部情報との照合ステップを組み込む
知識のハルシネーションとコンテキスト無視に同時に対処するには、「生成した内容を、取得済みの情報と照合するステップ」を明示的にプロンプトへ組み込む方法が有効です。
RAGを使っている構成であれば、リトリーバルの結果をエージェントに「引用」として扱わせるよう指示します。
【ルール】
- 以下の「参照情報」に記載されていない事実を、あなた自身の知識で補完しないでください。
- もし参照情報だけでは回答できない場合は、「参照情報に記載なし」と明示した上で、
推測である旨を必ず断ってから回答してください。
【参照情報】
{retrieved_context}
【質問】
{user_query}重要なのは「補完しないでください」という否定形の指示と、「記載なし」という代替出力を明示的に用意することです。モデルは「答えなければならない」という暗黙の圧力に引きずられやすい傾向があるため、「わからなくてよい」という出口を作ることで無理な生成を抑制できます。
複数ステップのエージェントであれば、各ツール呼び出しの後に「取得した結果を要約し、次のステップに必要な情報が揃っているかチェックする」という中間ステップを挟む設計も効果的です。
実践テンプレート：チェックリストで思考プロセスを強制する
ここまでの考え方を組み合わせた、より実践的なテンプレートを示します。コードレビューを補助するエージェントを想定した例です。
あなたはコードレビューを支援するエージェントです。
以下の「チェックリスト」に従い、段階的にレビューを進めてください。
## チェックリスト（必ずすべての項目を明示的に確認すること）
[ ] ステップ1: 変更差分を読み、変更の意図を自分の言葉で要約する
[ ] ステップ2: セキュリティ上の懸念点を列挙する。懸念がない場合は「懸念なし」と明記する
[ ] ステップ3: 各指摘について、コード内の該当箇所（行番号）を引用して根拠を示す
[ ] ステップ4: 自信のない指摘には ⚠️ を付け、「要確認」と記載する
## 重要な制約
- コード差分に存在しない行を引用しないでください
- 一般的なベストプラクティスを指摘する場合は、コード内に具体的な問題箇所がある場合のみにしてください
## コード差分
{diff}設計上の工夫は3点あります。チェックリスト形式で思考プロセスを強制すること、「懸念なし」という答えを許容すること、自信のない部分を自己申告させることです。これらを組み合わせることで、エージェントの出力が検証しやすい形に近づきます。
落とし穴：チェック強化によるレイテンシ増加への対処
ここまで紹介した手法には副作用があります。チェックステップを増やすほど、トークン消費とレイテンシが増加します。マルチターンのエージェントループでは、各ステップに検証プロセスを挟むと全体のレスポンスタイムが大幅に延びることもあります。
対処の方針は「リスクに応じてチェックの粒度を変える」ことです。
- 高リスク操作（データベース更新、外部API呼び出し、金額に関わる判断など）：確信度チェックと根拠列挙を必須にする
- 低リスク操作（テキスト要約、フォーマット変換など）：チェックを省略し、高速な出力を優先する
実装上は、システムプロンプトの冒頭にリスクレベルを宣言し、それに応じた出力フォーマットを切り替えるアプローチが現実的です。
def build_system_prompt(risk_level: str) -> str:
base = "あなたは〇〇タスクを処理するエージェントです。"
if risk_level == "high":
base += """
回答前に必ず以下を出力してください:
- 確信度 (0-100)
- 判断根拠（箇条書き）
- 不確かな点のリスト
"""
return baseまた、LLMの呼び出しを並列化できる部分はできるだけ並列化し、チェックと本処理を直列に並べる必要がない箇所を整理するだけでも、体感レイテンシを改善できる場合があります。
本番運用での検出：モニタリング設計
プロンプト設計がどれだけ優れていても、本番環境では想定外の入力が必ず来ます。思い込み判断の発生をモニタリングする仕組みを併せて構築することが重要です。
まず、エージェントの出力ログに「確信度」と「根拠」が構造化された形で含まれるようにしておきます。前述のテンプレートを使っていれば、これは自然に実現されます。そのうえで以下の指標をトラッキングします。
- 確信度の分布：低確信度出力の割合が急増していないか
- 「参照情報に記載なし」の発生頻度：RAGのリトリーバルが機能していない可能性のシグナル
- ユーザーフィードバックとの相関：低確信度の回答がユーザーからの修正リクエストに繋がっているか
あわせて、正解付きのテストケース（ゴールデンセット）を定期的にエージェントに流して回答の一貫性を確認するオフライン評価も有効です。プロンプト変更時の品質劣化を早期に検知するリグレッションテストとして機能します。
思い込み判断の完全な排除は現時点では難しいですが、発生を検知できる状態を作ることが、エージェントを本番で安全に運用するための現実的なゴールです。プロンプト設計とモニタリングの両輪を整えることで、信頼性のある運用基盤が少しずつ固まっていきます。