Privacy Statnive Live · Parhum Khoshbakht

Global Privacy Control とハイブリッド同意モード：実用パターン

GPC はクライアント側で順守され、ハイブリッドモードは面ごとに同意を求めるかどうかを分けます。パターン、トラッカー API、そして 2026 年の現実的なデフォルトがハイブリッドである理由を解説します。

本記事はプライバシーに関する調査資料であり、法的助言ではありません。詳細はフッターの免責事項をご覧ください。

TL;DR

  • GPC は 2026 年 1 月 1 日付で CCPA § 7025(c)(6) のもとで拘束力を持ちます — 事業者はシグナルが順守されたことを 可視的に表示 しなければなりません。米国 12 州 が GPC またはユニバーサルオプトアウトシグナルの認識を要求しています。
  • GPC は EU 法のもとでは推定的 — まだ拘束力はありません。 提案中の Digital Omnibus 第 88b 条は、シグナルを順守するサイト運営者にコンプライアンス推定を付与する予定で、ブラウザ標準採択の 6 か月後に発効します。
  • 2 層の執行が正しいパターンです — クライアントサイドの短絡（data-statnive-honour-gpc="1" 経由）で最も摩擦の少ない経路を確保し、サーバーサイドの consent.respect_gpc 強制で多層防御を備えます。
  • ハイブリッドモードはサーバー強制であり、クライアント信頼ではありません — サーバーが権威的な同意記録を保持するため、ブラウザは同意状態について嘘をつけません。
  • WordPress プラグインは現在 2 つの同意モードのみ；Statnive Live は 4 つすべてを備えています。 ハイブリッドモードは本稿執筆時点では Statnive Live 専用です。

なぜ 2026 年に GPC が重要なのか

2009 年の ePrivacy 改訂は、EU 居住者に対し、端末機器上での保存とアクセスを拒否する権利を与えました。16 年が経過した今、ほとんどのサイト運営者がその拒否を求める方法 — 埋もれた Reject ボタン付きの Cookie バナー — が、2025 年 9 月 1 日の CNIL による 3.25 億ユーロ／1.5 億ユーロの並行制裁 と 2024 年 7 月 16 日のオランダ AP による Kruidvat への 60 万ユーロ罰金 を生んだ規制上のリスクとなっています。罰金の対象となるのは、その背後の Cookie だけでなく、バナーそのものです。

Global Privacy Control はブラウザレベルの代替手段です。すべての送信 HTTP リクエストに 1 ビットが設定されます — Sec-GPC: 1 — それが意味するのは: この訪問者は必須でないトラッキングを拒否します、サイトごとのバナーは不要です。 カリフォルニア州の CCPA は GPC を CCPA Regulations § 7025 のもとで法的拘束力のあるシグナルとして扱います。CPPA は 2025 年 9 月に 2026 年規制パッケージを最終化しました；§ 7025(c)(6) — 2026 年 1 月 1 日施行 — は加えて、事業者にシグナルが順守されたことを 可視的に表示 することを要求します（例: 「オプトアウトリクエスト順守」メッセージ）。2026 年初時点で米国 12 州が GPC またはユニバーサルオプトアウトシグナルの認識を要求しており、2025 年 9 月にはカリフォルニア、コロラド、コネチカットの司法長官が、シグナルを順守しない事業者に対する協調的捜査スイープを発表しました。提案中の Digital Omnibus 第 88b 条 は、技術標準が採択された時点で GPC を順守する EU 事業者にコンプライアンス推定を付与する予定です — これはまさに EU が 2018 年以来 Cookie 改革に必要としていたものです。

以下に続くのは、サイト運営者向けのパターンです。GPC とは何か、そして何ではないか、Statnive Live がどのように 2 層で順守するか、なぜ「ハイブリッド」同意モードが規制要件の混在するサイトにとって 2026 年の現実的なデフォルトなのか、自社バナーを統合するサイト運営者向けのトラッカー API、WordPress プラグインがどこで分岐するか、そして GPC が実際に順守されていることを検証するエンドツーエンドのテストプランをカバーします。

