Claudeのprivacy-legalプラグインでDPA・DSAR・PIAを下書きする手順と日本法の補い方

privacy-legalは、Anthropicがclaude-for-legalリポジトリで公開しているプラグインです。プライバシー担当者の仕事のうち、DPA(データ処理契約)のレビュー、DSAR(本人からの開示・削除などの請求)への回答、PIA(プライバシー影響評価)の作成を、Claudeに下書きさせる8つのコマンドを束ねています。

この記事では、入れ方、コマンドごとの動き、出力の読み方を説明します。後半では、プラグインが想定していない日本の個人情報保護法をどこで補うかを扱います。

privacy-legalプラグインは何をするものか

リポジトリのREADMEは、プラグインを「社内のプライバシー担当弁護士のワークフロー」と位置づけています。対象は、DPAレビュー、DSAR回答の下書き、PIA生成、新しい規制と現行ポリシーの差分分析です。

出力は、すべて弁護士のレビューを前提にした下書きです。引用には出所のタグが付き、秘匿特権の表示は保守的に付き、送付や提出のような取り返しのつかない操作は確認を挟んで止まります。

plugin.jsonのバージョンは1.0.2、作者はAnthropicです。同梱の.mcp.jsonは、SlackとGoogle Driveの2つのMCPサーバーを指しています。DPAの原本やポリシー文書をDriveから読み、通知をSlackに出すための接続です。

想定する利用者は、READMEの表に4種類あります。

業務プラグインの全体像は人事プラグインの9スキル解説やCoworkのプラグイン3種にあります。privacy-legalは、同じ「プラグインを入れて業務の型を持ち込む」発想の法務版です。

入れ方と、最初に必ずやる初期設定

Claude Codeでは、マーケットプレイスを追加してから個別にインストールします。READMEの手順は次のとおりです。

/plugin marketplace add anthropics/claude-for-legal
/plugin install privacy-legal@claude-for-legal

マーケットプレイスの追加にはリポジトリのパスかGitHubのURLを渡します。上のanthropics/claude-for-legalはGitHubの省略形で、READMEの例とは書き方が違います。Claude Code側の仕組みはClaudeプラグイン(Plugins)完全ガイドで扱っています。

Coworkでは、Coworkタブの左サイドバーで「Customize」を開き、「Browse plugins」から入れます。プラグインのディレクトリをZIPにして自作ファイルとして入れる方法も用意されています。

入れたら、再起動してから初期設定を走らせます。

/privacy-legal:cold-start-interview

これは省略できない手順です。ルートのREADMEも「最初に初期設定を行う。他のスキルはすべて、ここで書かれる設定を読む」と明記しています。設定が空のまま実行すると、スキルは汎用の出力しか返しません。

この設定ファイルは固定ではなく、使いながら育てる前提です。ファイルを直接編集してもよく、スキルに新しい立場を記録させてもよいと説明されています。

8つのコマンドと、使う順番

コマンドは8つあります。実務では、受け付けた案件が何であるかによって入口が変わります。

新機能や新しい委託先の相談は、use-case-triageから入るのが定石です。結果が「PIA必要」なら、同じ会話でpia-generationに進めます。DPAは取引の局面で独立して届き、DSARは本人からの請求で独立して届きます。

use-case-triage — PIAが要るかを4段階で仕分ける

use-case-triageは、PIAを書く前の「そもそも要るのか」に答えるスキルです。結論は次の4つのどれかで返ります。

• PROCEED: PIAは不要で、標準の安全管理で進める
• PIA REQUIRED: 展開の前か並行して評価が必要
• DPIA MANDATORY: 規制が義務づける影響評価が必要
• STOP: プライバシーポリシーと矛盾する、または適法な根拠が説明できず、設計の見直しが必要

実行例はREADMEに載っています。

/privacy-legal:use-case-triage "Marketing wants to use behavioral data for ad personalization"

活動の説明が曖昧なときは、分類する前に質問が返ります。確認されるのは、扱うデータの種類、本人は誰か、目的は何か、新規収集か既存データの転用か、外部ベンダーが絡むか、自動判断があるか、の6点です。「新機能」「データ処理」だけでは仕分けできない、という立場です。

設定が未実施のときは「provisional(暫定)」と答えると動きます。その場合の前提は、米国の管轄、中程度のリスク許容、弁護士の役割で、出力には「暫定」の注記が付きます。日本の事業者が暫定のまま使うと、米国法の枠で答えが返ります。この点は後半で扱います。

dpa-review — 受ける側か出す側かを最初に決める

DPAレビューは、同じスキルが2つの向きを扱います。顧客から来たDPAなら、自社が処理者として運用の柔軟性を守る立場でレビューします。ベンダーのDPAなら、自社が管理者としてデータを守る立場で見ます。向きは自動判定ですが、曖昧なら聞き返します。向きを間違えると推奨がすべて逆になるためです。

