gdpr-data-handling

gdpr-data-handling skill の概要

gdpr-data-handling skill でできること

gdpr-data-handling skill は、GDPR の広い要件を、データ処理、同意、データ主体の権利、保存期間、Privacy by Design に関する具体的な実装判断へ落とし込むのに役立ちます。単に「GDPR に準拠して」といった汎用プロンプトでは足りず、製品・業務フロー・ポリシーを GDPR の代表的な義務に照らして構造的に見直したい場面で特に有効です。

どんな人に向いているか

特に相性がよいのは、次のようなユーザーです。

• EU の個人データを扱う機能を出荷する product / engineering チーム
• 初期ギャップレビューを行う compliance、legal-ops、security のレビュー担当
• 同意フロー、DSR 対応、保存期間コントロールを設計する創業者や運用担当
• リリース前に gdpr-data-handling for Compliance Review を使いたい AI ビルダー

レビュー対象のシステム自体は理解しているものの、抜け漏れを防ぐチェックリストと出力の型が欲しい場合、この skill はかなり適しています。

実際に解決してくれる仕事

多くのユーザーが必要としているのは、法科大学院レベルの GDPR 解説ではありません。実務では、たとえば次のような問いに答える必要があります。

• どの個人データのカテゴリが関係するのか
• どの法的根拠を主張するのか
• 本当に同意が必要なのか
• どのデータ主体の権利に対応しなければならないのか
• 保存期間、削除、監査可能性のどこが弱いのか
• リリース前にどんな是正対応が必要なのか

これこそが gdpr-data-handling skill の中核的な価値です。

汎用プロンプトとの違い

通常のプロンプトでも、広い意味でのプライバシー助言は返せます。ですが、この skill は次のような GDPR 固有の論点をモデルにきちんと考えさせたいときに、より実用的です。

• 特別カテゴリデータや子どものデータを含む個人データ分類
• Article 6 に基づく適法根拠
• データ主体の権利への対応
• Privacy by Design に関する期待値
• ポリシー文言だけでなく、運用上のコンプライアンス作業

差が出るのは構造です。入力が雑然としていても、コンプライアンスレビュー向けの思考の枠組みをエージェントに与えやすくなります。

インストール前に知っておくべきこと

この skill は、追加スクリプトや参照フォルダを持たず、SKILL.md を中心に構成された単一ファイル型のガイダンス skill に見えます。つまり導入は簡単ですが、出力品質は与える事実情報に大きく左右されます。レビューやドラフト作成を速める助けにはなりますが、法務アドバイス、法域ごとの個別判断、実システムからの証拠収集を置き換えるものではありません。

gdpr-data-handling skill の使い方

gdpr-data-handling のインストール方法

この skill を含むリポジトリからインストールします。

npx skills add https://github.com/wshobson/agents --skill gdpr-data-handling

インストール後は、ほかの skill と同様にエージェント環境から呼び出して使います。この skill で公開されているのは SKILL.md のみなので、セットアップ作業はほぼインストールとプロンプト準備だけで済みます。

まず読むべきファイル

最初に確認するべきなのは次のファイルです。

• plugins/hr-legal-compliance/skills/gdpr-data-handling/SKILL.md

ここでは references/、resources/、スクリプト類は見当たらないため、実際の利用指針のほぼすべてがこのファイルに入っています。特に、適用範囲の境界を把握したい場合は、実案件で使う前に必ず読んでおくのがおすすめです。

実務で向いている使いどころ

gdpr-data-handling usage は、次のようなタスクに向いています。

• 個人データを収集・共有する新機能のレビュー
• 同意フローが本当に必要で有効かの確認
• プロダクトの処理フローと適法根拠の対応付け
• 開示、削除、ポータビリティに対する DSR 対応準備の評価
• リスクと是正項目を含むコンプライアンスレビュー・メモの下書き
• リリース前の Privacy by Design 主張の妥当性確認

強みが出るのは、抽象的な方針だけでなく、具体的なシステム事実をエージェントに渡せるときです。

うまく機能させるために必要な入力

この skill が義務を適切に推論するには、運用実態に関する情報が必要です。特に有用なのは次の情報です。

• プロダクトが何をするものか
• 対象ユーザーは誰か、とくに EU ユーザーや子どもが含まれるか
• どのデータ項目を収集するか
• データの取得元と送信先
• 特別カテゴリデータや犯罪関連データを扱うか
• 各処理活動の目的
• 現在の同意取得フローと通知フロー
• 保存期間
• DSR 対応プロセス
• ベンダー、subprocessor、移転の文脈

