LLM のハルシネーション(幻覚)— 原因と実務での対策

2026年8月13日木曜日

読了 6分

LLM を業務に組み込むときに最初にぶつかる壁がハルシネーション(hallucination、幻覚)です。存在しない論文を引用し、存在しない API を自信満々に呼び出すコードを書いてきます。結論を先に書くと、ハルシネーションはバグではなく LLM の動作原理から生まれる構造的な副産物であり、完全になくすことはできませんが、実務レベルでは十分に減らして管理できます。この記事では、なぜ起きるのかから、何で減らすのかまでを整理します。

なぜ起きるのか — 検索エンジンではなく生成器です #

LLM はデータベースから事実を照会するシステムではありません。学習データの統計的パターンを圧縮して保持し、「ここまでのテキストの次に来る確率が高いトークン」を 1 つずつ生成するシステムです。この構造から 3 つの帰結が導かれます。

知識は非可逆圧縮で保存されています。 頻繁に登場した事実はよく再現されますが、まれにしか登場しなかった事実は似たパターンと混ざって保存されます。ぼんやりとしか記憶されていない部分を聞かれると、モデルは最ももっともらしいパターンで空白を埋めます。その結果がハルシネーションです。
流暢さと正確さは別物です。 モデルは「自然な文章」を作るように学習されているため、内容が間違っていても文体は自信に満ちています。人間が嘘をつくときのようなためらいのシグナルがない分、より危険です。
学習カットオフ以降のことは知りません。 学習データの収集時点より後の事実を聞くと、モデルは知らないと答えるか、古い情報をもとにもっともらしく答えます。最近のモデルは「知らない」と答える訓練が強化されていますが、その境界は今も完璧ではありません。

よく遭遇する類型 #

事実誤り: 日付、数値、人物の関係など、検証可能な事実が間違っているケースです。特に数字と固有名詞の組み合わせで頻発します。
出典の捏造: 存在しない論文タイトル、判例番号、URL、書籍の引用を作り出します。体裁が完璧なので、かえって騙されやすいです。実際に、裁判所へ提出する書面に偽の判例を引用して問題になった事例が、複数の国で繰り返し起きています。
コード API の幻覚: 存在しない関数、古いバージョンで削除されたメソッド、別のライブラリのシグネチャを混ぜて書きます。コードは実行すればすぐ露見するため、検証ループを組み込みやすい領域でもあります。
文脈の歪曲: 提供した文書に書かれていない内容を、書かれていると答えるケースです。RAG を付ければ終わりではない理由で、検索された根拠と回答の整合性は別途確認する必要があります。

減らす方法 — 実務で検証済みの手段 #

ハルシネーション対策は 1 つの銀の弾丸ではなく、複数の層の組み合わせです。

根拠を注入します(RAG)。 モデルの記憶に頼らず、質問に関連する文書を検索してコンテキストとして与え、「この根拠の中で答えること」と指示します。社内知識、最新情報、まれな事実についての幻覚を減らす、最も効果の大きい手段です。基盤技術は埋め込みとベクトル検索で、失敗ポイントの診断は RAG 深掘り #1 で扱いました。
引用を強制します。 回答の各主張に、根拠文書のどの部分を参照したかを示させると、根拠のない主張が入り込む余地が減り、ユーザーが検証する経路も生まれます。具体的な実装は RAG 深掘り #5 引用でハルシネーションを減らすにまとめています。ベンダーが API レベルで引用機能を提供している場合もあります。
「知らない」と答える道を用意します。 「確信がなければ知らないと答えること」「根拠文書になければ、ないと答えること」という明示的な指示は、単純ですが実測できる効果があります。逆に「必ず答えを出すこと」という指示はハルシネーションを誘発します。
計算と照会はツールに任せます。 算術、日付計算、最新情報の取得、DB の照会は、モデルに記憶で答えさせず、コード実行や検索、関数呼び出しのツールで処理させます。モデルの役割を「事実の生成」から「ツール結果の整理」に変えるということです。ツール連携の標準は MCP 整理で扱いました。
出力を機械的に検証します。 構造化出力でスキーマを強制し、生成された URL は実際のアクセスで、コードはコンパイルとテストで、引用された判例や論文は原本の照会で後処理検証します。検証可能な形に出力を設計すること自体がハルシネーション対策です。
評価パイプラインで劣化を防ぎます。 代表的な質問セットと正解基準を用意しておき、プロンプトやモデルを変えるたびにハルシネーション率を測定します。作るのは面倒ですが、これがないと「改善」が本当に改善なのか分かりません。構築方法は RAG 深掘り #6 評価パイプラインで扱いました。

なくせない前提で設計します #

上記の手段をすべて適用しても、ハルシネーション率はゼロにはなりません。確率的生成という本質が変わらないからです。だから最後の層は技術ではなく運用設計です。

エラーのコストに応じて人間のレビューを配置します。 社内文書のドラフトのようにエラーのコストが低いところは自動化し、法律相談、医療案内、対外的な告知のようにエラーのコストが高いところは、人間の承認なしに出力が出ていかない仕組みにします。
ユーザーに限界を明示します。 AI が生成した回答であることを明記し、根拠リンクを併せて提供すれば、ユーザーが最終検証者の役割を果たせます。
ハルシネーションの事例を収集します。 運用中に見つかった幻覚を評価セットに追加し続ければ、対策は累積的に良くなっていきます。

まとめ #

ハルシネーションは、次トークンの確率予測という LLM の動作原理から生まれる構造的な現象です。バグではないので、パッチでは消えません。
危険なのは、間違った内容が自信に満ちた文体で出てくるからです。出典の捏造とコード API の幻覚が実務では特に頻発します。
対策は層で積み上げます。RAG で根拠を注入し、引用を強制し、「知らない」と答える道を用意し、計算と照会はツールに任せ、出力を機械的に検証し、評価パイプラインで劣化を監視します。
それでもゼロにはなりません。エラーのコストが高い経路に人間のレビューを設計として組み込むのが、最後の防衛線です。