ハルシネーション対策とは？原因・RAG・評価指標・運用体制を実務解説

そもそもハルシネーションはなぜ起きるのか？

大規模言語モデル（LLM）は確率的に次の語を選ぶ。学習データの欠落、生成の性質、要求側の設計が重なると誤情報が生まれる。

ハルシネーションは「モデルが嘘をつく」現象ではない。次トークン予測という設計から必然的に生じる副作用に近い。AX（AI Transformation）の実装では、この前提を理解しないまま「精度の高いモデルに乗り換えれば解決する」と考える組織が少なくない。しかし、モデルを変えるだけで消える問題ではない。対策を設計する出発点は、原因を次の三つに分けて捉えることだ。

学習データの欠落と古さは何を招くのか？

学習時点にない事実や珍しい情報は、モデル内部で近い知識に置き換えられ、もっともらしい誤答として出てくる。

LLMは、学習データに含まれない社内規程、直近の法改正、個別顧客の契約条件などを「知らない」。それでも問われれば、統計的に近い一般論で穴を埋める。日本企業の実務でよく見るのは、法令名や省庁名が微妙にずれる誤りや、社内制度の名称が一般的な人事用語に置き換わる誤りだ。表面上は自然な日本語なので、レビュー担当者が読み飛ばしやすい。

確率的生成そのものが誤りを生むのはなぜか？

次トークン予測は「知らない」と黙る設計ではなく、空白を埋めるように文を続ける。そのため断定的な虚偽が出る。

とくに危険なのは、存在しない出典・条文番号・統計値が生成されるケースだ。書誌情報や数値は形式が決まっているため、モデルにとっては「それらしく作る」ことがたやすい。一方、読み手にとっては最も検証しにくい。OpenAI、Anthropic、Google、Microsoftをはじめとする主要な生成AI提供事業者は、利用規約や技術ドキュメントで「出力の正確性は保証されず、重要な用途では人間による確認が必要」という趣旨を明示している。これは免責の文言であると同時に、設計上の事実を宣言したものでもある。

プロンプトと評価設計が誤りを助長する場面は？

曖昧な指示、誤った前提を含む質問、正答を強く求める評価設計。この三つの場面でモデルは推測で答えやすくなる。

「〜について3つ挙げて」と個数を固定すると、根拠が2つしかなくても3つ目を捏造しやすい。同じように、社内評価で「回答率」だけをKPIにすると、棄権（「わからない」と答えること）が減点扱いになり、結果として誤答が増える。現場の実務者からは「評価指標を変えた途端に体感の誤答が減った」という声を聞くことがある。原因はモデル側だけでなく、要求する側の設計にも潜んでいる。

ハルシネーション対策は入力・生成・出力のどこで効くのか？

対策は入力（文脈の供給）・生成（制約）・出力（検証）の三層に分かれる。どれか一つでは足りず、組み合わせが要る。

一つの手法で誤情報をゼロにすることはできない。層ごとに得意な誤りの種類が違うため、リスクの高いユースケースほど複数の層を重ねるのが実務の定石である。

入力層で何を渡せば誤りが減るのか？

必要な一次情報を検索して文脈に載せる設計が中心になる。精度を左右するのは、渡す情報の鮮度と粒度だ。

入力層で起きる問題の多くは、生成AIではなく情報システムの問題である。社内文書が版管理されていない、廃止済みの規程が残っている、PDFがスキャン画像で本文を抽出できない——こうした状態でRAGを導入しても、モデルは古い規程を忠実に引用する。AX推進の初期フェーズでは、モデル選定よりナレッジの棚卸しに時間を割くほうが投資対効果が高い場面が多い。

生成層の制約はどこまで効くのか？

出力形式の固定、根拠の明示要求、「わからない」と答える許可。この三点が断定的な誤答を実務上かなり減らす。

具体的な設計は次の三つ。

1. 回答文とは別に、引用元の文書IDと該当箇所を必ず出力させる
2. 文脈内に根拠がなければ「提供資料には記載がありません」と返す方針を、システムプロンプトに明記する
3. JSONなどの構造化出力で必須フィールドを定義する

