生成AIのハルシネーションの原因は？仕組みからRAG等の対策まで解説

結論：ハルシネーション（Hallucination）とは、生成AIが事実に基づかない情報を、あたかも真実であるかのように生成してしまう現象のことです。

【現実】AIは「嘘をついている」つもりはない

生成AIを活用する上で、最も厄介であり、かつ避けて通れないのがこのハルシネーションです。
「AIが嘘をついた」と表現されることが多いですが、人間のように悪意を持って騙そうとしているわけでも、知ったかぶりをしているわけでもありません。

エンジニアや実務担当者がまず理解すべきは、これがバグや故障ではなく、現在のLLM（大規模言語モデル）の仕様そのものであるという点です。どれほど高性能なモデル（GPT-4やClaude 3など）を使っても、発生確率をゼロにすることはできません。

本記事では、なぜAIが息を吐くように嘘をつくのか、その技術的メカニズムを解剖し、実務で被害を最小化するための「プロンプト制御」「RAG構築」「組織的運用」の具体的対策を解説します。

発生メカニズム：なぜAIはもっともらしく誤るのか

ハルシネーションを理解するには、LLMがどのように回答を生成しているかを知る必要があります。

「知識の検索」ではなく「確率的な連想ゲーム」

私たちが検索エンジンを使うとき、データベースから「正解」を探し出します。しかし、生成AIはデータベースを持っていません。
LLMの本質は「次単語予測（Next Token Prediction）」です。入力された文脈に対して、確率的に「次に続く可能性が最も高い単語（トークン）」を選び出し、それを繋げているだけです。

これを人間に例えるなら、「即興演劇（インプロ）の役者」に近いと言えます。

その結果、AIは「わかりません」と沈黙するよりも、文脈的に自然であれば、存在しない事実を流暢に語り続けることを選択してしまいます。これがハルシネーションの正体です。

構造的な発生要因

この「即興演劇」が失敗する（事実と異なる）主な要因は以下の通りです。

• 学習データのカットオフ:
  モデルが学習を終えた日（ナレッジカットオフ）以降の情報は持っていません。しかし、文脈を繋げるために古い情報を混ぜたり、架空の未来を予測として語ったりします。
• Web上のノイズ:
  学習データであるインターネット上のテキスト自体に誤情報や偏見が含まれており、それを「真実」として学習しています。
• 流暢さの優先:
  Transformerアーキテクチャは、事実の正確性よりも「文章としての自然さ」に高いスコアを与える傾向があります。

【ここでのポイント】AIは知識のデータベースではなく、確率で言葉を繋ぐエンジンです。「もっともらしい嘘」をつくのは、AIが「文章の自然さ」を最優先しているからです。

ハルシネーションの2分類：矛盾と捏造

ハルシネーションは一様ではありません。研究論文等では、大きく「内在的」と「外在的」の2つに分類されます。対策を立てる上でも、この違いを意識することは重要です。

ここでは、「料理レシピの生成」を例に解説します。

1. 内在的ハルシネーション (Intrinsic Hallucination)

提供された情報源（ソース）と、生成された回答が論理的に矛盾している状態です。

• 例:
• 入力: 「材料：豚肉、キャベツ、塩」というテキストを与える。
• AIの回答: 「まず、鶏肉を一口大に切り、フライパンで炒めます…」
• 分析:
  入力された情報（豚肉）を無視し、学習データ内の一般的なレシピ（鶏肉のレシピなど）と混同して処理してしまっています。推論能力の限界や、注意機構（Attention）のミスによって起こります。

2. 外在的ハルシネーション (Extrinsic Hallucination)

入力情報にも、事前の学習データにも存在しない情報を、AIが完全に新規にでっち上げる状態です。検証が難しく、より危険度が高いタイプです。

• 例:
• 入力: 「最高のカレーの作り方を教えて」
• AIの回答: 「隠し味として『月光スパイス』を加えるのがポイントです。このスパイスは東京・練馬区の専門店『スパイスハウス・ルナ』で購入可能です。」
• 分析:
  『月光スパイス』も『スパイスハウス・ルナ』も実在しません。もっともらしい固有名詞と場所を捏造しています。

