この記事で分かること

  • RAG＝外部の文書を検索して取得し、その内容を根拠に回答を生成するAIの方式であること
  • 出典を示せることが、金融実務でRAGが重視される最大の理由
  • 検索対象の鮮度・アクセス権・出典表示という3つの論点と、その確認のしかた
  • 整数設例で見る「参照文書のうち根拠として提示されたのは何件か」の数え方

30秒で分かる定義

RAG（検索拡張生成）とは、質問に対してまず外部の文書群を検索して関連箇所を取得し、その取得結果を根拠として回答を生成させる、生成AIの利用方式のことです。英語では Retrieval-Augmented Generation（読み方：らぐ／けんさくかくちょうせいせい）、検索連携生成とも呼ばれます。ポイントは、検索（Retrieval）と生成（Generation）が工程として分かれていることです。AIが学習時に覚えた知識だけで答えるのではなく、回答の直前に指定した文書群を参照し、そこに書かれていた内容をもとに文章を組み立てる手順を踏みます。社内規程・有価証券報告書・契約書など、モデルが学習していない情報や学習時点より新しい情報を扱う場面で用いられます。汎用の生成AIとの違いは金融特化AIと汎用生成AIの違いで整理されています。

なぜ実務で重要なのか

金融実務では、成果物の数字や記述について「その根拠はどこか」を必ず問われます。生成AIの回答をそのまま使えない最大の理由は、根拠をたどれないことにありました。RAGは参照した文書を回答と一緒に提示できるため、回答→出典文書→原本という追跡経路が残ります。この追跡経路は、上司レビューでも監査対応でも効いてきます。一方で、出典が表示されていることと、その出典に本当にその記述があることは別の問題です。生成AI出力の検証手順のとおり、出典表示は検証を不要にするものではなく、検証を現実的な工数で行えるようにする仕組みだと捉えるのが実務的です。

計算式（または仕組み）

RAGは、おおむね次の4工程で構成されます。工程ごとに確認すべきことが異なります。

工程行われること実務で確認すること
1. 文書の準備対象となる文書群を検索できる形に整えるどの文書を対象にしたか、いつ時点のものか
2. 検索質問に関連する箇所を上位N件だけ取得する取得件数の設定、取りこぼしの有無
3. 生成取得した内容を根拠に回答を組み立てる各記述に取得文書が紐づいているか
4. 出典表示参照した文書名・箇所を回答に添える表示された箇所から原本までたどれるか
根拠の紐づけ率 ＝ 出典を確認できた記述数 ÷ 回答中の記述数（単位：件／件、無次元）

分母は回答が主張している事実の数、分子はそのうち取得文書の該当箇所に実際に書かれていた数です。その差が、人が追加で確認すべき箇所になります。

整数設例で確認する

設例（架空）。社内の資料庫に文書が120件あり、ある質問に対して検索が上位10件を取得したとします。生成された回答には事実の記述が12個あり、うち出典が表示されたのは9個でした。

まず参照文書の側を数えます。取得10件のうち、回答の出典として実際に提示されたのは7件でした。残る3件は取得されたものの回答には使われていません。10 − 7 ＝ 3件で計算が合います。

次に記述の側を数えます。根拠の紐づけ率は 9 ÷ 12 ＝ 0.75（75%）です。裏返すと、12 − 9 ＝ 3個の記述には出典が付いていません。この3個が最も危険で、検索で取得できなかった情報を、AIが学習済みの一般知識や推測で埋めた可能性がある部分です。実務ではこの3個を最優先で原本照合し、確認できなければ回答から削除します。「出典が9個も付いているから信頼できる」ではなく「出典が付いていない3個がある」と読むのが正しい使い方です。

実務で必ず詰める3つの論点

1つ目は、検索対象の鮮度です。古い規程や失効した契約書が混ざっていると、AIは古い内容を出典付きで提示します。対象文書の版と取込日を管理し、改訂時に差し替える運用がなければ、出典表示はかえって誤りを補強してしまいます。

2つ目は、アクセス権です。検索対象に、質問者が本来閲覧できない文書（未公表の案件資料、人事情報など）が含まれていると、RAGはそれを要約して提示してしまいます。文書単位の閲覧権限が検索段階で効いているかの確認が必要です。バーチャルデータルームで権限管理している案件資料を、権限設計のないまま検索対象に流し込まないことが基本です。機密情報の線引きは生成AIに入れてよい情報・いけない情報で整理されています。

