金融部門のRAG実装ガイド｜社内規程・案件資料を出典付きで検索する設計

結論：RAGの成否は「何を索引に入れるか」と「誰が何を見られるか」で決まる

社内文書を生成AIに検索させる仕組みはRAG（検索拡張生成）と呼ばれます。定義と、出典提示がなぜ重視されるのかは用語ページに譲り、本記事はその先の実装の設計判断を扱います。

金融部門でRAGがうまくいかないとき、原因の多くはモデルの性能ではありません。索引に入れる文書の範囲を絞らなかったことと、閲覧権限を検索の手前で効かせなかったことの2点に集約されます。前者は「規程の旧版が現行版と同じ顔で出てくる」という形で表面化し、後者はその利用者が見てはいけない案件資料の内容が、要約という形で漏れるという深刻な事故になります。

したがって最初に決めるべきは、モデルでもツールでもなく、次の3つです。

• 対象範囲：どの文書群を索引に入れ、どれを入れないか（全社の共有フォルダを丸ごと入れない）
• 権限の実体：文書1件ごとに「誰が見てよいか」をどのデータで表現し、検索のどの時点で効かせるか
• 出典の粒度：文書名だけで止めず、版・条番号・ページのどこまで返せば、読み手が原本に到達できるか

この3つが決まっていれば技術選定は入れ替え可能です。逆にここが曖昧なまま製品を選ぶと作り直しになります。特化型と汎用の選択軸は金融特化AIと汎用生成AIの違いで整理していますので、本記事では製品に触れず、どの製品でも必要になる設計だけを扱います。

RAGの参照構成：7段階と、権限チェック・ログの位置

RAGは「構築時に一度だけ行う工程」と「質問のたびに走る工程」に分かれます。この2つを混ぜて考えると、権限チェックをどこに置くべきかが見えなくなります。

強調したいのは2点です。第一に、権限チェックは2か所に必要です。構築時には「そもそもこの文書を索引に入れてよいか」、実行時には「この利用者に見せてよいか」を判断します。前者だけでは部門横断の事故を防げず、後者だけでは索引そのものが機密の集積になります。第二に、ログは全工程に置きます。回答文だけでは「なぜその回答になったか」を再現できません。取得した文書のIDと版まで残して初めて監査に耐えます。

AIが複数工程を自律的に進める形（エージェント）にする場合の承認フローと監査証跡はAIエージェントの統制設計で扱っています。本記事は「一度だけ検索して回答する」単純な構成を前提にします。

段階別の設計判断と、失敗の仕方

① 対象文書の選定

設計判断：索引に入れる文書群を業務単位で明示的に列挙します。「経理部の月次締め手順」に答えたいなら、対象は経理規程・締めマニュアル・過去のFAQに限定します。範囲を広げるほど後段の精度が落ちます。入れる・入れないの決定は所管部署が行い、AIに任せてよいのは棚卸しリストの下書きと重複候補の抽出までです。

失敗の仕方：共有フォルダのルートを丸ごと指定する。下書き・個人メモ・失効した様式・重複コピーが同じ重みで索引に入り、正解の文書が上位に来なくなります。人が探しても見つからない棚は、AIに探させても見つかりません。

② 前処理（分割・メタデータ付与）

設計判断：文書を検索単位（チャンク）に分割し、1件ごとにメタデータを付けます。詳細は後述します。

失敗の仕方：文字数だけで機械的に切ること。「1,000文字ごと」の固定長分割は条文や表の途中で切れます。切れた側だけが検索に当たると、条件節が落ちた不完全な内容が根拠として使われます。

③ 索引化

設計判断：チャンクを検索可能な形に変換して格納します。ここで決めるのは技術ではなく更新ルールです。規程の改訂・契約の失効・案件のクローズを、索引側にいつ・誰が・どう反映するかを決めます。

失敗の仕方：初回構築だけ丁寧にやり、更新を人手の思い出しに任せること。半年後には出典付きで古い内容を返す仕組みができあがります。削除の反映は特に忘れられがちで、原本を消しても索引に残れば検索には出続けます。

