gdpr-dsgvo-expert

GDPR/DSGVO エキスパート

EU 一般データ保護規則（GDPR）およびドイツ連邦データ保護法（BDSG）への準拠に関するツールとガイダンスです。

---

目次

• ツール
  • GDPR 準拠チェッカー
  • DPIA ジェネレーター
  • データ主体の権利トラッカー
• リファレンスガイド
• ワークフロー

---

ツール

GDPR 準拠チェッカー

コードベースをスキャンし、個人データのパターンやリスクのあるコード慣行など、GDPR への準拠に関する潜在的な問題を検出します。

# Scan a project directory
python scripts/gdpr_compliance_checker.py /path/to/project

# JSON output for CI/CD integration
python scripts/gdpr_compliance_checker.py . --json --output report.json

検出対象：

• 個人データのパターン（メールアドレス、電話番号、IP アドレス）
• 特別カテゴリーのデータ（健康情報、生体情報、宗教）
• 財務データ（クレジットカード、IBAN）
• リスクのあるコードパターン：
  • 個人データのログ記録
  • 同意取得の仕組みの欠如
  • 無期限のデータ保持
  • 機密データの暗号化漏れ
  • 削除機能の無効化

出力：

• 準拠スコア（0～100）
• リスク分類（重大、高、中）
• GDPR の条文を参照した優先度付きの推奨事項

---

DPIA ジェネレーター

第 35 条の要件に従って、データ保護影響評価の文書を生成します。

# Get input template
python scripts/dpia_generator.py --template > input.json

# Generate DPIA report
python scripts/dpia_generator.py --input input.json --output dpia_report.md

機能：

• DPIA の実施要否の自動評価
• データ処理の特性に基づくリスクの特定
• 法的根拠の要件に関する文書化
• リスク軽減策の推奨
• Markdown レポートの生成

評価対象の DPIA 実施要件：

• 体系的な監視（第 35 条 3 項（c））
• 大規模な特別カテゴリーのデータ処理（第 35 条 3 項（b））
• 自動化された意思決定（第 35 条 3 項（a））
• WP29 の高リスク基準

---

データ主体の権利トラッカー

GDPR 第 15～22 条に基づくデータ主体の権利行使請求を管理します。

# Add new request
python scripts/data_subject_rights_tracker.py add \
  --type access --subject "John Doe" --email "[email protected]"

# List all requests
python scripts/data_subject_rights_tracker.py list

# Update status
python scripts/data_subject_rights_tracker.py status --id DSR-202601-0001 --update verified

# Generate compliance report
python scripts/data_subject_rights_tracker.py report --output compliance.json

# Generate response template
python scripts/data_subject_rights_tracker.py template --id DSR-202601-0001

対応する権利：

権利	条文	期限
アクセス	第 15 条	30 日
訂正	第 16 条	30 日
消去	第 17 条	30 日
処理の制限	第 18 条	30 日
データポータビリティ	第 20 条	30 日
異議申し立て	第 21 条	30 日
自動化された意思決定	第 22 条	30 日

機能：

• 期限の追跡と期限超過アラート
• 本人確認ワークフロー
• 回答テンプレートの生成
• 準拠状況のレポート

---

リファレンスガイド

GDPR 準拠ガイド

references/gdpr_compliance_guide.md

以下を網羅した包括的な実装ガイダンス：

• データ処理の法的根拠（第 6 条）
• 特別カテゴリーの要件（第 9 条）
• データ主体の権利の実装
• 説明責任の要件（第 30 条）
• 国際移転（第 V 章）
• データ侵害の通知（第 33～34 条）

ドイツ BDSG の要件

references/german_bdsg_requirements.md

ドイツ固有の要件：

• DPO の選任基準（BDSG 第 38 条 - 従業員 20 人以上）
• 従業員データの処理（BDSG 第 26 条）
• ビデオ監視の規則（BDSG 第 4 条）
• クレジットスコアリングの要件（BDSG 第 31 条）
• 州のデータ保護法（Landesdatenschutzgesetze）
• 労使協議会の共同決定権

DPIA の方法論

references/dpia_methodology.md

DPIA の段階的なプロセス：

• 実施要否の評価基準
• WP29 の高リスク指標
• リスク評価の方法論
• リスク軽減策のカテゴリー
• DPO および監督機関との協議
• テンプレートとチェックリスト

