Back to skills
extension
Category: Development & EngineeringNo API key required

privacy-email-review

Conduct a privacy design review for features that involve obtaining emails. Use this before implementing the feature to save email addresses, during the design confirmation of PII acquisition.

personAuthor: jakexiaohubgithub

目的

メール(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