④ 検索

設計判断：候補を何件取得するか、どのメタデータで事前に絞るかを決めます。「現行版のみ」「自部門＋公開文書のみ」といった既定のフィルタを最初から掛け、必要なときだけ利用者が外せるようにする設計が扱いやすい、というのが本記事の提案です。

失敗の仕方：フィルタを掛けずに全件から取得すること。似た文言の旧版・他部門版が並び、生成段でどれを信じるかの判断ができなくなります。

⑤ 生成

設計判断：取得したチャンクだけを根拠に回答を作らせ、根拠が取れなかったときの振る舞いを明示的に定義します。大規模言語モデル（LLM）は参照文書になくても一般知識でもっともらしい文章を作れてしまうため、これを禁止する指示を必ず入れます。

失敗の仕方：「参考にしてください」程度の弱い指示で渡すこと。検索結果が的外れだったとき、モデルは黙って一般論で埋めます。読み手にはそれが検索結果由来か一般知識由来か区別できません。

⑥ 出典提示

設計判断：回答の各主張に、どの文書のどこを使ったかを紐づけて表示します。最低限、文書名・版・該当箇所（条番号またはページ）・原本へのリンクの4点です。

失敗の仕方：ファイル名だけを返すこと。「経理規程.pdf」では200ページのどこを見ればよいか分からず、結局は人が全部読むことになり、検証の手間が減りません。

⑦ 評価

設計判断：「うまく動いている気がする」を数値に置き換えます。評価セットを作り、変更のたびに同じ問題で測ります。

失敗の仕方：評価セットを作らず、担当者が思いついた質問をその場で試すこと。改善したのか悪化したのかが分からず、前処理を変えた結果ある種類の質問だけが壊れる事態を検知できません。

金融文書に固有の5つの難所

ここからが本記事の核心です。一般的なRAGの解説では扱われにくい、金融部門ならではの問題を5つ挙げます。

難所1：アクセス権 ── 部門横断検索がいちばん危ない

金融機関では案件ごとに閲覧できる人が限定されます。証券会社等では法人関係情報の管理について不公正な取引の防止に必要かつ適切な措置を講じることが求められています（金融商品取引業等に関する内閣府令。条文はe-Gov法令検索でご確認ください）。いわゆるチャイニーズウォールです。

RAGは、この壁を技術的に迂回してしまう構造を持っています。利用者は文書を開けなくても、AIが要約した文章としてなら内容を受け取れるからです。索引は元のフォルダ構造から切り離された別の入れ物なので、「ファイルサーバのACLで守られているから大丈夫」という前提は成り立ちません。対処は次のとおりです。

1. 索引に入れる時点で落とす：案件限定の文書は全社向け索引に入れません。必要なら案件単位で別の索引を作り、案件チームだけがアクセスできるようにします
2. チャンク1件ごとに閲覧可能グループを持たせる：文書単位ではなくチャンク単位です。1つの文書に公開部分と非公開部分が混在することがあるためです
3. 検索の前段でフィルタする：取得してから捨てるのではなく取得する前に候補集合から除外します。取得後に生成モデルへ渡せば、その時点で内容が入力に乗ります
4. 「ヒット件数」も漏らさない：「該当資料が3件ありますが表示できません」という応答は、案件の存在自体を伝えます。存在を秘匿すべき情報では、権限外の文書は最初から存在しない扱いにします

難所2：版管理 ── 旧版と新版が同時にヒットする

規程・マニュアル・契約書には改訂があります。旧版と新版は文言が9割方同じなので、検索では両方が同じくらいの強さでヒットします。しかも旧版のほうが長く存在していた分、参照や引用が多く、上位に来ることさえあります。対処は、版をメタデータとして持たせ、既定で現行版だけを検索対象にすることです。あわせて次の2点を設計します。

• 適用開始日：「2026年4月1日から適用」の規程について、3月時点の取引に関する質問なら旧版が正解です。改訂日ではなく適用開始日を持たせ、基準日で絞れるようにします
• 後継版へのポインタ：旧版を意図的に検索したとき「この版は第8版により改訂されています」と併記できるよう、旧版に後継版のIDを持たせます

