RAG構築の進め方：社内文書で答える生成AIの設計・精度評価・閉域運用

RAG（検索拡張生成）とは

RAG（Retrieval-Augmented Generation、検索拡張生成）とは、質問を受けるたびに社内文書やデータベースから関連する箇所を検索し、その内容を根拠に大規模言語モデル（LLM）に回答を生成させる仕組みです。LLMが学習していない社内規程、製品マニュアル、契約書、問い合わせ記録などに基づいて答えられるため、社内文書を扱う生成AIの代表的な構成です。

原典は2020年にLewisらが発表した論文で、事前学習済みの言語モデル（パラメトリックメモリ）と、検索で参照する文書の索引（ノンパラメトリックメモリ）を組み合わせた言語生成モデルとしてRAGを提案しました。総務省・経済産業省の「AI事業者ガイドライン（第1.2版）」の別添もこの定義を引き、企業で社内文書やデータベースを検索して回答の精度を高めるために使われているとしています。

同じ別添は期待される効果として、ハルシネーション（もっともらしい誤り）の抑制、参照元の明示による根拠の透明性の向上、再学習なしにデータソースを追加できることによるコストの低減を挙げています。用途は業種を問いません。

• 製造：保守マニュアルや故障対応記録から、手順と該当ページを示して答える
• 法務・購買：契約書や取引条件書から該当する条項を探し、引用する
• カスタマーサポート：製品仕様書やFAQから、根拠付きの回答案を作る
• 社内ヘルプデスク：就業規則、経費規程、情報セキュリティ規程の質問に答える
• 金融：事務手続や商品説明資料、規程類を横断して照会に答える

RAGの仕組み：取り込み・検索・生成の3段階

RAGは、文書を検索できる形に整える「取り込み」、質問に関係する箇所を探す「検索」、見つけた箇所を根拠に答えを書く「生成」の3段階で動きます。誤りは生成の段階で目に付きますが、原因は前の2段階にあることが少なくありません。

1. 取り込み（索引の作成）：PDF、Word、社内Wikiなどからテキストを抽出して「チャンク」と呼ぶ短い単位に分け、埋め込みモデルでベクトルに変換して、文書名、版、閲覧権限などのメタデータとともにベクトルDBや検索エンジンに登録します。
2. 検索：質問も同じ埋め込みモデルでベクトルに変換し、意味の近いチャンクを上位から数件取り出します。キーワード検索の併用や、候補の再ランキングを加えることもあります。
3. 生成：取り出したチャンクを質問とともにLLMに渡し、「与えた資料の範囲で、出典を付けて答える」よう指示して回答を生成します。

Lewisらの実験では、Wikipediaを重なりのない100語ごとのチャンクに分け、約2,100万件の索引を作りました。そのベクトルをCPUメモリに置くには約100GBが必要で、圧縮により36GBまで減らせたと報告されています。オンプレミスで構築するなら、LLMを動かすGPUに加えて、索引を置くメモリやストレージも見積もります。

同論文は、2016年12月版と2018年12月版のWikipediaの索引を入れ替える実験も行いました。その間に交代した82人の各国首脳を尋ねると、索引と時期が一致すれば正答率は70%（2016年）と68%（2018年）、一致しなければ12%と4%でした。再学習なしに索引の差し替えだけで知識を更新できることは、規程や製品情報が頻繁に変わる企業がRAGを選ぶ大きな理由です。

RAGとファインチューニングの違いと使い分け

社内の知識に基づいて答えさせたいなら、まずRAGを検討します。ファインチューニングは追加学習でモデルの重みを調整する手法で、文体や出力形式、特定タスクへの適応には向きますが、知識の更新には再学習が必要で、回答の根拠となる文書も示しにくいからです。Lewisらも、知識をパラメータだけに持つモデルでは、根拠の提示と知識の更新が未解決の課題だと述べています。

IPAのガイドラインは、2024年6月時点では導入の難しさの点でもRAGが優位で、組織での活用がより現実的だとする見方を紹介しています。両者は排他的ではなく、RAGで知識を与え、ファインチューニングで出力形式を整える組み合わせもあります。米国国立標準技術研究所（NIST）の生成AIプロファイル（NIST AI 600-1）は、どちらを実装した後にもモデルのリスクを再評価するよう求めています。

RAGの精度を上げる設計：文書、分割、検索、指示

RAGの精度は、モデルの性能より先に、検索対象の文書の質と検索の設計で決まります。IPAのガイドラインは、ノイズが含まれる情報、重複した情報、最新版ではない古い情報がベクトルDBにあると、ハルシネーションや誤った回答につながるとしています。AI事業者ガイドラインの別添も、RAGの精度は利用する情報に依存するため、信頼性の高いデータソースを使い、品質を定期的に管理・監視する必要があるとしています。

文書を整える