【実践対策1】プロンプトエンジニアリングによる制御

ここからは、実務でハルシネーションを抑制するための具体的な技術解説に入ります。まずは、エンジニアでなくとも実践できる「指示出し（プロンプト）」の工夫です。

AIという「即興役者」に対し、アドリブを禁じ、台本通りに演じさせるための指示を与えます。

「存在しない前提」への対処法

ユーザーが誤った前提で質問をしてきた場合、AIはそれに迎合（Sycophancy）して嘘をつく傾向があります。これを防ぐには、「情報がない場合は正直に答えろ」という強い制約（Grounding）が必要です。

悪いプロンプト例:

弊社（株式会社サンプル）が2026年に買収した企業のリストを出して。
（※注：実際には2026年に買収の事実はないシナリオ）

この場合、AIは「株式会社サンプル」の業種に関連しそうな架空の企業名を列挙する可能性があります。

改善したプロンプト例（指示書）:

# 命令書
あなたは厳格な企業監査人です。以下の[Context]のみに基づき、ユーザーの質問に回答してください。

# 制約条件
- [Context]に含まれない情報は一切使用しないこと。
- 該当する情報が見当たらない場合は、推測せず「提供された情報内には記述がありません」と回答すること。
- 回答には、情報の根拠となる[Context]内の引用部分を明記すること。

# Context
(ここに2026年のプレスリリース全集などのテキストデータを挿入)

# ユーザーの質問
弊社が2026年に買収した企業のリストを出して。

効果的なテクニック一覧

• 拒否権の付与:
  上記のように「わからなければ『わからない』と言っていい」と明示的に許可を出します。
• CoT (Chain of Thought):
  「ステップバイステップで考えて」と指示し、思考過程を出力させます。いきなり答えを出させるよりも、論理の飛躍や矛盾が発生しにくくなります。
• 引用（Source）の要求:
  回答の末尾に「参照元のURLやドキュメント名」を記載させます。捏造した場合、参照元が存在しないためチェックが容易になります。

【実践対策2】システム的なアプローチ：RAGとパラメータ

個別のプロンプトだけでは限界がある場合、システム構成そのものでハルシネーションを封じ込めます。

RAG (Retrieval-Augmented Generation) の導入

RAGは、生成AIに外部データベースや検索エンジンを接続する技術です。
これまでのAI利用が「自分の記憶だけを頼りに回答する」ものだとすれば、RAGは「オープンブック試験（教科書持ち込み可のテスト）」です。

• Retrieve (検索): ユーザーの質問に関連する情報を、社内Wikiやマニュアルから検索してくる。
• Augment (拡張): 検索結果を「参考資料」としてプロンプトに埋め込む。
• Generate (生成): 「この参考資料を使って答えろ」とAIに指示する。

Temperature (温度) パラメータの調整

API経由でLLMを利用する場合、Temperature というパラメータ設定が極めて重要です。これは生成時の「ランダム性」を制御する数値です（通常0.0〜1.0または2.0）。

• 高い値 (0.7〜1.0):
  確率分布の裾野まで拾うようになり、回答が多様でクリエイティブになります。小説の執筆やアイデア出しに向きますが、ハルシネーションのリスクは最大化します。
• 低い値 (0.0〜0.2):
  確率が最も高い単語だけを選び続けます。回答は機械的で毎回同じになりますが、正確性は高まります。

【ここでのポイント】システム的には「RAGでカンニングさせる」「Temperatureを0にしてランダム性を消す」のが鉄板の対策です。

【実践対策3】組織的な防御とガイドライン

技術的な対策を施しても、すり抜けは発生します。最後は「運用」と「人間」による防御壁が必要です。

HITL (Human-in-the-Loop) の義務化

AIが生成したコンテンツを、そのままエンドユーザーや顧客に出してはいけません。必ず「人間が介在する（Human-in-the-Loop）」フローを構築してください。