---

まず確認すること

評価を実施する前に、以下の入力内容を確認します。不足している情報や曖昧な情報が結果に影響する場合は質問してください。結果に影響しない場合は、妥当なデフォルト値を使用し、使用した値を明記してください。

• タスク： コードベースのコンプライアンススキャン、DPIA の作成、またはデータ主体の権利に関する対応（ツールとワークフローを選択します）。
• 役割と管轄区域： 管理者か処理者か、GDPR のみか、ドイツの BDSG が適用されるか（BDSG では、DPO の基準、§26 の雇用規定、§4 のビデオ規則が追加されます）。
• 処理の特性： プロファイリング、AI、または大規模な特別カテゴリーのデータなど、高リスクの処理（DPIA が必要かどうかを判断します）。

リクエストに最も重要な 2～3 項目について質問し、すべてを一度に確認する必要はありません。ユーザーがすぐに結果を求めている場合は、前提条件を冒頭に明記して結果を提示してください。

ワークフロー

ワークフロー 1：新しい処理活動の評価

Step 1: Run compliance checker on codebase
        → python scripts/gdpr_compliance_checker.py /path/to/code

Step 2: Review findings and compliance score
        → Address critical and high issues

Step 3: Determine if DPIA required
        → Check references/dpia_methodology.md threshold criteria

Step 4: If DPIA required, generate assessment
        → python scripts/dpia_generator.py --template > input.json
        → Fill in processing details
        → python scripts/dpia_generator.py --input input.json --output dpia.md

Step 5: Document in records of processing activities

ワークフロー 2：データ主体からのリクエストへの対応

Step 1: Log request in tracker
        → python scripts/data_subject_rights_tracker.py add --type [type] ...

Step 2: Verify identity (proportionate measures)
        → python scripts/data_subject_rights_tracker.py status --id [ID] --update verified

Step 3: Gather data from systems
        → python scripts/data_subject_rights_tracker.py status --id [ID] --update in_progress

Step 4: Generate response
        → python scripts/data_subject_rights_tracker.py template --id [ID]

Step 5: Send response and complete
        → python scripts/data_subject_rights_tracker.py status --id [ID] --update completed

Step 6: Monitor compliance
        → python scripts/data_subject_rights_tracker.py report

ワークフロー 3：ドイツの BDSG コンプライアンスチェック

Step 1: Determine if DPO required
        → 20+ employees processing personal data automatically
        → OR processing requires DPIA
        → OR business involves data transfer/market research

Step 2: If employees involved, review § 26 BDSG
        → Document legal basis for employee data
        → Check works council requirements

Step 3: If video surveillance, comply with § 4 BDSG
        → Install signage
        → Document necessity
        → Limit retention

Step 4: Register DPO with supervisory authority
        → See references/german_bdsg_requirements.md for authority list

---

GDPR の主要概念

法的根拠（第 6 条）

• 同意： マーケティング、ニュースレター、分析（自由意思に基づき、具体的で、十分な情報を得たうえでの同意である必要があります）
• 契約： 注文の履行、サービスの提供
• 法的義務： 税務記録、労働法
• 正当な利益： 不正防止、セキュリティ（利益衡量テストが必要です）

特別カテゴリーのデータ（第 9 条）

明示的な同意、または第 9 条第 2 項の例外規定が必要です。

• 健康データ
• 生体データ
• 人種・民族的出自
• 政治的見解
• 宗教的信条
• 労働組合への加入
• 遺伝データ
• 性的指向

データ主体の権利

すべての権利は30 日以内に履行する必要があります（複雑なリクエストの場合は 90 日まで延長できます）。

• アクセス： データのコピーと処理に関する情報を提供します
• 訂正： 不正確なデータを訂正します
• 消去： データを削除します（法的義務などの例外があります）
• 処理の制限： 問題が解決するまで処理を制限します
• データポータビリティ： 機械可読形式でデータを提供します
• 異議申立て： 正当な利益に基づく処理を停止します

ドイツの BDSG による追加事項

トピック	BDSG の条項	主な要件
DPO の基準	§ 38	従業員 20 人以上の場合、DPO が必須です
雇用	§ 26	従業員データに関する詳細な規則
ビデオ	§ 4	標識の設置と比例性
スコアリング	§ 31	説明可能なアルゴリズム

