privacy-by-design

プライバシー・バイ・デザイン

概要

ソフトウェアアーキテクチャに、後付けではなく最初からプライバシー保護を組み込みます。このスキルでは、データベース、API、ユーザーフローの設計において、プライバシー・バイ・デザインの原則（GDPR 第 25 条、Cavoukian のフレームワーク）を適用します。実際のユーザーのデータを保護し、信頼を築きます。

このスキルを使用する場面

• 個人データ（氏名、メールアドレス、位置情報、設定）を収集するアプリを構築するとき
• データベースのスキーマ、API、認証フローを設計するとき
• ユーザーがフォーム、ユーザーアカウント、分析、サードパーティとの連携について言及したとき
• 本番環境にデプロイするとき。リリース前にプライバシー管理を確認してください

法的枠組み

GDPR（EU） — 主な参照先です。第 25 条は「設計段階およびデフォルトでのデータ保護」を義務付けています。EU のユーザーに適用され、多くの場合、世界的にも採用されています。

CCPA（カリフォルニア州） — 知る権利、削除する権利、販売をオプトアウトする権利があります。最小化、開示、ユーザーによる管理を認めるという類似の原則があります。

LGPD（ブラジル） — GDPR に準拠しています。目的の限定、必要性、透明性を定めています。ブラジルのユーザーに適用されます。

適用される法域と処理目的をそれぞれ個別に整理してください。ある枠組みへの準拠によって、別の枠組みへの準拠が証明されるわけではありません。

---

基本原則

1. データの最小化

厳密に必要なものだけを収集します。すべての項目について、文書化された正当な理由が必要です。「後で必要になるかもしれない」という理由で収集するのは避けてください。

2. 目的の限定

各データ項目の目的を記録します。すべての処理目的について、適法性の根拠と目的との適合性を特定し、文書化してください。同意は根拠の一つですが、唯一の根拠ではありません。

3. 保存期間の限定

保存期間を定めます。保存期間が終了したら、自動的に削除または匿名化する仕組みを実装してください。デフォルトで「永久に」データを保持してはいけません。

4. デフォルトでのプライバシー保護

任意のデータ収集はオプトアウトではなくオプトインにします。分析やマーケティングなど、機微な設定はデフォルトでオフにします。同意のチェックボックスをあらかじめ選択済みにしてはいけません。

5. エンドツーエンドのセキュリティ

保存中および転送中のデータを暗号化します。RBAC を使用します。監査に備え、機微なデータへのアクセスを記録します。

6. 透明性

収集するデータとその理由を文書化します。プライバシーポリシーは明確にします。ユーザーが簡単にデータへアクセスし、削除できるようにします。

---

ユーザーの権利（GDPR）

以下の権利を初日から実現できるようにしてください。

権利	実装するもの
アクセス	すべてのユーザーデータを返すエンドポイントまたはフロー
訂正	データを更新・訂正できる機能
消去	検証可能な消去ワークフロー、適用される法的例外、期限を定めたバックアップの有効期限と復元の抑止
データポータビリティ	機械可読形式（JSON、CSV）でのデータエクスポート

---

詳細：重要な理由

データの最小化 — データが少なければ、侵害時の影響やストレージコストが軽減され、コンプライアンスも簡素化されます。項目一つひとつがリスクになります。

目的の限定 — GDPR に基づき、再利用の適法性の根拠と目的との適合性を評価します。すべての処理活動で同意が必須というわけではありません。スキーマまたはメタデータに目的を記録してください。

保存期間 — 無期限の保存はリスクを高め、GDPR に違反します。データの種類ごとに retention_days を定め、クリーンアップを自動化してください。

ログ記録 — ログから個人識別情報（PII）が漏れることはよくあります。メールアドレス、ID、トークンをマスキングしてください。許可リストを用いた構造化ログを使用します。

サードパーティ — 分析、クラッシュレポート、広告などの SDK は、データを外部へ送信する可能性があります。依存関係を監査し、任意のトラッキングを読み込む前に、適用される同意および適法性の根拠に関する要件を確認してください。

---

コード例

JavaScript/Node — 最小限のユーザーモデル

// BAD: Collecting everything "just in case"
const user = { email, name, phone, address, birthdate, ipAddress, userAgent, ... };

// GOOD: Minimal, documented purpose
const user = {
  email,        // purpose: authentication
  displayName,  // purpose: UI display
  createdAt,    // purpose: account age
};

JavaScript — トラッキング開始前の同意

// BAD: Track first, ask later
analytics.track(userId, event);

// GOOD: Check consent first
if (userConsent.analytics) {
  analytics.track(userId, event);
}

