退会機能の実装

論理削除は「削除」にならない。識別子マスキングと法定保存データの分離設計

なにが問題になるか

退会機能でエンジニアがよく選ぶ論理削除（deleted_at フラグ）は、参照整合性や誤削除からの復元の面で実務上合理的です。しかし個人情報保護法の観点では、論理削除はユーザーの個人情報を「削除した」とは言えません。

2022年改正で「保有の必要がなくなった場合」も消去請求の対象に加わりました。退会したユーザーのデータは「サービスの提供」という当初目的が終了しているため、これに該当すると解釈されるケースがあります。論理削除のまま残していると、「退会したのにデータが残っているのでは？」という指摘に法的根拠を持って答えるのが難しくなります。

一方で、法的義務として保存しなければならないデータもあります。電子帳簿保存法による取引記録の7年間保存、特商法に基づく返金対応のための購入履歴などです。

現実的な落としどころは：

• 「サービス利用に関わる個人情報」と「法定保存義務のある取引記録」を別テーブル・別ストレージに分離する
• 退会イベントをトリガーに、識別子カラム（メールアドレス・氏名・住所など）を NULL でマスキングする
• 年齢・性別などの属性は統計用テーブルに移す

個人情報保護法が求めるのは「特定の個人を識別できなくなること」であり、必ずしも物理削除ではありません。識別できない形に加工すれば個人情報ではなくなるため、分析目的での保持も可能になります。

確認すべきこと

• 退会機能の設計方針（消すデータ・残すデータ）を確認した
• 退会時に消すべきデータ（識別子）と残すべきデータ（法定保存義務のある取引記録）を別テーブルまたは別ストレージで設計した
• 識別子マスキング処理を退会フローに組み込んだ
• 「分析のために残す」データが匿名化（個人を識別できない形）されている
• 運用中、マスキングと法定保存データの保持が正しく機能しているか定期確認している

こんな仕様が出たらアラート

• 退会機能の実装（論理削除・物理削除の選択）
• 退会後もデータを「分析のために」保持する
• 退会ユーザーのデータを復元できる仕様

あわせて確認

• 退会時のポイント残高の扱い → 退会時のポイント残高返金