AIエージェントのハルシネーション対策｜5つの設計

社内規程を検索するAIエージェントが、存在しない条文をもっともらしく答えた。チャットだけなら、そこで誤りに気づけるかもしれない。ところが、その回答を根拠に申請を作り、承認者へ送り、長期メモリへ保存したらどうなるだろう。

厄介なのは、最初の誤回答より、その後の連鎖だ。

生成AIの誤りはゼロにできない。産業技術総合研究所の生成AI品質マネジメントガイドラインは、確率的な生成の仕組みを説明したうえで、完全になくすのは実際上も原理上も不可能と述べる（p.93）。

ならば設計目標を変える。誤りを一度も出さないことではない。根拠のない回答を検知し、実行や記憶へ進ませず、安全に人へ戻すことだ。

AIエージェントのハルシネーションは「行動」で重くなる

NISTは誤った内容を自信ありげに示す現象を「confabulation」と呼ぶ。Generative AI Profileでは、誤った引用や説明まで生成され、人が不適切に信頼する危険にも触れている。

普通のチャットでは、誤りは画面上の文章にとどまる。一方、AIエージェントは検索、計算、更新、送信を組み合わせる。誤った前提がツール呼び出しへ渡ると、被害の形が変わる。

• 存在しない顧客情報をCRMへ登録する
• 誤った在庫数を使って発注案を作る
• 架空の社内ルールをメモリへ保存する
• 誤った判断を別のエージェントへ引き渡す

伝播経路は「根拠のない主張→ツール引数→業務データ→長期メモリ→下流エージェント」と表せる。後ろへ進むほど、修正対象と影響範囲が増える。

ここで「モデルを高性能に替える」だけでは足りない。参照資料、ツール、メモリ、承認を一つのシステムとして扱う。

AIエージェントのハルシネーション対策は、プロンプトの工夫ではなく境界設計である。押さえる場所は5つだ。

ハルシネーションを抑える5つの設計

回答精度だけを追うのではなく、根拠・版・権限・記憶・停止の5点を一緒に設計する。誤りをゼロにできない前提で、業務影響を広げない構造を作る。

設計1：回答ではなく「主張と根拠」を出力させる

最初の設計は、回答の形式を変えることだ。

「質問に答える」だけでは、検証する単位が曖昧になる。そこで、出力を少なくとも次の3要素に分ける。

• 主張：何を事実として述べるか
• 根拠：どの資料のどの箇所を使ったか
• 判定：根拠は十分か、不足しているか

たとえば就業規則への質問なら、「有給申請は3日前まで」と答えるだけでは不十分だ。文書名、版、該当節、更新日を一緒に返す。根拠が見つからなければ「確認できない」を正常な結果として扱う。

この「答えない」動作が意外に難しい。役に立とうとするモデルは、情報が足りなくても文章を完成させようとするからだ。仕様には、回答条件だけでなく拒否条件を書く。

たとえば「有効な一次資料が1件もない」「資料同士が矛盾する」「更新日を確認できない」なら、人へ確認を返す。曖昧なときほど流暢に答えさせない。

NISTが進めるagentic AIの評価プローブは、主張を信頼できる資料と照合し、faithfulness、completeness、sufficiencyを検査する。単に引用が付いているかではなく、その引用が本当に主張を支えるかを見る考え方だ。

設計2：参照資料に版・所有者・有効期限を持たせる

RAGを入れれば安心、とは限らない。古い資料や矛盾した資料を検索すれば、根拠付きの誤回答ができあがる。

実務では、文書本文よりメタデータが効く。最低限、次を持たせたい。

• 文書の所有部署
• 施行日と失効日
• 現行版か廃止版か
• 公開範囲と機密区分
• 正式版を示す参照先

検索時には、内容の近さだけで選ばない。有効期間と閲覧権限で絞り、正式版を優先する。複数の文書が食い違うなら、勝手に一つへ決めず矛盾を返す。

考えてみてほしい。2024年版の経費規程が文章として最も近くても、2026年版が正式なら前者を使ってはいけない。検索精度の問題に見えるが、実際は文書管理の問題である。

参照資料の整備は地味だ。だが、ここを飛ばしてプロンプトを調整しても限界が来る。入力と根拠の設計は、AIエージェントの入力設計でも詳しく整理している。

設計3：生成と実行の間に権限ゲートを置く