「棄権を許可する」だけで体感精度が変わることは多い。ただし、業務側が棄権を受け入れるかどうかは、運用ルールとして事前に合意しておく必要がある。

出力層の検証は自動化できるのか？

機械的に正誤を判定できる数値・日付・固有名詞・URLは自動化できる。解釈を伴う記述の確認は人間が担う。

正規表現や辞書との照合で「社内に存在しない部署名」「実在しないURL」「桁数がおかしい金額」を機械的にはじく仕組みは、比較的低コストで導入できる。一方、因果関係の記述や助言の妥当性は自動判定に向かない。ここは人間レビューに残す領域として、あらかじめ線を引いておく。

RAGでハルシネーションはどこまで減らせるのか？

RAGは知識の欠落による誤りに効く。ただし検索が外れれば誤りは残り、RAG特有の新しい失敗も持ち込まれる。

Retrieval-Augmented Generation（RAG）は、Lewisらが2020年にNeurIPS 2020で提案した枠組みで、外部知識を検索して生成時の文脈に与える手法である。企業のAX実装では事実上の標準構成になっている。しかし「RAGを入れたので誤情報の問題は解決した」という説明は正確ではない。

RAGが効く領域と効かない領域は？

社内規程や製品仕様など明文化された情報には強い。一方、暗黙知や文書化されていない判断、将来予測には効かない。

RAGで補えるのは「どこかに書いてある事実」の欠落である。営業現場の判断基準や、文書化されていない例外運用は検索対象に存在しないため、モデルは従来どおり推測で埋める。導入前に「その質問の答えは社内のどの文書に書かれているか」を業務側と洗い出しておくと、RAGで解ける範囲を現実的に見積もれる。

RAG特有の失敗はどこで起きるのか？

RAG導入後の誤りは、主に検索漏れ、チャンク分割による文脈の断裂、版の異なる文書の混在の三つから生じる。

実務者からは、RAGの精度改善の大半は検索側（インデックス設計とメタデータ）で決まり、プロンプト調整で取り返せる幅は思ったより小さい、という指摘が多い。ただし一般論として受け取るのではなく、自社データでの検証結果と突き合わせて判断したい。

引用の提示は利用者の誤読を防ぐのか？

根拠へのリンクを示すと利用者が自分で確かめやすくなり、誤情報が業務判断に流れ込む確率が下がる。

引用が表示されていれば、利用者は不自然な記述に気づいたときに原文へ戻れる。逆に、引用のない回答は検証できず、たとえ正しくても業務利用には向かない。「根拠を示せない回答は出さない」という方針を、UIとプロンプトの両方に反映させておくとよい。

ハルシネーションの発生率はどうやって測ればよいのか？

自社業務の質問セットに正解と根拠を用意し、事実整合率・根拠付与率・棄権率を継続して測るのが基本になる。

公開ベンチマークのスコアは、自社業務での精度を表さない。測るべきは「自社の業務質問に対する回答」だ。評価セットを作ること自体が、AX推進の重要な資産になる。

評価データセットはどう作るのか？

実際の問い合わせログから100〜300件を抜き出し、正解・根拠文書・棄権すべき質問を業務側と一緒に定義する。

作り方の手順は次のとおり。

1. 実利用ログまたは想定質問から、頻度と業務への影響が大きい質問を抜き出す
2. 各質問に「正解」と「根拠となる文書と該当箇所」を業務部門の担当者が付ける
3. 「社内に答えが存在しない質問」を意図的に1〜2割混ぜ、棄権できるかを測る
4. 曖昧な質問や前提が誤っている質問も含め、逆に質問し返せるかを確認する
5. モデル更新やインデックス変更のたびに同じセットで測り直し、差分を記録する

手順3の「答えが存在しない質問」を混ぜる設計は見落とされやすい。しかし棄権能力を測れるのはこの方法だけで、実務では最も重要な部分と言える。

どの指標を追えばよいのか？

