2026.06.29

その RAG、社内規程に「忠実」に答えていますか？ ― 回答を遅くする後追い検証に頼らず、構造で正す

はじめに

こんにちは。AI 研究開発室の M.K. です。

社内にしかないドキュメントを RAG（Retrieval-Augmented Generation – 検索した文書をもとに大規模言語モデル (LLM) が回答する仕組み）の仕組みで回答させることは今やありきたりの時代になりました。

しかし、ありきたりの技術ながら、社内ドキュメントが大規模になったり、精度や正確さを求めようとすると RAG は難しくなっていきます。かといって RAG を置き換えるソリューションにも決め手がありません。オープンな生成AIモデルを持ってきてのファインチューニング（追加学習）は、性能を求めて巨大モデルが利用できる環境や高品質な学習データセットを用意することに大きなハードルがあります。

そのような状況を踏まえて、最近は Agentic RAG と言った高度な RAG や、AI に自律的に隅々まで検索させる Agentic Search の手法なども出てきました。

今回は、精度や正確さが求められる、金融業界における社内規程の RAG システムで行った技術的工夫を紹介します。

社内規程の RAG は社内規程のドキュメントが余程大量または複雑化しているものでもなければ、一般的な RAG で十分対応でき、それほど課題を抱えることはないと思いませんか？

私もはじめはそう思いましたが、金融業界などで、お客様が関わるような規程を検索・回答させたい場合、間違ったり嘘をついたりすると大きな問題が生じかねず、これを防ごうとすると実は相当難しい課題が多いことに気が付きました。

つまるところ、「正確に答えているか分からない」という不安になりますが、これには2つの別々の問題が混ざっています。

正しく出典を引けているか（検索の問題）
引いた出典に忠実に答えているか（回答生成の問題）

一つ目の「正しく出典を引けているか」はよく語られるところと思います。検索精度、recall、再ランク、などです。ところが二つ目の「引いた出典に忠実に答えているか」は意外と置き去りにされがちで、こちらの方が見抜きにくく、厄介だったりします。

この記事では、主に「引いた出典に忠実に答えさせる」ためにシステムをどう作り替えたかを書きます。ポイントは、回答を生成したあとに「合ってる？」と確かめる重い検証ステップを足すのではなく、そもそも出典からはみ出せない構造に組み替えたところです。

検索は当たっているのに、回答が規程からズレる ―「忠実さ」は検索とは別問題
後追いの検証はやめた ― 遅くなるし、結局こぼれる
根拠を先に、回答は後から ― 構造で「忠実さ」を作る（evidence-first）
「忠実さ」は良い検索があって初めて効く ― 土台としての検索層
検索失敗と捏造を分けて測る ― LLM-as-Judge で効果を可視化する
まとめ

1. 検索は当たっているのに、回答が規程からズレる ―「忠実さ」は検索とは別問題

RAG の品質を上げるには検索精度を上げるのは非常に重要です（社内規程 RAG でももちろん様々な工夫をしています。後述）。

ところが実際に試してみると、目立つ失点はしばしば検索の外で起きます。正しい根拠をちゃんと引けているのに、回答を書く段になって LLM がその根拠をわずかに読み替えてしまう、などですね。

そもそも「主張」と「根拠」って?

根拠とセットになる考え方として主張があります。ここで言う「主張」と「根拠」が何かを知っていないとこの後の話が入ってこないので、具体例で噛み砕きます。

たとえば、ある社内規程にこう書いてあったとします（例はすべて架空のもの）。

在宅勤務者の経費精算は、月末締めとする。

この規程に実際に書いてある一文が「根拠」です。出典そのもの、と言ってもいいです。

一方、ユーザーが「経費精算の締め日は?」と聞いてきて、システムがこう答えたとします。

経費精算は月末締めです。

この、システムが言い切った回答の一文が「主張」です。

さて、勘のいい方はもう気づいたと思います。この主張、「在宅勤務者の」という限定が抜け落ちています。根拠には「在宅勤務者の経費精算は」と書いてあるのに、回答は「経費精算は（みんな）月末締めです」と、対象を広げて断言してしまっています。

もっともらしいからこそ、危ない