見るのは、役割、処理範囲、再委託先、安全管理措置、漏えい通知、監査権、国際移転、削除・返還、責任の9項目です。それぞれ「自社の標準・譲れる線・受けられない線」を設定ファイルのプレイブックから引きます。

処理者として受けるときの「要注意条項」は具体的です。

• 再委託先の変更に顧客ごとの拒否権がある
• 短い通知期間での現地監査を求められる
• 通知期限がこちらの把握より前に設定されている
• データの所在地が1か国・1拠点に固定される
• 処理者の責任が上限なしになっている
• 顧客が拘束力のある「指示」をいつでも出せる
• 削除期限が短く、バックアップとログの保持と両立しない

管理者としてベンダーのDPAを見るときは、逆の穴を探します。再委託先の一覧が無い、安全管理が「業界標準」とだけ書かれている、漏えい通知の期限が無い、サービス改善名目で自社データを使える、といった条項です。

DPA以外の特徴も3つあります。

• 連邦法の上乗せを最初に聞く。金融(GLBA)、医療(HIPAA)、教育(FERPA)、児童(COPPA)などの規制対象データが流れるかを、条項を見る前に確認します。該当なしの場合も「該当なし」と明記して終わります
• 過去の成果物を引き継ぐ。同じ相手先の過去のトリアージやPIAがあれば、リスク評価を下限として引き継ぎます。トリアージで赤だった案件を、DPAレビューで黙って緑に下げることはできません
• 赤入れは最小の粒度で出す。条項を丸ごと差し替えず、語、句、文の順に手を入れます。丸ごと差し替えたときは、送付メモで理由を書くよう求められます

出力は結論2文、課題の件数(緑・黄・橙・赤)、条項ごとの比較、プライバシーポリシーとの整合チェックの順です。DPAが「利用目的はXとYのみ」と約束するなら、ポリシーにも同じ目的が書かれているかを照合します。

SaaSの利用規約とDPAを導入前に点検する具体的な流れはSaaSの利用規約とDPAをClaudeで審査する手順に整理しています。

dsar-response — 2通のレターで期限に間に合わせる

DSARのスキルは、請求の分類、本人確認、システムごとのデータ所在確認、例外の検討、回答の下書きの順に進みます。分類は、開示、削除、持ち運び(ポータビリティ)、訂正、異議、制限、販売・共有のオプトアウトや自動判断への異議、の7種です。「アカウントを消して、その前にデータを送って」のような複合請求は、削除と持ち運びの2件として扱います。

設計の肝は「2通のレター」です。

• 受領通知(5a): 受け取ってから数日以内に出す。請求の理解、回答の目標日、残っている本人確認の依頼を書く。実質的な開示は含めない
• 実質回答(5b): 法定期限(社内SLAのほうが短ければそちら)までに出す。開示の中身、削除の結果、持ち運び用のデータを載せる

法定期限の直前に1通だけ出すのは、内容が正しくても「プロセスの失敗」だと書かれています。期限の起点も指定があります。本人確認が終わってからではなく、請求を受け取った時点から数え、規制が別の起点を定めていなければ黙って止めない、というルールです。

例外の検討は「提案どまり」に設計されています。第三者のプライバシー、秘匿特権、営業秘密、保安、保存義務、訴訟上の保全義務などを、可能性のあるものはすべて候補に挙げます。最終的に絞り込むのは弁護士で、各候補に「提案。主張する前に弁護士のレビューが必要」と付きます。

スキルがしないことも明記されています。システムへの問い合わせはせず、チェックリストを歩かせるだけです。近しい判断は弁護士に回し、回答は送りません。

送る前の関門もあります。設定の役割が「弁護士ではない」なら、送付前に「弁護士と確認したか」を聞かれます。答えが「いいえ」なら、弁護士に持ち込む1枚の要約(本人、請求の種類、適用される規制、所在確認の結果、保留する情報と理由、期限、弁護士への3つの質問)を生成します。

pia-generation — 聞き取りから条件リストまで

PIAは、プロダクト担当への聞き取りから始まります。何を、誰のデータで、どこへ流して、何が起こりうるかを会話で聞き、自社の書式で次の7部構成に仕上げます。

1. 処理の記述
2. 適法な根拠
3. データの流れ
4. プライバシーポリシーとの整合
5. リスクと緩和策
6. 本人の権利(開示・削除・訂正・持ち運び・異議)
7. 勧告(承認/条件付き承認/要変更/不承認)

勧告には、公開前に満たすべき条件がチェックリストで付きます。「セキュリティを改善する」ではなく、「管理画面の位置情報検索に監査ログを追加(担当:エンジニアリング責任者、公開前)」のように、担当と期限のあるものにするよう求めています。

リスクの書き方にも基準があります。「データ漏えい」「GDPR違反」のような、どの機能にも当てはまる記述は悪い例として挙げられています。良い例は、設計に結びついた形です。たとえば「サポート担当が管理画面から監査ログなしで位置情報を見られるため、内部不正が検知されない」のように書きます。目安は、水増しの15件ではなく、実際のリスク2〜5件です。

