pia-generation

/pia-generation

1. 読み込みます：~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md → PIA のハウススタイル（トリガー、構成、詳細度、承認）。
2. 以下のワークフローを実行します。
3. 確認します：本当に PIA が必要ですか？（ハウストリガーに加え、適用される各法域の義務的な評価トリガーを調査し、一次資料を引用して最新性を確認します。）
4. インテーク：プロダクトチームに質問します。PRD が提供されている場合は、そこから情報を取得できます。
5. ハウス形式で PIA を作成します。プライバシーポリシーとの整合性チェックを含めます。
6. 条件の一覧と担当者名を付けて出力します。承認に回します。

/privacy-legal:pia-generation "Location sharing feature"

/privacy-legal:pia-generation
PRD: [Drive link]

---

PIA の作成

案件のコンテキスト

案件のコンテキスト。 実務レベルの CLAUDE.md にある ## Matter workspaces を確認します。Enabled が ✗（社内ユーザーのデフォルト）の場合、この段落の残りはスキップします。スキルは実務レベルのコンテキストを使用し、案件関連の仕組みは表示されません。有効で、アクティブな案件がない場合は、「どの案件に関するものですか？/privacy-legal:matter-workspace switch <slug> を実行するか、practice-level と入力してください。」と尋ねます。アクティブな案件の matter.md を読み込み、案件固有のコンテキストと上書き設定を確認します。出力は案件フォルダー ~/.claude/plugins/config/claude-for-legal/privacy-legal/matters/<matter-slug>/ に書き込みます。Cross-matter context が on でない限り、別の案件のファイルは読み込まないでください。

---

出力先の確認

出力を作成する前に、出力先を確認します。ユーザーが出力先（チャンネル、配布リスト、取引相手、「全員」など）を指定した場合、それが秘匿特権の対象範囲内かどうかを尋ねます。公開チャンネル、全社向けリスト、取引相手／相手方弁護士、ベンダー、クライアント（業務成果物の場合）への共有は、保護を放棄することになります。出力先が対象範囲外に見える場合は、その旨を伝え、（a）法務部門専用の秘匿特権付きバージョン、（b）より広いチャンネル向けに情報を整理したバージョン、または（c）両方を提示します。秘匿特権のヘッダーを付けたうえで、そのヘッダーでは保護されない場所への貼り付けを黙って手伝ってはいけません。このプラグインの CLAUDE.md にある正規の ## Shared guardrails → Destination check を参照してください。

目的

PIA は、記録に残すプロダクトチームとの対話です。どのデータを、なぜ、どれくらいの期間、誰が閲覧でき、何が問題になり得るかを確認します。このスキルは、その対話を構成し、コールドスタート時のシード PIA から学習したチームの形式で出力を作成します。

法域に関する前提

この評価では、設定で指定された法域の範囲を前提とします。プライバシー規則、評価トリガー、適法な根拠は、法域によって大きく異なります（GDPR、州の消費者プライバシー法、分野別法規制など）。処理活動、管理者、または影響を受けるデータ主体が別の法域に該当する場合、この分析は記載どおりに適用されない可能性があります。

この機能／アクティビティに関する過去のコンテキストを読み込む

新しい PIA を作成する前に、outputs フォルダーを確認し、同じ機能、処理アクティビティ、または取引相手に関する過去の作業がないか調べます。パスは ~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md → ## Outputs で確認してください。次の項目を検索します。

• このアクティビティを対象とする過去の use-case-triage の結果 — トリアージのリスク評価、必須条件、指摘事項は、PIA の出発点です。
• 同じ、または重複するアクティビティに関する過去の pia-generation の出力 — 以前の PIA に取って代わる PIA では、何が変わり、何が引き継がれたかを整理する必要があります。同じアクティビティに関する過去の PIA と異なる結論を、説明なく提示することは、レビューする弁護士が把握できない矛盾です。
• 対象範囲のベンダーに関する過去の dpa-review の出力 — DPA レビューの調査結果は、再委託先、越境移転、保存期間のリスクに関する PIA の分析に役立ちます。

過去の出力が見つかった場合は、PIA で引用します。

「過去のトリアージ（[date]）では、リスクは[risk level]と評価され、[conditions]が必須とされていました。この PIA はその評価を踏まえ、[どの条件が満たされ、どの条件が未解決で、どの条件の対象範囲が再設定されたか]を示します。」

過去の PIA がある場合：

