LLM のハルシネーション対策 ― 審査で「嘘」を出さないための技術

審査業務で LLM を使う際に避けて通れないハルシネーション問題。検出・抑制・評価の3層アプローチを技術的に解説します。

審査における「ハルシネーション」とは何か

LLM（大規模言語モデル）が事実と異なる情報をもっともらしく生成する現象を「ハルシネーション（幻覚）」と呼びます。これは単なるバグではなく、LLMの確率的な文章生成メカニズムに根ざした構造的な特性です。

審査業務の文脈では、ハルシネーションは主に2つの形態で現れます。

重要なのは、RAG（検索拡張生成）を導入すれば解決する問題ではないという点です。RAGで正しいドキュメントを検索できたとしても、LLMがその内容を誤解釈したり、文脈から切り離して結合したりすることで、「根拠はあるが結論が間違っている」という、より発見しづらいタイプのハルシネーションが発生します。

なぜ審査業務で致命的なのか — 実際の事故シナリオ

「ハルシネーションは稀にしか起きない」と思われがちですが、実データは異なる現実を示しています。2025年の大規模調査では、生成AIユーザーの**75%**が少なくとも一度はハルシネーションに誘導された経験を報告しています。

医療分野：偽の安全性提示

2025年のMicrosoft Copilotの利用状況分析（3,750万件の会話ログ）では、米国で最も頻繁に処方される上位50医薬品の相互作用に関する質問に対して、26%の確率で医学的に不正確なアドバイスが提供されていました。

さらに深刻なのは、LLMが実際には存在しない大量の薬物相互作用を「捏造」する問題です。リウマチ患者の実投薬データを用いた検証では、以下のような結果が出ています。

※ 真の相互作用は204件のみ

Geminiは1,556件もの相互作用を提示しましたが、そのほとんどが架空の相互作用です。これは臨床医に深刻なアラート疲労を引き起こし、本当に危険な相互作用の見落としにつながります。

法務分野：専門AIツールでも残存するハルシネーション

法務分野では、弁護士がChatGPTを利用して作成した準備書面に架空の判例が多数含まれていた事例が広く知られています。しかし、問題は汎用チャットボットに限りません。

スタンフォード大学の2025年の検証によれば、LexisNexisの「Lexis+ AI」やThomson Reutersの「Westlaw AI-Assisted Research」など、業界最高水準の法律AI専門ツールでも17%〜33%の頻度でハルシネーションが発生しています。これらのツールはRAGアーキテクチャを実装し「ハルシネーション・フリー」を謳っていましたが、外部評価ではその主張が裏付けられませんでした。

金融・コンプライアンス分野：AIの約束が法的責任に

Air Canadaのチャットボットは、実際の運送約款には存在しない「忌引割引」を顧客に約束してしまいました。法廷闘争の結果、企業側が敗訴し、AIの出力に対する企業の直接的な法的責任が認められる重要な判例となりました。

金融審査では、該当する情報が存在しない「データ・ボイド」に直面した際、LLMがもっともらしい規定や手続きを捏造するリスクが特に危険です。住宅ローン審査や保険金請求対応でAIがデータを捏造すれば、深刻なコンプライアンス違反につながります。

検出技術 — ハルシネーションを見つける最新手法

ハルシネーション対策の第一歩は、出力に含まれる事実誤認を正確に検出する仕組みの構築です。2025年の研究は、従来のROUGEなどのテキスト一致型指標の根本的欠陥を明らかにし、新しいアプローチへの完全移行を促しています。

なぜ従来の評価指標（ROUGE等）ではダメなのか

ROUGEはテキストの表面的な単語一致率に依存するため、以下の致命的な問題を抱えています。

• 正確でも罰する — 参照テキストと異なる語彙で説明すると、内容が正確でもスコアが下がる
• 不正確でも通す — 参照テキストと表面的に似ていれば、事実誤認があっても高スコアになる
• 長文に弱い — 100トークンを超える詳細な回答は、正確でもハルシネーション閾値を下回る

