久しぶりの投稿となります、高橋栞です。
GA4はUAとはもはや別ツールと言ってよいほど機能が進化しており、その変化を追い続けています。
最近、プライバシー保護の話をよく耳にするようになりました。Webサイトの利用者としてはポジティブに感じつつ、デジタルマーケティングに携わる者としては頭が痛い話です。
プライバシー保護の動きや影響について、GAを利用している方は理解しておく必要があるとはいえ、結局のところ具体的に何をどうしたらよいかまで考えていくのはなかなか難しいですよね。
プライバシー保護の動き全体についてはとても一記事には納められないので、今回はここ最近でGoogleが力を入れて取り組んでいるトラッキングブロック機能の対策として、2026年2月時点でのGoogle タグ ゲートウェイについて検証していきます。
広告主様向けの Google タグ ゲートウェイ（GTG）とは
Google タグ ゲートウェイってなに？
Google タグ ゲートウェイ（GTG）は、Google タグやGoogle タグ マネージャー（GTM）といったスクリプトの配信と、Googleアナリティクス等の測定データの送信を、Googleのサーバーではなく独自のファーストパーティ ドメインの環境を経由して行う仕組みです。
GTGがリリースされた当初は「ファーストパーティ モード」という名称でした。
「ファーストパーティ モード」という名称の方が仕組みをイメージしやすいかもしれません。
GTG未導入の計測は、下図のようにGoogleのサーバー（サードパーティ ドメインの環境）を経由してデータの受け渡しをしています。
GTGを導入すると、下図のように自社ドメインの環境を経由してデータの受け渡しができるようになり、サードパーティ ドメインへの依存度を低減できるようになります。
Google タグ ゲートウェイを導入するとどうなるの？
ここまで、GTGが「自社ドメインの環境を経由して計測できるようにする仕組み」という概要をお伝えしましたが、ファーストパーティ ドメインを利用することの何がよいのかご紹介します。
Googleが公式で案内しているメリットは以下の3点です。
- コンバージョンの測定の精度を高める: 広告主向け Google タグ ゲートウェイは、コンバージョン データをウェブサイト独自のサーバー経由で転送することで、コンバージョン データの精度を高め、入札、キャンペーンの最適化、広告費用対効果を改善します。
- 詳細なキャンペーン インサイトを得る: キャンペーンのパフォーマンスとアトリビューションに関する詳細なインサイトを得ることで、カスタマー ジャーニーを深く理解し、費用対効果を高める戦略を特定することができます。
- デフォルトでプライバシー保護を強化: 広告主向け Google タグ ゲートウェイで設定されるタグは、まもなくデフォルトで Confidential Computing に対応するようになります。これにより、データを収集し処理する方法に関してセキュリティと透明性が向上します。
公式ヘルプ：広告主向け Google タグ ゲートウェイでコンバージョンの測定と広告のパフォーマンスを向上 - Google 広告 ヘルプ
上記3点が案内されていますが、最大のメリットはブラウザの機能や広告ブロッカーによるトラッキングのブロックを回避できる点です。
これにより、コンバージョンの測定の精度を高め、詳細なキャンペーン インサイトを得ることが可能になります。
このメリットについて、昨今のプライバシー保護の流れとともに紹介します。
昨今ではプライバシー保護を目的として、ブラウザの機能や広告ブロッカーによりWebサイトのトラッキングを制限・防止する動きがみられています。
特にApple社が2023年9月にリリースしたSafari 17以降のバージョンでは、プライベートブラウズを利用するとWebサイトのトラッキングをブロックする機能が追加されました。
公式ドキュメント：Safari 17 Release Notes | Apple Developer Documentation
実際にSafari 17以降のバージョンで検証したところ、GA4の計測や広告タグの配信がブロックされるだけでなく、GTMの読み込みまでもがブロックされていました。
GTMはトラッキングではなくタグの管理・配信を目的としたツールですが、Googleのサーバー（サードパーティ ドメインの環境）を経由するため、厳しくブロックされてしまうようです。
このようなプライバシー保護の動きによってGAの計測ができないケースが増えている事態に対応するために、GTGという機能が生まれました。
また、プライバシー保護の動きにはCookieの利用についての制限などもあります。Cookieの利用制限に対応するGA4の機能に同意モード（Consent mode）があります。
同意モードについては今回説明は割愛しますが、下記の記事で紹介しているのでこちらもぜひチェックしてください！
GTGを導入すると、ファーストパーティ ドメインを経由した計測が可能になるため、トラッキングのブロックが適用されなくなるケースがあります。
実際にGTGを導入してSafari 17以降のプライベートブラウズで動作確認をしたところ、無事にGTMが読み込まれGA4の計測を行うことができました。
つまり、GTGを導入する最大のメリットは、ブラウザの機能や広告ブロッカーによるトラッキングのブロックを回避できることです。※GTGの実際の効果については後述します。
プライバシー保護の動きとそれに対応するトラッキングの技術はいたちごっこのようですが、少なくとも現時点ではGTGでSafariのプライベートブラウズによるブロックに対応することができます。
Googleによると、GTGを導入した場合シグナルが 11% 向上した（Google タグの読み込み回数が増加した）と発表しています。
独自のドメインからタグを配信することで、測定シグナルの精度とレジリエンスを大幅に高めることができます。これは、パフォーマンスを向上させるためにすべてのマーケターが行うべき重要なアクションです。広告主向け Google タグ ゲートウェイを設定した広告主は、シグナルが 11% 向上しています。
公式ヘルプ：広告主向け Google タグ ゲートウェイでコンバージョンの測定と広告のパフォーマンスを向上 - Google 広告 ヘルプ
設定方法とデバッグのポイント
3つの導入方式
GTGの導入方式にはウェブサーバー、ロードバランサ、コンテンツ配信ネットワーク（CDN）を利用した3つがあります。
各導入方式と特徴は下表のとおりです。自社の環境に合った方式を選択しましょう。
| サーバーサイド タグ設定（sGTM） | ロードバランサ | コンテンツ配信ネットワーク（CDN） | |
|---|---|---|---|
| 概要 | サーバーサイド タグ設定を使用する | ロードバランサ（Cloud Load Balancingなど）を使用する | CDN（Cloudflare、Akamaiなど）を使用する |
| メリット | ・Google社以外のタグにも適用できる ・Cookieがサーバーサイドで発行されるようになる ・サーバーサイド タグ設定を導入済みの場合は導入までの障壁が低い |
・ロードバランサを導入済みの場合は、導入までの障壁が低い | ・CDNを導入済みの場合は、導入までの障壁が低い ※特にCloudflareやAkamaiはGTG統合機能があるため導入までの障壁が低い ・CloudflareやAkamaiの場合はウェブサイトのタグの修正が不要 |
| デメリット | ・ウェブサイトのタグの修正が必要 ・サーバーコンテナの障害時にタグが動作しない |
・ウェブサイトのタグの修正が必要 ・ロードバランサの障害時にタグが動作しない |
・CDNが未導入の場合は導入の障壁が高い ・CloudflareやAkamai以外のCDNを利用している場合は手動設定が必要 |
| ユースケース | ・既にサーバーサイド タグ設定を導入済の場合 ・Google社以外のタグも対応したい場合 |
・既にロードバランサを導入済の場合 | ・既にCDNを導入済みの場合 ※特にCloudflareやAkamaiを導入済みの場合 |
ロードバランサを利用する方法については、2026 年 1 月 5 日にGoogle Cloudでワンクリックで利用できるようなアップデートがありました。
また、CDNに関しては2026 年 1 月 29 日にAkamai用のオプションが追加されるなど、Cloudflare以外でも対応できるように順次拡大しているようです。
sGTM以外の方法でも簡単に導入できるようなアップデートが今後もありそうですね。
各導入方式の設定手順は公式ドキュメントにまとまっていますので、参考にしてください。
公式ドキュメント：広告主様向けの Google タグ ゲートウェイを設定する | Google tag gateway for advertisers | Google for Developers
サーバーサイド タグ（sGTM）を利用して設定してみた
ここからは、「NRIネットコムBlog」の計測について、実際にsGTMを利用してGTGを導入した際の手順をお見せします。
Google Cloudの環境構築やsGTMの設定方法については割愛し、既にsGTM経由でGA4の計測を行っている前提で、GTGの設定について簡単にご紹介します。
環境によってGTGの設定方法は変わると思うので、sGTMを利用する場合に必要な作業イメージを膨らませるための参考になれば幸いです。
①Google Cloud：Cloud Runのドメインマッピング
まずはGTGで利用するドメインをマッピングします。
sGTMを既に導入している前提だと既にsGTMのドメインの設定が入っていると思いますが、ここにGTGの設定も追加します。
マッピングを追加し、sGTMとは異なるGTG用の自社ドメインを追加します。
所有者の証明やDNSレコードの更新についての手順は割愛しますが、画面の指示に従って設定を進めます。
このあたりの設定は社内の自社サーバーを管理しているメンバーと協力して設定してください。
②GTM：sGTMのクライアント設定
sGTMコンテナでGTG設定用のワークスペースを作成し、「クライアント」を開きます。
sGTMでの計測設定を実施している場合は、既にタイプ「Google アナリティクス: GA4（ウェブ）」のクライアント設定があると思います。
ここにさらに設定を追加します。
クライアントのタイプで「Google タグ マネージャー: ウェブコンテナ」を選択します。
「許可されているコンテナ ID」に自社サーバー経由にしたいGTMコンテナのIDを入力します。
その他の設定項目は利用する環境に応じて設定します。
③Webサイトの改修：GTMコンテナの修正
Webサイトにはすでにウェブ コンテナが実装されていると思いますが、このウェブ コンテナのスニペットを修正します。
もともとコンテナで発行されているキャプチャのようなスニペットを実装していると思います。
もとのスニペットの「src」のURLを、①でマッピングしたドメインに修正します。
これで設定完了です。
既にsGTMを導入している環境だと、思いのほか簡単に設定できてしまいますね。
では、実際に動作確認します。
④動作確認
GTMのプレビューモードを利用して計測を確認します。
GTGを導入すると、sGTMコンテナでのプレビューモードの見え方が、sGTMのみを導入している場合と異なるようです。
■（GTG導入前）sGTMのみを導入している場合の見え方
GTG導入前は、sGTMコンテナのプレビューモードでイベントごとにリクエストの内容を確認できます。
クライアントの詳細や、サーバーからの HTTP 送信リクエスト、受信した HTTP リクエストを確認できます。
特にサーバーからの HTTP 送信リクエスト、受信した HTTP リクエストからは、キャプチャのようにどのような内容のイベントのリクエストかの詳細を確認することができます。
詳細はぼかしていますが、イベント名やイベント パラメータ、計測先の測定IDなどのMeasurement Protocolの内容を確認することができます。
Measurement Protocolの詳細については下記の公式ドキュメントを参照してください。
公式ドキュメント：Measurement Protocol のリファレンス | Google Analytics | Google for Developers
▼サーバーからの HTTP 送信リクエストの詳細
▼受信した HTTP リクエストの詳細
■GTG導入後の見え方
GTG導入後は、sGTMコンテナのプレビューモードでイベントごとにリクエストの内容を確認することができなくなります。
サイトで計測された各イベントは直接 sGTM に送信されるのではなく、クライアント「Googleタグマネージャー：ウェブコンテナ」のリクエストに含まれて送信される仕様となるためです。
一見、設定ミスでうまく動作していないように見えますが、この見え方が現状の仕様では正解です。
サーバーからの HTTP 送信リクエスト、受信した HTTP リクエストの内容はキャプチャのようになっており、確認できる項目はGTGの導入前後で変わりません。
▼サーバーからの HTTP 送信リクエストの詳細
▼受信した HTTP リクエストの詳細
イベントの詳細については「受信した HTTP リクエスト」のレスポンス本文内で確認できますが、キャプチャのようにびっしりと多くの情報が記載されています。
レスポンス本文の内容はぼかしていますが、Measurement Protocolの内容は確認できないので、GTG導入前と比べてかなり見づらいです。
GTG導入時の検証では受信側である GA4 の Debug Viewで確認することが必須です。
導入時につまずいたポイントと注意点
①CMP（同意プラットフォーム）ツールとの干渉
実際に「NRIネットコムBlog」でGTGを導入した際につまずいた点はCMP（同意プラットフォーム）ツールとの干渉です。
「NRIネットコムBlog」では、CMPツールとしてWebtruを導入しています。
Webtruには、Webサイトに訪れたユーザーの同意状況によって各サービスの通信を制御する機能があります。
今回の対応で、Googleのサーバー経由での配信だったGTMを自社ドメイン経由に修正したことで、通信の制御がうまくいかなくなってしまいました。
Webtruの設定を調整しながら無事導入することができましたが、正直な感想としてはCMPツールとの相性はあまりよくありません。
検証環境などで動作確認をしながら慎重に導入する必要があります。
②導入時のコスト
GTGを導入した場合、追加で下記の費用がかかります。
サーバーサイド タグ設定（sGTM）を用いた設定について、実際に弊社環境で導入した際には下表の費用がかかっていました。
GTG導入時に発生する費用は現時点で以下が想定されます。
| 導入方式 | 内容の詳細 | コスト感 |
|---|---|---|
| サーバーサイド タグ設定（sGTM） |
|
高 |
| ロードバランサ |
|
中 |
| コンテンツ配信ネットワーク（CDN） |
|
低 |
GTGを導入したい気持ちが先走ってとりあえずで導入してしまうと、想定外に費用がかさんでしまう恐れがあるのでご利用環境に応じて試算してみてください。
サーバーサイド タグ設定（sGTM）を利用する場合は、下記の公式ドキュメントの「First party serving enabled (via server container)」 という項目があり、この項目が有効化されているかどうかでGTG分の費用が計算できる可能性があります。
公式ドキュメント：Cloud Run によるサーバーサイド タグ設定をセットアップする | Google Tag Manager - Server-side | Google for Developers
実際どれくらい効果がある？
今回はGTG導入の効果を確認するために、GTGを導入して計測を行うプロパティと、未導入で計測を行うプロパティの2環境で「NRIネットコムBlog」の計測を行いました。
全体の改善状況は以下のとおりです。
| アクティブユーザー | +1.8% |
|---|---|
| セッション | +4.6% |
目覚ましい効果を感じられる結果とはなりませんでしたが、ユーザー数セッション数ともにGTG導入プロパティの方が数値が多くなりました。特にセッション数の増加率が高いです。
前提として、GAではユーザーID（会員情報など）を計測していない場合は、Cookieの値でユーザーを識別しています。
Apple社Safariブラウザに搭載されているITP（Intelligent Tracking Prevention）は、サードパーティ Cookieの有効期限を標準よりも短くして削除されやすくする技術です。この技術は、Cookieの値でユーザーを識別しているGAの計測に影響してしまいます。
ITPの影響で再訪したユーザーを新規ユーザーとしてカウントしてしまっていたのが、sGTMの導入によりファーストパーティ Cookieを利用できるようになり1ユーザーとして計測できるようになったため、ユーザー数の増加率はほかの指標と比べて低いのかもしれません。
デバイス別に確認してみると、mobile（モバイルデバイス）とtablet（タブレット）でのセッション数が7～16%程度多い結果となりました。
モバイルデバイスとタブレットでの増加率が顕著なので、Safariのプライベートブラウズに効果があるのではと思えますね。
| デバイス | アクティブユーザー | セッション |
|---|---|---|
| desktop | +0.4% | +3.5% |
| mobile | +3.5% | +10.2% |
| tablet | -0.8% | +7.3% |
OS別（iOSはブラウザ別）に見てみると、ますます増加率は顕著です。
iOSのSafariのセッション数は20%以上の増加をしているので、やはりSafariのプライベートブラウズによりブロックされていたアクセスを計測できるようになったように思えます。
| OS | ブラウザ | アクティブユーザー | セッション |
|---|---|---|---|
| iOS | Safari | +10.8% | +21.0% |
| Chrome | -12.4% | -3.1% | |
| Android | - | +5.7% | +4.6% |
| Windows | - | -0.3% | +3.1% |
結論として、iOSのSafariでのアクセスの増加率が高いことから、やはりSafariのプライベートブラウズによるブロックの対策として効果があるようです。
iOSデバイスのSafariブラウザからのアクセスに関しては、Google が提示している「シグナル（Googleタグの読み込み回数）が11％改善」を大きく上回る20%以上の増加率となりました。
逆に未導入の計測ではこれほどのアクセス数を取りこぼしていると思うとインパクトが大きいですね。
弊社の技術ブログでは全体の増加率としては大きな数値ではありませんでしたが、技術ブログというサイトの特性上、PCで閲覧しているユーザー数が多いためと考えられます。
スマホからのアクセスが多いサイトではより高い効果が期待できます。
まとめ
今回はGoogle タグ ゲートウェイ（GTG）を導入するとどのような効果があるか検証してみました。
GTGの導入ハードルは少し高いかもしれませんが、ブラウザの機能や広告ブロッカーによるトラッキングのブロックを回避できるという大きなメリットがあります。
GTGはなんとなく耳にするものの、結局どんな効果があるのかがイメージできなかったり、クラウドの設定が関わって難しそうと敬遠してしまったり、とりあえずスルーしてしまっている方は多いのではないでしょうか。そんな方の参考になれば幸いです！
プライバシー保護の波に乗れるか乗れないかで、今後のGAやウェブ広告の有用性に大きな差が開いてしまいそうです。
プライバシー保護の動きに対してはGoogleも対策に力を入れているようなので、今後のアップデート情報には常にアンテナを張っておく必要がありますね。
今後大きなアップデートがあればまた検証してみたいと思います。
Google アナリティクスを中心としたGoogle マーケティング プラットフォーム（GMP）のテクニカルサポートを担当しています。
