AIのハルシネーションを減らすには、「推測しないで」と一文加えるだけでなく、誤りの型を分類し、必要な根拠をRAGやToolで取得し、引用・schema・回答拒否を検証し、評価データで測る必要があります。
この記事では、知識不足、検索失敗、推論飛躍、形式違反、架空引用、古い情報を分け、対策と指標を対応付ける方法を解説します。
情報確認日：2026年7月18日（日本時間）
結論：症状ごとに取得・検証・拒否・評価を組み合わせる
- 誤回答を症状と原因へ分類する
- 固定資料はRAG、最新値はToolで取得する
- 回答文と根拠をclaim単位で対応付ける
- 根拠不足・矛盾・高リスク時は答えない
- 答えなしを含むdatasetで改善前後を測る
NISTのGenerative AI Profileでは、もっともらしい誤りや架空の論理・引用を含む現象をconfabulationとしてリスク管理の対象にしています。日本語では一般にハルシネーションと呼ばれます。
ハルシネーションの症状を分類する
| 症状 | 例 | 主な確認先 |
|---|---|---|
| 知識不足 | 社内規程を知らず推測 | 情報源の有無 |
| 検索失敗 | 正解文書を取得できない | retrieval結果 |
| 推論飛躍 | 根拠から言えない結論 | claimとevidence |
| 形式違反 | 未定義labelや壊れたJSON | schema validator |
| 架空引用 | 存在しないURL・文言 | source metadata |
| 古い情報 | 旧価格・旧statusを回答 | 取得日時と正本 |
すべてを「modelが悪い」でまとめると改善できません。質問、取得結果、Tool結果、最終回答、引用を同じtraceへ残します。
原因別の対策マトリクス
| 原因 | 第一対策 | 追加対策 | 指標 |
|---|---|---|---|
| 資料不足 | 正本を追加 | 回答拒否 | answerable coverage |
| 検索失敗 | chunk・hybrid検索 | rerank | Recall@k |
| 最新値 | Toolで取得 | 取得時刻表示 | tool success |
| 推論飛躍 | claim-evidence対応 | verifier | groundedness |
| 形式違反 | schema検証 | 限定retry | schema pass rate |
| 根拠なし | abstention | 人間確認 | false answer rate |
根拠を外部から取得する
RAGで固定・社内資料を検索する
規程、manual、FAQなど管理された文書はRAGで関連chunkを取得します。正本、更新日、owner、access scopeをmetadataへ付けます。
RAGを入れても、誤ったchunkを取得すれば回答は誤ります。検索結果に正解が入ったかを回答生成とは別に評価します。仕組みはRAGとはを参照してください。
Toolで最新値と確定データを取得する
在庫、残高、status、時刻、計算結果などは、modelの記憶ではなく権限管理されたAPIやDB Toolから取得します。
- Tool名と用途を具体化する
- 引数をschemaで検証する
- timeout・error時に推測へ切り替えない
- 取得日時とsource IDを回答へ渡す
- 書き込みToolは人間承認を入れる
回答と根拠を対応付ける
{
"answer": "申請期限は3営業日前です。",
"claims": [
{
"text": "申請期限は3営業日前",
"source_id": "leave-policy-v4",
"source_section": "申請期限",
"source_updated_at": "2026-07-01"
}
],
"status": "grounded"
}citation URLをmodelに自由生成させず、検索結果やTool resultのmetadataから組み立てます。リンク先が存在し、claimを直接支えるかを検証します。
structured outputで必須項目を検証する
schemaは形式を安定させますが、内容の真偽は保証しません。source_idが取得結果に実在するか、quoteが原文にあるかをapplication側で照合します。
答えない条件と人間確認を設計する
回答を停止する条件
- 正解資料が検索上位にない
- 複数の正本が矛盾している
- sourceの更新期限を過ぎている
- Toolがtimeout・error
- 必須fieldがschemaにない
- 医療・法律・金融・安全の重要判断
返す内容
- 確認できなかったこと
- 使用したsource
- 次に必要な情報
- 人間へ確認する方法拒否を増やせば誤答は減りますが、答えられる質問まで拒否すると使えません。誤答率と不必要な拒否率を両方測ります。
答えなしを含む評価dataset
id,question,answerable,expected_source,expected_behavior,risk
Q01,申請期限は？,yes,leave-policy-v4,3営業日前と引用,medium
Q02,海外補助金は？,no,,資料にないと拒否,low
Q03,現在の在庫は？,tool,inventory-api,Tool成功時だけ回答,high
Q04,旧規程と新規程が矛盾,conflict,policy-v3|v4,人間確認,high| 指標 | 測るもの |
|---|---|
| 誤答率 | 誤った内容を回答した割合 |
| 不必要な拒否率 | 答えられるのに拒否した割合 |
| Citation precision | 引用がclaimを支える割合 |
| Retrieval Recall@k | 正解sourceが上位k件に入る割合 |
| Schema pass rate | 形式検証を通る割合 |
model、prompt、index、chunk、Tool、schemaを変更するたびに同じdatasetを実行します。評価の設計はLLM評価の基礎を参照してください。
改善前後の失敗率表
version,cases,wrong_answer,unnecessary_refusal,bad_citation,tool_error
baseline,100,18,4,12,6
rag-v2,100,10,6,5,6
rag-tool-abstain,100,5,9,2,2数値は設計例です。改善によって誤答が減っても拒否が増えている点を見ます。riskが高い質問には厳しいthresholdを設定します。
よくある質問
promptだけでハルシネーションを防げますか？
完全には防げません。promptは補助であり、外部根拠、Tool、検証、拒否、評価を組み合わせます。
RAGを使えば正確になりますか？
検索が正しければ助けになりますが、資料品質、chunk、検索、回答の失敗が残ります。取得と生成を分けて評価してください。
Toolを使う利点は何ですか？
在庫やstatusなど確定データを実行時に取得できます。ただしTool errorや権限問題があるため、失敗時に推測しない設計が必要です。基礎はTool Callingとはを参照してください。
まとめ
ハルシネーション対策は、症状を分類し、固定資料はRAG、最新値はTool、出力はclaimとcitation、根拠不足は拒否という形で役割を分けます。
答えあり・答えなし・矛盾・Tool失敗を含むdatasetを作り、誤答率と不必要な拒否率を継続測定してください。完全防止ではなく、影響と頻度を測って安全側へ改善する取り組みです。
