ハルシネーション対策｜LLMの誤回答を減らす実装と運用設計

ハルシネーションとは｜4つの型と起きる理由

結論として、ハルシネーションは単一の現象ではありません。原因が違う4つの型が「それらしい誤り」という見た目でひとまとめにされています。型を分けないと、効かない対策に工数を払うことになります。

定義と、よくある誤解

ハルシネーション（hallucination）とは、モデルが事実と異なる内容を、確信のある文体で出力することを指します。文法的には自然で、口調も断定的です。だからこそ読み手が見逃します。

よくある誤解は「モデルが壊れている」という捉え方です。実際には、次の語を予測するという仕組みが正しく働いた結果として誤りが出ます。バグではなく、確率的な生成の副産物です。

4つの型

RAGで下がるのは中心的には①と④です。②はRAGを入れても残りやすく、むしろRAG構成でこそ問題になります。検索で正しい文書を引けていても、安心はできません。生成段階で内部知識が混ざると、資料にない一文が入るからです。③はRAG単体ではほぼ解決せず、出力形式の制約で潰します。

ただし、検索の絞り込みや参照範囲の設計を詰めれば②の混入率も下がります。層の切り分けは責任範囲の整理であって、排他的な分担ではありません。

この分け方が実装判断に効きます。「RAGを入れたのに誤回答が減らない」という相談の多くは、②や③を①の対策で止めようとしている状態です。

RAGそのものの仕組みと導入判断はRAGとは？仕組み・活用事例・導入メリットをわかりやすく解説で扱っています。本記事は、RAGを入れた後に残る誤りをどう潰すかに絞ります。

なぜ完全には消せないのか

OpenAIの研究者らによる論文「Why Language Models Hallucinate」（arXiv:2509.04664、2025年9月公開のプレプリント）は、ハルシネーションを神秘的な現象ではなく二値分類の誤りとして説明できると述べています。あわせて、標準的な学習・評価の手続きが「不確実性を認めること」よりも「推測すること」に報酬を与えている点を指摘しています。査読前の論文ですが、評価設計と出力の関係を考えるうえでの出発点になります。

実装者にとっての含意は明快です。多くの評価設定では無回答を減点し、当てずっぽうを部分点として拾うため、モデルは黙るより推測するほうが得をします。つまり「わからない」と言わせたいなら、こちらの設計でそれを許し、評価でも減点しない必要があります。

ここを踏まえずに「絶対に間違えないで」とプロンプトへ書き足しても、効果は限定的です。

ミニFAQ：モデルを新しい世代に上げれば解決しますか。

モデル更新で誤答の量が下がる報告は出ていますが、質が変わるため同じ対策が効くとは限りません。型②の混入が減る一方で、長い文脈での指示逸脱が増えるといった入れ替わりが起きます。更新時は必ず同じ評価セットを通し、型別に比較してください。

対策の全体像｜入力・生成・出力の3層で分担する

対策は3層に分けて責任を持たせます。どの層でも100%は取れないので、層ごとに「ここまで」を決めて積むという考え方です。

この表の要点はコストの置き場所です。入力層はデータ整備に人手が要り、出力層は1リクエストあたりの費用と待ち時間が増えます。生成層は最も安いので、まずここを埋めてから上下に広げるのが実務的な順番になります。

逆に、いきなり出力層の判定APIから入れると、効果が見えないまま推論コストだけ倍増しがちです。

第1層：入力側のグラウンディング設計

結論として、入力層の仕事は「モデルに推測させる余地を物理的に減らすこと」です。渡していない話を禁止するのではなく、答えに必要な材料を確実に渡す方向で設計します。

参照先を限定し、根拠を識別子で持つ

グラウンディングの基本は、回答の根拠を特定のデータソースに閉じることです。主要クラウドでも、名称や適用範囲は異なりますが、近い考え方の機能が提供されています。

• Google CloudはVertex AI のグラウンディングとして、自社データや検索結果に基づく生成をサポートしています

• AWSはAmazon Bedrock Guardrails の contextual grounding checkで、応答が参照元に基づいているかを判定できます

