RAGを業務システムに組み込むとき、検索精度だけを改善しても、更新前の文書を引用したり、閲覧権限のない情報を回答に混ぜたりする問題は残ります。取り込みから回答までを一つのパイプラインとして扱い、どの文書版を、誰の権限で検索し、どの根拠で回答したかを追える設計が必要です。

本稿は公開資料に基づく設計案です。以下の擬似コード、品質ゲート、切り戻し手順は未実装・未検証であり、本番運用の実績や性能値ではありません。対象読者は、RAGをPoCから業務システムへ移すエンジニアとテックリードです。

技術的な問い：どこを一つのリリース単位にするか

前提は、更新される文書を根拠に回答し、利用者ごとの閲覧権限があるナレッジ検索です。文書取り込みと質問処理は別のタイミングで動きます。そこで「索引が作れた」だけでは完了とせず、検索、引用、回答保留まで含む版の整合性をリリース条件にします。

文書更新 → 抽出・正規化 → チャンク化 → 埋め込み → 候補索引
                                           ↓ 評価・公開切替
利用者認証 → 権限で検索対象を限定 → 検索 → 文脈構成 → 生成
                                                     ↓
                                          根拠照合 → 回答 / 保留

MicrosoftのRAG設計ガイドも、取り込み・検索・生成の各段階と全体を評価対象として分けています。この分割を運用上の責任境界として使います。

設計選択肢：更新をその場で反映するか、検証して切り替えるか

選択肢	利点	引き受けるリスク	採用条件
稼働中の索引を直接更新	構成が簡単で追加の索引費用が少ない	更新途中に旧版と新版が混ざりやすい	小規模で版混在を許容できる場合
候補索引を別に構築して切替	代表質問で評価してから版を切り替えられる	一時的に索引が二重になり、容量と運用手順が増える	引用版の一貫性や切り戻しが必要な場合
検索をせず毎回原文を読む	索引更新の管理が不要	文書量、遅延、入力トークン費用が増える	対象文書がごく少ない場合

この前提では候補索引を作ってから切り替える方式を選びます。索引の別構築とエイリアスによる切替はAzure AI Searchの再索引手順にもある運用方法です。ただし、切替だけで正しさは保証されません。取り込み成功、権限メタデータ、評価質問、引用先の到達性を確認してから切り替えます。小規模用途では二重索引の費用が過剰になるため、直接更新も候補に残します。

実装の要点：文書と回答を同じ版へ結び付ける

最小限、各チャンクに document_id、source_revision、index_release、source_span、allowed_principals を持たせる設計にします。source_span は引用元の位置を再現するための識別子です。取り込み時には削除された文書も検出し、旧版のチャンクが検索に残らないことを確認します。Amazon Bedrockの同期手順では、追加・変更・削除の後に同期して索引へ反映すると説明されています。

build_release(source_snapshot):
  snapshot_id を確定
  各文書を抽出し、失敗文書と削除文書を記録
  権限・出典・版を付けて候補索引へ投入
  件数、権限欠落、引用先、代表質問を検査
  合格した候補索引だけを公開先へ切り替える

answer(user, question):
  user を認証し、利用可能な権限集合を取得
  権限条件を検索クエリに適用して候補を取得
  取得文書の版・出典・権限を再確認
  根拠が不足、矛盾、失効していれば回答を保留
  根拠付き回答を生成し、主張と引用箇所を照合
  公開中の index_release と引用した source_revision を記録

権限条件をプロンプトだけに書いてもアクセス制御にはなりません。検索前に認可し、検索結果を利用者の権限に合わせて絞る必要があります。Azure AI Searchのセキュリティフィルターは実装例ですが、同資料はフィルターに入れる主体IDそのものの認証・認可を検索エンジンが行うわけではない点も明記しています。利用者IDの信頼性と権限更新の反映はアプリ側の責任です。

品質ゲートと失敗時の振る舞い

評価用の質問は、正解文書がある質問だけでなく、該当文書なし、旧版との競合、権限外、複数文書にまたがる条件を含めます。検索段階は必要な根拠を候補に含めたか、回答段階は根拠に沿っているかを別々に見ます。検索結果の関連度スコアを回答の正しさに読み替えません。Microsoftの検索評価ガイドと回答評価ガイドも、この二段階を区別しています。

失敗	検出する位置	安全側の処理
抽出失敗・権限メタデータ欠落	候補索引の構築時	その文書を公開対象から外し、更新を止める
必要な根拠が検索されない	検索評価・実行時	別の検索条件を試すか回答を保留する
新旧文書が矛盾する	文脈構成時	有効版を確認できなければ人手確認へ送る
引用が主張を支えない	生成後の照合時	回答を出さず再確認する
索引切替後に品質が悪化	運用監視時	旧索引へ切り戻し、原因を調べる

自動評価だけで合否を決めず、保留例と誤引用例を人が確認できる経路を用意します。権限外の質問への応答は、回答の正確さ以前に必須の検査です。

本番運用で残すログとコストの見方

質問ごとに追跡ID、公開中の索引版、検索で使った権限条件、候補文書ID、引用文書版、保留理由、各段階の所要時間を記録します。本文や個人情報を無条件にログへ複製せず、監査に必要な識別子と保存期間を決めます。索引更新の失敗率、引用不一致率、回答保留率、検索と生成それぞれの遅延を監視対象にします。

費用は埋め込みの再計算、二重索引の保存、検索、生成、評価・人手確認に分けて見積もります。二重索引に見合うかは、更新頻度と切り戻し要求で判断します。ここでの工数削減やROIは未計測です。業務上の効果としてまず検証すべきなのは、回答の可否と根拠を説明できること、誤引用や権限逸脱を検知して止められることです。

次に改善すること

最初は少数の代表文書と質問で、文書更新・削除・権限変更から回答までを通し、同じ評価セットで索引版を比較します。その後、抽出失敗と権限欠落を意図的に発生させ、切替が止まることを確かめます。ログから原因が分からない失敗が残るなら、モデル変更より先に追跡情報を補います。

同様の仕組みの設計・構築・運用については相談可能。

この記事を書いた人✏️@YushiYamamoto
ITPRODX.com代表 / AIアーキテクト
Next.js / TypeScript / n8nを活用した自律型アーキテクチャ設計を専門としています。
日々の自動化の検証結果や、ビジネス側の視点（ROI等）に関するより深い考察は、以下の公式サイトおよびnoteで発信しています。