AIエージェント削除の再検証

1. 01

   再クエリのスコープをシステム全体ではなく、元の削除対象に限定する。

   元の削除計画またはチケットを取得し、記載されたすべてのストア（本番テーブル、削除時点でスコープに含まれていたバックアップ、キャッシュ、インデックス、その他の派生コピー）をリストアップする。スコープを暗黙的に拡大する再クエリは、実際に何が約束されていたかについて独自の紛争を招く。

2. 02

   障害が発生したアーティファクトを生成したアクセスパスとは独立したパスを通じてチェックを実行する。

   破損したシールを生成したパイプラインは、自身の修正を認証するツールとして使用すべきではない。別の認証情報、別のクエリパス、または独立したアクセス権を持つ第二のレビュアーを使用し、どれを使用したかを記録する。

3. 03

   チェックしたすべてのストアを不在・存在・到達不能のいずれかに分類し、「推定」として暗黙的に扱わない。

   到達不能なストア（権限によりフィルタリング、現在のアクセス範囲外、第三者プロセッサが保有）は記録上も到達不能のままとする。他のチェックが通過したからといって「不在」に繰り上げてはならない。

4. 04

   再クエリで存在が確認されたもののみを再削除し、そのスコープに対して再度クエリを実行する。

   スコープ付き再削除とそれに続く確認クエリがループを閉じる。二度目のチェックを省略することは、アクションを独立して確認せずに信頼するという元のミスを繰り返す。

5. 05

   新しい記録を、アーカイブおよびそれが記述するパイプラインから管理を分離した場所に封印する。

   新しい検証記録（何を・どのパスを通じて・誰が・どんな結果でチェックしたか）を、元の削除パイプラインが変更できない場所に保存する。これにより、そのパイプラインの欠陥が最初の証明を無効にしたように、新しい証明を暗黙的に無効にすることを防ぐ。

6. 06

   新しい記録に恒久的な有効性を想定するのではなく、レビュートリガーを設定する。

   再検証記録は、チェック時点のシステムとアクセスパスに対して有効である。何が再確認を必要とするか（プラットフォーム移行、アクセス制御の変更、新しいバックアップ対象の追加）を明記し、永遠に解決済みとして扱わない。

再計算されたマニフェストハッシュを再検証として扱うことは何も解決しない。なぜならそれはライブデータではなく同じ保存済みの主張をチェックするだけだからである。また、独立したチェックがすでに不在を示している場合でも、すべての再検証を新たな削除の根拠とすることは、存在しない問題に対して破壊的操作の承認と監査証跡コストを費やすことになる。