compliance-testing について
compliance-testing は、QA チーム向けの技術的なコンプライアンステストスキルです。承認済みの地域ポリシーに照らして同意状態、リクエスト遮断、保存、開示を検証しますが、テスト合格は法令遵守や CMP 認証を示すものではありません。
主な機能
- 01同意前後の保存状態とリクエストを検証
- 02同意の保存・撤回と GPC 信号を確認
- 03TCF v2 と Consent Mode 信号をテスト
- 04EU AI Act の開示要件を確認
- 05Cookie 属性とインベントリのずれを検証
- 06Better Ads 基準に沿った広告体験のテスト
活用シーン
- 01同意拒否後に送信される追跡リクエストの調査
- 02撤回後の保存状態と通信の変化を検証
- 03実際の Cookie と定義済み一覧の照合
- 04AI 生成コンテンツの開示テストを自動化
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ petrkindlmann/ qa-skills --skill compliance-testingインストール後、Claude Code で/compliance-testingを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
references/better-ads-tests.mdci-automation.mdcookie-compliance.mdeu-ai-act-tests.mdgdpr-cmp-tests.md詳細
調査時の質問
まず、プロジェクトのルートにある .agents/qa-project-context.md を確認してください。このファイルには、適用される規制、CMP の詳細、広告ネットワーク、対象地域が記載されています。すでに回答されている質問は省略してください。ファイルがない場合は、qa-project-context スキルを使って作成することを提案してください。
適用される規制
- どのプライバシー規制およびプラットフォーム規制が適用されますか? これにより、テストマトリックス全体が決まります。
- EU: GDPR、ePrivacy 指令(Cookie)、デジタルサービス法(DSA、2024 年 2 月 17 日適用開始)、EU AI 法(禁止事項と AI リテラシー要件は 2025 年 2 月 2 日適用開始、汎用 AI(GPAI)の義務と罰則は 2025 年 8 月 2 日適用開始、第 50 条の透明性要件は 2026 年 8 月 2 日適用開始 — 高リスク AI の義務は延期されています。下記を参照してください)。
- 米国: CCPA/CPRA および対象ユーザーに適用される州法。地域別ポリシーマトリックスに、具体的なオプトアウト要件とユニバーサルシグナルの要件を記録してください。
- 英国: UK GDPR/DPA、PECR(Cookie)、2023 年オンライン安全法、データ利用・アクセス法(DUAA)。
- その他: LGPD(ブラジル)、PIPEDA(カナダ)、POPIA(南アフリカ)。
- 処理の法的根拠は何ですか? 同意(オプトイン)、正当な利益、または契約上の必要性のいずれかです。これにより、処理の開始前に明示的な同意が必要かどうかが決まります。
- DPO または法務チームはいますか? 法的要件を定義するのはこの担当者です。このスキルでは、それらの要件に照らして技術的な実装のみを検証します。
同意管理
- どの CMP と広告製品を使用していますか? CMP によってストレージ形式、API、統合方法が決まります。対象となる製品と地域について、現在の認証状況と TCF 要件を記録してください。CMP API の応答や数値のポリシーバージョンの比較から推測しないでください。
- どのような同意カテゴリがありますか? 一般的には、Strictly Necessary(常に有効)、Analytics/Performance、Functional/Preferences、Marketing/Targeting です。
- サードパーティスクリプトにはどのように同意を伝えますか? IAB TCF v2(
__tcfapi)、カスタムデータレイヤー、または CMP API のいずれですか? - Google Consent Mode は Basic と Advanced のどちらですか。また、地域別ポリシーで要求されるデフォルト設定は何ですか? Basic では、同意が得られるまでタグをブロックします。Advanced では、ストレージへの同意が拒否されていても、許可された測定データを送信できます。この違いにより、同意前のネットワークに関する検証内容が変わります。Google の実装ガイドを参照してください。
- 各同意状態の変更が完了したことを何によって確認しますか? 予定されたタグ処理を含む、アプリケーションまたは CMP の完了シグナルを特定してください。バナーの表示や
networkidleだけでは、遅延トラッキングが発生しないことを確認できません。
広告とアクセシビリティ
- どの広告ネットワークとフォーマットを使用していますか? Google Ads、Meta、プログラマティック広告など、ディスプレイ、動画、インタースティシャルなどです。Chrome の広告フィルタリングの対象となるフォーマットは、Coalition for Better Ads が定義しています。
- アクセシビリティに関する義務(ADA、EAA、Section 508)はありますか? これらは実際のコンプライアンス要件ですが、
accessibility-testingで作成してください。このスキルでは法的な適用範囲の整理のみを行います。下記を参照してください。
基本原則
1. 承認済みポリシーをテストの基準にする
各地域および同意状態について、期待されるストレージ、リクエスト、シグナル、UI の動作を記録してください。マトリックスからの逸脱は失敗と判定します。テストで証明できるのは、観測された技術的な結果です。法令の適用可能性、許可される処理、視覚的なダークパターンの判断には、それぞれ別途レビューが必要です。
2. 技術的なチェックは自動化し、法務監査はスケジュールを設定する
自動化する項目:ポリシーで禁止されている Cookie とリクエスト、バナーの機能、Cookie 属性、同意の保持、GPC、Consent Mode のシグナルです。プライバシーポリシーの文言、バナーの目立ちやすさ、越境移転に関する文書は、引き続き人が監査します。最小ボタンサイズのアサーションだけでこれらの問題が解決したかのように装ってはいけません。
3. 同意が望ましくない状態になるケースをテストする
コンプライアンスの境界となるのは、「操作なし」「拒否」「撤回」の状態です。違反が隠れているのはこのような状態です。「すべて許可」の状態は、テスト対象として最も興味を引きません。
4. CMP ではなく動作を検証する
CMP にはバグがあります。CMP の UI を証拠として信用してはいけません。実際の結果をアサートしてください。Cookie が設定されたか、スクリプトが読み込まれたか、GPC のオプトアウトが登録されたかを確認します。CMP は実装の詳細であり、コンプライアンスは動作で評価します。
5. 多層防御と設定駆動
CMP の設定、ネットワークリクエスト、Cookie の状態、クライアントシグナルなど、複数のレイヤーで検証します。型付きのインベントリとトラッキングドメインのリストを使ってテストを駆動し、カテゴリやしきい値の追加をテストスイートの書き換えではなく、データの編集で済ませます。規制は変わるため、テストスイートは低コストで更新できる必要があります。
Playwright による GDPR / CMP のテスト
同意フローのコンプライアンスは、それぞれ独立して失敗しうるチェックに分かれています。各チェックの実行可能なコード全文は references/gdpr-cmp-tests.md にあります。
- 同意バナーとコントロール — 初回訪問時に表示されること、同意・拒否のコントロールが使用可能であること、ポリシーへのリンクがあることを検証します。最小寸法は機械的なしきい値です。同等の目立ちやすさとダークパターンは別途評価してください。
- 同意前後の Cookie の状態 — 初期化の完了時、同意時、拒否時に、承認済みのオプションストレージポリシーを適用します。必要不可欠な Cookie の名前を正確に管理し、インベントリ全体を維持してください。プレフィックスによって、名前が似たトラッキング Cookie まで例外扱いにしてはいけません。
- 同意の保持と撤回 — ナビゲーション後に実際に保持された状態と、撤回後に更新された新しい状態を検証し、その後にストレージとネットワークへの影響を確認します。初回訪問には、
storageState: { cookies: [], origins: [] }を設定した新しいコンテキストを使用してください。 - サードパーティリクエストのブロック — ナビゲーションの前に
page.on('request')を登録し、URL の部分文字列ではなく、設定済みのホスト名とエンドポイントを照合します。基本モードではトラッキングリクエストがゼロであることを求められます。高度なモードでは、拒否状態で許可されるトラフィックをアサートする必要があります。ファーストパーティプロキシと、実際の完了マイルストーンを含めてください。 - Global Privacy Control — HTTP ヘッダーの経路と DOM の設定経路を個別に検証します。
extraHTTPHeaders: { 'Sec-GPC': '1' }を設定しても、navigator.globalPrivacyControlは作成されません。DOM エミュレーションであることを明示し、記録されたオプトアウトと、ポリシーで禁止されている動作を確認します。ブラウザーのサポート検証には、GPC が有効なネイティブブラウザーを使用してください。GPC 仕様を参照してください。 - TCF v2 の同意状態 —
__tcfapi('addEventListener', 2, callback)を使用し、該当する完了イベントを待機して、失敗に上限を設定し、リスナーを削除します。getTCDataは非推奨です。設定済みの目的とベンダーの同意をアサートしてください。ポリシー番号だけでは、TC 文字列の有効性、TCF v2.3 の鮮度、認定を証明できません。IAB CMP APIを参照してください。 - Google Consent Mode v2 — 地域のポリシーに照らして4つすべてのシグナルを検証し、コマンドの順序を維持します。すべてのテストでオブザーバーを設定し、各アクションの前にチェックポイントを設けてください。アプリ独自のデフォルト値をテストする際に、拒否状態のデフォルト値をテスト用に設定してはいけません。共有アダプターは gtag の引数配列を監視します。オブジェクトイベントと GTM の同意テンプレート API には、それぞれのドキュメントに記載されたアダプターが必要です。共有ヘルパーと基本モード/高度なモードの違いについては、
../analytics-tracking-testing/references/consent-mode.mdを参照してください。
EU AI 法への準拠
この法令は段階的に適用され、スケジュールは2026年に変更されました。注:デジタル・オムニバス(2025年11月の提案、2026年5月7日の暫定合意)により、ハイリスク関連の義務が延期されました。旧日程の2026年8月2日のハイリスク適用日を基準にテストしないでください。
| 義務 | 適用日 | テスト内容 |
|---|---|---|
| 禁止事項+AI リテラシー | 2025年2月2日(適用中) | 第5条で禁止されている行為(ソーシャルスコアリング、公共の場でのリアルタイム生体認証、操作的な AI)がないことを確認します。対象となる AI 機能を文書化し、禁止対象ライブラリを使用できないようにします。 |
| GPAI 義務+罰則 | 2025年8月2日(適用中) | モデルカード、学習データの概要、著作権ポリシーおよび開示ページが存在することを確認します。 |
| 第50条の透明性 | 2026年8月2日 | AI 生成コンテンツに表示があること、ディープフェイクの開示、AI と対話していることがユーザーに伝えられることを確認します。開示ラベル/透かしをテストします。この日付でも適用されます。 |
| 機械可読な表示の猶予期間 | 2026年12月2日 | 2026年8月2日より前に市場に投入済みのシステムは、この日までに透かし/表示を追加できます(オムニバスにより、6か月から3か月に短縮)。 |
| ハイリスク(附属書 III、ユースケース) | 2027年12月2日 | リスク管理、データガバナンス、人間による監督、透明性 UI を確認します。オムニバスにより、2026年8月2日から延期されました。 |
| ハイリスク(附属書 I、製品規制対象) | 2028年8月2日 | 上記と同様の要件を、規制対象製品に組み込んで確認します。2027年8月2日から延期されました。 |
第50条の開示テストは今すぐ作成し、ハイリスク UI テストは附属書 III の義務が適用されるまで延期してください。第50条の透明性開示テストと、第5条の禁止行為(生体認証ライブラリ)ゲートについては、references/eu-ai-act-tests.md を参照してください。LLM 固有の評価(ハルシネーション、ジェイルブレイク耐性、プロンプトインジェクション)には、ai-system-testing スキルを使用してください。
Better Ads Standards
Coalition for Better Ads は、ブラウザーによる広告フィルタリングの対象となる広告フォーマットを定めています(Chrome は基準に準拠していないサイトの広告をフィルタリングします)。
| フォーマット | デスクトップ | モバイル | テスト方法 |
|---|---|---|---|
| ポップアップ広告 | はい | はい | ユーザー操作なしでページ読み込みから5秒以内にモーダル/オーバーレイが表示されるか確認します |
| 音声付きの自動再生動画 | はい | はい | HTML 属性ではなく、実際の video.autoplay / video.muted プロパティを読み取ります |
| カウントダウン付きプレスタイシャル広告 | はい | はい | コンテンツを遮るカウントダウンタイマーがあるか確認します |
| 大型のスティッキー広告(ビューポートの30%超) | はい | はい | スティッキー要素の寸法とビューポートを比較します |
| 広告密度が30%超 | いいえ | はい | 広告の総面積とコンテンツ面積を比較します |
| 点滅するアニメーション広告 | いいえ | はい | アニメーションのフレームレート(1秒あたり3回超の点滅)を監視します |
ミュート動画の確認では、getAttribute('muted') ではなく、実際の DOM プロパティ(el.muted)を読み取る必要があります。プレーヤースクリプトはコンテンツ属性を追加せずに JS で video.muted = true を設定するため、属性だけを確認すると、ミュートされた広告を音声付きと誤判定し、ミュート後にミュート解除される広告を見逃します。
注:CBA は2025年1月14日に、デスクトップ広告エクスペリエンスを2種類、モバイル広告エクスペリエンスを2種類追加しました。Chrome によるこれらの評価は、早くても2026年5月14日以降に始まります。 それまでは、より新しい複合フォーマットを現行の Better Ads Standards ページと照らし合わせて再確認してください。自動再生動画とモバイル広告密度の確認については、references/better-ads-tests.md を参照してください。
Cookie コンプライアンス
型付きの Cookie インベントリを信頼できる唯一の情報源として管理し、実際の Cookie が次の 3 つの観点で一致することを検証します。
- インベントリ — Cookie の名前、カテゴリ、目的、最大有効期限、および各 Cookie に必須の
Secure/HttpOnly/SameSite属性を記録したCookieDefinition[]です。 - 属性の検証 — 検出されたすべての Cookie が定義のフラグと一致し、宣言された最大有効期限を超えていないことを検証します。比較前に、未設定の
SameSiteをNoneに正規化してください。サーバーが設定していない場合、Playwright はこれを省略したり値を変えたりするため、正規化しないと誤って失敗するか、問題を見逃してしまいます。 - ドリフト検出 — インベントリにない Cookie が現れた場合は、警告ではなくテストスイートを失敗させます(
throw)。これにより、スクリプトの追加に合わせてインベントリを最新の状態に保てます。
型付きインベントリと 2 種類の実装については、references/cookie-compliance.md を参照してください。
アクセシビリティコンプライアンス — 法律の概要のみ
アクセシビリティは多くの法域で法的要件ですが、実際のテスト(axe-core、キーボード、スクリーンリーダー)は accessibility-testing で作成してください。この表は義務の内容を把握するための法律の概要です。
| 地域 | 法律 | 規格 | 適用 |
|---|---|---|---|
| EU | European Accessibility Act (EAA) | EN 301 549 / WCAG 2.1 AA | 2025 年 6 月 28 日に適用開始。加盟国による罰則が有効です。次回の EN 301 549 改訂では WCAG 2.2 との整合が見込まれます。 |
| USA | ADA | WCAG 2.1 AA(判例) | 民事訴訟 |
| USA(連邦) | Section 508 | WCAG 2.0 AA | 連邦政府の調達要件 |
| Canada(オンタリオ州) | AODA | WCAG 2.0 AA | 1 日あたり最大 100,000 ドルの罰金 |
| UK | Equality Act 2010 | WCAG 2.1 AA(ガイダンス) | 訴訟 |
定期的なコンプライアンス監査
設定のドリフトを検出できるよう、コンプライアンステストは PR 時だけでなく毎週実行し、監査証跡として結果を長期間保持される CI アーティファクトに保存してください。アーティファクトを 90 日間保持する定期実行の GitHub Actions ワークフローについては、references/ci-automation.md を参照してください。
アンチパターン
同意を受け入れた場合だけテストする
「すべて受け入れる」状態でしかコンプライアンステストを実行しないことです。コンプライアンスの境界となるのは「操作なし」と「拒否」の状態です。違反が潜んでいるのはこの状態です。すべての状態をテストしてください。操作なし、受け入れ、拒否、一部受け入れ、撤回です。
作り上げた CMP グローバル変数を検証する
GPC オプトアウトを「証明」するために、window.__cmp.gpcStatus などの架空のグローバル変数をチェックすることです。CMP の文書化された状態または設定 UI を使い、必要なネットワーク/ストレージ上の結果を検証してください。GPC HTTP ヘッダーと DOM プロパティは別々の入力であり、TCF には GPC ステータスのフィールドは定義されていません。
欠けている同意設定をテスト側で補う
アプリケーションのデフォルトをテストする際に、addInitScript から拒否のデフォルト値を設定すると、欠陥が隠れる場合があります。すべてのテストでアプリケーション独自のコマンドを監視し、後から行われる更新を保持してください。また、監視の抜けや置き換えられたデータレイヤーを修復するのではなく、テストを失敗させてください。各ゲートには、正常な状態が確認できるフィクスチャと、対象を絞った不具合のあるバリエーションを組み合わせてください。
属性だけで動画をチェックする
getAttribute('muted') === null を「音声あり」とみなすことです。プログラムからミュートされた動画では、コンテンツ属性が設定されていないことがよくあります。代わりに、el.muted/el.autoplay のライブプロパティを読み取ってください。
更新されずにずれていく Cookie リストをハードコードする
誰も更新しない Cookie インベントリを使うことです。不明な Cookie があれば throw するドリフト検出テストを使い、実際の状態とインベントリが自動的に一致するようにしてください。
CMP だけをテストする
CMP を信頼し、その UI だけを操作することです。CMP にもバグはあります。Cookie が設定されるか、スクリプトが読み込まれるか、データが送信されるかという結果をテストしてください。
四半期ごとの手動監査だけを行う
四半期に一度、手作業で監査することです。監査の間に、開発者が同意前に実行される分析スクリプトを追加しても、3 か月間誰も気づかない可能性があります。自動テストなら、次回の CI 実行時に検出できます。
地域ごとの違いを無視する
すべての地域で単一の同意モデルを使うことです。GDPR ではオプトインが必要ですが、CCPA では GPC によるオプトアウトが認められています。両方の地域にサービスを提供する場合は、両方のユーザー体験をテストしてください。
コンプライアンスを一度きりのものとして扱う
スイートを一度構築したら、そのまま固定してしまうことです。規制は変化します(ePrivacy Regulation、TCFのバージョン更新、AI Actの段階的施行、CBA基準の更新)。四半期ごとに見直してください。
検証
まずは最小限のチェックから始めます。信頼する前に、コンプライアンススイートが実行され、ゲートとして機能することを確認してください。
npx playwright test tests/compliance --project=chromium
調整したレシピを tests/compliance に配置し、実際の準備状況シグナルとポリシーインベントリを設定してください。まず、明示的に空のコンテキストで、正常なフィクスチャに対してテストが合格することを証明してください。次に、制御された不具合のあるバリアントに対してテストを実行します。禁止されたリクエストの遅延、デフォルト設定の欠落、アクション後の更新が誤っているまたは存在しないケース、GPCの無視、完了しないCMPコールバックを対象にしてください。それぞれに対応するテストが失敗する必要があります。HTTP GPCヘッダーは、明示的にエミュレートされた、またはネイティブに有効化されたDOM設定とは独立して検証してください。すべて拒否するポリシーの高度なモードでは、測定前に4つのデフォルト設定すべてを確認してください。基本モードでは、同意後にタグが初期化される際のデフォルト設定と更新を検証してください。シナリオと観測間隔を結果とともに保持してください。
完了条件
- 製品と対象地域に適用される規制(GDPR、ePrivacy、DSA、EU AI Act、関連する米国州法の範囲、UK OSA/DUAA)が特定され、
.agents/qa-project-context.mdに記録されていること。 - すべてのエントリーポイントについて、同意フローをテスト済みであること。初回訪問、同意、拒否、撤回、ページ間移動後の永続性を、それぞれ独立した合格テストとして確認してください。
- 必要なHTTPおよびDOM入力に対するGlobal Privacy Controlのケースが合格し、記録されたオプトアウトと、ポリシーで禁止されたストレージ/リクエストが検証されていること。DOMのエミュレーションは、エミュレーションであると明示してください。
- Google Consent Modeの4つのシグナルとコマンドの順序が、承認済みの地域/モードマトリックスと一致していること。新しいアクションのチェックポイントで、同意、拒否、部分的な同意、撤回後の更新を確認してください。オブザーバーがアプリケーションの同意デフォルトを設定していないこと。
- 制御された正常なフィクスチャと不具合のあるフィクスチャにより、各技術的ゲートが意図した動作を区別できることを確認してください。上限付きのタイムアウトと完了マーカーによって、観測結果が何もないまま黙って終了することを防いでください。
- EU AI Actの適用可能性を評価済みであること。禁止行為のゲート、GPAIの文書レビュー(該当する場合)、およびAI生成コンテンツに対する第50条の透明性開示をテストしてください。
- Cookie監査が完了していること。すべてのCookieが型付きインベントリで分類され、ドリフト検出テストが未知のCookieゼロで合格していること。
- プライバシーポリシーに開示されていないトラッキングドメインやCookieが実行されないこと(これは自動化可能な範囲です。法的文言のレビューは別途、手動での法務承認が必要であり、テストではありません)。
- コンプライアンススイートが毎週のCIジョブで問題なく実行され、その結果が90日間の保持期間でアーティファクトとして保存されること。
関連スキル
- accessibility-testing — 実際のWCAG/axe-core/キーボード/スクリーンリーダーのテストを作成します。このスキルではアクセシビリティに関する法規制の全体像のみを整理し、a11yアサーションは作成しません。
- security-testing — セキュリティコンプライアンス(OWASP Top 10:2025、依存関係およびサプライチェーンのスキャン)はプライバシーコンプライアンスを補完しますが、脅威モデルもツールも異なります。
- ai-system-testing — AI機能の評価レイヤー(ハルシネーション、ジェイルブレイク、プロンプトインジェクション)を定義します。このスキルでは第50条の開示のみをテストし、AI自体の動作はそのスキルでテストします。
- ci-cd-integration — 週次監査のスケジュール実行とコンプライアンス品質ゲートのパイプライン設定を行います。
- release-readiness — コンプライアンスゲートの失敗(オプトイン前に同意処理が実行される、AI Actの開示がないなど)はリリースをブロックします。このスイートを、同スキルのリリース可否チェックリストに組み込んでください。
参考ファイル(references/内)
- gdpr-cmp-tests.md — バナーの操作、Cookie の状態、永続化/撤回、ポリシーに基づくリクエストのブロック、GPC 入力の独立性、読み取り範囲を限定した TCF イベントの取得、Google Consent Mode の遷移を検証する Playwright コードです。
- eu-ai-act-tests.md — 第50条の透明性開示テストと、第5条の禁止行為(生体認証ライブラリ)に関するゲートを実施します。Omnibus のスケジュールに関する注記も含まれます。
- better-ads-tests.md — Coalition for Better Ads のチェック項目です。稼働中のプロパティにおける、ミュートされていない自動再生動画の検出と、モバイル広告密度の測定を行います。
- cookie-compliance.md — 型付き Cookie インベントリ、属性の検証(SameSite の正規化を含む)、インベントリの差分検出について説明します。
- ci-automation.md — 90日間のアーティファクト保持期間を設定した、コンプライアンス監査を毎週定期実行する GitHub Actions ワークフローです。