RAGの資料更新の運用設計：追加・改訂・廃止ごとの取り込みと再インデックス

先に決める3点:文書ID・版・内容ハッシュ

処理を分けるには、「同じ資料か」「中身が変わったか」を機械的に判定する必要があります。最低限、資料ごとに次の3つを持たせます。

• 文書ID:ファイル名ではなく、改名しても変わらない識別子(例:HR-001)
• 版:改訂のたびに増やす番号(例:v3)
• 内容ハッシュ:本文から計算した値。ファイルの更新日時ではなく本文の変化を見るために使う

文書IDを安定させる理由は、検索基盤の更新方式がIDに依存するからです。Google Cloud の Vertex AI Search(Agent Search)のデータ更新では、INCREMENTAL(既定)は同じIDの文書を新しい内容で置き換え、FULL は取り込み元にない文書をデータストアから削除します。また、自動生成されたIDは複数回の取り込みで一定とは限らないという注意があります。Azure 側も、文書キーや、ADLS Gen2 のディレクトリ名・パスを変えると、どの内容をいつ索引化したかという内部の追跡が壊れると説明しています。

これらを一覧(台帳)にします。次は説明用の例です。

• HR-001、version：v3、content_hash：a1b2…、status：active、source_path：/規程/休暇規程.pdf、indexed_at：2026-10-20
• HR-002、version：v1、content_hash：c3d4…、status：active、source_path：/規程/出張旅費.pdf、indexed_at：2026-10-20
• HR-000、version：v2、content_hash：e5f6…、status：retired、source_path：/規程/旧休暇規程.pdf、indexed_at：2026-10-20

各チャンクにも doc_id・version・status を属性として付けてください。削除や絞り込みを文書単位で行うための土台になります。

追加・改訂・廃止の処理表

台帳と現在の資料置き場を突き合わせ、次の表に従って振り分けます。

• 追加、判定：台帳にない文書IDが現れた、索引での処理：解析→分割→埋め込み→登録。チャンクに ID・版・status を付ける、完了の確認：その資料にしか書かれていない内容を質問し、出典に出るか見る
• 改訂(本文)、判定：同じ文書IDで内容ハッシュが違う、索引での処理：新版を先に登録し、確認後に旧版のチャンクを全部削除する、完了の確認：旧版にしかない記述を質問し、出てこないか見る
• 改訂(属性のみ)、判定：本文ハッシュは同じで、部署・公開範囲などの属性だけ違う、索引での処理：属性だけ更新し、再埋め込みはしない、完了の確認：絞り込み条件で、期待した範囲にだけ出るか見る
• 改名・移動、判定：パスだけ変わり、文書IDと本文は同じ、索引での処理：台帳の source_path と索引側の出典URLを更新する。取り込み方式に応じて更新検知・再索引化も行う、完了の確認：出典表示のリンクが新しい場所を指すか見る
• 廃止、判定：台帳が retired になった、または置き場から消えた、索引での処理：索引から削除してから、原本を消す、完了の確認：廃止資料にしかない内容を質問し、出ないか見る
• 復活、判定：廃止した資料を戻す、索引での処理：追加と同じに扱う。Azure のソフトデリートからの復元では、削除状態の解除に加え、LastModified を更新してインデクサーを実行する、完了の確認：追加と同じ

「新版を先、旧版を後」にする理由は、回答に空白期間をつくらないためです。ただし、短時間は新旧が同時に検索される可能性があります。差し替え中は status=active だけを検索する条件を付けると、混在の影響を抑えられます。この順序は私たちの編集上の提案で、どの製品でも必須というわけではありません。

次の変更は、資料ではなく処理系の変更なので、全件の再処理が必要になると考えてください。

• 分割の方針(チャンクの大きさ・重なり)を変える
• 埋め込みモデルを変える
• PDFなどの解析方法を変える

OpenAI の vector store では、既定のチャンクが 800トークン・重なり400トークンで、100〜4096トークンの範囲で調整できると説明されています。こうした設定を変えたときは、一部の資料だけ新設定にすると、検索結果の質が資料間でそろわなくなります。

廃止の扱い:索引から先に外す

廃止の事故は、「原本は消したのに回答に出る」形で起きます。避けるために、手順を次の順に固定します。

1. 台帳の status を retired にして、廃止日と理由を記録する
2. 索引からその doc_id のチャンクをすべて削除する
3. 廃止確認の質問(後述)を実行して、出典に出ないことを確かめる
4. 確認できたら、原本を削除・移動する