GPC とは何か、そして何ではないか

Global Privacy Control は HTTP ヘッダーと対応する navigator.globalPrivacyControl JavaScript プロパティです。両方とも単一のビットを伝えます: この訪問者は個人情報の販売・共有をオプトアウトし、必須でないトラッキングを拒否します。技術仕様は globalprivacycontrol.github.io/gpc-spec にあります。

このシグナルは通常、プライバシー拡張機能（DuckDuckGo Privacy Essentials、Privacy Badger）またはデフォルトでプライバシー重視のブラウザ（Brave、Mullvad Browser、DuckDuckGo Browser）によってブラウザが設定します。Chrome — 2026 年中頃時点で全世界シェア約 65% — はネイティブ GPC サポートを持たず、コミットもしていません；Safari と Microsoft Edge も同様にネイティブサポートを欠きます；Firefox は privacy.globalprivacycontrol.enabled 設定の背後に組み込みサポートを持ちます。結果として、GPC は EU トラフィックの意味のあるが少数派のシェアに到達します — プライバシー意識の高いユーザーがツールを採用するにつれシェアは拡大しており、提案中の第 88b 条は技術標準が採択された時点で主要ブラウザに GPC 機能の提供を 要求 する予定です。2026 年 5 月 5 日に公開された査読済み研究は、GPC が EU の同意バナーを削減できると結論付けています — ただし部分的にのみ、そして EU 規制当局と立法者がシグナルを既存のデータ保護法にどうマッピングするかを明確化する意図的な手順を踏む場合に限ります。

GPC とは何か: カリフォルニア州法のもとでの拘束力のあるプライバシー設定、そして提案中の第 88b 条のもとでの推定的なプライバシー設定。これを順守するサイト運営者は訪問者に再度尋ねる必要はありません — 訪問者は既に回答しています。

GPC とは何ではないか: サイト運営者のより広範なコンプライアンス姿勢の代替ではありません。GPC の順守は、サイト運営者の GDPR 第 13 条の透明性義務、第 21 条の異議申し立て権エンドポイント、下流ベンダーとの第 28 条処理者契約、適用可能な場合の第 35 条 DPIA を排除しません。GPC は同意 / 拒否決定への 1 つの入力であり、GDPR の残りの仕組みは依然として適用されます。

GPC とは何ではないか、第 2 部: EU 管轄で自動的にオンになるものではありません。現行の GDPR の立場は、GPC は 拘束力のある同意撤回ではない — サイト運営者は順守することを選択できますし（プライバシー重視のアクセス解析ツールのほとんどはそうしています）、法的に強制されているわけではありません。提案中の第 88b 条は、技術標準採択の 6 か月後にそれを変更します。前を見据えるサイト運営者は、後のポリシースイッチを避けるため、今から GPC を順守するのがデフォルトです。

GPC 強制の 2 層

Statnive Live は GPC を 2 層で順守します — クライアントサイドとサーバーサイド。両方の層が異なる方法で失敗するため、両方とも重要です。

クライアントサイド短絡。 トラッカーはスクリプト初期化時に navigator.globalPrivacyControl === true をチェックします。プロパティが true に設定されており、AND サイト運営者がスクリプトタグの data-statnive-honour-gpc="1" 属性で GPC 順守を有効化している場合、トラッカーは no-op 関数に短絡します。トラッキングイベントは送信されません。サーバーへの往復はありません。データは訪問者のブラウザを離れません。

これは、最も摩擦の少ない GPC 実装を望むサイト運営者のためのプライバシー保護的なデフォルトです。サーバーラウンドトリップを節約し、訪問者の帯域幅を節約し、ブラウザ DevTools を持つ誰でも GPC レスポンスを監査可能にします（送信リクエストが発生しないため）。