3つ目は、出典表示の粒度です。ファイル名だけの表示では検証できません。文書名・版・該当箇所（条番号やページ）まで表示され、原本に到達できて初めて実務で使えます。

実務での使い方

  • 取得件数（上位何件を参照するか）を把握し、根拠を取りこぼしていないかを既知の答えがある質問で確かめる
  • 回答の記述を1つずつ行に落とし、出典の有無と原本照合の結果をExcelで管理する。COUNTIF関数で「未照合」を集計し、ゼロになるまで残件として追う
  • 「該当する記述が見つかりませんでした」と返す設計になっているかを、意図的に答えのない質問を投げて確認する
  • 対象文書の一覧・版・取込日を台帳化する。データの入力規則で版の表記ゆれを防ぐと後の突合が楽になります
  • 開示資料が対象なら生成AIで有価証券報告書・決算資料を読むの手順と組み合わせ、原本のページ番号まで戻れるようにする

実務家が確認するポイントとよくある誤解

誤解1：「RAGを使えばハルシネーションは起きない」→ 起こり得ます。取得できなかった部分をAIが学習済みの知識で埋めることがあります。出典が付いていない記述が残っていないかを毎回確認します。

誤解2：「出典が表示されていれば内容も正しい」→ 示された文書にその記述が本当にあるとは限りません。提示された箇所を開いて突き合わせるまでが検証です。

誤解3：「社内の全文書を入れるほど賢くなる」→ 対象を広げるほど関連度の低い文書が上位に紛れ込み、精度が下がることがあります。目的別に対象を絞る方が実務では機能します。

確認ポイント：回答そのものではなく、参照された文書の一覧と記述ごとの出典の有無をレビュー対象にしているかを確認します。AIを使った財務モデリングと同じく、検証責任は利用者側に残ります。

日本実務での扱い

個人情報保護委員会は「生成AIサービスの利用に関する注意喚起等について」（2023年6月2日）を公表し、個人情報取扱事業者が生成AIサービスにプロンプトとして個人情報を含む内容を入力する場合は、特定した利用目的の達成に必要な範囲内であることを十分に確認するよう求めています。RAGでは検索対象の文書群そのものが入力に当たり得るため、特に慎重な検討が必要です。総務省・経済産業省「AI事業者ガイドライン」（第1.2版、2026年3月31日公表）は、法令ではなくガイドラインという位置づけの文書です。また金融庁のEDINETは利用規約において、二次利用時に編集・加工を行ったこと及びその主体を記載することを求め、短時間における大量アクセス等を禁止する旨を規定しています。これらの適用可否や自社の運用の適合性の判断は、必ず法務・コンプライアンス部門に確認してください。横断分析の具体的な進め方はAIでEDINETの複数企業・複数年度を横断比較するで扱われています。

面接・モデルテストで問われるポイント

Q：社内文書を使ったRAGを導入する場合、まず何を確認しますか？
「対象文書の版と取込日が管理されているか、閲覧権限が検索段階で効いているか、出典が該当箇所まで表示されるかの3点を先に確認します。そのうえで、既知の答えがある質問で取りこぼしを測り、答えのない質問には『見つかりませんでした』と返す設計かを確かめます。」

深掘りでは「出典が付いていない記述をどう扱うか」「対象文書を広げると精度が下がる理由」が問われます。

よくある質問（FAQ）

Q. RAGと、プロンプトに資料を貼り付ける方法は何が違いますか？
A. 貼り付ける方法はどの資料を渡すかを人が毎回選び、RAGは質問ごとにシステムが自動で選びます。対象が数件なら貼り付けで十分ですが、数百件から探す場合にRAGの利点が出ます。渡した資料に書かれていないことは答えられない点は同じです。

Q. 出典が付いていない記述は必ず誤りですか？
A. 必ずしも誤りとは限りませんが、取得文書で裏付けが取れていない状態です。原本で確認できたものだけを残し、確認できないものは成果物から落とす運用が安全です。

出典・参考（2026-08-03確認）

共有: