policy-monitor

/policy-monitor

スイープモード（引数なし、または --sweep）：

1. ~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md を読み込み、出力フォルダーのパス、ポリシー文書、前回のスイープ日を確認します。
2. 以下のワークフローを実行します。出力フォルダーをスキャンし、前回のスイープ以降に作成されたファイルを確認します。
3. 各出力について、承認済みの慣行を抽出し、現在のポリシー上の確約と照合します。
4. 不足事項を分類します：REQUIRED（ポリシーが現在の慣行を誤って記載）と ADVISABLE（ポリシーに記載なし）。
5. 各不足事項について、現在のポリシーを引用し、不足内容を説明し、推奨文案を作成します。
6. ~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md の最終ポリシースイープ日を更新します。

直接クエリモード（説明の引数あり）：

1. ~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md を読み込み、現在のポリシー上の確約と実際のポリシー文書を確認します。
2. 提案された慣行を解析します。データカテゴリー、目的、第三者、保持期間、ユーザーの権利、開示について、ポリシーと照合します。
3. 出力：対応済み／不足／矛盾、および各不足事項に対する推奨文案と実施時期の推奨。

スケジュール： ご利用のスケジューラー（カレンダー、タスクマネージャー、CI）で、/privacy-legal:policy-monitor を毎週実行する定期リマインダーを設定します。スケジュール実行には、スケジュール済みタスクとの連携が必要ですが、このプラグインには含まれていません。

/privacy-legal:policy-monitor
/privacy-legal:policy-monitor "We want to start using behavioral data to personalize onboarding emails"

---

プライバシーポリシーのモニタリング

目的

プライバシーポリシーと実際の慣行との間には、一方向の乖離が生じます。慣行は先へ進み、ポリシーは取り残されます。PIA によって新たなデータカテゴリーが承認されます。どこにも記載されていない再委託先との DPA が締結されます。トリアージ結果により、新たなユースケースに条件付きの判定が下され、ポリシーにはまだ記載されていない開示要件が課されます。数カ月後に誰かがポリシーを読んでも、実際の運用が反映されていません。

このスキルは、出力フォルダーを毎週クロールするか、「X を始めようとしていますが、ポリシーにはどのような影響がありますか？」という直接の質問に答えることで、問題になる前に乖離を検出します。

出力は常に同じです。不足事項と、推奨文案を提示します。

---

現在の状態を読み込む

~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md を読み込みます。

• ## Who we are → ## Regulatory footprint：対象となる法規制（GDPR、CCPA / CPRA / その他の州消費者プライバシー法、GLBA、HIPAA、FERPA、COPPA、VPPA、CPNI など）
• ## Privacy policy commitments：公開済みのポリシーから抽出した確約事項
• ## Outputs：出力フォルダーのパス、ポリシー文書の場所、前回のスイープ日

## Outputs に [PLACEHOLDER] が含まれている場合：

「出力はまだ設定されていません。直接クエリでの確認は実行できます。計画していることを説明していただければ、現在のポリシーと照合します。クロールスイープを有効にするには、/privacy-legal:cold-start-interview を実行し、出力フォルダーのパスを指定してください。」

## Outputs に記載されたパスから、実際のプライバシーポリシー文書を読み込みます → Privacy policy document。設定ファイルの CLAUDE.md にある確約事項は要約です。編集案を提示する際は、実際の文書を正とします。

プライバシーに関する約束は複数の場所に記載されています — すべてを確認しましょう

ウェブサイトのプライバシーポリシーは、複数ある掲載先の一つです。現代のプライバシープログラムでは、規制当局が不整合を積極的に調査する、少なくともあと4つの場所でも拘束力のある約束が示されています。

1. Cookie 同意バナー／CMP。 同意管理プラットフォームは、Cookie のカテゴリと目的を具体的に提示します。プライバシーポリシーに「分析 Cookie を使用します」と書かれている一方、CMP では「厳密に必要なもののみ」と表示されていれば、矛盾が生じます。EU のデータ保護当局と FTC は、いずれも CMP の設定不備に対して措置を講じています。
2. アプリストアのプライバシーラベル。 Apple の App Privacy（「栄養成分表示」）と Google の Data Safety は、事業者の自己申告に基づき、FTC の執行対象となります。プライバシーポリシーを更新しても、App Store のラベルを更新しない企業には、規制当局の目に触れる重大な不整合が生じます。確認事項：ラベルの最終更新日はいつですか？現在のポリシーに記載されたデータカテゴリ、目的、共有内容と一致していますか？
3. 製品内の同意フロー。 ユーザーがデータ利用に関する選択を行う実際の画面（オンボーディング時の同意、設定の切り替え、「ポリシーを更新しました」というダイアログなど）です。ポリシーには事業者の取り扱いが記載され、同意フローにはユーザーが同意した内容が示されます。両者は一致している必要があります。
4. 分野別の通知。 GLBA のプライバシー通知、HIPAA の NPP、FERPA のディレクトリ情報に関する通知、COPPA の直接通知です。これらには独自の更新義務があり、一般的なプライバシーポリシーとの整合性も個別に求められます（「分野別通知」の項で詳述）。