版管理を怠ると出典付きで堂々と間違えるという最も厄介な失敗が起きます。出典が付いている分、読み手は疑いません。

難所3：表とPDF ── 財務諸表がテキスト化で壊れる

決算資料・有価証券報告書・投資委員会資料の要点は、多くが表にあります。ところがPDFをテキスト化すると表は行と列の関係を失い、「売上高　12,400　11,800」が「売上高12,40011,800」と連結されたり、列がずれて別年度の数字が結びついたりします。さらに固定長で切ると分割位置が表をまたぎます。見出し行だけが前のチャンクに残り数値行が次に入ると、どちらも単独では意味を成しません。対処は次のとおりです。

1. 1つの表を1チャンクにする：本文とは別の単位として扱い、途中で切らない
2. 表に見出し・単位・期間を必ず添える：「第3四半期連結損益計算書（単位：百万円、2026年4月〜12月）」を先頭に付け直し、表だけを見て単位が分からない状態にしない
3. 説明文を別チャンクとして併置する：表そのものは検索に当たりにくいので、「連結売上高と営業利益の3期分の推移」といった説明文を人が付け、そこを検索の入口にします
4. 数値は原本で確認する：AIが表から読み取った数値をそのまま転記させない。照合手順は生成AIで有価証券報告書・決算資料を読むで扱っています

難所4：固有名詞と略語 ── 社内略称・案件コードネーム

「AL委」「本部稟」のような社内固有の略称は、一般の言語モデルにとって意味を持ちません。加えてM&A案件ではコードネームが使われ、同じ案件が資料によって正式名称・コードネーム・略称のいずれかで書かれています。対処は辞書を作り、前処理と検索の両方に効かせることです。

• 略語辞書：社内略称と正式名称の対応表を作り、メタデータに正式名称を併記します。本文を書き換えず別項目として持たせるほうが、原本との差分が出ません
• コードネーム対応表：案件IDを軸にコードネーム・正式名称・対象会社名を紐づけます。ただしこの対応表自体が機密です。誰が引けるかを厳格に制限します
• 表記ゆれ：全角半角、「&」と「アンド」など。正規化した検索用テキストを別に持ち、表示は原本のままにします

難所5：出典の粒度 ── どこまで示せば原本に到達できるか

出典提示の目的は読み手が数十秒で原本の該当箇所にたどり着けることです。この基準で粒度を決めます。本記事の提案は次の水準です。

• 社内規程：規程名＋版数＋条・項番号（例：与信管理規程 第8版 第12条第2項）。ページ番号だけでは改訂で位置がずれます
• 契約書：契約名＋締結日＋条番号。同じ相手先と複数の契約がある場合、締結日がないと特定できません
• 開示資料：書類種別＋発行体＋会計期間＋セクション名またはページ。会議資料・議事録は会議体名＋開催日＋議題番号またはスライド番号

あわせて出典と回答文の対応を取れるようにします。末尾に出典を3件並べるだけでは、どの文がどの出典に基づくか分かりません。主張ごとに紐づけるほうが検証は速くなります。

文書前処理の設計：分割単位とメタデータ

前処理の設計は文書種別ごとに変えます。全種別を同じルールで切るのが、最もよくある失敗です。

チャンク粒度の目安

粒度は「1件だけ読めばその質問に答えられる最小の単位」を狙います。本記事の提案は次のとおりです。

• 基本は見出し単位：条・項・章・スライドなど文書自体が持つ構造で切ります。文字数で切るのは、構造が取れない文書だけの例外扱いにします
• 長すぎる見出しは分ける：1つの条が数ページに及ぶ場合は項で分けます。目安として1チャンクが800〜1,200字を大きく超えるなら分割を検討します
• 短すぎるチャンクは前後を含める：「第5条　削除」のような1行では役に立ちません。前後の文脈を少し重ねて持たせます
• 親の見出しを必ず引き継ぐ：「第3章 与信判断 > 第12条 稟議の要否 > 第2項」という経路を書き込みます。検索の手掛かりにも出典表示にも使えます