サーバーサイド強制。 取り込みエンドポイントは、すべての受信リクエストで Sec-GPC: 1 ヘッダーをチェックします。サイトポリシーが consent.respect_gpc = true であり、ヘッダーが設定されていれば、訪問者識別子が計算される前にリクエストはドロップされます。拒否する訪問者に対して仮名レコードは作成されません — 後で削除すべきものがデータベースに存在しないのは、何も書き込まれなかったからです。

サーバーサイド層は、クライアントサイド層が見逃すケースをキャッチする多層防御です: サーバーサイドレンダリング経由で到達する訪問者（訪問者のマシン上でトラッカースクリプトが実行されない）、トラッカースクリプトが短絡できる前に拡張機能によってブロックされた訪問者、CLI HTTP クライアントを使用する訪問者、JavaScript GPC プロパティは存在しないが HTTP ヘッダーが設定されているブラウザ上の訪問者。

2 つの層は合成されます。クライアントサイド層はサイト運営者の優先経路で、サーバーサイド層はブラウザで何が起こったかに関係なくポリシーが順守されることの保証です。

なぜ「ハイブリッド」モードが存在するのか

consent-free 展開は最もシンプルなメンタルモデルです: バナーなし、Cookie なし、サーバーサイドのオーディエンス計測のみ。consent-required 展開はもう 1 つのシンプルなモデルです: 訪問者が受け入れるまでバナーがトラッカーをブロックします。どちらも一様な規制要件を持つサイトで機能します。

2026 年の現実的なサイトは混在した規制要件を持ちます。マーケティングページには同意なしのオーディエンス計測が必要；チェックアウトフローには CNIL Sheet 16 のオーディエンス計測カーブアウトがカバーしないコマースアトリビューションが必要；ログイン済みダッシュボードにはアクセス解析がまったく不要、ユーザーが既知の顧客だからです。

hybrid は規制要件が混在するサイト向けの同意モードです。パターン:

  • 訪問者がバナーと相互作用する前: 匿名集計オーディエンス計測が実行されます。Cookie レス、日次ローテーションソルト、ホスト名のみのリファラー、IP 切り捨て、User-Agent 最小化 — デフォルトで consent-free アーキテクチャ。
  • 訪問者が同意を受け入れた後: トラッカーはフルアトリビューションにアップグレードします。Cookie ID がブラウザに発行されます；訪問者単位のセッション継続性が保たれます；コマースイベントが捕捉されます；コンバージョンアトリビューションが流れます。
  • 訪問者が拒否した後（または受け入れた後に撤回した後）: トラッカーは匿名モードに戻ります。Cookie なし；訪問者単位の継続性なし。訪問者が以前に受け入れていた場合、既存の Cookie ID はサプレッションリスト経由でサーバー側で無効化されます。

これは Google が 2024 年 3 月に「Consent Mode v2」として展開したものと同じパターンですが、決定的な違いがあります: Statnive Live のハイブリッドモードは サーバー強制 であり、クライアント信頼ではありません。Google のパターンは、すべてのイベントに同意状態を示すパラメータを送信します；受信サーバーは正しい処理を適用すると信頼されます。Statnive Live のハイブリッドモードは、訪問者の同意に関するサーバー自身の記録に基づいて、取り込み層で同意状態を適用します。サーバーが権威的な同意記録を保持するため、ブラウザは同意が付与されたかどうかについて嘘をつけません。

サイト運営者の初日の負担は、consent-required よりも hybrid の方が低くなります。オーディエンス計測指標は関係なく流れます。バナーは、何らかのアトリビューションへのゲートではなく、より多くの アトリビューションへの経路になります。

トラッカー API

サイト運営者は、トラッカーが公開する 2 つの関数を呼び出すことで、自社の同意バナーを Statnive Live と統合します:

// Visitor accepts consent (typically from a banner's Accept button)
statnive.acceptConsent(csrfToken);

