Google タグ ゲートウェイ（GTG）の導入相談が増えるなか、最初の関門はいつも CDN 選定です。「自社は AWS CloudFront を使っているが GTG は動くのか」「Cloudflare 一択と聞くが GCP に寄せた構成では難しいのか」「マルチクラウドだがどこに置くべきか」――こうした問いに、ベンダー資料の断片情報だけでは答えが出ません。本稿は GTG CDN比較 をテーマに、Cloudflare／AWS CloudFront／GCP の3CDN を技術要件・費用構造・運用容易性の観点で並列比較し、BtoB マーケ責任者と代理店技術者が判断軸として使える形に整理します。
💡 この記事の要点（30秒で）
結論先出し：Cloudflare Workers が第一選択。レイテンシ・コスト・実装容易性の3軸で総合優位。
ただし AWS／GCP の既存資産が大きい企業は無理に乗り換えない。各社の統合構成でも GTG は実用範囲で動作する。
AWS は CloudFront Functions 単体では機能不足で、Lambda@Edge との2層構成が現実解。
GCP は Cloud CDN ＋ Cloud Run が定番。GA4／BigQuery 連携の親和性は3CDN中もっとも高い。
ツール選定後に詰まるのは「配信・分析・運用が縦割り」になるパターン。組織設計を伴走で詰めるのが鍵。
Cloudflare vs AWS vs GCP：GTG 用途の結論先出し
GTG 用途で CDN を選ぶ際の判断は、極論すれば3つのプロファイルに収束します。
| プロファイル | 推奨 CDN | 理由 |
|---|---|---|
| 性能・コスト最優先、CDN を新規選定 | Cloudflare Workers | 単一 Worker で配信・加工・転送が完結、Cold Start ほぼゼロ |
| AWS フル活用、CloudFront 既存運用あり | AWS CloudFront ＋ Lambda@Edge | 既存 IAM／WAF／CloudWatch 資産を活かす |
| GCP データ基盤、BigQuery 分析が中心 | GCP Cloud CDN ＋ Cloud Run | GA4／BigQuery／Looker への直結 |
「Cloudflare 一択論」は半分正しく半分間違いです。エッジ実行機能の成熟度ではたしかに Cloudflare Workers が頭一つ抜けています。しかし、CDN を一つ変えるコストは技術費用だけでは測れません。既存の運用フロー、監視基盤、ログ集約、IAM ポリシー、そして社内の習熟度――この合計が CDN 切替の総コストです。だから本稿の比較軸は「性能・費用」だけでなく、既存資産との整合性と 運用容易性 を含めた多軸で構成しています。
評価軸は次の7つです。
1. p95 タグ配信レイテンシ
2. PV 500万規模での月額コスト目安
3. 実装期間
4. エッジ実行機能の充足度
5. 既存資産との整合性
6. GA4／BigQuery 連携親和性
7. 運用容易性（デプロイ・監視・障害切り分け）
これらをすべて踏まえた選定マトリクスは Part 2 の末尾に提示します。
7軸で見る Cloudflare／AWS／GCP の本質的な違い
GTG は技術的にはシンプルですが、CDN ごとに「できること」と「やり方」がかなり違います。まずエッジコンピューティング機能の素地から確認します。
| 機能 | Cloudflare Workers | AWS CloudFront Functions | AWS Lambda@Edge | GCP Cloud Run (＋Cloud CDN) |
|---|---|---|---|---|
| 実行時間上限 | 50ms (CPU) | 1ms | 5秒 | 60分 |
| メモリ | 128MB | 2MB | 最大10GB | 最大32GB |
| 言語 | JS／TS／Rust／WASM | JS のみ | Node.js／Python | 任意 |
| Cookie 書き換え | ◎ | △（制約あり） | ◎ | ◎ |
| サブリクエスト | ◎ (fetch) | × | ◎ | ◎ |
| KV／状態保持 | ◎ (Workers KV／D1) | × | △ | ◎ (Firestore等) |
| デプロイ容易性 | ◎ (wrangler) | ○ | △ | ○ |
| Cold Start | ほぼゼロ | ほぼゼロ | あり (100-500ms) | あり (調整可) |
Cloudflare Workers：単一レイヤーで完結する設計が効く
GTG が要求する処理は、ざっくり「タグ配信のヘッダー書き換え」「計測ビーコン受信」「Cookie 操作」「サーバーサイド GTM への転送」の4つです。Cloudflare Workers はこのすべてを 単一の Worker で処理できます。fetch サブリクエストで GTM サーバーコンテナへ転送し、Workers KV に設定値を置き、wrangler コマンド一発でデプロイする。この構成のシンプルさは、運用負荷の低さに直結します。
AWS CloudFront Functions ＋ Lambda@Edge：2層構成が宿命
AWS で同じことをやろうとすると、CloudFront Functions の機能制約（実行時間 1ms、サブリクエスト不可、KV なし）にぶつかります。結果として、軽量ヘッダー操作は CloudFront Functions、計測ビーコン加工と GTM 転送は Lambda@Edge という 2層構成 が定型解になります。Lambda@Edge には Cold Start（100-500ms）があり、Provisioned Concurrency で打ち消すと費用がさらに膨らみます。
GCP Cloud CDN ＋ Cloud Run：データ基盤への直結が利く
GCP は「エッジ実行」というより「オリジン近接でコンテナを動かす」発想です。Cloud CDN 自体にはエッジ実行機能がないため、Cloud Run でロジックを実装し、Cloud CDN でファーストパーティ配信を担保します。p95 レイテンシは Cloudflare に一歩譲りますが、GA4 → BigQuery → Looker のデータパイプラインに GTG 計測ログがそのまま乗る親和性は他2社にない強みです。
選定マトリクス（CRIEN による定性評価）
| 評価軸 | Cloudflare | AWS | GCP |
|---|---|---|---|
| p95 レイテンシ | ◎ | ○ | △ |
| 月額コスト感（500万PV） | ◎ | △ | ○ |
| 実装容易性 | ◎ 2-5営業日 | △ 5-10営業日 | ○ 4-8営業日 |
| 既存資産との整合 | △ 独立CDN | ◎ AWS統合 | ◎ GCP統合 |
| GA4／BigQuery 親和性 | ○ | ○ | ◎ |
| 運用容易性 | ◎ 単一Worker | △ 2層構成 | ○ Cloud Run |
| 可用性（SLA） | 100% | 99.99% | 99.95% |
注：レイテンシ・コストは弊社が複数案件で観測した相対傾向に基づく定性評価です。実際の数値は構成・トラフィック分布・リージョン選定で変動します。
🏢 CRIEN実証 ── 代表 佐藤淳一は IT 歴23年、技術顧問20社以上のなかで Cloudflare／AWS／GCP すべての本番運用を経験してきました。経験則として言えるのは、「CDN そのものの性能差より、組織がそのCDNを使いこなせるかの差のほうがはるかに大きい」ということです。Cloudflare Workers が技術的には最短ルートでも、AWS 中心のチームに無理矢理導入すると IAM 設計と監視基盤の二重化で運用が崩れます。CDN 比較は「速いか・安いか」だけで終わらせず、必ず既存運用フローとの噛み合わせで判断するべきです。
決めた後に詰まる3パターンと、30/60/90日定着プラン
CDN を選び終えて「さあ実装」と動き出してから、現場で詰まるパターンは大きく3つに分かれます。GTG は配信・計測・分析・広告運用が交差する領域なので、技術選定が終わってからが本番です。
パターン①：ツールだけ入れて運用設計が空白
CDN とエッジコードはデプロイしたが、タグの追加・変更フロー が定まっていないケース。GTM コンテナの変更を誰がレビューし、サーバーサイドコンテナをいつデプロイし、GA4 のイベント定義をどこで管理するか。GTG は「タグ運用のガバナンス」をセットで設計しないと、3か月後に整合性が崩れます。
パターン②：経営層が ROI を見られない
GTG は計測精度の改善が主目的なので、効果は 広告 ROAS や CV データの信頼度 に間接的に現れます。経営層が「導入したのに数字が変わらない」と感じるのは、KPI 設計のレイヤーがずれているからです。改善 KPI を「タグ取得率」「サーバーサイド計測比率」「GA4 イベント取得率」などの中間指標で設計し、月次でレビューする運用が要ります。
パターン③：CDN 戦争が組織内で起きる
「インフラチームは AWS、マーケチームは Cloudflare を勧めるベンダーと話している、データチームは GCP を推す」――この三つ巴は実際によく起きます。誰の意見が正しいかではなく、どの軸で意思決定するかの合意形成が先です。決定権者と評価軸を最初に確定させないと、PoC を3つ走らせて全部中途半端で終わります。
30/60/90日定着プラン（GTG 全社展開の基本形）
| 期間 | フォーカス | 主要タスク |
|---|---|---|
| 〜30日 | 配信設計 | サブドメイン設計／CDN 選定／PoC 環境構築／GTM サーバーコンテナ設計 |
| 31〜60日 | 計測設計 | 既存タグ棚卸し／GA4 イベント再定義／サーバーサイド計測比率の目標化 |
| 61〜90日 | 運用定着 | 月次レビュー定例化／変更管理フロー文書化／KPI ダッシュボード整備 |
自社実行 vs 伴走支援（正直比較）
| 項目 | 自社実行 | CRIEN 伴走 |
|---|---|---|
| 初期費用 | 抑えられる | 月額契約あり |
| 立ち上げ速度 | 社内学習に依存（1-3か月） | 2-10営業日で本番化 |
| CDN 選定の客観性 | 社内派閥に左右されがち | 3CDN 中立評価 |
| GTM サーバーコンテナ設計 | 公式ドキュメントから自走 | 既存実装パターンを再利用 |
| 計測 KPI 設計 | 走りながら整える | 初月から運用設計込み |
| 経営層への説明資料 | 都度自作 | 投資稟議向けテンプレ提供 |
自社実行が悪いわけではありません。社内に Cloudflare／AWS／GCP のどれかを使いこなすエンジニアと、計測設計を回せるアナリストが両方いるなら、外部支援なしでも回ります。逆に「インフラと計測の両方を引き受けられる人材がいない」場合は、ここで自走すると 90日後に運用が宙に浮きます。
結局のところ、ツールより組織設計：最短7日で動き出す
3CDN の比較を一通り見たうえで、最後に強調しておきたいのは 「ツールの差より、組織の運用設計の差のほうがインパクトが大きい」 という事実です。Cloudflare を選んでも運用が空白なら計測精度は戻りませんし、AWS のままでも組織が整っていれば GTG は十分機能します。CDN 選定は通過点であって、ゴールではありません。
CDN 選定で迷っている段階の方が、貴社で GTG を最短7日で動かすためのステップは以下です。
1. Day 1-2：既存 CDN ／既存 GTM 構成／計測要件のヒアリング、CDN 選定方針を1ページで合意
2. Day 3-4：サブドメイン設計・DNS・証明書の準備、PoC 環境構築
3. Day 5-6：エッジコード／Lambda／Cloud Run の実装、GTM サーバーコンテナとの接続テスト
4. Day 7：本番リリース、計測ログの初期確認、運用ドキュメント引き渡し
弊社 CRIEN は3CDN すべての本番実装経験を持ち、まるごとAI顧問・自社開発・代理店パートナー支援の3軸で GTG 導入をサポートしています。CDN 選定で迷っているフェーズや、社内で意見が割れているフェーズこそ、外部の中立な判断軸を入れる価値が高い段階です。具体的なサービス内容は Google タグ ゲートウェイ 導入支援 をご参照ください。
FAQ（よくある質問）
GTG のために CDN を乗り換えるべきですか？
基本的に乗り換えは不要です。AWS／GCP でも GTG は実装可能で、既存資産との整合性を犠牲にしてまで Cloudflare に寄せるメリットは限定的です。ただし、CDN を新規選定するフェーズで GTG を視野に入れているなら、Cloudflare Workers を第一候補にすることをおすすめします。性能・コスト・実装容易性のバランスが3CDN中もっとも良いためです。
複数 CDN を併用できますか？
可能です。たとえば「タグ配信は Cloudflare Workers、サイト本体は AWS CloudFront」という構成は実用上問題なく動きます。サブドメインを分けるだけで分離できるため、GTG だけ Cloudflare に切り出すパターンは比較的多く採用されています。ただし、ログ集約と障害切り分けが2系統になるため、運用設計を事前に詰める必要があります。マルチCDN は弊社 CRIEN でも複数案件で実装経験があります。
費用感がもっとも軽いのはどの CDN ですか？
定性的には Cloudflare がもっとも軽くなる傾向にあります。料金体系がリクエスト単価ではなく定額＋少額従量のため、トラフィック増加時のコスト予測が立てやすいのも実務上の利点です。AWS は Lambda@Edge の従量と Cold Start 対策費用が積み上がり、GCP は Cloud Run のコンテナ稼働費が中心になります。大規模 PV（月数億）になると各 CDN のディスカウント交渉次第で逆転することもあるため、見積もり段階でベンダー直接交渉を推奨します。
パフォーマンスが一番良いのはどれですか？
p95 タグ配信レイテンシで見ると Cloudflare Workers が頭一つ抜けます。エッジロケーション数（300超）と Workers の Cold Start ほぼゼロが効いています。AWS は Lambda@Edge の Cold Start、GCP は Cloud Run のリクエスト到達経路が長くなることが、Cloudflare との差の主要因です。ただし日本国内ユーザーが大半の場合、3CDN とも東京リージョン経由で差が縮まり、体感ではほぼ同等のケースもあります。
運用がもっとも楽なのはどれですか？
Cloudflare Workers です。単一の Worker で配信・加工・転送が完結するため、デプロイも wrangler 一発で済みます。AWS は CloudFront Functions ＋ Lambda@Edge の2層構成になり、IAM／WAF／CloudWatch の設定が増え、運用負荷が3社中もっとも高くなります。GCP は Cloud Run のコンテナ運用に慣れているチームなら中間。チームのスキルセットと既存運用フローに合わせて選ぶのが現実的です。