---

相互参照：CCPA/CPRA と米国のプライバシー規制の比較

EU と米国の両方の管轄区域で事業を行う場合は、GDPR への準拠を、CPRA によって改正されたカリフォルニア州消費者プライバシー法（CCPA）に合わせてください。対応が必要な主な違いは次のとおりです。

項目	GDPR	CCPA/CPRA
適用範囲	EU 居住者のデータを処理するすべての組織	収益またはデータの基準を満たす営利企業
法的根拠	6 つの適法な根拠が必要（第 6 条）	法的根拠の要件なし。オプトアウト方式
同意	デフォルトでオプトイン	オプトアウト（未成年者および機微データを除く）
データ主体の権利	アクセス、訂正、消去、データポータビリティ、異議申立て	知る権利、削除、訂正、販売・共有のオプトアウト、機微データの使用制限
データ侵害の通知	監督機関に 72 時間以内に通知（第 33 条）	消費者に「可能な限り速やかに」通知
執行	世界全体の売上高の最大 4% の制裁金を科す DPA	カリフォルニア州プライバシー保護局（CPPA）、違反 1 件あたり 2,500～7,500 ドル
DPO の要件	多くの場合に必須（第 37 条）	DPO の要件なし
子どものデータ	16 歳未満の場合、保護者の同意が必要（第 8 条）	16 歳未満は販売にオプトインが必要。13 歳未満は保護者の同意が必要

実務上の調整： より厳格な GDPR の要件をデフォルトで満たす統一的なプライバシープログラムを構築し、そのうえで CCPA/CPRA 固有の仕組み（例：「Do Not Sell or Share My Personal Information」リンク、年次指標の開示）を追加します。

関連項目： CCPA/CPRA のコンプライアンスワークフローとツールの全容については、../ccpa-cpra-specialist/SKILL.md を参照してください。

---

インフラストラクチャのプライバシー管理

Cookie Consent and Tracking

GDPR Art. 6 + ePrivacy Directive に準拠した Cookie 同意を実装します。

カテゴリー	例	同意が必要	デフォルト状態
厳密に必要	セッション、CSRF、ロードバランサー	いいえ	有効
機能	言語設定、UI 設定	はい	無効
アナリティクス	Google Analytics、Matomo、Hotjar	はい	無効
マーケティング	Facebook Pixel、Google Ads、リターゲティング	はい	無効

実装要件：

• 明示的な同意を得るまで、バナーで必須ではないすべての Cookie をブロックする必要があります
• あらかじめチェックされたボックスは有効な同意ではありません（Planet49 判決、CJEU C-673/17）
• 同意の撤回は、同意の提供と同じくらい簡単にできる必要があります
• 同意の証拠（タイムスタンプ、バージョン、選択内容）を記録します
• Cookie ポリシーに重要な変更があった場合は、再度同意を取得します

Global Privacy Control（GPC）シグナル

CCPA/CPRA の規制および新たな EU ガイダンスに従い、次のように対応します。

• Sec-GPC: 1 HTTP ヘッダーと navigator.globalPrivacyControl JavaScript API を検出します
• GPC を CCPA/CPRA における有効なオプトアウトシグナルとして扱います
• GDPR では、GPC は Art. 21 に基づく異議申し立てのシグナルとして機能する可能性があります。ケースごとに評価してください
• GPC シグナルの検出を記録し、自動的に尊重します

データのローカライゼーションと越境移転

移転メカニズム	ステータス（Schrems II 判決後）	使用する場合
EU 十分性認定	有効	十分性認定を受けた国への移転（例：日本、英国、韓国、DPF を通じた米国）
標準契約条項（SCC）	TIA の実施を条件に有効	十分性認定を受けていない国への移転におけるデフォルトのメカニズム
拘束的企業準則（BCR）	有効	多国籍企業グループ内の移転
EU-US Data Privacy Framework（DPF）	有効（2023 年 7 月以降）	DPF の認証を受けた米国企業
例外（Art. 49）	限定的な利用のみ	明示的な同意、契約上の必要性 — 体系的な移転には使用しないでください

SCC に関する移転影響評価（TIA）の要件：