// Visitor withdraws consent (from the privacy policy's withdraw link)
statnive.withdrawConsent(csrfToken);

両方の関数は、サイト運営者のセッションから派生した CSRF トークンとともに /api/privacy/consent に POST します。サーバーは訪問者の同意状態を更新し、privacy.consent_given または privacy.consent_withdrawn 監査イベントを発行します。後続のトラッカーイベントは、サーバー側の取り込み層で新しい同意状態を使用します。

サイト運営者のバナーはサイト運営者の UI です。Statnive Live はバナーを提供しません — 数十の同意管理プラットフォームがあり、ほとんどのサイト運営者には好みのものがあります。統合面は 2 つの関数呼び出しと監査イベントストリームです。原文の文言、バナーの色、「Reject を Accept と同じくらい簡単に」の実装（CNIL は誤った実装で何度もサイト運営者に罰金を科しています）は、サイト運営者の責任です。

サードパーティ CMP（Cookiebot、OneTrust、Sourcepoint、Didomi）を使用するサイト運営者にとって、統合パターンは同じです: CMP の onAccept と onReject コールバックが statnive.acceptConsent() と statnive.withdrawConsent() を呼び出します。CMP はベンダーごとの同意 UI の管理を続け、Statnive Live の貢献はサーバー強制の状態です。

WordPress プラグインが分岐する場所

2 つの Statnive 製品の間で選択するサイト運営者にとって重要な、製品パリティに関するメモです。

Statnive Live（スタンドアロンアクセス解析サーバー）は 4 つの同意モードすべて — permissive、consent-free、consent-required、hybrid — と上記のサーバー強制同意ゲーティングを提供します。ハードルール検証付きの 11 管轄列挙が適用されます；GPC の 2 層強制が適用されます；4 モード × 11 管轄行列が完全な面です。

Statnive WordPress プラグイン は現在 2 つの同意モード — cookieless と disabled-until-consent — を提供しており、Statnive Live の consent-free と consent-required モードにほぼ対応します。プラグインはクライアント側で GPC と DNT を順守し、DSAR 登録のために WordPress Privacy API を尊重します。hybrid モードや完全な 11 管轄列挙は現在提供していません。

サイト運営者向けの判断ツリー:

  • 一様な規制要件を持つサイト（すべての面で同意なし、またはすべての面でバナーゲート）: WordPress プラグインの 2 モードで十分です。
  • 混在する規制要件を持つサイト（同意なしのマーケティングページ＋同意必須のチェックアウト、または EU ＋ 非 EU トラフィックの管轄別差異）: Statnive Live SaaS またはセルフホスト製品が適切な選択です。プラグインの範囲を WordPress 管理画面のページビューに、Statnive Live の範囲を公開フロントエンドにすれば、WordPress プラグインは同じサイト上で共存できます。

セルフホスト対プライベート EU SaaS の記事 と WP プラグイン対 Statnive Live 比較 がより広範な判断を詳しくカバーしています。本記事の対象である GPC とハイブリッド同意の具体については、Statnive Live が完全サポートを持つ製品です；WordPress プラグインはよりシンプルなサブセットを持ち、規制面もよりシンプルなサイト運営者向けの正しい選択です。

既存バナーからの移行経路

既に Cookie バナーを持っているサイト運営者 — 自作か CMP 経由か — が GPC 順守付きの hybrid モードに移行したい場合、実用的な移行シーケンス:

フェーズ 1（1 週目）: バナーを変更せずに GPC 順守を有効化する。 Statnive Live のスクリプトタグに data-statnive-honour-gpc="1" を追加；サイトポリシーで consent.respect_gpc = true を設定。バナーは非 GPC 訪問者に対して引き続き発火します；GPC 訪問者はバナーを見る前に no-op 化されます。これは無回帰の変更です — 以前バナー経由で拒否していた訪問者は引き続き拒否され、以前バナー経由で受け入れていた訪問者は引き続き受け入れられ、以前バナーを見ていた（おそらく拒否していた）GPC 訪問者は今、バナーがレンダリングされる前に短絡されます。

