GoogleタグとGTMの違いと使い分け|併用時の二重計測を防ぐ整理手順
Googleタグ(gtag.js)とGTMの違いを役割とタグIDから整理し、併用で二重計測になる条件・ならない条件を解説。Tag Assistantでの診断、GTMへ統一する移行5ステップ、並行計測による数値検証まで、タグ混在サイトを当日から整理できる実務手順をまとめました。
この記事のポイント
- GoogleタグとGTMの併用で二重計測になるのは、同一の測定IDやコンバージョンIDに両方から送信している場合だけです
- GA4・Google広告・他社タグを複数運用する体制ほど、GTMへの統一が合理的な選択になります
- 移行時はGTM側で並行計測し、数値が1〜2%以内で一致してから旧gtag.jsを削除するのが安全な手順です
- Tag Assistantで同一タグIDの発火回数を確認すれば、二重計測の有無は当日中に診断できます
- GTMへの統一は、Google Tag Gatewayなど将来のサーバーサイド計測基盤への準備にもなります
代理店から引き継いだサイトのソースを開いたら、gtag.jsのスクリプトとGTMのコンテナタグが両方埋め込まれていた——こうした状態に遭遇して、コンバージョン数の増減の理由が説明できずに困る運用担当者は少なくありません。結論から先に言うと、GoogleタグとGTMの併用そのものは問題ではなく、同じ送信先IDに両方のルートから計測データが流れているかどうかで二重計測の有無が決まります。この記事では、まず二重計測の判定基準を提示したうえで、GTMへ統一するか現状維持するかの判断軸、そして実際に安全に整理するための移行手順と検証方法までを順に解説します。

