RAGとは｜検索拡張生成の仕組み・構成要素と評価、権限管理【2026年版】

RAG（Retrieval-Augmented Generation、検索拡張生成）は、必要な資料を検索し、その情報を大規模言語モデル（LLM）の回答生成へ渡す構成です。社内文書や製品資料を参照する用途で検討できますが、検索の成否、資料の版、利用権限と生成内容を確かめる設計が必要です。仕組みと構成要素、評価から導入・運用までを整理します。

RAGとは：検索した情報を生成へ渡す仕組み

RAGは、モデルが学習で得た情報に加えて、回答する際に検索した情報を使う考え方です。Lewisらの論文（2020年公開、2021年改訂）の要旨では、生成モデルと検索でアクセスする外部の記憶を組み合わせる構成を示しています。同論文の実験結果と、現在の自社文書を扱うシステムの品質は分けて評価します。RAGという名称だけで、あらゆる業務に同じ効果が出るとは言えません。

例えば社内規程の質問では、対象の規程と該当する箇所を探し、質問と一緒にLLMへ渡し、回答と参照先を利用者へ示す流れが考えられます。このとき、検索されなかった例外条項や古い版、質問の対象と異なる部門の規程があると、適切な判断材料がそろいません。引用先が表示されても、その箇所が回答の主張を実際に裏付けるかを確かめる必要があります。

文書の参照と、モデルへの追加学習も区分します。Amazon Bedrockのモデルカスタマイズの説明では、教師ありファインチューニングで入力と出力の学習例を用い、モデルのパラメータを調整することを案内しています。RAGは回答時に参照する情報を取得する構成で、ファインチューニングは特定のタスクに合わせてモデルを調整する手法です。両者を一律に費用や正確さで順位付けせず、更新される情報の参照と、出力形式や振る舞いの課題を整理して選びます。

「LLMには非公開資料を使えない」という説明も適切ではありません。許可した文書を入力へ含める方法、検索する方法、学習に利用する方法では、目的とデータの流れが異なります。RAGを使う場合も、検索サービス、モデルの提供先、履歴や一時保存を含め、どこへ何を渡すかを確認します。データの利用条件や契約、閲覧権限が、検索の仕組みを入れるだけで満たされるわけではありません。

導入の最初には、質問に必要な資料の所在と、誰がどの範囲を参照できるかを整理します。ファイルの版や責任者が定まっていない場合は、正本と更新手順をそろえる作業も対象になります。法人契約やデータの扱いから検討する場合は、社内ChatGPTの導入とデータ・権限管理も参考にしてください。

RAGの処理と構成要素：取り込み・検索・回答をつなぐ

資料を準備し、検索に必要な情報を持たせる

取り込み型の構成では、文書から必要な内容を抽出し、検索しやすい単位へ分割して登録します。分割した断片をチャンクと呼びます。本文だけでなく、文書名、参照先、版や適用日、所属・権限などの情報を合わせて管理する設計が考えられます。更新と削除が検索側へ反映されたかも確認します。資料の置き場所で変更したことと、回答が参照する内容を更新したことは同じではありません。

Azure AI Searchの文書分割ガイドは、固定長、文書構造や意味のまとまりなどによる分割を説明しています。見出しや例外条件、表の対応が切れていないかを実際の資料で確認します。一定の文字数を全資料へ当てはめたり、日本語の文字数をそのままモデルのトークン数と見なしたりせず、利用するモデルと内容に合わせて評価します。

質問から候補を取得し、必要な順序へ並べる

検索には、用語や品番などの一致を見る方法と、埋め込みと呼ぶ数値表現の類似性を見る方法、それらを組み合わせる方法があります。検索基盤はベクトル専用データベースに限定されません。Azure AI SearchのRAG概要は、キーワードとベクトルを組み合わせるハイブリッド検索や、候補の順位を調整する構成を示しています。再順位付けの導入も、該当資料を見つけられるかと処理時間・費用を比べて判断します。

同概要は、アプリケーションが検索とLLMへの受け渡しを組み立てる従来型と、LLMによる検索計画を含むエージェント型を区別しています。プレビューの機能も含まれるため、紹介されている構成すべてを一般提供済みの標準機能として扱いません。要件が単純なときも含め、必要な機能と提供条件を確認して選びます。

取得した根拠を回答へ渡し、参照先を示す

