ハルシネーション
Hallucination ・ はるしねーしょん
LLMがもっともらしい誤情報を生成する現象。生成AI活用の最大の落とし穴。
概要
ハルシネーション（幻覚）は、LLMが事実ではない内容を、あたかも事実であるかのように流暢に生成してしまう現象です。実在しない論文を出典として挙げる、存在しないAPIのメソッドを自信満々に提示する、架空の判例を引用する — 出力の文法も文体も完璧なだけに、読み手が誤りに気づきにくいのが厄介な点です。
生成AIを業務に組み込むうえで最大の落とし穴とされるのがこの現象です。検索エンジンは「見つからない」と答えられますが、LLMは問われれば何かしら「それらしい答え」を必ず生成してしまいます。弁護士がChatGPTの挙げた架空判例をそのまま裁判所に提出して制裁を受けた事件（2023年）は、この危うさを象徴する例としてよく引かれます。LLMを使うシステムの設計とは、ある意味で「ハルシネーションとどう付き合うかの設計」だと言っても過言ではありません。
なぜ生まれたか
ハルシネーションはバグや実装ミスではなく、LLMの動作原理そのものに由来します。LLMは「事実のデータベース」ではなく、「直前までの文脈に続く確率の高いトークンを選び続ける」確率的な文章生成器です。学習で獲得しているのは「もっともらしい言葉の続け方」であって、「真である命題の集合」ではありません。知識は膨大なパラメータに統計的パターンとして溶け込んでおり、個々の事実を確かめる参照テーブルはどこにもないのです。だから、学習データに含まれない事柄や曖昧にしか覚えていない事柄を問われても、モデルは「知らない」と止まる仕組みを本質的には持たず、統計的にもっともらしい語の列 — つまり流暢な作り話 — を出力してしまいます。
この問題が広く認識されたのは、2022年末のChatGPT公開でLLMが一般ユーザーの手に渡ってからです。研究者の間ではそれ以前から知られていましたが、「何でも即答してくれる賢いAI」という体験が先に広まり、その回答が平然と間違うことが社会問題化しました。以降、根拠に基づかせる（grounding）技術や不確実性の扱いが、LLM応用研究の中心テーマの一つになっています。
詳細
なぜ「知らない」と言えないのか
LLMの生成過程を分解すると、ハルシネーションの必然性が見えてきます。モデルは各ステップで語彙全体に対する確率分布を計算し、そこから次のトークンを1つ選びます。「日本の首都は」に続けて「東京」が選ばれるのは、学習データ中でその続き方が圧倒的に多かったからです。ところが「1987年のXYZ社の売上は」のような、学習データにほとんど根拠のない問いでも、確率分布は必ず計算され、何かしらのトークンが選ばれます。数字らしい形式の、もっともらしい数字が。生成の仕組み上、「根拠がある続き」と「形式だけ整った続き」を区別するステップが存在しないのです。
さらに、RLHFなどの調整が「自信を持って助けになる回答をするモデル」を選好してきた歴史も影響します。人間の評価者は「分かりません」より具体的な回答を高く評価しがちで、その報酬構造が「とにかく答える」傾向を強化した側面が指摘されています。つまりハルシネーションは、確率的生成という原理と、有用さへの最適化との合わせ技で生じています。
緩和策 — 根拠を与え、根拠を示させる
完全な解決策はまだありませんが、実務で効果が確立している緩和策はいくつかあります。中心となる考え方が「grounding（接地）」— モデルの内部知識だけに頼らせず、信頼できる外部情報を根拠として与えることです。その代表がRAGで、質問に関連する社内文書や最新情報を検索してプロンプトに添え、「この資料に基づいて答えよ」と指示します。モデルは自分の曖昧な記憶ではなく目の前の資料の言い換えに近い生成をするため、事実誤りが大きく減り、さらに「どの資料の何ページに基づくか」という引用を出力させれば、人間が検証できるようになります。
プロンプトエンジニアリングによる緩和も有効です。「不明な場合は不明と答えること」と明示する、根拠の引用を必須にする、段階的に推論させてから結論を出させる、といった指示は誤答率を下げます。生成時の温度パラメータ（出力のランダム性）を下げることも、事実性が重要な用途では定石です。さらにシステム側では、別のLLMや検証ロジックで出力を照合するセルフチェック、Function Callingで計算や検索を外部ツールに任せて「モデルに暗算・暗記させない」設計などが組み合わされます。
完全排除はできない — 前提としての設計
重要なのは、これらをすべて積み重ねてもハルシネーションはゼロにならない、という認識です。確率的生成という原理を保つ限り、誤生成の可能性は常に残ります。RAGでさえ、検索が外れれば無関係な資料から誤った答えを組み立てますし、資料を正しく渡しても読み違えることがあります。したがって実務の設計指針は「排除」ではなく「封じ込め」です。誤りのコストが高い用途（医療・法務・金融など）では人間のレビューを必須の工程に置く、出力を直接実行せず検証を挟む、ユーザーに出典を提示して確認可能にする — ちょうど分散システムが障害を前提に設計されるように、LLMを組み込むシステムは「モデルは時々もっともらしく間違う」ことを前提に組み立てる必要があります。この前提を持てるかどうかが、生成AI活用の成否を分ける分水嶺です。