嫌らしいのは、この回答が流暢で、もっともらしく、ちゃんと出典番号まで付いていることです。検索は当たっています。根拠のチャンクはちゃんと引けている。それでも、回答を書く一瞬で限定が外れてしまう。読んだ人は「規程を引いて答えてくれたんだな」と信じてしまいがちです。

規程・コンプライアンス・契約のように、「誰が」「どの条件で」「何の例外つきで」という限定が意味を決める領域では、この種の「もっともらしい誤り」が一番のリスクになります。

検索精度をいくら磨いても、回答生成でこれが起きる限り、品質目標には届きません。「正しく出典が検索できる」と「引いた出典に忠実に答える」は、別問題ということがおわかりいただけたでしょうか。

2. 後追いの検証はやめた ― 遅くなるし、結局こぼれる

「引いた出典に忠実に答える」をどうにかしたい。素直に思いつく対処は、検証（verification）を足すことです。回答を一度生成して、その後で「各文が、ちゃんと根拠に裏付けられているか？」を別ステップでチェックする。実際これは有効なアプローチで、研究も実装もたくさんあります。

最初はこの方向を考えましたが、後追いの検証には2つの弱点がありました。

弱点その1：遅くなる

検証を後段に足すというのは、要するに「回答を作る LLM 呼び出し」のうしろに「検証する LLM 呼び出し」をもう一段ぶら下げるということです。しかも回答全体が出そろわないと検証は始められないので、基本は直列。ユーザーを待たせる時間が、まるごと積み増しになります。

社内の問い合わせツールは、体感速度がそのまま「使われ続けるか」を左右します。「嘘はつかないけど、毎回もっさり待たされる」ツールは、結局みんな使わなくなりがちです。

弱点その2：後追いだから、こぼれる

もうひとつは構造的な限界です。後追い検証は「おかしな主張を弾く」ことはできても、「最初からおかしな主張が生まれること」自体は防げません。 また、網ですくう以上、必ず網目をすり抜けるものが出ます。

「先に回答（主張）を書かせて、あとから根拠を貼る」という構成も、同じ穴があります。主張が先にあると、根拠の伴わない主張がそもそも紛れ込む余地が残ってしまうからです。

共通する弱点は、結局「順序」でした。回答が先、根拠が後。この順序でいる限り、歪む余地は消えません。整理するとこうです。

	後追いで検証する	根拠を先に確定する
順序	回答が先、根拠が後	根拠が先、回答が後
根拠なき主張への対処	生まれたものを後で弾く（検出）	そもそも作らせない（予防）
応答速度	検証分のLLM呼び出しが直列で増える	増やさない
取りこぼし	網目をすり抜けるものが残る	構造的に生まれない

「だったら順序をひっくり返せばいいのでは?」——というのが、次の話です。

3. 根拠を先に、回答は後から ― 構造で「忠実さ」を作る（evidence-first）

順序が悪いなら、順序をひっくり返します。

これまで：回答を作る → あとから根拠をチェック／貼る
これから：先に根拠（出典）を確定する → その根拠から回答を組み立てる

根拠に紐づけられない主張は、そもそも作らない。これを設計の大原則に据えると、「根拠なき主張」は後で弾くものではなく、構造的に最初から生まれないものになります。検出（detection）ではなく予防（prevention）に倒す、という発想です。この方針を、ここでは evidence-first（根拠ファースト） と呼びます。

ちなみに、考え方自体は新しいものではありません。回答より先に根拠への帰属を置くというアイデアは、attributed QA や Chain-of-Verification（CoVe）など、すでに複数の研究で提案・検証されています。新しいのは思想ではなく、「検出ではなく予防に倒す」という実装上の意思決定の方です。

生成を「2つの役割」に分ける

evidence-first を実装に落とすとき、自分たちは生成を2つの役割に分けました。

事実を確定する段：検索で得た根拠とユーザーの問いを突き合わせ、「この根拠から、この主張が言える」という主張と根拠引用のペアを組み立てます。問いに照らして不要な根拠は落とし、根拠が足りなくて答えられない部分は「答えられない」と記録します。
読みやすい文章に整える段：確定したペアを、自然な日本語の回答に整形します。ここでのルールはひとつ、新しい事実を足さない。前段が確定したものを、人が読める形に包み直すだけです。

