アカウント削除を deleted_at の転記（論理削除）で実装していると、行自体が消えないため ON DELETE CASCADE が発火せず、配下データはすべて DB に残る。「ログイン不可になる」ことと「データが消える」ことは別で、後者を伴わないままプライバシーポリシーに「退会時に個人情報を削除」と書くと、実装と公表内容が乖離する。

契約化するときの複雑さ

単純なユーザー実削除では完結しない。

• 他ユーザーからの参照（いいね・ブックマーク・本文内の参照など）が残ると、外部キー制約で削除自体が失敗し得る。削除対象の閉包と削除順序を先に確定する。
• 外部サービス（決済・分析・外部 AI など）に既に渡ったデータは自サービスから削除できない。削除できない境界を仕様として明記する。
• 既存の論理削除済みレコードの扱いを決める。回収するのか、対象外とするのか。

前提の数え方を確認する

「過去の削除ユーザーはいないので回収不要」と判断するとき、「データを作った削除ユーザーが0件」と「論理削除済みの行そのものが0件」は別の主張。前者だけなら、データを持たない残留行の処理が未定義のまま残る。回収機能を作らない選択をするなら、リリース前の0件確認を完了条件に残す。