問題と背景
ある企業では、PostgreSQL、検索インデックス、キャッシュ、追記専用（append-only）イベントログ、Icebergレイクハウス、DWH、サードパーティプロセッサー、日次バックアップにユーザーデータを保存しています。承認された忘れられる権利（right-to-erasure）リクエストを実行するパイプラインを設計してください。対象者のエイリアスを解決し、部分的な障害を処理し、古いイベントやリストアされたバックアップによって削除済みデータが再作成されるのを防ぎ、信頼性の高い完了証跡を生成する必要があります。
プライバシーまたは法務サービスがすでにリクエスト者を検証し、リクエストを承認し、そのスコープを定義し、適用される例外を記録し、ポリシー上の期限を提供していると仮定します。データプラットフォームはその決定を実行します。面接では、エンジニアに法律の解釈を求めているわけではありません。
ポリシーの境界を明確に保ってください。GDPR第17条は消去権を定義するとともに条件や例外も列挙しているため、承認されたリクエストには記録されたスコープが必要です。第19条では受領者への通知が求められる場合があります。また、本番システム、バックアップ、バージョン管理されたテーブルでは、削除状態がそれぞれ異なります。バックアップデータは利用停止（beyond use）状態に置かれながら上書きされるまで残る可能性があり、削除されたIcebergの行は古いスナップショットが参照するファイル内に残る可能性があります。ワークフローは、これらを単一のデータベース応答にまとめるのではなく、それらの状態を適切に表現しなければなりません。
最も堅牢な設計は、消去を永続的でポリシーに基づいたスコープを持つデータワークフローとして扱うことです。検証された対象者のアイデンティティから開始し、データインベントリとリネージグラフからバージョン管理されたターゲットマニフェストを導出し、ターゲットごとに冪等な処理を実行し、復活を阻止し、完了前に必要なすべてのターゲットを検証します。
面接官が評価しているポイント
第1に、候補者がコントラクトを定義できるかどうかです。アカウント閉鎖、ビジネスレベルの削除イベント、アクセス制限、承認された消去は、それぞれセマンティクスが異なります。削除サービスには、承認されたスコープ、有効なカットオフ日時、ポリシー期限、例外、および証跡要件が必要です。それらを勝手に推測して作成してはなりません。
第2に、候補者が実際のデータモデル全体から個人を特定できるかどうかです。メールアドレスだけでは不十分なことがほとんどです。同一人物が、アカウントID、テナントスコープID、デバイスID、決済顧客ID、サポート用アイデンティティ、アカウント統合時に置き換えられた識別子などを持っている場合があります。優れた回答では、制御されたアイデンティティ解決ステップを導入し、複数の対象者に属する共有レコードを考慮します。
第3に、候補者が異種ストレージの削除について論理的に考えられるかどうかです。行指向ストアは行の物理削除（hard-delete）や墨消し（redact）が可能です。検索やキャッシュは無効化が必要です。イミュータブルなオブジェクトファイルは書き換えが必要になる場合があります。レイクハウスの削除では新しいスナップショットが作成されますが、古いスナップショットは以前のファイルを参照したままになります。集計データには匿名化と再計算の判断が必要です。バックアップや外部プロセッサーには独自の完了セマンティクスがあります。
第4に、ワークフローがリトライや障害に耐えられるかどうかです。すべてのシステムにファンアウトする同期リクエストはタイムアウトし、あいまいな部分的状態を残します。面接官は、永続的な状態管理、冪等なターゲットタスク、有界リトライ、オーナーシップ、期限、そしてリトライ可能な障害・文書化された保持・適用除外・恒久的な実装ギャップを区別する方法を期待しています。
最後に、候補者がデータが削除された状態を維持できることを証明できるかどうかです。オーケストレーションジョブの正常終了（緑色）だけでは弱い証拠です。設計では、ターゲットでの不在、保持されたバージョン、リプレイ経路、リストア手順、新しく発見されたストア、ダウンストリームでの確認をテストしなければなりません。消去が承認された個人データそのものを保持することなく、復活を防ぐために十分な非個人データまたは最小化された管理証跡を保持する必要があります。
尋ねるべき確認質問
- 具体的に何が承認されたか？ どの対象者、管轄区域、データ利用目的、期間、プロダクト、法的例外がスコープ内ですか？最終的なポリシー決定のオーナーは誰ですか？
- 対象者キーは何か？ 安定した内部対象者IDは存在しますか？解決すべき過去のエイリアス、統合されたアカウント、テナントID、デバイスID、外部プロセッサーIDは何ですか？
- どのレコードが共有されているか？ 注文、会話、組織レコード、不正証跡、金融取引などは、複数人に紐づいているか、承認された保持要件を持つ場合があります。他の人のレコードを破損することなく削除できるフィールドはどれですか？
- データインベントリはどうなっているか？ すべてのストアがオーナー、対象者ロケーター、削除モード、リネージ、保持動作、検証機構、リストア手順を宣言していますか？未登録のアセットはどのように検出されますか？
- どのストアがミュータブル（更新可能）か？ イベントログやオブジェクトファイルは書き換え可能ですか？論理削除後もクエリ可能なレイクハウスのスナップショットやDWHのタイムトラベルバージョンはどれですか？
- バックアップの完了条件は何か？ バックアップは選択的に書き換え可能ですか、それとも有効期限切れを待つ必要がありますか、あるいは利用停止状態に制限できますか？リストアされたサービスがトラフィックを受け入れる前に、古いバックアップはどのように安全化されますか？
- カットオフ後に新しいデータが到着する可能性はあるか？ アカウント閉鎖により新規アクティビティはブロックされますか？遅延イベント、CDCのリトライ、インポート、または再作成されたアカウントが古い識別子を使用することはありますか？
- どのプロセッサーにデータが送信されたか？ API、チケット、契約上の確認パスはありますか？ターゲットタスクが終端状態に達する前にどのような証跡が必要ですか？
- 期限とエスカレーションのルールは何か？ どの障害でオーナーにページャー発報し、いつリクエストが期限超過となり、誰が文書化された例外を承認できますか？
- 検証でのデータ漏洩をどう防ぐか？ ログに個人情報をコピーするのではなく、プローブがカウント、スナップショットID、ソルト付き証拠を返すようにできますか？
30秒の回答フレームワーク
「私は、承認された消去リクエストを永続的なワークフローを通じて実行します。同期ファンアウトは、1つのターゲットがタイムアウトした際にあいまいな部分的状態を残してしまいます。制御されたアイデンティティサービスが対象者を不透明な内部・外部識別子に解決します。バージョン管理されたカタログとリネージグラフがターゲットマニフェストを生成し、各アダプターが冪等な削除、書き換え、制限、またはプロセッサー通知を実行します。抑制（サプレッション）レコードにより、古いイベントやリストアされたバックアップによるデータの再作成を阻止します。完了には、ターゲットレベルの不在チェック、スナップショットおよびバックアップ保持の証跡、プロセッサーの確認、およびリプレイテストが必要です。新しく発見されたアセットがあれば、リクエストを再オープンします。」
ステップごとの詳細解説
ステップ1: ポリシー決定とパイプライン実行を分離する
アイデンティティ検証とスコープ承認の後、イミュータブルなリクエストエンベロープを作成します。これには、リクエストID、不透明な対象者参照、承認されたプロダクトと目的のスコープ、カットオフ、期限、ポリシーバージョン、例外参照、および承認決定が含まれる必要があります。未加工の身元確認書類やフリーフォーマットの法務メモは、オーケストレーション台帳から除外してください。
received（受信済み）、authorized（承認済み）、planned（計画済み）、executing（実行中）、verifying（検証中）、completed（完了）、partially completed（部分完了）、rejected（拒否）、overdue（期限超過）などの明示的な状態を使用します。状態遷移は追記専用であり、追跡可能（attributable）です。承認されたターゲットマニフェスト内のすべての項目に、許可された終端結果（消去済み、日付指定の有効期限まで利用停止、プロセッサーによる確認済み、または文書化された例外の対象）が記録されて初めて、リクエストは完了できます。
この境界により、2つの危険なショートカットを回避できます。エンジニアがすべての集計データは匿名であると勝手に判断することはなく、法務サービスもワークフローがキューに入っただけでリクエストを完了とマークすることはありません。双方が自身が責任を持つ決定または証跡を提供します。
ステップ2: アイデンティティを一度だけ解決し、履歴を安全に保持する
検証された個人を安定した対象者キーに解決し、制限されたアイデンティティグラフを通じてそれを展開します。候補となるエッジには、現在および以前のアカウントID、統合アカウントID、テナントスコープID、デバイス識別子、決済顧客ID、CRMコンタクト、およびサードパーティプロセッサーの参照が含まれます。
グラフには有効日と出所（provenance）が必要です。再利用されたメールアドレスや電話番号を、2つのアカウントが同一人物のものであるという普遍的な証拠として扱うことはできません。共有オブジェクトにはフィールドレベルのルールが必要です。ある参加者を削除しても、別の参加者の注文やメッセージを削除すべきではありませんが、最初の参加者の直接的な識別子は削除または置換が必要になる場合があります。
リクエスト固有のアイデンティティバージョンを計画内で凍結します。後からエイリアスが発見された場合は、それを追記して影響を受けるターゲットを再生成します。タスクのペイロードには、最小化されアクセス制御されたロケーターのみを保存します。ログには、氏名や未加工のメールアドレスではなく、リクエストID、ターゲットID、カウント、バージョンを使用する必要があります。
ステップ3: インベントリとリネージからターゲットマニフェストを生成する
対象者データを保持する可能性のあるすべてのデータアセットは、削除コントラクトを登録する必要があります：
- オーナーおよびエスカレーションチャネル
- 対象者ロケーターおよびアイデンティティ名前空間
- データ利用目的および保持クラス
- アップストリームおよびダウンストリームのリネージ
- 物理削除、フィールド墨消し、ファイル書き換え、暗号鍵破棄、アクセス制限、プロセッサー通知などの削除アクション
- スナップショット、タイムトラベル、バックアップの期待される動作
- 冪等性キーおよびサポートされるリトライセマンティクス
- 検証クエリまたはプローブ
- 証跡スキーマおよび終端状態ルール
プランナーは、承認されたスコープ、凍結されたアイデンティティセット、カタログ、およびリネージグラフを結合して、バージョン管理されたマニフェストを生成します。マニフェストは実行前に確認可能であり、一致件数がゼロと予想されるターゲットも含まれます。理由のない除外は、明示的なゼロよりも危険です。
カタログのカバレッジには独自の監視・制御が必要です。ストレージアカウント、DWH、トピック、バケット、スキーマ、インデックス、プロセッサーレジストリをスキャンして、未登録のアセットを検出します。ランタイムアクセスログおよびリネージイベントをカタログと比較します。スコープ内のデータを含む新しく登録されたダウンストリームアセットは、オープンなすべてのリクエストに対してターゲットタスクを作成し、ポリシーに従って完了したリクエストを再オープンする場合があります。
ステップ4: 永続的で冪等なワークフローを実行する
少なくとも1回の配信（at-least-once delivery）を備えたキューまたはワークフローエンジンを使用します。リクエスト状態マシンは、ターゲットおよびアイデンティティ名前空間ごとに1つのタスクをスケジュールします。ターゲットアダプターは、リクエスト、ターゲット、対象者ロケーターのバージョン、およびアクションのバージョンから冪等性キーを導出します。完了したタスクを繰り返しても同じ終端証跡が返され、2回目のあいまいな変更が発生することはありません。
ターゲットのステータスを個別に永続化します：pending（保留中）、running（実行中）、retryable failure（リトライ可能な失敗）、blocked（ブロック）、erased（消去済み）、restricted until expiry（期限まで制限中）、processor pending（プロセッサー処理待ち）、exception（例外）、verification failed（検証失敗）。一時的なエラーには有界の指数バックオフを使用し、試行回数が上限に達した場合はデッドレターまたはブロック状態にし、オーナーが確認できる期限を設けます。部分的な障害によって成功した削除がロールバックされてはなりません。
オーケストレーターは、すべてのストアにわたって分散トランザクションを保持すべきではありません。承認された最終状態にフォワードアクションを収束させるサーガ（Saga）のように振る舞います。補償トランザクション（Compensation）とは、通常、保護された信頼できる情報源（Single Source of Truth）から個別の承認の下で過度な墨消しを修正することを意味し、以前に消去されたすべてのデータを復元することではありません。
ステップ5: ストレージクラスごとに削除アクションを選択する
トランザクショナルデータベース: 安定した対象者キーとマッピングされたエイリアスによって行を特定します。対象者のみが所有する行は物理削除します。共有または保持されるレコードについては、承認されたフィールドを墨消しするか、対象者へのリンクを非識別値に置き換えます。外部キーの順序を尊重し、プライマリテーブルとセカンダリテーブルの両方を検証します。
検索、キャッシュ、特徴量、ベクトルインデックス: ドキュメントとエンベディングを削除し、キャッシュキーを無効化し、インデックスが非同期の場合は強制リフレッシュを行います。ソーステーブルでの削除は、古い検索ドキュメントや特徴量ベクトルが消えたことを証明しません。検証機構はソースだけでなく配信サーフェス（serving surface）にもクエリを実行する必要があります。
イベントログとRAWオブジェクトストレージ: レコードを安全に書き換えられる場合は、対象者を除外して影響を受けるパーティションをコンパクションします。保持期間中にソースがイミュータブルである場合は、消去ツームストーン（tombstone）またはサプレッショントークンを登録し、すべてのマテリアライザー、リプレイ、エクスポート、ブートストラップパスにそれを参照させます。ソース自体は承認された制限または期限切れ計画に従います。ツームストーン単体では物理的な消去を主張できません。
レイクハウステーブル: 適切な場合はequality deleteまたはposition deleteを適用するか、より強力な物理的削除が必要な場合は影響を受けるファイルを書き換えます。コミットIDとスナップショットIDを記録します。現在のスナップショットに対するクエリでは0行と表示されても、古いスナップショットが依然としてファイルを参照している場合があります。Apache Icebergでは、保持されているスナップショットが参照しなくなるまでデータファイルが残るため、タスクは対応する物理削除ステージを主張する前に、スナップショットの有効期限切れと孤立ファイルのクリーンアップを追跡する必要があります。
DWHテーブルとマテリアライズドビュー: キー指定された行を削除し、必要に応じて影響を受けるパーティションを再構築し、マテリアライズドビューをリフレッシュし、クローン、抽出、タイムトラベルバージョンを列挙します。プロダクト固有の保持期間は設定値であり、普遍的な定数ではありません。たとえば、BigQueryは設定可能なタイムトラベルと追加のフェイルセーフ期間を文書化しています。マニフェストは実際のプラットフォームポリシーを読み取り、古いバージョンがいつアクセス不能になるかを記録する必要があります。
サードパーティプロセッサー: プロセッサーがサポートするチャネルを使用してスコープ指定されたリクエストを送信し、安定した冪等性参照を添付し、受領確認と完了ステータスを保持します。GDPR第19条は、該当する場合における受領者への通知を規定しています。契約上、機械可読な確認またはチケット状態が提供されている場合、送信されたメールは完了証跡にはなりません。
ステップ6: 集計、モデル、匿名化を慎重に処理する
出力によって対象者が依然として特定または識別可能（singled out）かどうかを問い直します。仮名化されたデータはキーまたはトークンを通じてリンクされたままであり、単にメールアドレス列を削除しただけで匿名と呼ぶことはできません。真に匿名化された集計データは消去対象外となる場合がありますが、プライバシー責任者がその分類を承認する必要があります。
キー付きまたは小規模コホートの集計については、許可されたソースレコードから影響を受けるパーティションを再構築します。引き算（減算）による更新は、十分な寄与度メタデータが保持された可逆的なメトリクスに対してのみ機能します。パーセンタイル、スケッチ、学習済みエンベディング、および多くのモデルアーティファクトは、1行を引き算するだけでは安全に修正できません。文書化された再構築、再トレーニングポリシー、または承認された匿名化の決定を選択してください。
モデルの取り扱いは、脅威とプロダクトのコントラクトに依存します。まず、対象者レベルの特徴量、サンプル、検索ドキュメント、キャッシュ、評価フィクスチャを削除します。次に、モデル自体がスコープ内にある場合は、承認された再トレーニングまたはモデルアンラーニング（機械学習の忘却）ポリシーを適用します。削除パイプラインはそのポリシーの決定と証拠を記録します。トレーニング行を削除することで既存のモデルからその影響が自動的に除去されると約束してはなりません。
ステップ7: 競合、リプレイ、リストアによる復活を防ぐ
不透明な対象者トークンとリクエストのカットオフ日時をキーとする最小化されたサプレッション（抑制）レジストリを維持します。取り込みおよびマテリアライゼーションパスは、古いイベントを配信ストアや分析ストアに書き込む前にこれをチェックします。このレジストリは、削除された対象者を認識するためだけに存在するため、通常のログよりも厳格なアクセス制御と保持制御が必要です。
並行するデータ取り込みに対して削除順序を制御します。可能な場合は対象者キーで処理をパーティショニングするか、ソースのウォーターマークを記録し、すべてのライターがカットオフを通過した後に最終スキャンを再実行します。リクエスト後の真に新しい正当なアクティビティをどのように処理するかは個別に決定します。古いイベントのリプレイは抑制されますが、有効な製品目的の下で新しいアカウントを作成する個人には、永続的なグローバルブロックではなく、新しい対象者エポックが必要になる場合があります。
すべてのリストア手順書（runbook）では、リストアされたサービスが読み取り可能になるかダウンストリームにデータを出力する前に、削除台帳とサプレッションセットを再適用しなければなりません。これをリストア訓練でテストします。ICO（英国情報コミッショナー庁）のガイダンスでは、バックアップデータを利用停止（beyond use）にすることを義務付けつつ、状況によっては上書きされるまで保持することを認めています。運用上の帰結として、アクセス制限に加えて削除の再適用、文書化された有効期限、およびバックアップからの通常目的での処理を行わないことが求められます。
ステップ8: 独立した証跡で完了を検証する
変更を実行するアダプターは実行証跡を出力できますが、完了の判断は独立した検証機構が行うべきです。ターゲットごとに以下を記録します：
- ターゲットおよびスキーマのバージョン
- アイデンティティロケーターのバージョン
- アクション、試行、および完了のタイムスタンプ
- 影響を受けた行、ドキュメント、オブジェクト、またはファイル
- 現在の配信サーフェスでの不在プローブ
- 保持されているスナップショットまたはバックアップの状態と予想される有効期限
- プロセッサーの確認参照
- 検証機構のバージョンと結果
カウントと不透明キーを使用して検証プローブを実行します。削除された値を証跡ストアにコピーすることは避けてください。サンプリングベースのチェックは、完了対象のリクエストに対する決定論的なチェックを補完することはできても、代替することはできません。
エンドツーエンドのコントロールを実行します：同一リクエストを2回送信する、変更後かつ受領確認前に各ターゲットを中断する、古いイベントをリプレイする、古いバックアップを隔離環境にリストアする、アイデンティティの統合と分割を行う、アカウントを再作成する、未登録のダウンストリームテーブルを追加する、1つのプロセッサーをオフラインにする、共有レコードと文書化された例外を組み合わせて実行するなどです。必要なターゲットに検証機構がない場合やステータスが不明な場合は、フェイルクローズ（安全側に倒して失敗）とすべきです。
ステップ9: 測定可能な責務を持ってシステムを運用する
ポリシー期限に対するリクエスト完了時間、期限超過および部分完了リクエスト、ターゲットの成功率とリトライ率、マニフェストのカバレッジ、未知のアセット、プロセッサー確認のレイテンシー、スナップショットおよびバックアップ期限切れのバックログ、リプレイによる復活インシデント、リストア時の再適用成功率を追跡します。
ジョブの例外だけでなく、ワークフローの状態に対してもアラートを発報します。プロセッサーやスナップショットの有効期限切れを無期限に待機しているリクエストは、実行中の障害がなくても期限超過になる可能性があります。ブロックされた各ターゲットにオーナーとエスカレーションパスを割り当てます。疑わしいパターンがないか、例外の使用や一致ゼロのターゲットをレビューします。
コストモデルも重要です。オーケストレーションはターゲット数におおよそ比例しますが、物理的な作業は一致した行数および影響を受けるファイルやパーティションのバイト数に依存します。リクエストごとのトレーサビリティを損なうことなく、ファイル書き換えとスナップショットメンテナンスをバッチ処理します。リクエストは、どの共有メンテナンスタスクがその証拠を提供したかを依然として示せる必要があります。
質の高い模範解答
「私は、承認されたリクエストエンベロープ（リクエストID、不透明な対象者参照、承認されたスコープ、カットオフ、期限、ポリシーバージョン、および例外参照）のみを受け取ります。制限されたアイデンティティサービスが、その対象者をバージョン管理された内部、履歴、テナント、デバイス、およびプロセッサーIDに展開します。メールアドレスを普遍的なプライマリキーとして使用することはありません。
次に、カタログとリネージグラフからバージョン管理されたターゲットマニフェストを生成します。すべてのターゲットは、そのオーナー、ロケーター、アクション、保持動作、検証機構、および証跡コントラクトを宣言します。カタログには、本番データベース、インデックス、キャッシュ、RAWイベント、オブジェクトストレージ、レイクハウスおよびDWHテーブル、マテリアライズド出力、エクスポート、バックアップ、プロセッサーが含まれます。インフラストラクチャの自動検出とランタイムリネージが実際のアセットをそのカタログと比較するため、未知のストアが存在する場合は完了をブロックするか再オープンします。
実行は、少なくとも1回の配信と冪等なターゲット別タスクを備えた非同期状態マシンです。リトライでは、リクエスト、ターゲット、アイデンティティバージョン、およびアクションバージョンをキーとして使用します。行ストアは単独所有の行を物理削除し、共有または保持されるレコードの承認されたフィールドを墨消しします。配信インデックス、キャッシュ、特徴量ストア、およびベクトルストアは削除され、個別にクエリ検証されます。RAWのイミュータブルログはサプレッションレコードを受け取り、承認された制限または期限切れ計画に従います。すべてのリプレイパスはそのサプレッションレコードを参照しなければなりません。
Icebergについては、行削除を適用するか影響を受けるファイルを書き換え、コミットとスナップショットを記録し、古いスナップショットの有効期限切れを追跡します。現在のクエリ結果がゼロ件であっても、基盤となるファイルが削除されたとは限らないためです。DWHでもクローン、マテリアライズドビュー、抽出、タイムトラベルバージョンに対して同様の処理が必要です。キー付きまたは小規模コホートの集計は、許可された入力から再構築されます。真に匿名の集計は、プライバシー責任者がその分類を承認した後にのみ保持されます。
バックアップには明示的な終端状態があります。選択的な書き換えが利用できない場合、リクエストには利用停止制限ステータスと予定された上書き日を記録します。削除台帳とサプレッションレジストリが再適用されるまで、リストアされた環境からトラフィックを処理することはできません。サードパーティプロセッサーには冪等タスクが割り当てられ、必要な確認が届くまで保留状態（pending）のままになります。
競合状態を防ぐため、ソースのウォーターマークを記録し、ライターがカットオフを通過した後に最終スキャンを実行します。遅延した古いイベントやリプレイされたイベントは抑制されます。ポリシーで許可されている場合、新しい正当なアクティビティには新しい対象者エポックが付与されるため、リプレイ保護が無制限のアカウント凍結になってしまうことはありません。
独立した検証機構が、各配信サーフェス、現在のテーブル状態、保持されたスナップショット、バックアップ状態、およびプロセッサーの証拠をチェックします。すべてのターゲットが許可された終端状態になって初めて、リクエストを完了できます。重複配信、変更と確認の間のクラッシュ、オフラインのターゲット、リプレイ、隔離リストア、アカウント再作成、アイデンティティ統合、共有レコード、新しく発見されたアセットをテストします。
私の運用メトリクスには、期限遵守率、部分完了および期限超過件数、カタログカバレッジ、未知のターゲット、リプレイ復活インシデント、スナップショットおよびバックアップ期限切れバックログ、プロセッサーレイテンシー、リストア再適用の成功率が含まれます。この設計により、個人情報を通常のログから排除し、法的なスコープ判断をデータパイプラインの外に保ちながら、永続的な証跡を企業に提供できます。」
よくある間違い
- プライマリアカウント行のみを削除する → インデックス、分析テーブル、エクスポート、プロセッサーにコピーが残る → リネージに裏付けられたターゲットマニフェストを生成し、必要なすべての配信およびストレージサーフェスを検証する。
- メールアドレスをユニバーサルな対象者キーとして使用する → メールアドレスは変更や再利用の可能性があり、統合されたアイデンティティや外部アイデンティティを見落とす → 出所情報を持つバージョン管理されたアイデンティティグラフを通じて、検証された対象者を解決する。
- リクエストAPIから同期ファンアウトを呼び出す → 1つのタイムアウトが未知の部分的状態と危険なリトライを引き起こす → ターゲットごとの永続タスク、明示的な状態、冪等性、オーナーへのエスカレーションを使用する。
- 論理削除を消去完了として扱う → 特権クエリ、エクスポート、リプレイ、リストアからデータが読み取り可能なままになる → 論理削除は承認された制限フェーズとしてのみ使用し、最終アクションまたは有効期限を追跡する。
- 現在のクエリがゼロを返した時点でIcebergの削除を完了とマークする → 保持されたスナップショットが依然として古いファイルを参照している可能性がある → スナップショットの状態を記録し、承認された有効期限切れおよびクリーンアップステージを待つ。
- すべての集計データが匿名であると決めつける → 小規模コホート、結合キー、仮名化識別子によって、依然として個人が特定または識別される可能性がある → 明示的な匿名化の判断を取得し、必要に応じて影響を受ける出力を再構築する。
- リプレイとリストアを無視する → 後からのバックフィルやバックアップリカバリによって、データがあらゆる場所で再作成される → 最小化されたサプレッションレジストリを維持し、リストアされたデータが提供される前に削除台帳を再適用する。
- 未加工のアイデンティティ値を証拠としてログに記録する → 監査証跡自体が削除対象データの新たな管理外のコピーになってしまう → 不透明な参照、カウント、バージョン、状態遷移、アクセス制限された証拠を保存する。
- 「プロセッサーにリクエスト送信済み」を完了として扱う → 送信完了はプロセッサーが処理を実行したことを証明しない → 契約に従って受領確認、最終確認、期限、エスカレーションを追跡する。
- 変更ジョブ自身に検証を行わせる → 呼び出しが成功しても、古いインデックス、スナップショット、サイレントなノーオペレーション（何もしない処理）を見落とす可能性がある → 独立したターゲットプローブと、エンドツーエンドのリプレイ・リストアテストを実行する。
フォローアップの質問と回答
フォローアップ1: 集計テーブルに影響する削除リクエストをどのように処理しますか？
まず各出力を分類します。責任を持つプライバシー責任者がその結論を承認した場合、真に匿名化された集計データは保持される可能性があります。仮名化された出力、キー付き出力、または小規模コホートの出力は、アクションの対象候補のままです。許可されたソースレコードから影響を受けるパーティションを再構築します。単純な引き算が安全なのは、信頼できる寄与度メタデータを持つ可逆的な集計のみです。パーセンタイル、スケッチ、および多くの学習済みアーティファクトは、再計算または個別の承認済みポリシーを必要とします。
フォローアップ2: Kafkaのリプレイによる削除済み行の再作成をどのように阻止しますか？
派生システムが完了を宣言する前に、永続的なサプレッションレコードを書き込みます。すべてのコンシューマー、バックフィル、マテリアライザー、ブートストラップパスは、不透明な対象者トークンとイベントのカットオフ日時をチェックします。ソースのウォーターマークを記録し、現在のライターがそれを通過した後に最終スキャンを実行します。カットオフ前のイベントを隔離環境にリプレイし、どのターゲットも再び読み取り可能にならないことを証明してテストします。
フォローアップ3: 古いバックアップがリストアされた場合は何が起こりますか？
隔離された環境にリストアします。トラフィックの開放やダウンストリームへの出力を開始する前に、バックアップ作成後からリストア前までに記録された関連するすべての削除リクエストを適用し、サプレッションレジストリをリフレッシュし、ターゲット検証機構を実行します。リストアされたサービスに適用された最新の削除台帳ポジションを記録します。予定された上書きまで残るバックアップはアクセス制限されたままであり、通常の処理目的で使用することはできません。
フォローアップ4: 期限直前に必要なデータストアが利用できない場合はどうしますか？
リクエストを部分完了または期限超過のまま維持し、成功したターゲットの結果を保持し、利用できないターゲットを冪等にリトライします。ポリシー期限の前に、指名されたオーナーおよびプライバシー運用オーナーにエスカレーションします。承認された例外のみが、ターゲットに必要な終端状態を変更できます。オーケストレーターは、試行回数の上限に達したリトライを勝手に成功に変換してはなりません。
フォローアップ5: 削除後のアカウント再作成をどのようにサポートしますか？
過去のリプレイ保護と、将来の正当なアクティビティを分離します。再作成されたアカウントに新しい対象者エポックと新しい内部IDを付与します。サプレッションレジストリは、承認されたカットオフ以前の古い識別子とイベントを引き続き拒否しますが、ポリシー制御によって新しいデータを収集できるかどうかが決定されます。アイデンティティ解決では、新しいエポックが過去の派生レコードに誤って再紐付けされないようにする必要があります。
フォローアップ6: 暗号学的消去（暗号鍵の破棄）は物理的削除の代わりになりますか？
検証されたストレージ設計の下でのみ可能です。関連するすべてのコピーが対象者固有のキーで暗号化されている場合、そのキーを破棄することでデータにアクセス不能にすることができます。共有キー、平文インデックス、ログ、キャッシュ、エクスポート、バックアップ、または保持されたキーコピーが存在する場合、その主張は破綻します。暗号鍵の破棄は、万能なショートカットではなく、独自のインベントリと検証機構を持つ1つのターゲットアクションとして扱ってください。
フォローアップ7: カタログが完全であるとどうやって把握しますか？
宣言されたアセットを、クラウドインベントリ、DWHのメタデータ、トピックやバケットの一覧、プロセッサーレジストリ、ランタイムリネージまたはアクセスイベントと継続的に比較します。新しいアセットが対象者データを処理する前に、削除コントラクトを必須とします。未知のアセットはカバレッジアラートを生成し、影響を受けるリクエストをブロックまたは再オープンします。定期的なリストアおよびリプレイ訓練により、静的リネージが見落としがちな経路を明らかにします。