各掲載先の場所と最終更新日を、プラクティスプロファイルに追加してください。 確認時には、各掲載先を現在のポリシーと照合し、相違があれば次のように警告します：「プライバシーポリシーは[日付]に更新されています。App Store のラベルの最終更新日は[それ以前の日付]です。新しいデータカテゴリが反映されていない可能性があります。CMP の最終設定日は[日付]です。Cookie の目的がポリシーと一致していることを確認してください。」

プライバシーポリシーに問題がなくても、App Store のラベルが古い企業には、FTC からの申し立てがいつあってもおかしくありません。文書だけでなく、掲載先全体を確認してください。

今回の確認では、分野別の通知も対象になります

ウェブサイトのプライバシーポリシーは、通知の一つです。連邦規制の対象となる業務には、ウェブサイトのポリシーでは代替できない、別途、分野に特化した通知が必要です。## Regulatory footprint に以下のいずれかが含まれる場合、今回の確認ではウェブサイトのポリシーに加えて、その通知との相違点も確認します。該当する通知が設定されていない場合は、その不在を指摘します。

フットプリントの項目	照合する分野別通知	指摘する内容
GLBA / Reg P（NPI を取り扱う金融機関）	GLBA の初回および年次プライバシー通知（12 C.F.R. Part 1016、または機能上の規制当局が定める同等のもの）	新たな NPI のカテゴリ、系列外の第三者との共有、または Reg P の通知に反映されていないオプトアウトの仕組みの変更を示唆する出力を指摘します。NPI を受け取る分析ベンダーと DPA を締結したにもかかわらず、対応する Reg P 通知が更新されていない場合は、ギャップです。
HIPAA（対象事業体または BA）	プライバシー慣行に関する通知（45 C.F.R. § 164.520）	新たな利用または開示、定例的な新しいカテゴリ、患者の権利に関する仕組みの変更を示唆する出力を指摘します。PHI を扱う新たな下請業者と BAA を締結したにもかかわらず、対応する NPP が更新されていない場合は、ギャップです。
FERPA（学校または学校向けサービスプロバイダー）	年次のディレクトリ情報／権利に関する通知（34 C.F.R. § 99.37）	学校関係者の例外に基づくサービスプロバイダーへの新たな開示カテゴリ、新たなディレクトリ情報の項目、または保護者の同意の引き継ぎに関わる変更を示唆する出力を指摘します。
COPPA（13 歳未満の子どもを対象とするサービスの運営者）	保護者への直接通知とオンライン通知（16 C.F.R. § 312.4）	子どもから収集する新たなデータカテゴリ、新たな第三者への開示、検証可能な保護者同意の仕組みの変更を示唆する出力を指摘します。
VPPA / CPNI / DPPA / その他の分野別規制	各規制が定める固有の通知または同意の仕組み	規制で制限されている処理活動が、設定された通知に反映されていない場合に指摘します。

フットプリントに含まれる規制について、分野別通知が設定されていない場合、一度限りの検出事項ではなく、毎回の確認で継続的なギャップとして表示してください。確認結果には以下を含めてください。

分野別通知の対応状況：

• [規制名]：[設定済みの通知のパス + 最終更新日、または「未設定 — 解決するまで毎回の確認で指摘」]

分野別通知を特定できない場合は、その旨を明示してください。ウェブサイトのポリシーだけを黙って照合対象にしないでください。GLBA を無視したポリシー監視の確認結果を頼りにするフィンテック企業の DPO は、規制当局向けの通知が古いまま、警告も受けずに運用を開始することになります。ギャップを明確に表示してください。

フットプリントが曖昧な場合は、ユーザーに確認してください。 ## Regulatory footprint に「GDPR / CCPA」とある一方で、出力のスキャンにより PHI、NPI、または学生データのカテゴリが見つかった場合は、先にフットプリントと実際の業務の不一致を指摘してください。「フットプリントには [GLBA / HIPAA / FERPA / COPPA] が記載されていませんが、今回の確認では [カテゴリ] を扱う出力が見つかりました。この規制をフットプリントに追加しますか。また、照合対象とする分野別通知はありますか？」

---

モードの判定

確認モード： 引数なし、--sweep、またはスケジュールによる起動。 → 出力フォルダーをスキャンします。前回の確認以降のすべての出力を、現在のポリシーと照合します。

