「Cloudflare を使っているなら、Google タグ ゲートウェイ（GTG）は自社で設定できるはず」――そう判断して着手したものの、サブドメインの CNAME 設定で詰まる、Workers のスクリプトをどう書けばよいか公式ドキュメントだけでは分からない、Tag Assistant がエラーを返す、といった相談が春先から続いています。Google タグ ゲートウェイ 設定方法は、Cloudflare の上であれば物理的には半日で終わる作業ですが、設計判断のミスが 1 つ混ざるだけで数週間溶けます。本稿は読むだけで終わるガイドではなく、読了後すぐに `dig` を叩き、Workers のエディタを開き、GTM コンテナを公開するところまで一気に進めるための実装書です。対象は、Cloudflare 管理権限と GTM 編集権限の両方が手元にある実装担当者・PM・CTO 直下のエンジニアを想定しています。
💡 この記事の要点（30秒で）
Cloudflare 上の GTG 実装で詰まる箇所は「サブドメイン命名」「Workers の本文書き換え」「GTM コンテナ公開漏れ」の 3 点に集約される
Workers / Page Rules / Bulk Redirect は役割が異なり、GTG には Workers 一択で他に選択肢はない
CNAME は `tag.example.com` を推奨。`gtm.` や `analytics.` は ITP・広告ブロッカーで遮断対象になっている
実作業は半日、ただし設計判断の手戻りで自社実装は数週間に膨らみやすい
自社で進めるか伴走を入れるかは「Workers 経験」「GTM 管理権限」「GA4 計測設計の理解」の 3 軸で判断する
このガイドが目指すゴールと、読むだけで終わらせないための前提
最初に、本ガイドの完了状態を定義します。読了直後に作業に入り、最短で半日、設計判断を含めて 1〜2 営業日後には次の状態に到達することを目指します。
• `tag.example.com` がブラウザから 200 を返し、`gtag/js` がプロキシ経由で配信されている
• レスポンス本文中の `www.googletagmanager.com` 参照がすべて自社サブドメインに置換されている
• GTM コンテナ側で「カスタムドメインを使用する」が公開済みになっている
• GA4 DebugView でリアルタイムイベントが流入し、本番反映前と同水準以上のイベント数を維持している
• Cookie の Domain 属性が `.example.com` で first-party 化されている
逆に、本ガイドが想定していない読者層も明示しておきます。Cloudflare のダッシュボードを触ったことがない、GTM の管理権限を持たない、GA4 の計測設計を別チームに丸投げしている――いずれかに当てはまる場合、本ガイドを読むだけでは実装は完了しません。手を動かす実装担当者と、GTM・GA4 を握っているマーケ担当者の二者を巻き込んだうえで着手するのが現実的です。
ハウツー記事は読むだけで満足しがちですが、GTG は「読了 → 着手 → 詰まる → 検索 → 別記事 → さらに詰まる」というループに入りやすい題材です。今回はこの全体図を最初に開示しておきます。
5 ステップの中で実装ミスが致命傷になりやすいのは Step 2 と Step 3 です。特に Step 3 の「保存しただけで公開していない」は、Tag Assistant 上は正常に見えるため発見が遅れます。以降の章で、ステップごとに完了条件・所要時間・つまずきポイントを順に開示していきます。
Cloudflare 上で GTG 実装が詰まる 3 つの構造的ポイント
Cloudflare を利用しながら GTG の自社実装に着手し、途中で止まってしまうケースには共通の構造があります。CRIEN 代表 佐藤淳一が AI 顧問・技術顧問として 20 社以上の Web 計測改善に関わってきた経験から見ると、つまずきポイントは綺麗に 3 つに分かれます。手を動かす前にこの 3 点だけは頭に入れてから着手してください。
1 つ目はサブドメインの設計判断。Google の公式ガイドには「first-party サブドメインを用意してください」としか書かれておらず、命名規則の推奨が明示されていません。toC EC のように iOS Safari 経由の流入が多いサイトで `gtm.brand.jp` のような命名を採用すると、iOS の ITP（Intelligent Tracking Prevention）と一部広告ブロッカーが `gtm` というサブドメイン文字列をシグナルとして検知し、せっかく first-party 化したリクエストが遮断される事象が起きます。命名を間違えただけで GTG を導入した意味が半減します。
2 つ目は Cloudflare のどの機能で実装するかの選定。Cloudflare 上で URL を書き換える方法は Workers、Page Rules、Bulk Redirect、Transform Rules と複数あり、それぞれ HTTP リクエスト/レスポンス処理の段階が異なります。GTG が要求しているのは「`googletagmanager.com/gtag/js` へのリクエストを自社サブドメイン経由でプロキシし、レスポンス本文中の追加ドメイン参照も書き換える」という処理ですが、これを Page Rules で組もうとすると本文書き換えができず、Bulk Redirect では Cookie の first-party 化ができません。Workers 以外の選択肢は存在しません。
3 つ目は GTM コンテナ側の設定変更漏れ。GTG はインフラ側の設定だけでは完結せず、GTM の管理画面で「サーバーコンテナ URL」または「カスタムドメイン」設定を更新する必要があります。ここを忘れたまま検証に進むと、Tag Assistant 上は問題なく動いて見えるのに、実際の本番トラフィックでは旧来の `googletagmanager.com` 直叩きに戻ってしまうという、最も発見が遅れるパターンに陥ります。
🏢 CRIEN実証 ── CRIEN 代表 佐藤淳一が顧問先の Web 計測改善を支援する中で繰り返し見てきたのは、GA4 と広告管理画面の CV 数の乖離が経営判断を歪めるパターン。GTG の自社ドメイン配信はこの乖離を構造的に縮める仕組みであり、Cloudflare を既に使っているならインフラ側の変更も最小で済むため、第一選択として推奨できる構成。一方で「公式ドキュメントの粒度では現場の判断ができない」という相談がこの題材では特に多く、設計判断のレビューさえ通れば、実作業そのものは数時間で片付くことが多い印象。
Cloudflare における GTG の仕組みと Workers が必須となる理由
GTG の本質は「Google が運営するドメイン（googletagmanager.com / google-analytics.com）へのサードパーティリクエストを、自社ドメインのサブドメイン経由でプロキシして first-party 化する」という、技術的にはシンプルな仕組みです。Cloudflare で実装する場合、リクエストフローは次のようになります。
Workers / Page Rules / Bulk Redirect の選択肢を表で整理します。
| 機能 | 用途 | GTG 対応可否 | 理由 |
|---|---|---|---|
| Workers | リクエスト/レスポンス全体の任意改変 | ◎ | 本文書き換え・Cookie 加工・条件分岐がすべて可能 |
| Page Rules | URL 単位の forwarding / cache 設定 | × | レスポンス本文を書き換える機能を持たない |
| Bulk Redirect | 大量 URL の一括リダイレクト | × | 301/302 を返すだけで proxy にならず、Cookie の first-party 化が不可 |
| Transform Rules | HTTP ヘッダの書き換え | △ | ヘッダのみ可能、本文不可のため GTG には不十分 |
結論として GTG Cloudflare 構成は Workers 一択です。Workers Free プラン（10 万リクエスト/日）で開始可能ですが、月間 PV が 100 万を超える場合は Workers Paid プラン（$5/月、1000 万リクエスト込み）への切り替えを最初から想定しておいたほうが運用が安定します。
DNS 設定（CNAME レコード）の正しい書き方は次の通りです。Cloudflare ダッシュボードの DNS タブで、Type を `CNAME`、Name を `tag`、Target を Workers のルートドメインではなく 任意の名前解決可能なホスト（例: 自社の `www.example.com`）で構いません――この点が公式ドキュメントで触れられておらず混乱の元になります。Workers の Route 設定（`tag.example.com/*`）が優先されるため、CNAME の Target は名前解決可能であれば実体は何でも構いません。プロキシ状態（オレンジ雲）は必ず ON にしてください。
サブドメイン命名規則は `tag.yourdomain.com` を強く推奨します。前章で触れた通り、`gtm.`・`analytics.`・`tracking.`・`pixel.` は ITP およびメジャーな広告ブロッカー（uBlock Origin、AdGuard）のフィルタリストに含まれており、計測精度が落ちます。`tag.` または `t.` のように汎用的な命名であれば、現状のフィルタリストでは遮断対象になっていません。
Cloudflare で GTG を導入する 5 ステップ実装手順
ここからが本題の GTG 導入手順です。Cloudflare 管理権限と GTM 編集権限の両方が手元にある前提で、5 ステップに分けて進めます。各ステップに完了条件・所要時間・つまずきポイントを併記しているので、進捗管理にそのまま使えます。
Step 1: Cloudflare ダッシュボードでサブドメイン作成（所要 10 分）
Cloudflare の対象ゾーンを開き、DNS タブから新規レコードを追加します。
• Type: `CNAME`
• Name: `tag`
• Target: 任意の名前解決可能なホスト（例：自社の `www.example.com` で構いません）
• Proxy status: Proxied（オレンジ雲 ON）
• TTL: Auto
完了条件：レコード保存後、`dig tag.example.com` で Cloudflare の Anycast IP（104.x または 172.x 系）が返ってくること。つまずきポイントは「オレンジ雲を OFF のまま保存」。OFF だと Workers が発火せず、Step 2 以降がすべて空振りになります。
Step 2: Cloudflare Workers での書き換えスクリプト（所要 30 分）
Workers タブから「Create application」→「Create Worker」を選択。スクリプトの骨格は以下の通りです（実運用では環境変数化・エラーハンドリング追加を推奨）。
保存後、Triggers タブから Route を `tag.example.com/*` で登録します。Zone は対象ドメインを選択。完了条件：ブラウザで `https://tag.example.com/gtag/js?id=G-XXXX` を直接開き、JavaScript が 200 で返ること、本文中に `www.googletagmanager.com` が含まれていないこと。つまずきポイントは「Route の登録漏れ」と「`replaceAll` の対象漏れ」。`google-analytics.com` 系のドメイン参照を見落とすと一部イベントが旧経路で飛びます。
Step 3: GTM コンテナの gtag.js URL 書き換え（所要 10 分）
GTM 管理画面 → 該当コンテナ → 管理 → コンテナの設定で、「カスタムドメインを使用する」をオンにし、`tag.example.com` を入力。サーバーサイドタグを併用している場合は、サーバーコンテナの URL も同時に更新してください。この設定変更後、必ずコンテナをプレビュー → 公開の順で反映させます。公開を忘れると本番に変更が出ません。
完了条件：公開バージョンが新しい番号でデプロイされ、プレビューモードで `tag.example.com` 経由の配信が確認できること。つまずきポイントは前述の「保存しただけで公開していない」。実装担当とマーケ担当が別人の場合に最も発生します。
Step 4: Tag Assistant での検証（所要 15 分）
Chrome 拡張の Tag Assistant Legacy または Tag Assistant Companion を有効化し、対象サイトを開きます。Network タブで以下を確認します。
• `tag.example.com/gtag/js?id=G-XXXX` が 200 で返ること
• レスポンス本文を検索し、`www.googletagmanager.com` の文字列が 残っていないこと
• Set-Cookie ヘッダの Domain 属性が `.example.com` または `tag.example.com` になっていること
完了条件：上記 3 点すべてクリア。つまずきポイントは「Cookie の Domain 属性がデフォルトのまま」。Cookie 加工処理を Workers 側で明示していないと、ブラウザによっては third-party 扱いに戻ります。
Step 5: GA4 DebugView での確認（所要 20 分 + 48 時間モニタリング）
GA4 管理画面 → 設定 → DebugView を開き、検証端末で `?_dbg=1` パラメータ付きで対象サイトに訪問。リアルタイムでイベントが流入することを確認します。流入していれば、計測経路の first-party 化が完了しています。本番反映後 48 時間以内に、計測イベント数が実装前と同水準以上を維持しているか必ず確認してください。Apple 端末からのイベント取得率が改善していれば成功です。
完了条件：本番反映から 48 時間、リアルタイムレポートで対象イベント（`page_view` / `conversion` 系）が前週同曜日比で同水準以上。つまずきポイントは「サンプルサイズが足りない時間帯に切り戻し判断をしてしまう」。深夜帯のイベント数で判断すると統計的にノイズに振り回されます。判断は日中の主要トラフィック帯で行ってください。
実装にあたって、Workers の設計レビューや GTM コンテナ側の整合性チェックを外部の目で入れたい場合は、 Google タグ ゲートウェイ 導入支援 の枠組みで CRIEN への相談も選択肢になります。
自社実装で踏みやすい 3 つの罠と、伴走を入れるかの判断軸
5 ステップを開示しましたが、現場では別軸のつまずきも発生します。実装作業自体ではなく、組織・運用設計レイヤーで起きる「3 つの罠」を共有します。
罠 1：サブドメイン命名の社内合意が取れず 2 週間停滞
`tag.` を推奨しているのに、社内のインフラチームから「サブドメイン命名規則は `gtm-prod.` で揃えてある」と差し戻されるパターン。命名規則の社内ルールを優先するか、計測精度を優先するかの判断は経営マターになりがちで、稟議で 2 週間以上溶けます。対処法は、Step 0 として「命名規則の例外申請」を実装着手前に出しておくこと。ITP と広告ブロッカーの仕様書を添えると通りやすくなります。
罠 2：Workers Free プランの上限超過で深夜に停止
10 万リクエスト/日は、月間 PV 30 万程度のサイトでは余裕ですが、キャンペーン期間中に PV が跳ねると一気に上限を超えます。上限超過すると Workers が止まり、`tag.example.com` 経由のリクエストが全滅、GA4 のデータが欠損します。対処法は、本番反映と同時に Workers Paid プラン（$5/月）に切り替えること。月 $5 でリクエスト上限 1000 万件まで上がるため、コスト的に迷う理由がありません。
罠 3：GA4 とのイベント名整合が崩れ、コンバージョン定義が壊れる
Workers でレスポンス本文を書き換える際、`google-analytics.com` も置換対象にすると、まれに GA4 側のイベント命名規約と齟齬が出るケースがあります。Enhanced Conversions や Consent Mode v2 を併用している場合は特に注意が必要で、GA4 のコンバージョン定義の再確認が必須です。対処法は、Step 5 の DebugView 確認時に、主要コンバージョンイベントの `event_name` と `event_params` をスクリーンショットで保存し、実装前後で差分を取ること。
伴走 vs 独力の判断軸を整理した比較表を置きます。
| 観点 | 独力で完遂可能な条件 | 伴走を入れたほうがよい条件 |
|---|---|---|
| Cloudflare Workers 経験 | 過去に Worker を本番運用した経験あり | 触ったことがない／触り始めたばかり |
| GTM 管理権限 | 実装担当者が GTM 編集・公開権限を保有 | マーケ部門に握られていて公開タイミングが調整必要 |
| GA4 計測設計の理解 | イベント設計とコンバージョン定義を自分で書ける | 設計を別チームに委託しており構造を把握していない |
| 切り戻し判断 | 障害時に 1 時間以内に Worker 無効化判断ができる | 障害時の意思決定者が不在になりやすい |
| 法務・プライバシー | Cookie 同意管理を自社で整備済み | Consent Mode v2 / プライバシーポリシーが未整備 |
3 つ以上で「伴走を入れたほうがよい条件」に該当する場合は、独力で進める前に外部の目を入れたほうが結果的に早くなります。CRIEN では Cloudflare の Workers 設計レビュー、GTM コンテナの公開フロー整備、GA4 コンバージョン再設計までを単発相談から請けています。顧問契約への移行は完全に任意で、相談単発でクローズする案件も少なくありません。
明日から動き出すための 3 アクション
ここまで読んだ方の 9 割は「あとでやる」になり、実際に手を動かすのは 1 割です。読了から行動への落差を埋めるため、今日中に着手できる 3 アクションに絞ります。
アクション 1：Cloudflare で `tag.{自社ドメイン}` の CNAME を 10 分で作成する
Step 1 の作業はリスクゼロです。CNAME を 1 本足すだけで、Workers の Route を設定するまでは何も起きません。先にレコードだけ作って `dig` で疎通確認しておくと、Step 2 以降のスピードが段違いに上がります。
アクション 2：GTM コンテナの「カスタムドメインを使用する」設定画面を開いて確認する
Step 3 の画面を実機で開いておくと、「マーケ担当者の公開権限が必要だった」という発見が初日に出ます。これだけで罠 1 と罠 3 を回避できる確率が上がります。
アクション 3：本記事をブックマークし、Step 2 の Workers スクリプトをコピペして自社ドメイン名に置換しておく
スクリプト自体をローカルのエディタに貼って、`tag.example.com` 部分だけ自社ドメインに書き換えて保存。これで実作業時に思考停止で貼り付けるだけになります。
GTG は仕組みとしては枯れた技術の組み合わせですが、現場の判断ポイントが多く、ハウツー記事を読むだけでは越えられない壁が確実にあります。実装に着手して詰まった時点で外部の目を入れたい場合、CRIEN は AI 顧問・技術顧問として 20 社以上の Web 計測改善・データ基盤整備に関与した経験から、Cloudflare Workers の設計レビュー、GTM の公開フロー整備、GA4 のコンバージョン再設計まで横断で対応します。代表 佐藤淳一が直接レビューに入る体制で、単発相談から顧問契約まで関与度を選べる構成です。
FAQ（よくある質問）
Cloudflare無料プランでも導入できますか？
可能です。Cloudflare Free プランでも DNS 管理と Workers Free（10 万リクエスト/日）が利用できるため、月間 PV が 30 万程度までのサイトであれば無料枠で完結します。それ以上のトラフィックがある場合は Workers Paid プラン（$5/月、1000 万リクエスト込み）への切り替えを推奨します。なお、Cloudflare の Web Analytics や Bot Management などのオプションは GTG とは独立しており、必須ではありません。
Workers以外の方法はありますか？
Cloudflare の機能内では Workers 一択です。Page Rules は本文書き換えができず、Bulk Redirect は単なるリダイレクトのため Cookie の first-party 化が不可能、Transform Rules はヘッダのみ対応で本文には触れられません。他クラウドであれば AWS CloudFront Functions / Lambda@Edge、GCP Cloud CDN + Cloud Run などが選択肢になりますが、Cloudflare 利用中の企業がわざわざ他クラウドに切り替えるメリットはほぼありません。
設定後にGA4データが消えることはありますか？
設定手順を順守すれば消えません。ただし「GTM のカスタムドメイン設定を公開せず保存だけで止めた」「Workers の Route 登録漏れで一部リクエストが旧経路のまま」というケースで、計測イベントが半減した事例があります。本番反映後 48 時間は GA4 のリアルタイムレポートと DebugView を毎日確認し、実装前のイベント数を下回らないかをモニタリングしてください。下回った場合は即座に Workers を一時停止して切り戻し可能です。
既存のCloudflareルールと競合しませんか？
`tag.example.com/*` の Route と既存の Page Rules / Workers Routes は、Cloudflare 上で優先順位が明確に定義されているため、サブドメインを新規追加する形であれば既存ルールと競合しません。ただし、ルートドメイン `example.com/*` 全体に作用する Workers が既に動いている場合は、`tag.` サブドメインに対する処理を除外する分岐を追加する必要があります。CRIEN への相談時には現状の Cloudflare 設定を共有いただければ干渉箇所を事前に洗い出します。
SSL証明書はそのまま使えますか？
そのまま使えます。Cloudflare の Universal SSL がワイルドカード相当でサブドメインを自動的にカバーするため、`tag.example.com` の証明書を別途取得する必要はありません。Cloudflare で SSL/TLS モードを「Full」または「Full (strict)」に設定していれば、Workers 経由のレスポンスもすべて HTTPS で配信されます。Origin 証明書を独自運用している場合のみ、サブドメインの追加発行が必要な場合があります。
出典・参考
• Google「タグ プラットフォーム」公式ドキュメント
• Google「サーバーサイド タグ設定」公式ドキュメント
• Google タグ マネージャー ヘルプ
• Cloudflare「Workers」公式ドキュメント
• Cloudflare「Zaraz」公式ドキュメント
• MDN「SameSite cookies」
• Apple WebKit「Tracking Prevention」