いずれも対応ユースケースや利用条件が定められており、更新も入ります。採用を決める前に、各社の最新ドキュメントで自分の構成が対象に入るかを確認してください。

実装上の勘所は、渡す文書に必ず識別子を振ることです。チャンクごとにIDを持たせ、そのIDを回答に引用させます。識別子がないと、後段の検証で「どの文のどこが根拠か」を機械的に突き合わせられません。

検索品質がそのまま誤答率になる

入力層で最も効くのは、実は検索の精度です。関連文書を引けていなければ、どれだけ生成を縛っても答えようがありません。そしてモデルは、材料が足りないときほど埋めにきます。

ここで測るべきは検索側と生成側を分けた指標です。総合スコア1本では、検索が悪いのか生成が悪いのか切り分けられません。指標の選び方と計測手順はRAGの評価方法｜Ragasの評価指標とボトルネック特定・精度改善にまとめてあります。

文書構造が複雑でチャンク分割だけでは関係性を保てない場合は、GraphRAGとは｜通常RAGとの違い・仕組み・構築案件の実務の構成も選択肢になります。

「資料にない」をどう扱うかを先に決める

取りこぼしが起きたとき、システムが何を返すかを事前に定義します。選択肢は3つです。

1. 「提供資料では確認できません」と明示して終える

2. 確認できない旨を伝えたうえで、近い内容の文書を提示する

3. 有人窓口・問い合わせ先へ引き渡す

このとき大事なのは、無回答を失敗として扱わないことです。前述のとおり、推測を報酬にする評価設計がハルシネーションの温床になります。社内の受け入れ基準でも「答えられなかった件数」をKPIの減点項目にしないでください。代わりに「誤った断定の件数」を見ます。

データの鮮度を運用に組み込む

型④（陳腐化）は、仕組みではなく運用で潰します。ソース文書に最終更新日を持たせ、一定期間を過ぎた文書は回答時に注記するか、検索対象から外します。

更新頻度の目安は対象によって大きく変わります。製品仕様や料金表のように改訂が入るものは、改訂のたびに同期する運用を前提にしてください。月次バッチだけで回すと、改訂直後の数週間が事故の窓になります。

第2層：生成側の出力制御

結論として、生成層は比較的低コストで効果を出しやすい層です。追加の推論が不要で、プロンプトとAPIパラメータだけで型②③にかなり効きます。

出典の明示を必須にする

回答文の各主張に、根拠となったチャンクIDを付けさせます。「参考：文書3」のような付け方ではなく、文単位で対応づけるのが望ましい形です。

効果は二重にあります。まず、引用を義務づけると資料にない主張を書きにくくなります。次に、後段の検証で「引用IDが実在するか」「引用先に本当にその記述があるか」を機械的に確認できます。

引用が空になった場合の挙動も決めておきます。引用ゼロの回答はそのまま返さず、無回答に落とすか人手レビューへ回す構成が扱いやすいです。

構造化出力でフォーマットを縛る

型③（指示逸脱）は、自然言語の指示ではなくスキーマで止めます。OpenAI APIのStructured Outputsのように、出力をJSONスキーマに適合させる機能が各社から提供されています。

出力オブジェクトに持たせると扱いやすい項目は次の3つです。

• answer：回答の本文

• citations：引用した文書IDの配列（空配列を許容する）

• answerable：資料から回答可能かどうかの真偽値

answerable を独立したフィールドで返させると、本文の文言を正規表現で判定するような脆い実装を避けられます。文面の揺れに依存しないので、プロンプトを変えても後段が壊れません。

プロンプト側の設計そのものを体系立てて詰めたい場合は、コンテキストエンジニアリングとは｜プロンプトとの違いと実務が参考になります。

不確実なら黙る、を許可する

「知らない場合は知らないと答えてよい」と明示的に許可を与えます。さらに、判断に迷ったときの優先順位まで書くと挙動が安定します。たとえば「推測した有用な回答より、確認できないという回答を優先する」といった順序づけです。

