AIのハルシネーションとは、ChatGPTなどの生成AIが事実に基づかない情報を、あたかも正しいかのようにもっともらしく出力する現象です。語源は英語の「hallucination（幻覚）」で、AIが幻覚を見ているかのように架空の情報を生成することからこう呼ばれています。
重要なのは、これがAIの「悪意」ではなく、大規模言語モデル（LLM）が確率的に文章を生成する構造から生じる現象だという点です。そのため、ハルシネーションを完全にゼロにすることはできません。しかし、発生しやすい条件を理解した上でプロンプト設計・ファクトチェック・RAG・組織運用を組み合わせれば、実務上のリスクは十分にコントロールできます。
本記事では、ハルシネーションの定義と発生メカニズムを整理した上で、実際のトラブル事例を踏まえながら、プロンプト設計からRAG・組織運用までの実務対策を具体的に解説します。
AIのハルシネーションとは？ 生成AIが「もっともらしい嘘」を出す現象
AIのハルシネーションとは、生成AIが事実に基づかない情報を、あたかも正しいかのようにもっともらしく出力する現象です。語源は英語の「hallucination（幻覚）」で、実在しないものを知覚してしまう状態になぞらえた表現です。
身近な場面で言えば、ChatGPTに「この分野の代表的な論文を教えて」と尋ねたとき、タイトルも著者名も引用数も本物らしく見えるのに、実際には存在しない論文が返ってくることがあります。GeminiやCopilotでも同様に、実在しないURLや架空の統計データが、正確な情報と同じ文体で出力されるケースがあります。
ここで押さえておきたいのは、AIが「意図的に嘘をついている」わけではないという点です。大規模言語モデル（LLM）は、与えられた文脈に対して「次にくる単語として最も確率が高いもの」を繋ぎ合わせることで文章を生成します。この仕組みでは、文脈としての自然さが事実としての正しさに優先されます。
つまり、ハルシネーションはAIの「悪意」ではなく、確率的な文章生成という構造から不可避的に生じる現象です。
内在的ハルシネーションと外在的ハルシネーション
ハルシネーションは大きく2種類に分類できます。発見しやすさと実務上の被害の大きさが異なるため、それぞれの性質を把握しておくと対策を立てやすくなります。
内在的ハルシネーションは、学習データに含まれている情報と矛盾する出力が生じるタイプです。たとえば「東京タワーの高さは400メートル」「第二次世界大戦の終結は1950年」のように、学習データ内に正しい情報が存在するにもかかわらず、異なる値や事実が出力されます。学習データと照合すれば誤りを検出できるため、比較的発見しやすいのが特徴です。
外在的ハルシネーションは、学習データ自体に存在しない情報が生成されるタイプです。架空の論文や実在しないURLの生成がその典型で、「AIが作り上げた情報」である以上、突き合わせるべき正解のソースが最初から存在しません。このため、知識のある専門家でなければ誤りに気づけないケースもあります。
実務での被害という観点では、外在的ハルシネーションのほうが深刻です。内在的ハルシネーションは「調べれば分かる」範囲にとどまりますが、外在的ハルシネーションは見た目に問題がないまま誤情報が意思決定やドキュメントに混入するリスクがあります。
ハルシネーションはなぜ起きる？ 発生メカニズムと主な原因
前章で見たとおり、ハルシネーションはAIが嘘をついているわけではなく、LLMの設計そのものに根差した現象です。根本のメカニズムを理解すると、「どんな使い方がリスクを高めるか」「どこを改善すれば発生を抑えられるか」の判断軸が見えてきます。
ハルシネーションの根本原因はLLMの確率的な文章生成構造にあり、学習データの品質とプロンプトの明確さが発生リスクを左右します。つまり、モデルの設計上の制約と利用者側のアプローチの両方が、ハルシネーションの頻度に影響しています。
LLMは「正しさ」ではなく「もっともらしさ」で文章を生成する
LLMが文章を生成するとき、内部でやっていることはシンプルです。「この文脈の次に、統計的に最も現れやすい単語は何か」を繰り返し予測し、単語をつなぎ合わせています。百科事典を参照して事実を確認しているのではなく、膨大な学習テキストから抽出したパターンをもとに「それらしい続き」を出力しているのです。
その結果、流暢で自信ありげな文章でも、内容が事実と食い違うことが構造的に起こりえます。LLMが最適化しているのは「情報が正しいか」ではなく「文脈として自然かどうか」だからです。存在しない論文のタイトルや、実在しないURLを堂々と出力するのは、悪意でも故意でもなく、この生成の仕組みから来ています。
また、評価の設計上の問題も見逃せません。LLMのトレーニングでは一般に、「わかりません」と棄権するより「何かしら答える」ほうに報酬が向かう設計になっています。知識の空白があっても推測で埋めることが奨励されやすい構造のため、ハルシネーションは完全にゼロにはなりません。
これが、どのモデルでもハルシネーションが残り続ける根本的な理由です。
学習データの偏りとプロンプトの曖昧さが精度を左右する
LLMの構造がハルシネーションを生む土台だとすると、学習データとプロンプトはその発生頻度を左右する要因です。
学習データの偏り・不足・古さ
LLMは学習したテキストに存在しない情報については、推測で補完しようとします。特定のトピックに関するデータが少なければ、その領域で誤りを出しやすくなります。ニッチな分野の固有名詞や、学習データに少数しか登場しない人物のプロフィールなどは、これが顕著に現れます。
学習データの「古さ」も同様の問題を引き起こします。学習データのカットオフ以降に起きた出来事や変更された制度・法規については、モデルは正確な情報を持っていません。それでも質問への回答を求められると、古い知識か推測をもとに答えを生成してしまいます。
プロンプトの曖昧さや誤った前提
利用者側のプロンプトも、ハルシネーションの発生率に直接影響します。「〇〇について教えて」のような曖昧な質問は、AIが勝手に文脈や条件を補完する余地を広げます。補完が増えるほど、推測に基づく出力が混じるリスクは高まります。
より問題になるのは、誤った前提を含む質問です。「〇〇という論文によれば〜」と架空の論文名を前提に尋ねると、LLMはその誤りを訂正せずに話を続けることがあります。前提を疑わずに補完を優先する傾向があるためです。
言い換えると、プロンプトを具体的かつ正確にすることで、AIが推測する必要のある空白を減らし、ハルシネーションの発生率を下げられます。これは利用者が今日からできる改善で、後述する対策の出発点になります。
ハルシネーションが起きやすい場面・起きにくい場面
リスクの高い使い方と低い使い方を区別する判断軸として、まず「事実確認型か変換タスクか」を意識してください。この2つは、ハルシネーションの発生率に大きな差があります。
人名・年号・具体的な数値・URLといった事実確認を求める質問は、ハルシネーションが起きやすい用途です。正解が一つに定まる問いほど、推測で補完した場合の「外れ」が目立ちます。一方、要約・翻訳・文章校正のように、手元にある入力テキストを変換するタスクはリスクが低めです。
モデルが参照すべき情報（入力テキスト）がそこにあるため、架空の情報を補完する余地が小さくなります。
加えて、次の3つの条件が重なると特にリスクが高まります。1つ目は最新情報への質問で、学習データのカットオフ以降の出来事は誤答しやすくなります。2つ目は専門分野、特に法律・医療・学術論文など正確さが求められる領域です。
3つ目はマイナーなトピックで、学習データが薄い対象ほど推測の割合が増えます。
「ChatGPTからClaudeに乗り換えれば解決する」という期待も、この文脈では調整が必要です。モデルによって精度の差はあるものの、上記のような場面でのハルシネーション自体は、どのモデルにも共通して起こりえます。モデルを変えることは根本解決にはならず、使い方の工夫とセットで考えることが求められます。
ハルシネーションのリスクと実際に起きたトラブル事例
発生メカニズムを理解すると、次に気になるのは「では実際にどんな被害が出ているのか」という点でしょう。
事例を見ると、その深刻さは「AIが誤情報を出した」という技術的な失敗にとどまりません。法的制裁、時価総額の暴落、名誉毀損訴訟と、組織の存続に関わる実害に発展しています。
以下では、ビジネスで想定される3つのリスクカテゴリを整理したうえで、実際に起きた事件を具体的に見ていきます。
ビジネスで想定される主なリスク
ハルシネーションがもたらすリスクは、業務の上流から下流まで広く及びます。意思決定、法的責任、対外的な信用という3つの観点から整理します。
誤った意思決定につながるリスク
AIが生成した架空のデータや市場分析を根拠に経営判断を下した場合、実態と乖離した投資や事業展開につながり、ビジネスチャンスの損失や直接的な経済的ダメージが生じます。
担当者が「AIが出力したから正しいはずだ」と確認を省略するほど、このリスクは高まります。
法的責任・コンプライアンスリスク
AIが最新の規定に存在しない架空の契約条件や法令を提示し、そのまま取引や社内文書に使用してしまうと、法的責任やコンプライアンス違反を問われる可能性があります。
契約交渉や法務業務でAIを補助ツールとして使う場面では特に注意が必要で、出力された法令番号や条文は必ず一次ソースで確認する必要があります。
信用・ブランド毀損リスク
AIが生成した誤情報をSNSや対外的な広報文書でそのまま発信した場合、企業の信用やブランド価値が傷つきます。誤情報が一度広まると、訂正コストと信用回復にかかるコストはどちらも大きく、発信前の検証を怠ったという事実が残ります。
こうしたリスクは現場の感覚とも一致しており、大企業の生成AI担当者への調査では、AI活用時の不安として「誤情報の生成（ハルシネーション）」を挙げた割合が59.2%で最多となっています（出典：IDEAETCH（リサピー®︎によるインターネット調査）「生成AIの業務適応と課題に関する実態調査」2024年）。
この数字は、社内やクライアントへAI利用のリスクを説明する際の根拠としても活用できます。
実際に起きた3つのトラブル事例
「理論的なリスク」が現実の損害に変わった事例が、すでに複数起きています。3件を順に見ていきます。
ChatGPTが生成した架空の判例を弁護士が裁判資料に引用した事件
2023年、ニューヨーク連邦地裁で審理されたMata v. Avianca事件で、原告側弁護士がChatGPTに判例調査を任せ、出力された判例をそのまま法廷資料に引用しました。問題は、引用した判例の大半が実在しない架空のものだったことです。裁判官から指摘を受けて初めて誤りが発覚しました。
裁判所はこの弁護士に5,000ドルの制裁金を命じ、当事者への通知義務も課しました（出典：Jurvantis.ai「Mata v. Avianca, Inc. (S.D.N.Y. June 22, 2023)」2023年）。金額以上に深刻だったのは信用の損傷で、「AIの出力を一切確認しなかった」という事実がキャリアに与えたダメージは回復できないものでした。この事件が示す教訓は明確です。
AIは調査の補助に使えても、出力の検証責任は人間が負うという点は変わりません。
Google Bard発表デモでの誤回答と株価暴落
2023年2月、Googleが新しいAIチャットボット「Bard」を公式に発表したプロモーション動画の中で、Bardが天文学に関する質問に誤った情報を回答しました。「ジェームズ・ウェッブ宇宙望遠鏡が系外惑星の写真を初めて撮影した」という事実に反する内容で、天文学コミュニティからすぐに誤りを指摘されました。
翌日、親会社Alphabetの株価は急落し、時価総額にして約1,000億ドルが失われました（出典：NPR「Google’s AI chatbot, Bard, sparks a $100 billion loss in Alphabet shares」2023年）。製品の品質への疑念が投資家心理に直結した事例です。AIの出力を公開前に検証する体制の重要性を、世界最大級のテック企業が最悪の形で示した事件と言えます。
ChatGPTによる名誉毀損訴訟
2023年6月、米国の法学教授Mark WaltersがOpenAIを相手取り訴訟を起こしました。ChatGPTが、実在する彼を横領や詐欺の当事者として描写した架空の文書を生成したことが発端です。（出典：「ChatGPTが告訴状を「偽造」 米男性、名誉毀損でオープンAI提訴」2023年） v. OpenAI事件として知られるこの訴訟は、AIが生成した虚偽情報が個人の名誉を傷つけた場合、その法的責任の所在をどこに問うのかという問いを提起しました。
この事件が示すリスクは、当事者がAIを利用していなくても被害者になりうるという点です。自社や個人名がAIによって誤った文脈で出力される可能性は、AIを使う・使わないに関わらず、誰にとっても無縁ではありません。
ハルシネーションはどう防ぐ？ 実務で使える4つの対策
こうした実害を踏まえると、対策が欠かせないことが分かります。ハルシネーションのリスクは、適切な対策を組み合わせることで実務上十分にコントロールできます。対策は3つの層に分かれます。
利用者個人が取り組む「プロンプト設計」と「ファクトチェック」、システム側で対処する「RAG（検索拡張生成）」、そして組織全体で取り組む「AI利用ルールの整備」です。
各対策は独立しているわけではなく、層を重ねるほどリスクが下がる構造になっています。まずプロンプトで発生を抑え、出力を検証し、技術と運用でそれを補う、という順序で整理します。
1. プロンプトの工夫で発生を抑える
ハルシネーションの多くは、AIが曖昧な質問に対して推測で補完しようとするときに起きます。プロンプトに主語・年代・対象を具体的に指定することで、AIが「空白を埋める」余地を減らせます。
例えば「最近のマーケティング動向を教えて」という質問より、「2024年の日本における中小企業向けSNSマーケティングの主な傾向を教えてください」のように書く方が、AIが推測に頼る範囲を絞り込めます。対象・時期・地域・範囲の4点を意識してプロンプトを組み立てると、回答の精度が上がります。
もう一つ有効なのが、回答制約の明示です。プロンプトの末尾に「情報がない場合や確信が持てない場合は『わかりません』と答えてください」と加えることで、AIが根拠のない内容を自信満々に出力する動作を抑制できます。AIはデフォルトでは「何らかの答えを返そうとする」傾向があるので、「わからない」と言う許可を明示的に与えることが効きます。
また、事実かどうかわからない前提を質問に含めないことも重要です。「〇〇社がAを実施したと聞きましたが、その効果はどのくらいですか？」のような質問は、誤った前提をAIが肯定したまま回答を生成するリスクがあります。
前提の真偽を先に確認してからプロンプトを作る習慣をつけてください。
2. 出力のファクトチェックを習慣化する
プロンプトを工夫してもハルシネーションをゼロにはできないため、出力の検証を習慣化することが不可欠です。すべての文章を一から確認するのは現実的ではないので、優先順位を絞ることがポイントです。
最優先で確認すべき要素は次の4つです。
- 数値（統計・割合・金額・件数など）
- 固有名詞（人名・企業名・商品名・団体名）
- URL（存在するリンクか、内容と一致しているか）
- 日付・時期（出来事の発生時期や最新情報の有効性）
これらは「もっともらしく見える」が「間違えやすい」典型です。確認の手順は、まず一次情報（公式サイト・原典・政府統計など）と突き合わせ、次に複数のソースでクロスチェックする2段階が基本です。どちらか一方だけでは漏れが出るので、両方を習慣として組み込みます。
組織でAI出力を活用する場合は、個人のチェックだけに任せず、担当者による一次確認と専門部署（法務・広報・品質管理など）による再確認のダブルチェック体制を構築することを推奨します。チェックの抜け漏れが発生しやすいのは「誰かが確認しているはず」という暗黙の前提があるときなので、確認フローを明文化して役割を明確にしておくことが前提になります。
3. RAG（検索拡張生成）で外部知識を参照させる
プロンプト設計とファクトチェックは利用者側の対策ですが、技術的なアプローチでハルシネーションを抑える手段もあります。その代表がRAG（Retrieval-Augmented Generation、検索拡張生成）です。
RAGの仕組みはシンプルです。通常のLLMは学習済みのパラメーターだけをもとに回答を生成しますが、RAGでは回答を生成する前に外部のデータベースを検索し、その検索結果を文脈として与えた上で回答を生成します。「記憶だけで答えさせる」のではなく「調べてから答えさせる」構造に変える、というイメージです。
この仕組みによって、学習データに含まれていない最新情報や社内情報をAIに参照させられるようになります。さらに「どのドキュメントをもとに答えたか」という出典を提示できるため、出力の根拠を事後に確認しやすくなるのも利点です。
社内での活用シーンで特に効果を発揮するのが、参照先を社内ナレッジに限定したAIです。例えばNotePMのAIチャットボット機能は、NotePM上の情報だけを参照して回答を生成する設計になっているため、一般的なLLMよりも社内利用でのハルシネーションリスクが低い構造になっています。
「同じ質問が繰り返される」「担当者によって回答がばらつく」といった課題を抱える組織では、こうした仕組みが有効な選択肢になります。
4. 組織のAI利用ルールを整備する
個人の習慣や技術的な対策だけでは、組織全体のリスクを管理しきれません。AI出力に起因するトラブルが発生したとき「誰が何を確認する義務があったか」が曖昧だと、責任の所在が不明になり再発防止も難しくなります。ガイドラインの整備は、こうした状況への備えです。
ガイドラインに盛り込むべき内容は、主に3点です。第一に、AI利用の範囲の明示。情報収集・事実確認には単独での利用を避け、あくまでサポート業務（文章の校正・アイデア出し・要約など）に限定する、といった線引きを決めます。
第二に、ファクトチェックの手順と担当者の指定。何を・誰が・どのステップで確認するかを明文化し、確認の空白地帯をなくします。第三に、責任の所在の明確化。
AI出力を最終的にレビューする担当者を設定し、対外発信の場合は管理職や専門部署の承認を必須とするフローを定めます。
特に重要な意思決定や対外発信にAI出力を活用する場面では、専門知識を持つ担当者によるHITL（Human-in-the-Loop、人間による最終確認プロセス）を必ず組み込む必要があります。AIの出力はあくまで「たたき台」として扱い、最終的な判断と責任は人間が持つ設計にすることがリスク管理の基本です。
ガイドラインを整備したら、全従業員への周知と定期的な研修も欠かせません。ルールが存在しても知られていなければ機能しないため、入社時のオンボーディングに組み込む、半年ごとに内容を見直す、といった運用まで設計しておくことで、組織としてのハルシネーション対策が実効性を持ちます。
ハルシネーションは「なくす」より「コントロールする」
ここまで4層の対策を見てきましたが、その前提として押さえておきたいのは、最新のGPT-5世代の推論モデルでも、ハルシネーションは完全には解消されていないという事実です。改善は着実に進んでいますが、すべての言語モデルにとって依然として根本的な課題であり続けています（出典：OpenAI「GPT-5 System Card」2025年）。
「もっと良いモデルに乗り換えれば解決する」という期待は、残念ながら現時点では成立しません。
ただし、これは「AIが使えない」という意味ではありません。ハルシネーションは確率的な文章生成という構造から生まれる現象であり、発生条件を理解して対策を組み合わせれば、実務上のリスクは十分にコントロールできます。
こうした対策の土台になるのが、参照情報の品質です。AIが参照できる社内ナレッジが整備されていれば、RAGの精度は上がり、ハルシネーションが入り込む余地も縮まります。NotePMは、社内のナレッジをまとめて管理し、NotePM上の情報だけを参照するAIチャットボット機能を備えたツールです。
担当者ごとに回答がばらつく、調べるたびに時間がかかるといった状況を解消しながら、ハルシネーション対策の仕組みとしても機能します。
