ハルシネーションはなぜ起きるか。減らせる場面と諦めるべき場面

結論:ハルシネーションは「確率的に最もらしい文字列を生成する」仕組みから必然的に発生する
AIが嘘をつく——と言われるハルシネーション(幻覚)は、バグでも悪意でもありません。LLMの動作原理から来る構造的な問題です。
LLM(大規模言語モデル)は「次にくる単語として統計的に最も自然なものを選ぶ」という処理を繰り返してテキストを生成します。「事実を調べて答える」のではなく「それらしい文章を作る」のが本質です。だから、知らないことを聞かれても「知らない」と答えず、それっぽい答えを生成してしまうことがあります。
重要なのは「ハルシネーションが起きやすい場面」と「ほぼ起きない場面」を区別して使うことです。すべての場面で疑うより、リスクの高い場面を把握して対策を絞るのが実用的です。



ハルシネーションが起きる仕組み:3つの根本原因
原因1:「知らない」と言えない設計
人間なら「それは知りません」と答えられますが、LLMは基本的にどんな質問にも何らかの回答を生成しようとします。これは訓練の過程で「答えを出す」ことが正解とされてきたためです。
特に以下の場面でハルシネーションが起きやすいです。
- モデルの学習データのカットオフ以降の情報(例:「2025年12月以降の出来事」をChatGPTに聞く)
- ニッチすぎる情報(学術論文の詳細な数値、マイナーな人物の経歴、地方企業の詳細など)
- 存在しないものを存在するかのように聞く質問(「〜という論文の内容は?」と架空の論文を聞く)
原因2:文脈の引力に引っ張られる
LLMは文脈の流れに乗ってテキストを生成します。「〜について教えてください」と聞かれると、そのトピックに関連した語彙や文体で回答しようとします。この「文脈への引力」が、正確な情報よりもそれらしい情報を優先させることがあります。
典型例:「鎌倉時代の有名な武将を10人挙げて」と頼むと、後半になるにつれ実在しない人物名が混入することがある。10人という数を埋めることへの圧力が、事実確認を上回るためです。
原因3:温度パラメータによる創造性と正確性のトレードオフ
LLMには「温度(temperature)」というパラメータがあり、高いほど創造的・多様な回答を、低いほど安全で保守的な回答を出す設定です。ユーザー向けのインターフェースでは多くの場合この設定が隠されていますが、創造的な文章生成では高めに設定されており、それがハルシネーションを引き起こしやすくします。

ハルシネーションを「減らせる場面」
RAGで外部情報を与える
ハルシネーションの最も強力な対策は、AIが参照できる情報源を与えることです。RAG(Retrieval-Augmented Generation)という手法で、データベースや文書から関連情報を検索してプロンプトに含めることで、AIは「与えられた情報の範囲で答える」ようになります。
個人レベルで今すぐできる同様の方法:
- ソースを貼り付けて要約させる:「以下の文章を要約してください:(本文)」——モデルが「創作」ではなく「要約」タスクになるのでハルシネーションが激減する
- Web検索連携AIを使う:Perplexity・ChatGPT(Web検索オン)・Geminiは検索結果を参照して回答するため、最新情報・事実確認が必要な場面でのハルシネーションを大幅に減らせる
- NotebookLMに資料を読ませる:アップロードした文書の範囲内でしか答えないため、業務文書の質問応答に向いている
プロンプトで「わからない場合は言って」と指定する
シンプルですが効果があります。プロンプトに以下を加えるだけで、不確かな回答を減らせます。
- 「確信が持てない場合は『わかりません』と答えてください」
- 「事実として断言できないことは、その旨を明示してください」
- 「情報源が不明な場合は推測であることを示してください」
完全には防げませんが、モデルが「不確実性を明示する」方向に誘導されます。特にClaudeはこの指示への応答性が高いとされています。
推論モデルを使う
o3(OpenAI)・Claude Sonnet 4.6(extended thinking)などの推論モデルは、回答を出す前に「考えるステップ」を踏みます。この「思考プロセス」がある分、単純なLLMより事実確認のフィルタリングが行われやすく、ハルシネーション率が低い傾向があります。数学・論理・コーディングなどの検証可能なタスクでは特に効果的です。



ハルシネーションを「諦めるべき場面」
完全に防ぐことは現状不可能
2026年時点でも、ハルシネーションをゼロにする方法は存在しません。以下の場面では、対策しても一定の確率でハルシネーションが起きると考えて使う必要があります。
- 具体的な数値・日付・固有名詞の正確性:「〇〇の株価は?」「〇〇が設立されたのはいつ?」——必ず一次ソースで確認
- 法律・医療・税務の具体的な判断:それらしい回答が出ても、専門家への確認なしに使うのは危険
- 引用・参考文献:LLMが出す論文タイトルや著者名は架空のことがある。DOIやURLで必ず確認
- マイナーな人物・組織の詳細:情報が少ない対象ほど「それっぽい情報の創作」が起きやすい
ハルシネーションと「うまく付き合う」考え方
ハルシネーションを「AIには使えない理由」ではなく「使い方を選ぶべき特性」として扱うのが実用的です。
| タスクの種類 | ハルシネーションリスク | 対処法 |
|---|---|---|
| 文章の要約・整形 | 低(与えた情報の範囲で動く) | そのまま使える |
| アイデア出し・ブレスト | 低(事実でなくても目的を果たす) | そのまま使える |
| コードの生成・デバッグ | 中(動作確認が必須) | 必ずテスト実行 |
| 最新情報・統計の引用 | 高 | Web検索連携AIを使う・一次ソース確認 |
| 論文・書籍の引用 | 高 | 必ずDOI・ISBNで実在確認 |
| 法律・医療の具体的判断 | 極めて高 | 専門家への確認必須。AIの回答は参考程度 |

まとめ:ハルシネーション対策の優先順位
- 情報ソースを与える——文書を貼り付けての要約、Web検索連携AIの活用が最も効果的
- 「不確かな場合は言って」とプロンプトに入れる——シンプルだが効果あり
- 検証可能なタスクには推論モデルを使う——o3・Claude Sonnet extended thinkingなど
- 数値・引用・法的判断は必ず一次ソース確認——AIへの過信をやめる
- リスクの高いジャンルでの「丸投げ」をやめる——AIは補助、最終判断は人間
生成AIのハルシネーション全般については「生成AIのハルシネーション対策ガイド」も参考にしてください。RAGを使った情報根拠付けの仕組みは「RAGとは?仕組みと活用事例をわかりやすく解説」で詳しく解説しています。


