$ cd ../
$ cat post.metadata
LLM出力の検証 ①全体像 — 「もっともらしい嘘」をどう捕まえるか
date: 2026-06-26
LLM
ハルシネーション
考察
LLMの出力が「おかしなことを言っていないか」を検証したい。だが「おかしさ」を一枚岩で捉えると手法選びを誤る。第1回は全体像として、検証すべき失敗を5種類に分解し、手法を4系統の地図に落とす。そして「銀の弾丸は無い／多段防御で組む」という実装の勘所まで。
「LLM出力の検証」連載（全3回）
① 全体像（この記事）／
② 手法カタログ／
③ 実装編
①で地図を描き、②で各手法を棚卸しし、③で多段防御パイプラインを実際に組む、という流れ。
1. 「流暢さ」は「正しさ」ではない
LLMは、もっともらしい文章を淀みなく生成する。だがその流暢さは正しさを一切保証しない。一番厄介なのは、モデルが自信たっぷりに、しかし事実無根の内容を断定するケースだ。文体が完璧なぶん、人間のレビュアーほど騙されやすい。
遊びで使うぶんには笑い話で済む。しかし医療・金融・法務・カスタマーサポートのように誤情報のコストが高い領域では、放置すれば実害になる。だから「出力を生成して終わり」ではなく、「出力がまともかを検証する層」をプロダクトに組み込む必要がある。この連載は、その検証層をどう設計するかの地図帳だ。
この連載で「検証」と呼ぶもの
生成された出力に対して、
正しいか／根拠があるか／安全かを別の仕組みで判定し、怪しいものに
フラグを立てる・ブロックする・作り直す・人に回すこと。学習段階での幻覚低減（より良いモデルを作る話）ではなく、
すでに動いているモデルの出力をどう守るかに絞る。
2. まず「おかしさ」を5つに分解する
検証設計の出発点は、「おかしさ」を種類ごとに割ることだ。ここを混ぜると「ハルシネーション検知ツールを入れたのに事故が止まらない」になる。検知すべき失敗は、ざっくり5種類に分けられる。
| 「おかしさ」の型 | 中身 | 典型例 | 主に効く系統 |
|---|
事実誤認
Factuality | 世界知識に照らして客観的に誤り | 実在しない論文を引用、人物の経歴を捏造 | 検索照合・ファクトチェック |
文脈不忠実
Faithfulness | 与えた文脈・出典に支持されない主張（RAGで最重要） | 検索結果に無い数値を要約に混入 | NLI含意照合・RAG忠実性評価 |
自己矛盾
Confabulation | 同じ問いでも生成のたびに答えが発散・矛盾 | 同一質問に毎回違う固有名詞を返す | 自己一貫性・意味エントロピー |
指示逸脱
Instruction | フォーマット・スコープ・ルールから外れる | JSONが壊れる、禁止トピックに踏み込む | 構造化出力検証・ガードレール |
不適切
Unsafe | 有害・PII漏洩・規範逸脱・攻撃 | トキシック発言、機密漏洩、プロンプトインジェクション | モデレーション・ガードモデル |
重要なのは、これらが直交するということ。たとえば「事実は正しいが文脈には不忠実」（合っているけど与えた資料には書いていない）と、「文脈には忠実だが文脈自体が誤り」（資料どおりだが資料が間違っている）は別物だ。RAGの忠実性チェックは前者を捕まえるが、後者は素通しする。だから単一指標では足りない——これが連載全体を貫く前提になる。
3. 検証手法の全体地図 — 4つの系統
世の中の検証手法は数十あって最初は途方に暮れる。だが「何を根拠に正しさを測るか」で見ると、大きく4系統に整理できる。
図1: 検証手法の4系統。A→Bは「根拠を外部に持つか」の軸。CとDは別軸（誰が判定するか／いつ働くか）で、A・Bと組み合わせて使う。
4系統を一言ずつで言うと——
- A. リファレンス不要: 「本当に知っていることは何度聞いても一致するが、捏造は聞くたびにブレる」という仮説を使う。外部知識を用意できなくても動くのが強み。
- B. リファレンス有り: 検索結果や与えた文脈と照合する。RAGの「文脈不忠実」を捕まえる主力で、実運用ではここが最重要になりがち。
- C. ジャッジ系: 強いLLMに採点・批判させる。人手評価の自動化として最も普及していて、まず最初に試す価値が高い。
- D. 実行時ガードレール: 本番のI/Oを門番として検査する。形式崩れ・安全性・攻撃を止める「最後の砦」。
4. 手法選びを左右する2つの軸
地図の上でどの手法に手が届くかは、次の2軸でほぼ決まる。
軸1: ブラックボックス vs ホワイトボックス
モデルの内部が見えるかどうか。GPT・Claudeのような外部APIは、隠れ状態もattentionも取れない（せいぜいlogprob）。この場合、出力テキストだけで動く手法——SelfCheckGPT、verbalized confidence（モデルに確信度を言わせる）、LLM-as-judge——に限られる。一方、自社ホストのオープンウェイトモデルなら、隠れ状態やattentionを使う高精度かつ低コストな手法（後述のSEPやLookback Lens）が解禁される。「どのモデルを使うか」が「どう検証できるか」を縛る、というのは見落としやすい。
軸2: 検知 vs 予防
検証というと「出てきた出力を後から採点する（検知）」を思い浮かべるが、そもそも問題が出る量を減らす（予防）も設計に含めるべきだ。代表例がRAGのグラウンディング——回答を検証済みドキュメントに根拠づけ、言える主張を取得文脈に縛る。本番ではグラウンディング単体で幻覚を大きく減らせるという報告もあり、検知の前段で発生量そのものを削るのが定石になる。検知器をどれだけ磨いても、入口を絞るほうが安いことは多い。
5. 実装の勘所 — 銀の弾丸は無い、だから多段で組む
ここまでで察しがつくと思うが、「これ1つ入れれば安心」という手法は存在しない。高精度な手法はたいてい高価（出力1件に対してLLMを何度も叩く）で、安価な手法はすり抜けが多い。だから実務の答えは「1つを選ぶ」ではなく「安価なチェックから高価なチェックへ、段階的に絞り込む」——多段防御（cascade）になる。
図2: 多段防御の基本形。安価な段（①②）で全件を捌き、怪しいものだけを高価な段（③④）へエスカレーションする。研究例ではカスケード化で品質を保ちつつ大幅なコスト削減が報告されている。
この形にしておくと、大半のリクエストは安い段で片付き、高価なLLMジャッジや人手は本当に怪しいものにだけ使われる。コストとレイテンシを抑えながら品質を担保する、という相反する要求を両立させる唯一の現実解だ。第3回でこのパイプラインを具体的なコードに落とす。
第1回のまとめ
① 流暢さは正しさではない。検証層をプロダクトに組み込む。
② 「おかしさ」は
事実誤認／文脈不忠実／自己矛盾／指示逸脱／不適切の5種類。混ぜない。
③ 手法は
A 不要・B 有り・C ジャッジ・D ガードレールの4系統に整理できる。
④ 銀の弾丸は無い。
安価→高価の多段防御で組む。
次回
地図が描けたので、次は中身の棚卸し。第2回「手法カタログ」では、4系統それぞれの代表手法を——SelfCheckGPTから意味的エントロピー、RAGAS、MiniCheck、LLM-as-judge、Chain-of-Verification、Llama Guardまで——分類ツリーと比較表で整理し、「どれをいつ使うか」を判断できるところまで持っていく。
sue@blog ~ $ _