索引に入れる前に必ず付ける項目

チャンク1件ごとに持たせる項目の設計例です。項目名は例示なので、社内の呼び方に合わせて構いません。

このうち機密区分と閲覧可能グループは、付け忘れを許さない設計にします。空欄のまま索引に入れられる仕組みは作らず、値がなければ取り込みを止めます。「あとで付ける」は運用上ほぼ実現しません。機密区分の決め方は生成AIに入れてよい情報・いけない情報で整理しています。

AIに任せる範囲と、人が判断する範囲

RAGは自動化の仕組みに見えますが、設計上の重要な判断はすべて人が行います。

特に回答の採否は人の仕事です。RAGの出力は「原本を探す手間を減らす下書き」であって、そのまま社内外に出す成果物ではありません。

生成段に与えるプロンプト例

取得したチャンクを渡して回答を作らせる段階の指示例です。{取得したチャンク}にはメタデータ付きのテキストが入ります。

【役割・目的】
あなたは社内文書の検索補助です。以下の「参照文書」だけを根拠に回答し、
質問者が原本の該当箇所に短時間でたどり着けるようにしてください。判断そのものは行いません。

【参照文書】
{取得したチャンク}
（各チャンクには 文書ID／文書名／版数／適用開始日／所管部署／見出し経路／原本の位置 が付いています）

【質問】
{利用者の質問}　／　基準日：{YYYY-MM-DD}

【計算方法】
- 金額は参照文書に記載された単位（百万円・千円など）をそのまま使い、換算しない
- 単位の記載がない数値は「単位不明」と書き、推測して補わない
- 版の判定は「適用開始日 ≦ 基準日」を満たすもののみを有効とする

【出力形式】
1. 回答（3〜5文）
2. 根拠（主張ごとに1行。「主張 → 文書名 第○版 見出し経路（原本の位置）」の形式）
3. 参照した文書の一覧（文書ID・文書名・版数・適用開始日）
4. 確認が必要な点（後述の条件に当てはまるものを列挙）

【禁止事項】
- 参照文書に書かれていない内容を、一般知識や推測で補うこと
- 要約する過程で、条件・例外・除外規定を落とすこと
- 出典のない主張、および「一般的には」「通常は」といった根拠のない一般論を書くこと

【不明情報の処理】
参照文書から答えが確定できない場合は「参照文書からは確定できません」とだけ書き、続けて
(a) 不足している情報 (b) どの部署・どの文書に当たるべきかの見当 を書いてください。

【検算・自己点検】
回答を出す前に次を確認し、結果を「確認が必要な点」に反映してください。
- 参照文書に複数の版が含まれていないか。含まれる場合は版数と適用開始日を並べて示す
- 引用した条文に「ただし書き」「例外」「別に定める」がないか
- 数値を引用した場合、単位と対象期間が原文に明示されているか
- 参照文書が0件の場合は、回答を作らず「該当なし」と答える

【レビュー項目（人が確認する）】
- 提示された原本の位置を開き、引用が原文と一致するか
- 版数と適用開始日が、質問の基準日に対して正しいか
- 条件・例外が落ちていないか
- 権限上、質問者が閲覧してよい文書のみが参照されているか

要点は「参照文書が0件なら答えない」を明示していることです。ここを書かないと、検索が失敗したときにモデルが一般論で埋めます。出力の検証手順は生成AI出力の検証手順の型がそのまま使えます。

検索品質の測り方：評価セット30問で測る

改善したかどうかを数値で確かめる方法です。以下は架空の設例で、実測結果ではありません。架空の「城南トラスト銀行」が、与信関連の社内規程と稟議資料を対象にRAGを構築したとします。

評価セットの作り方

1. 現場から寄せられる質問の型を集め、30問を作ります
2. うち25問は社内文書に答えが存在する質問とし、1問ごとに「正解となる文書とその該当箇所」を人が事前に特定します
3. 残り5問は意図的に答えが存在しない質問にします。正解は「該当なしと答えること」です。ここを入れないと、推測で埋める癖を検知できません
4. 変更を加えるたびに同じ30問で測り直します

