生成AIの幻覚対策：RAGと検証の基本手順

生成AIを業務で使い始めると、多くの現場で最初にぶつかるのが「もっともらしく間違える」問題です。文章としては自然で、断定口調でもあり、しかも一見すると筋が通っているため、誤りに気づきにくい。この現象は一般に「幻覚」と呼ばれます。社内FAQ、規程検索、問い合わせ一次対応、レポート作成補助など、事実性が求められる用途では、この幻覚を放置すると誤案内や誤判断につながります。そこで重要になるのが、RAG（Retrieval-Augmented Generation）で外部情報を参照させることと、出典設計・評価・監視をセットで整えることです。実際、OpenAIの精度改善ガイドでも、検索を加えるだけでなく、検索品質の調整と fact-checking step の追加が精度改善の流れとして示されています。さらに、OpenAIのRAG向け解説でも、RAGは新しい情報をモデルに取り込み、幻覚を減らすのに有効ですが、それでも幻覚は残りうると明記されています。本記事では、その前提に立って、RAGを万能視せずに使いこなす基本手順を整理します。

第1章：幻覚とは何か、なぜ起きるのか

まず押さえたいのは、幻覚とは単なる誤字や言い回しの乱れではなく、事実としては誤っているのに、自然な文章として生成されてしまう現象だという点です。生成AIは、世界の事実をデータベースのようにそのまま保存しているわけではなく、学習時に見た大量の表現パターンから、次にもっともらしい語を予測して文章を組み立てています。そのため、入力が曖昧だったり、必要な根拠が手元になかったり、質問に対して一貫した答えを返す圧力が強すぎたりすると、正確さより流暢さが前に出ることがあります。すると、存在しない社内ルール、誤った日付、架空の製品仕様、似ているが別物の概念などが、いかにも本当らしく出力されます。

また、幻覚はモデルの知識不足だけで起きるわけではありません。たとえば社内文書を使う業務では、モデルが一般知識としては正しくても、社内固有の運用ルールと食い違うことがあります。逆に、参照資料を与えていても、検索がずれていたり、必要な箇所が長い文書の奥に埋もれていたりすると、モデルは十分な根拠を拾えません。さらに、質問文そのものが曖昧で、問い合わせ側の前提が不足している場合も、AIは「わからない」と言うより、それらしい補完をしてしまいがちです。つまり、幻覚はモデルの問題だけでなく、入力・検索・出力設計の問題としても起きます。

実務では、もっとも危険なのは露骨に変な回答ではなく、部分的に正しい情報と誤りが混ざった回答です。たとえば就業規則の案内で、申請期限は合っているのに対象者条件だけ違う、問い合わせ返信で製品名は正しいのに交換条件を取り違える、といったケースです。この種の誤答はレビューでも見落とされやすいため、単に「自然な文章かどうか」ではなく、「どの文がどの根拠に支えられているか」を追える設計が必要になります。幻覚対策の出発点は、AIを知識そのものとして信じるのではなく、根拠付きで答えさせるべき生成器として扱うことです。

第2章：RAGで事実性を補強する基本

RAGの基本は、質問に答える前に外部の文書やナレッジベースから関連情報を検索し、その内容を参照しながら回答させることです。OpenAIのRAG解説でも、RAGはモデルの知識を新しいデータで補い、回答の事実性を高める用途に向いていると説明されています。一方で、同じ資料では「RAGでも幻覚は残りうる」と明記されており、検索さえ入れれば安全というわけではありません。つまり、RAGの本質は「モデルの自由回答を減らし、参照範囲を管理すること」にあります。

実装の第一歩は、良い検索基盤を作ることです。ここで重要なのは、文書をそのまま長い塊で入れないことです。OpenAIのRAG向けCookbookでも、文書を適切な単位にチャンク分割し、埋め込み、検索、再ランキング、安全チェックまでを一連の技術パターンとして扱っています。たとえば社内規程集を丸ごと1ファイルで扱うより、「申請条件」「提出期限」「例外条件」「問い合わせ先」のような意味のまとまりで分割したほうが、必要箇所を引き当てやすくなります。さらに、見出しや要約を前処理で補っておくと、検索ヒット時に文脈がつかみやすくなります。

次に重要なのが、検索ヒット件数と品質の調整です。関連性の低い断片を大量に詰め込むと、かえってモデルが混乱し、誤答が増えることがあります。反対に、上位1件だけに頼ると、必要条件が別チャンクにある場合に抜け漏れが出ます。そのため、上位数件を取得したうえで再ランキングし、最後に「十分な根拠が見つからない場合は推測せず不足を伝える」と明示する設計が有効です。たとえば、問い合わせ回答なら「該当文書が見つからない場合は断定せず、確認が必要と返す」、規程検索なら「根拠文書名と節番号が取れた場合のみ結論を書く」といったルールです。RAGを成功させる鍵は、検索精度そのものに加えて、根拠不足時に無理に答えさせないことにあります。

第3章：出典提示・引用・再確認の設計

RAGの価値を実務で引き出すには、単に裏で検索して終わりにせず、何を根拠に答えたかを利用者が確認できる形にすることが欠かせません。もっとも基本的なのは、回答文に対して参照した文書名、章、節、更新日などを添えることです。たとえば「就業規則第12条」「FAQ_返品対応_2026-03版」のように出典を具体化すると、利用者はその場で裏どりしやすくなります。これがないと、RAGを入れていても、実際には“AIがそう言っている”以上の確認ができません。