• 対象を絞る：最初は一つの業務、一つの文書群に限り、正本（最新版）の場所を確定させる
• 旧版と重複を除く：改訂前の規程や複製を索引に入れず、版と施行日をメタデータに持たせる
• 抽出の品質を確かめる：スキャンしたPDFの文字認識、表、段組みが崩れていないかを抜き取りで確認する
• 権限情報を付ける：文書ごと、必要ならチャンクごとに、閲覧できる部署や役職を持たせる

分割と検索を設計する

チャンクは見出し、条、手順といった意味の切れ目で分け、文書名や見出しを付けて、切り出しても文脈が分かるようにします。日本語は単語の間に空白がないため、長さは語数ではなく文字数やトークン数で管理します。前後を少し重ねて、切れ目での欠落を防ぐ方法もあります。

検索はベクトル検索だけに頼らず、キーワード検索（BM25など）との併用を検討します。Lewisらの実験でも、固有名詞が中心の事実検証タスク（FEVER）ではBM25による検索が最も良い結果でした。型番、条番号、製品名、取引先名を含む質問では、キーワードの一致が効きます。

LLMに渡すチャンクの件数も調整項目です。Lewisらは、取り出す文書の数で性能と処理時間の両方が変わると報告しています。多く渡せば取りこぼしは減りますが、RAGASの論文が指摘するように、文脈が長すぎるとLLMはそれを活かしにくく、コストも増えます。

回答の指示を決める

• 与えた資料の範囲で答え、資料にないことは「見つからない」と答えさせる
• 出典（文書名、版、ページや条番号）を付けさせ、利用者が原文を確かめられるようにする
• 出力の形式（結論、根拠、注意点など）を固定し、必須項目の欠落をプログラムで検査する

OWASP Top 10 for LLM Applications 2026も、LLM07（誤情報）の対策として、信頼できる最新の情報源による裏付けと、必須項目を持つ構造化出力による欠落の防止を挙げています。

RAGの精度評価：検索と生成を分けて測る

RAGの精度は、「必要な文書を検索できたか」と「その文書に忠実に、質問に答えたか」を分けて測ります。「回答が良かったか」だけでは、誤りの原因が検索と生成のどちらにあるのか分からず、改善の打ち手が決まりません。

RAGの自動評価の枠組みを提案したRAGASの論文は、次の3つの観点を中心に据えています。

• 忠実性（Faithfulness）：回答が、与えられた文脈（検索した文書）に根拠を持っているか
• 回答の関連性（Answer Relevance）：回答が、実際に尋ねられた質問に答えているか
• 文脈の関連性（Context Relevance）：検索した文脈が質問に絞られ、無関係な情報をできるだけ含まないか

検索そのものは、正解の根拠となる文書やチャンクが上位数件に入る割合で測ります。業務では、引用した箇所が本当にその内容を述べているか（出典の正しさ）と、資料にない質問に「見つからない」と返せるかも確かめます。

評価セットの作り方

1. 実際の質問を集める：問い合わせ履歴やヘルプデスクの記録から、よくある質問と、誤ると影響の大きい質問を選ぶ
2. 正解の根拠を付ける：質問ごとに、根拠の文書と箇所、模範回答を業務の担当者が記入する
3. 難しい質問を混ぜる：資料にない質問、旧版と新版で答えが変わる質問、複数の文書をまたぐ質問を入れる
4. 変更のたびに測り直す：文書、分割方法、埋め込みモデル、LLM、指示文を変えたら、同じ評価セットで比べる

NIST AI 600-1は、狭く体系的でない、逸話的な評価から生成AIの性能を推し量らないよう求め、導入前と運用中の両方で出力の出典や引用を確認・検証するよう示しています。数問を試して本番に進むのではなく、結果を記録し、合格の基準を先に決めておくことで、品質を説明できるようになります。

RAGのセキュリティ：権限、間接プロンプトインジェクション、ベクトルDB

RAGに固有の論点は、検索対象の文書が、LLMへの新しい入力経路であり、新しい漏えい経路にもなることです。OWASPが2026年8月に公開した「OWASP Top 10 for LLM Applications 2026」は、LLM01（プロンプトインジェクション）、LLM02（機微情報の漏えい）、LLM09（ベクトルと埋め込みの弱点）などで、RAGに関わるリスクと対策を示しています。

権限についてOWASPの指摘は明確です。類似度による検索はアクセス制御リストを考慮せず、一度LLMに渡したチャンクは後から取り消せないため、検索後に画面側で絞り込むのでは遅すぎます。認可は検索の前に索引への問い合わせの内側で行い、機密度の高い用途ではテナントや信頼区分ごとに索引を物理的に分けます。ほぼ公開情報の文書にも機密の段落はあり得るため、制御の単位はチャンクです。