指標の定義

• 上位5件に正解が入った割合：検索の上位5件に正解の該当箇所が含まれた問 ÷ 25
• 「該当なし」正答率：実際に「該当なし」と答えた問 ÷ 5
• 合格回答率：「回答が原本と一致し出典の指定も正しい」または「正しく該当なしと答えた」問 ÷ 30

改善前の測定（設例）

共有フォルダを丸ごと索引化し、1,000文字の固定長で分割し、メタデータを付けていない状態です。

• 上位5件に正解が入ったのは25問中17問。17 ÷ 25 ＝ 0.68 ＝ 68.0％
• 外した8問の内訳：旧版が上位を占めた 3問／表が分割で壊れた 3問／社内略語が展開されず他部門の文書が上位に来た 2問（3＋3＋2＝8）
• その17問のうち、回答文と出典の指定まで正しかったのは14問（残り3問は条文の指定違いやページのずれ）
• 答えが存在しない5問のうち、正しく「該当なし」と答えたのは1問。1 ÷ 5 ＝ 0.20 ＝ 20.0％
• 合格回答は 14 ＋ 1 ＝ 15問。15 ÷ 30 ＝ 0.50 ＝ 50.0％

改善後の測定（設例）

対象を4つの文書群に限定し、見出し単位で分割し、メタデータ付与と現行版フィルタを既定にし、略語辞書を入れ、生成段に「根拠がなければ該当なしと答える」指示を明記した状態です。

• 上位5件に正解が入ったのは25問中22問。22 ÷ 25 ＝ 0.88 ＝ 88.0％
• 外した3問の内訳：表が壊れた 2問／略語が展開できなかった 1問（2＋1＝3）。版管理起因の失敗は0問になりました
• その22問のうち、回答と出典の指定がともに正しかったのは20問
• 答えが存在しない5問は5問すべて正しく「該当なし」と回答。5 ÷ 5 ＝ 1.00 ＝ 100％
• 合格回答は 20 ＋ 5 ＝ 25問。25 ÷ 30 ＝ 0.8333… ≒ 83.3％

検算

• 改善前：17（正解が上位5件に入った）＋ 8（外した）＝ 25 ✓／内訳 3＋3＋2 ＝ 8 ✓
• 改善後：22 ＋ 3 ＝ 25 ✓／内訳 2＋1 ＝ 3 ✓
• 合格回答：改善前 14＋1 ＝ 15、15 ÷ 30 ＝ 50.0％ ✓／改善後 20＋5 ＝ 25、25 ÷ 30 ＝ 83.3％（小数第2位を四捨五入）✓
• 改善幅：上位5件の割合は 88.0 − 68.0 ＝ ＋20.0ポイント、合格回答率は 83.3 − 50.0 ＝ ＋33.3ポイント（％ではなくポイントで表記します）

読み取ってほしいのは改善幅そのものではなく失敗の内訳が変わったことです。版管理起因の失敗が0になった一方、表の処理は残っています。次に手を入れるべき場所が内訳から一意に決まります。合計の数字だけを見ていると、この判断ができません。なお30問は「1人が半日で正解を作れる」現実的な下限で、1問あたり3.3ポイント動く粒度ですから細かい差は測れません。導入の段階を踏む順序は金融部門のAI導入ロードマップを参照してください。

RAG固有の検証方法

一般的な検証手順は前掲の出力検証の記事に譲り、ここではRAGでしか起きない項目に絞ります。