直接問い合わせモード： ユーザーが新たに提案する業務の説明を提示。 → その業務を現在のポリシーと照合します。更新案を提示します。

---

モード 1：確認

対象範囲の特定

## Outputs → Last policy sweep の日付を確認します。出力フォルダーをスキャンし、その日付より後に作成された出力ファイルを探します。日付が記録されていない場合は、すべてのファイルをスキャンし、「初回確認 — すべての出力をスキャンします。」と記載します。

出力フォルダーが空、または前回の確認以降に新しいファイルがない場合：

「[前回の確認日] 以降、新しい出力はありません。ポリシーは最近の業務を反映しているようです。次回の確認予定日：[日付]」

確認の完了後、~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md の Last policy sweep を今日の日付に更新します。

各出力タイプで確認する内容

PIA（プライバシー影響評価）：

• 抽出する内容：処理されるデータカテゴリ、目的、関与する第三者／サブプロセッサー、保持期間、ユーザーの権利への影響、処理に課される条件
• フラグを付ける内容：その一覧に含まれる項目のうち、現在のプライバシーポリシーの約束に記載されていないもの

DPA レビュー（署名済みまたは承認済み）：

• 抽出する内容：追加されたサブプロセッサー、合意されたデータの保管場所、対象となる処理目的、DPA の条項によってデータ主体に生じる義務
• フラグを付ける内容：ポリシーに記載されていないサブプロセッサー（ポリシーで名称を挙げている場合）、新たな処理カテゴリ、新たなデータの保管場所、ポリシーと矛盾する義務

トリアージ結果（PIA REQUIRED／PROCEED の結果）：

• 抽出する内容：承認された内容、公的な約束を示唆する条件（例：「公開前に影響を受ける当事者への通知が必要」）
• フラグを付ける内容：ポリシーの対象となっていない承認済みの慣行、ポリシーへの記載が必要な条件

DSAR への回答：

• 抽出する内容：以前の DSAR 回答に記載されていなかった新たなデータカテゴリ、システム一覧に追加されたシステム
• フラグを付ける内容：収集されているものの、ポリシーに記載されていないデータカテゴリ

ギャップの特定

フラグを付けた各項目について、次のように評価します。

更新必須 — ポリシーで約束している内容と出力が矛盾する場合、または処理が行われているのにポリシーでまったく扱われていない場合です。更新しないと、重大な誤表示になります。

例：ポリシーに「氏名、メールアドレス、決済情報を収集します」と記載されています。PIA で位置情報の収集が承認されましたが、ポリシーには位置情報について何も記載されていません。開示していないデータを収集しているため、これは更新必須です。

更新が望ましい — ポリシーに記載がないものの、矛盾はしない場合です。更新しなくても処理の正当性を説明できますが、更新するとより明確になります。

例：ポリシーに「サービスプロバイダーとデータを共有する場合があります」と記載されています。新しい分析ベンダーとの DPA に署名しました。ポリシーではベンダーの名称を挙げていませんが、ベンダーを除外しているわけでもありません。サブプロセッサーの一覧を名称付きで管理している場合は、そこに追加することが望ましいです。

一括確認の出力形式