1. データフローをマッピングします（どのデータを、誰に、どこへ移転するか）
2. 受領国の法的枠組みを評価します（監視法、当局によるアクセス）
3. 必要な補完的措置を評価します（暗号化、仮名化、契約上の措置）
4. 評価を文書化し、毎年見直します

---

AI 固有の GDPR 要件

自動化された意思決定（Art. 22）

Art. 22 は、法的効果または同様に重大な影響を生じさせる、もっぱら自動化された処理に基づく決定を制限しています。

要件	実装
自動化された決定の対象とならない権利	重大な結果を伴う決定に対する人による審査の仕組みを提供します
説明を受ける権利	ロジック、重要性、結果を文書化して説明します
異議を申し立てる権利	データ主体が自動化された決定に異議を申し立てられるようにします
明示的な同意または契約上の必要性	導入前に Art. 22(2) の法的根拠を確保します
適切な保護措置	人による監督と、意見を表明する権利を実装します

AI の透明性チェックリスト：

• アルゴリズムのロジックを平易な言葉で文書化する
• 重大な影響を伴う意思決定（信用、雇用、保険）には人間参加型の仕組みを実装する
• 完全に自動化された意思決定に対するオプトアウトの仕組みを提供する
• バイアステストを実施して文書化する（Art. 9 に基づく保護対象の特性）
• 監査できるよう、すべての自動化された決定を理由とともに記録する
• プライバシー通知に AI による意思決定を含める（Art. 13(2)(f)、Art. 14(2)(g))

AI トレーニングデータの要件

要件	GDPR の根拠	対応
トレーニングデータの適法な根拠	Art. 6	正当な利益（DPIA を実施）または同意
目的の限定	Art. 5(1)(b)	トレーニングの目的は、当初の収集目的と両立する必要があります
データの最小化	Art. 5(1)(c)	必要最小限のデータを使用し、合成データ／匿名化データを優先します
正確性	Art. 5(1)(d)	トレーニングデータが正確かつ最新であることを確認します
保存期間の制限	Art. 5(1)(e)	トレーニングデータセットの保存期間を定めます
特別カテゴリーのデータ	Art. 9	健康データ／生体データには明示的な同意、または Art. 9(2)(j) の研究目的の適用除外が必要です
消去権	Art. 17	トレーニングセットから個人データを削除する仕組みを導入します（または削除できない理由を記録します）
データのスクレイピング	Art. 14	公開されているデータをトレーニングに使用する場合、データ主体に通知します

---

EU AI Act との統合による DPIA 手法の強化

DPIA と AI Act の適合性評価が重複する場合

個人データを処理する AI システムには、GDPR Art. 35 の DPIA と EU AI Act の適合性評価の両方が適用されることがあります。

AI リスクレベル（EU AI Act）	GDPR の DPIA は必要か	統合評価のアプローチ
許容できない（Art. 5）	該当なし — 禁止	導入しないでください
高リスク（Annex III）	ほぼ常に必要	DPIA と適合性評価を共同で実施
限定的リスク（Art. 50）	Art. 35 の基準に基づいて評価	体系的な監視またはプロファイリングを行う場合は DPIA を実施
最小リスク	Art. 35 の基準に基づいて評価	標準的な DPIA の要否評価

AI システム向けの強化された DPIA プロセス

Step 1: AI System Classification
        → Classify under EU AI Act risk levels
        → Map to GDPR Art. 35(3) triggers

Step 2: Data Flow and Processing Analysis
        → Document training data sources and legal basis
        → Map inference data flows
        → Identify automated decision points (Art. 22)

Step 3: AI-Specific Risk Assessment
        → Bias and discrimination risk (protected groups)
        → Accuracy and reliability risk
        → Explainability and transparency gaps
        → Data quality and representativeness
        → Model drift and ongoing monitoring needs

Step 4: Fundamental Rights Impact
        → Right to non-discrimination
        → Right to privacy and data protection
        → Freedom of expression (content moderation AI)
        → Right to an effective remedy

Step 5: Combined Mitigation Measures
        → Technical: differential privacy, federated learning, model cards
        → Organizational: AI ethics board, human oversight procedures
        → Contractual: AI-specific DPA clauses with processors
        → Monitoring: continuous bias monitoring, performance drift detection