ROUGE基準で高く評価されていた手法をLLM-as-a-Judge（人間の判断に近い評価手法）で再評価したところ、Perplexityベースの手法は最大45.9%、Eigenscoreは**最大30.4%**もの性能低下が判明しました。

最新の3つの検出フレームワーク

現在の最先端手法に共通するのは、テキストを**「アトミックな事実（最小単位の主張）」に分解し、一つ一つを独立して検証**するアプローチです。

用途別の選び方：

• 社内規定ベースの審査 → FActScore（参照DBを固定してローカル実行）
• 外部情報の裏付けが必要なKYC等 → SAFE（リアルタイム検索＋多段階推論）
• 機密保持が最優先の環境 → FactSelfCheck（外部アクセス一切不要）

抑制アプローチ — ハルシネーションを生まれにくくする技術

検出と並行して、そもそもハルシネーションを発生しにくくするための抑制技術も進化しています。ただし、2025年の実証研究は、どの手法にも「隠れたコスト」があることを示しています。

Chain-of-Thought（CoT）＋ Self-Consistency

CoTは最終回答の前に推論のステップを中間生成させる手法です。数学的推論では精度を40〜50%向上させますが、ハルシネーション削減効果は約15%にとどまるケースが報告されています。

この限界の理由は明確です。CoTはモデルが正確な知識を内部に保持していることが前提です。知識が不正確であれば、推論の連鎖を深めても、「尤もらしい嘘を別の形で再構成する」だけです。

Self-Consistency（複数の推論パスから多数決で結果を選ぶ手法）を組み合わせれば出力の一貫性は高まりますが、根本的な知識の欠如は解消できません。

RAG（Retrieval-Augmented Generation）

RAGはモデルの依存先を外部の最新情報源にシフトさせる手法であり、ハルシネーション抑制の主力技術です。しかし、「グラウンディングされている＝正確」ではありません。

RAGが失敗する典型パターンは以下の3つです。

3つ目の「文脈の誤結合」は特に危険です。個々のソースは正確で、生成された回答もソースに「忠実」に見えるため、汎用的な評価指標では「合格」と判定されてしまいます。

Constrained Decoding（制約付きデコーディング）の隠れたコスト

審査システムではLLMの出力をJSON等の厳密なフォーマットに強制する「Constrained Decoding」が広く用いられています。しかし、11モデルを対象とした実験で、Instruction-tunedモデルではフォーマット制約がかえって推論性能を劣化させることが判明しました。

モデルが学習した「自然言語の好ましいパターン」から強制的に引き離されることで、自信の低い出力が増え、ハルシネーションが増加します。緩和策として、十分なFew-shot例を提供してモデルを構造化出力に「慣れさせる」ことが有効です。

マルチエージェントによる敵対的レビュー

最も効果が高いのが、複数のエージェントに異なる役割を持たせ、内部でピアレビューを行うパターンです。

• Researcher（調査） — RAGで関連規定・判例・証拠を徹底収集
• Writer（判定） — 収集された証拠のみに基づき一次審査の判定ドラフトを作成
• Critic（批評） — 判定結果に対して論理の欠陥・規定との矛盾・証拠の不足を指摘し修正を強制

この敵対的なピアレビューをシステム内部に組み込むことで、単一エージェントと比較してハルシネーションを40〜60%削減できることが実証されています。

評価フレームワークの選び方

開発フェーズと本番運用の両方で、審査システムの品質を継続的に監視するための評価フレームワーク選定が重要です。

審査業務での選定指針

判定結果の監査証跡が法的要件となる審査業務では、評価結果がプロンプトの揺らぎで変動しないことが重要です。

• 再現性重視 → DeepEvalのDAGスコアリング（プロンプト揺らぎに依存しない決定論的評価）
• 検索精度のボトルネック可視化 → PhoenixのUMAP可視化（どのベクトル空間の偏りで重要な規定を取りこぼしているかを特定）
• 低コストでRAG品質を測る → Ragas（OSSで無償、CI/CDパイプラインに組み込み可能）

