dpia-assessment

⚠️ 実験的 — このスキルは、教育および情報提供のみを目的として提供されています。法的助言を構成するものではありません。利用に関するすべての責任はユーザーにあります。出力に基づいて行動する前に、資格を有する法律専門家に相談してください。

DPIA 評価

GDPR 第35条のデータ保護影響評価ツールです。DPIA の要否を評価し、緩和策の追跡を含むリスク登録簿を管理して、監督機関の期待に沿った文書を作成します。

---

目次

• ツール
  • DPIA 閾値チェッカー
  • DPIA リスク登録簿
• 参照ガイド
• ワークフロー
• 法的な重要ポイント
• 出力形式
• トラブルシューティング
• 成功基準
• 範囲と制限
• アンチパターン
• ツールリファレンス

---

最初に確認すること

評価を始める前に、以下の情報を確認してください。不明または曖昧な項目があれば、推測せずに質問してください。

• 処理活動の説明 — 目的、データの種類、自動化のレベル、規模 — 第35条第3項の該当条件と EDPB 基準のスコアリング（評価全体の判定）に影響します
• 特別カテゴリーのデータと規模 — 第35条第3項(b)の該当条件、第9条の累積要件、大規模処理に関する4要素テストを左右します
• 管轄区域 — 適用される各国のブラックリスト（DE/FR/IE/BE/NL/IT/PL）を確認します。最も厳格な要件が適用されます
• AI システムが関与するかどうか — EDPB 意見書 28/2024 に基づく二段階（学習／推論）の分析と、別個の FRIA との区別が必要になります

停止ルール：出力に最も大きく影響する項目を2～3個だけ質問してください。ユーザーが「とにかく草案を作成して」と言った場合は、作業を進め、評価の冒頭に前提を列挙してください。

ツール

DPIA 閾値チェッカー

処理活動の説明に基づいて DPIA が必要かどうかを評価します。第35条第3項の必須条件と EDPB の9つの基準を確認します。

# Check a processing activity (interactive prompts)
python scripts/dpia_threshold_checker.py --activity "AI-based credit scoring using financial and behavioral data of retail banking customers across EU"

# Check from JSON description
python scripts/dpia_threshold_checker.py --input processing.json

# JSON output
python scripts/dpia_threshold_checker.py --activity "Employee monitoring via CCTV in workplace" --json

# Generate blank input template
python scripts/dpia_threshold_checker.py --template > processing.json

確認内容：

• 第35条第3項(a)：法的または重大な影響を伴う自動意思決定
• 第35条第3項(b)：特別カテゴリーのデータ（第9条）または犯罪データ（第10条）の大規模な処理
• 第35条第3項(c)：一般にアクセス可能な区域の大規模かつ体系的な監視
• WP 248 rev.01 の EDPB 9基準と、2基準に基づく推定ルール

出力：

• 判定：必須／推奨／不要
• 第35条第3項の該当条件
• 根拠を含む EDPB 基準のスコア
• 2基準に基づく推定の分析

---

DPIA リスク登録簿

DPIA のリスク登録簿を JSON 形式で管理します。リスクの追加、緩和策の適用、残余リスクの算出を行います。

# Initialize a new risk register
python scripts/dpia_risk_register.py init --output dpia_risks.json

# Add a risk
python scripts/dpia_risk_register.py add --register dpia_risks.json \
  --description "Unauthorized access to profiling data" \
  --rights-category "right-to-privacy" \
  --likelihood 4 --severity 3

# Add mitigation to a risk
python scripts/dpia_risk_register.py mitigate --register dpia_risks.json \
  --risk-id 1 --measure "Implement role-based access control" \
  --likelihood-reduction 2 --severity-reduction 1

# View risk register table
python scripts/dpia_risk_register.py view --register dpia_risks.json

# Generate residual risk summary
python scripts/dpia_risk_register.py summary --register dpia_risks.json --json

# Check Art. 36 consultation threshold
python scripts/dpia_risk_register.py art36-check --register dpia_risks.json

権利カテゴリー： プライバシーの権利、差別されない権利、表現の自由、情報に対する権利、自動化された決定の対象とならない権利、身体の安全に対する権利