Step 6: DPO and Supervisory Authority Consultation
        → Consult DPO on combined assessment
        → Prior consultation with SA if high residual risk (Art. 36)
        → Notify national AI authority if high-risk AI system

---

プライバシー・バイ・デザインの技術的対策

データ最小化の手法

手法	説明	使用例
フィールドレベルの暗号化	保存時に特定の PII フィールドを暗号化します	データベースへの保存
トークン化	PII を逆変換できないトークンに置き換えます	決済処理、分析
データマスキング	データの一部を隠します（例：メールアドレス：j***@example.com）	UI 表示、ログ記録
集約	集約済み／統計データのみを処理します	分析、レポート
目的に応じたアクセス制御	特定の処理目的に限ってデータへのアクセスを許可します	複数目的のシステム
自動有効期限	TTL に基づいてデータを削除します	セッションデータ、一時的な処理

仮名化の実装（Recital 26, Art. 4(5)）

方法	可逆性	強度	最適な用途
HMAC ベース	キーを使って可逆	強	再識別が必要な内部分析
フォーマット保持暗号化	キーを使って可逆	強	レガシーシステムとの互換性
決定論的ハッシュ化（ソルト付き）	一方向	中	PII を使わないデータセット間の関連付け
ランダム ID のマッピング	ルックアップテーブルを使って可逆	強	研究用データセット

仮名化のためのキー管理：

• 再識別キーは仮名化データとは別に保管します
• キー素材に厳格なアクセス制御を適用します（最低 2 名での承認ルール）
• キーのローテーションスケジュールを文書化します
• すべての再識別イベントを記録します

暗号化標準

レイヤー	最低基準	推奨
保存時	AES-256	エンベロープ暗号化を使用する AES-256-GCM
転送時	TLS 1.2	TLS 1.3
データベース	透過的データ暗号化（TDE）	PII の列レベル暗号化
バックアップ	AES-256	AES-256 ＋ 本番環境とは別のキー
キー管理	ハードウェアベース（HSM/KMS）	顧客管理キー（BYOK）を使用するクラウド KMS

---

フレームワーク間のプライバシー対応表

要件	GDPR 条項	CCPA/CPRA セクション	HIPAA 規則	NIS2 条項
リスク評価	Art. 35（DPIA）	§1798.185（リスク評価規則）	§164.308(a)(1)	Art. 21(2)(a)
データ侵害の通知	Art. 33-34（監督機関へ72時間以内）	§1798.150（消費者への通知）	§164.404-408（60日以内）	Art. 23（24時間以内の初期警告）
データ最小化	Art. 5(1)(c)	§1798.100(c)（収集の制限）	§164.502(b)（必要最小限）	Art. 21(2)(e)
暗号化	Art. 32(1)(a)	明示的な規定なし（合理的なセキュリティ）	§164.312(a)(2)(iv)（対応可能な場合）	Art. 21(2)(e)
アクセス制御	Art. 32(1)(b)	明示的な規定なし（合理的なセキュリティ）	§164.312(a)(1)（アクセス制御）	Art. 21(2)(d)
インシデント対応	Art. 33-34	§1798.150	§164.308(a)(6)	Art. 21(2)(b)
サプライチェーンセキュリティ	Art. 28（処理者との契約）	§1798.140(ag)（サービスプロバイダーとの契約）	§164.308(b)（BAA）	Art. 21(2)(d)
ガバナンス／説明責任	Art. 5(2), Art. 24	§1798.185（監査規則）	§164.308(a)(1)	Art. 20（ガバナンス）
削除／消去の権利	Art. 17	§1798.105	限定的（保持規則）	該当なし
データポータビリティ	Art. 20	§1798.130(a)(2)	該当なし	該当なし

相互参照： ISO 27001 のセキュリティ管理策については ../information-security-manager-iso27001/SKILL.md を、MDR に基づく医療機器データの保護については ../mdr-745-specialist/SKILL.md を参照してください。

---

フレームワーク間のプライバシー統合

GDPR と CCPA/CPRA の比較