GoogleタグとGTMを併用すると二重計測になる?【結論:送信先IDの重複次第】
Tag Assistantで同じIDが二重発火を発見
GoogleタグとGTMを同じサイトに併用しても、それだけでは二重計測になりません。二重計測が発生するのは、同一の測定ID(G-から始まるGA4のID)や同一のコンバージョンID(AW-から始まるGoogle広告のID)に対して、gtag.jsとGTMの両方からイベントが送信されている場合に限られます。逆に言えば、片方は広告タグ専用、もう片方はGA4専用というように送信先が明確に分かれていれば、併用していても数値は重複しません。
二重計測になる条件・ならない条件
判断に迷ったときは、まず自社の設置状況を次の表と照らし合わせてみてください。
| 設置パターン | 二重計測の有無 |
|---|---|
| gtag.jsとGTMが同一のG-IDへイベントを送信 | なる |
| GTM内のカスタムHTMLタグにgtag.jsのスニペットを貼り付け | なる(典型的な事故パターン) |
| gtag.jsはAW-ID専用、GTMは別のG-ID専用で役割分担 | ならない |
| gtag.jsで基本のページビューのみ、GTMでイベント計測のみと分離 | ならない(ただし推奨される構成ではない) |
Tag Assistantで今すぐ確認する手順
診断は難しい作業ではありません。Google Tag AssistantというChrome拡張機能を使えば、次の手順で当日中に判定できます。
- Tag Assistantを起動し、対象ページを開く
- 検出されたタグ一覧で同一のタグID(G-・AW-)が複数回リストされていないか確認する
- プレビューモードでdataLayerに積まれるイベントと、実際のリクエスト数を照合する
- 同じ測定IDへのリクエストが2本以上立っていれば、二重計測が確定する
Tag Assistantの操作でつまずきやすい細部については、GTMプレビュー・Tag Assistantのつまずき診断フローにまとめているので、あわせて参照してください。
Googleタグ(gtag.js)とGoogleタグマネージャー(GTM)の違いとは?
図1: gtag.jsとGTMの役割の違いを図解
Googleタグ(gtag.js)とは、Google Analytics 4やGoogle広告などGoogle系サービスへ直接データを送信するJavaScriptの計測コードです。一方、Googleタグマネージャー(GTM)とは、複数の計測タグをまとめて管理し、条件に応じて発火させるタグ管理システムを指します。両者は競合する技術ではなく、役割が異なる存在だと理解するのが出発点になります。
役割の違い:データを送るコードとタグを管理する箱
Analytics Maniaの解説では、gtagを楽器、GTMを演奏者に例えています。楽器そのものが音を出す装置であるように、gtag.jsはデータを送信するコードそのものです。演奏者がどの楽器をいつ鳴らすか決めるように、GTMは複数のタグをいつ・どの条件で発火させるかを管理する立場にあります。日本の実務に置き換えると、gtag.jsは送信専用の一本のコード、GTMはそのコードを含む複数タグの発火順序・条件を集中管理する箱、というイメージです。
タグID(G-・AW-・GT-・GTM-)の見分け方
タグIDの接頭辞を覚えておくと、ソースを見ただけでどのプロダクトの設定か判別できます。
| 接頭辞 | 意味 |
|---|---|
| G- | GA4の測定ID |
| AW- | Google広告のコンバージョンID |
| GT- | Googleタグの統合ID(複数プロダクトを束ねる場合に使われる) |
| GTM- | GTMコンテナのID |
GoogleタグとGTMはどっちを使うべき?使い分けの判断基準
図2: GTM統一を判断するフローチャート
GA4とGoogle広告、さらに他社タグを併用するサイトでは、GTMへの統一が原則になります。理由は単純で、タグの追加・変更のたびにソースコードを触る必要がなくなり、変更履歴やバージョン管理もGTMの管理画面内で完結するためです。ただし、すべてのサイトに一律で当てはまるわけではありません。
GTMに統一すべきケース(広告・GA4・他社タグの複数運用)
- GA4とGoogle広告に加えて、Meta広告やX広告など他社タグも運用している
- タグの追加・変更を非エンジニアのマーケ担当者が行う体制になっている
- コンバージョンリンカーなど、複数タグ間の連携設定が必要になっている
gtag.js直書きのままで良いケース
一方で、Analytics Maniaが挙げているように、IT部門のポリシーでタグマネージャーの設置自体が禁止されている組織や、計測対象がGA4のみで開発フローがコードベースで完結している小規模サイトでは、gtag.jsの直書きを維持しても実務上の支障は小さいと考えられます。
判断フローチャート
迷ったら、次の順で当てはめてみてください。設置タグが1種類のみで運用者もエンジニア1人なら直書きのままで問題ありません。タグが2種類以上、または非エンジニアが運用に関わるならGTM統一を検討すべき段階です。複数人・複数部門でタグを追加していく体制であれば、GTM統一はほぼ必須と言えます。
併用状態を整理する手順|gtag.jsからGTMへ安全に移行する5ステップ
図3: 5ステップで見る安全な移行フロー
併用状態の整理は、いきなり片方のタグを削除するところから始めてはいけません。棚卸し、重複判定、集約、並行検証、削除という順序を踏むことで、移行中の計測断絶を防げます。
ステップ1:設置タグの棚卸し(ページソース×Tag Assistant)
まずページソースをview-sourceで開き、「gtag(」「GTM-」「AW-」「G-」で検索して、設置されているすべてのIDを洗い出します。あわせてTag Assistantでも検出結果を確認し、ソース上の記述とツールの検出結果を突き合わせておくと、後工程での見落としが減ります。
ステップ2:送信先IDの重複判定
洗い出したIDをリスト化し、同一IDが複数箇所から呼ばれていないかを確認します。Two Octobersの分析では、GTM導入済みサイトの重複計測の最頻原因は「ハードコードされた旧タグの残留」とされています。ツールの検出結果だけに頼らず、直帰率やイベント数の不自然な変化からも重複を逆算的に疑う視点を持っておくと、引き継ぎアカウントの棚卸しでは特に役立ちます。
ステップ3:GTM公式テンプレートへの集約
重複が確認できたら、GTM内でGA4設定タグ、Google広告コンバージョントラッキングタグといった公式テンプレートに集約します。
ステップ4:並行計測と数値比較(1〜2%以内が目安)
ここが最も省略されがちな工程です。Bounteousは、GTM側で全タグを複製したうえで数日間の並行計測を行い、主要指標が1〜2%以内の差に収まることを確認してから旧タグを削除するという段階検証プロセスを推奨しています。公開直後に旧タグを消すのではなく、この並行期間を挟むことで、移行時に数値が途切れるリスクを避けられると考えられます。
ステップ5:旧gtag.js削除と公開の同時実行
数値の一致が確認できたら、旧gtag.jsのコード削除とGTMコンテナの公開を同じタイミングで行います。時間差を空けると、その間だけ二重計測または計測欠落の状態が発生してしまいます。
やってはいけないこと:カスタムHTMLへのgtag貼り付け
Analytics Maniaは、gtag.jsのスニペットをGTMのカスタムHTMLタグにそのまま貼り付ける設定を、二重計測と設定不整合の典型的な原因として明確に禁止しています。GTMには公式のGA4設定タグ・Google広告コンバージョントラッキングタグが用意されているため、カスタムHTMLを使う理由は基本的にありません。集約後にタグが発火しない事象が起きた場合は、GTMでコンバージョンタグが発火しない時のデバッグ手順を切り分けの参考にしてください。
移行後に数値が合っているか検証する方法
移行前後の数値を見比べてひと安心
移行作業が完了しても、それで終わりではありません。公開直後から数日間は、旧構成との数値差を継続的に見ておく必要があります。
GA4 DebugViewとGoogle広告タグステータスの確認
GA4の管理画面からDebugViewを開き、イベントがリアルタイムで届いているかを確認します。Google広告側は「ツールと設定」→「測定」からタグのステータスを確認し、アクティブと表示されているかをチェックします。あわせてTag Assistantのプレビューモードでイベントの発火順序も見ておくと安心です。
移行前後で数値がズレた場合の切り分け
数値が増えた場合は旧タグの削除漏れやカスタムHTMLの残留を、減った場合はGTM側のトリガー条件不足やコンバージョンリンカーの未設置を疑うのが基本の切り分け方です。GA4側のイベント重複についてはGA4イベントが重複計測される3つの原因と切り分け修正手順、広告コンバージョンの重複については広告CVのダブルカウントを発見・修正する実務手順で、より詳細な切り分け手順を扱っています。
タグをGTMに統一しておくべきもう一つの理由|Google Tag Gatewayとサーバーサイド化
タグの統一は、単なる見た目の整理にとどまりません。Brainlabsのレポートでは、gtag.jsやGTMのコードを自社ドメイン経由で配信するGoogle Tag Gateway(旧First-Party Mode)が、2026年時点の計測基盤の標準になりつつあると指摘されています。ブラウザ側の計測ブロックが強まるなかで、ファーストパーティ経路での計測はGA4・Google広告双方の精度維持に直結するという文脈です。
日本市場でもブラウザのトラッキング制限は徐々に強まる傾向にあり、サーバーサイド化やTag Gatewayの導入を検討する段階になって、タグがGTMに統一されていないと移行作業そのものが複雑になります。タグの整理は「今の二重計測を消す作業」であると同時に、将来の計測基盤整備の前提条件でもあると捉えておくとよいと思います。サーバーサイド化の要否判断については、サーバーサイドGTMは導入すべきかの判断フレームで整理しています。
よくある質問
Q:GA4の計測タグはGTMとGoogleタグ(gtag.js)を併用してもいいですか? 併用自体は可能ですが、同一の測定IDに対して両方から二重送信になる設定は避けるべきです。役割が明確に分かれていない限り、どちらか一方に統一するのが原則です。
Q:二重計測されているかどうかを確認する方法は? Tag Assistantで同一タグIDの検出数を確認し、GA4のリアルタイムレポートでイベント数が想定より多くないかを併せて確認する方法が実務的です。
Q:GTMに移行したら古いgtag.jsのコードは削除すべきですか? 削除は必須です。ただし、いきなり消すのではなく、並行計測で数値の一致を確認したうえで、GTMコンテナの公開と同時に削除するのが安全な手順です。
Q:タグIDのGT-とGTM-は何が違いますか? GT-はGoogleタグ固有のID、GTM-はGTMコンテナのIDです。あわせてG-はGA4の測定ID、AW-はGoogle広告のコンバージョンIDを表します。
Q:GTMを使っている場合、Google広告のコンバージョンタグは別途設置が必要ですか? 不要です。GTM内のコンバージョントラッキングタグとコンバージョンリンカーの設定で完結するため、別途gtag.jsを直書きする必要はありません。
タグの混在状態は、放置している期間が長いほど棚卸しの手間が増えていきます。真策堂では、代理店引き継ぎやインハウス化のタイミングで発生しがちな複数タグ混在アカウントの整理について、こうした診断・移行の観点から相談を受けています。
- アクセス解析
サーチコンソールとGA4の数値が合わない原因6パターン|どちらを正とすべきかの判断基準
サーチコンソールのクリック数とGA4のセッション数が合わない原因を、計測欠損・セッション定義・集計範囲・タイムゾーン等の6パターンで切り分け。乖離率の計算式と「20〜30%は正常」の目安、SEO成果はGSC・サイト内行動はGA4という目的別の判断基準まで実務手順で解説します。
- アクセス解析
GA4のデータ保持期間を変更したのに反映されない?過去データが見れない原因と確認手順
GA4のデータ保持期間を14ヶ月に変更したのに探索レポートで過去データが見れない原因を、最大24時間の反映ラグ・遡及適用されない仕様・イベント/ユーザーデータ設定の混同・画面の違いの4点で切り分け。戻らないデータの範囲とBigQuery連携による長期保存まで実務手順で解説します。
- アクセス解析
GA4のデータ保持期間は14ヶ月まで?探索レポートで過去データが見れない原因と設定変更・長期保存の対処法
GA4の探索レポートで過去のデータが見れないのはデータ保持期間(デフォルト2ヶ月・最大14ヶ月)が原因です。消えるのは探索用データだけで標準レポートは残る仕組みを整理し、14ヶ月への変更手順、復元できない仕様、BigQuery連携による長期保存までコスト感つきで解説します。