エージェントは返金を確認し、チケットを解決済みとマークしました。しかし返金APIは一度も呼び出していません。流暢で、自信に満ちていて——そして行われなかったアクションについて完全に間違っていました。本ガイドの核心的な主張：LLMハルシネーションは排除できず、管理することしかできません——そして「ゼロハルシネーション」を売り込むベンダーはデモを売っているのです。
繰り返されるパターンがあります：チームがLLM機能を出荷し、本番でハルシネーションを含む回答を目にし、モデルを切り替えて対応します。3週間後、別のハルシネーション。次にプロンプトエンジニアリング。次にRAG。次に「ガードレール」製品。どのステップも進歩に感じられますが、どのステップも、ハルシネーションの予算も検出レイヤーも緩和ポリシーもないシステムの対症療法にすぎません。
本ガイドは別の主張をします：ハルシネーションは修正可能なバグではなく、管理されるリスクです。本番での答えは3層フレームワーク——検出、防止、緩和——であり、ハルシネーション率をスキャンダルではなくSLOのように扱うモニタリング予算を伴います。モデル切り替えだけでは失敗する理由を示すベンチマークデータ、コストを伴うフレームワークの各レイヤー、ガバナンスを具体的にする予算の数字、そして反論——「モデルを切り替えればいい」には本物の答えが必要だからです——を解説します。
なぜ3層フレームワークが銀の弾丸に勝るのか
要点：すべての一点集中型「ソリューション」——より良いモデル、より多くのプロンプティング、RAG——は1つの失敗クラスをカバーし、他をそのままにします。
根拠となるデータは公開されており、成長し続けています。Vectaraのハルシネーションリーダーボードのような独立系リーダーボードは要約ハルシネーションでモデルファミリーを測定し、Presencの2026年ベンチマーク研究はタスクタイプ横断でこの分野を追跡しています。データが一貫して示すこと：
- **ハルシネーション率はモデル依存ではなくタスク依存です。**要約で最もハルシネーションが少ないモデルが、コードや抽出では中位になることがあります。「最良のモデルに切り替えよう」は単一の最良モデルの存在を前提としますが、ベンチマークにはそんなものはありません。
- **モデル間の差は現実ですが、限定的です。**フロンティアモデル同士はほとんどのタスクで一桁台の差しかありません——低価格モデルとの差はそれより大きいです。モデル選択は率を動かしますが、ゼロにはしません。
- **ハルシネーションにはサブタイプがあり、それぞれ異なる対処が必要です。**ファブリケーション（事実を捏造する）、矛盾（会話の途中で事実を変える）、アクションハルシネーション（行われていないアクションが行われたと主張する）。RAGはファブリケーションの原因に対処しますが、アクションハルシネーションには何もできません。プロンプティングは文体エラーに対処しますが、事実の捏造には何もできません。
すべての銀の弾丸の失敗モードは同じです：1つのサブタイプを最適化し、モニタリングの死角をそのままにします——それが次のハルシネーションが驚きとしてやってくる理由です。
それが意味すること：検出、防止、緩和
要点：3つのレイヤー、それぞれに明確な役割と測定可能なコストがあります——そしてこれらのレイヤーはオプション機能ではなく、アーキテクチャそのものです。
**レイヤー1——検出。**見えないものは管理できません。検出オプションをコスト順に：サンプリングしたサブセットでのLLM-as-judge評価（最も安価で最も一般的）、専用のハルシネーション検出器、自己整合性チェック（2回生成して比較）、引用強制（ソースを要求して検証）。それぞれにレイテンシとコストのプロファイルがあり、サンプリング率が予算のダイヤルです。このレイヤーの背後にある評価規律は、ローンチ前だけではなく継続的に適用されるCIスタイルの評価です。
実際の判断を左右するトレードオフを含む4つのオプション：
| オプション | チェックする内容 | 追加レイテンシ | 追加コスト | 最適な用途 |
|---|---|---|---|---|
| LLM-as-judge（サンプリング） | タスクのルーブリックに対する出力 | オフライン、バッチ | 最低 | ほとんどの本番トラフィック |
| 専用検出器 | 事実整合性スコアリング | 10〜100ms | 低 | 要約パイプライン |
| 自己整合性 | 2回生成して比較 | 生成時間の2倍 | トークンが2倍 | 高リスクの単一回答 |
| 引用強制 | ソースが存在し一致するか | 検索＋検証 | 中 | グラウンディングされた機能 |
最もシンプルな本番形態のジャッジループ：
import random
import re
from openai import OpenAI
client = OpenAI()
SAMPLE_RATE = 0.05 # 5% of traffic; raise toward 1.0 for high-risk features
def maybe_judge(question: str, answer: str, rubric: str) -> float | None:
if random.random() > SAMPLE_RATE:
return None
verdict = client.chat.completions.create(
model="gpt-4o-mini",
messages=[{"role": "user", "content":
"Rate 0-10: is the answer factual per this rubric? "
"Reply with a single number.\n"
f"Rubric: {rubric}\nQ: {question}\nA: {answer}"}],
)
match = re.search(r"(\d+(?:\.\d+)?)", verdict.choices[0].message.content)
return float(match.group(1)) if match else None**レイヤー2——防止。**生成前に率を下げます：取得データやライブデータでのグラウンディング（本シリーズのグラウンディングガイドが実装を解説）、構造化出力モードでの制約付きデコーディング、コンテキスト衛生（送るものこそが矛盾の対象になる）、タスク・モデルマッチング（低価格モデルにクラスを超えた推論を求めない）。RAGが属するのは防止レイヤーです——事実探索の失敗クラスに対してのみです。
**レイヤー3——緩和。**間違った回答がどうしても出荷されてしまうとき（必ずあります）、システムはグレースフルデグラデーションを行う必要があります。拒否経路付きの信頼度スコアリング、2番目のモデルや人間へのフォールバックチェーン（カスタムルーティングがフォールバックを設定にします）、そして検出された失敗をevalセットにフィードバックするループ。緩和は、ハルシネーションをインシデントからテレメトリポイントに変えるレイヤーです。
本番予算にとっての意味
要点：ガバナンスはポリシーではなく予算です——サンプリング率、しきい値、アラートがフレームワークを具体的にし、CFOも満足させます。
フレームワークの運用面での解釈：
- **リスク別のサンプリング率。**低リスク機能（要約、分類）：トラフィックの1〜5%をジャッジベースの検出用にサンプリングします。高リスク機能（医療、法務、金融、エージェントアクション）：100%、可能な場合はリクエストごとの引用チェック付き。サンプリング率がコストのダイヤルです——検出が安いのはまさにサンプリングだからです。
- **しきい値とアラート。**機能ごとにハルシネーション率のSLOを定義します（数値はタスクとリスククラスに依存します——リーダーボードが達成可能な水準のリファレンスです）。個々の悪い回答ではなく率でアラートします。個々の回答はフィードバックループ用です。
- ガバナンスのインプットとしてのモデル選択。モデルカタログとベンチマークデータが一体となって、ガバナンスの出発点となるベース率を決めます——タスクに合った選択は最も安価な防止レイヤーであり、他のすべてと複利のように効きます。
予算の形状：5%サンプリングでの検出は、通常API請求に一桁台のパーセントを追加します。防止は生成時には何も追加しません（グラウンディングとルーティングは設定です）。緩和は、拒否やフォールバックがたまに発生するコストです。ガバナンスはLLMスタックで最も安価な信頼性投資の1つです——本番最適化ドキュメントが周辺スタックを解説しています——だからこそ、その不在がこれほど目立つのです。
**具体的な予算例。**フロンティアティアで1日100,000回の呼び出しがある機能を想定します。ジャッジベース検出用に5%をサンプリング：5,000回のジャッジ呼び出し、それぞれメイン呼び出しの約5分の1のコスト——フルレートの可視性のために請求に約1%追加されます。SLOはevalセットベースラインのp90に設定します（例：「直近1週間のハルシネーション率3%未満」）、そして直近の率がそれを超えたらアラートします。高リスクのエージェントアクション機能は100%サンプリングとより厳しいSLOを正当化します。サンプリングのダイヤルこそ、わずかなコストと引き換えに確信を得る方法です。
反論：「モデルを切り替えればいい」とその他の神話
要点：4つのよく聞く答え——どれもデータの裏付けに穴があります。
- **「フラッグシップモデルに切り替える」。**リーダーボードは、フラッグシップがすべてのタスクで最良ではないことを示しています——そしてフラッグシップの率は、低いとはいえ依然としてゼロではありません。モデル切り替えはベース率を動かしますが、検出と緩和の必要性を取り除きません。
- **「RAGで解決する」。**RAGは検索に基づく事実に対処します。アクションハルシネーションには触れず、コーパス自体が間違っている場合には役に立たず、独自の失敗クラス——もっともらしい間違ったチャンクの検索——を導入します。当社のRAGガイドが両側面を解説しています。
- **「プロンプトエンジニアリングで直る」。**プロンプトは文体と構造を形作るものであって、事実性ではありません。プロンプトエンジニアリングガイドは境界を明確にしています：より良いプロンプトは出力をよりきれいにしますが、より真実にはしません。
- **「率が低いからモニタリングは不要」。**低い率×大量のボリューム＝確実なインシデント。1日10,000回の呼び出しで99.5%の正確性は、1日50件の間違った回答です——そして「率が低い」という主張こそ、検証のためにモニタリングを必要とするものです。
FAQ
ハルシネーションを完全に排除できますか？
いいえ——そしてゼロハルシネーションを主張するベンダーはデモを説明しているのです。本番の目標は管理された率です：検出し、可能な限り防止し、出荷されたら緩和する。本ガイドのフレームワークが、そのガバナンスの構築方法です。
どのモデルが最もハルシネーションが少ないですか？
リーダーボードによればタスク依存です——要約のリーダーが必ずしもコードのリーダーとは限りません。タスクごとに選択し、自社のデータで自社のevalセットを使って検証しましょう。重要なのはあなたのタスク分布だからです。
ハルシネーション検出のコストはいくらですか？
LLM-as-judgeで5%サンプリングの場合、検出は通常API請求に一桁台のパーセントを追加します。100%サンプリングの高リスク機能はより高コストです——しかしそれはリスククラスの代償であり、インシデントのコストよりは安いのです。
RAGはハルシネーションを止めますか？
事実探索の失敗クラス——既知のコーパスに基づくグラウンディングされた回答——に対処します。アクションハルシネーションやコーパス由来のエラーは止められず、検索は独自の失敗モードを導入します。銀の弾丸ではなく防止レイヤーです。
現実的なハルシネーション率のSLOは？
自社のevalセットと、タスククラスに対応する公開リーダーボードから設定しましょう——検出を導入すれば、ほとんどの本番タスクで一桁台は達成可能です。それ以下の数字はモデルの性質ではなくガバナンス上の決定です。
アクションハルシネーションは具体的にどう検出しますか？
テキストではなくアクションを検証することで検出します：ツール呼び出しが実際に実行されたか、状態が主張どおりに変化したかを確認します。テキストベースのジャッジはアクションを見ることができません——エージェントフレームワークの実行ログがこのサブタイプの検出レイヤーです。
まとめ
LLMハルシネーションは管理されるリスクです：サンプリングによる検出、グラウンディングとタスクマッチングによる防止、拒否とフォールバックによる緩和——そしてガバナンスを具体的にするモニタリング予算。モデル切り替えはベース率を動かします。フレームワークこそがハルシネーションをインシデントからテレメトリポイントに変えるものです。レイヤーを構築し、SLOを設定すれば、次のハルシネーションは驚きではなくデータポイントになります。
このフレームワークをブックマークしておきましょう——独自のハルシネーションSLOを設定するとき、リンクしたリーダーボードがリファレンスになり、evalセットが判定役になります。新しいモデルファミリーが登場するたびに、ベンチマークデータの四半期ごとの更新を当社のブログでチェックしてください。そのフレームワークこそ、議論を運用可能なダッシュボードに変えるものです。