削除依頼は、ユーザーテーブルに対するDELETEだけでは完了しません。複数のモジュールを持つアプリケーションでは、関連レコード、ファイル、検索インデックス、キュー、エクスポートデータ、外部サービスにも情報が存在する可能性があります。画面上のアカウントだけを削除すると、アクセス可能なコピーが残ることがあります。一方、無差別に削除すると、ほかの処理を正常に続けるために保持すべきデータまで影響を受けるおそれがあります。
PHPで検証可能なデータ削除を実現するには、適用範囲、責任者、状態、再試行、検証方法を明確にしたプロセスとして設計します。運用上の目標は、あらゆるコピーがただちに消えると約束することではありません。どの保存先を処理したか、それぞれでどのような結果になったか、どの制約が未解決かを特定できるようにすることです。
実行前に適用範囲を定義する
依頼を、データの種類とシステムの一覧に落とし込みます。たとえば、アカウントにはプロフィール、設定、セッション、ドキュメント、コメント、アクティビティイベントが関連付けられている場合があります。請求書など、共有レコード内に参照が含まれていることもあります。各データについて、適用される社内ポリシーに基づき、削除、関連付けの解除、匿名化、保持のいずれが適切かを決めます。これらを同じものとして扱ってはいけません。匿名化では想定するコンテキストにおいて本人を識別できなくする必要があり、関連付けを解除しても元のデータが削除されるとは限りません。
各保存先について、「完了」の意味も定義します。メインデータベースから行を削除しただけでは、検索インデックスが更新されたことも、ファイルが削除されたことも証明できません。データベース、オブジェクトストレージ、キャッシュなど、直接管理できる保存先と、特定のバックアップのようにプロバイダーや保持期間に依存する保存先を区別します。最終状態では、この違いを単一の「成功」ラベルで隠さずに示します。
コピーを洗い出し、責任者を割り当てる
データの一覧は、データベーススキーマだけでなく、実際のデータフローをたどって作成します。ジョブキュー、検索インデックス、分析システム、一時ファイル、アプリケーションログ、連携ツールなど、データが作成、エクスポート、変換される場所を確認します。各チームに、レコードの特定に使える識別子と、そのシステムが対応する操作を確認してください。
保存先ごとに技術責任者を割り当て、処理方法、期待する応答、再試行、制約を文書化します。安定した識別子で検索できないシステムがあれば、検証が困難になるため、設計上の負債として扱います。削除依頼の記録自体に個人データのコピーを追加で保存することは避けてください。通常は、内部ケースID、処理に必要な参照情報、最小限の結果だけで十分です。
システムごとの状態と結果をモデル化する
堅牢なプロセスでは、たとえばreceived、validated、in_progress、partially_completed、verification_pending、completed、failedのような状態を明示します。状態遷移と、それを開始できる担当者を合意しておきます。必須の保存先に検証可能な結果がない間は、依頼を完了としてはなりません。
各システムの結果は個別に記録します。状態には、保留、削除済み、該当データなし、再試行可能、要確認、文書化された制約あり、などがあります。「該当データなし」も有効な結果になり得ますが、正しいキーを使い、想定した範囲を網羅して検索した場合に限ります。一時的な障害（サービス停止など）と、対応が必要な恒久的な拒否を区別してください。
PHPでは、処理全体の調整と、保存先ごとの処理を分離します。アプリケーションサービスがケースを読み込み、権限を確認してタスクをディスパッチし、独立したアダプターがデータベース、ストレージ、API向けの操作を実装できます。これにより、プロバイダーの変更時にビジネスロジックと通信方式の詳細を混在させずに済みます。また、ケースの作成と参照にはアクセス制御を設け、管理操作を誰が開始したかを記録してください。
依存関係を考慮して削除の順序を決める
削除の前に、アカウントに依存する関係と、共有されている関係を特定します。外部キーや削除時のカスケード設定は整合性の維持に役立ちますが、個人所有のデータと共有データが同じモデルに混在している場合、カスケードによって想定以上のデータが削除されることがあります。各関係の影響を確認し、適用範囲が明確でない場合は明示的な操作を優先してください。
一般的な手順としては、対象に関連する新たな書き込みを停止し、セッションや認証情報を無効化し、内部依存関係を除去してから、対象自身のレコードを削除または変換し、その後、インデックスや外部サービスに処理を伝播させます。具体的な順序はアーキテクチャによって異なります。他システムのデータ特定に必要なキーを先に削除すると、処理の継続に必要な情報を失う可能性があります。その参照情報は保護し、必要な期間に限って保持してください。運用記録を別のデータ保管庫にしてはいけません。
冪等性と再開可能性を確保する
分散ジョブは、操作の完了後、結果を通知する前に失敗することがあります。そのため、各ステップは、不適切な副作用を起こさずに繰り返せる必要があります。冪等な削除処理では、レコードがすでに存在しない場合も受け入れ、常にエラーとして扱うのではなく、制御された結果を返せます。
保存先ごとに進捗を保存し、リモートシステムが対応していれば、冪等性キーまたは安定したケースIDを使用します。各保存先の処理は適切なトランザクションまたは作業単位で実行し、APIの応答を待つ間、データベーストランザクションを開いたままにしないでください。失敗時は上限を設け、待機戦略に従って再試行します。再試行を使い切ったエラーは、ログに埋もれさせず、確認用キューに送る必要があります。
再開時は未完了のステップから続行します。安全でない操作を繰り返したり、以前の結果を上書きしたりする可能性がある場合、フロー全体を最初からやり直してはいけません。特に、「依頼送信済み」と「削除確認済み」を区別してください。HTTPの成功応答が確認するのは受信であり、リモート処理の完了とは限りません。プロバイダーと、各応答が何を意味するかを定義しておきます。
削除対象を保持せずに検証する
検証方法は、保存先と操作の種類に合わせます。データベースでは、想定したキーで検索し、適用範囲内に行が残っていないことを確認できます。ストレージでは、オブジェクトが存在しないこと、または削除機構の応答を確認できます。インデックスでは、適切なキーでドキュメントを検索し、反映にかかる時間を考慮します。ワーカーの成功メッセージだけでは、こうした検証の代わりになりません。
ケースID、保存先、操作、タイムスタンプ、状態、安全な場合は処理件数、結果の技術的な参照情報など、最小限の証跡を記録します。削除した内容、認証情報、トークン、不要な個人識別子をログやメトリクスに複製しないでください。監査記録を保護し、アクセスを制限し、社内での保持期間を定めます。証跡は、削除しようとした情報を再現せずに、処理内容を説明できるものでなければなりません。
制約に対処し、フローをテストする
バックアップは明示的に扱う必要があります。即時の選択的削除ができない場合があるため、想定する保持サイクルと、復元によって削除済みデータが再導入されないようにする方法を文書化します。たとえば、復旧手順の中で、復元したシステムを有効にする前に、保留中または完了済みの削除依頼を再適用できます。利用可能な仕組みが保持期間の満了を待つだけなら、バックアップが削除済みだと主張してはいけません。
外部システムについては、誰が処理を開始できるか、プロバイダーがどのような確認を返すか、結果が不確かな場合にいつエスカレーションするかを明記します。運用上の制約は検証成功と同じではありません。入手可能な証拠に応じて、保留、制限あり、解決済みとして表示する必要があります。
運用開始前に、合成データを使って非本番環境でフローをテストします。重複依頼、共有関係、存在しないファイル、タイムアウト、曖昧な応答、ステップ完了後の障害を試してください。再試行によって副作用が重複しないこと、権限によって不正なアクセスが阻止されること、レポートからデータが漏えいしないことを確認します。本番環境では、アラートに個人情報を含めず、障害数、未解決ケースの滞留期間、確認が得られていない保存先を監視してください。
チェックリスト：適用範囲と例外の定義、保存先と責任者の洗い出し、状態と遷移の文書化、依存関係の確認、冪等かつ再開可能なステップ、システムごとの検証、最小限に抑えて保護した証跡、バックアップとプロバイダーの制約の共有、障害テストの実施、確認とエスカレーションの手順の整備。これらの管理策により、チームは追跡可能な形で対応し、削除の開始と結果の確認を混同せず、処理がどこで止まったかを正確に把握できます。