さらに一歩進めるなら、結論だけでなく、短い引用や要約済み根拠をあわせて表示する設計が有効です。たとえば「返金は購入後14日以内が対象です（根拠：返品ポリシー第3節『商品到着後14日以内は全額返金』）」のように、結論と根拠を隣接させる形です。ただし、引用は長くなりすぎると読みにくいため、全文転載ではなく、判断に必要な最小限の根拠だけを見せるのが現実的です。そのうえで、ユーザーが詳細を開けるようにしておくと、レビュー性と可読性の両立がしやすくなります。

また、重要な業務では再確認の段階を別に設けるべきです。OpenAIのガードレール解説でも、入力ガードレールと出力ガードレールを分け、出力後に検証する発想が強調されています。実務では、回答生成後に「この文は根拠チャンク内で支持されているか」「断定表現のうち、出典が明示されていない文はないか」「日付・金額・対象条件に矛盾がないか」を別ステップで点検させると、もっともらしい誤答をかなり落とせます。たとえば二段構成として、1回目で回答草案を作り、2回目で根拠一致チェックを実行し、不一致があれば非回答へ倒す設計です。RAGの精度は、検索と生成の間だけで決まるのではなく、出典を人とシステムの両方が検証しやすい形に整えることで大きく変わります。

第4章：もっともらしい誤答を見抜く評価法

幻覚対策では、精度評価の仕方も重要です。単に「自然な文章だったか」「役に立ちそうだったか」だけで採点すると、もっともらしい誤答を高く評価してしまいます。RAG評価のサーベイでも、検索側と生成側を分けて、relevance、accuracy、faithfulnessといった指標で見る必要性が整理されています。ここで特に実務で重要なのは、検索が適切だったかと、回答が検索根拠に忠実だったかを別々に見ることです。検索は合っていたのに回答が盛ってしまうこともあれば、回答文自体は慎重でも検索がずれていて結論が誤ることもあるからです。

そのため、評価表は最低でも「検索関連性」「根拠忠実性」「回答正確性」「非回答の適切さ」の四つに分けると扱いやすくなります。たとえば社内規程QAなら、検索関連性は「必要な条文を上位に引けたか」、根拠忠実性は「回答が取得文書の範囲を超えていないか」、回答正確性は「最終結論が業務上正しいか」、非回答の適切さは「根拠不足時に無理に断定しなかったか」で見ます。ここで重要なのは、答えられなかったケースを一律に減点しすぎないことです。根拠がないのに断定するより、確認が必要と返すほうが本番運用では安全なためです。

また、OpenAIの精度改善ガイドが示すように、改善は「評価→仮説→修正→再評価」の反復で進めるのが基本です。そのため、評価用データセットには平常ケースだけでなく、あえて難しいケースも含めるべきです。たとえば、似た規程が複数ある質問、更新前後で条件が変わった文書、質問文が曖昧で確認事項が必要なケース、出典のどこにも答えがないケースなどです。これらを混ぜることで、回答精度だけでなく、未ヒット時の挙動や過剰推測の有無まで確認できます。もっともらしい誤答を減らしたいなら、成功例だけを見るのではなく、失敗の再現性を評価セットに組み込むことが欠かせません。

第5章：本番運用での幻覚監視フロー

最後に、本番運用では「良い設計を作ること」と同じくらい、「崩れたときに早く気づくこと」が重要です。OpenAIのガードレール解説では、入力前後で検知的な制御を置く考え方が示されており、安全運用ではモデレーションや監視、人的レビューを組み合わせることが勧められています。実務では、幻覚監視もこれと同じ発想で組むとわかりやすいです。つまり、入力時、検索時、出力時、事後監査の四段階で異常を拾います。

たとえば入力時には、質問が対象範囲外か、プロンプトインジェクションの疑いがないかを見ます。検索時には、上位ヒット件数、スコア、文書更新日、再ランキング結果をログ化し、未ヒットや低信頼ヒットをフラグにします。出力時には、出典欠落、断定表現、日付や金額の記載、不一致の可能性が高い表現を自動チェックします。さらに事後監査では、ユーザーからの差し戻し、手修正率、再生成率、根拠不明回答率を週次で集計すると、どこで品質が崩れているかを追いやすくなります。たとえば、未ヒット率が高いなら検索設計の問題、出典付きなのに誤答が多いなら回答生成や再確認設計の問題と切り分けやすくなります。

加えて、高リスク用途では人手確認ラインを残してください。社外向け回答、規程解釈、金額・期限・法務要素を含む案内などは、AIが下書きし、人が根拠と結論を確認して確定する形が安全です。OpenAIの安全ベストプラクティスでも、人間の監督やモデレーション、レッドチーミングの重要性が案内されています。つまり、本番運用で大切なのは「幻覚をゼロにできる」と考えることではなく、幻覚が起きても検知・隔離・修正できるフローを作ることです。RAG、出典提示、再確認、監視ログ、人手確認をつないだ運用まで整ったとき、生成AIはようやく事実性が求められる業務で使いやすくなります。

生成AIの幻覚対策は、プロンプトだけで解決する問題ではありません。幻覚がなぜ起きるかを理解し、RAGで根拠を補い、出典提示と再確認を設計し、評価では検索と生成を分けて見て、本番では監視フローを回す。この一連の流れを作ることで、もっともらしい誤答は着実に減らせます。まずは小さな業務から、未ヒット時の非回答ルール、出典表示、難ケースを含む評価セット、週次の誤答監視を始めてみてください。RAGは万能薬ではありませんが、検証と運用を組み合わせれば、事実性が重要な業務での実用性は大きく高められます。