Chapter 13

第13章: ハルシネーションと評価 — どう信頼するか

LLM に法律相談をする。

「2024 年に成立した個人情報保護法の改正点を 3 つ教えて」

LLM は流暢に答えてくる：

「2024 年の個人情報保護法改正では、以下の 3 点が主要な変更点です：① 第 17 条第 2 項の本人同意要件の緩和、② 第 23 条のオプトアウト規定の見直し、③ 第 38 条の罰則強化。東京地裁・令和 6 年判決 でもこの改正が引用されています。」

説得力がある。条文番号も判決例も具体的だ。 ところが事実は ── この改正は存在せず、判決も実在しない。 LLM は 「もっともらしい嘘」 を、自信たっぷりに作文した。

これが本章のテーマ ── ハルシネーション (hallucination) だ。 本書の最後に、LLM の最大の弱点を、その「構造に由来する宿命」として理解する。

13.1 ハルシネーションとは何か

LLM の文脈で ハルシネーション とは、次のような現象を指す：

ハルシネーション (hallucination)

LLM が、事実に基づかない情報を、流暢で自信に満ちた口調で生成する現象。

「幻覚」が原義だが、AI の文脈では「もっともらしい作り話」というニュアンスで使われる。 特徴：

  • 文章は 流暢で構造が整っている
  • 固有名詞・数字・日付などが 具体的に書かれている
  • それでいて 事実と一致していない

人間が「この答えは信用できそう」と感じてしまう形で出てくるのが厄介。

ハルシネーションは、単純な「機械の故障」ではない。 LLM の 構造そのもの に組み込まれた、ある意味で 必然の現象 だ。 理由を本章で掘り下げる。

13.2 なぜハルシネーションは起きるのか

第9章で確認した通り、LLM は 「次の単語の確率」を計算する機械 だ。 それ以外のことはしていない。

ここに、ハルシネーションの根本原因がある。

ハルシネーションの構造的理由

LLM は、「真実を述べる」ように訓練されているわけではない。 「確率的にもっともらしい文章を生成する」ように訓練されている。

その 2 つは、しばしば一致する（多くの真実は、もっともらしい）。 だが、真実ではないが、もっともらしい 文章も存在する。 その領域で、LLM は 平気で嘘を書く。

具体例で見よう。 LLM に「2024 年の個人情報保護法改正の条文番号は？」と聞いたとする。 LLM の頭の中では、おおむね次のような計算が走る：

注意: LLM は「2024 年に本当にあった改正かどうか」を確認していない。 「法律解説の文体として自然な単語の並び」 を選んでいるだけだ。 だから、現実に存在しない条文番号や判決を、説得力のある形で生成してしまう。

13.3 ハルシネーションが目立つ場面

ハルシネーションが特に起きやすい場面：

場面起きる理由
固有名詞・日付・数字を聞くこれらは学習データに散在し、LLM の頭の中で「もっともらしいが間違ったもの」を組み立てやすい
「最近の」「最新の」を聞くLLM の学習時点より新しい話題は、無理に推測すると外しやすい
専門的な詳細を聞く学習データに「それっぽい文体」は多いが、内容まで正確な情報は希薄
「○○氏が△△と言った」を聞く実際の発言と異なる引用文を生成しがち
コード生成で存在しないライブラリ関数を呼ぶ似た名前の本当の関数と区別がつかない場合

特に開発の現場では、「存在しない API 関数を、それっぽい名前と引数で呼び出すコード」 を LLM が生成する現象が頻繁に観測される。 これも構造的にはハルシネーションの一種だ。

ハルシネーションの怖さは、「機械が知っているふり をするから」ではない。 「自分が知っているかどうかを、機械自身が判断できない」 ことだ。

LLM の内部には、「自信度の信号」がそもそも明示的に組み込まれていない。 「確率分布で 0.8 のトークン」と「確率分布で 0.3 のトークン」を、出力する単語選びの中で区別しているだけ。 人間のように「これは確証がないから、断定を避けよう」とは、デフォルトでは思考しない。

