ウェブサイトに設置したGoogle タグマネージャー（以下、GTM）のスクリプトが、どこから読み込まれているかを意識したことはあるでしょうか。
GTMのスクリプト（gtm.js）は通常、Googleのドメインから読み込まれています。ところが近年は、ブラウザのトラッキング防止機能や広告ブロッカーなどの影響で、この読み込みがブロックされるケースがあります。
こうしたリスクへの対策として、GTMのスクリプトを自社ドメインから配信する方法があります。本コラムでは、自社ドメイン配信が必要になる背景を確認したうえで、以下2つのアプローチをどう選び分けるかを整理していきます。
- Google タグ ゲートウェイ
- Stape Custom Loader
先に結論をお伝えすると、まずGoogleのスクリプト配信先だけを自社ドメインに変えたい場合はGoogle タグ ゲートウェイが候補になります。一方で、StapeでサーバーサイドGTM（以下、sGTM）を運用している、またはこれから導入する前提がある場合は、Custom Loaderのほうが適しています。
- 通常のGTM読み込みと、なぜ自社ドメイン配信が必要になるか
- まず選び分けを整理する
- Google タグ ゲートウェイの仕組み・向いているケース・注意点
- Stape Custom Loaderの仕組み・導入前提・注意点
- sGTMと組み合わせると何が広がるか
- まとめ
通常のGTM読み込みと、なぜ自社ドメイン配信が必要になるか
まず前提として、通常の読み込みの仕組みと、なぜ自社ドメインからの配信が検討されるのかを確認します。
通常の読み込みの仕組み
GTMをウェブサイトに導入する際は、HTMLに「コンテナスニペット」と呼ばれるコードを設置します。コンテナスニペットは、GTMの管理画面から確認できます。
このコンテナスニペットを見ると、googletagmanager.comというGoogleのドメインから、GTMのスクリプトであるgtm.jsを取得していることがわかります。同様に、Google アナリティクス（以下、GA）やGoogle 広告のスクリプト（gtag.js）も、通常はGoogleのドメインから取得しています。
外部ドメインからの読み込みがブロックされると
ここで問題になるのが、外部ドメインからのスクリプト取得がブロックされるケースです。
ブラウザのトラッキング防止機能や広告ブロッカーの影響により、GTMの読み込みがブロックされる場合があります。その結果、GTMのスクリプトを取得できず、GTM自体が機能しなくなる可能性があります。
GTMがブロックされると、GTM経由で配信しているタグはすべて動作しなくなります。影響を受けるのはGAやGoogle 広告などの計測タグだけではありません。たとえば、以下のような機能を担うタグにも影響が及ぶ可能性があります。
- チャットウィジェット
- A/Bテストツール
- 同意管理プラットフォーム（CMP）
- ヒートマップツール
このようなリスクへの対応策として、GoogleのスクリプトをGoogleのドメインから直接取得するのではなく、自社ドメイン経由で配信する方法があります。
ブラウザから見ると、自社ドメイン配信は「外部サービスではなく自社のドメインと通信している」ように見える構成です。このような構成はファーストパーティの配信として扱われやすく、ブラウザのトラッキング防止機能や広告ブロッカーの影響を受けにくくなる場合があります。
ここまでで、通常の読み込みの仕組みと、自社ドメイン配信が必要になる背景を確認しました。ここからは、まず2つのアプローチの選び分けを整理してみましょう。
まず選び分けを整理する
Google タグ ゲートウェイとCustom Loaderは、どちらも「Googleのスクリプトを自社ドメイン経由で配信する」という点では同じ目的を果たします。一方で、違いは前提条件と、その先に広げられる範囲にあります。
まず配信先だけを切り替えたい場合はGoogle タグ ゲートウェイが候補になります。一方で、StapeでsGTMを運用する前提がある場合は、Custom Loaderのほうが適しています。
この選び分けを踏まえて、次のセクションからそれぞれの特徴を順に見ていきましょう。
Google タグ ゲートウェイの仕組み・向いているケース・注意点
まず、Googleのスクリプト配信先だけを自社ドメインに切り替えたい場合に、有力な選択肢となるのがGoogle タグ ゲートウェイです。
Google タグ ゲートウェイは、CDNやロードバランサーなどの配信基盤を経由して、Googleのスクリプトを自社ドメインから配信できるようにする仕組みです。
CDNとは、ウェブサイトのコンテンツを各地のサーバーに分散配置し、ユーザーに近い場所から配信する仕組みです。ロードバランサーとは、アクセスを複数の処理先に振り分ける仕組みです。
Googleのスクリプトを取得するブラウザからのリクエストは、まずCDNなどの配信基盤で受け付けられ、その後googletagmanager.comへ中継されます。ブラウザから見る配信元はGoogleのドメインではなく、自社ドメインになります。
向いているケース
Google タグ ゲートウェイが向いているのは、sGTMを前提にせず、まずGoogleのスクリプト配信だけを改善したい場合です。
たとえば、GTMやGA、Google 広告のスクリプトを自社ドメイン経由に切り替えたいが、sGTMの導入まではまだ決まっていない場合があります。このような場合は、まずGoogle タグ ゲートウェイから検討すると整理しやすくなります。
導入パターンと注意点
Google タグ ゲートウェイには複数の導入パターンがあり、環境によっては自動設定を選べる場合もあります。一方で、対応する構成やセットアップ方法は変わることがあるため、最新の対応状況は公式ドキュメントで確認することが重要です。
※とはいえ、公式ヘルプも更新が遅れているケースがあるためご注意ください。
Google for Developers:
https://developers.google.com/tag-platform/tag-manager/gateway?hl=ja
導入前に確認したい点は、大きく2つあります。
1つ目は、CMPへの影響です。
CMPは、Cookieの利用可否や同意状態を管理する仕組みです。タグの読み込み経路が変わることで、タグの発火条件や同意状態の扱いに影響する可能性があります。
2つ目は、どのドメインにGoogle タグ ゲートウェイの設定が反映されるかです。
設定内容によっては、本番サイトだけでなく、同じドメイン配下のサブドメインにも影響する場合があります。たとえば、検証環境や別CMSの管理画面まで影響が及ぶ可能性がある点に注意が必要です。
GTMタグの計測対象となるドメインの範囲が変わるため、全ページで発火しているタグなどに支障が出る場合があります。
そのため、Google タグ ゲートウェイを検討する際は、技術的に設定できるかだけでなく、「どのドメインに反映されるか」「同意管理の実装に影響しないか」まで含めて確認することが大切です。
ここまでで、Google タグ ゲートウェイが向いている場面を確認しました。次に、sGTMをStapeで活用する前提がある場合の選択肢として、Custom Loaderを見ていきましょう。
Stape Custom Loaderの仕組み・導入前提・注意点
前のセクションでは、Google タグ ゲートウェイが「まず配信先だけを変えたい場合」の候補になると説明しました。ここで登場するのが、StapeでsGTMを運用する前提がある場合の選択肢になるCustom Loaderです。
Stapeは、sGTMの構築・ホスティング・運用を支援するオールインワンプラットフォームです。2021年の設立以来、世界で 200,000 以上のクライアントに採用され、65,000 以上のsGTMを運用している、サーバーサイド計測分野のグローバルリーダーです。
Custom Loaderは、そのStapeが提供する追加機能の1つです。Stapeではこのような追加機能をPower-Upと呼んでいます。
sGTMの概要とStapeについては、弊社の以下コラムをご参照ください。
「サーバーサイドGTM」の基本知識
アユダンテとStapeがパートナーシップに至った背景と想い
Custom Loaderも、GTMのスクリプト配信先を自社ドメインに変える機能です。
ただし、Custom Loaderの特徴は、Stape上のsGTM運用とあわせて使うことを前提にしており、配信先変更に加えて、その後のデータ活用までつなげやすい点にあります。
導入前に確認したい前提
まず確認したいのは、sGTMをStapeで運用している、またはこれから導入する前提があるかどうかです。Custom LoaderはStapeのsGTM環境とあわせて使う機能のため、GTMのスクリプト配信先だけを単独で変えたい場合には、Google タグ ゲートウェイのほうが適しているケースがあります。
配信先としては、たとえばsgtm.example.comのようなsGTM用サブドメインを利用します。www.example.comで公開しているウェブサイトに対して、sgtm.example.comからGTMのスクリプトを配信するイメージです。
反映方法と確認ポイント
導入パターンは、大きく2つあります。1つは、ウェブサイトに設置しているGTMコンテナスニペットを、Stapeから発行されるCustom Loader対応版のコードに差し替える方法です。
もう1つは、WordPress、Shopify、MagentoなどでStapeのプラグインを利用して反映する方法です。
反映後は、ブラウザのデベロッパーツールでネットワーク通信を確認し、GTMのスクリプト取得先がgoogletagmanager.comではなく、自社のsGTMドメインに変わっているかを検証します。
特に確認したいのは、既存のGTMコンテナスニペットとの差し替え漏れです。テンプレート、CMSのテーマなど複数の場所でGTMコードを管理している場合は、一部だけ旧スニペットが残ってしまうことがあります。そのため、実装箇所を事前に整理したうえで反映することが重要です。
Custom Loaderのセットアップ手順は、Stapeの公式ヘルプをご参照ください。https://stape.io/helpdesk/documentation/custom-loader-setup
ここまでで、Custom Loaderがどのような前提で使われるかを確認しました。次のセクションでは、sGTMと組み合わせたときに何が広がるのかを見ていきます。
sGTMと組み合わせると何が広がるか
ここまで見てきた通り、Google タグ ゲートウェイとCustom Loaderは、どちらも自社ドメイン配信という目的には対応できます。一方で、Custom Loaderの強みは、sGTMとセットで使うことで、その後のデータ処理まで含めて設計しやすくなる点にあります。
sGTMは、ブラウザなどから受け取ったデータをサーバー側で処理したうえで送信できる仕組みです。たとえば、以下のような処理が可能です。
- 個人情報を除去してからGAに送信する
- 同じデータをBigQueryにも並行して送信する
- MetaやTikTokなどのコンバージョンAPIにサーバーから直接送信する
Google タグ ゲートウェイは、こうしたデータ加工や他媒体連携そのものを担う仕組みではなく、あくまでスクリプト配信経路の変更が中心です。そのため、将来的に計測基盤や広告連携まで整理したい場合は、sGTMを前提にした構成のほうが拡張しやすくなります。
さらに、StapeにはCookie Keeperという別のPower-Upがあります。Cookie Keeperは、SafariのITP（Intelligent Tracking Prevention）によって短縮されたCookieの値を、後から復元しやすくするための機能です。
Cookieの復元処理は、GAなどのタグが動く前に実行されることが前提になります。復元する前にタグが発火すると、新しいCookieが生成される可能性があるためです。そのため、Cookie Keeperを使う場合は、Custom Loaderが必須となります。
Cookie Keeperについては弊社の以下コラムをご参照ください。
【sGTM】サーバーサイドGTMでCookieの寿命を延ばす方法
このように、StapeでsGTMを運用する前提がある場合、Custom Loaderは自社ドメインからのスクリプト配信だけにとどまらず、タグ配信後のデータ加工や他媒体との連携、Cookie Keeperとの組み合わせまで、一気通貫で考えやすい選択肢です。
まとめ
本コラムでは、GTMのスクリプトを自社ドメインから配信する背景と、Google タグ ゲートウェイ、Stape Custom Loaderの選び分けを紹介しました。
通常、GTMのスクリプトはgoogletagmanager.comから読み込まれます。これがブラウザのトラッキング防止機能や広告ブロッカーの影響を受けると、GAの計測データが欠落するだけでなく、GTM経由で管理している機能が動作しなくなる可能性があります。
まずGoogleのスクリプト配信先だけを改善したい場合は、Google タグ ゲートウェイが候補になります。一方で、StapeでsGTMを運用する前提があり、配信先変更に加えてデータ加工や他媒体連携、Cookie Keeperとの連携まで見据えたい場合は、Custom Loaderのほうが適しています。
まずは自社の環境を確認し、「配信先だけを変えたいのか」「sGTM活用まで含めて整理したいのか」を切り分けるところから始めてみてください。自社ドメイン配信を検討する際の参考になれば幸いです。
なお、アユダンテではサーバーサイドGTMの導入支援を行っております。Stapeとは2025年11月にパートナーシップを締結しており、Stapeを活用したsGTM導入支援も行っています。Stapeの導入に興味がある場合や、Custom Loaderの活用を検討している場合は、お気軽にお問い合わせください。