confidence のような自己申告スコアを出させる方法もあります。ただし自己申告の値は実際の正答率と一致しないことが多く、単独では信用できません。使うなら、後段の判定スコアと組み合わせて参考値に留めます。

生成パラメータは控えめに

事実回答の用途では、temperature を低めに設定するのが基本です。ただし下げすぎると表現が硬直し、要約タスクでは読みにくくなります。

出力の最大長を適切に絞ることにも意味があります。長く書ける余地があるほど、資料にない補足で埋めにいく傾向が出ます。短く答えさせるだけで型②が減るケースは珍しくありません。

ミニFAQ：プロンプトに「ハルシネーションしないで」と書くのは効きますか。

単独ではほとんど効きません。モデルは自分の誤りを認識していないため、禁止の指示が発火しないからです。効くのは「引用IDを必ず付ける」「資料にない場合は answerable を false にする」のように、検証可能な行動を指定する書き方です。

第3層：出力側の自動検証と人の確認

結論として、出力層は「残りを捕まえる網」です。ここで全部を止めようとすると、コストと待ち時間が見合わなくなります。

グラウンディング判定を使う

応答が参照元に基づいているかを判定する機能が、各クラウドから提供されています。MicrosoftはAzure AI Content Safety のグラウンデッド性の検出として、ソース資料に基づかない出力の検出を提供しています。AWSの contextual grounding check も同系統です。

これらを入れるときの手順には、順番があります。

1. まず検知のみで動かし、ブロックはしない

2. 1〜2週間ほど実トラフィックのスコア分布をログに貯める

3. 誤検知（正しい回答がブロックされる率）と見逃しの両方を見て閾値を決める

4. 閾値を適用し、遮断または人手レビューへの振り分けを有効化する

いきなり既定値で遮断を有効にすると、正常な回答まで止まって現場の信頼を失います。閾値は提供元の推奨値を出発点にしつつ、最終的には自分のデータで調整するのが基本です。

ルールベースの検証も併用する

判定APIだけに頼らず、安く確実に取れるものは機械的に潰します。

• 引用IDが実在するか（存在しないIDを引けば捏造確定）

• 引用先のチャンクに、回答中の数値が実際に含まれるか

• 固有名詞・金額・日付が参照文書に出現するか

• 出力がスキーマに適合しているか

特に数値の照合は費用対効果が高い検査です。金額や件数は読み手が最も信用する部分であり、同時にモデルが最も混ぜやすい部分でもあります。

人手確認をどこに置くか

全件レビューは現実的ではないので、条件を絞ります。置き場所の候補は次のとおりです。

• グラウンディング判定が閾値を下回った応答

• 引用ゼロ、または引用先と数値が一致しなかった応答

• 金額・契約・医療など、誤りの損害が大きい領域の質問

• 外部の顧客に直接返す経路（社内向けより基準を上げる）

経済産業省・総務省のAI事業者ガイドライン（第1.2版）は、2026年3月31日に公表された執筆時点での最新版で、人間による関与のあり方に触れています。どこまで自動化し、どこで人が確認するかは、システムの用途と影響度に応じて設計するという整理です。改定が入る文書のため、運用時は経済産業省・総務省の公開ページで最新版を確認してください。設計根拠として参照しておくと、顧客側の説明もしやすくなります。

なお、悪意ある入力によって指示を乗っ取られるプロンプトインジェクションは、ハルシネーションとは別の問題です。対策も別系統になるため、プロンプトインジェクション対策｜LLMアプリのセキュリティ実装ガイドを併せて確認してください。攻撃者視点での検証を外部に依頼する場合はAIレッドチーミング・LLMセキュリティ診断案件｜単価と必要スキルが参考になります。

運用設計｜閾値・ログ・回帰のまわし方

結論を先に書くと、ハルシネーション対策はリリースして終わる作業ではありません。文書が増え、モデルが更新され、質問の傾向が変われば、誤答の出方も変わります。

何をログに残すか

後から再現できない事象は改善できません。最低限、次の組み合わせを紐づけて保存します。

• 入力された質問文

• 検索でヒットしたチャンクのIDとスコア