1. 出典リンクを実際に開く：文書名が正しくても、リンク先が別の文書・別の版であることがあります。リンク切れも含め定期的に抜き取り確認します
2. 引用と原文の一致を確認する：「第12条第2項では〜」と書かれた内容が原文と一致するか。要約の過程でただし書きが落ちるのが典型的な崩れ方です
3. 版と基準日の整合を確認する：提示された版の適用開始日が、質問の基準日以前になっているか
4. 権限の確認：権限の異なる複数のテストアカウントで同じ質問を投げ、見えてはいけない文書が出ないことを確認します。機能追加のたびに必ず再実施します
5. 「該当なし」と削除の確認：存在しない社内制度について質問して推測で答えないことを、削除・失効させた文書について質問して索引から消えていることを確認します
6. 数値の再計算：財務数値を含む回答は原本から計算し直して照合します。指標の計算を手元で確かめるには、ブラウザで計算できるモデリングラボのような環境で再計算し突き合わせる方法があります

1〜3は毎回、4〜5は変更のたび、6は数値を扱う回答すべてで行う、という頻度の設計が扱いやすいと考えられます。

機密情報・個人情報の注意

RAGは仕組み上、社内の機密文書を索引という新しい入れ物に複製します。原本の管理が適切でも、索引側の管理が甘ければそこが最も弱い箇所になります。索引の保管場所・アクセス権・保存期間・削除手順を、原本と同じ水準で定めてください。

個人情報を含む文書を対象にする場合、個人情報保護委員会は、生成AIサービスに個人情報を含むプロンプトを入力する際には利用目的の達成に必要な範囲内であることを十分に確認すべきことなどを注意喚起しています（令和5年6月2日）。顧客情報が含まれる文書は、そもそも索引に入れるかどうかから検討が必要です。区分の作り方は前掲の機密管理の記事で扱っています。本記事の設計では、その区分をメタデータとして持たせ、検索の手前で効かせる形にしています。

よくある失敗

1. 全社の文書を無差別に索引化する：範囲が広いほど良いと考えて共有フォルダごと投入する。下書き・重複・失効文書が正解を押し下げ、権限の事故リスクも最大化します。1業務・1文書群から始めるのが確実です
2. 機密区分を付けずに投入する：空欄のまま取り込む。運用が始まると誰も遡って付けません。値がなければ取り込めない仕組みにしてください
3. 出典を出さずに回答させる：使い勝手を優先して出典表示を省く。回答が正しいかを誰も確認できず、結局は使われなくなります。出典表示は付加機能ではなくRAGの目的そのものです
4. 取得できなかった情報を推測で埋めさせる：検索が0件のときに「一般的には〜」と答えさせる。社内規程の質問に一般論が返るのは、誤りより悪い結果を招きます
5. 評価をせずに改善したつもりになる：担当者の実感だけで判断する。前処理を変えた副作用で別の質問が壊れても気づけません

実務チェックリスト

• 索引に入れる文書群を業務単位で列挙し、所管部署の承認を得た
• 各文書群について、分割の単位（条・項・スライド・表）を決めた
• チャンク1件ごとに、文書種別・版数・適用開始日・所管部署・機密区分・閲覧可能グループを付与し、空欄なら取り込みが止まる仕組みになっている
• 案件限定の文書は、全社向け索引から除外されている
• 検索は、候補を取得する前に権限で絞り込んでいる
• 権限外の文書について、件数や存在自体も応答に含まれない
• 既定で現行版のみが検索対象になり、基準日を指定すれば過去版も引ける
• 旧版のメタデータに後継版のIDが入っている
• 表は1つの表を1チャンクとし、見出し・単位・期間を先頭に添えている
• 社内略語と案件コードネームの対応表を用意し、対応表自体の閲覧を制限している
• 出典は文書名・版・条またはページ・原本リンクの4点を返している
• 参照文書が0件のときは「該当なし」と答える指示が入っている
• 評価セット（正解あり・正解なしの両方を含む）を作り、変更のたびに測り直している
• 質問・利用者ID・取得した文書IDと版・提示した出典・人の採否をログに残している
• 規程の改訂・契約の失効・案件クローズを索引へ反映する手順と担当が決まっている

日本企業・日本市場での留意点

