ハルシネーションの仕組み
ハルシネーション（hallucination、幻覚）は、AI が事実と異なる内容を、自然な文章でもっともらしく出力する現象です。OpenAI の Why language models hallucinateでは、これを「モデルの故障」ではなく「学習と評価の構造から生じる必然」として扱い、Anthropic も Mapping the Mind of a Large Language Modelなどの研究で、内部状態と誤認識のメカニズムを公開しています。
LLM は確率的にトークンを並べる装置なので、根拠なく自然な文章を作る能力と、誤情報を自然に作る能力は表裏一体です。ゼロにできない前提で、根拠の付与・出典表示・人間レビューを業務設計に組み込みます。
01.まず結論：ハルシネーションは仕組みから生じる必然
ハルシネーションを「AI の不具合」「モデルの欠陥」と捉えると、対策は「より高性能なモデルを待つ」になりがちです。しかし、LLM が確率的トークン予測器である限り、根拠の無い文章をもっともらしく作る能力は構造的に存在し続けます。
BtoB 実務で重要なのは、ハルシネーションを「ゼロにする」ではなく、「業務影響をゼロに近づける」設計です。本記事では、ハルシネーションの定義と原理を整理し、別記事の「AI 出力の品質管理」で扱う具体対策の前提を作ります。
02.ハルシネーションの4分類
「ハルシネーション」と一括りにすると対策が立てにくいので、出力のどこが誤っているかで 4 種類に分けて扱います。
| 分類 | 内容 | 例 | 対策の方向 |
|---|---|---|---|
| 事実誤認 | 数値・日付・固有名詞が違う | 「2023 年に発表」を「2022 年」と書く | 一次資料との照合 |
| 出典捏造 | 存在しない論文や URL を引用 | 実在しない URL を「公式情報」として出す | URL とその内容の二段確認 |
| 文脈誤認 | 自社条件や顧客状況に合わない一般論 | 業界平均で答えるが、実態は外れ値 | RAG で社内文脈を渡す |
| 責任誤認 | AI が断定してはいけない判断を断定 | 「この症状は◯◯病です」と医療助言 | 禁止事項の明示と承認フロー |
AI出力の品質管理｜ハルシネーション・出典確認・人間レビューの実務チェック
ハルシネーションを業務で抑える具体手順（出典確認・3 層レビュー・公開前チェックリスト）は別記事で整理しています。
03.なぜ起こるのか（発生原理）
確率的トークン予測の本質
LLM は「これまでの文脈に対して、次のトークンに何が来やすいか」を確率で予測します。事前学習で大量テキストの「自然な並び方」を学習しているため、根拠が無くても「もっともらしい順番でトークンを出す」ことは得意です。これは性能の裏返しで、「言い切る能力」と「もっともらしい誤情報を作る能力」は同じ仕組みから来ています。
LLM（大規模言語モデル）とは｜学習・トークン・コンテキストウィンドウ・推論の仕組み
LLM がトークン予測器であることの詳細は別記事で整理しています。あわせてご覧ください。
学習データの限界と陳腐化
LLM の知識は事前学習データの範囲に閉じています。学習データの中で多数派の表現が「らしさ」として強く学習されるため、(a) 少数派の正解が拾われない、(b) 学習日以降の新しい事実は知らない、(c) 社内固有情報は学習されていない、という限界があります。これらが揃うと、AI は「知らない」ではなく「もっともらしい推測」で穴を埋めようとします。
「分からない」より「推測」を選びやすい評価
OpenAI の研究は、ハルシネーションが起こる理由の 1 つに「評価方法そのもの」を挙げています。回答の正誤を採点する仕組みが「答えを出した方が部分点」になっていると、モデルは「分からない」と言うより「もっともらしく答える」を選びやすくなります。「分からない」が高く評価される設計でない限り、推測を抑える方向には学習されません。
現行の 推論モデル（Claude 4 系、GPT-5、Gemini 2.5 など）は、この点を意識して「分からないと答える」「根拠が無いときは答えを保留する」挙動を学習に組み込み始めていますが、ゼロにはなっていません。
04.なぜゼロにできないのか
ハルシネーションを完全にゼロにするためには、「事実かどうか」を内部で判定する仕組みが必要です。しかし、LLM の中身は確率予測器であり、「事実判定機」ではありません。RAG や検索で外部根拠を渡しても、その根拠を解釈する段階でまた確率予測が走るため、根拠とずれる出力（"根拠は正しいが要約が誤っている"）が起きえます。
| ゼロにできない理由 | なぜか | 対処の方向 |
|---|---|---|
| 確率的予測の宿命 | 「もっともらしさ」と「正しさ」は別軸 | 根拠提示と出典確認で代用する |
| 学習データの未網羅 | 全人類の最新事実を学習することは不可能 | 外部検索・RAG で動的補完 |
| ツール出力の解釈段階 | 正しい根拠でも、要約過程で誤情報が混じる | 出典との照合を人間が行う |
| 評価とインセンティブ | 推測を出す方が点を取りやすい構造 | 「分からない」を許容する運用ルール |
05.モデル進化でどれくらい減ってきたか
ハルシネーションはゼロにはなりませんが、モデルの進化で「同じ根拠文書を渡して要約させる」タスクの誤りは大きく減ってきました。Vectara の HHEM Leaderboard は、要約が元文書に含まれる事実へ忠実かを測る代表的な公開ベンチマークです。
短文要約タスクのハルシネーション率（Vectara HHEM Leaderboard）
短文要約タスクに限った推移です。長文・事実問答など他タスクの率はこの図には含みません。
出典: Vectara HHEM Leaderboard（短文要約タスク）。Vectara HHEM Leaderboard は 2023 年公開。2021 年の数値は同基準で遡及評価したリーダーボード上の参照値。
この図が示すのは短文要約タスクの改善です。人物・制度・契約条件の事実問答、社内資料をまたぐ判断、法務・医療・金融の助言では誤り方が変わります。モデル進化は品質向上の土台ですが、業務品質は「モデル + 根拠 + 評価 + 人間レビュー」で決まります。
06.結局、どうしたら品質が上がるのか
読者が実務でまずやるべきことは、ハルシネーションを「見抜く力」に頼るのではなく、誤りが残りにくい工程に変えることです。最小構成は、入力を具体化する、根拠を渡す、出力を構造化する、評価セットで測る、人間の承認点を置く、の 5 つです。
| 工程 | 具体策 | 品質が上がる理由 |
|---|---|---|
| 入力を具体化 | 目的・対象・禁止事項・参照資料・不明時の扱いを明記 | AI が推測で空白を埋める余地を減らす |
| 根拠を渡す | RAG、検索、社内資料、一次ソース URL を入力に含める | 学習データ外の最新情報・社内情報を補える |
| 出力を構造化 | 主張 / 根拠 / 要検証 / 不明点を分けて出させる | 自然な文章に誤りが紛れることを防ぐ |
| 評価セットで測る | 実案件 30〜100 件を固定し、モデル変更時に再評価する | 感覚ではなく誤り率・修正工数で改善を追える |
| 人間レビュー | 低リスクはサンプリング、高リスクは全件承認にする | 責任範囲・顧客影響・例外条件を人間が判断できる |
特に重要なのは、AI には「最終回答」ではなく「根拠付き下書き」と「要検証リスト」を出させることです。レビュー担当者は全文を漫然と読むのではなく、数字・日付・固有名詞・引用・権利・責任範囲だけを重点的に確認できます。人間レビューを「作成者 / 専門 / 公開責任者」の 3 層で組み立てる具体手順は、別記事の「AI 出力の品質管理」で図解付きで整理しています。
現実的に抑える4つの打ち手
ゼロにできない前提で、業務影響を最小化する 4 つの打ち手を組み合わせるのが現実的です。
| 打ち手 | 中身 | 単体で足りない理由 |
|---|---|---|
| 根拠を渡す | RAG・検索ツールで一次資料を文脈に入れる | 正しい根拠でも要約段階で誤情報が混じりうる |
| 出典を要求 | 出力に「どの文書のどこを根拠にしたか」を出させる | 出典の真偽は別途人間が確認する必要 |
| 確信度を表示 | 「分からない場合は分からないと答える」を明示 | 自然な誤情報は確信度が高く出ることがある |
| 人間レビュー | 重要決定の前に出典確認・担当者承認を挟む | 全件レビューはコスト面で続かない |
具体的な実装手順（出典確認の見方、人間レビューの 3 層、公開前チェックリスト）は、別記事の「AI 出力の品質管理」で整理しています。本記事は「なぜハルシネーションが起こるか」までの基礎で、対策はその記事をあわせてご覧ください。
07.よくある誤解
| 誤解 | 実際 | 現場での扱い方 |
|---|---|---|
| ハルシネーション ＝ AI の故障 | 確率的予測の仕組みから生じる必然 | 前提として品質管理を設計する |
| 高性能モデルにすれば消える | 減りはするが、ゼロにはならない | モデル選定だけで安全にしようとしない |
| RAG を入れればハルシネーションが無くなる | RAG でも要約段階で誤情報は混じりうる | 出典と出力の照合をセットで運用する |
| ハルシネーションは「嘘」 | 嘘は意図的、ハルシネーションは確率的副作用 | 意図ではなく確率的副作用として扱う |
| 見抜けば対策できる | 自然な文章なほど見抜きにくい | 「見抜く」より「根拠と承認で防ぐ」 |
08.よくある質問（FAQ）
ハルシネーションは「AIの嘘」ですか？
違います。嘘は意図を伴いますが、ハルシネーションは確率的トークン予測の副作用で、AI に意図はありません。設計判断としては「意図ではなく確率的に起こる現象」として扱い、根拠提示・人間レビュー・承認フローで業務リスクを抑えます。
ハルシネーションは将来ゼロになりますか？
確率予測の構造を変えない限り、完全にゼロにはなりません。推論モデル化や RAG 連携で頻度は減らせますが、ゼロにはなりません。BtoB の業務設計では、ゼロを前提にしないことが安全です。
RAG を使えばハルシネーションは消えますか？
減らせますが、消えません。RAG で正しい根拠を渡しても、その根拠を要約・解釈する段階で誤情報が混じる可能性があります。出典と出力の照合（人間レビューまたは自動チェック）を別途運用に組み込みます。
「temperature を下げる」だけで対策になりますか？
対策の一部にはなりますが、それだけでは不十分です。temperature を下げると出力の多様性は減りますが、確率予測の仕組みは変わらないため事実性は保証されません。根拠提示・出典確認・人間レビューと組み合わせて使います。
ハルシネーションが致命的になる業務は？
医療・法務・金融・契約・規程・顧客個別条件などの YMYL領域、および本番反映・顧客送信・支払い操作を伴う業務です。これらでは AI 出力を最終判断にせず、出典確認と人間承認をフローに必ず組み込みます。
09.まとめ
ハルシネーションは AI の故障ではなく、確率的トークン予測器という LLM の仕組みから生じる必然です。事実誤認・出典捏造・文脈誤認・責任誤認の 4 分類で扱うと、対策が立てやすくなります。
ゼロにはできない前提で、根拠の付与・出典表示・確信度の制御・人間レビューを組み合わせて業務影響を最小化するのが現在の主流です。高性能モデルへの置き換えだけで安全になるという発想は、過去の話として整理し、品質管理を業務プロセスに組み込むのが現実的です。
ハルシネーション対策を業務に組み込みませんか
AI 活用や AI エージェント導入のご相談、PoC、伴走支援をご検討の方は、お気軽にお問い合わせください。