項目	GDPR	CCPA/CPRA
適用範囲	EU 居住者のデータを処理するすべての組織	売上高が2,500万ドル以上、消費者が10万人以上、または個人情報の販売による売上が50％以上
法的根拠	6つの法的根拠が必要（Art. 6）	オプトアウト方式（収集に法的根拠は不要）
同意	オプトインが必要	販売／共有についてオプトアウト
削除権	Art. 17	§1798.105
データポータビリティ	Art. 20	§1798.130
罰則	最大2,000万ユーロまたは全世界売上高の4％	違反1件につき2,500～7,500ドル
DPO の設置義務	あり（多くの場合）	なし
DPIA の実施義務	あり（高リスクの処理）	リスク評価（CPRA）

AI に関する GDPR 固有の要件

• 自動化された意思決定（Art. 22）： 法的効果または重大な影響をもたらす、自動処理のみに基づく決定の対象とならない権利があります
• AI のトレーニングデータ： 正当な利益または同意が必要です。モデルのトレーニングには目的制限が適用されます
• プロファイリング： 重大な影響をもたらす自動プロファイリングには明示的な同意が必要です
• EU AI Act との統合： 個人データを処理する高リスク AI システムには、GDPR Art. 35 に基づく DPIA が必要です
• 相互参照： AI 固有のコンプライアンスについては eu-ai-act-specialist を参照してください

インフラストラクチャのプライバシー管理策

• Cookie の同意： TCF 2.2 に準拠した同意管理プラットフォーム（CMP）
• グローバルプライバシーコントロール（GPC）： GPC のブラウザーシグナルを尊重する必要があります（CCPA の要件でもあります）
• データのローカライゼーション： EU のデータレジデンシー要件、Schrems II の十分性認定
• 越境移転： 標準契約条項（SCC）、十分性認定、拘束的企業準則
• プライバシー・バイ・デザインの管理策： データ最小化、仮名化、保存時／転送時の暗号化、アクセスログの記録

フレームワーク間の対応表

管理策	GDPR	CCPA	HIPAA	NIS2
プライバシー通知	Art. 13-14	§1798.100	プライバシー慣行	—
データ主体の権利	Art. 15-22	§1798.100-125	アクセス／訂正	—
データ侵害の通知	Art. 33-34	§1798.150	§164.404-408	Art. 23
DPO／プライバシー責任者	Art. 37-39	—	プライバシー責任者	—
リスク評価	Art. 35（DPIA）	リスク評価	§164.308(a)(1)	Art. 21
暗号化	Art. 32	合理的なセキュリティ	§164.312(a)(2)(iv)	Art. 21.2.h
トレーニング	Art. 39.1.b	—	§164.308(a)(5)	Art. 21.2.g

---

トラブルシューティング

問題	考えられる原因	解決策
コンプライアンスチェッカーが、特別カテゴリーのデータに関する重大な問題を報告する	明示的な同意または Art. 9(2) の例外がないまま、コードが健康、バイオメトリック、宗教に関するデータを処理している	特別カテゴリーのデータ処理をすべて特定します。明示的な同意を取得するか、適用される Art. 9(2) の例外を文書化します。機密フィールドにはフィールドレベルの暗号化を実装します
DPIA ジェネレーターが評価の実施が必要と判断したが、組織に DPIA のプロセスがない	処理が Art. 35(3) の基準（体系的な監視、大規模な特別カテゴリーのデータ処理、自動化された意思決定）に該当する	references/dpia_methodology.md の DPIA 方法論に従います。dpia_generator.py --template でテンプレートを生成します。処理を進める前に DPO に相談します。残存リスクが高い場合は、監督機関との事前協議を検討します（Art. 36）
データ主体の権利行使請求への対応が、繰り返し 30 日の期限を超過する	追跡システムを使わずに手作業で対応している、データの所在が不明確、または本人確認の要件が複雑	data_subject_rights_tracker.py を導入して期限の監視を自動化します。データインベントリを使用して、すべての個人データの所在を把握します。本人確認を、目的に見合った方法に簡素化します
国境を越えたデータ移転の仕組みが無効とされた、または不確実である	廃止された仕組みに依存している、または SCC に関する移転影響評価が未完了	現行の十分性認定を確認します（英国、日本、韓国、DPF 経由の米国）。SCC の場合は、Schrems II の要件に従って移転影響評価を完了します。補完的措置（暗号化、仮名化）を文書化します
Cookie 同意バナーが非準拠と判定される	あらかじめ選択されたチェックボックス、アクセスを妨げる Cookie ウォール、または同意ボタンより見つけにくい拒否ボタン	TCF 2.2 に準拠した CMP を実装します。明示的な同意が得られるまで、必須ではない Cookie をすべてブロックします。Planet49 判決（CJEU C-673/17）に従い、拒否ボタンを同意ボタンと同じ程度に目立たせます。同意の証明を記録します
GDPR コンプライアンスチェッカーが、アプリケーションログ内の個人データを検出する	アプリケーションログに、メールアドレス、IP アドレス、またはユーザー識別子が含まれている	保存前に個人データをマスキングまたは仮名化するログサニタイズを実装します。PII フィールドを除外するよう、ロギングフレームワークを設定します。目的に沿ったログ保持期間の上限を設定します
個人データを処理する AI システムに Art. 22 の保護措置がない	自動化された意思決定が、人による確認の仕組みなしに法的または重大な影響をもたらす	重大な影響を伴う意思決定には、人間が介在する仕組みを実装します。説明を求める権利と異議を申し立てる権利を提供します。アルゴリズムのロジックを平易な言葉で文書化します。Art. 13(2)(f) に従い、プライバシー通知に AI による意思決定を含めます