制度面では、金融庁が2025年3月に「AIディスカッションペーパー（第1.0版）」を、2026年3月3日に第1.1版を公表しています。これは金融分野におけるAIの健全な利活用に向けた論点整理であり、規制そのものではありません。総務省・経済産業省の「AI事業者ガイドライン」も2026年3月31日に第1.2版が公表されていますが、法令ではなく事業者向けの指針です。拘束力の有無と対象主体を混同しないことが社内説明では重要になります。EUのAI法など海外の制度は対象主体も義務も異なるため、日本の実務と同一視しないでください。

実務面では、社内規程が独自様式のPDFでテキスト化の品質がばらつくこと、「第○条第○項第○号」と階層が深く号まで示さないと特定できないこと、旧字体・異体字（髙・﨑など）が社名・人名の検索を妨げることが日本語文書に固有の事情です。いずれも前処理で吸収します。加えて文書の所管が部署ごとに分かれるため、対象範囲を決める段階で部署横断の合意が要り、技術検証よりここに時間を要することが多いと考えられます。

よくある質問（FAQ）

Q. 検索で取得する件数は何件にすべきですか

本記事の設例では上位5件を基準にしましたが、これは「人が現実に確認できる件数」からの逆算です。件数を増やせば正解が含まれる確率は上がる一方、関係のない文書も混ざり、生成段でどれを使うかの判断が難しくなります。まず少ない件数で測り、外した問の内訳を見てから増やすかを決める順序を提案します。

Q. RAGを入れれば、AIが事実と違うことを言う問題はなくなりますか

なくなりません。参照文書を指定すれば根拠のない内容が混じる余地は減りますが、次の3つは残ります。①検索が的外れで無関係な文書を根拠にする。②正しい文書を引いたのに要約で条件や例外を落とす。③参照文書自体が古い、または誤っている。①②は本記事の設計と評価で減らせますが、③は文書管理の問題でRAGでは解決できません。出典が付いていることと、内容が正しいことは別です。

まとめ

金融部門でRAGを実装するときに効くのは、モデルの選択ではなく前処理と権限設計です。

• 範囲を絞る：1業務・1文書群から始め、共有フォルダを丸ごと索引化しない
• 権限を2か所で効かせる：構築時と実行時。取得の前に絞り込む
• 版と適用開始日を持たせる：出典付きで旧版を返すのが、最も見抜きにくい失敗です
• 表は表として扱う：1つの表を1チャンクにし、見出し・単位・期間を添える
• 出典は原本に到達できる粒度で：文書名・版・条またはページ・原本リンクの4点
• 根拠がなければ答えさせない：参照文書0件のときの応答を定義する
• 評価セットで測る：正解あり・なしの両方を含め、失敗の内訳から次の一手を決める

設計を先に固めておけば、使う製品が変わっても作り直しにはなりません。逆に範囲と権限を決めないまま製品から入ると、動くものはできても運用に載りません。まずは1つの業務で、図2の設計表と30問の評価セットを作るところから始めてください。生成AIをファイナンス実務に組み込む全体像は生成AI×ファイナンス実務で概観できます。

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

• 金融庁「AIディスカッションペーパー（第1.1版）の公表について」令和8年3月3日（第1.0版は2025年3月公表）
• 総務省「AI事業者ガイドライン」掲載ページ（第1.2版・令和8年3月31日、総務省・経済産業省）
• 個人情報保護委員会「生成AIサービスの利用に関する注意喚起等について」令和5年6月2日
• 金融商品取引業等に関する内閣府令（平成19年内閣府令第52号）第123条「業務の運営の状況が公益に反し又は投資者の保護に支障を生ずるおそれがあるもの」（e-Gov法令検索）
• Lewis, P. et al. “Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks”, arXiv:2005.11401（2020年）※RAGという用語の出典
• 本記事の設計表・チェックリスト・評価セットの設計・数値例は編集部による提案および仮設例であり、特定の実装や実測結果に基づくものではありません。

※本記事は教育目的の一般的な解説であり、法務・税務・会計・投資に関する助言ではありません。実際の判断は専門家にご確認ください。設例は理解のための仮設例です。AI製品の仕様・料金は変更されることがあるため、利用前に各社の公式情報をご確認ください。