[WORK-PRODUCT HEADER — per plugin config ## Outputs — differs by role; see `## Who's using this`]

# Privacy Policy Monitor — Sweep Report

**Date:** [date]
**Outputs scanned:** [N files] | **New since last sweep:** [N files]
**Gaps found:** [N] REQUIRED | [N] ADVISABLE

---

## REQUIRED updates

### [Gap 1 short name]

**Source:** [filename / output type that triggered this]
**What's happening:** [plain description of the new practice]
**Current policy:** [quote the relevant section — or "No coverage"]
**Gap:** [what's missing or inconsistent]

**Suggested language:**
> *Add to [section name]:*
> "[Drafted policy text — specific, consistent with house style of the actual policy]"

---

[repeat for each REQUIRED gap]

---

## ADVISABLE updates

### [Gap name]

**Source:** [filename]
**What's happening:** [description]
**Current policy:** [quote or "Silent"]
**Suggested language:**
> *Add to / update [section]:*
> "[Drafted text]"

---

## No action needed

[List outputs scanned where no gaps were found — confirms they were reviewed]

---

## Next steps

- [ ] Review REQUIRED updates — each needs a decision before the associated
  feature/processing goes live (or immediately if already live)
- [ ] Review ADVISABLE updates — lower urgency but worth addressing at next
  policy refresh
- [ ] Next scheduled sweep: [date]

---

モード 2：直接問い合わせ

提案された慣行を解析する

ユーザーの説明から次の内容を抽出します。

• どのようなデータを収集または処理しますか？
• 目的は何ですか？
• 他に誰が関与しますか（ベンダー、パートナー、第三者）？
• データ主体は誰ですか？
• 自動意思決定はありますか？
• データ主体への新たな通知が必要ですか？

説明が曖昧な場合は、先に確認の質問を 1 つしてから進めます。長い聞き取りは行いません。このモードでは迅速に対応します。

ポリシーとの差分

提案された慣行を、現在のポリシーの関連する各セクションと照合します。

確認項目	現在のポリシーの記載	提案された慣行	判定
データカテゴリ	[ポリシーに記載されている内容]	[該当する場合は新しいカテゴリ]	🟢 対象 / 🟡 ギャップ / 🔴 矛盾
目的	[記載されている目的]	[新しい目的]
第三者／サブプロセッサー	[記載されている関係者]	[該当する場合は新たな関係者]
保持	[保持に関する約束]	[示唆される保持期間]
ユーザーの権利	[提供される権利]	[新たな権利への影響]
開示／通知	[ユーザーへの通知に関するポリシーの記載]	[この慣行で必要となる内容]

直接問い合わせの出力形式

[WORK-PRODUCT HEADER — per plugin config ## Outputs — differs by role; see `## Who's using this`]

# Privacy Policy Check: [Proposed practice in one line]

**Bottom line:** [POLICY UPDATE REQUIRED / ADVISABLE / NO UPDATE NEEDED]

---

## What's covered

[List aspects of the proposed practice already addressed by the current policy —
brief, confirms they don't need to change]

## What's missing

### [Gap 1]

**Current policy:** [quote or "Silent"]
**What's needed:** [why this gap matters — legal, reputational, or consistency reason]

**Suggested language:**
> *Add to [section]:*
> "[Drafted text]"

### [Gap 2]
[same format]

## What conflicts

### [Conflict 1 — if any]

**Current policy says:** [quote]
**Proposed practice does:** [what conflicts]
**Resolution:** [which one needs to change and why — usually the practice adjusts
to match the policy, or the policy gets updated to a defensible new position]

---

## Timing

[If any gap is REQUIRED: "Policy update should happen before this goes live."
If ADVISABLE: "Can proceed; update at next policy refresh."]

---

推奨する言語品質基準

ポリシーの文言は、次の条件を満たす必要があります。

• 既存のポリシーの語調とスタイルに合わせる（草案を作成する前に、設定用の CLAUDE.md の要約だけでなく、実際の文書を読む）
• 意味のある内容になる程度に具体的でありながら、定型的な変更で破綻するほど具体的にしない（すべてのベンダーを列挙するより、「事業運営を支援するサービスプロバイダー」とするほうが長く使えます）
• チームが守れない約束をしない（たとえば、アーキテクチャ上、位置情報が分析ベンダーに送られるなら、「位置情報を共有することは決してありません」と草案に書かない）
• 文言を追加するだけでなく、より広範なポリシーの方針変更が必要となる可能性も指摘する

草案を作成する際は、追加先のセクションを必ず明記してください。適切なセクションがない場合は、その旨を伝え、新しいセクションの作成を提案してください。

---

スケジュールへの統合

ご自身のスケジューラー（カレンダー、タスクマネージャー、CI）で、毎週 /privacy-legal:policy-monitor を実行する定期リマインダーを設定してください。スケジュール実行にはスケジュール済みタスクの統合が必要ですが、このプラグインには含まれていません。

スイープを実行するたびに、~/.claude/plugins/config/claude-for-legal/privacy-legal/CLAUDE.md の ## Outputs → Last policy sweep が更新されるため、次回のスイープでは新しいファイルだけが対象になります。

---

次のステップの意思決定ツリーで締めくくる

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

スイープで10件を大きく超えるドリフトの指摘が見つかった場合、またはユーザーから依頼があった場合は、ダッシュボードを提案してください（CLAUDE.md の ## Outputs → Dashboard offer for data-heavy outputs を参照）。今回の成果物に合わせて、サーフェス別（ポリシー条項／PIA／DPA／トリアージ）の件数、重大度別の件数、およびソースとなる成果物と推奨される修正を含む、並べ替え可能な指摘一覧を提示してください。

このスキルで行わないこと

• ポリシー自体は更新しません。推奨する文言を草案として作成し、判断が必要な点を指摘しますが、変更はすべて人間が確認し、承認します。
• 規制の変更は検出しません。それは reg-gap-analysis の役割です。このスキルが監視するのは社内の運用との乖離であり、外部の法改正ではありません。
• 成果物が保存されるよう強制しません。チームが PIA を設定済みのフォルダーに保存していない場合、スイープでは見つかりません。保存済みの成果物がなくても、直接クエリモードは動作します。
• 非公式な決定を把握するためにメールや Slack を読みません。設定済みのフォルダーに保存された構造化された成果物のみが対象です。