• ドラフト作成はAI、承認・修正は人間。
• チャットボットの場合、回答に「これはAIによる自動生成です。誤りを含む可能性があります」という免責を必ず表示し、不審な場合は有人対応へエスカレーションする導線を作る。

ファクトチェックの重点項目

漫然と「チェックしてください」と指示しても見落としが起きます。特にハルシネーションが起きやすい以下の項目を重点チェック対象としてリスト化しましょう。

• 数字: 金額、日付、スペック数値、電話番号。
• 固有名詞: 人名、社名、製品名。
• URL/リンク: 実在するか、リンク切れでないか（AIはURLの構造だけを真似たリンク切れURLを生成するのが得意です）。
• 法的/医学的判断: これらはそもそもAIに判断させてはいけない領域です。

法的リスクと過去の失敗事例

「ちょっとした間違い」では済まされない事態も実際に起きています。企業がAIを利用する場合、ハルシネーションは法的責任（Liability）に直結します。

1. Air Canada チャットボット事件 (2024年)

エア・カナダのチャットボットが、顧客に対して誤った「忌引割引ポリシー（事後申請でも返金可能という嘘）」を案内しました。顧客がそれを信じて正規料金で購入した後、返金を求めたところ、会社側は「ボットの誤りであり、公式サイトの規約が正」と主張。
しかし、裁判所は「企業はチャットボットが提供する情報に対しても責任を負う」と判断し、エア・カナダに賠償を命じました。

2. 米国弁護士の判例捏造 (Mata v. Avianca)

ニューヨークの弁護士が、ChatGPTを使って裁判所に提出する準備書面を作成しました。ChatGPTはもっともらしい過去の判例（Varghese v. China Southern Airlinesなど）を複数引用しましたが、これらは全て実在しない捏造された判例でした。
確認を怠った弁護士は裁判官から厳しく追及され、制裁金処分を受ける事態となりました。専門家であっても、AIの流暢な嘘に騙されるリスクがあることを示しています。

3. Google Bard (Gemini) のデモ誤答

GoogleがAIチャットボット「Bard（現在のGemini）」を発表した際のデモ動画で、ジェームズ・ウェッブ宇宙望遠鏡に関する誤った情報を回答してしまいました。
この事実は天文学者たちによって即座に指摘され、Googleの親会社Alphabetの株価が急落、時価総額で約1,000億ドル（当時のレートで約13兆円）が吹き飛ぶ事態となりました。

よくある質問 (FAQ)

有料版（GPT-4など）を使えばハルシネーションはなくなりますか？

なくなりません。モデルの性能向上により、論理的な矛盾の頻度は減ります。しかし、逆に「非常に説得力のある高度な嘘」をつくようになるため、人間が一見しただけでは誤りに気づきにくくなるリスクがあります。「賢いモデルほど、騙すのが上手い」と考えてください。

RAGを導入すればファクトチェックは不要ですか？

依然として必要です。RAGはハルシネーションを抑制しますが、完璧ではありません。参照する社内ドキュメント自体が古かったり間違っていたりする場合（Garbage In, Garbage Out）や、AIがドキュメントの読み取りを間違える場合があるため、最終確認は必須です。

最もハルシネーションが起きやすいタスクは何ですか？

「最新情報」「計算」「架空設定」です。学習データに含まれていない直近のニュース、厳密な計算処理（LLMは計算機ではなく言語処理機です）、そして「もし〜だったら」という架空の前提に基づく質問において、確率的に誤情報を生成しやすくなります。

---

まとめ

生成AIのハルシネーションは、技術的な「バグ」ではなく、確率論で言葉を紡ぐAIの「特性」です。
これを100%防ぐ魔法の杖はありませんが、リスクを管理可能なレベルまで下げることは可能です。

• 理解: AIは「即興役者」であり、事実を知らないことを受け入れる。
• 技術: プロンプトで「わからない」と言わせ、RAGで「カンニング」させる。
• 組織: AIのアウトプットを盲信せず、必ず人間が責任を持つフロー（HITL）を作る。