---

参照ガイド

EDPB 基準

references/edpb_criteria.md

EDPB の9基準に関する評価フレームワークの全容：

• 各基準の説明、指標、スコアリングの指針
• 第35条第3項の必須条件
• 2基準に基づく推定ルール（WP 248 rev.01）
• 複数の管轄区域にまたがる DPIA 分析
• 各国のブラックリスト／ホワイトリストの概要（DE、FR、IE、BE、NL、IT、PL）

リスクスコアリングの方法

references/risk_scoring_methodology.md

データ主体の視点に基づく DPIA リスクのスコアリング：

• 可能性と重大度の尺度（1～5）
• 前文75に基づく権利カテゴリー
• リスクレベルのしきい値（低／中／高／非常に高い）
• 緩和策の有効性のスコアリング
• 残余リスクの算出
• 第36条の協議要件
• リスクカタログ：よくある DPIA リスク20件以上

---

ワークフロー

ワークフロー1：DPIA の完全評価

Step 1: Threshold check — determine if DPIA required
        → python scripts/dpia_threshold_checker.py --activity "description"

Step 2: If Required or Recommended, describe the processing
        → Document purpose, legal basis, data categories, recipients, retention

Step 3: Assess necessity and proportionality
        → Confirm lawful basis (Art. 6, cumulative with Art. 9 if special categories)
        → Verify purpose limitation, data minimization, storage limitation

Step 4: Identify risks from data subject perspective
        → python scripts/dpia_risk_register.py init --output dpia_risks.json
        → Add risks using references/risk_scoring_methodology.md catalog

Step 5: Apply mitigations and calculate residual risk
        → python scripts/dpia_risk_register.py mitigate --register dpia_risks.json ...

Step 6: Check Art. 36 consultation requirement
        → python scripts/dpia_risk_register.py art36-check --register dpia_risks.json

Step 7: Document and review
        → python scripts/dpia_risk_register.py summary --register dpia_risks.json

ワークフロー2：簡易しきい値評価

Step 1: Describe the processing activity
        → python scripts/dpia_threshold_checker.py --template > processing.json
        → Fill in processing details

Step 2: Run threshold check
        → python scripts/dpia_threshold_checker.py --input processing.json --json

Step 3: Review verdict and reasoning
        → Required: proceed to full DPIA (Workflow 1)
        → Recommended: proceed unless strong justification to skip (document)
        → Not Required: document the assessment and rationale

ワークフロー3：AI システムの DPIA

Step 1: Classify AI system (EU AI Act risk level if applicable)
        → Map to DPIA triggers (automated decision-making, profiling, scoring)

Step 2: Run threshold check with AI-specific indicators
        → python scripts/dpia_threshold_checker.py --activity "AI system description"

Step 3: Dual-phase risk analysis (EDPB Opinion 28/2024)
        → Phase 1: Training data risks (collection, bias, consent)
        → Phase 2: Inference risks (decisions, profiling, transparency)

Step 4: Assess from data subject perspective
        → Add risks covering both training and inference phases
        → Include algorithmic bias, lack of transparency, unfair outcomes

Step 5: Apply mitigations specific to AI
        → Explainability measures, human oversight, bias testing
        → Document FRIA distinction per EU AI Act Art. 27 if applicable

---

法的な精度を高めるポイント

専門家レベルのDPIA業務を特徴づける、法的な精度を高める12のポイントです。