13.4 LLM をどう評価するか

ハルシネーションの存在を踏まえると、LLM の評価 が大きな課題になる。 「うまく動いている」をどう測るか。

LLM の評価は、おおむね次の 3 つの軸で語られる：

軸①: タスク別ベンチマーク

決まったタスクで、決まったデータセット上での精度を測る：

ベンチマーク測るもの
MMLU57 分野の多肢選択問題（一般教養から法律・医学まで）
HumanEvalPython コードの自動生成精度
GSM8K / MATH数学の問題解決
HellaSwag常識的な文章補完
BIG-Bench HardLLM が苦手とする難問の集合

ニュースで「GPT-5 が MMLU で 90% を達成」のような数字を見るのは、こうしたベンチマークの結果だ。

ただし、ベンチマークには 致命的な問題 がある：

軸②: 人間評価 (Human Evaluation)

人間の評価者が、LLM の応答を 「役立つか」「正確か」「適切か」 で採点する。 RLHF（第10章）の文脈で見た「人間の好み」と地続きの評価だ。

軸③: LLM-as-Judge

最近広まっている発想：もう 1 つの LLM に、出力を評価させる。

GPT-4o や Claude などの強力なモデルに、「以下の応答を 1〜10 で採点せよ」と頼む。 これにより、安く・速く・大規模に 評価が回せる。

ただし、評価する LLM 自身がハルシネーションする可能性、評価モデル間の偏りなど、新しい課題もある。

実務メモ

業務で LLM を導入するとき、「精度」を 1 つの数字で表現することは、ほぼ不可能。ユースケース固有の評価セット を自社で作るのが王道。 「自社の代表的な質問 100 件を作り、各応答を手動でチェック」── 地味だがこれが最強。

13.5 ハルシネーションを減らす実用テクニック

ハルシネーションを完全に消す方法は、本書執筆現在まだ存在しない。 だが、減らす ためのテクニックは色々ある：

対策①: RAG で外部情報を渡す（第11章）

LLM 単独で答えさせるのではなく、信頼できる外部知識を検索してプロンプトに含める。 「内蔵知識から思い出す」を「与えられた文章から読み取る」に変換できれば、ハルシネーションは大幅に減る。

対策②: 引用・根拠を強制する

プロンプトで「情報源を明示してください」「引用元を URL とともに示してください」と指示する。 完璧ではないが、LLM の応答が 検証可能な形 になる。

対策③: 「分からない」を許す

プロンプトで「確信が持てないことは『分かりません』と答えてください」と仕込む。 RLHF だけだと「自信満々に答える」傾向に流れがちなので、明示的に「分からない」を許す指示が効く。

対策④: 自己反省（Chain-of-Verification 等）

LLM に「自分の応答を見直して、確証のない部分を指摘してください」と二段で問う。 追加のコストはかかるが、LLM 自身に間違いを発見させる試み。

対策⑤: 範囲を狭める

「広い世界の知識」を聞くのではなく、「この文書の中だけ」のように 範囲を限定する とハルシネーションは激減する。 社内文書 Bot は、この性質を活用している。

ハルシネーションは「消す」よりも「管理する」発想で扱う。

  • 検証可能な形（引用付き、範囲限定、出力検査）にして、後から確認できるようにする
  • 高リスクな場面（法律、医療、金融）では、人間の確認をワークフローに組み込む
  • リスクとコストのバランスで「どこまで間違いを許容するか」をユースケースごとに設計する

13.6 「分からない」と言える AI へ ── 研究の最前線

ハルシネーション対策は、本書執筆現在も研究の最前線にある。

代表的な研究の方向性：

方向何を目指すか
Calibration（自己校正）LLM が出力に「自信度」を付けられるようにする。「これは 80% 確信、これは 30% 確信」と表現する
Tool Use（道具使用）計算や検索を 外部ツール に委ねる。LLM 単独で答えず、必要なツールを呼んで補強する
Constitutional AIモデル自身が「この応答は誇張気味だ」と気づき、修正する仕組み
Long-context LLM大量の文脈を直接読ませる（第11章末参照）
Mechanistic InterpretabilityLLM の内部状態を解析し、「機械がこれを知っているか」を直接覗き見る

