RAG（検索拡張生成）を社内文書へつなぐと、モデルの知識を更新しなくても回答へ根拠を渡せます。しかし、規程を改訂した、契約書を差し替えた、公開を取り消した後に、古いchunkが検索され続ければ、もっともらしいが期限切れの回答を返します。検索精度だけでなく、更新と削除をどう追跡するかが運用品質を左右します。
結論は、原本を正本にし、ベクトル索引を派生データとして扱うことです。文書ごとのsource revision、chunk ID、embedding model、索引versionを分け、更新はupsert、不要なchunkは削除、embeddingの互換性が変わるときは新しいindexへ切り替えます。一度の再索引で全部を直そうとしない方が、原因調査と安全な復旧をしやすくなります。
RAGの回答は、原本ではなく検索時点の候補である
RAGの原論文は、言語モデルに外部の非パラメトリックな記憶を検索で与える方法を扱い、知識更新と出典提示を課題として挙げています。実務でも、ベクトルDBは文書管理システムの置き換えではありません。原本の版、公開状態、保持期限、閲覧権限をベクトルだけに閉じ込めると、更新漏れを検出できなくなります。
そこで原本側に、少なくともdocument ID、revision、公開状態、更新時刻を持ちます。分割したchunkにはdocumentId:revision:chunkNoのような安定したIDと、原本を参照する値を持たせます。回答時には、検索で得た候補のrevisionと原本の現行revisionを照合し、古い候補なら採用しません。全文を毎回取り直す必要はありませんが、「索引にあるから現行」とは扱わないことが大切です。
更新を四つの状態に分ける
文書更新を「再埋め込みする」という一語で扱うと、失敗時の復旧が曖昧になります。次の四つに分けます。
- 原本変更の検知：更新・削除・公開停止を原本から検知し、document IDと新revisionを記録する。
- chunk生成とembedding：新revisionを分割し、chunkごとに内容、生成日時、embedding modelを記録する。
- 索引反映：同じvector IDをupsertして、値とmetadataを新revisionへ完全に置き換える。Cloudflare Vectorizeのupsertは既存vectorの値とmetadataをマージせず、全体を置換します。
- 読取り側の切替：少数の検証queryと原本照合を通してから、新revisionを検索対象として扱う。削除・非公開は原本照合で先に除外し、索引削除の完了を待つ間も露出させない。
Cloudflare Vectorizeのupsertは非同期で、query可能になるまで通常は数秒かかるとされています。更新要求が成功した直後に検索して旧結果が出ても、直ちにデータ破損とは限りません。固定時間だけ待つのではなく、対象documentのrevisionを含む検証queryを用意し、反映確認とタイムアウト時の再調査を分けます。
upsertは便利だが、削除と再分割を代替しない
同じvector IDのupsertは、前の値とmetadataを置換します。これは文言修正や同じ区切りの更新には向きます。一方、見出し追加でchunk数が増減した、PDF全体を差し替えた、文書を非公開にした場合は、旧chunkを残したまま新chunkだけを追加すると、検索結果に旧版が混ざります。
原本のrevisionごとに「期待するchunk IDの集合」を保存し、再索引後に索引側との差を確認します。削除対象は原本で先に無効化し、ベクトル削除は後続jobとして確実に処理します。大量更新を一件ずつ送るより、Vectorizeが推奨するバッチで入れる方が、書込みをまとめてreadへ見えるまでの遅延を抑えやすくなります。ただしバッチ化は鮮度保証ではなく、失敗単位と再実行単位を大きくする側面もあります。
embeddingの互換性が変わるならindex versionを分ける
indexのdimensionと距離metricは作成後に変更できません。embedding modelを変え、次元数や意味空間の前提が変わるなら、既存indexへ混在させず、新しいindex versionを作ります。原本のrevisionとindex versionは別物です。前者は文書内容の変化、後者は検索基盤の互換性を表します。
安全な切替は、旧indexを残したまま新indexへ全量を作り、代表queryで原本・revision・出典を確認してから、読取り先を一度に切り替える形です。読み取り先の切替後も、旧indexの削除は監査・rollback期間とデータ保持方針を確認してから行います。二重書込みを恒久化する必要はありません。移行の目的と終了条件が明確な短期間だけに限定します。
監視するのは類似度だけではない
類似度の高い候補が返ることは、最新の正本が返ったことを意味しません。運用では、原本の更新件数、索引成功・失敗件数、未反映revision数、削除待ちchunk数、検索結果の原本照合失敗数を追います。これらをrequest IDやjob IDと結べば、いつの原本がどの索引処理で止まったかを調査できます。
更新処理は長くなるため、受付と再試行はCloudflare Queuesの設計、会話単位の二重起動はDurable Objectsによる同時実行制御、障害の横断追跡はAIエージェントの可観測性設計と分けると、責務が明確になります。
実装前チェックリスト
- 原本のdocument ID、revision、公開状態を索引とは別に管理しているか
- chunk IDがrevisionとchunk番号から再現でき、重複upsertを判定できるか
- 検索結果を原本の現行revision・公開状態と照合するか
- 更新で減ったchunk、非公開文書、削除文書を除外・削除する経路があるか
- upsert直後の非同期反映を前提に、検証queryと失敗時の再調査を用意したか
- embedding model、dimension、distance metricが変わるときにindex versionを分けるか
- 反映待ち件数、原本照合失敗、削除待ちを監視できるか
限界：索引が新しくても回答の正しさは保証されない
索引を最新化しても、検索queryが不適切、chunk分割が悪い、原本そのものが誤っている、モデルが根拠を誤読する、といった問題は残ります。RAGは正解を保証する機能ではなく、回答に使う候補と出典へ到達しやすくする仕組みです。高リスクな判断では、回答に原本へのリンクとrevisionを示し、人が正本を確認できるようにします。
また、索引更新の速度や制約は製品・プラン・データ量で変わります。本文の設計はCloudflare Vectorizeの2026年9月9日時点の公開資料を前提とし、実装前には最新のlimitsと変更履歴を確認してください。
AI基盤設計・セキュリティ相談
社内文書をAI検索へ接続する際の更新設計、出典表示、運用監視を整理したい方は、AI基盤設計・セキュリティ相談をご利用ください。
一次情報と確認範囲
| 機関・資料 | 確認した範囲 | URL |
|---|---|---|
| Lewis et al. / NeurIPS | RAGの外部記憶、知識更新・provenanceの課題 | Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks |
| Cloudflare Vectorize | upsertの非同期性、同一IDの完全置換、query API | Vectorize API |
| Cloudflare Vectorize | insert/upsert、metadata、バッチ更新とread可視化 | Insert vectors |
| Cloudflare Vectorize | index設定が作成後に変更できないこと | Create indexes |
| Cloudflare Vectorize | vector変更がquery可能になるまでの遅延改善 | Vectorize Changelog |
| Cloudflare Vectorize | metadata filter、namespace、metadata indexの制約 | Metadata filtering |
一次情報と確認範囲
確認日：2026年9月9日。製品仕様・制度は更新されるため、導入時はリンク先の最新版を再確認してください。海外の制度・職業規範は日本へ直接適用せず、相違点と限界を本文に明記しています。
- RAGは外部の非パラメトリック記憶を検索で用い、知識更新とprovenanceは課題である
- Vectorizeのupsertは非同期で、同一IDの値とmetadataを完全に置換する
- Vectorizeは更新をまとめて処理し、バッチがreadへの可視化時間を短縮し得る
- indexのdimensionとdistance metricは作成後に変更できない
- Vectorizeの2026-07変更では、vector変更のquery可能化は中央値30秒未満、p99二分未満と説明されている
- metadata filterはvector検索前に適用され、metadata index作成前のvectorには後から反映されない