なぜわざわざ分けるのか。「何が言えるか（事実の確定）」と「どう読ませるか（文章の生成）」は、求められる能力もリスクも違うからです。一段で同時にやらせると、流暢さを優先して事実の方が侵食されやすい。役割を分けて、後段に「事実を作り直す自由」を与えないことで、第1段が確定した事実を第2段が崩せない構造にしています。

出典の対応が「あとからズレない」

役割を分けた効果は、出典の出し方に表れます。

第2段が前段の確定ペアに従う以上、回答本文の各文・本文中の出典番号・根拠が、ばらばらに後付けされるのではなく、最初から一貫して対応するように設計できます。LLM が出した出典番号を後から「合ってる?」と検算するのではなく、そもそも対応が崩れない経路を作る、という考え方です。

さらに、根拠として提示する引用が元の文書に本当に存在するかは、LLM の自己申告ではなくプログラムで確かめます（引用が原文と一字一句一致するかの確認）。「LLM がそう言った」ではなく「原文にそう書いてある」を担保にする、という方向です。

答えられないときは、答えない

そして、この構造はもうひとつ良い副作用を生みます。根拠が足りなければ、無理に答えない。

検索が取りこぼした、あるいは引けた根拠では問いを支えきれない——そんなとき、LLM が自分の知識で「それらしい答え」を答えるのではなく、「答えられない」と答えられるようになります。evidence-first だと、この「誠実な無回答」が、例外処理ではなく標準の挙動になります。金融業界などでは、知ったかぶりより「分かりません」の方が、ずっと安全です。

4. 「忠実さ」は良い検索があって初めて効く ― 土台としての検索層

evidence-first のやり方にはひとつ大事な前提があります。evidence-first は、引いてきた出典（根拠）が良質であって初めて効きます。

根拠から回答を組み立てる以上、検索が取りこぼせば、回答もそこで止まります（潔く「分かりません」になる）。つまり検索の網羅性が、そのまま回答できる範囲の上限になる。evidence-first を入れると、検索層の重要性はむしろ上がります。「正しく出典が検索できる」と「引いた出典に忠実に答える」は、やっぱり両輪でした。

検索層の方は、以下のような手法を組み合わせています。検索チャネルは、意味の近さで引くベクトル検索と、語の一致で引くキーワード検索の2系統を併用しています。

原文+要旨をベクトル検索：原文だけを RAG にするのではなく、原文から抽出した「要旨」もベクトル検索対象にして、検索のヒット率を向上
多段クエリへ変換：ユーザーの問い合わせをそのまま投げるだけでなく、仮想的な「回答文」を生成してベクトル検索したり（質問と文書の文体ギャップを埋める）、キーワード検索をするなどして検索の網羅性を向上
- キーワード検索（固有名詞の完全一致）：ベクトル検索が苦手な固有名詞・専門用語をピンポイントで拾う
RRF による融合：多段クエリの複数チャネルの検索結果を Reciprocal Rank Fusion で統合し、上位を厳選

このあたりの検索の工夫は前回のブログ「RAGはSpannerのハイブリッド検索がおすすめ＆ベクトル検索に「答え」を投げると精度が上がる話 — ベクトル検索×フルテキスト検索×RRF融合」にも書いていますのでよかったら見てみてください。

5. 検索失敗と捏造を分けて測る ― LLM-as-Judge で効果を可視化する

さて、ここまでの設計は、作っただけでは「効いている」とは言えません。検索や回答生成のやり方を変えるたびに、本当に良くなったかを何かしら定量的に計測できないと改善のサイクルは回りません。根拠となる出典に正しく基づいた回答を生成することを専門的に「グラウンディング」と言います（本記事でここまで「忠実さ」と呼んできたものは、技術的にはこのグラウンディングのことです）。このグラウンディングについて計測する必要があります。

検索系の指標（出典ファイル名ベースの precision / recall など）はまだ機械的に測りやすいところがありますが、グラウンディングの正しさは機械的に測りにくく、従来は人手レビューに頼っていたと思います。

そこで、グラウンディングを自動採点する LLM-as-Judge（LLM を採点者として使う手法）の仕組みを開発しました。

