--- title: "AIハルシネーション対策｜プロンプト・RAG・検出APIで誤答を減らす実装手順" url: "https://www.issoh.co.jp/tech/details/8017/" published: 2025-08-04 updated: 2026-09-27 categories: ["LLM・RAG"] publisher: "株式会社一創" --- # AIハルシネーション対策｜プロンプト・RAG・検出APIで誤答を減らす実装手順 AIのハルシネーション対策は「気をつける」では回りません。指示文の書き方、根拠文書への接地、出力の検証、そして計測。この4つを別々の仕組みとして積む作業です。しかも積んでも誤答はゼロになりません。ここでは各レイヤーで実際に何を設定するのか、どのAPI機能が使えるのか、どこまで下げれば実用かを、公式ドキュメントと計測結果に基づいて整理します。ハルシネーションの定義・種類・発生メカニズムそのものは[AIにおけるハルシネーションとは？基本概念と種類の解説](/tech/details/4472/)で扱っているため、本記事は対策の実装に絞ります。 ## まとめ - 対策は4層。**指示文（棄権を許す）→ 外部ソース参照（根拠に接地）→ 検証（引用の強制・自動検出）→ 計測（幻覚率の監視）**の順に積む。 - プロンプトで最も効くのは「わからないと答えてよい」と**信頼度のしきい値を数値で明示する**こと。根拠がない話題を無理に埋めさせない。 - RAGや検索接地は誤答を減らすが消しはしない。根拠文書を与えた要約タスクでも、2026年5月時点の最良モデルで幻覚率1.8%が残る。 - 「ゼロにする」ではなく**「率を下げ、残りを検知して人が止める」**設計にする。誤答が通ると何が起きるかで、人手確認の厚みを決める。 - ファインチューニングで事実誤りを直すのは筋が悪い。新しい知識を追加学習させると、幻覚はむしろ増えることが実証されている。 ## ハルシネーション対策の全体像と優先順位 ### 4つのレイヤーと着手順 | レイヤー | 設定内容 | 導入コスト | 効果 | | ----------- | -------------- | ----- | --------- | | 1\. 指示文 | 棄権許可・しきい値・形式固定 | 低 | 即日・全用途 | | 2\. 外部ソース参照 | RAG・検索接地 | 中 | 社内知識・最新情報 | | 3\. 検証 | 引用強制・自動検出 | 中 | 誤答の検知 | | 4\. 計測 | 幻覚率の定点観測 | 中 | 劣化の早期発見 | 上から順に効率がよく、1と2だけでも大半の業務用途は成立します。3と4は、誤答が金銭や信用に直結する用途（見積、法務、医療、顧客回答）で必要になります。逆に社内の下書き生成のように人が必ず読み直す工程では、3・4に投資しても回収できません。 ### 「ゼロ化」を目標にしない理由と残存する幻覚率 Vectaraが公開しているハルシネーション・リーダーボード（2026年5月11日更新、評価モデルHHEM-2.3）は、短い文書を渡して要約させ、元文書と矛盾する記述が出た割合を測っています。**根拠となる文書を目の前に与えているにもかかわらず**、最上位のantgroup/finix\_s1\_32bで1.8%、openai/gpt-5.4-nano-2026-03-17で3.1%、google/gemini-2.5-flash-liteで3.3%の幻覚が残ります。 この数字の意味は明確です。RAGを組んでも100件に2〜3件は根拠から外れた文が混じる。だから対策の目標は撲滅ではなく、率を下げたうえで残りを検知する経路を作ることになります。 ## プロンプトによる抑制：「わからない」と答えさせる指示文 ### 信頼度しきい値の数値明示 モデルは知らないことを聞かれると、黙るより埋めるほうが得をするように訓練されています。OpenAIの研究者らによる論文「Why Language Models Hallucinate」（arXiv:2509.04664、2025年9月提出）は、この偏りを打ち消す指示文の型を示しています。原文はこうです。 ``` Answer only if you are >t confident, since mistakes are penalized t/(1-t) points, while correct answers receive 1 point, and an answer of "I don't know" receives 0 points. ``` 論文はしきい値としてt=0.5、0.75、0.9を挙げています。減点幅が`t/(1-t)`で決まる点が肝で、t=0.75なら誤答は3点減点、t=0.9なら9点減点、棄権は常に0点です。日本語の業務プロンプトに落とすなら「確信度が75%を超える場合のみ回答してください。それ未満なら『資料からは判断できません』とだけ答えます。正答は+1点、誤答は-3点、『わからない』は0点として採点します」となります。誤答のコストが高い用途ほどtを上げます。単に「正確に答えて」と書くのとの違いは、**棄権が許されることと、その代償が数値で示されている点**にあります。 ### モデル非依存で効く指示の型 ChatGPTとGeminiで書き分ける必要はほとんどありません。効くのは製品によらない3点です。第一に、参照範囲を閉じること（「添付資料に書かれていることだけで答える。書かれていなければ『記載なし』と返す」）。第二に、根拠の提示を義務づけること（「各主張の直後に引用元のページ番号を付ける。付けられない主張は書かない」）。第三に、出力形式を固定すること。JSONスキーマなどで構造を縛ると、モデルが空欄を埋めるために創作する余地が減ります。 逆に効果が薄いのが「ハルシネーションしないでください」という禁止命令です。この一文は、モデルが何を根拠に答えるかを何も変えません。行動が変わるのは、棄権の許可や参照範囲の限定のように**出力の条件そのものを変える指示**だけです。 ## 外部ソース参照（グラウンディング）による根拠への接地 ### 接地手段の3形態と選び方 外部ソース参照とは、モデルの記憶に答えさせるのをやめ、**回答の直前に信頼できる文書を取ってきてプロンプトに差し込み、その中だけで答えさせる**方式です。実装形態は3つに分かれます。 - **自前RAG**：社内文書をベクトル検索などで引き当て、コンテキストに載せる。社内規程・製品仕様のように公開されていない情報が対象。 - **検索接地（Web grounding）**：Gemini APIの`google_search`ツールのように、モデル側が検索を実行して結果に接地する。最新の公開情報が対象で、応答には引用注釈が付き、本文のどの範囲がどのURL由来かを追えます。Gemini 3系では実行された検索クエリ単位で課金されます（2.5以前はプロンプト単位）。 - **ファイル添付**：単発の照会でPDFやテキストをそのまま渡す。検索基盤を作らずに済む代わりに、量とコストの上限が早く来ます。 選択軸は、答えの出どころが社内にあるか社外にあるか、そして更新頻度です。社内規程のように非公開かつ改訂が続く情報は自前RAG、製品の最新価格のように公開されていて動く情報は検索接地が向きます。 ### RAGを入れても誤答が残る失敗パターン RAGの誤答は、生成ではなく**検索の失敗**から生まれることが多いです。関連文書を引けなかったとき、モデルは「見つかりませんでした」ではなく手持ちの知識で埋めにいきます。検索が外れる典型は、質問の語彙と文書の語彙がずれるケース（利用者は「解約」と書き、規程は「契約の終了」と書く）です。 ここは検索側の設計で潰します。キーワード検索とベクトル検索の結果を統合する[RRF（Reciprocal Rank Fusion）とは？RAG-Fusionでの仕組み・スコア計算・実装を解説](/tech/details/8015/)で語彙ずれの取りこぼしを減らし、章立ての構造を辿って必要な節を特定する[PageIndexとは？ベクトル不要の推論型RAGの仕組み・使い方・従来RAGとの違い](/tech/details/8760/)のような手法は、長い規程・仕様書で断片だけを拾って文脈を落とす失敗に効きます。文書間の関係を保持したい場合は[BookRAGとは何か？階層構造とナレッジグラフを活用する次世代RAG手法の特徴と概要について徹底解説](/tech/details/10269/)の階層構造の考え方が参考になります。 もう一つ必ず入れるのが、検索結果が空・低スコアのときに生成させない分岐です。「該当文書なし」を正しく返せるパイプラインは、それ自体がハルシネーション対策になります。 ## 出力の検証：引用の強制とグラウンデッドネス自動検出 ### 引用付き回答による人手確認コストの削減 プロンプトで「引用を付けて」と頼むと、引用そのものが捏造されます。存在しないページ番号、実在しない判例。後述するDeloitteの事例はまさにこれです。API側の機能で強制するほうが確実です。 Anthropic APIのCitationsは、渡す`document`で`citations`を有効にすると、Claudeが出力の各主張に対して引用元の位置を返します。 ``` { "type": "document", "source": {"type": "text", "media_type": "text/plain", "data": "（社内規程の本文）"}, "title": "就業規則", "citations": {"enabled": true} } ``` 引用の粒度は、プレーンテキストなら文字位置（`char_location`）、PDFならページ（`page_location`）、独自に分割したチャンクなら`content_block_location`。返る`cited_text`は実際に渡した文書から抽出された文字列なので、**引用元が存在しないという事態自体が起きません**。`cited_text`は出力トークンとして課金されないため、プロンプトで引用を書かせる方式よりコスト面でも有利です。Claude Haiku 3を除く現行モデルで使えます。 ### 自動検出の実装と日本語運用の制約 生成後に「この回答は根拠文書に支えられているか」を機械判定する経路もあります。Azure AI Content Safetyのgroundedness detectionは、根拠文書と生成結果を渡すと、根拠から外れた箇所を検出します。 ``` { "domain": "Generic", "task": "QnA", "qna": {"query": "現在の金利は？"}, "text": "金利は5%です。", "groundingSources": ["2024年7月時点で、金利は4.5%です。"] } ``` この例では「5%」が根拠と矛盾するとして検出されます。`domain`は`MEDICAL`と`GENERIC`、`task`は`Summarization`と`QnA`を選べ、Reasoningモードにすると「なぜ根拠外と判定したか」の説明が返ります。correction機能（プレビュー）を有効にすると、根拠文書に沿って訂正した文まで返してきます。 ただし**対応言語は英語のみ**です。上の例を日本語で投げても精度は保証されません。ここは日本企業の運用で見落とされがちな制約で、日本語のまま自動判定を回したいなら、LLMを判定器に使う自作の検証（回答と根拠文を並べて矛盾の有無を答えさせる）か、翻訳を挟む構成を検討することになります。 ## 幻覚率の継続測定とモデル差し替え時の再評価 モデルは差し替わります。バージョンが上がった、コスト削減で軽量モデルに変えた、その瞬間に幻覚率が変わる。前掲のリーダーボードで軽量モデルが上位に来ることからも分かるとおり、モデルの大きさと幻覚率は素直に対応しません。大きいモデルへ替えたから安全、とは言えないということです。 自社の代表的な質問と正解のセットを50〜100件用意し、モデルやプロンプトを変えるたびに誤答率を測る。この定点観測がないと、改善したつもりの変更で劣化していても気づけません。文書を追加したときも同様で、検索の当たり方が変われば誤答の出方も変わります。 ## 対策しても消えない理由：推測を報いる評価設計 ここが競合記事のほとんどが触れていない核心です。前掲のOpenAIの研究者らによる論文は、ハルシネーションを「学習データの不足」や「モデルの欠陥」としてではなく、**評価の設計に起因する合理的な振る舞い**として説明します。 論旨はこうです。多くのベンチマークは正解に1点、不正解に0点、「わからない」にも0点を与えます。この採点では、確信がなくても推測して答えるモデルのほうが、正直に棄権するモデルより必ずスコアが高くなる。試験でわからない問題を空欄にせず適当にマークするのと同じ構造です。モデルはこの採点基準に最適化されて出荷されているので、確信度が低くても答えを作ります。 だから論文の提案は「幻覚を測る新しいベンチマークを増やすこと」ではなく、**既存の主要ベンチマークの採点方法を直すこと**——棄権にペナルティを課さず、誤答にはしきい値に応じた減点を与える——になっています。 この視点は実務にそのまま効きます。自社の評価やプロンプトが「必ず何か答えろ」という圧をかけていないか。回答率100%をKPIにしていないか。**「わからない」を許容しない運用設計そのものが、ハルシネーションを生産している**可能性があります。 ## 効果が薄い対策・避けるべき対策 ### ファインチューニングによる事実修正の限界 「社内データでファインチューニングすれば正しく答えるようになる」は、ハルシネーション対策としては勧められません。追加学習で入れた事実は重みに溶け込むだけで、参照可能な根拠としては残らないためです。しかも副作用があります。Gekhmanらの研究（arXiv:2405.05904、2024年）は、ファインチューニングのデータに**モデルが未知の新しい知識を混ぜるほど、幻覚の傾向が線形に増加する**ことを実験で示しました。事実の正しさが要る用途では、学習ではなく参照（RAG・検索接地）で解くのが原則です。ファインチューニングが向くのは、口調・出力形式・分類基準のような「振る舞い」の調整です。 ### ガイドライン止まりの運用 「生成AIの出力は必ずファクトチェックすること」という社内ルールは、罰則も工程もなければ守られません。実効性を持たせるには、チェックを人の心がけではなく**工程**にする必要があります。出力に引用を必ず付ける（API機能で強制）、引用元が空の回答は提出できない、外部に出す文書はレビュー担当の承認を通す。ルールの文言ではなく、通れない経路を作るかどうかで結果が変わります。 ## 業務システムに載せるときの運用設計 誤答が通ったときに何が起きるかで、人手確認の厚みを決めます。参考になるのがDeloitteのオーストラリア法人の事例です。2025年7月に豪雇用職場関係省のサイトで公開された237ページの報告書に、存在しない学術文献の参照と、連邦裁判所の判決からの捏造された引用が含まれていました。8月下旬にシドニー大学の研究者が最大20件の誤りを指摘して発覚し、10月に公開された改訂版で生成AI（Azure OpenAI）の使用が開示されます。契約額44万豪ドル（約29万米ドル）のうち、最終支払い分にあたる約9万7千豪ドルが返金されました。同じ構図は法廷でも起きており、2023年の米Mata v. Avianca事件では、ChatGPTが作った実在しない判例を引用した弁護士2名と事務所に5,000ドルの制裁金が科されています。 ここで壊れたのは金額よりも、外部に出す成果物の信用です。社内の検索補助であれば多少の誤答は許容できますが、顧客回答・契約・見積・監査対象の文書は、引用元の実在確認を人が通す工程を外せません。ドキュメントAI（社内文書に対する質問応答）の誤回答リスクを抑えるなら、次の3点を設定に落とし込みます。 - 回答は根拠文書の範囲内に限定し、該当なしを正しく返せるようにする（検索が空なら生成させない）。 - 回答には必ず引用元（ファイル名・ページ）を機械的に付け、リンクから原典に飛べるようにする。 - 外部に出る文書は、引用の実在確認を人の承認工程として通す。 この3点を満たしていれば、Deloitteの事例のような「捏造された脚注が納品物に残る」経路は物理的にふさげます。 ## よくある質問 ### ハルシネーションを減らすための「外部ソース参照」とは具体的にどのような方法ですか？ モデルの記憶に答えさせず、回答の直前に信頼できる文書を検索して取得し、その中だけで回答させる方式です。社内文書が対象ならRAG、公開情報が対象ならGemini APIの`google_search`ツールのような検索接地機能、単発の照会ならファイルをそのまま添付する方法があります。実装で忘れがちなのは、検索が空振りしたときに生成させない分岐です。根拠が取れないまま生成させると、モデルは記憶で埋めにいきます。 ### 「必ず出典を明記して」と指示すればハルシネーションは防げますか？ 防げません。出典そのものが捏造されるためです。Deloitteの報告書では存在しない学術文献と判決引用が生成され、Mata v. Avianca事件では実在しない判例が引用されました。プロンプトで頼むのではなく、Anthropic APIのCitationsのように**渡した文書から引用箇所を機械的に抽出させる**API機能を使えば、引用元が存在しないという状態自体が起こりません。人手確認も「引用先を開いて突き合わせる」だけで済みます。 ### 高性能なモデルに変えればハルシネーションは減りますか？ そうとは限りません。Vectaraのリーダーボード（2026年5月更新）では、要約タスクの幻覚率で軽量モデルが上位に入っており、モデルの規模と幻覚率は素直に対応しません。モデルを差し替えるときは「上位モデルだから安全」と仮定せず、自社の質問セットで誤答率を測り直してください。 ### ハルシネーション率はどこまで下げれば業務に載せられますか？ 一律の合格ラインはなく、**誤答1件が通ったときの損害で決めます**。社内の下書き生成や検索補助なら数%残っていても人の目で吸収できます。一方、顧客への回答・見積・契約・医療のように誤答が金銭や安全に直結する用途では、率をいくら下げても最後の1件が事故になるため、率の目標値ではなく「引用元の実在確認を人が通す」工程の有無で判断すべきです。技術的な上限として、根拠文書を与えた要約でも最良モデルで1.8%が残るという数字を前提にしてください。 ### ハルシネーション対策は一度実施すれば終わりですか？ 継続が必要です。モデルのバージョンアップや軽量モデルへの切り替えで幻覚率は変わり、参照文書が増えれば検索の当たり方も変わります。代表的な質問と正解を50〜100件用意しておき、モデル・プロンプト・文書を変更するたびに誤答率を測り直す運用にしてください。測っていなければ、劣化は事故が起きるまで見えません。 ## 関連記事 - [AIにおけるハルシネーションとは？基本概念と種類の解説](/tech/details/4472/) - [RRF（Reciprocal Rank Fusion）とは？RAG-Fusionでの仕組み・スコア計算・実装を解説](/tech/details/8015/) - [PageIndexとは？ベクトル不要の推論型RAGの仕組み・使い方・従来RAGとの違い](/tech/details/8760/) - [BookRAGとは何か？階層構造とナレッジグラフを活用する次世代RAG手法の特徴と概要について徹底解説](/tech/details/10269/) --- 出典: [AIハルシネーション対策｜プロンプト・RAG・検出APIで誤答を減らす実装手順]()（株式会社一創）