#	ポイント	詳細
1	第35条第3項の絶対的なトリガー	他の分析結果にかかわらずDPIAが必須となるトリガーが3つあります。（a）法的効果を伴う自動化された意思決定、（b）大規模な特別カテゴリーのデータまたは犯罪データの処理、（c）公共の場所の体系的な監視
2	2つの基準による推定	EDPBの9つの基準のうち2つ以上に該当する場合、DPIAが必要と推定されます（WP 248 rev.01）。文書化された正当な理由がある場合に限り、この推定を覆すことができます
3	第9条と第6条の累積的な適用	特別カテゴリーのデータを処理するには、第6条に基づく適法な根拠と、第9条第2項に基づく例外の両方が必要です。いずれか一方だけでは不十分です
4	大規模処理に関する4要素テスト	（a）データ主体の数、（b）データの量、（c）地理的範囲、（d）期間・継続性を評価します。固定された数値基準はありません
5	各国のブラックリストは追加的に適用	監督機関が公表する、DPIAが必要な処理業務のリストは、第35条第3項およびEDPBの基準に追加されるものであり、それらに置き換わるものではありません
6	複数の法域にまたがる場合の確認	処理が複数の加盟国にまたがる場合は、各監督機関のブラックリストを確認します。最も厳格なリストが適用されます
7	処理開始前の義務	DPIAは処理の開始前に完了しなければなりません（第35条第1項）。事後に実施したDPIAでは要件を満たしません
8	AIに関する二段階の分析	EDPB意見書28/2024：AIシステムでは、学習段階と推論・展開段階について、それぞれ別個のリスク分析が必要です
9	第36条の逐次的な適用	監督機関への事前協議（第36条）が必要となるのは、DPIA完了後も残存リスクが高い場合に限られます。DPIAを省略することはできません
10	仮名化に関する注意点	EDPBガイドライン01/2025：仮名化によってリスクは軽減されますが、DPIAの要件がなくなるわけではありません。データは引き続き個人データです
11	データ主体の視点	あらゆるリスクは、管理者の事業上の視点ではなく、データ主体の視点から評価しなければなりません（前文75）
12	AI法におけるFRIAとの区別	EU AI Act第27条は、ハイリスクAIに対して基本権影響評価（FRIA）を義務付けています。FRIAはGDPRのDPIAとは別の評価であり、両方が必要となる場合があります

---

出力形式

閾値判定

VERDICT: DPIA REQUIRED
Reason: Art. 35(3)(a) trigger matched (automated decision-making with legal effect)
        + 4 of 9 EDPB criteria met (two-criterion presumption applies)
Matched triggers: automated_decision_making, evaluation_scoring, sensitive_data, large_scale

リスク登録簿テーブル

ID	説明	権利のカテゴリー	L	S	スコア	レベル	緩和策	残存L	残存S	残存スコア	残存レベル
1	無許可のプロファイリング	プライバシー権	4	3	12	高	RBAC + 暗号化	2	2	4	低
2	差別的な結果	差別の禁止	3	4	12	高	バイアステスト + 人によるレビュー	2	3	6	中

残存リスクの概要

Total risks: 8
Mitigated: 6 (75%)
Residual risk distribution:
  Low:       3 (37.5%)
  Medium:    3 (37.5%)
  High:      2 (25.0%)
  Very High: 0 (0.0%)

Art. 36 consultation: NOT TRIGGERED (no Very High residual risks)

---

トラブルシューティング

問題	考えられる原因	解決策
しきい値チェッカーでは「不要」と表示されるが、処理にリスクがあるように感じる	活動の説明が曖昧、または重要な詳細が不足している	データの種類、規模、自動化のレベル、データ主体のカテゴリーを含め、より具体的に説明します
2基準の推定が適用されたが、管理者が同意しない	管理者は、推定に反論する理由を文書化する必要がある	基準に該当するにもかかわらずDPIAが不要である具体的な理由を文書化します。監督機関（SA）が異議を唱える場合があります
リスク登録簿で、緩和策の適用後も残存リスクが「高」と表示される	緩和策が不十分、または適切に評価されていない	緩和策の有効性を確認し、追加の管理策を検討します。残存リスクが高いままの場合、Art. 36に基づく協議が必要です
複数の管轄区域を対象とした確認で、結果に矛盾が生じる	監督機関（SA）ごとに禁止リストやしきい値が異なる	最も厳しい要件を適用し、管轄区域ごとの分析を文書化します
AIシステムのDPIAで、学習時と推論時のリスクが不明確	学習と推論の各フェーズでリスク特性が異なる	EDPB Opinion 28/2024に従って分析を分け、各フェーズを個別に評価してから統合します
Art. 36の確認で、しきい値が不明確	残存リスクが「高」と「非常に高」の境界付近にある	境界付近の評価を文書化し、適切な対応として任意の協議を検討します