• 実際にモデルへ渡したプロンプト

• 出力本文と引用ID

• 各検証の判定結果とスコア

• モデル名とバージョン、主要なパラメータ

モデル名とバージョンを残していないと、更新後に「いつから増えたのか」が追えなくなります。地味ですが、ここを落としている構成はかなり見かけます。

誤答の受付経路を作る

利用者が「これは違う」と押せるボタンを置き、該当の実行IDと紐づけて記録します。報告が来たら、その質問を評価セットへ追加します。

この循環が回り始めると、評価セットが実際の失敗パターンで埋まっていきます。合成した質問を並べるより、はるかに実効性があります。

回帰は小さく、毎週

週次で回す前提の初期セットとしては、30〜50問程度から始めます。対象ドメインの質問の幅によって適正な件数は変わるため、あくまで小規模な初期運用での出発点です。件数より、毎週同じものを回し続けられることを優先します。数百問を用意しても、実行が重くて月1回になれば劣化の検知が遅れます。

回すタイミングを決めておきます。文書ソースの大きな更新時、プロンプトの変更時、モデルの更新時の3つは必ず通します。指標の設計とツールの選択はLLM評価（Evals）とは｜LLM-as-a-Judgeと品質保証の実務まで解説で詳しく扱っています。Faithfulness のように「与えた文脈に忠実か」を測る指標は、Ragas の faithfulness 指標の定義が実装の出発点になります。

残存リスクの引き受け先を決める

どれだけ積んでも誤りはゼロになりません。だからこそ、残った誤りを誰が引き受けるかを要件定義の段階で合意します。

• 画面上で「AIが生成した内容であり、重要な判断の前に原典を確認してください」と明示する

• 原典へのリンクを常に併記し、読み手が自分で確かめられるようにする

• 誤りが見つかったときの訂正フローと連絡先を用意する

この合意がないまま本番に出すと、最初の誤答でプロジェクトごと止まります。技術的な対策と同じくらい、ここの握りが効きます。

用途別の設計パターン

用途によって、許容できる誤りの量と待ち時間が違います。同じ構成を使い回さず、振り分けます。

社内ナレッジQA

社内規程や手順書への質問です。誤答の損害は中程度で、利用者が内容をある程度判断できます。

出典必須化と引用の実在チェックまでを入れ、判定APIは質問の種類で絞って使うのが現実的です。全件に重い検証をかけるより、原典リンクを目立たせて利用者の確認を促すほうが費用対効果が出ます。

顧客向けチャット

外部に直接返るため、基準を一段上げます。回答できる範囲をあらかじめ狭く定義し、範囲外は有人へ引き渡します。

グラウンディング判定は遮断に使い、閾値を下回った応答は返さない構成が無難です。範囲を広げたい誘惑はありますが、答えられる範囲を狭く保つことが最大の対策になります。

文書要約・議事録

要約では型②が出やすくなります。原文にない一般論や、それらしい結論が足されるためです。

対策は、要約文の各文に原文の該当箇所を対応づけさせることです。対応づけられない文を削るだけで、品質が目に見えて変わります。文字数の上限を厳しめに設定するのも効きます。

コード生成・エージェント

存在しないメソッドやライブラリを提示する型①が典型です。幸い、コードは実行して確かめられます。

生成物を実際に動かす、型チェックを通す、テストを走らせるといった検証を自動化しておけば、誤りの大半は本番前に落ちます。自動テストの作り方と限界はAIテスト自動化の実務｜生成AIで単体・E2Eテストを作る手順と限界にまとめてあります。

複数ステップを自律的に進めるエージェント構成では、途中の誤りが後段に伝播します。ステップごとに検証を挟む設計が前提になります。

よくある失敗と対策

RAGを入れたから大丈夫だと考える

最も頻出するパターンです。RAGが効くのは型①と④であり、型②（資料にない内容の混入）はRAG構成でこそ発生します。導入後に必ず型別の内訳を取ってください。

単一の「ハルシネーション率」で追う

