社内RAG(検索拡張生成)を本番運用に載せたあと、精度が落ちる最初のシグナルはインデックスの鮮度低下です。文書は毎日更新されるのに、埋め込みインデックスは古いまま置かれる状態が続きます。
モデルやチャンキング(文書分割)設計の前に、更新方式と鮮度SLA(業務側と合意する目標時間)を決めないと、社内チャットは「知っているはずの新情報を知らないRAG」に見えます。
この記事では、差分更新・全再構築・イベント駆動の3方式を業務観点で比較し、鮮度SLA、監視指標、担当設計まで整理します。
RAGインデックスの鮮度管理と再構築設計｜差分更新・全再構築・鮮度SLAの実務ガイド(2026年秋版)
この記事でわかること
- RAGインデックスの鮮度低下が業務判断に与える影響
- 差分更新・全再構築・イベント駆動の3方式の使い分け
- 鮮度SLAの決め方と最初に見る4つの監視指標
- 導入前チェックリストと採用しないほうがよい条件
- 業務課題・データ・運用体制から見たBlackfordの支援範囲
結論サマリー｜課題別に最初に取る行動
情報確認日は2026年9月27日です。RAG運用の鮮度課題は、原因を絞ってから更新方式を選びます。
| 読者の課題 | 最初に見る指標 | 確認すること | 次の行動 |
|---|---|---|---|
| 新しい社内資料が引かれない | インデックス反映までの平均時間 | 差分更新が動いているか | 差分更新を1日1回以上に強化 |
| 古い資料が優先されて出る | 古い文書のヒット割合 | 廃止済み資料が残っていないか | 削除フラグを更新側で扱う |
| 週明けに応答品質が落ちる | 週末の変更ファイル件数 | 週末の差分が反映されているか | イベント駆動更新の追加 |
| 再構築後に検索精度が振れる | 再構築前後の再現率差分 | 埋め込みモデル・チャンク幅の変更履歴 | 再構築のバージョン管理を分離 |
導入判断や既存クラウドとの接続については、Blackfordへの相談で受け付けています。
RAGインデックス鮮度管理の基本
RAGのインデックス鮮度管理は、社内文書の変更をベクトルDBに反映し続ける仕組みです。文書は追加・修正・削除のいずれかで更新されます。
用語を先に整理します。
| 用語 | 意味 |
|---|---|
| インデックス | 文書を検索するために埋め込みとメタデータで作った索引 |
| 差分更新 | 変更された文書だけを検知して索引に反映する処理 |
| 全再構築 | 全文書を最初からベクトル化しなおして索引を作る処理 |
| イベント駆動更新 | 文書の更新イベントを受け、その都度反映する処理 |
| 鮮度SLA | 文書変更から索引反映までに保証する時間の目安 |
鮮度は「更新から反映までの時間」で測ります。この時間が業務の意思決定サイクルより長いと、RAGは古い情報で応答します。
なぜ2026年秋に鮮度管理が運用課題になるか
RAGを1年以上運用した企業から、鮮度に関する不満が急増しています。原因は文書量の増加と、社内チャットの利用範囲の拡大です。
初期のRAGは、規程集や製品マニュアルなど更新頻度の低い資料が対象でした。実運用ではQ&A履歴、議事録、顧客対応記録、営業資料が加わり、更新頻度は日単位から時間単位に上がります。
鮮度が落ちると、次の3つが同時に起こります。
- 利用者が「AIが知らない」と判断して社内チャットを使わなくなる
- 古い規程で回答され、業務判断のリスクが増える
- 情報システム部門が「精度低下」と誤診断してモデル差し替えを検討する
モデルより先にインデックスの鮮度を疑うのが、RAG運用2年目の基本方針です。
インデックス更新方式の比較｜差分・全再構築・イベント駆動
更新方式は主に3つあり、実務では組み合わせて使います。
| 方式 | 一言でいうと | 向くケース | 注意点 |
|---|---|---|---|
| 差分更新 | 変更を定期的に検知して反映 | 変更頻度が中程度で、遅延を数時間許容できる | 削除の検知漏れが起きやすい |
| 全再構築 | 全文書を再ベクトル化して置き換え | 埋め込みモデル変更や整合性回復 | 実行中は精度・遅延が振れる |
| イベント駆動更新 | 更新イベントを受けて随時反映 | 変更を数分以内に反映したい業務 | イベント漏れ・順序ずれ対策が必要 |
実務判断の観点で比較すると、次のようになります。
| 比較軸 | 差分更新 | 全再構築 | イベント駆動更新 |
|---|---|---|---|
| 反映遅延 | 数十分〜数時間 | 実行時のみ整合 | 数秒〜数分 |
| 実装難度 | 中 | 低 | 高 |
| 運用負荷 | スケジューラ監視 | 実行時のリソース確保 | イベントバス監視 |
| コスト | 埋め込みAPIの追加コスト | 一括で発生 | 常時トリガー費用 |
| 削除・改訂の反映 | 検知ロジック次第 | 確実 | ハンドラ設計次第 |
多くの企業は、平日に差分更新を回し、週末に全再構築を予約する組み合わせから始めます。速報性が必要な情報源だけ、イベント駆動更新を追加します。
鮮度SLAと運用で確認すべき項目
鮮度SLAは、業務の意思決定サイクルより短い時間で設定します。曖昧に「なるべく早く」と決めると、運用側が判断できません。
決め方の順序を守ります。
- 情報源ごとに「変更から利用までの猶予時間」を業務側と合意する
- 情報源ごとの鮮度SLAをドキュメント化する
- 差分更新のスケジュールを鮮度SLAより短く設定する
- 全再構築の頻度と実行時間帯を決める
- 監視指標と担当・アラート閾値を決める
運用開始後は、次の4指標を最低限見ます。
| 指標 | 意味 | 見方 |
|---|---|---|
| 反映遅延 | 更新イベントから索引反映までの時間 | 情報源ごとにSLA達成率を測る |
| 差分検出漏れ率 | 変更検知ロジックで拾えなかった割合 | 監査時にサンプリング確認 |
| 古い文書のヒット率 | 廃止済み文書が上位に出る割合 | 定点評価データセットで確認 |
| 再構築中の品質低下幅 | 全再構築中の再現率低下 | 再構築前後で同一クエリを比較 |
導入前に確認するチェックリストは次の通りです。
- 情報源ごとの更新頻度と変更検知手段が整理されているか
- 削除・廃止フラグを更新側で扱えるか
- 埋め込みモデルのバージョンをインデックス側で管理できるか
- 全再構築の実行時間帯と業務影響を合意できているか
- 監視指標の閾値と担当が決まっているか
鮮度SLAは情報源ごとに分けて決めるのが実務の要点です。すべての情報源に同じSLAを敷くと、コストと監視負荷が跳ね上がります。
リスクと限界｜採用しないほうがよい条件
インデックス鮮度管理は、やみくもに更新頻度を上げると逆効果になります。
主なリスクを整理します。
- 埋め込みAPI費用が想定を超えて増える
- 更新中に古い索引と新しい索引が混在して精度が振れる
- 削除ロジックの不備で、廃止済み文書が長期間残る
- 全再構築中に検索遅延が伸びて業務が止まる
- イベント駆動更新のイベント漏れが監視できていない
次の条件に当てはまる場合は、鮮度管理の高度化を後回しにします。
- 情報源が単一で、業務側の更新頻度が月1回以下
- 変更検知の権限が情報源側にない
- 埋め込みモデルの契約が固定的で、モデル切り替え計画がない
- RAG利用者が数人で、更新遅延の実害が測れない
注意
鮮度SLAは業務側と合意した猶予時間を基準にします。技術側だけで「1時間以内」と決めると、コストと運用負荷が過剰になります。
Blackfordの見解｜鮮度管理を業務・データ・運用に接続する
鮮度管理は、単独の設計課題ではなく、業務・データ基盤・運用責任者を横断する運用テーマです。BlackfordはRAG運用改善局面で、次の観点から支援します。
- 業務課題: どの情報源で鮮度が業務判断に効くかを整理する
- 扱うデータ: 変更検知の可否、権限、監査ログを整理する
- 評価指標: 鮮度SLA、差分検出漏れ率、再構築品質を測る指標を設計する
- コスト上限: 埋め込みAPI費用と全再構築コストの上限を運用側と合意する
- セキュリティ要件: 更新イベントの経路と個人情報の扱いを設計する
- 運用責任者: インデックス管理の担当・レビュー頻度・エスカレーション先を決める
- 既存クラウドとの接続: AWS、Azure、GCP、VPC内のRAG基盤に更新パイプラインを組み込む
社内データを扱いやすい形に整えるところから支援するのがBlackfordの立ち位置です。DataRoidは社内設置型のAIデータ基盤として、ベクトル化・メタデータ付与・権限継承・鮮度管理を一体で扱いやすくします。既存クラウド資産を活かしたい場合はDataRoid Cloudを組み合わせられます。
※LLM関連サービスの料金、データ保持条件、提供機能は変更される場合があります。導入前に公式情報で最新条件を確認してください。
よくある質問
Q. RAGインデックスは毎日全再構築したほうがよいですか？
多くの場合は不要です。差分更新を主軸にして、埋め込みモデル変更や整合性回復のときだけ全再構築を予約するのが実務的です。全再構築を高頻度で走らせると、コストと検索遅延が業務時間帯に食い込みます。
Q. 差分更新の遅延はどのくらいに設定すべきですか？
情報源ごとに業務の意思決定サイクルから逆算します。規程集は1日1回で足りることが多く、営業商談メモや顧客対応記録は数分〜数十分の遅延を目標にする例が増えています。全情報源に同じ遅延を敷くとコストが跳ね上がります。
Q. 削除された文書がRAG検索に残るのはなぜですか？
削除イベントがインデックス側に届いていないためです。差分更新では追加・修正の検知に比べて削除の検知が漏れやすく、削除フラグや監査ログをインデックス側で扱う設計が必要です。
Q. 中小企業でも鮮度管理は必要ですか？
必要ですが、規模に合わせて簡素化できます。情報源が数種類で更新頻度が低ければ、1日1回の差分更新と月次の全再構築だけで鮮度課題の多くは防げます。運用担当者と閾値を先に決めることが重要です。
Q. 埋め込みモデルを切り替えるときは差分更新で追いつきますか？
追いつきません。埋め込みモデルを切り替えるとベクトル空間が変わるため、全再構築が前提です。切り替え中は旧モデルの索引を並行運用し、品質を確認してから切り替えるのが実務的です。
まとめ｜鮮度は業務側と合意して測るテーマ
RAGインデックスの鮮度低下は、モデルやチャンキング設計より先に運用品質を落とす原因になります。差分更新・全再構築・イベント駆動を組み合わせ、情報源ごとに鮮度SLAを分けて決めることが運用改善の起点です。
ただし、更新頻度を上げるほど費用と監視負荷は増えます。業務側の意思決定サイクルと合意した基準で、鮮度SLA、監視指標、担当を先に決めてから設計に入りましょう。
＼RAG運用改善の相談ができます／
Blackfordに相談する