---

成功基準

• すべての高リスク処理活動を評価済み -- 処理開始前にしきい値の確認を完了し、判定とその根拠を文書化している
• 緩和策を記載したリスク登録簿が完成している -- 特定されたすべてのリスクについて、発生可能性、重大度、権利のカテゴリー、および少なくとも1つの緩和策を記載している
• 残存リスクが許容可能、またはArt. 36に基づく協議を開始済み -- 対処されていない「非常に高い」残存リスクがない
• 文書が監督機関（SA）の期待に沿っている -- 評価がArt. 35(7)の要件である、体系的な記述、必要性・比例性、リスク、緩和策に準拠している
• EDPBの基準を適切に適用している -- 2基準の推定を適切に評価し、その根拠を文書化している

---

対象範囲と制限事項

対象範囲：

• Art. 35(3)のトリガーおよびEDPBの基準に基づくDPIAしきい値の評価
• 緩和策の追跡と残存リスクの計算を含むリスク登録簿の管理
• Art. 36に基づく事前協議のしきい値評価
• 複数の管轄区域における禁止リストへの対応（DE、FR、IE、BE、NL、IT、PL）
• AIシステムの2フェーズDPIA分析に関するガイダンス
• Recital 75に基づくデータ主体の視点からのリスク評価

対象範囲外：

• 適法な根拠（Art. 6）の選択、またはArt. 9(2)の例外の適用可能性に関する法的助言
• 監督機関への提出または監督機関とのやり取り
• 緩和策（暗号化、アクセス制御）の技術的な実装
• DPOの任命または協議の実務
• 記載されている管轄区域以外の国内禁止リストを網羅的に扱うこと
• EU AI Actの適合性評価（eu-ai-act-specialistを参照）

---

アンチパターン

• 処理開始後にDPIAを実施する -- Art. 35(1) では、処理開始前にDPIAを実施することが求められます。遡及的なDPIAでは法的義務を満たせず、執行上のリスクが生じます
• 管理者の視点からリスクを評価する -- Recital 75 に基づき、DPIA のリスクはデータ主体の視点から評価する必要があります。この分析では事業への影響は関係ありません。企業にとって軽微な侵害でも、影響を受ける個人にとっては壊滅的な事態となる可能性があります
• 仮名化によってDPIAが不要になると見なす -- GDPR（Recital 26）では、仮名化されたデータも引き続き個人データに該当します。仮名化はリスクスコアを下げる軽減策であり、DPIA全体を省略する根拠にはなりません
• 残存リスクが高い場合に Art. 36 の協議を省略する -- 軽減策を講じた後も残存リスクが「非常に高い」場合、監督機関との事前協議は任意ではなく、必須です
• DPIA と FRIA を混同する -- EU AI Act の基本的権利影響評価（Art. 27）は、GDPR の DPIA とは別の義務です。一方を完了しても、もう一方を満たしたことにはなりません。個人データを処理する AI システムでは、両方が必要となる場合があります

---

ツールリファレンス

dpia_threshold_checker.py

Art. 35(3) のトリガーと EDPB の基準に基づいて、DPIA が必要かどうかを評価します。

フラグ	必須	説明
--activity <text>	はい（--input または --template を指定していない場合）	処理活動の説明
--input <file>	はい（--activity を指定していない場合）	JSON 形式の処理内容を記述したファイルへのパス
--template	いいえ	空の入力テンプレートを生成します
--json	いいえ	JSON 形式で出力します

dpia_risk_register.py

軽減策の追跡と残存リスクの算出を行いながら、DPIA リスク登録簿を管理します。

サブコマンド	説明
init	新しい空のリスク登録簿を作成します（--output が必須）
add	リスクを追加します（--register、--description、--rights-category、--likelihood、--severity が必須）
mitigate	軽減策を追加します（--register、--risk-id、--measure、--likelihood-reduction、--severity-reduction が必須）
view	リスク登録簿を表形式で表示します（--register が必須）
summary	分布を含む概要を生成します（--register が必須、--json は任意）
art36-check	Art. 36 の協議要件を確認します（--register が必須）