HaRu-LLC avatar

privacy-email-review

メール取得を伴う機能のプライバシー設計レビューを行う。メールアドレスを保存する機能を実装する前、PII取得の設計確認時に使う。

作者 HaRu-LLC|オープンソース

目的

メール(PII)取得で起きがちな事故を事前に防ぐ設計レビュー。 開発着手前に、プライバシーリスクを洗い出し対策を明確にする。

トリガー語

  • 「メール取得のレビュー」
  • 「プライバシーチェック」
  • 「PII設計確認」
  • 「メールアドレスを保存する設計を確認」

入力で最初に聞くこと

#質問目的
1メール取得の目的は?(結果送付/ログイン/連絡等)必要性の判断
2保存先は?(DB/外部サービス/ローカル)保護方法の決定
3保持期間は?削除計画の策定
4削除要件は?ユーザー権利への対応

手順(7項目チェックリスト)

1. 目的の正当化

  • メール取得が本当に必要か?
  • 代替手段(匿名ID等)で代替できないか?

2. 同意(オプトイン)

  • 同意文言はわかりやすいか?
  • プライバシーポリシーへのリンクがあるか?

3. 取得最小化

  • フォーム項目は最小限か?

4. 露出経路遮断

  • URLにメールを載せていないか?
  • ログにマスクなしで出力していないか?

5. 保存と保護

  • 分離保管・暗号化されているか?
  • アクセス制御が明確か?

6. 保持と削除

  • 保持期間・削除手順が整備されているか?

7. インシデント対応

  • 漏えい時の対応手順があるか?

→ 詳細チェックリストは REFERENCE.md 参照


実装上の注意点

項目推奨
HTTPメソッドPOST使用(GETでメールを送らない)
ログ出力メールはマスク(***@***
DBスキーマPIIテーブルを分離、暗号化
URL設計クエリにメールを含めない

成果物

成果物内容
メール取得設計メモ7項目を埋めたドキュメント
実装注意点リスト開発者向けガイドライン

検証(完了条件)

  • 全チェック項目がレビュー済み
  • 懸念事項に対策が記載されている
  • 設計メモが保存されている
  • 法務レビューの要否が判断されている

免責事項

このレビューは一般的なベストプラクティスに基づくものであり、法令適合性を保証するものではありません。


参照

  • Workflow: .agent/workflows/05_meta_privacy_review_email.md