原本と派生データの関係を記録する
問い合わせを消して検索結果がなくなれば、その検索経路で表示されない証拠が得られます。一方、会話要約や保存されたセッションから同じ内容がモデルへ渡ることがあります。承認された対象を、保管先と利用経路の両方で追跡します。
架空の問い合わせT-804の削除が承認されたとします。サポートシステムに本文と添付、検索には断片、ベクトルと表題があります。以前の会話の要約がアカウントの長期メモリになり、評価データにはメールアドレスを除いた文章が登録されていました。派生文に注文時刻、販売元、まれな問い合わせ種別の組み合わせが残る場合があります。作成元を追えれば識別子を除いた事例も見つけられます。
原本IDと版または取り込み世代、派生物の種類とID、生成ジョブ、保存アカウントやリージョン、担当者を結びつけます。複数の断片に分けた文書は個々のキーを追います。複数の案件の要約は元資料を記録し、削除対象を除いて再生成できるか確認します。ログに参照値だけが残る場合も、人物や事象を識別できるか調べます。結びつけ可能な原本IDもアクセスと保管を制限します。
API経路に加え、ツールが内部に保存する場所を記録します。モデルへの要求と応答、提供元のアプリ状態、デバッグ資料、評価用の抽出、複製、バックアップを含められます。どの操作で削除でき、どの処理が再流入を起こすかを記録します。NISTの生成AIプロファイル[1]は保存方針と上流・下流の依存関係を扱います。OWASPのエージェントセキュリティガイド[2]はデータの最小化と保管・削除方針を勧めています。
利用停止、稼働中のコピー、保管例外の状態を分ける
即時の利用停止では検索、回答、ツール実行、評価用資料の生成で使えないようにします。読み取りと派生処理が参照する場所に停止を記録し、派生キーと削除状態を調べます。一般ユーザーから見えなくても、管理画面や分析エクスポートに残る場合があります。アクセス制限を試験し、各保管先の削除依頼と結果を記録します。Azure AI Searchの文書単位アクセス制御[3]には索引方式や設定に応じた制御例があります。
稼働中のコピーの整理では、データベース、検索、キャッシュ、評価ストアの対象を除去または再生成します。削除APIの成功は、文書に明記された段階を示します。非同期の削除ではジョブ完了を確認し、実際のキーと内容で参照を試します。削除フラグと記録媒体からデータを読めない状態にする処理には異なる証拠があります。NISTの媒体サニタイズ指針[4]は所定の労力で対象情報にアクセスできない状態を定義します。管理サービスでは契約とサービスの証拠範囲に沿って残存状態を記録します。
保管例外は権限のある業務、セキュリティ、法務の担当者が判断します。技術側は許可する用途、運用で再利用されない仕組み、次に見直す時点を決めます。不変の復旧ポイントでは個別データの即時削除が難しい場合があります。たとえばAWS Backup Vault Lock[5]のコンプライアンスモードは猶予期間後の変更・削除を制限します。保管や有効期限には実際の設定と復元経路を適用します。
再取り込みと復元にも削除マーカーを適用する
削除マーカー（tombstone）には原本の識別情報、範囲、有効時刻、処理状態を記録します。最小限の識別値を使い、消すべき問い合わせの本文はコピーしません。収集処理が古いイベントを受けたり原本を再取得したりする場合もこのマーカーを使います。復元で新しいIDが割り振られる場合は元のIDとの対応を確認します。識別子が再利用されるシステムでは、原本のシステムと世代も使って正規の新規文書を誤って除かないようにします。
埋め込みの生成には断片の作成、検索索引の更新、別ストアへのメタデータ記録が含まれることがあります。原本を先に消すと変更監視が削除を取りこぼす場合があります。Microsoftは一部のAzure AI Searchの索引構成ではソフト削除を先に同期しなければ、索引側に孤立した文書が残り得ると説明しています。手動削除では原本IDと索引のキーを照合します。実際に使う索引とデータソースの設定に沿って適用します。Azure AI Searchの文書削除[6]
キャンペーンに必要なデータから接続 — 施策から逆算してイベントと属性を定義し、識別子、送信時点、測定ツールの役割を整えます。
保存先ごとの証拠と再流入試験
承認対象の保管先に次の表を適用します。削除できる単位や証拠の範囲は製品と契約で異なります。各行をどう確認したかと、残るコピーの利用をどう制限したかを記録します。
| 保管先 | 処理の例 | 完了の証拠 | 再流入試験 |
|---|---|---|---|
| 原本、添付、イベント | 本文と添付の削除・隔離、変更と再処理の管理 | 原本照会、ジョブや保存APIの状態、権限別参照 | 古い取り込みを再実行し新しく複製されないか |
| 検索断片、ベクトル、表題 | 派生キーをすべて処理し、新しい索引にもマーカーを適用 | 想定キー、処理結果、直接照会、キーワード・意味検索 | 再索引、索引の切り替え、旧索引への復帰 |
| キャッシュ、会話メモリ、要約 | キーの無効化と複数資料の要約の再生成 | 直接照会、新旧セッションのモデル入力、再生成の根拠 | 古いセッションの継続、遅延したキャッシュ書き込み |
| ログ、分析、証拠保管 | 対応可能な単位で除去・制限、例外を別管理 | アカウント、データセット、エクスポート、例外の担当と期限 | 集計やログの再読込、エクスポート経路 |
| 評価・訓練入力 | 行、派生事例、スナップショットを管理し後続ジョブへの投入を防ぐ | 再構成の版、関連ID、入力拒否 | 旧版からの再生成や定期実行 |
| 外部の提供元 | アカウント・機能別に削除や期限を確認し、受付と完了を区別 | 依頼番号、公式の結果と方針、未確認範囲 | 旧IDからの照会や再開 |
| バックアップ、スナップショット、複製 | 期限・保管条件に従い、隔離復元後に整理 | 復旧点、期限、隔離状態、復帰承認、例外 | 削除前を復元し再流入と正常データ保持を確認 |
証拠を作るために削除済みの本文を監査ログに再登録しないようにします。依頼ID、保管先とアカウント、安全な原本参照、確認時刻、ツールの結果、権限別参照、再流入試験の判定を記録します。検索結果がないことは利用停止の一部の証拠です。似た回答が返った場合は、引用とツールの記録で原本を検索したか、別の根拠を使ったかを確認します。AIエージェントの動作を確認する観測項目も参考にできます。
架空の問い合わせを復元して削除を検証する
T-804を原本でマークし、検索やメモリ生成がIDの利用を拒否することを確認します。原本、添付、三つの断片、検索用のタイトル、キャッシュした回答、要約を記録します。評価データにメールやIDがなくても、生成履歴をたどると二つの派生例が見つかりました。そこから除外して評価データを新しい版にし、以前の評価結果を保存するなら原文の有無とアクセス範囲を調べます。
- 再取り込み。 削除前の収集イベントを再配信し、対象IDから新しい検索断片や評価入力が作られないことを確認します。同時に正常な問い合わせが取り込まれることを確認します。
- セッション継続。 削除前の架空の会話を続け、古い要約が再投入されないか、別セッションで作った共有キャッシュも方針を適用するかを比較します。
- 隔離復元。 削除前のバックアップを分離環境に復元し、検索、エクスポート、キューを開ける前に最新の削除マーカーを適用します。通常の問い合わせは残り、対象と派生キーが見えないか確かめます。
- 提供元での確認。 テスト用の外部IDで削除を依頼し、状態を確認します。依頼の範囲外で契約上保管されるデータは、確認担当と次の確認日を記録します。
マーカーをバックアップと同じ時点に戻すと、削除承認まで古い状態になります。独立して管理した最新の記録を本番切り替え前に適用し、確認した復元世代を明示します。復旧点を使えるかの判断にはスナップショットとバックアップの違いも参考になります。
外部の提供元と残る範囲を確認する
学習への利用除外、非同期処理の保管、安全運用ログ、保管期間、削除は異なる設定や契約で扱われます。たとえばOpenAIのAPIデータ制御資料[7]は学習利用、悪用監視ログ、アプリ状態を分け、機能ごとの保管を示しています。利用中のアカウント、エンドポイント、ツールや再委託先を確認し、提供元が出せる証拠を求めます。過去に学習や微調整へ使った場合は入力ファイルの削除と、稼働モデルの重みに残る影響を個別に確認します。
完了時には利用を止めた場所、確認した稼働中のコピー、残った例外と未確認範囲を報告します。承認済み保存や外部回答待ちには担当と次の確認時点を付けます。本番に戻り得る復元データやエクスポートが対象外なら、データの関係を見直して影響を確認してから案件を閉じます。