---

成功基準

• コードベースのスキャンで80以上のコンプライアンススコアを達成 -- 重大な個人データの露出に関する問題がなく、高リスクのパターンすべてに対処して文書化されていることを示します
• すべてのデータ主体の権利に関する請求を30日以内に処理 -- data_subject_rights_tracker.py で追跡し、本人確認を完了し、回答テンプレートを生成し、期限超過の請求がゼロであることをコンプライアンスレポートで確認します
• すべての高リスクな処理活動についてDPIAを完了 -- 第35条第3項の適用条件、WP29の基準、リスク軽減策、DPOへの相談を網羅します。必要な場合は、監督機関への事前相談を文書化します
• 処理活動記録（第30条）を維持し、最新の状態に保つ -- すべての処理活動について、目的、法的根拠、データの種類、受領者、保存期間、移転メカニズムを網羅します
• 越境移転メカニズムを検証 -- すべての国際的なデータフローについて、十分性認定、TIAを伴うSCC、またはBCRを整備し、毎年見直します
• Cookieの同意実装が準拠している -- 明示的な同意を得るまで必須ではないCookieをブロックし、拒否を承諾と同じくらい簡単に行えるようにし、同意の証明をタイムスタンプとバージョンとともに記録し、GPC信号を尊重します
• 必要な場合にDPOを任命し、登録 -- 個人データを自動処理する従業員が20人以上の場合に適用されるドイツBDSG第38条の基準を含み、監督機関への通知を行います

---

対象範囲と制限事項

対象範囲：

• 個人データのパターンやリスクの高い処理方法を検出するためのコードベースのスキャン
• 第35条の要件に従い、基準評価とリスク軽減策を含むDPIAの作成
• データ主体の権利に関する請求（第15～22条）の期限監視と回答テンプレートを含む追跡
• ドイツBDSG固有の要件（DPOの基準、従業員データ、ビデオ監視、信用スコアリング）
• 越境移転メカニズムの評価（十分性認定、SCC、BCR、DPF）
• AI固有のGDPR要件（第22条の自動意思決定、トレーニングデータのガバナンス、プロファイリング）
• フレームワーク間のプライバシー対応付け（GDPR、CCPA/CPRA、HIPAA、NIS2）

対象外：

• 特定の法的根拠の選択や正当な利益の衡量テストに関する法的助言 -- DPOおよび法律顧問に相談してください
• データ侵害報告（第33～34条）に関する監督機関への通知や対応
• Cookie同意管理プラットフォームまたは同意管理コードの実装
• EU域外の組織におけるGDPR代理人の任命手続き（第27条）
• 拘束的企業準則（BCR）の申請または承認プロセス
• 一般的なガイダンスの範囲を超える、ドイツの州レベルのデータ保護法（Landesdatenschutzgesetze）

重要事項：

• GDPRの執行による罰金は2025年に23億ユーロに達し、前年比38％増加しました。医療分野の違反が急増し、平均制裁金は20万3,000ユーロとなりました
• EU AI Actにより、個人データを処理するAIシステムには二重の義務が課されます。DPIA（GDPR第35条）と適合性評価（AI Act）の両方が同時に適用される場合があります
• 同意インターフェースにおけるダークパターンへの執行監視が強化されています。規制当局はCookieウォール、操作的なUI、目立たない拒否オプションに対して制裁を科しています

