RAG削除を「要求送信」で完了扱いしない

RAGや検索基盤の削除は、削除APIが成功応答を返したことだけで完了と判定してはいけません。少なくとも「削除要求を受理したこと」「管理面で対象ジョブや資源が消えたこと」「検索・取得面で対象データが再び返らないこと」を別の状態として記録し、必要に応じて派生物や外部保存先も個別に確認します。

Amazon Transcribe系の削除APIでは、ジョブ削除と顧客管理S3オブジェクトの削除を同一視できません。生成結果を削除するAPIや権限記述が存在しても、それだけで顧客S3、派生字幕、分析結果、provider内部バックアップまで一括消去されたとは証明できません。URIが失効したことも、保存データの消去証明ではありません。

運用では、削除要求ID、対象資源ID、状態遷移、失敗理由、削除後のnegative read/query、派生物一覧、外部保存先、再試行・期限、監査ログを一つのerasure recordに束ねます。削除APIの成功と、データ面の非存在確認を別々に保存してください。非同期削除では、完了確認前に「消去済み」と表示しない設計が必要です。

• APIの200/成功応答は、顧客管理ストレージや全派生物の消去を意味しません。
• control-planeでジョブが見えなくなっても、data-planeの検索不能・取得不能を自動的には証明しません。
• 一時URLや結果URIの失効は、物理消去やバックアップ消去の証拠ではありません。
• provider内部バックアップの保持・物理消去時刻は、公開APIだけでは確認できない場合があります。
• 削除後の代表的な1クエリだけでは、全インデックス・全派生表現からの非検索化を証明できません。

削除対象ごとに、request_id、resource_id、要求時刻、provider応答、最終状態、negative read/queryの結果、確認時刻、派生物と保存先、未確認領域、再試行履歴を保持します。確認不能な領域はUNKNOWNとして残し、推測で「完全消去」にしません。

この運用はproof-of-erasureそのものを保証するものではなく、削除要求と削除確認を分離し、未確認領域を監査可能にするための実務的な証跡設計です。