RAGでハルシネーションを減らす方法：プロンプトとガードレールの作り方

RAGでもハルシネーションが起きる理由（まず誤解をほどく）

生成AIの「ハルシネーション（もっともらしい嘘）」は、社内FAQや規程、製品マニュアルを参照させるRAG（Retrieval-Augmented Generation：検索拡張生成）を使えばゼロになる、と期待されがちです。しかし実務では、RAGを入れても誤回答が出ることがあります。理由はシンプルで、RAGは「参照すべき情報を取りに行く仕組み」を追加するだけで、最終的に文章を作るのはLLM（大規模言語モデル）だからです。LLMは確率的に文章を組み立てるため、曖昧な質問や不足した根拠があると、つじつまを合わせてしまいます。

もう少し業務に寄せて言うと、「資料は渡したのに、担当者が別の記憶で答えてしまった」状態に近いです。たとえば、検索で拾った社内文書が古い版だった、質問が曖昧で別の製品の文書を引いてしまった、検索結果に該当箇所がないのにAIが埋めてしまった、などが典型です。つまり、RAGの品質は「検索」「プロンプト」「運用ルール（ガードレール）」の三つ巴で決まります。

本記事では、開発に詳しくない方でも意思決定できるように、RAGでハルシネーションを減らすための具体策を「プロンプト設計」と「ガードレール（安全柵）」に分けて解説します。なお、RAGは「万能な正解装置」ではなく「根拠を示せる回答装置」に近い、と捉えると失敗しにくくなります。

ハルシネーションを減らすRAGの全体像（検索・生成・評価の三段階）

RAGの流れを、非エンジニアでも判断できる粒度に分解すると次の三段階です。ここを押さえると、どこに投資すべきか（データ整備か、プロンプトか、ガードレールか）が見えます。

• 検索（Retrieval）：質問に関連する社内文書やナレッジを探して取り出す
• 生成（Generation）：取り出した情報を根拠に、回答文を組み立てる
• 評価・制御（Evaluation/Guardrails）：根拠が弱い回答を止める／確認させる／ログで改善する

ハルシネーションは「生成」だけの問題と思われがちですが、実務では検索側の原因が非常に多いです。たとえば、PDFをそのまま入れた結果、章番号や注釈ばかりが検索に引っかかり、肝心の定義が取れない。あるいは「契約」と「約款」「利用規約」など言い換えが多く、検索が外れる。こうした状況で生成だけを縛っても、AIは「根拠がない」状態で書こうとしてしまい、結果として誤回答が増えます。

そこで重要になるのが、「根拠が取れないなら答えない」設計と、根拠が取れている場合でも「根拠の範囲内だけを要約する」設計です。これを実現する主役が、後述するプロンプト（AIへの指示）とガードレール（ルールとチェック）です。

プロンプトで効く3つの原則（根拠・範囲・出力形式）

プロンプトは「AIへのお願い」ではなく、業務で再現性を出すための仕様書です。RAGでハルシネーションを減らすうえで、効き目が大きい原則は次の3つです。

根拠を必須にする（引用・参照の強制）

最も効果的なのは、回答の根拠を必須にすることです。たとえば「必ず根拠（引用）を添える」「根拠がないなら不足情報を質問する」と明記します。ここでのポイントは、AIに「探して」と言うのではなく、RAGが返したコンテキスト（検索結果）のみを根拠にすると限定することです。外部知識や推測を混ぜる余地を減らせます。

範囲を限定する（コンテキスト外は推測禁止）

RAGでは、検索結果に載っていない情報をAIが補完してしまうことがハルシネーションの温床です。そこで「コンテキストに書かれていないことは推測しない」「不明なら不明と答える」と範囲を限定します。業務的には、誤回答でトラブルになるより「わかりません」を許容するほうが安全です。正確さ優先の運用に寄せるのが基本です。

出力形式を固定する（短く・検証しやすく）

長文は誤りが混ざりやすく、確認コストも上がります。出力形式を固定し、短く、検証しやすい形にします。おすすめは「結論→根拠（引用）→手順→注意点→必要なら確認事項」です。これにより、現場担当者が目視で検証しやすくなり、RAGの品質改善サイクルも回しやすくなります。

あなたは社内ナレッジを参照して回答するアシスタントです。
以下の「コンテキスト」に書かれている内容だけを根拠に、日本語で簡潔に答えてください。

ルール:
- コンテキストに無い情報は推測で補わない。必要なら「不足情報」を質問する。
- 重要な主張には、コンテキストからの引用（原文の一部）を必ず付ける。
- 形式は「結論 / 根拠（引用） / 手順（あれば） / 注意点 / 不足情報」で出力する。
- 数字・条件・期限・金額などは、引用で裏付けできる場合のみ書く。

コンテキスト:
{{retrieved_context}}

ユーザーの質問:
{{user_question}}

「答えない」を実装するガードレール（業務で事故を防ぐ仕組み）

プロンプトだけでは限界があり、運用で事故を防ぐにはガードレールが必要です。ガードレールとは、AIが誤った方向に進みそうなときに、止める・確認させる・人に渡すための仕組みです。特に中小企業や情シス部門で重要なのは、「誤回答を減らす」より「誤回答で事故らない」ことです。

回答の自信が低いときは「確認モード」に切り替える