弱い入力例: “Review our app for GDPR.”

強い入力例: “Review our hiring platform for GDPR. We collect name, email, CV, interview notes, optional disability accommodation details, and recruiter assessments. EU candidates can create accounts, upload documents, and request deletion. Data is stored in AWS EU-West, shared with a US email vendor and analytics provider. We currently rely on consent for marketing emails and contract necessity for application processing.”

粗い目的を強いプロンプトに変える方法

よい gdpr-data-handling guide プロンプトは、通常次の 4 要素で構成されます。

1. システムの説明
2. データ棚卸し
3. 法務・コンプライアンス上の前提
4. 欲しい出力形式

プロンプト例:
“Use the gdpr-data-handling skill to perform a compliance review of our employee wellness app. Identify personal data categories, likely legal bases, where explicit consent is required, DSR obligations, retention risks, and privacy-by-design gaps. Then produce a prioritized remediation list with high/medium/low severity and note assumptions where facts are missing.”

このプロンプトが優れているのは、一般的な GDPR 助言ではなく、分類・分析・優先順位付けを求めている点です。

時短につながる実践的な進め方

再現性の高い進め方は次のとおりです。

1. システムと利用者を説明する
2. データカテゴリと処理目的を列挙する
3. 各処理活動を適法根拠に対応付けるようエージェントに依頼する
4. 権利、同意、保存期間、移転への影響を確認する
5. 重要度と次の対応を含むギャップ一覧を出させる
6. 初回結果を見て不足事実を補い、再評価する

いきなり最終的なポリシーや法的結論を求めるより、この段階的な進め方のほうがうまくいきます。

依頼すると役立つ出力形式

実装に落とし込む前提なら、行動につながる出力を求めるのが重要です。

• 処理活動テーブル
• 適法根拠マップ
• 同意判断マトリクス
• DSR 対応チェックリスト
• 保存・削除要件
• Privacy by Design の推奨事項
• リリース阻害要因と非阻害要因の切り分け
• 法務レビュー向けの未解決論点

こうした形式にすると、gdpr-data-handling skill は文章中心の説明よりも engineering チームや compliance チームにとって実用的になります。

この skill が特に効く場面

この skill の価値が最も高いのは、チームにまだ成熟したプライバシー運用の型がない一方で、初期の構造化レビューは必要という場面です。特に有効なのは、前提の抜けをあぶり出す用途です。多くのチームは「何を集めているか」は把握していても、「実際にどの適法根拠に依拠しているか」「開示請求や削除請求にエンドツーエンドでどう対応するか」までは整理できていないことが多いからです。

制約とトレードオフ

この skill はドキュメント中心で、バンドルされた自動化機能を持ちません。そのため、データベース、ログ、ベンダー契約、本番設定を自動で検査することはできません。与えられた事実に基づいて妥当なレビュー成果物を作ることはできますが、実装証跡の検証まではできません。監査システムではなく、ガイド付きのコンプライアンス分析レイヤーとして使うべきです。

通常のプロンプトで十分なケース

GDPR の概念を短く説明してほしいだけなら、一般的なプロンプトでも足ります。gdpr-data-handling をインストールする意味があるのは、実装レビューを繰り返し同じ構造で行いたいとき、とくに適法根拠の選定、権利対応、設計判断を engineering タスクに落とし込む必要があるときです。

gdpr-data-handling skill の FAQ

gdpr-data-handling は初心者にも向いていますか？

はい、プロダクトの内容を自分で把握しているなら有用です。この skill は、適法根拠やデータ主体の権利といった実務上の GDPR 論点に沿ってレビューを整理してくれるため、初心者の助けになります。一方で、まだデータフローを整理できていない段階だと、モデル側の推測が増えすぎるため効果は下がります。

gdpr-data-handling を Compliance Review に使えますか？

はい。むしろそれが最も有力な用途のひとつです。この skill は、機能・プロダクト・業務フローに対する初回の compliance review に向いており、規制の一般論ではなく、ギャップ一覧や是正計画を欲しいときに特に使い勝手があります。

弁護士や DPO の代わりになりますか？

なりません。gdpr-data-handling skill は、想定される義務、リスク、欠けているコントロールを洗い出す助けにはなりますが、法的助言を行うものでも、規制当局との争いで通用する解釈を保証するものでもありません。法務レビュー前の準備を良くし、見落としを減らすために使うのが適切です。

同意管理専用の skill ですか？

いいえ。同意は適法根拠のひとつにすぎず、多くのチームはそこを過剰に使いがちです。この skill は、契約上の必要性、正当利益、法的義務、Privacy by Design、DSR 対応、データ分類にも対応します。この広い視点こそ、同意だけを見るチェックリストより優先して使う理由のひとつです。