単一スコアでは「どこが悪い」が分からない

総合点を1つ出すだけだと、「どこが悪いの？」が分かりません。そこでグラウンディングの採点項目を、互いに独立した複数の軸に分解しました。主張が根拠と整合しているか、引用が十分か、避けるべき言い回しを踏んでいないか、捏造がないか……といった軸ごとに見ることで、「捏造はないが論点を取りこぼしている」「主張の質は高いが意図を逸脱している」のように、どの部位が落ちているかを切り分けられるようにしています。

ポイントは「検索失敗」と「捏造」を分けること

素朴に作ると、主張を「根拠に支持されているか？」の二値で判定しがちです。けれどこの二値は、性質がまったく違う2つの失敗を、同じ箱に潰してしまいます。

主張のタイプ	根拠の裏付け	正解との一致	直すべき場所
検索失敗だが、結果的に正しい	なし	合っている	検索
本物の捏造	なし	違っている	回答生成

どちらも「根拠なし」ですが、直すべき場所は正反対です。前者はモデルが自分の知識でたまたま正答にたどり着いただけ、後者は根拠にもなく正解とも違う情報を作ってしまったケース。二値判定だと、この区別がつかず、次にどっちを直せばいいのか舵が切れません。

そこで、「根拠に支持されているか」と「正解と一致しているか」を別々の軸として掛け合わせ、主張をいくつかの象限に分類する設計にしました。これで、上の2つは別の象限にきれいに分かれて見えるようになります。

そして、この「検索失敗（補完）」と「捏造」を分ける軸は、第3章の evidence-first と一直線につながります。evidence-first は、まさに前者を「無理に補完しない（分からないと答える）」方向に倒す設計でした。生成側でその挙動を作り込み、評価側でその挙動を可視化する。両輪が噛み合う、というのはこういうことです。

なお、この LLM-as-Judge（LLM を採点者として使う手法）の仕組みは、ユーザー問い合わせのリアルタイム経路には組み込んでいません。あくまで開発段階で利用します。正確さの評価には「あるべき回答（= gold 回答）」が必要で、gold 回答だけは人手で作り込まなくてはなりません。ただ、この仕組みを開発する際に一度作ればOKです。

6. まとめ

evidence-first を入れて、第5章で紹介した自分たちで作った LLM-as-Judge の仕組みで測ったところ、グラウンディング（回答が根拠に裏付けられている度合い）の主要指標は、はっきり改善しました。相対的な傾向として——

観点	変化
引用のねじ曲げ（根拠に支持はあるが、正解と食い違う主張）	大幅に減少（約4割減）
捏造（根拠にも正解にもない、作り話の主張）	ほぼ消滅（実質ゼロに）
真に根拠に裏付けられた主張の割合	増加（裏返せば、根拠で固めきれない主張が約半減）
出典の精度（引用したファイルの的中率）	向上（約1割）

特に強調したいのは、後段に重い検証層を足さなくても、捏造をほぼ抑え込めたことです。これは「検出を頑張った」結果ではなく、根拠から組み立てる構造そのものの効果だと考えています。しかも、回答を遅くせずに、です。

なお、論点の網羅性（拾うべき論点をどれだけ拾えたか）は、わずかに下がりました。これは evidence-first を「確証が持てなければ答えない」方向に倒した設計の、意図したトレードオフです。多少の取りこぼしを許容してでも、誤りと捏造を抑える——厳密さが要る領域での、私たちの優先順位の置き方です。

最後に、要点を2つに絞ります。

作り方：回答を作ってから検証するのではなく、根拠を先に確定し、そこから回答を組み立てる（evidence-first）。根拠なき主張を「後で弾く」のではなく「構造的に作らない」。足りなければ誠実に「分かりません」と答える。後段に重い検証を積まないので、回答を遅くせずに捏造を抑えられる
測り方：品質を独立した軸に分解し、特に「検索失敗」と「捏造」を分けて見る。これにより、次に直すべき場所が「検索」か「回答生成」なのかが定量的に分かる

この2つは独立した施策ではなく、互いを支え合う両輪です。構造で予防し、分解して可視化する。「だいたい合ってる」では困る——正確さが強く要求される領域の RAG ほど、この組み合わせが効いてきます。