フェーズ 2（2-3 週目）: hybrid モードに切り替える。 サイトポリシーの consent_mode を consent-required から hybrid に更新。バナーと相互作用する前に匿名集計指標が収集され、訪問者が受け入れた後にフルアトリビューションにアップグレードされます。サイト運営者の初日のトラフィック可視性は跳ね上がります — 55.6% のバナー拒否税（Plausible の Cookie バナー研究 による）が、オーディエンス計測層についてほぼゼロに崩壊します。

フェーズ 3（3-4 週目）: サイト運営者のバナーをトラッカー API に配線する。 CMP の既存の onAccept コールバック（現在はサードパーティタグをオンにする）を、statnive.acceptConsent(csrfToken) を呼び出すものに置き換えます。バナー UX は訪問者にとって変わりません；サイト運営者の根本的なトラッキング機構がサーバー強制状態に遷移します。

フェーズ 4（4 週目以降）: バナーがゲートしていた Cookie を廃止する。 サイト運営者が同意フローがサーバー側で機能していることを確認したら、元のバナーがゲートしていたサードパーティ Cookie（広告ピクセル、リターゲティングタグ）をレビューして整理できます。同意なしに全面移行するサイト運営者にとって、これはバナーを完全に廃止するステップです（CNIL Sheet 16 と § 25 TDDDG の条件が累積的に満たされる場合）。コマースアトリビューションを維持するサイト運営者にとって、バナーは残りますが UX の重みのほとんどを失います。

移行は各ステップで可逆です。任意のフェーズで戻したいサイト運営者は、サイトポリシーの変更を元に戻せます；監査ログは、どのタイムスタンプにどのモードがアクティブだったかの同時並行的な証拠を保持します。

エンドツーエンドテストプラン

GPC が両方の層で順守され、ハイブリッドモードが正しく動作することを検証する実用的なテストプラン:

テスト 1: クライアントサイド短絡。

  1. navigator.globalPrivacyControl = true を設定するブラウザ拡張機能をインストール（DuckDuckGo Privacy Essentials、または Firefox の privacy.globalprivacycontrol.enabled 設定を有効化）。
  2. DevTools コンソールに navigator.globalPrivacyControl と入力してプロパティが設定されていることを確認；true を期待。
  3. サイト運営者のサイトを読み込む。
  4. DevTools → Network → /api/track でフィルター。
  5. 期待: トラッカーエンドポイントへの 送信リクエストがゼロ。トラッカーは短絡しています。

テスト 2: サーバーサイド強制。

  1. curl または任意の HTTP クライアントを使用して、サイト運営者のトラッカーエンドポイントに直接 POST: 
    curl -X POST https://app.statnive.live/api/track \
  -H 'Sec-GPC: 1' \
  -H 'Content-Type: application/json' \
  -d '{"site_id": "...", "page": "/test"}'
  2. 期待: X-Statnive-GPC-Honoured: 1 ヘッダー付きの HTTP 204。リクエストは受理されましたが、訪問者識別子が計算される前にイベントはドロップされました。
  3. サイト運営者の events_raw ClickHouse テーブルを検査。期待: テストページとタイムスタンプに一致する 行なし。

テスト 3: ハイブリッドモードの同意前匿名。

  1. GPC を無効化（拡張機能を削除；Firefox 設定をリセット）。
  2. クリーンプロファイルでサイト運営者のサイトを読み込む。
  3. バナーと相互作用しない。 2-3 ページを閲覧。
  4. テストセッションの events_raw を検査。期待: 行は存在しますが、cookie_id_hash は NULL で、visitor_signature は日次ローテーションのソルトから派生した値です。

