プライバシー・バイ・デザイン（Privacy by Design & Default）

Privacy by Design & Default（DPbDD）とは

UK GDPR Article 25 が義務化した要件：

「コントローラーは、処理の設計段階および処理時において、データ保護原則を効果的に実装するために設計された適切な技術的・組織的措置を実装しなければならない」

データ最小化のアーキテクチャ的実現：最小化を後付けするのではなく、システム設計段階から組み込む。

なぜ「デザイン」段階に組み込むのか

後付けのアプローチ（問題あり）:
  システムを構築 → 動かしてみる → 問題が見つかる → 修正
    ↑ データが既に大量に蓄積されていたら修正コストが爆発する

設計段階からのアプローチ（Article 25 が求めるもの）:
  要件定義で「何のデータが必要か」を問う
    → データモデルを最小限に設計
    → 不要なフィールドは作らない
    → デフォルト値をプライバシー保護側に設定

Cavoukian の Privacy by Design 7原則

Ann Cavoukian（元オンタリオ州プライバシーコミッショナー）が提唱した基盤理論。 Article 25 の思想的ルーツ：

1. Proactive not Reactive（事後対応ではなく事前設計）
   プライバシー侵害が起きてから対処するのではなく、起きないよう設計する

2. Privacy as the Default（デフォルトでプライバシー保護）
   ユーザーが何もしなければ最も保護された状態になっている
   → 公開設定を「全員に公開」にしない

3. Privacy Embedded into Design（設計に組み込む）
   プライバシー保護は機能のアドオンではなく、コアアーキテクチャの一部

4. Full Functionality（プライバシーと機能性は両立する）
   「プライバシー保護 vs 機能性」はゼロサムでない。両方実現できる

5. End-to-End Security（ライフサイクル全体での保護）
   収集から削除まで、データの全ライフサイクルを通じた保護

6. Visibility and Transparency（可視性と透明性）
   何をしているかをユーザーと監督機関に対して説明可能にする

7. Respect for User Privacy（ユーザープライバシーの尊重）
   個人を尊重する設計。同意メカニズムを形骸化させない

Privacy by Default の具体的意味

「デフォルト設定は最もプライバシー保護的なもの」：

SNS の例:
  ✗ デフォルト「全員に公開」→ ユーザーが意図せず公開状態
  ✓ デフォルト「自分だけ」→ ユーザーが意識的に公開範囲を広げる

アプリの権限要求:
  ✗ インストール時に「連絡先・位置情報・カメラ」をまとめて要求
  ✓ 実際に機能が必要になった時点で個別に要求

データ収集フォーム:
  ✗ 任意項目を「必須」と偽って収集
  ✓ 本当に必要な項目のみ必須。任意項目は明示的に任意

技術的措置 vs 組織的措置

Article 25 は「技術的かつ組織的措置」を求めている：

技術的措置の例:
  - データ最小化: スキーマ設計時に不要フィールドを排除
  - 仮名化: 個人識別子を内部 ID に置換した上で分析
  - 暗号化: 保存時・転送時の暗号化
  - アクセス制御: 最小権限の原則（Least Privilege）
  - 自動削除: 保持期間超過時の自動 purge 処理

組織的措置の例:
  - プライバシー影響評価（DPIA）プロセスの導入
  - 開発者向けプライバシー研修
  - データ分類ポリシーの策定
  - 新機能開発時のプライバシーレビュー（Privacy Review Gate）
  - DPO（データ保護責任者）との協議プロセス

開発ライフサイクルへの組み込み方

要件定義フェーズ:
  □ 収集するデータ項目の必要性を問う
  □ 目的とデータ項目の対応を文書化

設計フェーズ:
  □ デフォルト値を最小収集・最大保護に設定
  □ 仮名化・暗号化の実装方針を決定
  □ 保持期間と削除処理を設計に含める

実装フェーズ:
  □ 不要なログ出力（個人データの混入）を排除
  □ テストデータに本番個人データを使わない

リリース前:
  □ プライバシーレビュー / DPIA の実施
  □ デフォルト設定の検証

運用フェーズ:
  □ 定期的なデータ棚卸し
  □ 保持期間の自動実行確認