RAGは、社内のマニュアルや規程、過去の問い合わせ記録などを根拠にして回答を作る仕組みである。生成AIが学習した一般的な知識ではなく、自社の資料に基づいて答えるため、的外れな回答が減ると期待される。しかし、RAGにしたからといって、誤った回答（ハルシネーション）がなくなるわけではない。根拠の取り違え、資料の読み違い、根拠がないのにそれらしく答えてしまう、といった形で、もっともらしい誤りは依然として起こりうる。

本記事は、RAGの回答の正しさをどう担保するかを、発注者の視点で整理する。読者として想定しているのは、中小企業の経営者、DX担当、情シス担当、事業責任者である。技術的な仕組みの細部までは踏み込まず、「出典をどう示すか」「分からないときにどう答えさせるか」を発注前に決めておくための観点に絞って解説する。RAGの回答精度そのものについてはAI開発でよくある失敗｜RAGの精度が出ない原因でも扱っている。

結論：出典を示し、根拠がなければ「分からない」と答えさせる

RAGの回答品質を担保する設計の要点は、回答そのものの正しさを完璧にすることではなく、利用者が回答を検証できる状態を作ることである。GXOが出典提示とハルシネーション対策で重視するのは、次の3点である。

  • 回答には必ず引用元（出典）を示し、どの資料に基づいたかを分かるようにする
  • 根拠が見つからないときは、無理に答えず「分からない」と返す設計にする
  • 利用者が出典をたどって、自分で正しさを確認できるようにする

RAGは「正しい答えを断言する機械」ではなく、「根拠とともに答えを示す機械」として設計するほうが、現実の業務では信頼されやすい。誤りをゼロにできない以上、誤りに気づける仕組みを併せて持たせることが重要である。

なぜ出典の提示が必要か

出典を示さないRAGは、回答が正しいかどうかを利用者が確認できない。回答の文章だけを見せられても、それがどの資料に基づくのか、そもそも資料に基づいているのかが分からない。出典がないと、次のような問題につながる。

  • もっともらしい誤りに気づけず、そのまま業務に使われてしまう
  • 回答が古い資料に基づいていても、利用者が判断できない
  • 問題が起きたときに、どの資料が原因かを追えない

出典を示すことには、もう一つ大きな効果がある。それは、社内の信頼につながることである。「この回答はこの規程の第何条に基づく」と示されれば、利用者は内容を確かめたうえで安心して使える。逆に、根拠が見えないと、便利でも「本当に正しいのか」という不安が残り、結局は使われなくなる。出典の提示は、回答の正しさを担保すると同時に、利用者がRAGを信頼して使い続けるための土台でもある。

社内導入では、この信頼の有無が定着を左右することが多い。導入直後は物珍しさで使われても、一度でも明らかな誤りに出くわすと、利用者は「やはり当てにならない」と感じて使うのをやめてしまう。出典が示されていれば、誤りがあっても「この資料が古かったのか」と原因まで見当がつき、仕組みそのものへの不信にはつながりにくい。出典は、誤りが起きたときに信頼を守る保険としても働く。

加えて、出典を示す設計は、回答する側だけでなく資料を管理する側にも規律をもたらす。どの資料が回答の根拠として参照されているかが見えるようになるため、参照される資料を整え、古い版を更新する動機が生まれる。出典提示は、RAGの回答品質と社内ナレッジの整備を、同じ方向に引っ張る働きを持つ。

根拠がないときに「分からない」と答えさせる

ハルシネーションが起きやすいのは、適切な根拠が見つからないのに、AIが無理に答えを作ってしまう場面である。社内資料の中に該当する情報がないとき、それでも何かしら答えようとすると、それらしい誤りが生まれる。

ここで重要なのは、「分からないときは分からないと答える」ことを、あらかじめ設計に組み込んでおくことである。何でも答えるRAGより、答えられないことを正直に返すRAGのほうが、業務では信頼できる。判断の目安として、次のような切り分けが考えられる。

  • 関連する根拠が十分に見つかる → 出典とともに回答する
  • 根拠が弱い、または部分的にしか見つからない → 注意を添えて回答する、または有人対応に回す
  • 関連する根拠が見つからない → 無理に答えず「分からない」と返す

どこで線を引くかは、業務の性質によって変わる。誤った回答が大きな影響を及ぼす業務ほど、慎重に「分からない」と返す側に寄せたほうがよい。この線引きの方針を、発注前に開発会社と共有しておきたい。

「分からない」と返すことには、もう一つ利点がある。それは、社内資料のどこに穴があるかが見えることである。利用者からよく聞かれるのに「分からない」と返ってしまう質問は、社内資料にその情報が整理されていないサインである。無理に答えてその場をしのぐと、この穴は見えないまま残るが、正直に「分からない」と返す設計にしておくと、不足している情報を補うべき箇所が浮かび上がる。「分からない」は、運用しながらナレッジを育てるための入口にもなる。

対策と効果を整理する

出典提示とハルシネーション対策には、いくつかの組み合わせがある。それぞれの狙いと効果を整理すると、自社にどれが必要かを判断しやすい。

主な対策と効果

対策内容効果
出典の明示回答に引用元の資料名や箇所を添える利用者が根拠を確認できる
出典へのリンク出典の該当箇所を開けるようにする検証の手間を減らし、信頼が高まる
不明時の保留根拠がなければ「分からない」と返すもっともらしい誤りを抑える
信頼度の表示根拠の強さを回答に添える利用者が回答の扱いを判断できる
有人対応への接続自信のない回答は人に引き継ぐ重要な判断を人が担保する