「この PIA は、[理由 — 対象範囲の変更、新たなデータカテゴリ、ベンダーの変更、規制の変更]により、[date]の PIA に取って代わるものです。引き継いだ結論：[X]。修正した結論：[Y、理由はZ]。」

~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md → ## Shared guardrails にあるスキル間の重大度の最低基準ルールに従い、上流の重大度を最低基準として引き継ぎます。use-case-triage でアクティビティが高リスクと評価されている場合、理由と変更点を示さずに、PIA で低リスクと結論付けることはできません。

過去の出力が見つからなかった場合は、「outputs フォルダーにこのアクティビティに関する過去のトリアージや PIA はありません。今回は初回の確認です」と明記し、確認を実施したものの、調整対象が見つからなかったことをレビューする弁護士に伝えます。

チームのスタイルを確認する

~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md → ## PIA house style を読みます。ここには次の情報があります。

• この環境で PIA の実施が必要になる条件（規制上の DPIA の実施条件と一致しない場合があります。すべての案件で PIA を実施するチームもあれば、高リスク案件のみを対象とするチームもあります）
• シード PIA から抽出した構成テンプレート
• 標準的な詳しさ
• 承認者

PIA の構成が設定ファイルの CLAUDE.md に記載されている場合は、その構成を使用してください。この PIA の目的は、一般的な PIA のように見せることではなく、このチームが作成するほかの PIA と同じ形式にすることです。

ステップ 0：PIA は必要ですか？

~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md にある発動基準を確認してください。これがチームの標準的な回答です。

さらに、規制対象となる各法域について、現在有効な必須評価の発動要件を調査してください（GDPR／UK GDPR の DPIA 発動要件、CCPA／CPRA のリスク評価発動要件、その他の米国州法におけるデータ保護評価の発動要件、各業界の規制）。該当箇所を特定して、適用される法令、規則、規制当局のガイダンスを引用してください。情報が最新であることを確認してください。評価の基準や定義は、新たな州法、規則制定、執行ガイダンスによって変わります。推測せず、不確かな点は明示してください。

補足を黙って加えないこと。 設定済みの法律調査ツールで検索しても、ある法域の DPIA／リスク評価の発動要件または適法根拠について、結果がほとんど、あるいはまったく得られなかった場合は、見つかった内容を報告して、そこで止めてください。許可を求めずにウェブ検索やモデルの知識で不足分を補ってはいけません。次のように伝えてください。「[ツール名] から [N] 件の結果が返されました。[法域／質問] に関する情報は十分でないようです。選択肢：(1) 検索クエリを広げる、(2) 別の調査ツールを試す、(3) ウェブを検索する — 結果には [web search — verify] とタグを付け、利用前に一次資料と照合する必要があります、または (4) 未検証として記録し、ここで止める。どれにしますか？」信頼度の低い情報源を受け入れるかどうかは、弁護士が判断します。

出典の明記。 PIA 内の引用にはすべて、入手元を示すタグを付けてください。法律調査コネクターから取得した引用には [Westlaw]、[regulator site]、または MCP ツール名を付けます。ウェブ検索による引用には [web search — verify]、学習データから想起した引用には [model knowledge — verify]、ユーザーが提供した引用には [user provided] を付けます。verify タグ付きの引用は捏造のリスクがより高いため、優先して確認してください。タグを削除したり、まとめたりしてはいけません。

法令上の義務に加え、次の点は、厳密には必須でなくても PIA の実施を検討すべき強い指標として扱ってください（適用される制度の下で、これらのいずれかが単独で必須評価を発動するかどうかも調査してください）。

• 新しいテクノロジー、または既存のテクノロジーの新たな用途
• 子どものデータ
• それぞれ別々に収集されたデータセットの結合
• 差別につながるおそれのあるデータ
• ユーザーが予期しない処理

法令上の発動要件が該当せず、社内基準にも該当しない場合は、「PIA は必要なさそうです。誰かに尋ねられた場合に備えて、ファイルに保管する理由を説明する 1 段落のメモを以下に記載します。」

インテーク

何かを書く前に、プロダクトチームから次の回答を得てください。会話形式でかまいません。チームに送るフォームではありません。

内容と目的

• どのような機能／プロダクト／変更ですか？
• ユーザーにとって、どのような問題を解決しますか？
• どのような個人データを扱いますか？具体的に記載してください。「ユーザーデータ」では回答になりません。どの項目ですか？
• 新たに収集するデータはありますか？それとも、すでに保有しているデータだけですか？
• どのような処理を行いますか？保存、分析、共有、自動化された意思決定などですか？

法的根拠／制度ごとの確認事項

