GA4イベントが重複計測される3つの原因とGTM・直実装の切り分け修正手順
GA4でイベントが2回カウントされる原因を「GTM内部の設定タグ重複」「GTM×直実装混在」「複数GTMコンテナ」の3パターンに分類。Networkタブ・GTMプレビュー・ページソース確認の3ステップ切り分けフローとパターン別の修正手順を実務担当者向けに体系解説します。
この記事のポイント
- GA4でイベントが2回カウントされる原因は「GTM内部の設定タグ重複」「GTM×gtag.js直実装の混在」「複数GTMコンテナの同時読み込み」の3パターンに分類できる
- まずNetworkタブでcollect?v=2リクエストの件数を確認し、2件以上送信されていれば二重発火が確定する
- GTMプレビューとページソース確認を組み合わせた3ステップ診断でパターンを特定し、パターン別の修正手順を実行すればDebugViewで正常化をリアルタイムに確認できる
- 修正後のGA4標準レポートへの反映には24〜48時間のタイムラグがあるため、修正日をアノテーション等に必ず記録しておく
GA4の管理画面を開いたとき、「コンバージョンイベントが昨日から倍増している」「ページビューが実感値の2倍ある」という状況に遭遇した担当者は少なくないと思います。こうしたケースの多くは、1回のユーザー操作に対して同じイベントが2回送信される「重複発火」が原因です。
重複発火自体は珍しい事象ではありません。GTMの設定変更やサイトリニューアルのタイミングで気づかないまま発生し、気づいたころにはレポートのデータが混在した状態になっているケースが多いです。問題は「どこで何が重複しているのか」の特定が難しい点にあります。原因が1つとは限らず、GTM内部の問題なのか、直実装との混在なのか、コンテナが複数あるのかによって修正の手順がまったく異なります。
この記事では、GA4 イベント 重複計測の原因を3パターンに体系化し、NetworkタブとGTMプレビューを組み合わせた切り分けフローから、パターン別の修正手順、DebugViewでの正常化確認まで一気通貫で解説します。
GA4でイベントが重複計測されているかを確認する
DebugViewで「同一イベントが連続2件」表示される症状を確認する
重複発火を最初に疑う場面は、Googleアナリティクス4(GA4)のDebugViewを開いたとき、同じイベント名が連続で2件並んでいるケースです。
確認手順は次のとおりです。GA4管理画面の左メニューから「管理」→「DebugView」を開き、対象のページをブラウザで再読み込みします。DebugViewのタイムラインに page_view や session_start が秒単位で2件並んでいれば、重複発火の可能性が高いと判断できます。
ただし、DebugViewにデータが表示されるには、ブラウザがデバッグモードである必要があります。ChromeにTag Assistant拡張機能をインストールしてアクティブにした状態、またはGTMプレビューモードを起動した状態であれば、自動的にデバッグモードで計測されます。何も拡張機能を入れていない通常ブラウザでは DebugView に映らないため、必ずTag Assistantを使って確認してください。
GA4標準レポートでイベント数が不自然に多い場合の見分け方
DebugViewを常時監視している担当者はほとんどいないので、多くの場合は標準レポートの異常から重複発火に気づくことになります。見るべき指標は主に2つです。
1つ目は「イベント数 ÷ セッション数」の比率。通常のサイトでは page_view イベントはセッションあたり数件程度に収まることが多く、これが突然2倍近く跳ね上がっているなら二重発火を疑います。
2つ目は、変化が起きたタイミングの確認です。GTMの公開操作・サイト更新・新しいタグの追加直後にイベント数が急増しているなら、その変更が原因である可能性が高い。GA4の「探索」メニューから日別のイベント数を折れ線グラフで出し、急増した日を特定してから切り分け作業に入ると効率的です。
GA4重複発火の原因3パターン
パターン①:GTM内にGA4設定タグが複数存在する
Googleタグマネージャー(GTM)の中に、同じ測定ID(G-XXXXXXXXXX)を持つ「GA4設定タグ」(タグタイプ: Googleアナリティクス: GA4設定)が複数作成されているケースです。
なぜこうなるかというと、GTMを複数人で管理しているとき、あるいは設定を別担当者から引き継いだ際に、古い設定タグを削除せずに新しいものを追加してしまうことがあります。また「念のため別のトリガー条件でも設定タグを入れておこう」という意図で重複が生まれることもあります。
このパターンでは、2本のGA4設定タグがどちらも「All Pages」のトリガーになっていることが多く、ページ読み込みのたびに2本のconfig呼び出しが発生します。GTMコンテナ内のタグ一覧で「GA4設定」タイプにフィルタして件数を確認するのが最初の作業です。
パターン②:ページにgtag.jsが直書きされかつGTM経由のGA4も動いている(最多)
実務でもっとも遭遇するのがこのパターンです。サイトのHTMLにgtag.jsを直接埋め込んだ後、別の担当者またはエージェンシーがGTMを導入してGA4タグを追加した、というケースで生じます。
直実装側は <head> 内に以下のような形で入っています。
<!-- Google tag (gtag.js) -->
<script async src="https://www.googletagmanager.com/gtag/js?id=G-XXXXXXXXXX"></script>
<script>
window.dataLayer = window.dataLayer || [];
function gtag(){dataLayer.push(arguments);}
gtag('js', new Date());
gtag('config', 'G-XXXXXXXXXX');
</script>
この状態でGTM経由でもGA4設定タグが発火していると、同じ測定IDへのcollectリクエストが2件送信されます。CMSのテンプレートにgtag.jsが最初から埋め込まれており、後からGTMにGA4設定タグが追加されたときに起こりやすいパターンです。
パターン③:複数のGTMコンテナが同一ページに読み込まれている
GTMコンテナ(GTM-XXXXXXXX形式のID)が1つのページに2つ以上読み込まれているケースです。
よくあるのは、マーケティング部門管理のGTMコンテナとエンジニアリング部門管理のGTMコンテナが両方埋め込まれており、どちらにもGA4設定タグが入っているパターン。あるいは、サイトリニューアル時に旧コンテナを除去し忘れて新コンテナと並存している状況です。
このパターンはページソースだけでは気づきにくく、window.google_tag_manager オブジェクトに複数のコンテナIDが登録されているかどうかを確認する必要があります。
原因パターンの切り分けチェックリスト(3ステップ診断フロー)
ステップ1:Networkタブでcollect?v=2リクエストが何件送信されているかを確認する
ブラウザのデベロッパーツール(Chromeなら F12)を開き、「Network」タブを選択します。検索欄に collect と入力してフィルタをかけた状態で対象ページを再読み込みします。
GA4はサーバーにイベントを送信するとき、https://www.google-analytics.com/g/collect?v=2... というリクエストを発行します。このリクエストが1回のページ読み込みで何件発生しているかを数えます。
- 1件のみ:重複発火していない(別の原因を調査)
- 2件以上:重複発火確定
さらに、対象リクエストをクリックして「Payload」を展開すると、en(イベント名)や tid(測定ID)などのパラメータが読めます。2件とも同じ tid=G-XXXXXXXXXX であれば同一プロパティへの二重送信です。異なる測定IDなら、2つの別GA4プロパティに送っている可能性もあるため、意図した設計かどうかを確認します。
ステップ2:GTMプレビューで同一GA4設定タグが複数回発火していないかを確認する
GTMのワークスペースで「プレビュー」ボタンをクリックし、Tag Assistantのタブで対象URLを入力して接続します。ページを表示すると左パネルに「Container Loaded」「Window Loaded」などのイベントが時系列で並びます。
「Container Loaded」を選択し、右側の「Tags Fired」一覧に同じGA4設定タグが2回以上出ていないかを確認します。1本しかないのに2件のcollectリクエストが来ている場合、GTM外のgtag.js(直実装側)が原因と絞り込めます。
GTMプレビューがうまく接続できない・タグが発火しない場合は、GTMプレビューが接続できない・タグが発火しない原因切り分けチェックリストも参照してみてください。
ステップ3:ページソースでgtag(‘config’,‘G-XXXXXXXX’)が直書きされていないかを確認する
ブラウザで対象ページを開き、右クリック→「ページのソースを表示」(Ctrl+U)。Ctrl+F で gtag('config' を検索します。この文字列がソース内に見つかれば、gtag.jsの直実装が存在します。
あわせて googletagmanager.com/gtm.js?id=GTM- を検索し、何件ヒットするかも確認します。2件以上あればパターン③(複数コンテナ)の可能性があります。
| ステップ | 確認内容 | 重複時の判断 |
|---|---|---|
| 1. Networkタブ | collect?v=2が何件か | 2件以上→重複確定 |
| 2. GTMプレビュー | GA4設定タグの発火回数 | 2回→パターン① |
| 3. ページソース | gtag(‘config’)の有無 | 発見→パターン② |
この3ステップで、ほとんどのケースはパターンを特定できます。パターン①②のいずれでもなくcollect?v=2が2件来ている場合は、パターン③(複数コンテナ)を疑います。
【パターン①修正】GTM内のGA4設定タグ重複を解消する
GA4設定タグを1本に集約する手順とバージョン管理の注意点
GTM内のタグ一覧を「Googleアナリティクス: GA4設定」タイプでフィルタし、同じ測定IDが設定されているタグが複数あることを改めて確認します。
残すタグを1本に決め(最も長く使われてきたもの、または設定内容が整備されているもの)、残りを削除します。削除前に、削除対象のタグの設定内容(測定ID・設定フィールド・初期化タイミング)をスクリーンショットやメモで記録しておくと、後から問題が生じたときに差分を確認できます。
バージョン管理の面でも注意が必要です。GTMは「公開」操作のたびにバージョンが作成され、過去の状態にロールバックできます。修正作業前に現在の状態を「バージョンを作成」しておくと安全です。
既存カスタムイベントタグが参照する設定タグを統一する際の依存確認
GTMのタグ一覧を「Googleアナリティクス: GA4イベント」タイプでフィルタし、各タグの「設定タグ」列を確認します。削除予定のGA4設定タグを参照しているイベントタグがある場合、参照先を存続させる設定タグに切り替えてから削除します。参照先のないまま削除すると、カスタムイベントタグの設定が壊れ、イベントが送信されなくなります。
切り替えは1タグずつ行い、GTMプレビューで動作確認してから次に進むことを推奨します。一括変更するとどのタグで問題が起きたか追えなくなるためです。修正完了後にGTMを公開し、DebugViewで page_view が1件になったことを確認してから運用に戻します。
【パターン②修正】GTM×直実装(gtag.js)の混在を解消する
GTMに一本化すべきケースとgtag.jsを残すべきケースの判断基準
どちらを残すかは、用途と今後の運用体制によって変わります。
GTMへの一本化が適切な場合(多数派)
- タグ管理をマーケティング担当者が主体で行っており、HTMLを直接編集する工数を削減したい
- コンバージョンや各種イベントをGTMで一元管理したい
- サーバーサイドGTMを使っていない、またはGA4専用のサーバーサイド実装を持っていない
gtag.jsを残してGTM側のGA4設定タグを削除すべき場合
- サーバーサイドGTMとの接続構成において gtag.js の config 呼び出しが必要になっている
- 特定のeコマース計測でデータレイヤーへのpush順序がgtag.jsの実行後でなければ正しく動かない構成
- CMSの制約上GTMスニペットを
<head>の適切な位置に配置できない
どちらかに一本化することが大前提です。「両方残す」は重複発火の原因そのものになるため、どちらを採用するか判断したら中途半端に残さないことが重要です。
HTMLからgtag.jsを除去する際に確認すべき依存関係チェックリスト
削除前に以下を確認します。これをスキップすると、gtag.js 除去後に別の計測が壊れます。
- ページ内で
gtag('event', ...)を直接呼んでいる箇所がないか(ソース内をgtag('event'で検索) - Google広告コンバージョンタグが
gtag('event', 'conversion', ...)形式で直実装されていないか - Google広告リマーケティングタグが gtag形式で直実装されていないか
- 同意モード(Consent Mode)の初期化をgtag.jsで行っていないか
上記に該当する実装がある場合は、それらもGTM経由に移行してからgtag.jsを除去します。GA4設定タグだけGTMに移してもGoogle広告タグが直実装のままなら、今度はGoogle広告側の重複発火が発生するためです。移行完了後、Networkタブで発火数が1件になっていることを確認して完了とします。
【パターン③修正】複数GTMコンテナの重複読み込みを解消する
ページに読み込まれているGTMコンテナIDを一覧取得する方法
ブラウザのコンソールタブで次のスクリプトを実行すると、そのページで動作しているGTMコンテナIDの一覧を取得できます。
Object.keys(window.google_tag_manager || {}).filter(k => k.startsWith('GTM-'))
返ってきた配列が2件以上あれば複数コンテナが読み込まれています。ページソースで gtm.js?id=GTM- を検索して異なるIDが何件出てくるかも同時に確認します。
GTMの管理画面でアカウント配下にあるコンテナIDをリストアップし、ページで読み込まれているIDと照合することで、それぞれのコンテナが誰の管理下にあるかを特定できます。自社管理のコンテナか、エージェンシーが設置したコンテナか、旧担当者が残したものかを把握してから次のアクションを決めます。
コンテナ統合か不要コンテナ除去かの判断フローと実施手順
複数コンテナが存在する場合の対処法は2択です。
選択肢A:どちらかに統合する 両コンテナに現役で動いているタグがある場合は統合が必要です。GTMのコンテナ設定→「エクスポート」から移行元のタグ・トリガー・変数設定をJSONでダウンロードし、統合先コンテナにインポートします。その後、移行元コンテナのGTMスニペットをHTMLから除去して計測を1系統にまとめます。コンテナ統合は設定の複雑度が上がるため、ステージング環境での検証と、作業前後のバージョン書き出しが推奨されます。
選択肢B:不要なコンテナを特定して除去する どちらかのコンテナが実質何も動かしていない(タグが全部一時停止・未設定)なら、そちらのGTMスニペットをHTMLから除去するだけで解決します。除去後にGTMプレビューで残ったコンテナが正常に動作していることを確認し、Networkタブで発火数を確認します。
修正後の検証手順とモニタリング設計
DebugViewで修正後の発火件数が1件になったことを確認する手順
GTM公開またはHTMLのデプロイが完了したら、ChromeのTag Assistant拡張機能をアクティブにした状態で対象ページを開きます。GA4管理画面の「DebugView」のタイムラインで page_view イベントが1件だけ表示されていれば正常化確認完了です。
確認の際は、GTMプレビューモードを終了した状態で行うことを推奨します。GTMプレビューが起動中だと追加のデバッグリクエストが発生し、DebugViewの表示件数が変動することがあります。Tag Assistantのみ有効にした通常閲覧状態での確認が最も信頼できます。
2件表示が続く場合は修正が不完全です。Networkタブに戻り、どのタイミングで2件目のcollectリクエストが送信されているか(Container Loaded時か、Window Loaded時か)を確認して残存する原因を特定します。
GA4レポートのイベント数が正常化するまでのタイムラグと修正日記録の重要性
DebugViewはリアルタイムで確認できますが、GA4の標準レポートへの反映には24〜48時間のタイムラグがあります。修正直後にレポートを見ても数値が変わっていないのは正常な動作です。
修正を実施したら、必ず修正日をGA4アノテーション相当の場所に記録してください。GA4には標準のアノテーション機能がないため、Looker Studioのレポートに日付メモを入れる、スプレッドシートで計測変更ログを管理するなどの方法が現実的です。
記録しておかないと、数週間後に「この日からイベント数が半分になった」というデータを見て別の問題が起きたと誤解するケースが生じます。修正前の重複データは遡及修正できないため、前後のデータを比較する際は必ず修正日を基点に日付軸で区切って分析する必要があります。
修正後も念のため数日間はリアルタイムレポートで計測件数を監視し、異常な急減・急増がないことを確認してから通常の監視体制に戻すと安心です。GA4内の重複発火が解消してもGoogle広告のコンバージョン数との差異が残る場合は、GA4とGoogle広告のコンバージョン数が合わない原因7パターンも合わせて確認してみてください。また、GA4キーイベントのGoogle広告へのインポートに問題が続く場合はGA4キーイベントがGoogle広告にインポートできない・反映されない原因切り分けを参照してください。計測の正常化後に広告CV側の重複診断まで行いたい場合は広告CVのダブルカウントを発見・修正する実務手順が参考になります。
よくある質問
Q:GA4でイベントが2回発火する原因はGTMとgtag.jsの両方が入っているから?
最も多い原因はGTM×直実装(gtag.js)の混在ですが、GTM内に同じGA4設定タグが複数ある場合や、複数のGTMコンテナが同一ページに読み込まれている場合も同様の症状が起きます。まずNetworkタブで collect?v=2 リクエストが何件発生しているかを確認し、2件あれば重複確定、その後GTMプレビューとページソース確認でパターンを特定するのが最短の診断手順です。
Q:GA4 DebugViewでイベントが重複して表示される場合、どこを確認すればよい?
同一イベント名(例: page_view)が連続して2件表示されていれば二重発火確定です。次のステップとしてGTMプレビューを開き、「Tags Fired」の一覧で同じGA4設定タグが2回発火していないかを確認します。GA4設定タグの発火が1回のみであれば、GTM外(直実装のgtag.js)が原因と特定できます。GTMプレビューの使い方や接続トラブルはGTMプレビューが接続できない・タグが発火しない原因切り分けチェックリストも参考になります。
Q:GTMとGA4の直実装(gtag.js)が共存している場合、どちらを残すべき?
原則はGTMへの一本化です。マーケティング担当者がタグを管理する場合、HTMLを直接編集しなくてよいGTM運用の方が長期的に安定します。ただし、サーバーサイドGTMとの接続構成や特定のeコマース計測の要件でgtag.jsが必要な場合は、直実装を残してGTM側のGA4設定タグを削除します。「両方を残す」という選択肢は重複発火の原因そのものになるため、どちらかに必ず一本化してください。
Q:GA4の重複計測を修正してからレポートが正常化するまで何日かかる?
DebugViewはリアルタイムで確認できるので、修正直後に正常化を検証できます。一方、GA4の標準レポートへの反映は通常24〜48時間かかります。修正前の重複データは遡及修正できないため、修正を実施した日付をGA4アノテーション相当の記録媒体に必ず残してください。修正後にレポート数値が「急に半分になった」と見えても、それは計測の正常化であり異常ではありません。
GA4とGTMの計測設計は、複数の担当者やエージェンシーが関与する環境では予期しない重複が起きやすい構造になっています。真策堂では、GA4・GTMの計測設計の見直しや既存設定の診断・修正相談を受け付けています。イベント計測の正確性に不安がある場合や、設計の考え方から整理したい場合はお気軽にお問い合わせください。
- アクセス解析
広告CVのダブルカウントを発見・修正する実務手順|GA4×Google広告×Meta広告の計測ズレ診断と正規化フロー
広告コンバージョンの重複計測(ダブルカウント)をGA4・Google広告・Meta広告の3媒体横断で診断・修正する実務フレームを解説。GTMタグ重複・GA4インポートCV二重計上・Meta Pixel+CAPI重複排除の対処手順と正規化フローを体系化します。
- アクセス解析
GTMプレビューが接続できない・タグが発火しない原因切り分けチェックリスト|Tag Assistantのつまずき診断フロー
GTMプレビューモードがConnectedにならない・Tag Assistantに表示されない・タグが発火しない原因をブラウザ/GTM設定/CSP/サイト側の3層で切り分け。症状別チェックリストとCSP診断手順を実務担当者向けに解説します。当日中に原因特定できます。
- アクセス解析
GA4とGoogle広告のコンバージョン数が合わない原因7パターン|計測期間・アトリビューション・カウント方式の突き合わせ手順
GA4とGoogle広告でコンバージョン数が合わない原因を、アトリビューション・カウント方式・クリック日/CV日・ルックバック・ビュースルー・タイムゾーン・データしきい値の7パターンで切り分け。管理画面の確認手順と優先順位付きチェックリストで当日中に原因特定できます。