use-case-triage について
法律チーム向けのプライバシー・トリアージスキルです。設定済みの規制範囲とプライバシー上の約束を確認し、PIAやDPIAの要否を分類して、評価書の作成ではなく障害要因を示します。
主な機能
- 01プライバシー設定の確認
- 02社内PIA基準の適用
- 03必須DPIA要件の確認
- 04プライバシーポリシーとの矛盾検出
- 05分類・理由・条件の提示
活用シーン
- 01新機能のプライバシー評価要否の判断
- 02処理活動とプライバシー上の約束の照合
- 03評価前の規制要件と対応事項の特定
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/use-case-triageを入力して読み込まれたか確認します。
詳細
/use-case-triage
~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.mdを読みます。プライバシーの実務設定が済んでいることを確認してください。未設定の場合は、そこで中止してセットアップを案内します。- 以下のワークフローを実行します。活動内容が曖昧な場合は、具体的に確認してください。
- ハウスルールのトリガーを確認 → DPIA の必須要件を確認（GDPR の適用範囲に含まれる場合） → プライバシーポリシーとの抵触を確認します。
- 出力：分類（PROCEED / PIA REQUIRED / DPIA MANDATORY / STOP）、判断理由、必要に応じて条件の表、プラグイン間の引き継ぎ事項。
- 評価が必要な場合は、PIA の作成を続けるかどうかを確認します。
/privacy-legal:use-case-triage "New feature that uses behavioral data to personalize content recommendations"
プライバシーのユースケースのトリアージ
案件のコンテキスト
案件のコンテキスト。 実務レベルの 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 が必要か、何が障害になっているかも明らかにします。
プライバシーのトリアージは PIA の作成より迅速ですが、その前段階にあたります。評価そのものは作成せず、評価が必要かどうか、またどのような条件で必要かを判断します。詳細な作業は PIA 作成スキルが行います。
出力は次の 4 つの分類のいずれかです。
- PROCEED — PIA は不要です。標準的な保護措置を適用します。
- PIA REQUIRED — 導入前または導入と並行して評価が必要です。
- DPIA MANDATORY — 制度上義務付けられたデータ保護影響評価が必要です（適用される制度のトリガーを調査し、一次情報源を引用してください）。要件はより厳しく、DPO／GC の関与が必要となる可能性があります。
- STOP — 処理活動がプライバシーポリシーに抵触するか、説明された内容では適法な根拠がありません。進める前に再設計が必要です。
管轄区域に関する前提
このトリアージでは、設定で指定された管轄区域の範囲を前提とします。プライバシー規則、評価のトリガー、適法な根拠は管轄区域によって大きく異なります（GDPR、州の消費者プライバシー法、分野別の規制など）。処理活動、管理者、または対象となるデータ主体が別の管轄区域に該当する場合、この分類は記載どおりには適用されない可能性があります。
まず設定を確認する
トリアージの前に、必ず ~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md を読んでください。そこに記載されている PIA のトリガー基準、規制対象地域、およびプライバシーポリシー上のコミットメントが、判断の基準となります。一般的なプライバシー法の考え方は、この会社が実際に約束している内容の代わりにはなりません。
ファイルが見つからない場合、または [PLACEHOLDER] が含まれている場合は、次の案内を提示してください。
まだ業務プロファイルが設定されていないようです。これを設定すると、あなたの業務に合わせて PIA のトリガー基準、規制対象地域、およびプライバシーポリシー上のコミットメントを調整できます。
次の 2 つから選択してください：
/privacy-legal:cold-start-interviewを実行して（2 分）、プロファイルを設定してください。その後、あなたの業務に合わせてトリアージします。- 「provisional」 と入力すると、一般的なデフォルト（米国の法域、中程度のリスク許容度、弁護士の役割、プレイブックなし）を基準にトリアージします。また、コミットする前に私の動作を確認できるよう、すべての出力に
[PROVISIONAL — configure your profile for tailored output]のタグを付けます。
暫定モード
ユーザーが「provisional」と入力した場合は、次の一般的なデフォルトを使用して通常どおりトリアージします：中程度のリスク許容度、弁護士の役割、米国の法域（CCPA および一般的な連邦分野別の基準）、プレイブックなし（設定済みのコミットメントとの照合ではなく、一般的なプライバシー法の原則に基づいて分類）。レビュアー向けの注記とすべての所見ブロックに [PROVISIONAL] のタグを付けてください。出力の最後に、次を追加してください。
「これはデフォルトの前提に基づく一般的な実行結果です。
/privacy-legal:cold-start-interviewを実行すると、あなたの業務に合わせて調整された出力が得られます。規制対象地域、プライバシーポリシー上のコミットメント、リスク許容度が反映されます。所要時間は 2 分です。」
トリアージのプロセス
ステップ 1：活動を把握する
説明が曖昧な場合は、分類する前に質問してください。次の点を具体的に確認します。
- どのようなデータを収集または処理しますか？データのカテゴリーは何ですか？
- データ主体は誰ですか？顧客、従業員、第三者のいずれですか？
- 目的は何ですか？どのような課題を解決しますか？
- 新たなデータ収集ですか、それともすでに保有しているデータの転用ですか？
- サードパーティのベンダーが関与しますか？新規ベンダーですか、既存ベンダーですか？
- 自動意思決定が関与しますか？出力は誰かに影響を与えますか？
- 導入環境はどのようなものですか？社内限定ですか、顧客向けですか、一般公開ですか？
「新機能」や「データ処理活動」だけでは、正確なトリアージには不十分です。
ステップ 2：社内トリガーを確認する
~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md → ## PIA house style → Trigger criteria を読み、基準を適用してください。
社内トリガーに該当する場合は、少なくとも PIA が必要 です。
社内トリガーに該当しない場合も、PROCEED と結論づける前にステップ 3 に進んでください。社内ポリシーに関係なく、PIA が必要な活動もあります。
ステップ 3：必須の評価チェック
規制ごとのトリガーを調べる前に、まず活動ベースの連邦オーバーレイに関する質問をしてください。 処理が連邦規制対象のデータカテゴリーに該当する場合、通常は州のプライバシー法ではなく連邦オーバーレイが適用される枠組みとなるため、トリアージでは後回しにせず、早い段階で明らかにする必要があります。
活動ベースの連邦オーバーレイ — まず確認してください：
この処理は、以下に該当しますか？
- 消費者の金融口座データ、または「非公開個人情報」（GLBA／Reg P — 金融機関およびその非関連の第三者に適用されます。州のプライバシー法上の免除とは別に、またそれに加えて、マーケティング目的でのNPI共有に実質的な制限を課します）
- 対象事業体または業務提携先が保有する保護対象保健情報（HIPAA プライバシー規則／セキュリティ規則 — 利用および開示に実質的な制限を課し、500 件以上の記録に関する侵害通知を義務付け、あらゆるベンダーに BAA を要求します）
- 学校または学校に代わって業務を行うサービスプロバイダーが保有する教育記録（FERPA — 開示に関する同意要件、ディレクトリー情報の例外）
- 児童向けのオンラインサービスを運営する事業者が収集する、または実際に認識して収集する、13 歳未満の児童のデータ（COPPA — 保護者の同意、通知、削除権、保持および共有に対する厳格な制限）
- その他の分野別連邦制度（例：動画視聴記録に関する VPPA、通信事業者データに関する CPNI、自動車局の記録に関する DPPA、SMS／通話への同意に関する TCPA）
いずれかに該当する場合：連邦オーバーレイは通常、州の消費者プライバシー法の適用除外を定めるだけでなく、実質的な制限を定める適用枠組みとなります。続行する前に、具体的な条項を調査し、引用してください。GLBA の適用対象であるために CCPA の § 1798.145(e) の「適用除外」となる活動も、GLBA の制限（例：NPI の共有に関する § 6802(a)-(c)）の適用を受けます。CCPA の適用除外は、その活動を合法にするのではなく、適用される枠組みを GLBA に移すだけです。
~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md → ## Regulatory footprint に記載された各制度について、現在有効な、必須のプライバシー／データ保護評価のトリガーを調査してください。該当箇所を特定して、適用される法令、規則、または規制当局のガイダンスを引用してください。施行日を記載してください。各国および州の規制当局はトリガーのリストを定期的に公表・更新するため、固定的なチェックリストに依存しないでください。推測せず、弁護士による確認が必要な不確実性があれば明示してください。
該当する制度のいずれかで必須トリガーに該当する場合 → DPIA 必須（またはその制度に固有の同等の義務）。社内トリガーの有無は問いません。
強い指標（必ずしも義務ではありませんが、該当する場合は実施してください）：
- 新しい技術、または既存技術の新しい用途
- 児童のデータ
- 個別に収集されていなかったデータセットの組み合わせ
- 差別につながる可能性のあるデータ
- ユーザーが予想しない処理
- 類似オーディエンス、クロスコンテキスト行動ターゲティング広告、その他のトラッキングに基づくアドテック活動（消費者向け企業で繰り返し問題となり、ポリシー上のコミットメントとの矛盾や連邦の分野別オーバーレイを確実に浮き彫りにします）
調査済みの必須トリガーに該当しないものの、強い指標が 1 つ以上ある場合は、PIA 必須としてエスカレーションしてください （DPIA の必須実施ではありませんが、出力で明示してください）。
ステップ 4：プライバシーポリシーとの矛盾を確認する
~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md の ## Privacy policy commitments を読みます。提案された活動を、記載されているすべてのコミットメントと照らし合わせて確認します。
よくある矛盾の見落としに注意してください：
- ポリシーには「X、Y、Zを収集します」とあるが、この活動ではWを収集する。開始前にポリシーの更新が必要です。または、Wの収集を中止します。
- ポリシーには「データを第三者に販売または共有しません」とあるが、この活動ではベンダー自身の目的のためにデータを渡す。適用される各法制度の下で、そのデータの流れが規制対象となる「販売」「共有」またはその他の開示区分に該当するかを調査します。
- ポリシーで保持期間が定められているが、この活動ではデータをより長く保持する。
- ポリシーには「データは［目的］にのみ使用します」とあるが、この活動では、新たな同意または正当な利益の評価なしに、新たな目的でデータを使用する。
- ポリシーで提供するユーザーの権利が定められているが、この活動によって、権利対応プロセスで想定されていなかった新たなデータカテゴリが生じる。
直接的な矛盾がある場合 → 中止します。「注意して進める」のではありません。続行する前に、ポリシーの矛盾を解消する必要があります（ポリシーの更新または活動の再設計）。
ステップ 5：分類と出力
結論
［PIA が必要／DPIA が必須／続行 — 理由を1文で］
活動：［理解した処理活動を記載］
分類：［続行／PIA が必要／DPIA が必須／中止］
社内基準のトリガーに該当しますか？［はい／いいえ］ GDPR の DPIA 必須トリガーに該当しますか？［はい — ［トリガー］／いいえ／該当なし（対象範囲に GDPR が含まれない）］ プライバシーポリシーとの矛盾はありますか？［なし／あり — ［具体的な矛盾］］
判断理由： ［1～3文。続行の場合：現行ポリシーの下で問題がない理由。PIA／DPIA の場合：義務が生じる理由。中止の場合：矛盾する具体的なポリシー上のコミットメントまたは原則。］
PIA が必要、または DPIA が必須の場合 — 続行する前の条件：
| 要件 | 担当者 | 完了？ |
|---|---|---|
| ［例：プライバシー影響評価 — DPIA の完全な形式］ | ［プライバシー担当弁護士］ | ☐ |
| ［例：正当な利益の評価（LI を法的根拠とする場合）］ | ［プライバシー担当弁護士］ | ☐ |
| ［例：DPO への相談（DPIA 必須の場合）］ | ［DPO］ | ☐ |
| ［例：ベンダーとの DPA を締結］ | ［プライバシー／法務］ | ☐ |
| ［例：開始前にプライバシーポリシーを更新］ | ［プライバシー担当弁護士］ | ☐ |
| ［例：同意取得の仕組みを構築してテスト］ | ［プロダクト］ | ☐ |
| ［例：新しいデータカテゴリをデータ主体の権利対応プロセスの対象に含める］ | ［プライバシー／プロダクト］ | ☐ |
法的根拠（対象範囲に GDPR が含まれる場合）：［同意／契約／正当な利益／法的義務 — または「不明 — PIA での判断が必要」］
次のステップ — 続行するか確認します：
PIA が必要、または DPIA が必須という結果を提示した後は、必ず次の文で締めくくります。
「今から PIA を開始しましょうか？個別にコマンドを実行していただかなくても、質問への回答をもとに評価書を作成できます。」
相手が了承した場合は、pia-generation スキルを読み込み、同じ会話の中で続行します — 活動の説明と、すでに特定したトリガーを渡します。
相手が断った場合は、トリアージ結果はそのままです。PIA はいつでも次のコマンドで実行できます。
/privacy-legal:pia-generation [activity]
中止の場合：
矛盾：［矛盾する具体的なプライバシーポリシー上のコミットメントまたは原則］
続行するには、次のいずれかを変更する必要があります：
- ［選択肢 A — 矛盾が生じないように活動を再設計する］
- ［選択肢 B — この処理を対象とするようプライバシーポリシーを更新する（更新内容自体が法的根拠と整合するかの確認が必要）］
進む方法がない場合は、先に進む方法を提示しないでください。処理が明示されたコミットメントまたは法的根拠と単純に両立できない場合は、その旨を伝えてください。
ステップ 6：プラグイン間の引き継ぎ
AI ガバナンスへの引き継ぎ： アクティビティに、AI システムが個人に関する意思決定を行う、または意思決定に影響を与えることが含まれる場合：
「このアクティビティには AI による意思決定が含まれます。PIA に加えて、AI 影響評価も必要となる可能性があります。
/ai-governance-legal:aia-generation [activity]を使って並行して実施してください。両者は代替できるものではありません。」
プロダクト法務への引き継ぎ： 新しいプロダクト機能またはローンチの場合：
「これがプロダクトローンチの一環であれば、プロダクト法務にも共有してください。
/product-legal:launch-reviewを使うと、プライバシー関連の要素が検出され、このプラグインに引き継がれます。」
実際に該当する引き継ぎだけを指摘してください。定型文として両方を追加しないでください。
一括トリアージ
ユーザーが機能リスト、ロードマップ、またはバックログを提示した場合は、まず概要表を示してから、PROCEED 以外の各項目を詳しく説明します。
| # | アクティビティ | 分類 | 主な条件／ブロッカー |
|---|---|---|---|
| 1 | [activity] | 🟢 Proceed | — |
| 2 | [activity] | 🟡 PIA required | 適法性の根拠の評価が必要。ベンダーとの DPA が未締結 |
| 3 | [activity] | 🟠 DPIA mandatory | 大規模な特別カテゴリーのデータ |
| 4 | [activity] | 🔴 Stop | プライバシーポリシーとの不整合 — 目的の限定 |
エッジケースと失敗パターン
「匿名化されています」だけでは、自動的に PROCEED にはなりません。 どのように匿名化したのか、またデータセットを踏まえて再識別が現実的に可能かを確認してください。仮名化されたデータも、GDPR の下では引き続き個人データです。
「すでに似たことをしています」は、トリアージの代わりにはなりません。 これまで評価されていない既存の処理が、新たな処理を正当化することはありません。新しいアクティビティが規模、目的、またはデータカテゴリーの点で実質的に異なる場合は、改めてトリアージしてください。
「単なるパイロット」でもトリアージは省略できません。 実際のユーザーや従業員のデータを扱うパイロットには、同じ要件が適用されます。同じ分類基準を適用してください。PIA が必要であれば、パイロットにも PIA が必要です。
「プライバシー対応はすべてベンダーが行います。」 ベンダーが担当するのはインフラストラクチャです。目的を決定する管理者は、引き続きあなたです。個人データがベンダーに渡る場合は DPA が必要であり、その目的についても引き続きトリアージが適用されます。
推論データや派生属性も対象に含まれます。 アクティビティによって個人に関する推論データ（例：行動スコア、予測された嗜好）が生成される場合、トリアージではその推論属性を個人データとして扱ってください。「スコアを計算しているだけ」という説明によって、そのスコアが何を表しているかを見えにくくしないでください。
次のステップの意思決定ツリーで締めくくる
CLAUDE.md の ## Outputs に従って、次のステップの意思決定ツリーで締めくくってください。選択肢は、このスキルで生成した内容に合わせて調整してください。デフォルトの 5 つの分岐（X の草案を作成する、エスカレーションする、追加情報を得る、状況を見守る、その他）は出発点であり、固定ではありません。出力するのはツリーで、判断するのは弁護士です。