RAGの検索結果が薄い（関連文書が少ない、引用が短い、同じ文書ばかり等）場合、AIに答えさせない方が安全です。そこで「根拠が一定量に満たない場合は、回答を止めて質問に切り替える」ルールを入れます。現場での体験としては、「AIが勝手に決めつけず、追加で聞き返してくれる」状態になります。

• 例：引用が1つも付けられない場合は回答しない
• 例：検索結果が社内規程ではなく雑多な議事録しかない場合は「担当部署に確認」を促す

用途別に「やってよいこと／ダメなこと」を明文化する

ガードレールは技術だけでなく、社内ルールとして効きます。たとえば「法務・人事・労務は最終判断をしない」「対外文書は下書きまで」「個人情報を入力しない」など、用途別に線引きを決めます。これにより、ユーザーがAIを過信しにくくなり、ハルシネーションが業務事故に直結するのを防げます。

ログと監査（あとから直せる仕組み）

RAGは一度作って終わりではなく、運用で育てる仕組みです。そこで「質問」「検索で当たった文書」「回答」「ユーザー評価（役に立った／誤り）」を残します。ログがあれば、誤回答の原因が「検索ミス」なのか「文書が古い」なのか「プロンプトが弱い」なのか切り分けできます。改善できる形で残すのがガードレールの要です。

実務で効くRAGデータ設計（チャンク・メタデータ・版管理）

プロンプトとガードレールの効果を最大化するには、RAGが参照するデータ側の整備が欠かせません。ここが弱いと、どれだけ「根拠を示せ」と言っても、そもそも根拠が取れません。専門用語を避けつつ、意思決定に必要なポイントをまとめます。

チャンク（文書の分割）を業務単位にする

RAGでは文書を適切な長さに分割して検索しやすくします。長すぎると関係ない文章まで混ざり、短すぎると文脈が欠けます。業務では「見出し1つ分」「手順のまとまり」「Q&A1件」など、意味のかたまりで区切るのが有効です。特に規程・マニュアルは、定義・適用範囲・例外・手続きが分散しやすいので、1チャンクに目的が1つになるよう調整します。

メタデータ（属性）で検索の精度を上げる

「どの部署のルールか」「対象製品はどれか」「いつ改定されたか」といった属性を付けると、RAGの検索精度が上がり、ハルシネーションが減ります。たとえば、情シス向けの手順と営業向けの手順が混ざると、AIが誤って別部署のルールを引用することがあります。文書に「部門」「業務カテゴリ」「版」「有効期限」などを付け、検索時に絞り込めるようにします。

版管理（最新が勝つ仕組み）を作る

現場でよく起きるのが「古い規程が検索に当たる」問題です。AIは最新・正しい版を自力で判断できません。そこで、文書の版を明記し、古い版は検索対象から外す、または「参考（旧版）」として扱うなどの運用が必要です。最低限、改定日と有効/無効のフラグを持たせるだけでも効果があります。

導入手順（PoCから本番まで）と、失敗しない評価の仕方

RAG導入は、いきなり全社展開すると失敗しやすいです。理由は、業務ごとに「正解」の定義が違い、文書の品質もバラバラだからです。成功確率を上げるには、用途を絞ってPoC（小さな検証）を行い、評価指標を決めて改善する流れが有効です。

用途を1つに絞る（例：社内問い合わせ一次対応）

最初は「人事・総務への社内問い合わせ」「情シスの手順案内」「製品の操作FAQ」など、文書が比較的整っていて、かつ問い合わせが多い領域がおすすめです。ここで重要なのは、AIに最終判断をさせない前提で、一次案内や該当資料の提示に寄せることです。

テスト प्रश्नを集め、正誤だけでなく「根拠の質」を見る

評価は「答えが合っているか」だけでは不十分です。RAGでは「根拠が適切か（正しい文書の正しい箇所か）」が核心です。たとえ結論が合っていても、引用がズレているなら再現性がありません。テスト用の質問を30〜100件程度集め、次をチェックします。

• 根拠一致：引用が質問に対応しているか
• 不足時の挙動：根拠が無いときに「わからない／確認質問」になるか
• 運用適合：社内ルール（対外文書禁止等）を守れるか

本番では「人に渡す」導線を用意する

本番運用で重要なのは、AIが詰まったときにどうするかです。「担当部署へエスカレーション」「チケット発行」「参考リンク提示」など、人の業務フローに接続します。AIが間違っても、人の判断で止められる導線があると、現場が安心して使えます。AI単体で完結させない設計が結果的に利用率を上げます。

まとめ

RAGはハルシネーションを減らす強力な手段ですが、「検索した情報を根拠として使う」だけでは不十分で、プロンプトとガードレール、そしてデータ整備がセットで必要です。特に効果が大きいのは、①コンテキスト外の推測を禁止し、②根拠（引用）を必須にし、③根拠が薄いときは答えず確認に回すことです。これにより、誤回答を減らすだけでなく、誤回答が業務事故になるリスクを下げられます。

導入は、用途を絞ったPoCから始め、正誤だけでなく「根拠の妥当性」「答えない挙動」「運用ルール遵守」を評価し、ログを元に改善するのが近道です。社内文書の版管理やメタデータ整備も、RAGの精度に直結します。まずは「一次対応」「該当資料提示」など安全な範囲から始めると、現場に定着しやすくなります。