文章が少し間違うことと、外部システムを更新することは、同じリスクではない。だから生成と実行を直結させない。

ツールごとに操作を3段階へ分けると扱いやすい。

1. 読み取り：検索、一覧、参照
2. 下書き：更新案、メール案、申請案の作成
3. 確定：送信、登録、削除、支払い

読み取りは自動でもよい。下書きは根拠を添えて人へ見せる。確定操作は、金額、対象人数、外部送信、不可逆性などで承認条件を変える。

ツールの引数も自由文にしない。顧客ID、金額、実行日、根拠IDを構造化し、必須項目と許容範囲を検証する。高リスク操作だけを承認へ回し、低リスク操作は監査ログ付きで進める。

AWSのAgentic AI Lensも、根拠性の閾値を用途のリスクに合わせる考え方を示している。創作業務と、契約や支払いを同じ基準で扱わないということだ。

設計4：長期メモリへ書く前に再検証する

一度の誤回答は、その会話で終わるかもしれない。長期メモリへ入ると、次回以降の前提になる。別のエージェントが読み、さらに別の判断へ使うこともある。

だから、会話の出力とメモリへの保存を分ける。

保存候補には、出典、作成時刻、作成者、検証結果、有効期限を付ける。検証結果はモデルの自己申告ではない。根拠との整合性検査、業務ルール、別の評価器から算出する。そして次の条件を一つでも満たさなければ、確定領域へ入れず隔離する。

• 一次資料へ追跡できない
• 既存メモリと矛盾する
• 個人の推測と確定事実が混ざっている
• 保存期限や所有者がない
• 高リスクな判断を含む

削除より「無効化」を使う方法もある。誤りがいつ入り、何へ参照されたかを追えるからだ。AWSもメモリ書き込み前のグラウンディング検査と、影響した情報の再検証を勧めている。

メモリは便利なノートではない。次の判断を変えるデータベースだ。AIエージェントのメモリ設計と同じく、保存条件と失効条件を先に決めたい。

設計5：評価、監視、停止を一つにつなぐ

最後は運用だ。リリース前のテストだけでは、資料更新や利用者の変化を拾えない。

テストデータは、正解例だけでなく失敗例を入れる。

• 根拠が見つからない質問
• 古い版と新しい版が競合する質問
• 数値だけが資料と違う回答
• 存在しない引用を含む回答
• ツール実行後に失敗するケース
• メモリの誤情報を再利用するケース

評価指標も「正答率」一つにまとめない。主張が根拠に支えられた割合、必要な引用の充足、拒否すべき質問を拒否できた割合、誤ったツール実行の件数を分ける。

OpenAIのAgent evalsのような評価基盤を使う場合も、業務固有の合格条件が先に要る。評価ツールは、何を事故とみなすかまでは決めてくれない。

本番では、根拠不足率や承認差し戻し率が閾値を超えたら止める。参照資料の更新直後やモデル変更後も再評価する。異常を検知しても動き続けるなら、監視は飾りになってしまう。

停止後の戻り先も決めておく。担当者へ渡すのか、下書きだけ残すのか、直前の処理を取り消すのか。AIエージェントの停止条件は、平常時ではなく止まった後まで含めて設計する。

要件定義書へ写す4つの欄

5つの設計は、説明文のままでは受入判定に使いにくい。「要求事項・判定条件・証跡・異常時の遷移」の4欄へ変換する。

この表を2週間の検証に使う。1業務、1種類の資料、1つの下書き操作に絞り、古い文書、矛盾する文書、空の検索結果を流す。見るのは流暢さではない。根拠を追え、危険な操作を止め、人へ戻した後も仕事を続けられるかだ。

ハルシネーション対策を要件へ落とす

プロンプトに「嘘をつかないで」と足すだけでは、業務の安全条件にならない。必要なのは、根拠の形式、参照資料の鮮度、実行権限、メモリ保存、評価と停止を別々の要件へ落とすことだ。

AIエージェントは間違える。その前提を受け入れると、設計はむしろ明確になる。どこで検知し、どこで止め、誰へ戻すかを決めればよい。

自社業務で事故の形を洗い出し、AIエージェントの仕様へ変えたい場合は、Atsumellへ相談してほしい。業務フローの整理から評価条件、権限、実行基盤まで一緒に設計する。

関連記事

• AIエージェントのオーケストレーション｜5つの制御
• AI要件定義は禁止条件から決める
• AIエージェントの評価設計