テスト 4: ハイブリッドモードの同意後アップグレード。

  1. テスト 3 から続行。バナーを受け入れる。
  2. さらに 2-3 ページを閲覧。
  3. 同意後の行の events_raw を検査。期待: cookie_id_hash が現在入力されています（h: プレフィックス＋ SHA-256）、同意後の行で同じ値です。

テスト 5: ハイブリッドモードの撤回後復帰。

  1. テスト 4 から続行。同意を撤回（DevTools コンソールから statnive.withdrawConsent(csrfToken) を呼ぶ、またはサイト運営者のプライバシーポリシーの撤回リンクをクリック）。
  2. privacy.consent_withdrawn 監査イベントを検査。期待: 訪問者のシグネチャとタイムスタンプとともに発行されています。
  3. さらに 2-3 ページを閲覧。
  4. 撤回後の行の events_raw を検査。期待: cookie_id_hash は再び NULL；訪問者は匿名モードに戻ります。

テスト 6: 監査ログの完全性。

  1. セッション全体の監査ログを検査。
  2. 期待されるイベントの順序: privacy.consent_given（テスト 4）、privacy.consent_withdrawn（テスト 5）。オプトアウト、DSAR アクセス、DSAR 消去イベントは、このテストでは行使されていないため存在しません。

完全なテストプランは、1 つのブラウザセッションと 1 つの curl 呼び出しに収まります。一度実行してスクリーンショットを取得したサイト運営者は、査察または内部監査に必要な実証パックを手に入れます。

サイト運営者が得られるもの

実務上の成果:

  • 両層での GPC 順守 — クライアントサイド短絡が往復を回避し、サーバーサイド強制がクライアントサイド層が見逃すすべてをキャッチする多層防御です。
  • hybrid モード — 55.6% のバナー拒否税にほとんどの consent-required 展開が失うオーディエンス指標を回復しつつ、同意した訪問者向けのフルアトリビューション経路を保持します。
  • クライアント信頼ではなくサーバー強制の同意状態 — Google Consent Mode v2 パターンがさらすような「ブラウザが同意について嘘をつく」失敗モードを排除します。
  • 2 関数のトラッカー API — 任意のバナー（自作またはサードパーティ CMP）とクリーンに統合し、構造化された監査証跡を発行します。
  • 4 フェーズの可逆移行 — フラグデー切り替えなしでレガシーバナーから移行するサイト運営者向け。
  • 6 ステップのエンドツーエンドテストプラン — 実装が本番で機能することを検証します。

提供しないもの: 出荷準備の整ったバナー — それはサイト運営者の UI 選択です。サイトポリシーが GPC を順守する EU 管轄で、不本意な訪問者の GPC シグナルをオーバーライドする方法 — 設計上、サーバーサイド層はオーバーライド不可です。WordPress プラグインのハイブリッドモードとの互換性 — WordPress プラグインは現在ハイブリッドモードを提供していないためです（判断ツリーセクション がどの製品を使用すべきかをカバーします）。

やるべきこと・避けるべきこと

DoDon’t
両方の層を有効化する — スクリプトタグの data-statnive-honour-gpc="1" 経由のクライアントサイド ＋ サイトポリシーの consent.respect_gpc = true 経由のサーバーサイド。クライアントサイドでのみ GPC を順守する — プライバシー拡張機能は短絡が発火する前にトラッカーをブロックできます；サーバーサイド層が多層防御です。
規制要件が混在するサイトには hybrid モードをデフォルトにする — 同意前は匿名集計、同意後はフルアトリビューション、サーバー強制状態。マーケティングページにアトリビューションが不要であれば、サイト全体を consent-required にデフォルト設定する — 何のためでもなく訪問者可視性の 55.6% を失います。
GPC が順守された時に可視的に表示する（2026 年 1 月 1 日 CCPA § 7025(c)(6) アップデートに従う）。GPC を静かに処理し、訪問者が確認を必要としないと仮定する。CCPA は現在、可視的な表示を要求します。
statnive.acceptConsent() と statnive.withdrawConsent() を既存のバナー / CMP の onAccept / onReject コールバックに配線する。すべてのイベントでクライアント信頼の同意パラメータに依拠する（Google Consent Mode v2 パターン）。ブラウザは嘘をつけますが、サーバーの権威的な同意記録は嘘をつけません。
EU ＋ 米国トラフィックを持つサイトでは、管轄に関係なく consent.respect_gpc = true をデフォルトにする — CCPA と他の 11 米国州に加え、EU consent-free モードを満たします。GPC を米国専用として扱う。提案中の第 88b 条は、標準が採択された時点で EU 順守を推定的にする予定です；今順守することが前方互換性のある姿勢です。