型をまとめて1つの数字にすると、改善が止まります。捏造が減っても指示逸脱が増えれば合計は横ばいに見えるからです。少なくとも「引用の実在率」「資料外内容の混入率」「形式違反率」の3つは分けて測ります。

出典を表示して満足する

引用を出すだけでは不十分です。引用先に本当にその記述があるかを検証しなければ、もっともらしい引用が付いた誤答という最悪の形になります。読み手の警戒心を下げるぶん、むしろ危険です。

閾値を決めずに検知を有効化する

既定値のまま遮断を有効にして、正常な回答が止まる事故が起きます。検知のみの期間を設け、自分のデータで分布を見てから決めてください。

評価セットを作って放置する

最初に作った評価セットが、半年後も同じ内容で回っている状態です。実際の失敗報告を継ぎ足し続けないと、現場の課題と乖離していきます。

文書側の矛盾を放置する

見落とされがちですが、参照する文書そのものが矛盾していれば、モデルは正しく答えようがありません。旧版と新版の規程が両方検索対象に入っている、といった状態は珍しくありません。誤答を調べたら原因が文書側だった、というケースは実際にあります。

実装チェックリスト

着手前と本番投入前に通す項目です。型と層の対応を意識して並べてあります。

ハルシネーション対策の経験は案件でどう見られるか

結論として、評価されるのは「対策を知っていること」ではなく、誤答率を下げた手順と数字を説明できることです。

首都圏中心の主要フリーランスエージェント数社の公開案件と募集要件を見る限りでは、PoCから本番運用へ移る段階の募集で、精度の作り込みと運用設計に触れる要件が見られます。公開案件ベースでは社内規程QAや問い合わせ対応といった用途が比較的目立ち、実装そのものより「どの指標をどこまで改善したか」を問われる場面が多くなります。

スキルシートに書くなら、使用したフレームワーク名を並べるより、評価セットの規模・測った指標・改善前後の数値・要した期間を書くほうが通ります。定量表現の作り方はデータ・AIエンジニアのスキルシートの書き方｜モデル精度と基盤規模の定量表現で整理しています。

隣接する案件領域の単価感や参画ルートは、それぞれの記事にまとめてあります。社内LLM導入案件とは｜構成・要件・単価とフリーランスの参画実務、RAG構築案件の実情｜単価相場・必要スキル・獲得方法、LLM評価・データアノテーション案件｜単価相場と参入ルートを参照してください。

いまの経験でどの程度の単価を狙えるか確かめたい方は、無料のフリーランスエンジニア単価診断で市場単価の目安を確認できます。案件を直接見たい場合はフリコンの案件一覧から探せます。

まとめ

ハルシネーションは消すものではなく、型ごとに減らして残りを捕まえるものです。RAGで下がるのは4類型のうち2つだけで、残りは生成層と出力層で潰します。

• 4つの型（事実捏造・文脈逸脱・指示逸脱・陳腐化）を分けて測る。合計値だけ見ない

• 層は入力・生成・出力の3つ。最も安い生成層（引用必須化・スキーマ拘束・無回答の許可）から着手する

• 出典は表示するだけでなく、引用先の実在と数値一致まで検証する

• 検知系は1〜2週間の検知のみ運用を挟み、自分のデータで閾値を決める

• 評価セットは週次運用の初期セットなら30〜50問から始め、回し続ける。実際の誤答報告を継ぎ足す

• 残存リスクの引き受け先（注記・原典リンク・訂正フロー）を要件定義で合意しておく

次の一歩としては、いま動いているシステムのログから誤答を20件ほど拾い、4類型に振り分けてみてください。どの層が手薄かが、その時点ではっきりします。

参照した一次情報は以下のとおりです。

• Why Language Models Hallucinate（arXiv:2509.04664）

• Amazon Bedrock Guardrails｜contextual grounding check

• Azure AI Content Safety｜グラウンデッド性の検出

• Vertex AI｜グラウンディングの概要

• OpenAI API｜Structured Outputs

• Ragas｜Faithfulness

• AI事業者ガイドライン（第1.2版）概要｜経済産業省・総務省