GA4 や Google 広告の数値が、社内のアクセス解析ツールや MA の数値と合わない。広告予算を増やしているのに「コンバージョン経路がわからない」と現場から声が上がる。広告ブロッカー 対策 計測 の議論はここから始まります。uBlock Origin や Brave Browser のフィルタリストは、`gtag/js`・`gtm.js`・`collect`・`analytics.js` といった解析系リクエストを名前ベースで遮断するため、従来の JavaScript タグ実装のままでは構造的に防げません。本稿では Google タグ ゲートウェイ（GTG） で自社ドメイン経由の first-party 配信に切り替え、ブロッカーの遮断網をすり抜ける手順を、つまずきポイントと検証コマンドつきで実装担当者向けに解説します。
💡 この記事の要点（30秒で）
主要4ブロッカー（uBlock Origin / AdBlock / Brave / Ghostery）は、ドメイン名と URL パターンの両方でブロックする。`google-analytics.com` のような既知ドメインは確実に落ちる
GTG は計測タグを 自社ドメイン配下のサブパス（例: `data.example.com/collect`）で配信するため、フィルタリストの「ドメイン一致」「URL パターン一致」の両方を回避できる
影響度は GA4 セッション数とサーバアクセスログの差分 から逆算できる。差分が 10% を超えるなら導入優先度は高い
実装は7ステップ・1〜2日工数。Cloudflare Workers なら 50 行程度のスクリプトで動き始める
つまずきやすいのは「配信パスの命名」「Cookie 属性」「Brave Aggressive Mode への割り切り」の3点。事前に把握すれば事故は防げる
広告ブロッカー対策GTGの実装でつまずく3つの典型ポイント
このガイドの読了後、読者は GTG（Google タグ ゲートウェイ）を自社サイトに7ステップで導入し、広告ブロッカー由来の計測欠損の大半を回復するための手順 を獲得します。所要工数の目安は、エッジ構築 1〜2日・タグ差し替え半日・検証半日の合計 2〜3日。実装担当者・マーケテック PM・CTO 直下のエンジニアを想定読者にしています。
GTG 実装は手順自体は素直ですが、現場で 9割の担当者が同じ3か所 でつまずきます。先に把握しておくと事故が減ります。
つまずき1：配信パスの命名でフィルタに学習される。`/collect` `/gtm.js` をそのまま自社ドメイン配下に置く実装が散見されますが、EasyPrivacy は URL パスも明示的に遮断対象 にしています。`data.example.com/collect` ではブロックされる可能性が残るため、`/sdk/m.js` `/e/p` のように 既存フィルタが知らない命名 にする必要があります。
つまずき2：Cookie の SameSite・ドメイン属性。GTG 経由のレスポンスで Cookie を first-party として確実に発行するには、`SameSite=Lax` か `None; Secure` の選択、`Domain=.example.com` の付与、ITP 7日ルールへの対処方針を事前に決めておく必要があります。後から変更すると既存ユーザーの計測継続性が崩れます。
つまずき3：Brave Aggressive Mode と Pi-hole への「割り切り」設計。GTG は遮断率の大半を消せますが、ユーザーが明示的に強化したブロッカーは原理的に回避できません。経営層に「100% 回復」と説明してしまうと運用フェーズで信頼を失います。最初から「90% 以上を取り戻す施策」と位置づける のが正解です。
このあとは、GTG の仕組み（Part 2）、7ステップ実装手順（Part 3）、独力 vs 専門家伴走の判断軸（Part 4）の順に進みます。
広告ブロッカーが計測タグを落とす3層構造と GTG が回避できる仕組み
実装に入る前に、なぜ GTG が 広告ブロッカー 対策 計測 の解になるのか、技術的な前提知識を整理します。ここを曖昧なまま実装すると、Step 6 の検証フェーズで原因切り分けができなくなります。
ブロッカーが計測タグを落とす3層
広告ブロッカーがリクエストを遮断する経路は 3層 に分かれます。
第1層：DNS 解決の遮断。Brave の Shields や Pi-hole などは `www.google-analytics.com` や `www.googletagmanager.com` を DNS の段階で書き換えます。ここで落ちると、ブラウザは JavaScript の `fetch` すら走らせません。
第2層：URL パターンマッチによる遮断。uBlock Origin と AdBlock が使う EasyList / EasyPrivacy フィルタには、`||google-analytics.com^`、`||googletagmanager.com^`、`/gtag/js`、`/gtm.js`、`/collect` といった数千行のルールが含まれます。同一ドメインでも `/analytics/collect` のようなパスがあれば遮断対象です。これが「サブドメイン CNAME だけでは回避できない」と言われる根拠です。
第3層：DOM ベースの cosmetic filtering。GTM 経由で挿入される一部のリマーケティングタグ（Meta Pixel、X Pixel など）が DOM 監視で落とされるケースがあります。これは GTG の守備範囲外で、別レイヤの設計が必要です。
GTG が回避できる3つの仕組み
GTG（Google タグ ゲートウェイ） は、GA4・Google 広告・GTM の計測リクエストを、自社が所有する任意のドメイン経由でプロキシ配信 する仕組みです。Cloudflare Workers、AWS CloudFront Functions、Google Cloud Run、さくらのクラウドなどのエッジ／サーバレスで構築します。
1. ドメイン名の一致を回避する。`www.google-analytics.com/collect` ではなく、`data.example.com/c` のような自社ドメイン配下にリクエストを送るため、EasyList の `||google-analytics.com^` ルールに引っかかりません。ドメイン名そのものがフィルタの主軸 なので、これだけで遮断率の大半を消せます。
2. URL パスを自由に設計できる。`/gtag/js` や `/collect` は EasyPrivacy が個別に指定しているパスです。GTG では `/sdk/m.js` や `/e/p` のように、フィルタが学習していない命名で配信できます。フィルタ側の追加学習にはタイムラグがあり、自社ドメイン配下の独自パスはルール化されにくい構造です。
3. Cookie が first-party になる。Apple の ITP（Intelligent Tracking Prevention）と Firefox の ETP は、third-party Cookie を 7日 ないし 24時間で削除します。GTG 経由のレスポンスは自社ドメイン発行の first-party Cookie になるため、ITP の制限を受けません。Safari ユーザーの計測精度が改善するのはこの副次効果です。
GTG が万能ではない3点
• Brave の Aggressive Mode や Pi-hole の上流 DNS 遮断で、`gtag.js` 自体の元配信ドメインがブロックされている場合、自社ドメイン経由でも初期スクリプトのロードに失敗するパターンが残る
• 拡張機能型の Privacy Badger は、ヒューリスティックに「トラッキングっぽい挙動」を学習するため、自社ドメインでも長期運用後に遮断される可能性がある
• GTG はあくまで 計測タグの配信回避 が主目的。広告タグ自体（`doubleclick.net` のクリエイティブ表示）は別レイヤで、混同しないこと
🏢 CRIEN実証 ── CRIEN代表 佐藤淳一（IT歴23年・技術顧問20社以上）の現場感覚として、広告代理店のレポートと事業会社の社内 KPI が大きく食い違う案件 を見ていくと、媒体評価ロジックよりも前段の「計測そのものの欠損」を疑うべきケースが少なくありません。GTG はその欠損を構造的に減らす手段として、現時点で最も投資対効果が読みやすい打ち手だと考えています。
ステップバイステップで進める GTG 実装7手順
ここからは 広告ブロッカー 対策 計測 の実装7ステップを、各ステップの完了条件・所要時間・つまずきポイントとセットで解説します。
Step 1: 現状の影響度を計測する（所要 1日）
GTG 導入の前に、自社サイトでどれだけブロッカー影響があるか を定量化します。指標は3つ。
• GA4 のセッション数 vs サーバアクセスログ（CDN含む）の差分
• GSC のクリック数 vs GA4 のオーガニックセッションの差分
• Cloudflare / CloudFront のアクセスログから `gtm.js` `collect` を含むリクエストの成功率
完了条件：3指標を Excel/スプレッドシートに整理し、差分の絶対値と割合を経営層・代理店と共有できる状態。差分が 10% 以上あれば GTG の費用対効果は出やすいと判断できます。
つまずきポイント：CDN ログの保持期間が短いと過去比較ができません。先に Cloudflare の Logpush などで 30日以上の保持 を確保してから測定を開始します。
Step 2: 配信ドメインを決定する（所要 半日）
`data.example.com` `m.example.com` `t.example.com` などの 計測専用サブドメイン を1つ用意します。メインドメイン直下ではなくサブドメイン にする理由は、将来的にエッジルーティングを切り替える際の影響範囲を限定するためです。
DNS は Cloudflare に集約し、TTL は 300秒 に設定して切り替えに備えます。つまずきポイント：サブドメインの命名で `analytics` `tracking` `metric` などフィルタが学習しやすい単語を使うと、将来的に遮断対象化されるリスクがあります。汎用名（`data` `m` `t` `s` 等） が安全策です。
Step 3: エッジ／サーバレスを構築する（所要 1-2日）
主要な構成パターンの比較は以下のとおりです。
| 構成 | 工数目安 | 推奨ケース |
|---|---|---|
| Cloudflare Workers | 1日 | 既に Cloudflare 利用中・最短実装 |
| AWS CloudFront Functions | 1.5日 | AWS インフラ統一したい |
| Google Cloud Run | 2日 | GCP 一元管理 |
| さくらのクラウド | 2-3日 | 国内データ主権重視 |
最も簡単なのは Cloudflare Workers。50行程度の Worker スクリプトで `data.example.com/sdk/m.js` を `googletagmanager.com/gtm.js` に内部プロキシし、Cookie のドメインを書き換えて返すだけです。
完了条件：`curl https://data.example.com/sdk/m.js` が 200 を返し、body に `googletagmanager` 由来のスクリプトが含まれている状態。
つまずきポイント：プロキシ先のレスポンスヘッダ `Set-Cookie` の `Domain` 属性を書き換え忘れると、Cookie が発行されません。Worker 側で 明示的な Cookie 書き換え処理 が必須です。
Step 4: 計測タグを差し替える（所要 半日）
サイト側の `<script src="https://www.googletagmanager.com/gtm.js?id=GTM-XXXX">` を、`<script src="https://data.example.com/sdk/m.js?id=GTM-XXXX">` に置換します。GTM のコンテナ ID やイベント設計は変更不要。既存の GA4 / 広告タグ設定はそのまま流用 できるのが GTG の運用上の強みです。
つまずきポイント：CMS や複数の LP に直書きされたタグの取りこぼし。差し替えは grep で全文検索 してから一括置換する手順を踏みます。
Step 5: GTM 内のサーバサイド設定を調整する（所要 1日）
サーバサイド GTM を併用する場合は、エンドポイントを `data.example.com/g/collect` に変更。Enhanced Conversions を Google 広告で使っている場合は、ハッシュ化済みの顧客データ送信先も自社ドメイン経由に切り替えます。Consent Mode v2 を運用している場合、`consent` パラメータの伝搬経路に変更がないかも確認します。
Step 6: 3ブラウザで検証する（所要 半日）
検証は 3パターンのブラウザ で実施します。
• Brave Browser（Shields 標準モード）
• Chrome + uBlock Origin（EasyList + EasyPrivacy 有効）
• Safari（ITP 有効、third-party Cookie ブロック）
DevTools の Network タブで `data.example.com` へのリクエストが 200 を返すこと、GA4 リアルタイムレポートにヒットが反映されることを確認します。
参考検証コマンド：
つまずきポイント：Brave Aggressive Mode はデフォルトで有効になっていない設定です。標準モードで通れば実運用上 OK と割り切ります。
Step 7: 効果計測とチューニング（所要 継続）
導入後 2週間 で GA4 のセッション数増加率、Google 広告の CV 数増加率、CPA 改善率を計測。期待値より下回る場合は、配信パスの命名見直し（フィルタ学習されている可能性）や、Cookie の SameSite 属性調整 で追い込みます。
導入後の改善余地は別記事で深掘りしています。 GA4 計測ロス 2026 ガイド と iOS17 ITP 計測戦略 も並行して参照すると、ITP・ETP 起因の欠損まで一貫して整理できます。
独力で進めるか専門家伴走を入れるか — GTG実装の判断軸
7ステップ自体は素直ですが、実務では 「思っていたより詰まる箇所」 があります。CRIEN が顧問先で遭遇してきた典型は以下の3つです。
罠1：配信パス名の選定で2か月止まる。マーケ・情シス・法務間で「どの命名なら社内ガバナンス上 OK か」の合意形成に時間が溶けるケース。先に命名規約とサブドメイン運用ルールを決め切る のが回避策です。
罠2：社内政治によるブロック。「広告代理店の数字に手を入れてよいのか」「データ主権の観点で海外エッジを使ってよいのか」が論点化して止まるケース。経営層への説明資料を Step 1 と並行で用意 し、効果試算と法令準拠状況をセットで提示します。
罠3：エッジ運用コストの読み違い。アクセス急増時の Worker / Functions のリクエスト課金、ログ転送コスト、Cookie 関連の障害対応工数を見積もりに入れ忘れ、運用フェーズで予算超過するケース。月次の運用コスト枠を独立に確保 しておきます。
独力 vs 専門家伴走の判断軸
| 項目 | 独力で進める | 専門家伴走を入れる |
|---|---|---|
| 社内に GTM 設計の実装経験者がいる | 進められる | 必須ではない |
| Cloudflare Workers / AWS / GCP いずれかの運用実績がある | 進められる | 必須ではない |
| 業種が一般的（フィルタ学習が穏やか） | 進められる | 必須ではない |
| 代理店との数値乖離が経営課題化している | やや困難 | 推奨 |
| 法務・情シスの合意形成に時間がかかる組織 | やや困難 | 推奨 |
| 業種が IT・ガジェット・金融など遮断率高め | やや困難 | 推奨 |
実装パートだけなら独力で完遂可能なケースは多数あります。一方で 罠1〜3 の社内調整・運用設計 までを一貫させたい場合は、伴走を入れた方が結果として早く着地します。判断軸の自己診断には Google タグ ゲートウェイ 導入支援 のページが参考になります。
🏢 CRIEN実証 ── CRIEN代表 佐藤淳一の技術顧問20社以上の経験では、GTG のような マーケテック実装は「技術より社内合意」で止まる ことが大半でした。だからこそ伴走の価値は、コードを書くことよりも、経営層・代理店・情シス・法務の翻訳役として 意思決定の摩擦を減らす ところにあると考えています。独力でも完遂は十分可能なので、組織の状況に応じて選択してください。
明日から始める3アクションと、詰まった時の選択肢
GTG 導入で得られる最終的な価値は、広告予算配分の最適化 と CV 経路の可視化 です。読んだだけで終わると価値は出ません。最初の一歩として、明日からの3アクションを置きます。
アクション1：差分を測る。GA4 のセッション数とサーバ／CDN アクセスログを直近30日で並べ、差分の絶対値と割合を出します。これだけで社内議論の土俵が変わります。
アクション2：配信サブドメインの候補を3つ決める。`data.example.com` `m.example.com` `t.example.com` などの中から、社内命名規約に通せる候補を3つピックアップして法務・情シスに事前打診します。Step 2 の停滞要因を先回りで潰します。
アクション3：Cloudflare Workers のサンプル Worker を1本動かす。検証用ドメインでよいので、`googletagmanager.com/gtm.js` をプロキシする最小 Worker を1本動かし、`curl` で 200 が返る状態を作ります。実装のハードル感覚がここで掴めます。
GTG の主要ステップを総覧したい場合は Google タグ ゲートウェイ 概要 を、設定途中の詰まりに当たったら ITP 起因の計測欠損を扱う iOS17 ITP 計測戦略 を併読すると、原因切り分けが早くなります。
FAQ（よくある質問）
Q1. 広告ブロッカーは全部回避できますか？
完全回避は不可能です。Brave の Aggressive Mode、Pi-hole の上流 DNS 遮断、Privacy Badger のヒューリスティック学習など、自社ドメイン配信でも遮断されるケースは残ります。ただし、現実の運用上は GTG 導入だけで遮断の大半を解消できるため、費用対効果は十分です。完璧主義に走らず、回避できる大多数を取りに行く設計が現実的です。
Q2. 影響度の調べ方は？
3つの差分 を見ます。第一に GA4 のセッション数とサーバアクセスログの差分、第二に GSC のクリック数と GA4 のオーガニックセッションの差分、第三に Cloudflare などの CDN アクセスログから `gtm.js` `collect` リクエストの成功率を集計する方法です。差分が 10% 以上 あれば導入優先度は高いと判断できます。
Q3. GTG 導入後も回避できないケースは？
3パターンあります。一つ目は Brave の Aggressive Mode（ユーザーが明示的に有効化）、二つ目は 企業ネットワーク側の DNS フィルタ（情シスが Pi-hole 系を運用しているケース）、三つ目は ブラウザ拡張型の Privacy Badger が長期運用で学習してしまうケースです。比率は限定的で、ビジネス影響は許容範囲に収まります。
Q4. 効果が出るまでの期間は？
実装完了後 24時間以内 に GA4 のセッション数増加が見え始め、2週間 で広告 CV 計測の精度改善が確認できるのが一般的です。Google 広告の自動入札への学習反映には 3〜4週間 かかるため、CPA 改善などの最終 KPI 効果は 1〜2ヶ月後 から本格化します。早期に判断したい場合は、初週の GA4 セッション増加率を中間指標として使うのがセオリーです。
Q5. 検証方法は？
3ブラウザでの検証が標準です。Brave Browser（Shields 標準モード）、Chrome + uBlock Origin（EasyList + EasyPrivacy 有効）、Safari（ITP 有効）の3環境で DevTools の Network タブを開き、自社ドメインへの計測リクエストが 200 で返ること、GA4 リアルタイムレポートに即座に反映されることを確認します。CI/CD に組み込みたい場合は Playwright での自動検証スクリプト化も有効です。