実運用では、DeepEvalでCI/CDパイプラインの品質ゲートを構築し、Phoenixで検索精度の劣化を日次モニタリングする併用パターンが効果的です。

実践的な多層防御設計 — Claim-Evidence アーキテクチャ

ここまでの検出・抑制・評価を統合し、審査業務で実際に機能する多層防御アーキテクチャの設計パターンを示します。

設計原則：LLMに「意思決定」させない

審査業務におけるLLMの真の価値は、自律的な意思決定者ではなく、**膨大な文書から論理的根拠を抽出し、人間の判断を支援する「検証可能な推論エンジン」**として機能させる点にあります。

出力のすべてを**「主張（Claim）」と「証拠（Evidence）」の構造に分解し、原典ソースに直接リンクさせる**設計が核心です。2026年に発表されたPaperTrailアーキテクチャは、この考え方を学術Q&Aシステムで実現し、すべての審査判定文に「どの文書の、どのページの、どの段落」が根拠かをメタデータとして保持する仕組みを提供しています。

各レイヤーの役割

レイヤー1：Router（インテリジェントな振り分け）

すべてのクエリを高価な推論モデルで処理するのは非効率です。セマンティック・ルーティングにより、単純なFAQ的規定照会は軽量モデル（応答50ms）へ、複雑な監査推論はマルチエージェント・ワークフローへ振り分けます。

レイヤー2：マルチエージェント審査（Researcher-Writer-Critic）

Researcher→Writer→Criticの敵対的レビューループで、一次判定のハルシネーションを40〜60%削減します。Criticは「悪魔の代弁者」として機能し、論理の飛躍・証拠の不足・規定との矛盾を厳しく指摘します。

レイヤー3：Guardrails（入出力の最終防壁）

NVIDIA NeMo Guardrailsの状態遷移制御（Colang）とGuardrails AIのプログラム検証を組み合わせ、以下を実現します。

この検証・修正ループの組み込みにより、生のLLM出力をそのまま使う場合と比較して最大20倍の精度向上が報告されています。

規制対応：EU AI法とISO 42001

この多層防御設計は、技術的ベストプラクティスであると同時に、2026年8月に本格施行されるEU AI法とISO/IEC 42001への準拠要件を満たすための基盤です。

まとめ：「AIに賢く答えさせる」から「推論を透明にする」へ

ハルシネーションはLLMの「バグ」ではなく、確率的な文章生成に内在する構造的特性です。完全にゼロにすることはできません。審査業務でLLMを活用するためのパラダイムは、「AIにいかに賢く答えさせるか」から、**「AIの推論プロセスをいかに透明化し、人間による検証を容易にするか」**へ転換しています。

導入を検討される際は、以下のステップで進めることをおすすめします。

1. 現状把握 — 既存の審査プロセスでLLMの事実誤認が発生している箇所を特定する
2. 検出から着手 — FActScoreやSAFEで出力の事実性を定量評価する仕組みを構築する
3. Claim-Evidence設計 — すべての審査判定に根拠ソースの紐づけを義務付ける
4. Guardrails実装 — 入出力の検証ループを推論パイプラインに組み込む
5. 継続監視 — 評価フレームワークでRAGメトリクスを日次モニタリングする

「ハルシネーションをゼロにする」ことを目指すのではなく、「ハルシネーションが起きても人間が即座に検証できる」アーキテクチャを構築することが、審査業務におけるAI活用の唯一の現実的なアプローチです。

Naosyでは、審査業務におけるハルシネーション対策の設計から、Claim-Evidenceアーキテクチャの構築、ガードレールの実装まで一貫して支援しています。まずは現状の審査フローの課題をお聞かせください。

この記事の著者

Naosy 編集部

レビュー・校正・審査プロセスの最適化に関する実践的なナレッジを発信しています。