該当する各制度について、以下の問いに関する現在有効な枠組みを調査し、一次資料を引用してください。

• 処理に特定の適法な根拠を求める制度（例：GDPR、UK GDPR）では、目的ごとの根拠（契約／正当な利益／同意／法的義務／重大な利益／公共の利益に関する任務／その他）を特定してください。具体的な要件と、利益衡量テストまたは同意基準に関する期待事項を調査し、適用される当局の資料を引用してください。
• 開示を規制する制度（例：CCPA/CPRA、その他の米国州プライバシー法）では、現在有効な法定定義に照らして、いずれかのデータフローが「販売」、「共有」、またはその他の規制対象となる開示に該当するか確認してください。第三者広告は繰り返し問題となるため、該当する制度で規制対象のカテゴリーに含まれるか調査してください。
• 分野別の制度（HIPAA、GLBA、COPPA、FERPAなど）では、制度固有の根拠や開示に関する規則を調査してください。

最新性を確認してください。法定定義や根拠は頻繁に改正されます。不確かな点は、弁護士による確認が必要であることを明記してください。

誰が、どこで

• 社内の誰がこのデータを閲覧できますか？エンジニア、サポート担当者、アナリストなどでしょうか？
• 第三者はいますか？ベンダー、パートナー、分析サービスなどでしょうか？
• どこに保存されますか？どのリージョンですか？新しいインフラですか、それとも既存のものですか？
• どのくらいの期間保持されますか？削除スケジュールはありますか、それとも無期限に残りますか？

起こり得る問題

• このデータが漏えいした場合、本人にどのような被害が生じますか？
• 意図せずとも、このデータが差別に使われる可能性はありますか？
• ユーザーはこの処理に驚くでしょうか？（「気味が悪いかどうか」のテストです。法的基準ではありませんが、役立ちます。）
• オプトアウトの仕組みはありますか？設けるべきですか？

PIA の作成

**config CLAUDE.md にある PIA のひな形を使用してください。**ひな形を取得できなかった場合は、以下の既定のものを使用してください。~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md の ## Outputs にある成果物ヘッダーを先頭に付けてください（ユーザーの役割によって異なります。「## Who's using this」を参照してください）。