Amazon Bedrock Knowledge Basesの検索の説明では、資料を取得するRetrieveと、取得・生成を組み合わせ引用を含めるRetrieveAndGenerateを区別しています。検索だけを点検するか、生成までを組み合わせるかを分けられます。自社実装でも、検索した断片と参照先、生成へ渡した範囲を対応させ、利用者が原文へ戻って確認できる出力にします。フレームワークはこれらを組み立てる選択肢であり、特定の製品の併用やプログラミング言語だけで運用が決まるものではありません。

検索と回答を別々に評価し、誤りの原因を探る

RAGの評価では、まず検索が必要な根拠へ到達したか、その根拠から適切な回答を作れたかを分けます。Amazon BedrockのRAG評価の説明も、取得だけを対象にする評価と、取得・生成を対象にする評価を区別しています。文章の読みやすさだけを採点しても、参照すべき資料の欠落や権限の問題は十分に見えません。

確認する段階	確認する例	見直す場所の例
取り込み	対象の文書と版が登録されているか	対象範囲、抽出、更新・削除の処理
検索	必要な根拠が候補に入るか	分割、表記、検索方法、絞り込みと順位
生成	回答と引用先が対応するか	渡す範囲、指示、回答できない場合の動作
利用	確認や引き継ぎを含め業務で使えるか	画面、責任者、原文確認と修正の導線

以下は自社の評価設計を考えるための例です。社内規程なら、通常の質問に加えて、例外条項、旧版と新版の違い、対象部門による適用の違い、資料に答えのない質問を用意します。必要な根拠が取れない場合に、推測を断定せず不足を伝えられるかを確認します。複数の資料が矛盾する場合は、どの版や責任者へ確認するかを利用者へ案内できる状態を目指します。

評価用の質問には、期待する答えだけでなく参照すべき資料と対象条件を残します。検索方法や分割の設定、モデルを変更したときは、同じ質問で比較するとともに、新しく想定した業務への影響も見ます。平均の成績が上がっても、重要な質問や閲覧してはいけない資料の扱いが悪化していないかを個別に確認します。資料に登録のない事実や社外の情報まで、すべて正しく答える評価へ混ぜません。

日本語資料では、社内用語、略称、製品名、数字や記号、表の読み取りなど、実際に起きる質問を含めて確認します。「日本語対応」の表示だけで自社資料への適合を確定せず、修正後の再評価までを運用に入れます。研究や技術資料を扱う場合は、製造業の先行技術調査で検索と原文確認を分ける進め方も、資料の取得と最終判断を整理する参考になります。

権限と更新を運用へ組み込み、RAGの導入範囲を決める

社内資料を登録したRAGでは、誰でもログインできることと、その人が文書を閲覧できることを分けます。Azure AI Searchの文書単位のアクセス制御は、文字列のセキュリティフィルターと、権限情報を使うプレビュー機能などを区別しています。後者も検索側へ同期された権限情報を評価する構成で、元システムの権限変更が即時に全検索へ反映されるとは限りません。データソースと方式ごとの条件を確認します。

自社の設計では、確認された利用者情報を検索の制約へ結び付け、許可されない文書の断片や参照先を回答・画面・ログへ出さない範囲を点検します。異動や退職、共有解除、文書の削除で何が変わるかも確認する対象です。権限情報が更新できない場合に、どの検索を止め、誰へ連絡するかを決めます。モデルへの文章上の指示だけを閲覧権限の仕組みとして扱わず、検索と表示の経路で検証します。

Amazon Bedrockの取得処理の注意事項は、Guardrailsが入力と生成回答へ適用され、実行時に取得された参照情報へは適用されない点を明記しています。保護機能を有効にすることと、検索結果や参照先まで扱える範囲を確認することを分けます。サービス名や機能名だけで情報管理が完了したとせず、契約と保存条件、認証、権限、外部接続を含む流れを確認します。

費用は、文書の抽出・更新、検索基盤、モデルの呼び出し、監視、評価と修正、利用者への案内を含めて検討します。対象文書数だけで見積もらず、更新頻度、質問数、必要な応答時間、権限連携と確認作業をそろえます。試験導入の段階で、使える質問の範囲と失敗時の対応、本番へ進む条件を決める方法は、PoCの評価基準と本番移行の判断で整理しています。

文書の取り込みから検索・回答、評価と社内システムへの連携を自社向けに実装する範囲は、renueのFDEへ相談できます。資料の所在、利用者、権限、更新担当と困っている質問を共有し、接続条件や運用まで具体化します。認証・権限や外部接続を含む診断・改善が必要な場合は、AI脆弱性診断支援サービスで対象と検証環境を合意して進めます。RAGの導入とシステムの診断、それぞれで何を確かめるかを明確にします。