方針と実務のずれの検出にも使えます。ポリシーが「データを販売しない」と言うのに、新機能が広告パートナーにデータを渡すなら、販売に当たる可能性が出ます。PIAはこうした食い違いを洗い出し、どちらかを直すまで公開しない条件にします。

出力の読み方 — 出所タグと下書きの線引き

どのコマンドの出力にも共通するのが、引用の出所タグです。DSARとDPAのスキルでは、モデルの知識から出した引用を3段階に分けて付けます。

• [settled]: 変わりにくい定番の引用(GDPR第33条の72時間通知など)。それでも提出前に確認する
• [verify]: 実在するが確認が要る引用(実施規則、規制当局のガイダンス、閾値、施行日)
• [verify-pinpoint]: 項・号・条項番号のようなピンポイントの引用。捏造リスクが最も高く、必ず一次資料で確認する

法務リサーチ用のコネクタ(Westlawなど)から取れた引用は、そのコネクタ名のタグが付きます。ウェブ検索で拾ったものは[web search — verify]です。

もう1つの規則が「黙って補わない」です。調査ツールの検索結果が少ないとき、スキルはモデルの知識やウェブ検索で穴を埋めず、状況を報告して止まり、選択肢を聞きます。

出力の先頭には「Reviewer note(確認メモ)」が1か所にまとまります。出典のコネクタが繋がっているか、全部読んだか、確認が要る箇所は何件か、を書く欄です。本体は「清書」に近づけ、補足がまぎれ込まないようにしています。

日本の事業者が使うときに補うところ

ここまでの動きは、設定した規制の範囲に沿って動きます。設定に入れていない規制は、スキルの側では分かりません。

READMEとCLAUDE.md、7つのスキルの本文には、日本や個人情報保護法への言及がありません。DSARのスキルが例に挙げる規制は、GDPR、英国GDPR、CCPA/CPRA、米国各州法、分野別の規制です。use-case-triageの暫定モードは、米国とCCPAを前提にします。ただしCLAUDE.mdには「US以外の管轄を認識する」という節があり、米国の枠組みで答えを出す場合は「米国の枠組みなので、その管轄の法で確認せよ」と明示するよう定めています。

つまり、日本の法令を補うのは使い手の役目です。既定の想定と日本法の置き場所を、並べて見ます。

e-Gov法令検索の条文で、DSARの回答に関わる点を拾うと次のとおりです。

越境移転の条項は、DPAレビューの「国際移転」の項目に響きます。外国にある第三者への個人データの提供は、第28条が原則として本人の同意を求め、体制を整えた相手先なら相当措置の継続的な確保などで足りる、という構成です。スキルの本文には欧州のSCC(標準契約条項)が例に挙がるため、日本の事業者は第28条の枠で読み替える必要があります。Claudeの契約側の論点はClaude DPAのSCC組み込みとAPPIで整理しています。

設定ファイルに日本法を書き込む例

初期設定のインタビューで規制の範囲を聞かれたら、日本の法令を挙げます。インタビュー後も、設定ファイルを直接編集できます。たとえば、CLAUDE.mdの請求対応の節を次のように書き換える方法が考えられます。以下は書き方の例です。

## DSAR process
Response SLA: 受領後14日以内に実質回答(社内目標)。法33条の「遅滞なく」を満たす水準として運用
Regulatory footprint: 個人情報保護法(開示=33条、訂正等=34条、利用停止等=35条、手数料=38条)
Fee: 手数料の徴収は実費の範囲(38条)。徴収しない運用の場合は受領通知にその旨を書く
Systems to check: 本番DB / 分析基盤 / サポートチケット / CRM / メール配信 / ログ / バックアップ / 委託先

14日という数字は、この例で社内SLAとして置いた値であり、法が定める日数ではありません。数字は自社の体制で決めます。設定に法令名と条番号を入れておくと、スキルが「この法で調べて引用する」という前提で動き、[verify-pinpoint]の確認対象も条文に絞れます。

出力が本当にその条文で書かれているかは、必ず原文で確かめます。個人情報を含むプロンプトの外部送信そのものの論点は個人情報を含むプロンプトは第三者提供に当たるかで扱っています。

つまずきやすい点

まとめ

privacy-legalは、設定ファイルに書いた自社の立場を前提に、DPA・DSAR・PIAの下書きと、その前段のトリアージを担うプラグインです。最初の10〜20分の初期設定で、出力の質がほぼ決まります。

日本の事業者にとっての分かれ目は、規制の範囲に個人情報保護法を明示的に書き込むかどうかです。書き込めば、条文を軸にした下書きにできます。書き込まなければ、米欧の枠の下書きを読み替える作業が毎回発生します。どちらでも、送付と署名は人が行います。