RAGを工程の連なりとして管理する：文書投入から回答までの基本

2026年10月15日2026年10月25日

URLをコピーしました！

公開日: 2026年10月15日

RAGの回答を管理するには、文書を登録した後も、検索対象、利用者の権限、適用する版、回答を支える箇所をつなげて追えるようにします。必要な根拠が検索で得られなければ生成前に止め、根拠は渡せたのに回答が違えば生成後の確認で止めます。文書の準備、検索、回答の生成を分けて見れば、誤答の修正先を絞れます。

文書を入れるだけでは終わらない

RAGはRetrieval-Augmented Generation、検索拡張生成の略です。質問に関係する資料を取得し、その内容を生成モデルへ渡して回答を作る構成を指します。Lewisらの原研究は、モデルのパラメータに蓄えた知識と、検索可能な外部の知識を組み合わせる方式を扱いました。原研究はWikipediaの索引などを使う特定の構成であり、現在の全RAGに自動引用や正確性が備わるという意味ではありません。Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks

業務で管理する対象は、原文から検索用データを作る工程と、質問から回答を作る工程の両方です。前者で失った例外条件を、後者の丁寧なプロンプトだけで取り戻せるとは限りません。利用者が閲覧できない文書を渡した後に「回答には出さないで」と頼む方法にも依存できません。

以下は文書型の社内FAQを想定した管理の分け方です。すべてのシステムがこの順番の独立機能を持つという公式規格ではなく、統合された処理でも、何を受け取り何を渡したかを確認するための見取り図として使います。

文書と質問が回答へ届くまで

文書を検索できる形へ整える

文書投入では、本文に加えて、文書ID、版、適用期間、発行部門、閲覧可能な利用者や役割を受け取ります。こうした本文を説明する情報をメタデータと呼びます。投入してよい資料か、FAQ回答へ利用してよいかも、取り込む前に確認する前提です。

次に、検索やモデル入力で扱える単位へ文書を分割します。この単位がチャンクです。見出し、条項、表、注記の関係を失うと、検索では本文だけが見つかり、直後の例外が回答に届かないことがあります。Microsoftの文書分割ガイドは固定長や構造・意味に応じた分割を紹介しています。分割後も、チャンクから元の文書と位置へ戻れるようにしておきます。Chunk large documents for RAG and vector search in Azure AI Search

ベクトル検索を使う場合は、チャンクの内容を数値の並びへ変換するEmbedding、埋め込みを作ります。質問も対応する方法で変換し、数値表現の近さから候補を探します。Microsoftのガイドでも、質問と文書に同じ埋め込みモデルを使うことを推奨しています。モデル名や設定を記録し、文書側だけ更新した状態で質問側と混用しないかを確認します。Create a vector query in Azure AI Search

埋め込みは意味の近さを探すための表現で、文書の正しさ、適用する版、閲覧許可を証明するものではありません。原文と条件は別に保持します。キーワード検索を中心にする構成では埋め込みを使わない場合もありますが、原文への対応や権限確認は残ります。

質問に必要な根拠を選び、回答へ渡す

質問を受けたら、誰が何について、いつの条件で尋ねているかを定め、許可された範囲から検索候補を取ります。候補に権限外の内容が混ざったら、並べ替え用のモデルや別サービスへ送る前に除外します。その上で、必要に応じてRerank、リランクを行います。これは候補と質問の関係を改めて評価し、並べ替える処理です。Sentence Transformersの例では、まず候補を取得し、次に質問と候補の組を評価します。並べ替えるだけなら、最初の候補にない文書は増えません。Retrieve & Re-Rank

その後、モデルへ渡す文脈、つまりコンテキストを構成します。対象と時点に合う箇所、必要な例外、文書IDと版、引用位置を選び、入力可能な量に収めます。候補一覧に存在したことと、実際のモデル入力に残ったことは違います。重複除去や文字量の調整で必要な注記が消えた場合も、ここで確かめます。

工程	入力から出力への変化	一緒に渡す・照合する情報
文書投入	原文から利用対象文書へ	利用目的、文書ID、版、適用期間、権限
分割	文書からチャンクへ	原文位置、見出し、例外との関係、文書の条件
埋め込み・索引化	チャンクから検索用データへ	チャンクID、原文への対応、モデル・索引の版
検索	質問と条件から候補集合へ	利用者、対象、基準時点、認可結果
並べ替え	候補集合から順位付き候補へ	残した候補ID、除外理由、必要根拠の有無
文脈構成	候補から実際のモデル入力へ	採用した版・箇所、例外、権限の再確認
生成・出力確認	質問と根拠から引用付き回答へ	主張と根拠箇所の対応、未確認部分、表示先の権限

