7月12日、Elizabeth Fuentes Leoneが「Elizabeth Fuentes on Halting AI Agent Hallucinations: 5 Code-Centric Methods」と題した記事を公開した。AIエージェントのハルシネーション（幻覚）を抑制するための5つのコード実装手法を、コスト削減の観点も交えて解説している。
AIエージェントが嘘をつく問題は、コストと精度の両面でエンジニアを悩ませている。AWSエンジニアであるFuentes Leoneは、プロンプト調整ではなくコード変更で対処する5つの手法を提示している。
問題の本質：なぜプロンプトでは不十分なのか
ハルシネーションにはコスト面の問題が直結している。Fuentes Leoneは次のように述べている。
「AIエージェントが応答するたびに、入力トークンと出力トークンの両方に対して課金される。請求書を見れば、そのトークン数がわかる」
入力や処理に欠陥があると、エージェントはハルシネーションを起こし、不正確な回答を返す。さらにその不正確な情報を元に次の処理が動くため、コストと誤りが雪だるま式に増える。
ここで重要なのが、「プロンプトで対処しようとするアプローチの限界」だ。プロンプトエンジニアリングはモデルの挙動を誘導しようとするに過ぎず、モデルが誤った情報を生成することそのものを構造的に防げない。プロンプトはモデルの確率的な出力に働きかけるため、再現性が低く、モデルのバージョンアップや入力の揺らぎで効果が変わる。一方、コードによる制御はパイプライン自体に検証ロジックを組み込むため、再現性・保守性ともに本番運用に適している。5つの手法はいずれも「ユーザーに届く前に失敗を検知し、トークン消費と誤答を減らす」ことを目的としている。
手法1：セマンティックツール選択（最重要）
5手法の中で最もインパクトが大きいのがセマンティックツール選択だ。
Fuentes Leoneが示したのは、フライト・ホテル・支払い・キャンセルなど29種類のツールを持つ旅行エージェントのケースだ。従来の実装では、ユーザーがどんな質問をしても29ツール全ての定義がコンテキストウィンドウに送られる。各ツールのスキーマは70〜200トークンを消費するため、1回の呼び出しで数千トークンが飛ぶ。
セマンティックツール選択は、クエリとツール定義の意味的類似度を計算し、関連性の高いツールだけを動的に絞り込んでコンテキストに渡す手法だ。実装上は、各ツール定義をあらかじめベクトル化しておき、ユーザークエリの埋め込みベクトルとのコサイン類似度を計算してスコア上位のツールのみをプロンプトに含める、という流れになる。
# セマンティックツール選択の概念的実装例
relevant_tools = select_tools_by_similarity(
query=user_query,
tools=all_tools, # 29ツール全定義
top_k=5 # 上位5件のみを渡す
)
response = llm.invoke(relevant_tools, user_query)
これによりコンテキストウィンドウの使用量を大幅に削減でき、不要なツール定義によるノイズも減るため、ハルシネーションの発生も抑えられる。
手法2：Graph-RAGによるRAG強化
通常のRAG（Retrieval-Augmented Generation）はベクトル検索で文書チャンクを取得し、それをコンテキストとしてモデルに渡す。この方式では、取得された各チャンクは互いに独立しており、エンティティ間の関係情報が失われる。
Graph-RAGはこの課題を、エンティティ間の関係をグラフ構造で保持することで解決する。「AとBは関係があり、BとCも関係がある」という連鎖的な文脈をグラフのエッジとして表現するため、複雑な多段階の質問に対しても、モデルが「関係性を補完するための創作」に頼らずに根拠を提供できる。ハルシネーションの主要因の一つが「コンテキストの断片化による推測の補完」であることを踏まえると、グラフ構造による関係保持はその根本を塞ぐアプローチといえる。
手法3：構造化出力の強制
エージェントの出力をJSONスキーマなどで厳密に定義し、型外れの回答を構造レベルで弾く。「それっぽいが間違っている」自由文の生成を防ぎ、後続処理の信頼性を高める。
# 構造化出力の強制例（Pydanticによるスキーマ定義）
from pydantic import BaseModel
class AgentResponse(BaseModel):
answer: str
confidence: float # 0.0〜1.0
source_ids: list[str] # 根拠ドキュメントID
response = llm.with_structured_output(AgentResponse).invoke(query)
スキーマに合致しない出力はパース段階でエラーとなり、不正な形式の回答がそのまま後続パイプラインに流れ込むことを防げる。
手法4：エージェントの自己検証（Self-Verification）
エージェントが回答を生成した後、別のチェックステップで「この回答は根拠と整合しているか」を検証させる。回答生成と検証を分離することで、単一エージェントが確証バイアスに陥るリスクを低減する。実装上は同一モデルを2回呼び出す構成でも機能するが、検証ステップへの入力を生成ステップと独立させることが重要だ。
手法5：多段検証パイプライン
複数のモデルまたは複数のステップで独立した検証を行い、矛盾が生じた場合にフラグを立てるか、ユーザーへの回答を保留する仕組みだ。手法4の自己検証をさらに強化した構成と位置付けられる。コストはかかるが、高精度が求められる業務用エージェントで特に有効とされる。
エンジニアが押さえるべき視点
Fuentes Leoneの主張の核心は「プロンプトエンジニアリングで対処しようとするな、コードで制御しろ」という点だ。プロンプト調整はモデルの挙動を誘導しようとするが、コード制御はパイプライン自体に検証ロジックを組み込む。再現性と保守性の観点からも、後者の方が本番運用に向いている。
また、トークンコストとハルシネーション率はトレードオフの関係ではなく、適切なツール選択や構造化出力によって両方同時に改善できるという点も重要なメッセージだ。特に手法1のセマンティックツール選択は、コスト削減とハルシネーション抑制を同時に達成できる点で、実装コストに対するリターンが大きい。
詳細はElizabeth Fuentes on Halting AI Agent Hallucinations: 5 Code-Centric Methodsを参照していただきたい。
