ハルシネーションとは？定義と具体例
ハルシネーションは、生成AIの出力が「流暢で説得力があるのに、内容が事実に反している」状態を指します。単なる誤字や計算ミスと違い、誤りが自然な文章に溶け込んでいるため、知識のない人には見抜けないのが厄介な点です。
典型例を挙げます。実在しない書籍や論文をタイトル・著者名・出版年つきで「紹介」する。存在しない判例を引用する。実在の人物に架空の経歴を付け加える。誤ったAPIの使い方を正しいかのように解説する、などです。
重要なのは、AIに「嘘をつく意図」はないことです。AIの仕組みを理解すると見えてきますが、これはバグというより、現在の技術の性質に根ざした現象です。
なぜ起きるのか：LLMは「事実」ではなく「確率」を扱う
ハルシネーションの根本原因は、大規模言語モデル（LLM）の動作原理そのものにあります。LLMがやっているのは、膨大なテキストから学んだ統計パターンに基づく「次に来る確率が高い単語の予測」です。
つまりLLMは事実のデータベースを参照して答えているのではなく、「それらしい文章の続き」を確率的に生成しています。「東京タワーの高さは」と入力されれば「333メートル」が高確率で続くため正解しますが、この正解は事実照合の結果ではなく、あくまで確率予測の結果です。
学習データに情報が少ない質問や、複数の情報が混線しやすい質問では、この確率予測が「もっともらしいが誤った続き」を選んでしまいます。細部が曖昧なまま、文章としての自然さだけが保たれるため、自信満々の誤答が生まれるのです。
さらに、多くのチャットAIは「わかりません」と答えるより何かしら回答するよう調整されてきた経緯があり、これが無理な回答生成を助長する面も指摘されています。
ハルシネーションの代表的なパターン
- 事実の捏造：実在しない書籍・論文・判例・統計数値を生成する
- 事実の混線：実在するA氏の経歴に、別のB氏の実績を混ぜて語る
- 時間軸の混乱：学習データの時点より後の出来事を、古い情報で断定する
- 文脈への迎合：ユーザーの誤った前提（「〜という事件がありましたよね？」）に合わせて、存在しない事件の詳細を「補完」する
- 出典の捏造：本文は概ね正しいのに、根拠として示すURLや文献が実在しない
とくに危険なのは「文脈への迎合」です。ユーザーが確信を持って誤った前提で質問すると、AIはそれを訂正するより、前提に沿った回答を生成しやすい傾向があります。
実際に起きたトラブル事例
ハルシネーションは実害を伴う事故を複数起こしています。米国では2023年、弁護士がChatGPTで作成した準備書面に実在しない判例6件が引用されていたことが発覚し、裁判所から制裁を受けました。
また、カナダの航空会社では、公式サイトのチャットボットが実際には存在しない割引制度を案内し、裁判所が「チャットボットの回答にも会社は責任を負う」として返金を命じた事例があります。企業がAIの出力に法的責任を問われた先例として注目されました。
検索エンジンのAI回答機能が、ジョーク投稿を真に受けて「ピザに接着剤を入れる」ことを提案した事例も話題になりました。学習データやリアルタイム参照先の品質が、そのまま出力の品質に直結することを示しています。
実務でのハルシネーション対策
対策1：RAG（検索拡張生成）で根拠を渡す
最も効果的な技術対策がRAG（Retrieval-Augmented Generation）です。質問に関連する社内文書や信頼できる資料をまず検索し、その内容を根拠としてAIに渡したうえで回答させる仕組みです。
「知識をモデルの記憶に頼らせず、その場で資料を見せて答えさせる」ため、捏造の余地が大きく減ります。企業のAI導入でRAGが本命とされる最大の理由がこれです。
対策2：プロンプトの工夫
指示の書き方でも発生率を下げられます。「わからない場合は『わからない』と答えてください」と明示する、「提供した資料の範囲内でのみ回答してください」と制約する、回答に出典の明記を求める、といった方法が有効です。
対策3：人間による検証プロセスを組み込む
技術対策をしても、ハルシネーションをゼロにはできません。だからこそ、固有名詞・数値・出典は必ず一次情報で確認する、法務・医療・金融など高リスク領域では人間のレビューを必須にする、といった業務フロー側の設計が欠かせません。
「AIの出力は優秀な部下の下書き」と捉え、最終責任は人間が持つ。この運用原則が、現時点での最も確実な対策です。
ハルシネーションは今後なくなるのか
モデルの大型化や学習手法の改善により、ハルシネーションの発生率は世代を追うごとに下がってきています。検索機能との統合や、回答の確信度を示す研究も進んでいます。
一方で、「次の単語の確率予測」という原理を使う限り、完全な根絶は難しいというのが研究者の大方の見方です。ゼロを待つのではなく、RAGや検証フローといった「仕組みで抑え込む」発想が実務の主流であり続けるでしょう。
よくある質問（FAQ）
Q1. ハルシネーションはバグですか？
厳密にはバグではなく、確率的に文章を生成するというLLMの仕組みに由来する性質です。だからこそ修正パッチで消えるものではなく、使う側の対策が重要になります。
Q2. どんなときにハルシネーションが起きやすいですか？
マイナーな固有名詞、詳細な数値・日付、最新の出来事、複数の類似情報が混線しやすい質問で起きやすくなります。逆に一般的な知識の説明や、資料を渡したうえでの要約では起きにくくなります。
Q3. ハルシネーションかどうかを見抜く方法はありますか？
固有名詞・数値・出典を検索して一次情報と照合するのが基本です。同じ質問を聞き方を変えて複数回投げ、回答が揺れるかを見るのも簡易チェックとして有効です。
Q4. 対策済みのAIサービスなら信用してよいですか？
RAGや検索連携で発生率は大きく下がりますが、ゼロにはなりません。重要な意思決定に使う情報は、必ず人間が一次情報で確認する運用を維持してください。
まとめ：仕組みを知れば怖くない
ハルシネーションは、LLMが「事実」ではなく「確率」で文章を作ることに由来する、生成AIの構造的な性質です。原理を理解し、RAG・プロンプト設計・人間の検証という3層の対策を組み合わせれば、リスクを管理しながらAIの生産性を引き出せます。
前提知識としてLLMの仕組みとRAGの解説を、生成AI全般の基礎は生成AIとは？を、AI全体の見取り図はAIとは？総合ガイドをご覧ください。