権限確認は、表の一か所だけで完了する仕事ではありません。OWASPのRAG向けガイダンスは、取得時のアクセス制御、元文書からの権限継承、出所の追跡、出力確認を扱っています。生成モデルへ渡す前に許可外の内容を除外する必要があり、引用先や利用者が読めるログにも同じ境界を保つ設計にします。RAG Security Cheat Sheet、Access Control Inheritance・Source Attribution and Provenance・Output Validation and Enforcement

架空の社内FAQで、版と権限をつなぐ

架空の会社で、社員が「10月の国内出張では、宿泊費の上限はいくらですか」と尋ねる場面を考えます。実システムでの試験ではなく、工程の確認例です。対象を一般社員の通常出張、適用基準を出張日とする架空規程を前提にします。

文書庫には、9月30日まで適用する旅費規程第2版と、10月1日以降に適用する第3版があります。第3版の第4条には「国内出張の宿泊費は一泊12,000円を上限とする」、直後の注記には「指定地域は別表による」とあると仮定します。また、人事部だけが閲覧できる個別精算の文書もあります。

投入時に版と適用期間、権限を記録し、分割後も第4条から注記と別表へたどれるようにします。検索時は社員の権限と10月の出張条件を使い、第3版を候補に残します。人事部限定の個別精算を検索できたとしても、この社員の回答を作る文脈には入れません。権限確認に失敗した場合は、認可が確認できるまで該当内容を先へ送らない設計にします。

質問には出張先がないため、通常地域の上限だけでは最終判断ができません。第4条と注記を取得できた場合の期待回答は、「通常地域は一泊12,000円が上限です。指定地域は別表が適用されるため、出張先を確認する必要があります。根拠：旅費規程第3版第4条・注記」です。別表を未取得なら、その内容も未確認として示します。すべての地域で同額だと補いません。

引用表示からは、権限のある原文の第3版第4条へ戻れるようにします。モデルが書いた文書名だけを採用せず、実際に渡した箇所と対応するかを確認します。この架空例では版名・条項名で示しましたが、実装では利用者が開ける確認済みのリンクや文書識別子を使います。

条件が変わったら、どこで止めるか

第3版が未投入なら、検索結果が空でなくても回答に必要な版は不足しています。第2版の金額で埋めず、文書管理者へ投入状況を確認します。第3版を投入済みなのに候補へ出ないなら、索引への反映、対象条件、検索語、権限判定を順に調べます。原因不明の段階で権限条件を緩めて検索を続けることはしません。

第3版が候補に出ても、文脈を短くするときに注記が落ちたなら、文脈構成へ戻します。注記まで渡したのに回答が「全地域で12,000円」となったなら、生成後の出力確認で差し戻します。どちらも誤答につながりますが、直す工程は異なります。

権限外の文書が混ざった場合は、一般的な検索漏れの改善より先に、以後の受け渡しを止めます。どこまで渡ったかは記録で確認し、候補に出ただけなのか、モデル入力や利用者向け表示まで届いたのかを分けて扱います。追跡のために機密本文を無制限にログへ複製する設計は避け、必要なID・版とアクセス管理された記録を使います。

規模に合わせて軽くし、残す条件を決める

少数の公開FAQで更新頻度も低いなら、複雑な並べ替えを導入せず、単純な検索と人の確認から始める選択があります。それでも、資料を使う条件、適用版、根拠箇所の対応は残します。公開資料でも訂正や旧版との取り違えは点検対象です。

部署別の機密資料、頻繁な規程改訂、過去日付の質問を扱うなら、条件別の検索と更新確認の負担が増えます。権限変更や削除が、チャンク・索引・キャッシュへ反映されたかを確かめる運用も必要になります。FAQの数だけでなく、誤答や漏えいの影響と更新の仕方から管理の厳しさを選びます。

評価では、必要な文脈を取得する能力と、その文脈に忠実に回答する能力を分けます。RAGAsの研究もこれらを別の評価側面として扱っています。これは、特定の採点器を使えば真偽が保証されるという意味ではありません。RAGAs: Automated Evaluation of Retrieval Augmented Generation

検索・文脈の担当は、正しい対象と版を、許された範囲で渡せたかを確認します。回答の担当は、条件や例外を保ち、根拠のない補足をしていないかを確認します。外部への申請や精算まで行うシステムなら、その実行権限と承認は別に設けます。資料を読めたことを、その資料に関係する操作を実行できる権限へ広げないことが分担の出発点です。

プロンプト・RAG・ファインチューニング・Agentの使い分けは「普通のプロンプト・RAG・Fine-tuning・Agentをどう使い分けるか」で解説しています。