Azure AI Search ではこの考え方が標準の仕組みとして用意されています。「ソフトデリート」で先に検索文書を消し、あとで Storage 上の物理削除をする二段構えです。注意点も公式に書かれています。

• 削除検出の設定は最初のインデクサー実行から適用する必要がある。設定前に削除された文書は、あとで設定を足してリセットしても索引に残る
• ネイティブのソフトデリートは、Blob のバージョニングが有効だと使えない
• ネイティブのソフトデリートでは、保持期間をインデクサーの実行間隔よりかなり長くしておく。削除状態の Blob を処理できたときだけ、索引から消えるため
• 一対多のインデックス方式には、この二つの方法は使えず、削除リクエストを送る必要がある

また、削除の反映が即時とは限らない製品もあります。OpenAI の vector store では、ファイルの削除は結果整合(eventually consistent)で、削除後しばらく検索結果に内容が含まれる場合があると説明されています。そのため、手順3の確認は削除の直後に1回で済ませず、時間を置いてもう一度行うのが安全です。

廃止確認の質問を用意する

廃止資料1件につき、その資料にしか書かれていない事実を問う質問を1〜2問、台帳とは別に保存します。次は説明用の例です。

質問:旧休暇規程で定められていた「年次有給休暇の繰越上限」は何日ですか
期待:出典に HR-000 が出ない。「見つからない」または現行の HR-001 に基づく回答

質問の作成をAIに任せる場合は、機密情報をそのまま渡さず、公開可能な範囲か、ダミーに置き換えた文面で依頼してください。

次の規程の抜粋(説明用ダミー)から、この文書にしか書かれていない事実を
確かめる質問を2つ作ってください。他の文書と内容が重なる事柄は避け、
質問ごとに答えの根拠となる箇所も添えてください。
[抜粋]

生成された質問は、人が原本と照らして「本当にこの文書だけの内容か」を確認してから使います。

更新ログに残す項目

ログは、何かおかしな回答が出たときに「その時点で索引に何が入っていたか」をたどるために残します。次の項目を、1回の更新作業(バッチ)と文書ごとの変更の2段で記録するのが扱いやすい形です。

バッチ単位

• 実行ID、開始・終了時刻、実行者または実行ジョブ名
• 処理系の設定(分割設定、埋め込みモデル名、解析方法)の識別子
• 件数:追加・改訂・属性のみ・廃止・変更なし・失敗

文書単位

• doc_id、事象(追加/改訂/属性のみ/改名/廃止/復活)
• 旧版と新版、旧・新の内容ハッシュ
• 削除したチャンク数と登録したチャンク数
• 結果(成功/失敗/保留)と、失敗時のエラー内容
• 確認質問の実施結果(出た/出なかった)と確認時刻

「削除したチャンク数」が0のまま廃止が成功扱いになっている場合は、IDの不一致を疑うきっかけになります。件数をログに残す意味はここにあります。

確認の頻度の目安の考え方

頻度は「資料が変わる速さ」と「古い回答が出たときの被害の大きさ」の2軸で決めます。以下は編集上の目安であり、実測にもとづく数値ではありません。自組織の更新ペースに合わせて調整してください。

• 誤ると影響が大きく、頻繁に変わる、例(説明用)：規程、料金表、手続き案内、変更の検知：日次、または更新通知で即時、廃止・改訂の確認：更新のたびに確認質問を実行
• 通常の業務資料、例(説明用)：手順書、FAQ、変更の検知：週次、廃止・改訂の確認：週次の更新バッチ後にまとめて実行
• ほぼ変わらない資料、例(説明用)：過去の議事録、アーカイブ、変更の検知：月次、廃止・改訂の確認：四半期に一度、台帳と索引の件数を突き合わせる

どの区分でも、次の2つの点検を定期的に入れることをおすすめします。

• 台帳と索引の突き合わせ:台帳の active 件数と、索引内の文書ID数が一致するか。ずれた分が取りこぼしや削除漏れです
• 処理系の変更時の全件再処理:分割・埋め込み・解析の設定を変えたときは、頻度の表とは別に実施する

最初の1か月は、頻度を高めに設定して、ログから「実際にどのくらい変わるか」を数えると見直しやすくなります。この数え方で、各区分の頻度を実データに合わせて調整できます。

なお、この記事で参照した公式ページの記述は2026年10月27日に閲覧した範囲です。Azure の API バージョンや各社の仕様は変わることがあるため、実装の前に、使う製品の最新の資料を確認してください。