---

統合ポイント

スキル	統合内容	使用する場面
ccpa-cpra-privacy-expert	GDPR と CCPA/CPRA の両方を対象とする統合プライバシープログラム。フレームワーク間のマッピングにも対応します	EU 居住者とカリフォルニア州の消費者の両方のデータを組織が処理する場合
eu-ai-act-specialist	個人データを処理する高リスク AI システム向けに、DPIA と AI Act 適合性評価を組み合わせます	AI システムが GDPR 第 35 条の DPIA と EU AI Act の高リスク分類の両方に該当する場合
information-security-manager-iso27001	ISO 27001 のセキュリティ管理策により、GDPR 第 32 条の処理のセキュリティ要件をサポートします	個人データ保護のための技術的・組織的措置を実施する場合
infrastructure-compliance-auditor	技術的なプライバシー管理策（暗号化、アクセス制御、ログ記録、データマスキング）を検証します	GDPR のプライバシー・バイ・デザイン要件をサポートするインフラストラクチャを評価する場合
dora-compliance-expert	DORA は、個人データを処理する金融セクターの ICT システムに関して GDPR を補完します	金融機関が DORA の ICT セキュリティと GDPR のデータ保護要件を整合させる必要がある場合

---

ツールリファレンス

gdpr_compliance_checker.py

コードベースをスキャンし、個人データのパターンやリスクのあるコード慣行など、GDPR 違反の可能性がある問題を検出します。

フラグ	必須	説明
<project_dir>	はい	スキャンするプロジェクトディレクトリのパス
--json	いいえ	CI/CD 統合用に結果を JSON 形式で出力します
--output <file>	いいえ	レポートを指定したファイルパスにエクスポートします

検出対象： メールアドレス、電話番号、IP アドレス、クレジットカード、IBAN、ドイツの ID パターン、特別なカテゴリのデータ（健康、生体情報、宗教）、リスクのあるコードパターン（個人情報のログ記録、同意の欠如、無期限の保持、機密データの非暗号化、削除の無効化）。出力： コンプライアンススコア（0～100）、リスク分類（重大／高／中）、GDPR の条文を参照した優先度付きの推奨事項。

dpia_generator.py

第 35 条の要件に準拠したデータ保護影響評価の文書を生成します。

フラグ	必須	説明
--template	いいえ	空の DPIA 入力テンプレートを標準出力に生成します
--input <file>	はい（ただし、--template または --interactive を指定した場合を除く）	処理活動の説明を記載した JSON ファイルのパス
--output <file>	いいえ	DPIA レポートを指定したファイルパスにエクスポートします（Markdown 形式）
--interactive	いいえ	ガイド付きの DPIA 作成用に対話モードを起動します

機能： 第 35 条第 3 項のトリガーおよび WP29 の基準に基づく DPIA 閾値の自動評価、処理の特性に基づくリスクの特定、法的根拠の文書化、リスク軽減の推奨事項、Markdown レポートの生成。

data_subject_rights_tracker.py

GDPR 第 15～22 条に基づくデータ主体の権利請求を管理し、期限を追跡して回答テンプレートを提供します。

サブコマンド	説明
add	新しい請求を追加します（--type、--subject、--email が必須）
list	追跡中のすべての請求を一覧表示します
status	請求のステータスを表示または更新します（--id が必須、ステータスの変更には --update を指定）
report	コンプライアンスレポートを生成します（ファイルにエクスポートするには --output を指定）
template	特定の請求に対する回答テンプレートを生成します（--id が必須）

フラグ	説明
--type <right>	権利の種類：access、rectification、erasure、restriction、portability、objection、automated
--subject <name>	データ主体の氏名
--email <email>	データ主体のメールアドレス
--id <request_id>	請求識別子（例：DSR-202601-0001）
--update <status>	新しいステータス：received、verified、in_progress、completed、denied、extended
--output <file>	レポートまたはテンプレートを指定したファイルパスにエクスポートします

機能： 期限超過アラート付きの30日間の期限追跡、本人確認ワークフロー、権利の種類ごとの回答テンプレート生成、指標を含むコンプライアンスレポートを提供します。