Python — 安全なログ記録

# BAD: Logging PII in plain text
logger.info(f"User {user.email} logged in from {request.remote_addr}")

# GOOD: Redact or hash identifiers
logger.info(f"User {hash_user_id(user.id)} logged in")
# Or: logger.info("User login", extra={"user_id_hash": hash_id(user.id)})

SQL — 目的と保存期間を含むスキーマ

-- GOOD: Document purpose and retention in schema
CREATE TABLE users (
  id UUID PRIMARY KEY,
  email VARCHAR(255) NOT NULL,  -- purpose: auth, retention: account lifetime
  display_name VARCHAR(100),   -- purpose: UI, retention: account lifetime
  created_at TIMESTAMPTZ,      -- purpose: audit, retention: 7 years
  last_login_at TIMESTAMPTZ    -- purpose: security, retention: 90 days
);

-- Add retention policy (PostgreSQL example)
-- Schedule job to anonymize/delete last_login_at after 90 days

API — 必要なフィールドのみを返す

# BAD: Returning full user object
return jsonify(user)  # May include internal fields, hashed passwords

# GOOD: Explicit allowlist
return jsonify({
    "id": user.id,
    "email": user.email,
    "displayName": user.display_name,
})

---

よくある落とし穴

落とし穴	解決策
ログにメールアドレス、IPアドレス、トークンが含まれている	個人情報をマスキングします。ハッシュ化した ID または構造化ログを使用します
エラーメッセージからデータが漏れる	クライアントには汎用的なエラーを返し、詳細はサーバー側でログに記録します
同意を得る前にサードパーティ製 SDK が読み込まれる	同意を得てから分析ツールや広告を読み込みます。同意管理を使用します
データ削除の手順がない	初日からアカウント削除とデータ消去を設計します
バックアップにデータが永久に残る	保持ポリシーにバックアップを含め、バックアップを暗号化します
同意なしで Cookie を使用する	同意バナーを使用し、該当する場合は Do Not Track を尊重します

---

サードパーティの監査

ユーザーデータを扱う依存関係を追加する前に、次の点を確認します。

• どのようなデータを収集または受信しますか？
• データはどこ（サーバー、国）に送信されますか？
• ユーザーの同意を得る前と後のどちらで読み込まれますか？
• ユーザーがオプトアウトした場合、無効にできますか？
• そのプライバシーポリシーは自社のポリシーと整合していますか？

---

実装チェックリスト

ユーザーデータを扱う機能を構築する際は、次の点を確認します。

• このデータは必要ですか？より少ないデータで目的を達成できますか？
• この用途について明示的な同意を得ていますか？
• 保存時と転送時に暗号化されていますか？
• 保持・削除ポリシーがありますか？
• ユーザーは自分のデータをエクスポートまたは削除できますか？
• サードパーティのサービスは開示され、同意を得ていますか？
• ログに個人情報が含まれていませんか？
• 保持ポリシーにバックアップが含まれていますか？

---

ベストプラクティス

• ✅ 新しいデータ項目を追加するたびに「これは必要か？」と確認します
• ✅ 初日から削除とエクスポートの手順を設計します
• ✅ 可能な場合は、機微な識別子にハッシュ化またはトークン化を使用します
• ✅ スキーマまたはメタデータに目的と保持期間を記録します
• ❌ パスワード、トークン、個人情報を平文でログに記録しないでください
• ❌ 文書化された適法な根拠、適切な保護措置、適用される同意なしに個人データを共有しないでください
• ❌ 「プライバシー対応は後で追加すればよい」と考えないでください。そうなることはほとんどありません
• ❌ スタックトレースや内部エラーをクライアントに公開しないでください

---

使用する場面

このスキルは、個人データを収集、保存、処理するソフトウェアを構築する際に適用できます。設計および実装の段階で、事前に適用してください。

制限事項

• タスクが上記の範囲に明確に当てはまる場合に限り、このスキルを使用してください。
• 出力を、環境固有の検証、テスト、専門家によるレビューの代わりとして扱わないでください。
• 必要な入力、権限、安全上の境界、成功基準が不足している場合は、作業を中断して確認を求めてください。

ハッシュ化やトークン化は通常、識別子を仮名化するものであり、自動的にデータを匿名化したり、プライバシー上の義務をなくしたりするものではありません。再識別のリスクを評価し、鍵や対応表へのアクセスを制限してください。保持と消去には、目的に応じた規則、適法な例外、テスト済みの復元・削除処理が必要です。これは設計に関する指針であり、コンプライアンス認証ではありません。EDPB の適法な根拠およびICO の仮名化を参照してください。