← 返回列表

データ保存期限ポリシー：解约时「返す/消す/残す」三分类

2026/9/14

B 方向·OPC 最佳实践（合规运营）。家族图谱是 要配慮個人情報 的集合体——保存期限不设计好，APPI 对应与 backup 事故两端都会出问题。

背景与问题

  • 解约用户的数据怎么办？见守 log、回忆录原稿、決済记录、audit_log——不同性质的数据需要不同的「期限」。APPI は利用目的達成後の廃棄を要求するが，ユーザー資産（成书原稿）は消してはいけない——三分类が必要。

发现

框架【推断：APPI 原则+既有 schema 的整理】：

  • 返す（返还）：回忆录原稿/相册照片=用户の資産——解约时全量 download（ZIP）提供→90 日 download 窗口→削除【推测：窗口期长度自行设定，規約明記】。
  • 消す（削除）：见守 log/vitals/通院メモ=目的达成的观察数据——解约即削除（D1 删除级联，opc-family-graph-schema 已設計）+backup 同步削除（R2/さくら双备份に残留=事故源）。
  • 残す（法定保存）：決済/請求記録=電子帳簿保存法（7 年）・消費税関係（7 年）——個人情報ながら法定保存義務が勝る，最低限のみ匿名化保持【推测：法务确认事项】。
  • audit_log（consent 変更履歴）は证明责任のため解约後も期间保持【推测：3-5 年，規約明記】。

结论

可行动启发：

  1. 三分类表进利用规约 12 条：「保存期间」条目を上の三分类で具体化（opc-terms-of-service-template への追記项）——解约フロー画面にも 1 行で表示（用户の不安を下げる=解約理由调查の missing_feature 减）。
  2. backup 削除自动化：解约→D1 级联+R2/さくら両 backup の对象キー削除を同一ジョブで——「本站は消えたが backup に残る」是最悪事故パターン（opc-security-baseline の检查项追加）。
  3. 90 日返还窗口的实现：解约時 ZIP 生成（大容量=R2 pre-signed URL）+LINE/邮件で通知 2 回（Day0/Day60）——回忆录用户の资产焦虑を最も安く解消。
  4. 法定保存データは最小化：決済は Paddle 側にも残る——自社保存は tax 用の集計のみ（個人情報の所在表を 1 页で管理：どのデータがどこに何年あるか）。

待办 / 下次继续

关联