[WORK-PRODUCT HEADER — per plugin config ## Outputs]

# Privacy Impact Assessment: [Feature/Product Name]

**Prepared by:** [name] | **Date:** [date] | **Status:** DRAFT / APPROVED
**Product owner:** [name] | **Privacy reviewer:** [name]

---

## Executive summary

[Two sentences: what this is, whether it's okay. E.g., "Feature X collects
location data to provide Y. Processing is consistent with existing privacy
policy commitments and uses consent as lawful basis. Two mitigations
recommended below; no blockers identified."]

**Overall risk:** [Reviewer to set: 🟢 Low / 🟡 Medium / 🟠 High / 🔴 Very high]

---

## 1. Description of processing

**What:** [the feature, in plain English]
**Data categories:** [specific fields — not "user data"]
**Data subjects:** [customers / end users / employees / etc.]
**Purpose:** [why — tie to user benefit]
**New collection?** [yes — these fields are new / no — reusing existing data]

---

## 2. Lawful basis

| Purpose | Basis | Notes |
|---|---|---|
| [purpose 1] | [Contract / LI / Consent / etc.] | [if LI: balancing test summary; if consent: how obtained] |

---

## 3. Data flow

**Collection:** [how/where data enters]
**Storage:** [system, region, encryption]
**Access:** [who, via what controls]
**Sharing:** [third parties, purpose, governed by which DPA]
**Retention:** [how long, deletion mechanism]

---

## 4. Privacy policy consistency

| Policy commitment | Consistent? | Notes |
|---|---|---|
| [commitment from config CLAUDE.md privacy policy section] | 🟢 / 🟡 | |

[If any 🟡: policy update needed before launch, or processing needs to change]

---

## 5. Risks and mitigations

| # | Risk | Likelihood | Impact | Mitigation | Status | Owner |
|---|---|---|---|---|---|---|
| 1 | [specific risk, tied to the design — not "data breach" generically] | L/M/H | L/M/H | [specific control] | Done / Planned / Gap | [name] |

**Residual risk after mitigations:** [assessment]

---

## 6. Data subject rights

| Right | Can be exercised? | How |
|---|---|---|
| Access | | |
| Deletion | | |
| Correction | | |
| Portability | | |
| Objection | | |

---

## 7. Recommendation

[APPROVED / APPROVED WITH CONDITIONS / CHANGES REQUIRED / NOT APPROVED]

**Conditions (if any):**
- [ ] [specific thing that has to happen before launch]

**Sign-off:** [name, date]

リスクの品質基準

PIA に記載するリスクは、一般論ではなく、具体的で設計に即したものにしてください。質の低いリスクは文書を水増しし、読者が流し読みするようになる原因になります。

悪いリスク	問題点	より良い例
「データ侵害」	あらゆるケースに当てはまり、何も説明していません	「管理パネルで監査ログなしにサポート担当者が位置履歴にアクセスできるため、悪意ある内部関係者がユーザーを発見されずに追跡できる」
「GDPR に違反する」	循環論法です。PIA は本来、コンプライアンスを評価するものです	具体的な条項と不足している点を挙げてください
「ユーザーが気に入らないかもしれない」	曖昧です	「マーケティングをオプトアウトしたユーザーにも、このフローでオプトアウトフラグが確認されないため、マーケティングが届く可能性がある」

水増ししたリスクを15件挙げるのではなく、実際に問題となるリスクを2～5件挙げてください。

プライバシーポリシーとの差分

すべての PIA で、~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md に定められたプライバシーポリシー上の約束と照合してください。よくある不一致は次のとおりです。

• ポリシーには「X、Y、Z を収集します」とある一方で、新機能は W を収集する。ポリシーを更新するか、W の収集をやめる必要があります。
• ポリシーには「データを販売しません」とある一方で、新機能は広告パートナーとデータを共有する。CCPA 上の販売に該当する可能性があります。
• ポリシーには保持期間が「アカウントが有効な間」とある一方で、新機能は削除後もデータを保持する。

すべての不一致を明記してください。公開前に、いずれかを変更する必要があります。

引き継ぎ

• **プロダクトチームへ：**担当者と期限を明記した条件の一覧。「セキュリティを強化する」ではなく、「管理パネルの位置情報検索に監査ログを追加する。担当者：[eng lead]。公開前に対応。」としてください。
• **reg-gap-analysis スキルへ：**PIA でポリシーの不整合が判明した場合、そのスキルでポリシーの更新を管理します。
• **承認プロセスへ：**PIA の承認者については、~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md → 承認者を参照してください。

ゲート：DPIA を規制当局に提出する場合

内部向けの PIA の作成は、調査と文書化にあたります。DPIA を監督機関に提出すること、または問い合わせへの対応として規制当局に任意で開示することは、重大な影響を伴う行為です。

DPIA（または同等の影響評価）を規制当局、監督機関、執行機関に提出する前に： ~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md の ## Who's using this をお読みください。Role が Non-lawyer の場合：

規制当局への提出には法的な影響があります。文書は監督記録の一部となり、重要な漏れや誤りがあれば、執行措置を受けるリスクにつながります。弁護士と内容を確認しましたか？確認済みであれば、先に進んでください。まだの場合は、弁護士に相談するための概要を以下に示します。

［1 ページの概要を作成してください：適用される規制と規制当局、提出する理由（義務的な要件または任意）、特定されたリスク、緩和策実施後の残余リスク、注意が必要な不確実性、および提出前に弁護士に確認する 3 つの事項。］

ご自身の管轄区域で、資格を持つ弁護士、ソリシター、バリスター、またはその他の認定を受けた法律専門家を探す必要がある場合は、専門職規制機関の紹介サービスが最も手早い出発点です（米国では州弁護士会、イングランドおよびウェールズでは SRA／Bar Standards Board、スコットランド／北アイルランド／アイルランド／カナダ／オーストラリアでは Law Society、または管轄区域における同等の機関）。

明示的な「はい」の回答がない限り、このゲートを越えて先に進まないでください。

次のステップの判断ツリーで締めくくる

CLAUDE.md の ## Outputs に従って、次のステップの判断ツリーで締めくくってください。このスキルで作成した内容に合わせて選択肢を調整してください。5 つの既定の分岐（X の草案を作成する、エスカレーションする、追加情報を得る、様子を見る、その他）は出発点であり、固定ではありません。出力するのは判断ツリーです。選択するのは弁護士です。

このスキルで対応しないこと

• 処理を承認することはありません。PIA には人間が署名します。
• 監督機関向けの DPIA を作成することはありません。これは、特定の規制要件を伴う、より正式な文書です。このスキルが扱うのは内部評価です。
• 緩和策を設計することはありません。緩和が必要な事項を説明しますが、修正方法を設計するのはエンジニアリングチームです。