これらはすべてを一度に入れる必要はない。まずは「出典の明示」と「不明時の保留」を土台に据え、業務の重要度に応じて、リンクや信頼度の表示、有人対応への接続を足していくのが現実的である。

信頼度の低い回答をどう扱うか

RAGは、根拠が十分に揃わなくても、ある程度の回答を返せてしまう。問題は、その回答が「自信のある回答」と同じ見た目で出てくることである。利用者からは、しっかりした根拠に基づく回答なのか、薄い根拠から作られた回答なのかが区別できない。

そこで、回答の信頼度に応じて扱いを変える設計が役に立つ。根拠が弱い回答には注意書きを添える、一定の重要度を超える質問は必ず有人対応に回す、といった切り分けである。すべての回答を同じ重みで扱わず、自信のない回答を見分けられるようにしておくことで、誤った回答が重要な判断にそのまま使われる事態を避けやすくなる。

出典をたどれる状態をつくる

出典は、ただ資料名を添えるだけでは不十分なことがある。利用者がその出典をたどって、実際に該当箇所を確認できて初めて、検証は成り立つ。出典をたどれる状態をつくるには、次のような点を押さえたい。

  • どの資料か：回答の根拠となった資料の名前を示す
  • どの箇所か：資料のどのページ・どの節に基づくかを示す
  • 元資料に到達できるか：出典から元の資料を開ける導線をつくる
  • 資料の鮮度が分かるか：根拠とした資料がいつのものかを示す

出典をたどれるようにするには、元の社内資料が整理されていることが前提になる。資料の所在がばらばらで、版が古いものと新しいものが混在していると、出典を示しても利用者が確認にたどり着けない。出典提示の質は、元になる社内ナレッジの整備状況に左右される。この点は社内ナレッジ・FAQをRAGで活かす｜整備と維持の進め方でも整理している。

資料の鮮度は、特に見落とされやすい。RAGが古い規程を根拠にしていても、出典に日付が示されていなければ、利用者は最新だと思い込んでしまう。出典とあわせて、いつの資料かが分かるようにしておきたい。

発注前に決めておきたい観点

ここまでの内容を、発注前に確認しておきたい観点としてまとめる。いずれも、技術的にどう実現するかより前に、自社としてどういう方針で臨むかを決めておくべき論点である。

  • 出典をどの粒度で示すか：資料名までか、ページや該当箇所まで示すか
  • 出典から元資料に到達できるようにするか：リンクや参照導線を用意するか
  • 根拠がないときにどう答えさせるか：「分からない」と返す範囲をどこまでにするか
  • 信頼度の低い回答をどう扱うか：注意書きを添えるか、有人対応に回すか
  • 重要な質問を有人対応に振り分けるか：人の確認を必須にする範囲を決めるか
  • 資料の鮮度をどう示すか：いつの資料に基づくかを回答に添えるか

これらは、誤った回答が自社の業務でどこまで許容できるかという判断に基づく。許容できる誤りの範囲が業務によって違う以上、開発会社に任せきりにせず、発注者側で方針の輪郭を持っておきたい。方針があいまいなまま開発を進めると、出来上がったRAGが「便利だが信用しきれない」状態になり、結局は使われなくなる。出典提示とハルシネーション対策は、RAGを業務で使い続けられるものにするための、発注前の地ならしである。

よくある質問

Q1. 出典を示せば、ハルシネーションはなくなりますか

出典を示すこと自体は、誤りをゼロにする仕組みではない。出典の提示は、利用者が回答を検証し、誤りに気づけるようにするためのものである。これに「根拠がなければ分からないと返す」設計や、信頼度の低い回答を有人対応に回す仕組みを組み合わせることで、誤った回答が業務にそのまま使われるリスクを下げられる。誤りを減らす工夫と、誤りに気づける工夫の両方が必要である。

Q2. 「分からない」と答えるRAGは、使いものにならないのではないですか

何でも答えるが時々間違えるRAGより、答えられないことを正直に返すRAGのほうが、業務では信頼されやすい。誤った回答に気づかず使ってしまうほうが、影響は大きい。「分からない」と返された質問は、有人対応に回したり、社内資料の不足を補ったりするきっかけにもなる。答えられない範囲が見えること自体が、運用の改善につながる。

Q3. 回答の正しさは、発注前にどこまで決めておくべきですか

完璧な正しさを保証する設計は現実的ではない。発注前に決めておきたいのは、「出典をどう示すか」「根拠がないときにどう答えさせるか」「信頼度の低い回答や重要な質問をどう扱うか」という方針である。これらは技術というより、自社の業務でどこまでの誤りを許容できるかという判断に基づく。発注者側でこの方針を持っておくと、開発会社との設計がかみ合いやすい。RAGの全体像から確認したい場合は社内ナレッジを活かすRAG・AI検索の導入ガイドも参考になる。

RAGの出典提示とハルシネーション対策を一緒に設計しませんか

GXOでは、引用元の提示、根拠がないときの回答制御、信頼性の担保を含め、RAGの回答品質の設計をご支援します。

RAGの品質設計を相談する

※ 初回相談では、営業資料の説明よりも現状整理とリスク確認を優先します。