事実整合率を主指標に置き、根拠付与率・棄権率・重大誤り率を副指標として組み合わせるのが扱いやすい。

全体の平均精度より、重大誤り率を件数で管理するほうが意思決定に使いやすい。業務部門と話すときは、「95%正しい」より「重大な誤りが月に何件出たか」のほうが通じやすい。

LLMによる自動採点は信用できるのか？

自動採点は変化の検知には役立つ。ただし判定基準が妥当かどうかは、人手の抜き取り確認で定期的に確かめる。

いわゆるLLM-as-a-judgeは、回答と根拠文の照合を機械的に回せる点で便利だ。ただし採点するモデルもハルシネーションを起こす。全件の10〜20%程度を人手で二重採点し、ずれが大きければ採点プロンプト自体を見直す。これが現実的な運用だろう。

運用と体制でハルシネーションをどう抑え込むのか？

技術的な対策だけではリスクが残る。用途別のレビュー水準・ログ・責任体制を制度として定める必要がある。

AX推進において、ハルシネーション対策はモデル担当者だけの課題ではない。誤情報が業務判断や顧客対応に流れ込む経路を、組織として断つ設計が求められる。

人間レビューはどこまで必要なのか？

用途のリスクに応じてレビュー水準を三段階ほどに分け、社外向けと法務・財務系は全件確認とするのが妥当である。

「AIが下書きし、人間が承認する」という役割分担を明文化しておくと、レビューが形だけになりにくい。逆に、レビュー担当者に十分な確認時間がなければ、承認は事実上の形式的な押印になる。これは制度設計より工数配分の問題であり、運用開始後に見直しが必要になることが多い。

ログとインシデント対応をどう設計するのか？

入力・出力・参照文書・利用者を紐づけて保存し、誤情報が見つかったときに影響範囲を追える状態にしておく。

保存すべきは回答テキストだけではない。どの文書のどのチャンクを参照したか、どのモデルのどのバージョンだったかもあわせて記録しておくと、誤りの原因が検索側か生成側かを切り分けられる。誤情報が社外に出た場合の報告経路・訂正手順・記録の保存期間も、通常のインシデント対応プロセスに組み込んでおきたい。

ガバナンス文書には何を書くべきか？

利用範囲・禁止用途・確認義務・責任の所在を定め、国内外のガイドラインに照らして矛盾がないか確かめる。

参照できる主な枠組みは次のとおり。

日本企業でも、EU域内向けのサービスを持つ場合はEU AI法の適用範囲を確認する必要がある。これらの文書は「ハルシネーションをゼロにせよ」とは求めていない。求めているのは、リスクを特定し、抑制策を講じ、その過程を説明できる状態を保つことだ。AX推進の現場では、この「説明できる状態」を作ることが、技術的な精度改善と同等以上に重要になる場面が多い。

どこから着手すべきか？

高リスク用途の棚卸しと評価セットの構築を先に済ませ、RAG整備と検証の自動化を段階的に重ねるのが現実的だ。

順序は次のようになる。

1. 用途を洗い出し、リスク区分を付ける
2. 評価セットを作り、現状値を測る
3. 入力層（ナレッジ整備・RAG）を改善する
4. 生成層の制約と棄権の設計を入れる
5. 出力層の自動検証を入れる
6. レビュー体制とログを制度化する

手順2を飛ばすと改善の効果が測れず、どの施策を残しどれをやめるかを判断できなくなる。測定の基盤を先に持つことが、結果として最短経路になることが多い。

参考にした一次情報

• NIST「Artificial Intelligence Risk Management Framework (AI RMF 1.0)」2023年1月
• ISO/IEC 42001:2023「Information technology — Artificial intelligence — Management system」2023年12月
• 総務省・経済産業省「AI事業者ガイドライン（第1.1版）」2025年3月（初版2024年4月）
• Regulation (EU) 2024/1689（EU AI法）2024年8月1日発効
• Lewis et al.「Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks」NeurIPS 2020

姉妹メディアの関連記事