RAGの削除要求を「完了」にする4層チェック

社内RAGから契約終了済みの資料を削除したのに、質問すると古い一節がまだ引用される。知識基盤の担当者がこの状態を防ぐには、「ファイルを消した」を完了条件にせず、4層の削除証拠を一枚に集める必要があります。

物理削除の前に、子データを特定する

RAGでは、一つの元文書からチャンク、埋め込み、検索メタデータ、回答キャッシュが生まれます。元文書を先に消すと、残った断片と親の対応が分からなくなります。

Azure AI Searchの資料でも、ソースを先に物理削除すると検索インデックスに孤立文書が残る場合があると説明しています。[1] 最初に対象文書をretiredにし、文書IDに結び付く子データを列挙します。

チャンクIDはdocument_id#chunk_numberのように親IDを含めます。Pineconeは、指定した接頭辞でベクトルIDを一覧取得できます。[2] 同じ機能がなければ、親文書IDとチャンクIDの対応表を残します。

コピーして使える「削除受領票」

削除要求は、次の機械可読な記録へ変えます。

deletion_receipt:
  request_id: DEL-20261011-014
  source_id: policy-2025-17
  reason: contract_ended
  requested_by: knowledge-owner
  requested_at: 2026-10-11T09:00:00+09:00
  parent_state: retired
  expected_chunk_ids:
    - policy-2025-17#0001
    - policy-2025-17#0002
  layers:
    source: pending
    index: pending
    cache: pending
    answer: pending
  negative_queries:
    - "旧サービスの解約条件は"
    - "2025年版の違約金を教えて"
  owner: rag-platform
  deadline: 2026-10-11T17:00:00+09:00

expected_chunk_idsは削除前に確定します。件数だけでは別文書の減少を成功と誤認するためです。negative_queriesには本文固有の語句や旧回答の質問を入れます。

4層を順番に消し、別々に確認する

1. 元文書層：公開状態をretiredへ変え、新規取り込みと検索対象から外します。物理削除は最後まで待ちます。
2. 検索層：親IDに属する全チャンクを削除します。削除APIの成功応答だけで完了にせず、各IDの取得が失敗し、接頭辞一覧が空になるまで確認します。
3. キャッシュ層：検索結果、回答、引用プレビューのキャッシュを、文書IDまたは引用IDで失効させます。キーを逆引きできない場合は、該当テナントや期間のキャッシュを広めに無効化します。
4. 回答層：negative_queriesを権限別に実行し、削除文書のチャンクID、文言、引用URLが返らないことを確認します。代替資料がない場合は「根拠不足」と答えることも合格結果です。

Azure AI Searchでは、存在しない文書キーへの削除も成功扱いになるため、HTTP 200だけでは削除の証明になりません。削除後の取得が404になることまで確認します。件数への反映には時間差があり得ます。[1]

4層がすべてverifiedになり、検査時刻、方法、結果を記録できたら完了です。最後に元文書を物理削除し、受領票は残します。

例：終了した福利厚生サービスを外す

たとえば、社内FAQが前年までの福利厚生サービスを案内している場面を考えます。担当者は元PDFを削除する前にbenefit-2025をretiredへ変更し、benefit-2025#で始まる18個のチャンクを記録します。

次に18個を削除し、ID一覧が空であることを確認します。回答キャッシュを失効させ、三つの旧質問を一般社員と人事担当者の権限で再実行します。旧資料の文言や引用が出れば、回答層はfailedのままです。

文書を改訂する場合も、同じ親から生成された古いチャンクをすべて削除してから再取り込みします。MicrosoftのMarkdown索引ガイドも、更新文書を再索引する前に、同じ親ファイルから生成された文書をまとめて削除する方法を推奨しています。[3]

失敗モードと適用境界

• 削除APIの成功だけで完了にする：孤立チャンクや非同期反映を見落とします。
• 質問を一つしか試さない：言い換えや権限別フィルターに残った経路を検出できません。
• キャッシュを全消去する：簡単ですが、影響範囲と再計算費用が大きくなります。まず引用IDで逆引きできる設計を優先します。
• 物理削除を先に行う：親子対応を失い、対象チャンクの確定が難しくなります。

検索基盤を毎回丸ごと再構築し、切り替え前に旧インデックスを廃棄するという場合には向きません。その場合は、再構築したインデックスに対象IDがないことと、切り替え後に旧インデックスへ通信できないことを受領票へ記録します。

明日から使える実装チェックリスト

• [ ] 元文書IDから全チャンクIDを逆引きできる
• [ ] 物理削除前にretired状態へ変更する
• [ ] 削除前のチャンクID一覧を保存する
• [ ] 削除API後にID取得と接頭辞一覧を再確認する
• [ ] 回答・検索・引用キャッシュを失効させる
• [ ] 固有語句を含む複数の否定質問を用意する
• [ ] 利用者権限ごとに回答を再実行する
• [ ] 4層の証拠が揃うまで完了扱いにしない

まず一文書でこの受領票を埋め、削除に何分かかるかではなく、どの層の確認が欠けていたかを可視化してください。

参考資料

1. Microsoft Learn — Delete documents in Azure AI Search
2. Pinecone Docs — List vector IDs
3. Microsoft Learn — Search over Markdown blobs

本記事はAIを活用して作成し、公開前に自動レビューを実施しています。情報の確認日：2026-10-11。