---
title: 退会機能の実装
description: 論理削除は「削除」にならない。識別子マスキングと法定保存データの分離設計
sidebar:
  label: 退会機能
---

| 項目 | 内容 |
|---|---|
| **疑うべき法令** | 個人情報保護法（利用停止・消去の請求権 第35条） |
| **確認タイミング** | 機能企画〜DB設計時 |

## なにが問題になるか

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

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

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

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

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

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

## 確認すべきこと

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

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

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

## あわせて確認

- 退会時のポイント残高の扱い → [退会時のポイント残高返金](/features/money/point-refund)

{/* 実務メモ: 書籍にない独自の追加情報はこの下に追記していく */}