ハルシネーションはなぜ起きるか——確率的生成とファクトの本質的相性問題

LLMを使った経験があれば、一度は「自信満々に間違いを言われた」という体験をしたことがあるはずだ。存在しない論文の引用、架空の人物の経歴、実際とは異なる歴史的事実——これらはすべて「ハルシネーション（幻覚）」と呼ばれる現象だ。

ハルシネーションは単なるバグではなく、LLMの確率的生成という本質から生まれる、構造的な問題だ。

ハルシネーションの定義と種類

ハルシネーションとは、LLMが生成する内容が事実とかけ離れているにもかかわらず、自信を持って出力する現象の総称だ。大きく三種類に分けられる。

**事実誤認（Factual Hallucination）**は、実在する事物について誤った情報を述べるケースだ。ある人物の生年を間違える、ある出来事の年代を誤る、などがこれにあたる。

**情報捏造（Confabulation）**は、存在しないものを存在するかのように述べるケースだ。実在しない論文のタイトルと著者名と出版年を完璧な形式で生成する、架空の企業の詳細を実在するかのように説明するなどがある。

**論理矛盾（Logical Hallucination）**は、一つの回答の中で自己矛盾するケースだ。前の文で述べたことと相反する内容を後の文で言う、などだ。

これらの共通点は「確信を持った誤り」だ。LLMは間違いを述べるとき、正しいことを述べるときと同じトーンで、同じ自信を持って出力する。

確率的生成とファクトの相性問題

ハルシネーションの根本原因は、LLMの「確率的生成」という仕組みとファクト（事実）の本質的な相性の悪さにある。

LLMは「次のトークンとして最もそれらしいものを確率的に選ぶ」ことで文章を生成する。ここで「それらしい」とは、訓練データに現れたパターンとの一致度を意味する。

問題は、「最もそれらしいトークン列」と「事実として正しいトークン列」が一致するとは限らない点だ。

たとえば「○○という人物は△△大学を卒業し、□□賞を受賞した」という文章を生成するとき、LLMは「この人物についての自然な紹介文はどういうものか」というパターンを参照する。もし訓練データにその人物の詳細情報が少なければ、似たような文脈で登場した他の人物の情報がパターンとして混入しやすくなる。

LLMには「この情報が正確かどうかを検証する」仕組みが標準的には存在しない。生成の各ステップで行われるのは確率計算のみだ。

頻度帰属エラー——稀な事実が「沈む」理由

ハルシネーションが特に起きやすいのは、稀な情報や特定の固有名詞に関する質問だ。これには「頻度帰属エラー」という現象が関係している。

LLMの訓練データでは、頻繁に言及される情報ほどそのパターンが強く学習される。「東京は日本の首都」という事実は無数のテキストで繰り返されるため、非常に確実に出力される。一方、特定の人物の詳細な経歴、マイナーな学術論文の内容、地方の固有情報などは訓練データへの登場回数が少ない。

登場回数が少ない情報は、LLMの確率計算において「正確な情報」として確立されるほどのパターン強度を持てない。しかし、LLMはその不確実性を出力に反映させる仕組みを持っていない。代わりに、文脈的に「それらしい」情報を生成してしまう。

これが、有名な人物よりもマイナーな人物についての方がハルシネーションが起きやすい理由だ。

「自信」が付随する理由

ハルシネーションの厄介さを増しているのは、誤った情報が「自信を持って」出力される点だ。

LLMの出力には、「確信度」を示すメカニズムが標準的には組み込まれていない。文章を生成するトークン予測の過程で、「これは不確かな情報だから、曖昧に述べよう」という判断が自動的にはなされない。

一部のシステムでは「わかりません」「確認が必要です」という出力を行うよう訓練されているが、これはモデルが本当に「知っている」かどうかを判断しているのではなく、「不確かな場合に謙虚な表現を使う」というパターンを学習している結果だ。

本質的に言えば、LLMは「知っていること」と「知らないこと」を区別できない。生成された文章はすべて、確率的に選ばれたトークンの列だ。

対策の限界

ハルシネーションへの対策として、いくつかのアプローチが研究・実装されている。

**RAG（検索拡張生成）**は最も実用的な対策だ。外部データベースを検索して正確な情報をコンテキストに注入することで、LLMが「作り出す」代わりに「参照して答える」状況を作る。しかし検索が失敗した場合や、取得した文書がLLMによって誤って解釈された場合はハルシネーションが起きうる。

**自己整合性（Self-Consistency）**は、同じ質問を複数回行い、回答の一致度から信頼性を評価する手法だ。多数の回答が一致する場合は信頼性が高いと判断できるが、すべての回答が同じ間違いをする「一貫したハルシネーション」には対処できない。

**根拠付き生成（Grounded Generation）**は、出力の各部分にソースを付与させ、検証可能にする手法だ。しかしLLMがソースを捏造することも起きるため、ソースの実在確認が必要になる。

いずれの対策も「完全な解決」ではなく「軽減」だ。確率的生成という本質を変えない限り、ハルシネーションはゼロにはならない。

まとめ

ハルシネーションはLLMの欠陥ではなく、確率的トークン予測という設計そのものから生まれる構造的な問題だ。

「最もそれらしい文章を生成する」ことと「事実として正しい文章を生成する」ことは、本質的に異なる目標だ。LLMは前者に最適化されているが、後者の保証はない。

この理解に立つことで、LLMを使う際の正しいリテラシーが生まれる。重要な情報は必ず一次ソースで確認し、LLMの出力はドラフトや候補として扱い、事実確認の工程を省かない。それがハルシネーションと付き合う現実的な方法だ。