結論

Global Privacy Control は、提案中の Digital Omnibus 第 88b 条 がコンプライアンス推定を付与する予定のブラウザレベル機構です。技術的パターンはシンプルです: 1 ビットのシグナルをサイト運営者のサーバーが取り込み時に順守します。アーキテクチャパターンはクライアント信頼ではなくサーバー強制です。移行パターンは可逆かつ 4 フェーズです。テストパターンは 1 つのブラウザセッションに収まります。

Statnive Live はこれらすべてをデフォルトで提供します。4 つの同意モード、2 層 GPC 順守、サーバー強制ハイブリッドパターン、2 関数のトラッカー API、DSAR 記事でカバーされた 8 つのプライバシー監査イベント、そしてそのすべてを行う ~2.0 KB minified / ~0.9 KB gzipped のファーストパーティトラッカー。

WordPress プラグインは、一様な規制姿勢と WordPress 形状の展開を持つサイト運営者にとって正しい選択です。Statnive Live は、規制要件が混在するか非 WordPress スタックを持つサイト運営者にとって正しい選択です。両方について、GPC シグナルは順守されます。

より広範な枠組みについては 2026 年 EU 同意なしアクセス解析プレイブック を参照してください。国別の差分については、CNIL Sheet 16 と § 25 TDDDG の記事を参照してください。EU 全体で GPC 順守を標準化する Digital Omnibus の第 88b 条のニュース解説については、Digital Omnibus 記事 を参照してください。同意状態と統合するデータ主体権利の領域については、DSAR 記事を参照してください。

本記事はプライバシーに関する調査資料であり、法的助言ではありません。 GPC はカリフォルニア州の CCPA のもとでの拘束力のあるプライバシーシグナルであり、提案中の Digital Omnibus 第 88b 条のもとでの推定的シグナルです；現行の EU 法のもとでは拘束力のある同意撤回ではありません。GPC を順守することを選択するサイト運営者は、上記の実装パターンに支えられた政策的選択としてそうします。すべての Statnive 顧客はデータ管理者であり続け、自身の設定および DPIA について責任を負います。公開前に必ず管轄の有資格弁護士と相互参照してください。

規制関連参照の状況 — 2026 年 5 月 13 日時点: globalprivacycontrol.github.io/gpc-spec の GPC 仕様；2026 年 1 月 1 日施行 CCPA 法令 — § 7025(c)(6) は GPC シグナルが順守されたことの可視的な表示を要求；CPPA は 2025 年 9 月に 2026 年規制パッケージを最終化；2026 年初時点で米国 12 州が GPC ／ユニバーサルオプトアウトシグナル認識を要求；2025 年 9 月にカリフォルニア / コロラド / コネチカット司法長官が協調的 GPC 執行スイープ；Digital Omnibus COM(2025) 837 final（2025 年 11 月 19 日の委員会提案）第 88b 条 — 2026 年 5 月 13 日時点で COM(2025) 837 に関する欧州議会本会議投票なし；2026 年 2 月 11 日 EDPB-EDPS 合同意見書 2/2026；ePrivacy 指令 2002/58/EC およびその各国国内化；EDPB Guidelines 2/2023 v2.0、2024 年 10 月 7 日（施行中）。

Statnive を無料で入手