IPAのガイドラインも、機密情報をベクトルDBに格納すると全ての利用者が参照できてしまうことをRAGの課題に挙げ、情報の重要度ごとに参照できる利用者を設定する方法を紹介しています。同ガイドラインの2024年3月から5月のヒアリングでは、部門やプロジェクトの単位で利用申請を受け、領域を分けて格納する運用が多く見られました。

間接プロンプトインジェクションについて、OWASPは、わずか5件の細工した文書で、数百万件規模の知識ベースに対し約90%の攻撃成功率に達した研究（Zouら、2025年）を紹介しています。社内向けでも、取引先のファイル、応募書類、問い合わせメールなど社外の人が書いた文章を取り込めば、同じ経路が生まれます。AI事業者ガイドラインの別添も、参照するデータの不正な変更を早期に検出するため、定期的な管理・監査を検討するよう求めています。

クラウドAPI、閉域、オンプレミス（ローカルLLM）の選び方

RAGの配置は、LLMと索引をどこで動かすかで大きく3つに分かれます。基準は、文書の機密度と社外に送ってよいか、利用量、必要なモデルの性能、自社でGPUとモデルを運用できる体制です。

クラウドAPIでも、送るデータは最小限にします。OWASPは、外部の事業者には業務に必要な項目だけを送ること、入力を学習や保存に使わないことを規約の文言だけに頼らず技術的に担保することを挙げています。

自社の環境で動かすローカルLLMは、文書と質問を社外に出さずに済む一方、モデルの規模が自社のGPUに左右されます。日本語に強いモデルでは、国立情報学研究所（NII）の大規模言語モデル研究開発センターが主宰するLLM-jpが、オープンで日本語に強いモデルの構築を掲げてモデルを公開しています。NTTのtsuzumi 2は、40GB以下のメモリを持つGPU1枚での動作を想定した軽量モデルで、2025年10月に提供が始まりました。ライセンスと利用条件はモデルごとに確認します。

どの配置でも、索引とそのバックアップ、ログの置き場所はLLMと同じ基準で決めます。OWASPは、埋め込みから元の文章を復元できるため、ベクトルDBのバックアップを原本と同じ機密区分で扱うよう求めています。LLMだけを閉域に置いても、索引やログが外部のサービスにあれば、データは社外に出ています。

RAGの運用：文書の更新、監視、再評価

RAGは作って終わりではなく、文書の更新と評価を回し続ける仕組みです。IPAのガイドラインは、精度の維持には、ベクトルDBの情報を定期的に更新し、できるだけ最新で重複のない状態に保つことが重要だとしています。

• 更新を仕組みにする：正本の保存場所と索引を連携させ、改訂や廃止をすぐ反映する。元の文書を削除したら、その埋め込みも期限内に削除する
• 埋め込みモデルを替えたら全件を作り直す：OWASPは新旧のベクトルを混在させないよう求めている
• 検索の記録を残す：どの権限で、どの質問に、どのチャンクが返ったかを改ざんできない形で記録する
• 利用者の声を集める：回答への評価と答えられなかった質問を集め、文書の追加や評価セットの更新につなげる
• 定期的に測り直す：モデルや設定を変える前後にも、評価セットで結果を比べる

利用者への説明も運用の一部です。IPAのガイドラインは、「RAGを使えばどんな質問にも正しく答えられる」といった誤解を例に、期待と実際のギャップを指摘しています。AI事業者ガイドラインの別添は、RAGで回答が画一的になりやすいため、多様性や独創性が求められる業務には適さない場合もあるとしています。

RAG構築の進め方：6つのステップ

最初のRAGは、範囲を絞って小さく作り、評価で確かめてから広げます。進め方の目安は次のとおりです。

1. 用途と範囲を決める：誰のどんな質問に答えるのか、対象の文書群と、答えてはいけないことを明確にする
2. データとリスクを棚卸しする：文書の正本、版、機密区分、閲覧権限を整理し、社外に送れるかで配置を決める
3. 評価セットを先に作る：実際の質問と正解の根拠を業務の担当者と用意し、合格の基準を決める
4. 試作して測る：取り込み、分割、検索、指示文を組み、評価セットで測りながら改善する
5. セキュリティを検証する：権限を越えた参照、間接プロンプトインジェクション、ログの扱いを本番前に試験する
6. 限定して公開し、広げる：対象部署を限って公開し、利用者の評価と検索の記録をもとに直してから広げる

findnの支援

findnは、システム開発サービスの一つとして、社内データに基づいて回答するLLMアプリケーション（RAG）とAIエージェントの開発を支援しています。日本語LLMを含むモデルの選定とカスタマイズ、閉域・オンプレミスでの配置、評価、ガードレール、LLMOpsまでを対象とし、要件定義から設計、テスト、運用までを、ISO/IEC 27001:2022の認証を取得した体制で進めます。