Cloudflare Zaraz同意統合ガイド：2026年のエッジにおけるサーバーサイドタグ管理
Cloudflare Zarazは以前のタグ管理製品とは根本的に異なります。前提は段階的ではなく構造的です。Google Analytics、Meta Pixel、Hotjar、Mixpanel、LinkedIn InsightといったベンダーのJavaScriptを訪問者のブラウザに読み込む代わりに、Zarazはそれらの統合をCloudflare Workers内で実行します。Workers はエッジで動作し、出版社のオリジンの前に配置されます。ブラウザが見るのは小さなZarazランタイム一つだけで、ベンダーツールはサーバーサイドで動きます。このアーキテクチャ上の選択は同意に対して複合的な結果をもたらします。ほとんどのベンダーCookieがそもそも設定されないため、Cookie サーフェスが大幅に縮小します。ほとんどのベンダーJavaScriptがブラウザコンテキストで実行されないため、フィンガープリントのサーフェスも縮小します。そして同意の適用ポイントは、<script>タグの山を制御するJavaScriptバナーから、どのZaraz統合が起動してどのペイロードを受け取るかを決定するサーバーサイドの判断へと移行します。ZarazをCMPに正しく接続した出版社は、より小さなコンプライアンスサーフェス、高速なページ、明確な監査証跡を得られます。一方、ZarazをGoogle Tag Managerの高速版として扱い同意接続をスキップした出版社は、標準的なブラウザベース監査からは見えない活動が多いため発見しにくい規制上のリスクを抱えることになります。
Zarazがエッジで実際に行うこと
ZarazはCloudflare Workers内で実行されるサーバーサイドタグマネージャーです。訪問者がページを読み込むと、出版社のHTMLには小さなZaraz初期化スクリプト（通常数キロバイト）が含まれており、ブラウザから構造化されたイベントペイロード（ページビュー、クリック、カスタムイベント）を収集し、出版社自身のドメイン上のCloudflareエンドポイントにPOSTします。WorkerはそのペイロードをReceiptし、設定されたZarazツールを実行します。Google Analytics 4統合はMeasurement Protocolヒットを送信し、Meta Pixel統合はConversions APIイベントを送信し、Mixpanel統合はHTTP API呼び出しを送信します。ベンダーのサードパーティJavaScriptはブラウザには読み込まれず、ベンダーCookieは設定されないか、Workerを通じてCloudflareのファーストパーティドメイン経由で書き込まれ、ベンダーは出版社のZaraz設定が明示的に転送するデータのみを受け取ります。
これがアーキテクチャ上の価値提案です。また、同意の状況がクライアントサイドタグマネージャーとは異なる理由でもあります。従来の設定では、同意の問いはベンダーJavaScriptが読み込まれるかどうかです。Zarazでは、JavaScriptはどちらの場合も読み込まれません。問いはサーバーサイドのペイロードが送信されるか抑制されるか、そしてペイロードにベンダーがユーザーを追跡するために必要な識別子が含まれるかどうかになります。両方の問いにはZaraz Consent APIに明確に定義された答えがあり、出版社の仕事はそれらを正しくマッピングすることです。
Zaraz Consent APIとクライアントサイドCMPとの違い
Zarazには組み込みの同意モジュール（Zaraz Consent Tools）が搭載されており、訪問者ごとの同意状態を維持し、設定されたツールの起動を制御します。この状態は小さなJavaScript APIを通じて公開されます。zaraz.consent.set({ analytics: true, marketing: false })でユーザーの選択を記録し、zaraz.consent.get('analytics')で読み取り、zaraz.consent.getAll()で全マップを取得し、zaraz.consent.modal()で同意UIを開き、zaraz.consent.onModalShownや関連イベントのイベントリスナーでカスタムUI動作を実装します。ダッシュボードの各Zarazツールには一つ以上の目的IDが設定されており、Workerは訪問者の同意状態で関連する目的が許可されている場合にのみツールを実行します。
統合の選択は、Zarazの組み込み同意モーダルを使用するか、Zarazを外部CMPに接続するかです。組み込みモーダルが最も簡単な方法です。Consent Toolsを有効にし、目的を定義し、各ツールに適切な目的を設定して展開します。外部CMPのルートは、Cookiebot、OneTrust、Usercentrics、またはカスタムCMPに既に標準化している組織に適した選択です。この場合Zarazはユーザーがバナーを操作する際にCMPがzaraz.consent.set()を呼び出す形でCMPの下流で動作します。どちらのルートも同じ適用ポイントに到達します。Workerは各ツール実行前に同意状態を確認し、目的が許可されていないツールは単純に実行されません。
IAB TCFサポートと地域の規制
ZarazはIAB TCF v2サポートを2023年に追加し、それ以来フレームワークの進化を追ってきました。TCFベースの広告パートナーシップの下でEEAとUKで事業を展開する出版社の場合、出版社がオプトインすると統合によってTCF同意文字列がZarazの目的状態に自動的に変換されます。TCF対象外の地域では、出版社はカスタム目的（通常はanalytics、marketing、personalization、functional）を関連するZarazツールに直接マッピングします。同じWorkerが両方を適用するため、1つのZaraz設定でTCFを通じたEEA訪問者とカスタムマーケティング目的ゲートを通じたカリフォルニア州の訪問者の両方を、2つの並列パイプラインなしで対応できます。
ZarazがGDPRとePrivacyの状況を変える理由
GDPR、ePrivacy、CCPAの下での法的立場はサーバーサイド実行によって免除されるわけではありません。法的根拠は輸送手段ではなくデータを追います。しかし実際のコンプライアンスサーフェスは変わります。三つの変化が重要です。
- Cookieサーフェスの縮小。ベンダーJavaScriptがブラウザで実行されないため、ほとんどのベンダーCookieは書き込まれません。残るCookieは通常Zaraz自身のセッション識別子と出版社が意図的に伝播させたファーストパーティ識別子です。バナーが制御しなければならない非必須Cookieサーフェスは大幅に小さくなります。典型的なクライアントサイドスタックが生成する十数個に対し、時には1〜2個だけになることもあります。
- 第三者転送の開示が変わる。WorkerがサーバートサーバーCallを通じてベンダーにデータを送信するため、訪問者のブラウザからのデータパスはCloudflareのエッジを経由し、そこから設定されたベンダーへと続きます。プライバシーノーティスにはこれを反映させる必要があります。CloudflareはデータProcessorであり、各ZarazツールはDownstream受領者です。しかし、出版社が転送内容を完全に制御できるため、開示は多くの点で同等のクライアントサイドパスよりも明確です。
- 監査証跡の一元化。すべてのベンダーイベントがWorkerを通過するため、出版社は同意状態、イベントペイロード、Downstream受領者をログに記録できる単一のポイントを持ちます。クエリ可能な同意ログを期待する規制当局は、クライアントサイドタグの散在よりもZarazでより明確な答えを得られます。
機能する統合パターン
参照デプロイには4つの可動部分があります。最初はページ上のZaraz初期化で、Cloudflareのプロキシを通じて出版社のドメインから読み込まれます。2番目は組み込みConsent Toolsモーダル、またはユーザーが選択を行う際にzaraz.consent.set()を呼び出す外部CMPです。3番目は各ツールを適切な目的にマッピングするZarazダッシュボード設定です。分析ツールはanalyticsに、広告ツールはmarketingに、セッションリプレイツールはより厳格なfunctionalまたはresearchに、第三者転送依存ツールはcross-border-transferにマッピングします（出版社のプライバシーノーティスがそれを別の選択肢として公開している場合）。4番目は、規制当局の要求に応じて同意記録を提出できるよう、Cloudflare Analytics、Logpushによる出版社のデータレイクへの出力、またはクエリ可能なストアに同意決定を書き込むカスタムWorkerによるサーバーサイドログです。
検証ステップはどの同意統合にも適用される4つのチェックシーケンスと同じですが、Zaraz固有のポイントがあります。バナーは表示されているが選択が行われていないクリーンなブラウザセッションでは、訪問者のブラウザからどのベンダードメインへのリクエストもゼロ、非必須Cookieもゼロであるべきです。これはクライアントサイドスタックよりZarazで確認しやすく、サードパーティリクエストの不在は設定済みの例外ではなくデフォルトです。拒否訪問はその状態を維持する必要があります。承認訪問では、ユーザーが同意したイベントのみを運ぶZarazエンドポイントのPOSTが生成され、WorkerログにDownstreamツールの起動が表示される必要があります。撤回によってその後のWorkerツール実行が即座に停止し、Zarazが設定したCookieが期限切れになり、設定されたDownstreamベンダーへの適切な削除またはオプトアウトシグナルが送信される必要があります。
Zarazがまだ慎重な扱いを必要とする部分
Zarazは考える必要性を排除するアーキテクチャによる同意ソリューションではありません。3つの領域で意図的な対処が必要です。クリックして読み込む埋め込み（YouTube、Twitter、Instagram、TikTok動画）は、Zarazが現在埋め込み動画iframeをプロキシしていないため、consent-firstデプロイが使用するのと同じプレースホルダーパターンが必要です。ファーストパーティ目的のためにブラウザで設定することを選択したクライアントサイド識別子（ログイン済みユーザーID、セッショントークン、A/Bテストバケット）は同意境界の出版社側に残り、独自のゲーティングロジックが必要です。プライバシーノーティスにはサーバーサイド転送モデルを正確に記述する必要があります。CloudflareのProcessorとしての役割、データを処理するWorkersの地理的場所（Cloudflareエッジは複数のリージョンで動作し、訪問者のトラフィックが自分の地域ではないリージョンで処理される場合があります）を含めなければなりません。これらに対処することで、2026年のZarazデプロイはタグ管理製品から出版社が運用できる最もクリーンな同意アーキテクチャの一つに変わります。Cookieサーフェスの縮小、サードパーティリクエストの削減、一元化された適用、そして規制当局が実際に読める監査証跡を備えたアーキテクチャです。