どんなときはこの skill を使わないほうがいいですか？

次のような場合は見送るべきです。

• GDPR と無関係な、純粋に非 EU 圏のプライバシー業務だけを扱うとき
• システムからの証拠収集を自動化したいとき
• この skill の範囲を超える法域特化の法的助言が必要なとき
• 自分のシステムがどのデータを処理しているかまだ分かっていないとき

その場合は、先にデータディスカバリーを行うか、専門家を入れるほうが適切です。

単なる GDPR プロンプトと何が違いますか？

素のプロンプトでは、一般論のコンプライアンス文言に寄りがちです。gdpr-data-handling usage は、データ分類、適法根拠、権利、実装上の含意を一度に漏れなく見たいときに向いています。特に機能レビューでは、この構造が抜け漏れを減らします。

gdpr-data-handling skill を改善して使う方法

スローガンではなく処理棚卸しを渡す

品質を最も大きく左右するのは、曖昧な依頼を、簡潔な処理棚卸しに置き換えることです。含めるべき項目は次のとおりです。

• actor: customer、employee、candidate、child、patient
• data: 収集する項目
• purpose: なぜ処理するのか
• basis: 現時点の想定根拠
• movement: 保存、共有、移転
• lifecycle: 保存期間と削除

これにより、gdpr-data-handling は推測ではなく分析を返しやすくなります。

高リスクのカテゴリは最初に明示する

特別カテゴリデータ、犯罪関連データ、子どものデータ、大規模モニタリング、越境移転があるなら、プロンプト冒頭で必ず明示してください。こうした事実はコンプライアンス分析を大きく変え、追加 safeguards やより深いレビューが必要かどうかの判断にも直結します。

前提と結論を分けて出すよう依頼する

よくある失敗は、根拠の薄い断定です。出力を改善したいなら、エージェントに次のラベル付けを求めてください。

• confirmed facts
• assumptions
• likely obligations
• unresolved legal questions

この切り分けがあると、社内共有しやすく、結果の安全性も上がります。

是正策は実装言語で出させる

「GDPR リスクを特定して」で止めないことが重要です。代わりに、次のような出力を求めてください。

• 必要なコントロール
• 想定オーナー
• 優先度
• 集めるべき証拠
• 提案するプロダクト変更または業務プロセス変更

そうすることで、gdpr-data-handling guide は engineering と compliance の実行ツールになります。

現状と目標状態を比較させる

より強い結果を得るには、すでに存在するものも渡してください。

• consent banner またはアカウントフロー
• privacy notice の要約
• retention ルール
• deletion プロセス
• vendor 一覧
• security controls

そのうえで、現在の状態を GDPR 上の期待値と比較させます。一般的なチェックリストより、ギャップ分析のほうがはるかに実務で使えます。

初回出力のあとに必ず回す

1 回目の実行は、不足している事実を露出させるために使うのが有効です。その後、たとえば次のように追記して再実行します。

• “Reassess legal bases now that analytics is optional and disabled by default for EU users.”
• “Update the review assuming disability information is processed only when candidates request accommodations.”
• “Prioritize remediation items that block launch in the next 30 days.”

この 2 回目の見直しで、gdpr-data-handling skill は本当に意思決定に使える水準になりやすいです。

よくある失敗パターンに注意する

結果が悪くなりやすい原因は、たいてい次のどれかです。

• データカテゴリが不明確
• controller と processor の役割が区別されていない
• 同意が常に必要だと決めつけている
• 保存期間や削除運用を無視している
• ベンダー共有や国際移転を見落としている
• 事実が足りないのに最終的な法的回答を求めている

skill を疑う前に、まずこれらの入力条件を修正すべきです。

リポジトリ固有の文脈と組み合わせる

実際のコードベースやプロダクトをレビューするなら、アーキテクチャメモ、API fields、signup flows、vendor docs をプロンプトに貼り込んでください。skill 自体はあくまで一般ガイダンスであり、実システムの文脈が入ってはじめて、意味のあるレビューになります。

gdpr-data-handling はチェックボックスではなくレビュー層として使う

gdpr-data-handling の成果を最も改善する使い方は、単発ではなく継続的なワークフローの一部として組み込むことです。たとえば、設計レビュー、リリース前レビュー、DSR 対応準備確認、変更後の再評価です。最初の出力を最終版とみなすのではなく、プロダクト変更のたびに見直すチームのほうが、はるかに大きな価値を得られます。