特に「LLM が自分の自信度を正しく出せる」というのは、長年の難題だ。 2026 年現在も、これが完全に解けたとは言えない。

13.7 LLM を信頼するということ

ここまでで、LLM の 強力さ と 限界 の両方を見てきた。 最後に、LLM を実世界で使うときの 基本姿勢 を、本書からの提言として残したい。

LLM との付き合い方 — 本書からの提言

  1. 「次の単語予測」だと忘れない: LLM は真実を述べる機械ではない。確率的にもっともらしい文を生成する機械だ
  2. 流暢さを信頼の根拠にしない: 自信満々の口調と、内容の正しさは無関係
  3. 検証可能な形で使う: 引用・出典・範囲限定・人間レビューをワークフローに組み込む
  4. 得意・不得意を見極める: 翻訳・要約・コード生成は得意、固有名詞・最新情報・専門的正確性は不得意
  5. 大規模化に過度の期待をしない: 規模で多くは解けるが、ハルシネーションは構造的に残る

「賢い相談相手だが、時々もっともらしく嘘をつく」── これが LLM の正体だ。 人間関係と同じで、相手の 特性を踏まえた距離感 で付き合うのが、最善の使い方になる。

13.8 本書の旅を、ここで終える

第1章「言葉を単位に切る」から始まったこの本も、いよいよ最終章。 13 章にわたる旅を、一枚の地図にまとめておく。

[言葉を数にする]
 第1章: トークン化 ── 文字列を「単位」に切る
 第2章: 埋め込み ── トークンに座標を与える
 第3章: 文脈埋め込み ── 意味は文脈で動く

[系列を扱う]
 第4章: n-gram ── 単語の並びを確率で見る基本
 第5章: RNN/LSTM ── 内部状態に記憶を持つ

[注意機構と Transformer]
 第6章: Attention ── 全文を見渡して「どこに注目するか」を学ぶ
 第7章: Transformer ── Attention だけで作り直す。現代 LLM の土台

[大規模言語モデル]
 第8章: BERT ── 「読む」専門家、穴埋めで事前学習
 第9章: GPT ── 「書く」専門家、次トークン予測で事前学習
 第10章: Instruction Tuning + RLHF ── 指示に従い、人間に好まれる人格を仕込む

[応用と評価]
 第11章: RAG ── 外部知識を呼んでくる
 第12章: マルチモーダル ── 画像・音声も同じ枠で扱う
 第13章: ハルシネーションと評価 ── どう信頼するか ← 終着駅

序章で挙げた 三つの合言葉 を、もう一度思い出して締めよう：

  1. 「言葉を、どんな形の数にしているか?」
  2. 「学習の元ネタは何か?」
  3. 「次の単語予測だけで全部やる」

この 3 つを頭に持って、これから新しい NLP のニュース・論文・サービスに触れるとき、「ああ、これは本書の地図のここに位置する話だ」 と分かるはずだ。

ChatGPT、Claude、Gemini ── 名前は色々あれど、内側で起きているのは本書で見てきた話の延長だ。 規模が違っても、構造の本質は変わらない。

本書は、自然言語処理の 「現状の地図帳」 として書いた。 明日には新しいモデルが出るかもしれない。来年には新しい手法が主流になるかもしれない。 だが、「言葉を数にする」「系列を扱う」「Attention で関係を捉える」「次の単語予測で全部やる」 という背骨は、しばらく変わらないだろう。

ここを足場に、これからの NLP の動きを 「腑に落ちる形」 で追っていけるように、本書が役立てば嬉しい。

13.9 この章の振り返り

そして、本書全体の振り返り：

旅はここで終わる。 だが、自然言語処理の世界そのものは、まだ走り続けている。 本書がその風景を読み解く 地図 として、これからも役に立つことを願いたい。

それでは、楽しい NLP ライフを。