Googleタグマネージャーでよくあるエラーと原因・解決方法を徹底解説

Googleタグマネージャーでタグが発火しない、Tag Assistantにつながらない、GA4に反映されない原因を症状別に解説。よくあるエラーの確認方法と解決手順を初心者向けにわかりやすく紹介します。

Googleタグマネージャーを設定したのに、「タグが発火しない」「Tag Assistantにつながらない」「GA4にデータが反映されない」と困ったことはありませんか。GTMのエラーは、コンテナコードの設置ミスやトリガー条件、測定IDの間違い、未公開、キャッシュ、WordPress側の設定など、さまざまな原因で起こります。この記事では、GTMでよくあるエラーを症状別に整理し、原因の調べ方から具体的な解決方法まで初心者向けにわかりやすく解説します。どこから確認すればよいか分からない方も、順番にチェックできる内容です。

Googleタグマネージャーでエラーが起こる主な原因

Googleタグマネージャー（GTM）で「タグが発火しない」「GA4にデータが送られない」「Tag Assistantで確認できない」といったトラブルが起きる場合、原因は1つとは限りません。

GTMでは、コンテナコード・タグ・トリガー・変数・公開状態・GA4・WordPress側の設定など、複数の要素が関係しています。

そのため、エラーが起きたときは設定を次々に変更するのではなく、まず原因になりやすい場所を整理して確認することが大切です。

代表的な原因をまとめると、次のようになります。

主な原因	起こりやすい症状	最初に確認する場所
GTMコードの設置ミス	GTM自体が認識されない	コンテナコード
タグ・トリガーの設定ミス	タグが発火しない	GTMワークスペース
未公開	設定変更が本番サイトに反映されない	送信・公開状態
GA4のID間違い	GA4にデータが届かない	データストリーム
WordPress側の設定	二重計測・発火しない	テーマ・プラグイン
キャッシュなど	変更内容が古いまま表示される	ブラウザ・キャッシュ

GTMコンテナコードが正しく設置されていない

GTMを利用するためには、WebサイトにGoogleタグマネージャーのコンテナコードが正しく設置されている必要があります。

Web用コンテナでは、基本的に2つのコードがあります。

• 1つ目：<head>内のできるだけ上の位置
• 2つ目：<body>開始タグの直後

Google公式でも、1つ目のスニペットを<head>内の上部、2つ目を<body>開始タグの直後に配置するよう案内しています。

たとえば、コードを手動で設置した際に、

• 一部しかコピーしていない
• GTMコンテナIDを書き換えてしまった
• 別サイト用のGTMコードを貼っている
• 特定ページだけコードが読み込まれていない

といった状態になっていると、GTMが正常に動作しないことがあります。

特にWordPressでは、テーマ設定やプラグインを使ってGTMを設置することもあるため、同じコードを複数の方法で入れないことも重要です。

タグ・トリガー・変数の設定が間違っている

GTMのコンテナ自体が正常でも、タグ・トリガー・変数の設定に間違いがあると、期待した計測ができません。

それぞれの役割を簡単に整理すると、次のとおりです。

項目	主な役割
タグ	GA4などへデータを送信する
トリガー	タグを動かす条件を決める
変数	URLやクリック情報などの値を利用する

たとえば「お問い合わせボタンのクリック数を計測したい」とします。

タグ自体が正しく作られていても、トリガーで

「Click URL に /contact/ を含む」

と設定すべきところを、

「Page URL に /contact/ を含む」

としてしまうと、想定したクリックでタグが発火しないことがあります。

エラーが起こったときは、タグだけを見るのではなく、

• タグの種類
• トリガーの条件
• 使用している変数
• URLや文字列の指定

をセットで確認しましょう。

設定を保存しただけで公開していない

GTM初心者に特に多いのが、設定を保存したことで本番サイトにも反映されたと思ってしまうケースです。

GTMではタグやトリガーを編集して「保存」しても、それだけでは通常、本番サイトに変更内容は公開されません。

設定後は、

1. プレビューモードで動作確認する
2. 問題がないことを確認する
3. 「送信」をクリックする
4. 「バージョンの公開と作成」を選択する
5. 公開する

という流れで進めます。

Google公式でも、変更内容をサイトへ反映するには「送信」から「バージョンの公開と作成」を選び、公開する手順が案内されています。

たとえば、トリガーを修正してプレビューでは正常に動いたのに、本番サイトでは以前のままという場合は、公開忘れを疑ってみましょう。

GA4の測定ID・タグIDを間違えている

GTMからGA4へアクセスデータを送る場合、正しいGoogleタグID・測定IDを指定することが重要です。

GA4のWebデータストリームには、「G-」などで始まる測定IDがあります。Google公式では、GA4の「管理」→「データストリーム」から対象のWebデータストリームを開くことで測定IDを確認できます。

たとえば、

本来使うID
G-XXXXXXXXXX

とは別のプロパティのIDを設定してしまうと、タグ自体は動作していても、別のGA4プロパティへデータが送信される可能性があります。

そのため、GA4にデータが表示されない場合は、

• 使用しているGA4プロパティ
• Webデータストリーム
• 測定ID
• GTM側で設定したID

が一致しているか確認してください。

Google公式でも、GA4でデータが表示されない原因として、タグの未設置・設置ミス・タグIDの間違いなどが案内されています。

WordPress側の設定やプラグインが影響している

WordPressでは、GTM以外にもさまざまな方法でGoogle関連のタグを設置できます。

そのため、GTM側だけを確認しても原因が分からない場合があります。

たとえば、

• WordPressテーマ側でGoogleタグを設定している
• GTM設置用プラグインを利用している
• Site KitなどでGoogle関連サービスを設定している
• 別のプラグインでアクセス解析コードを設置している
• キャッシュ・JavaScript最適化機能を利用している

といったケースです。

特に注意したいのが、同じ計測コードの二重設置です。

たとえば、WordPress側でGoogleタグを直接設置し、さらにGTMから同じ計測を行っていると、設定方法によってはページビューなどが重複して記録される原因になります。

Google公式でも、GoogleタグとTag Managerの実装を重複させると、データが重複カウントされるなど意図しない結果になる可能性があると案内しています。

エラーを調べるときは、GTMだけではなくWordPress側でタグをどのように設置しているかも確認しましょう。

ブラウザ・キャッシュ・Cookieが影響している

設定を直したのに表示や動作が変わらない場合は、ブラウザやキャッシュの影響も考えられます。

たとえば、次のようなケースがあります。

• ブラウザに古いページ情報が残っている
• WordPressのキャッシュが残っている
• CDN側に古いファイルが残っている
• JavaScriptの最適化によって読み込み順が変わっている
• Cookieや同意設定によって計測が制限されている

特に、「設定は正しいはずなのに自分のパソコンだけ動かない」という場合は、ブラウザ側の影響も疑ってみましょう。

確認するときは、

• ページを再読み込みする
• キャッシュを削除する
• シークレットウィンドウで開く
• 別のブラウザで確認する

といった方法が役立ちます。

ただし、キャッシュを削除する前にGTMの設定そのものが間違っていないかを確認することも大切です。

まず確認したいGTMエラーの基本チェック

GTMでエラーが起きると、「タグを作り直した方がいいのでは？」と考えてしまいがちです。

しかし、最初から複雑な設定を変更する必要はありません。

まずは、GTMの土台となる部分が正常かどうかを確認しましょう。

おすすめの確認順序は次のとおりです。

順番	確認する項目	判断すること
1	コンテナID	正しいGTMを使っているか
2	GTMコード	サイトに設置されているか
3	公開状態	最新変更が公開されているか
4	Tag Assistant	GTMを認識できるか
5	シークレットウィンドウ	ブラウザの影響がないか

この順番で確認すると、問題の範囲を少しずつ絞り込めます。

正しいGTMコンテナIDを使用しているか確認する

最初に確認したいのが、GTMコンテナIDです。

GTMのWebコンテナIDは、

GTM-XXXXXXX

のように「GTM-」から始まります。

Googleタグマネージャーの管理画面で対象コンテナを開き、表示されているコンテナIDと、サイトに設置されているIDが同じか確認します。Google公式の設置手順でも、ワークスペースから「GTM」で始まるコンテナIDを選択してコードを確認する方法が案内されています。

たとえば、テストサイトと本番サイトで別々のコンテナを使っている場合、誤ってテスト用のコンテナIDを本番サイトへ設置してしまうことがあります。

まずは、

• GTM管理画面のID
• WordPressに設定したID
• 実際のWebサイトで読み込まれているID

が一致しているか確認しましょう。

headとbody直後にGTMコードが設置されているか確認する

次に、GTMコンテナコードの設置場所を確認します。

Google公式では、Webコンテナについて、

• 1つ目のコード：<head>内のできるだけ上
• 2つ目のコード：<body>開始タグの直後

に設置するよう案内しています。

WordPressではテーマやプラグインによって自動挿入される場合もあるため、必ずしも自分でHTMLを直接編集する必要はありません。

むしろ、初心者の場合はテーマファイルを直接編集するより、現在利用しているテーマや導入方法を確認してから設定する方が安全です。

確認したいポイントは次のとおりです。

• GTMコードが途中で切れていない
• コンテナIDが正しい
• 必要なコードが読み込まれている
• 同じGTMコードを二重に設置していない
• 特定ページだけGTMが抜けていない

コードをむやみに貼り直す前に、現在どの方法でGTMを設置しているのか確認してください。

ワークスペースに未公開の変更がないか確認する

GTMのワークスペースに変更内容が残っている場合、まだ本番環境へ公開されていない可能性があります。

たとえば、

「昨日トリガーを修正したのに、今日もタグが発火しない」

という場合、修正自体は保存されていても、公開されていないことがあります。

確認するときは、

• ワークスペースに変更内容が表示されていないか
• 最後に公開したバージョンはいつか
• 修正内容が公開済みバージョンに含まれているか

を確認しましょう。

GTMでは、保存と公開は別の操作です。Google公式でも、「バージョンを作成」だけなら公開せず保存でき、「バージョンの公開と作成」を選ぶことでサイトに変更を反映すると案内されています。

ただし、公開前には必ずプレビューモードで正常に動くことを確認してください。

Tag AssistantでGTMが認識されているか確認する

GTMの設置状態やタグの発火を調べるときに便利なのが、Tag Assistantです。

GTMのワークスペース右上にある「プレビュー」をクリックすると、Google Tag Assistantを使った確認を行えます。

基本的な流れは、

1. GTMの「プレビュー」をクリックする
2. 確認したいサイトURLを入力する
3. 「接続」をクリックする
4. 対象サイトを操作する
5. Tag Assistantでタグの状態を確認する

となります。

Google公式でも、この方法でTag Assistantを起動し、対象サイトへ接続してタグを検証する手順が案内されています。

Tag AssistantでGoogleタグが検出されない場合は、

• 正しいIDを設定しているか
• コードが実際に読み込まれているか

を確認するのが基本です。

Tag Assistantを使った確認方法や、プレビューモードでのデバッグ手順については、「Googleタグマネージャーのプレビューモードとは？デバッグ方法を詳しく解説」で詳しく紹介しています。

シークレットウィンドウでも確認してみる

通常のブラウザでうまく動作しない場合は、シークレットウィンドウやプライベートブラウズで確認する方法もあります。

シークレットウィンドウでは、通常の閲覧環境とはCookieやキャッシュの状態が異なるため、ブラウザ側の影響かどうかを切り分ける材料になります。

たとえば、

通常画面ではタグが発火しない
↓
シークレットウィンドウでは正常に発火する

という場合は、通常ブラウザ側のキャッシュ、Cookie、拡張機能などが影響している可能性を考えられます。

ただし、シークレットウィンドウで正常ならGTM設定が必ず正しい、と断定できるわけではありません。

GTMエラーを確認するときは、

• コンテナID
• コード設置
• 公開状態
• Tag Assistant
• ブラウザ環境

という順番で切り分けていくと、原因を見つけやすくなります。

「Tag Assistantに接続できない」原因と解決方法

Googleタグマネージャーのプレビューモードを使おうとしても、Tag Assistantにサイトが接続されず、確認作業を進められないことがあります。

Tag Assistantは、GTMのタグが正しく設置されているか、どのイベントでタグが発火したかなどを確認するための重要なデバッグツールです。

接続できない場合は、いきなりGTMの設定を作り直すのではなく、次の順番で原因を確認してみましょう。

主な原因	確認するポイント	主な対処方法
URL間違い	入力したURL・ドメイン	正しいURLを入力する
タグ未設置	GTMコード	設置状態を確認する
拡張機能	広告ブロッカーなど	一時的に無効化する
Cookie・キャッシュ	ブラウザ環境	削除・再接続する
リダイレクト	URL転送	最終URLを確認する
CSPなど	セキュリティ設定	ブロック状況を確認する

サイトURLの入力が間違っていないか確認する

まず確認したいのが、Tag Assistantへ入力したサイトURLです。

GTMの「プレビュー」をクリックするとTag Assistantが開き、確認したいWebサイトのURLを入力します。

たとえば、

Example Domain

example.com

へ接続したいのに、

http://example.com/

や古いドメイン、存在しないページURLを入力していると、正常に接続できないことがあります。

特に注意したいのは、次のようなケースです。

• httpとhttpsを間違えている
• wwwあり・なしが異なる
• サイト移転前のURLを入力している
• 削除済みのページを入力している
• GTMが設置されていないページを指定している

Google公式でも、接続できない場合は、正しいドメイン名・WebサイトURLを使用しているか確認することが案内されています。

まず実際にブラウザで対象URLを開き、正常にページが表示されるか確認してからTag Assistantへ入力しましょう。

GTMコードがサイトに読み込まれているか確認する

URLが正しくても、対象ページにGTMのコンテナコードが読み込まれていなければ、Tag Assistantで正常にデバッグできない場合があります。

前の章でも説明したとおり、Web用GTMではコンテナコードが正しくサイトへ設置されていることが基本です。

たとえば、

• トップページにはGTMが入っている
• 固定ページにはGTMが入っていない
• テーマ変更後にGTMコードが消えた
• プラグインを停止したことでGTMも読み込まれなくなった

といったことがあります。

Google公式も、Tag Assistantが接続できない場合は、接続先ページにGoogleタグが存在しているか確認することを案内しています。

確認するときは、

• 対象ページでGTMが読み込まれているか
• コンテナIDが正しいか
• 特定のページだけタグが抜けていないか

を確認しましょう。

また、Googleタグの読み込みが遅く、Tag Assistantが先に接続を試みてしまうケースでは、Google公式は「Retry」で再接続する方法も案内しています。

広告ブロッカーやブラウザ拡張機能を確認する

ブラウザに広告ブロッカーやプライバシー保護系の拡張機能を入れている場合、Googleタグの読み込みが止められることがあります。

たとえば、

• 広告ブロック拡張機能
• トラッキング防止機能
• JavaScriptを制限する拡張機能
• セキュリティ系ブラウザ拡張機能

などです。

Google公式でも、広告ブロッカーによってGoogleタグが実行されず、Tag Assistantが正常に接続できない場合があると案内しています。

原因を切り分けるときは、まずテスト対象のページだけ広告ブロッカーなどを一時的に無効にして、もう一度接続してみましょう。

また、Tag AssistantのChrome拡張機能を使用している場合は、対象サイトについてサイトデータを読み取り・変更する権限が許可されているかも確認してください。

ただし、普段利用しているセキュリティ機能をむやみにすべて解除する必要はありません。テストに必要な範囲だけ変更し、確認後は元に戻すと安心です。

Cookie・キャッシュを削除して再接続する

GTMやTag Assistantの設定を修正した直後は、ブラウザに残っているCookieやキャッシュの影響で、古い状態が表示されることがあります。

たとえば、

「GTMコードを修正したのにTag Assistantでは以前と同じ状態」

という場合です。

このようなときは、

• ページを再読み込みする
• ブラウザキャッシュを削除する
• Cookieを確認する
• シークレットウィンドウで試す
• 別のブラウザで確認する

といった方法で状況が変わるか確認してみましょう。

ただし、キャッシュ削除だけで必ず接続エラーが解消するわけではありません。

URL、GTMコード、広告ブロッカーなども併せて確認し、原因を一つずつ切り分けることが大切です。

リダイレクトが原因で接続できない場合を確認する

サイト内で複数回のリダイレクトが発生していると、Tag Assistantのデバッグウィンドウが正常に読み込めない場合があります。

リダイレクトとは、あるURLへアクセスしたときに別のURLへ自動転送する仕組みです。

たとえば、

http://example.com

↓

Example Domain

example.com

↓

Example Domain

www.example.com

のように複数回転送されるケースです。

Google公式でも、複数のブラウザリダイレクトによってデバッグウィンドウを読み込めない場合があると案内しています。

Tag Assistantに入力したURLと、最終的にブラウザへ表示されるURLが異なる場合は注意してください。

確認するときは、

• 入力したURL
• 転送先URL
• 最終的に表示されるURL
• GTMが設置されているURL

を比較してみましょう。

必要であれば、最終的に表示されるURLを直接Tag Assistantへ入力して確認します。

セキュリティ設定やCSPによるブロックを確認する

ここまで確認しても接続できない場合は、Webサイト側のセキュリティ設定も原因として考えられます。

代表的なものが**CSP（Content Security Policy）**です。

CSPは、Webページで読み込めるスクリプトや外部リソースなどを制限するセキュリティ機能です。

設定によってGoogle関連のスクリプトが許可されていない場合、GTMやTag Assistantが正常に動作しないことがあります。

また、

• ファイアウォール
• プロキシサーバー
• セキュリティプラグイン
• 同意管理ツール（CMP）
• Cookie同意設定

などがGoogleタグの動作へ影響する場合もあります。

Google公式でも、Tag Assistantの接続問題について、ファイアウォール・プロキシ・CSP・同意管理ツールなどによるブロックを確認することが案内されています。

初心者の場合、CSPを自己判断で変更するとサイトのセキュリティへ影響する可能性があるため、設定内容が分からないときは無理に変更せず、サーバー会社やサイト管理者へ確認する方が安全です。

「タグが発火しない」原因と解決方法

Tag Assistantには接続できたものの、設定したタグが発火しないこともあります。

この場合は、GTM自体の設置よりも、トリガー・イベント・URL条件・除外条件・発火タイミングなどを確認することが重要です。

タグは、設定したトリガーの条件を満たしたときに発火します。そのため、タグだけを見ていても原因が分からない場合があります。

確認ポイントをまとめると、次のとおりです。

確認項目	よくある原因	確認方法
トリガー	条件設定ミス	条件式を確認
イベント	種類が違う	Tag Assistantでイベント確認
URL条件	演算子の指定ミス	含む・等しいを確認
除外条件	発火をブロック	Exceptionsを確認
タイミング	発火時点が早い・遅い	イベント順を確認
発火結果	条件未達	Tag Assistantで確認

トリガーの条件が正しいか確認する

タグが発火しない場合、最初に確認したいのがトリガーです。

GTMでは、タグを作っただけでは通常は発火せず、「いつタグを動かすか」をトリガーで指定します。

たとえば、問い合わせ完了ページだけでタグを発火したい場合、

Page URL contains /thanks/

などの条件を設定できます。

しかし、

• URLの文字列を間違えている
• Page URLとClick URLを間違えている
• 条件を厳しく設定しすぎている
• 「すべて」ではなく「一部」の設定が間違っている

と、タグは発火しません。

Google公式でも、トリガーはページ読み込み・クリック・フォーム送信などのイベントを監視し、指定した条件を満たした場合にタグを発火させる仕組みとして説明されています。

タグが発火しないときは、まず**「そのイベントで、本当にトリガー条件が成立しているか」**を確認しましょう。

Page Viewなどイベントの種類を確認する

GTMでは、タグを発火させるタイミングによって使用するイベントやトリガーが異なります。

ページ表示に関連する代表的なタイミングには、

• Initialization
• Consent Initialization
• Page View
• DOM Ready
• Window Loaded

などがあります。

一般的なページ表示時の計測ならPage Viewを使うケースが多いですが、ページ内の要素が読み込まれた後でなければ取得できない値を利用する場合は、DOM Readyなど別のタイミングが適することもあります。

また、クリック計測であれば、

• Click
• Link Click

など、ページビューとは異なるイベントを利用します。

たとえば、

「ボタンをクリックしたら発火させたい」

のにPage Viewトリガーだけを設定していても、目的に合った計測にはなりません。

Google公式でも、タグはページ読み込み、ボタンクリック、スクロールなどのイベントに応じて発火すると説明されています。

**「何をしたときにタグを動かしたいのか」**を先に整理してから、イベントの種類を確認しましょう。

URL条件の「含む」「等しい」の違いを確認する

GTMのトリガー設定では、「含む」「等しい」など条件の指定方法によって結果が変わります。

たとえば、次のURLがあるとします。

Example Domain

example.com

トリガーを、

Page URL 等しい https://example.com/contact/thanks/

と設定した場合、?id=123まで含めた実際のURLとは完全一致しないため、条件を満たさないことがあります。

一方、

Page URL 含む /contact/thanks/

とすれば、その文字列を含むURLで条件が成立しやすくなります。

簡単に整理すると、

条件	意味	使用例
等しい	完全一致	URLが常に固定の場合
含む	指定文字列を含む	パラメータが変わる場合
始まる	指定文字列から開始	URLの先頭条件
正規表現	パターンで判定	複数条件をまとめたい場合

ただし、「含む」は便利な反面、条件を広くしすぎると、意図していないページでも発火する可能性があります。

初心者の場合は、まず実際のURLをTag Assistantで確認してから条件を設定すると間違いを減らせます。

除外トリガーが設定されていないか確認する

トリガー条件が正しいのにタグが発火しない場合は、**除外トリガー（例外・Blocking Trigger）**も確認してください。

GTMでは、

「この条件ではタグを発火する」

というトリガーだけでなく、

「この条件ではタグを発火させない」

という例外を設定できます。

たとえば、

• 全ページで発火
• ただし /admin/ を含むページでは除外

という設定ができます。

Google公式では、発火トリガーの条件を満たしていても、該当するトリガー例外がある場合はタグが発火しないことが説明されています。

以前テスト用に設定した除外条件を忘れているケースもあるため、

• タグを開く
• トリガー設定を確認する
• Exceptions・例外がないか確認する

という順番で確認しましょう。

タグの発火タイミングを確認する

タグは、どのタイミングで発火するかによって計測結果が変わります。

たとえば、ページが完全に表示される前に取得しようとしている変数が、まだ存在していない場合があります。

逆に、ページ遷移が非常に早いクリックでは、タグがデータを送信する前に次のページへ移動してしまうケースもあります。

GTMではタグごとに、

• イベントごとに1回
• ページごとに1回
• 条件に応じて複数回

など、発火動作にも違いがあります。

Google公式ではWebコンテナのタグ発火オプションとして、**Once per event（イベントごとに1回）やOnce per page（ページごとに1回）**などが用意されています。

「発火しない」と思ったときは、単にトリガーだけではなく、

• どのイベントで発火させるのか
• その時点で必要な変数が取得できているか
• 発火回数の設定
• ページ遷移とのタイミング

も確認してみましょう。

Tag Assistantの「Tags Not Fired」で原因を調べる

タグが発火しない原因を調べるときに、Tag Assistantが役立ちます。

プレビューモードでサイトを操作すると、ページビューやクリックなどのイベントごとに、どのタグが発火したか、どのタグが発火しなかったかを確認できます。

確認の基本的な流れは、

1. GTMで「プレビュー」を開く
2. サイトへ接続する
3. 調べたい操作を行う
4. Tag Assistantで対象イベントを選択する
5. 発火したタグ・発火しなかったタグを確認する
6. トリガーや変数の値を確認する

となります。

たとえば、お問い合わせボタンをクリックしてもタグが発火しない場合、

• Clickイベント自体は発生しているか
• Click URLの値は何か
• トリガー条件と一致しているか
• 除外条件に該当していないか

を順番に見ていきます。

Google公式でも、プレビューモードではタグが正常に発火したか、何が発火・非発火の原因になったかを確認できると説明しています。

つまり、「タグが発火しない」という結果だけを見るのではなく、

イベント発生 → 変数の値 → トリガー条件 → タグの発火

という順番で調べるのがポイントです。

この方法を覚えておけば、設定を何度も作り直さなくても、どこで条件が合わなくなっているのかを見つけやすくなります。

「タグが二重に発火する」原因と解決方法

Googleタグマネージャーを使っていると、1回しかページを表示していないのに、同じイベントが2回記録されることがあります。

このような状態を「二重発火」「二重計測」と呼ぶことがあります。

たとえば、本来1回だけ記録されるはずのpage_viewが2回送信されると、GA4のページビュー数やイベント数が実際より多くなる可能性があります。

Google公式でも、GoogleタグとGoogleタグマネージャーを重複して設置すると、データが過剰に計測されるなど意図しない結果になる可能性があると案内しています。

まずは次の順番で確認してみましょう。

確認項目	よくある原因	対処方法
WordPress	テーマとGTMで重複	設置方法を1つに整理
GA4	直接コードとGTMが重複	どちらかに統一
Site Kit	Analyticsコードも出力	設定を確認
トリガー	同じタグを複数条件で発火	条件を整理
発火オプション	発火回数が多い	詳細設定を確認
GA4	修正後も重複している	リアルタイム等で確認

GTMとWordPressの両方にタグを設置していないか確認する

まず確認したいのが、WordPress側とGTM側の両方に同じ計測設定が入っていないかどうかです。

WordPressでは、

• テーマ機能
• プラグイン
• カスタムHTML
• Site Kit
• GTM

など、複数の方法でアクセス解析コードを設置できます。

たとえば、WordPressテーマにGA4の測定IDを入力し、さらにGTMからGoogleタグを配信していると、同じページビューが2回送信されることがあります。

特に、以前はWordPressへ直接GA4を設定し、その後GTMへ移行した場合は注意が必要です。

確認するときは、

• WordPressテーマのアクセス解析設定
• GTMのGoogleタグ
• Analytics関連プラグイン
• Site Kit
• 手動で追加したコード

を一つずつ確認しましょう。

大切なのは、どの方法でGA4を計測するのかを明確にすることです。

GA4コードを直接設置していないか確認する

GTMを使ってGA4を設定している場合は、WebサイトにGoogleタグを直接設置していないか確認してください。

Google公式では、Google Analyticsの設置について、GoogleタグまたはGoogleタグマネージャーのどちらか一方を使用するよう案内しています。両方を重複して使用すると、データが過剰計測されるなどの問題が起こる可能性があります。

たとえば、

• HTMLへ直接Googleタグを貼り付けている
• Cocoonなどのテーマ側に測定IDを登録している
• GTMからも同じGA4へ送信している

という状態では、二重計測の原因になります。

GTMに移行した場合は、以前使用していたGA4の直接設置コードが残っていないか確認しましょう。

ただし、削除する前に現在どの設定でGA4が動いているかを確認してください。設定を把握せずにコードを削除すると、今度は計測そのものが止まる可能性があります。

Site Kitとの重複設定を確認する

WordPressでGoogle Site Kitを使用している場合も、GA4の設置方法を確認しましょう。

Site KitはGoogle AnalyticsなどのGoogleサービスとWordPressを連携するためのプラグインです。

注意したいのは、

• Site Kit側でAnalyticsコードを配置
• GTM側でもGoogleタグを配信

という状態になっている場合です。

このような構成では、設定内容によっては同じGA4プロパティへ重複してデータを送信する可能性があります。

確認するときは、

• Site KitでAnalyticsが接続されているか
• AnalyticsコードをSite Kitが設置しているか
• GTMにもGoogleタグが設定されているか
• 両方の送信先が同じGA4プロパティか

を見てください。

重要なのは、Site Kitを使っていること自体が問題なのではなく、GA4タグをどの方法で設置しているかです。

Site Kitをダッシュボード確認だけに利用し、実際の計測タグはGTMから配信する、といった運用もあります。

複数のトリガーが同じタグを発火させていないか確認する

タグの設置方法が1つでも、GTM内部のトリガー設定によって同じタグが複数回発火する場合があります。

たとえば、1つのタグに、

• All Pages
• Page Viewの特定条件
• カスタムイベント

など複数のトリガーを設定している場合です。

同じページで複数の条件が成立すると、設定によっては同じタグが複数回発火することがあります。

たとえば、

「全ページで発火」

と、

「URLに/blog/を含むページで発火」

を同じタグに設定していると、ブログ記事では両方の条件が成立する可能性があります。

確認するときは、

• 1つのタグに何個のトリガーが付いているか
• 同じページで複数条件が成立していないか
• 不要なカスタムイベントがないか

を確認してください。

Tag Assistantでイベントごとの発火状況を見ると原因を見つけやすくなります。

タグの発火オプションを確認する

GTMでは、タグごとに発火回数を制御できます。

Google公式では、タグの詳細設定に次のような発火オプションが用意されています。

• 無制限
• 1回のイベントにつき1度
• 1ページにつき1度

「1回のイベントにつき1度」は、同じイベントでタグが複数回発火するのを防ぎたい場合に利用できます。

「1ページにつき1度」は、ページ内で1回だけタグを発火させたい場合に利用できます。

簡単に整理すると次のとおりです。

発火オプション	主な動作
無制限	トリガー条件に応じて発火
1回のイベントにつき1度	同じイベント内では1回
1ページにつき1度	1ページ内で1回

ただし、二重計測が起きているからといって、発火オプションだけを変更すればよいとは限りません。

まず、

• タグの重複
• トリガーの重複
• GA4直接設置との重複

を確認したうえで、発火オプションも見直しましょう。

二重計測を解消したあとGA4で確認する

原因を修正したら、GA4側で二重計測が解消されたか確認します。

おすすめは、実際に自分でサイトへアクセスしてテストする方法です。

たとえば、

1. Tag Assistantでページを開く
2. page_viewが何回発生しているか確認する
3. GA4のリアルタイムレポートを開く
4. ページを移動する
5. イベント数が不自然に増えていないか確認する

という流れです。

ただし、GA4にはデータ処理の時間差があるため、通常レポートだけで判断せず、まずはTag Assistantやリアルタイムレポートで確認すると分かりやすいです。

二重計測を防ぐポイントは、

• 計測方法を1つに整理する
• 不要なタグを削除する
• トリガーの条件を整理する
• 公開前にプレビューする

ことです。

「GA4にデータが反映されない」原因と解決方法

GTMではGoogleタグが正常に発火しているのに、GA4を見るとアクセスデータが表示されないことがあります。

この場合は、

GTM → Googleタグ → GA4

というデータの流れのどこで問題が起きているかを確認します。

Google公式では、GA4にデータが表示されない主な原因として、

• Googleタグが設置されていない
• タグが正しく設置されていない
• タグIDが間違っている
• GTMの変更が公開されていない
• データ処理がまだ完了していない

などを挙げています。

確認ポイントをまとめると次のとおりです。

確認項目	主な原因
測定ID	別プロパティへ送信
Googleタグ	発火していない
リアルタイム	データ受信の確認
内部トラフィック	自分のアクセスを除外
同意設定	Analytics計測を制限
GTMとGA4	途中でデータが止まっている

GA4の測定ID・タグIDが正しいか確認する

最初に確認したいのが、GA4の測定IDです。

GA4のWebデータストリームには、

G-XXXXXXXXXX

のような測定IDがあります。

Google公式では、

「管理」
↓
「データストリーム」
↓
対象のWebストリーム

から測定IDを確認するよう案内しています。

たとえば、本番サイト用のGA4プロパティとテストサイト用のプロパティを持っている場合、誤ってテスト用測定IDをGTMへ入力してしまうことがあります。

この場合、GTMではタグが正常に発火していても、確認しているGA4プロパティにはデータが表示されません。

次の項目が一致しているか確認しましょう。

• GA4のプロパティ
• Webデータストリーム
• 測定ID
• GTMのGoogleタグで指定したID

「タグが発火しているから設定は正しい」とは限らない点が重要です。

Googleタグが正常に発火しているか確認する

測定IDが正しければ、次にGoogleタグが実際に発火しているか確認します。

GTMのプレビューモードを開き、Tag Assistantでページを表示します。

確認したいのは、

• Googleタグが発火しているか
• page_viewなど必要なイベントが発生しているか
• 対象の測定IDへ送信しているか
• タグが「Not Fired」になっていないか

です。

もしGoogleタグが発火していなければ、GA4側を確認する前にGTM側のトリガーや設定を修正する必要があります。

逆に、Googleタグが正常に発火している場合は、GA4側の設定へ原因を絞り込めます。

GA4のリアルタイムレポートで確認する

GTMの設定を変更したあとは、GA4のリアルタイムレポートでアクセスを確認してみましょう。

Google公式でも、GA4を新しく設定した場合、自分でサイト内を操作してからリアルタイムレポートを確認する方法が案内されています。

確認方法は簡単です。

1. GA4を開く
2. 「レポート」を開く
3. 「リアルタイム」を表示する
4. 別タブで自分のサイトを開く
5. ページを移動する
6. リアルタイムにイベントが表示されるか確認する

たとえば、

• ページ表示
• 記事移動
• ボタンクリック

などを行い、イベントが表示されるか見てみましょう。

なお、Google公式では、新規設定時にはデータ処理のため時間がかかる場合もあると説明しています。

そのため、設定直後に通常レポートへ表示されないからといって、すぐに「設定失敗」と判断しないことも大切です。

内部トラフィック除外設定を確認する

「自分でサイトを見ているのにGA4に表示されない」という場合は、内部トラフィックの設定も確認しましょう。

GA4では、自社やサイト管理者のアクセスをレポートから除外するために、内部トラフィックを定義できます。

たとえば、自宅や会社のIPアドレスを内部トラフィックとして設定していると、その環境からテストしたアクセスが除外される場合があります。

そのため、

「Tag Assistantでは正常」
「GA4では自分のアクセスが見えない」

という場合は、

• 内部トラフィック設定
• データフィルタ
• テストに使用しているIPアドレス

を確認してみましょう。

特にサイト運営者自身のアクセスだけ見えない場合は、確認する価値があります。

同意設定によって計測が制限されていないか確認する

Cookie同意バナーやConsent Modeを利用しているサイトでは、ユーザーの同意状態によってGoogleタグの動作が変わることがあります。

Google公式では、Consent Modeを利用すると、ユーザーの同意状態に応じてGoogleタグの動作が調整されると説明しています。

たとえば、

analytics_storage = denied

の状態が続いている場合、通常のAnalytics Cookieを利用した計測が制限されます。

確認したい項目は、

• Cookieバナーを導入しているか
• 同意後に状態が正しく更新されているか
• GTMの同意設定が正しいか
• CMPとGTMが正しく連携しているか

です。

Google公式も、Consent Modeに問題がある場合はTag Assistantを使って実装状態を確認するよう案内しています。

ただし、プライバシー保護のための同意設定を「計測できないから」という理由だけで安易に解除するのは避けてください。

GTMでは正常でもGA4に届かない場合の確認方法

GTMではタグが発火しているのにGA4にデータが表示されない場合は、次の順番で確認すると原因を切り分けやすくなります。

1. GTMのTag Assistantで発火を確認
2. 送信先の測定IDを確認
3. GA4のリアルタイムレポートを確認
4. 内部トラフィック除外を確認
5. Consent Modeを確認
6. GTMが最新版として公開されているか確認

簡単に図で表すと、次のようになります。

段階	確認結果	次に見る場所
Tag Assistantで発火しない	GTM側の問題	タグ・トリガー
発火するがIDが違う	設定ミス	測定ID
IDも正しい	GA4側を確認	リアルタイム
自分だけ見えない	除外の可能性	内部トラフィック
同意バナーあり	制限の可能性	Consent Mode
すべて正常	処理時間も確認	GA4レポート

このように、GTMとGA4のどちらか一方だけを見るのではなく、データがどこまで正常に進んでいるかを順番に確認することが重要です。

「クリックタグが発火しない」原因と解決方法

Googleタグマネージャーでは、リンクやボタンのクリックをトリガーとして、GA4イベントなどのタグを発火させることができます。

しかし、設定したはずなのにクリックしてもタグが発火しない場合があります。

クリック計測では、特に次の項目を確認することが大切です。

確認項目	よくある原因	主な対処方法
クリック変数	必要な変数が無効	組み込み変数を有効化
Click URL・Click Text	変数の選択ミス	実際の値を確認
トリガー種類	リンクとボタンの違い	適切な種類を選択
条件設定	文字列が一致していない	条件を修正
JavaScript	通常のクリックで取得できない	カスタムイベント等を検討
プレビュー	イベント自体が発生していない	Tag Assistantで確認

Google公式でも、クリックトリガーには「すべての要素」と「リンクのみ」があり、クリック時には有効になっているクリック関連の組み込み変数へ値が入力される仕組みになっています。

クリック変数が有効になっているか確認する

クリックタグを設定するときは、まず必要なクリック変数が利用できる状態になっているか確認しましょう。

GTMには、クリック計測で使える代表的な組み込み変数があります。

• Click Element
• Click Classes
• Click ID
• Click Target
• Click URL
• Click Text

たとえば、外部リンクをクリックしたときだけタグを発火させたい場合は、Click URLを条件として利用できます。

一方、ボタンに表示されている「お問い合わせ」という文字を基準に計測するなら、Click Textを利用する方法があります。

Google公式でも、Click URLはクリックされた要素のURL、Click Textはクリックされた要素の表示テキストを取得する変数として定義されています。

必要な変数が表示されない場合は、

1. GTMの「変数」を開く
2. 「組み込み変数」の「設定」をクリックする
3. 必要なクリック変数を有効にする

という流れで確認してください。

すべてのクリック変数をむやみに使う必要はありません。何を条件にクリックを判定したいのかを考えて、必要な変数を選びましょう。

Click URLとClick Textの違いを確認する

クリックタグが発火しない原因として多いのが、Click URLとClick Textの使い分けです。

それぞれの違いは次のようになります。

変数	取得する内容	向いている例
Click URL	リンク先URL	外部リンク・内部リンク
Click Text	表示されている文字	ボタン名・リンク文字

たとえば、

「公式サイトを見る」

というテキストリンクがあり、リンク先が

Example Domain

example.com

だった場合、

• Click Text → 「公式サイトを見る」
• Click URL → https://example.com/service/

のようになります。

Google公式のGA4イベント設定例でも、ボタンの表示文字を基準にする場合に、Click Textを条件として使う方法が紹介されています。

注意したいのは、Click TextはサイトのデザインやHTML構造によって、想定した文字列が取得できないことがある点です。

たとえば、ボタン内にアイコンや複数の要素が入っている場合は、クリックした位置によって取得値が変わることがあります。

そのため、条件を決める前にTag Assistantで実際のClick URLやClick Textの値を確認するのがおすすめです。

「すべての要素」と「リンクのみ」の違いを確認する

GTMのクリックトリガーには、主に次の2種類があります。

• すべての要素
• リンクのみ

Google公式では、「すべての要素」はリンク・画像・ボタンなどページ上のさまざまな要素を対象にし、「リンクのみ」は<a>要素のHTMLリンクだけを対象にすると説明しています。

違いを簡単に整理すると次のとおりです。

トリガー	主な対象
すべての要素	ボタン・画像・リンクなど
リンクのみ	<a>タグで作られたリンク

たとえば、

<a href="/contact/">お問い合わせ</a>

であれば、「リンクのみ」で取得できます。

一方、

<button>送信する</button>

のようなボタンは通常のHTMLリンクではないため、「リンクのみ」ではなく「すべての要素」を使う方が適しています。

「ボタンだからリンクのみ」と判断するのではなく、実際のHTML要素がリンクなのかボタンなのかを確認することがポイントです。

クリック条件の指定ミスを確認する

トリガーの種類が正しくても、条件が間違っているとタグは発火しません。

たとえば、外部リンクを計測するために、

Click URL 含む example.com

と設定したとします。

ところが、実際のリンク先が

https://www.example.jp

www.example.jp

だった場合、条件が一致しないため発火しません。

また、

• 「含む」と「等しい」を間違える
• URLの末尾の/が違う
• 大文字・小文字が違う
• Click URLではなくPage URLを指定している
• Click Textの表示文字と条件が一致していない

といったミスもあります。

Google公式では、クリックトリガーについて「一部のクリック」を選択し、Click URLなどを利用して条件を設定できると案内しています。

設定するときは、推測で条件を書くのではなく、Tag Assistantで実際の値を確認してから指定すると間違いを減らせます。

JavaScriptで生成されたボタンの場合を確認する

Webサイトによっては、JavaScriptを使ってボタンやリンクが動的に生成されていることがあります。

この場合、通常のクリックトリガーだけでは、期待したイベントを取得できないケースがあります。

たとえば、

• JavaScriptで後から表示されるボタン
• ポップアップ内のボタン
• SPAでページ遷移しないボタン
• 独自スクリプトでクリック処理を変更している要素

などです。

Google公式でも、フォームやリンクのトリガーについて、別のJavaScript処理が介入すると正常に動作しない場合があるため、公開前にプレビューモードで確認することが推奨されています。

標準のクリックトリガーで取得できない場合は、サイトの仕様によって、

• Click Elementなど別の変数を使う
• dataLayerへイベントを送る
• カスタムイベントトリガーを利用する

といった方法を検討します。

ただし、JavaScriptやdataLayerの設定は初心者には難しい場合があります。無理にコードを変更せず、まずプレビューモードで何が起きているのか確認しましょう。

プレビューモードでクリックイベントを確認する

クリックタグが発火しない場合は、プレビューモードで確認すると原因を見つけやすくなります。

基本的な確認手順は次のとおりです。

1. GTMで「プレビュー」をクリックする
2. 対象サイトへ接続する
3. 計測したいリンクやボタンをクリックする
4. Tag Assistantでクリックイベントを確認する
5. Click URL・Click Textなどの値を確認する
6. タグが発火したか確認する

重要なのは、いきなりタグの設定を直すのではなく、クリックイベント自体が発生しているかを見ることです。

たとえば、

• Clickイベントが出ない
  → トリガー種類やサイト側のJavaScriptを確認
• Clickイベントは出るがタグが発火しない
  → トリガー条件を確認
• タグは発火する
  → GA4など送信先を確認

というように原因を絞り込めます。

Google公式も、リンクやフォームのトリガーは公開前にプレビューモードでテストすることを推奨しています。

「フォーム送信タグが発火しない」原因と解決方法

お問い合わせフォームや資料請求フォームなどの送信完了を計測するために、GTMのフォーム送信トリガーを利用することがあります。

しかし、フォームの仕組みによっては、通常のフォーム送信トリガーでは発火しない場合があります。

まずは次のポイントを確認しましょう。

確認項目	主な原因	対処方法
フォーム送信トリガー	条件設定が違う	Form IDなどを確認
Ajaxフォーム	通常のsubmitが発生しない	カスタムイベント等を検討
完了ページ	URLが変わる	Page Viewで計測
送信ボタン	クリックだけを取得	誤計測に注意
プレビュー	実際のイベントが不明	Tag Assistantで確認

Google公式では、フォーム送信トリガーによってフォーム送信時にタグを発火でき、Form IDやForm Classesなどの組み込み変数が利用できると案内しています。

フォーム送信トリガーが正しく設定されているか確認する

まず、フォーム送信トリガー自体が正しく設定されているか確認します。

GTMでは、

「トリガー」
↓
「新規」
↓
「トリガーの設定」
↓
「フォームの送信」

から設定できます。

Google公式によると、フォーム送信時には次のような変数を利用できます。

• Form Element
• Form Classes
• Form ID
• Form Target
• Form URL
• Form Text

たとえば、お問い合わせフォームのIDが

contact-form

であれば、

Form ID 等しい contact-form

という条件で対象フォームだけを計測できます。

サイトに複数のフォームがある場合、「すべてのフォーム」を対象にすると不要なフォームまで計測する可能性があります。

そのため、

• 対象ページ
• Form ID
• Form Classes

などを使い、計測したいフォームだけに条件を絞ると分かりやすくなります。

Ajaxフォームでは通常の送信イベントが発生しない場合がある

フォーム送信タグが発火しない原因として特に注意したいのが、Ajaxを使ったフォームです。

Ajaxフォームでは、送信ボタンを押してもページ全体を再読み込みせず、その場で「送信しました」などのメッセージを表示できます。

このようなフォームでは、一般的なsubmitイベントが通常どおり発生しなかったり、サイト側のJavaScriptによって処理が変更されていたりする場合があります。

Google公式でも、フォームの標準動作が変更され、通常のsubmitイベントが使えない場合には、カスタムイベントトリガーを利用する方法が案内されています。

たとえば、

• Contact Form 7
• 独自のAjaxフォーム
• JavaScriptで送信処理を行うフォーム

などでは、フォーム送信トリガーだけで正しく取得できるとは限りません。

確認するときは、

1. プレビューモードでフォームを送信する
2. Form Submitイベントが発生するか確認する
3. 発生しない場合は別のイベントが出ていないか確認する

という順番で調べるとよいでしょう。

お問い合わせ完了ページを利用する方法

フォームを送信したあと、専用の「お問い合わせ完了ページ」へ移動するサイトであれば、そのページの表示を利用して計測する方法があります。

たとえば、

フォーム送信前
https://example.com/contact/

フォーム送信後
https://example.com/contact/thanks/

という構成です。

この場合は、フォーム送信そのものではなく、

Page Path 含む /contact/thanks/

などのPage Viewトリガーを使って、完了ページが表示されたときにイベントを送る方法があります。

Google公式でも、確認ページなど特定のページが表示された時点でイベントを送信したい場合は、ページビュートリガーを利用できると案内しています。

この方法のメリットは、

• 設定が比較的分かりやすい
• Ajaxの影響を受けにくい
• 「送信完了」を条件にしやすい

ことです。

ただし、完了ページのURLを直接開ける構造になっていると、実際にフォーム送信していない人まで計測する可能性があります。

そのため、サイトの仕様を確認したうえで利用してください。

クリックトリガーで代用する場合の注意点

フォーム送信トリガーが利用できない場合、送信ボタンのクリックを計測する方法もあります。

たとえば、

「送信する」

というボタンをクリックしたときにイベントを送る設定です。

ただし、この方法には注意が必要です。

送信ボタンをクリックした＝フォーム送信が成功した、とは限らないからです。

たとえば、

• 必須項目が未入力
• メールアドレスの形式が間違っている
• CAPTCHA認証に失敗した
• 通信エラーが発生した

場合でも、ボタン自体はクリックできます。

そのため、クリックタグでは、

「送信を試みた回数」

は計測できても、

「正常に送信された件数」

とは一致しない可能性があります。

お問い合わせ完了数やコンバージョンを正確に計測したい場合は、

• フォーム送信イベント
• 完了ページ
• dataLayerのカスタムイベント

など、送信成功を判断できる方法を優先する方が適しています。

プレビューモードで送信イベントを確認する

フォームの設定を公開する前には、必ずプレビューモードで実際にテストしましょう。

Google公式も、フォームやリンクのトリガーについて、JavaScriptなどの影響によって正常に動かない場合があるため、公開前のプレビュー確認を推奨しています。

確認手順は次のとおりです。

1. GTMの「プレビュー」を開く
2. 対象サイトへ接続する
3. テスト用の内容をフォームへ入力する
4. 実際に送信する
5. Tag Assistantでイベント一覧を見る
6. Form Submitなどのイベントを確認する
7. 対象タグが発火したか確認する

フォーム送信トリガーには、「タグの配信を待つ」と「妥当性をチェック」というオプションもあります。

Google公式では、

• 「タグの配信を待つ」
  → タグの配信完了または設定したタイムアウトまでフォーム遷移を待つ
• 「妥当性をチェック」
  → フォームが正常に送信された場合だけ発火させる

という仕組みが案内されています。

フォーム送信タグが動かないときは、

送信操作 → イベント発生 → トリガー条件 → タグ発火

という順番で確認してください。

原因を一つずつ切り分ければ、「GTMが壊れている」と考えて設定を作り直す必要はありません。

「スクロールタグが発火しない」原因と解決方法

Googleタグマネージャーでは、読者がページをどこまでスクロールしたかを条件にしてタグを発火させることができます。

たとえば、

• 25％まで読まれた
• 50％まで読まれた
• 75％まで読まれた
• 90％まで読まれた

といった地点でイベントを送ることが可能です。

しかし、スクロール距離トリガーの設定方法やページの長さによっては、期待した場所でタグが発火しないことがあります。

Google公式では、スクロール距離トリガーについて、縦方向・横方向を指定し、パーセントまたはピクセルで発火地点を設定できると案内しています。

主な確認項目を整理すると、次のとおりです。

確認項目	よくある原因	確認方法
スクロール距離	数値設定ミス	しきい値を確認
方向	縦・横の指定ミス	トリガー設定を確認
単位	%とpxの勘違い	単位を確認
ページ長	条件地点が最初から表示	ページ構成を確認
イベント	発生状況が不明	Tag Assistantで確認

スクロール距離トリガーの設定を確認する

まず確認したいのが、スクロール距離トリガーそのものです。

GTMでは、

「トリガー」
↓
「新規」
↓
「トリガーの設定」
↓
「スクロール距離」

から設定できます。

Google公式では、複数の発火地点をカンマ区切りで指定できます。たとえば、

25,50,75,90

と設定すれば、ページの25％、50％、75％、90％地点がそれぞれしきい値になります。

確認するときは、

• スクロール距離の数値が正しいか
• 数字の入力ミスがないか
• 発火させたいページにトリガーが適用されているか
• 対象タグに正しいトリガーが設定されているか

を見てください。

たとえば、90％地点だけで発火させたいのに「9」と入力していれば、意図した計測にはなりません。

縦方向と横方向の指定を確認する

スクロール距離トリガーには、

• 縦方向スクロール距離
• 横方向スクロール距離

があります。

一般的なブログ記事では、読者は上から下へ読み進めるため、通常は縦方向スクロール距離を使用します。

Google公式でも、

• 縦方向 → ページをどこまで下へ進んだか
• 横方向 → ページをどこまで右へ進んだか

を判定すると説明しています。

たとえば、ブログ記事で50％読了を測りたいのに横方向だけにチェックしていると、通常の縦スクロールでは期待どおりに発火しません。

確認ポイントは、

• 通常の記事 → 縦方向
• 横スクロールするコンテンツ → 横方向
• 必要に応じて両方

という考え方です。

ブログ記事の読了率を計測する場合は、まず縦方向が選ばれているか確認しましょう。

パーセント指定とピクセル指定の違いを確認する

スクロール距離は、

• パーセント
• ピクセル

のどちらかで指定できます。

Google公式では、ページの高さや幅に対する割合、またはピクセル数でしきい値を設定できるとしています。

違いを整理すると次のとおりです。

指定方法	例	向いている場面
パーセント	25、50、75、90％	記事の読了率
ピクセル	500px、1000px	固定距離で計測

たとえば、記事の長さが5000pxの場合、

50％
→ 約2500px地点

になります。

一方、2000pxという固定値を指定すると、記事が長くても短くても2000px地点で発火します。

そのため、ブログ記事の「どこまで読まれたか」を確認したい場合は、パーセント指定の方が扱いやすいことが多いです。

ただし、用途によってはピクセル指定の方が適している場合もあります。

短いページではスクロール条件を満たさない場合がある

スクロールタグが思ったとおりに動かない原因として見落としやすいのが、ページの長さです。

Google公式では、指定したスクロール地点がページ読み込み時点ですでに画面内に入っている場合、実際にスクロールしていなくてもトリガーが発火することがあると説明しています。

つまり、短いページでは、

「90％までスクロールしたつもりはないのに発火した」

ということもあります。

反対に、動的にページが伸び続ける無限スクロールページなどでは、通常のスクロール距離トリガーが適さない場合があります。

Google公式では、無限スクロールやページサイズが大きく変動するページでは、要素の表示トリガーの利用を検討するよう案内しています。

確認するときは、

• ページ全体の長さ
• 初期表示範囲
• 無限スクロールの有無
• 後から読み込まれるコンテンツの有無

も確認しましょう。

Tag Assistantでスクロールイベントを確認する

設定後は、Tag Assistantで実際のスクロールイベントを確認します。

基本的な流れは次のとおりです。

1. GTMの「プレビュー」をクリックする
2. 対象サイトへ接続する
3. 実際にページをスクロールする
4. Tag Assistantでスクロールイベントを確認する
5. 対象タグが発火しているか確認する
6. Scroll Depth Thresholdなどの値を見る

スクロール距離トリガーが発火すると、Google公式では次の組み込み変数に値が入ると案内しています。

• Scroll Depth Threshold
• Scroll Depth Units
• Scroll Direction

たとえば、

Scroll Depth Threshold = 50

Scroll Depth Units = percent

なら、50％地点のスクロール条件が成立したことを確認できます。

「タグが発火しない」ときは、まずスクロールイベント自体が発生しているのかを確認してください。

イベントが発生しているのにタグが発火しない場合は、タグやトリガー条件を確認します。

「変更した設定が反映されない」原因と解決方法

GTMで設定を変更したのに、本番サイトでは以前のままということがあります。

この場合は、設定内容そのものよりも、

• 保存だけで終わっていないか
• コンテナを公開したか
• 正しいバージョンが公開されているか
• キャッシュが残っていないか

を確認することが大切です。

Google公式では、GTMの変更内容を本番サイトへ反映するには、ワークスペースの「送信」から「バージョンの公開と作成」を選び、「公開」を実行する必要があると案内しています。

主な確認項目は次のとおりです。

確認項目	よくある原因	対処方法
保存状態	保存しただけ	公開まで行う
送信	公開操作をしていない	「送信」から公開
バージョン	古いものを公開	公開履歴を確認
ブラウザ	キャッシュが残る	再読み込み・削除
WordPress	キャッシュプラグイン	キャッシュ削除
過去設定	修正で不具合	以前のバージョンへ戻す

GTMを「保存」しただけではサイトに反映されない

GTMでは、タグやトリガーを編集して「保存」を押しても、それだけでは通常、本番サイトへ反映されません。

ここは初心者が特に間違えやすいポイントです。

たとえば、

1. トリガーを修正する
2. 「保存」を押す
3. サイトを確認する
4. 「変わっていない」と思う

というケースです。

保存は、あくまで現在のワークスペースに編集内容を保存した状態です。

本番環境へ反映するには、その後に公開操作が必要です。

Google公式でも、「バージョンを作成」は公開せず変更を保存する操作であり、「バージョンの公開と作成」を選ぶことでサイトへ反映すると説明しています。

「送信」からバージョンを公開したか確認する

設定変更後は、GTM画面右上の「送信」をクリックします。

Google公式の公開手順は、

1. ワークスペース右上の「送信」
2. 「バージョンの公開と作成」を選択
3. バージョン名と説明を入力
4. 「公開」

という流れです。

たとえば、バージョン名を、

「GA4クリックイベント追加」

説明を、

「お問い合わせボタンのクリックトリガーを追加」

などにしておくと、あとから何を変更したのか分かりやすくなります。

公開前には、必ずプレビューモードで動作確認を行いましょう。

公開中のコンテナバージョンを確認する

「公開したはずなのに反映されない」という場合は、現在どのコンテナバージョンが公開されているか確認します。

GTMでは、コンテナを公開するたびにバージョンが記録されます。

Google公式では、「バージョン」画面から公開履歴を確認でき、公開日や公開したユーザーも確認できると案内しています。

確認するときは、

• 最新の修正内容が含まれているか
• 公開日時
• バージョン名
• 説明
• 誤って古いバージョンを公開していないか

を見てください。

たとえば、

バージョン10
「クリックタグ追加」

を作ったのに、

バージョン9

が公開されていれば、新しいタグは本番サイトに反映されません。

ブラウザキャッシュを削除して確認する

GTMを正しく公開していても、ブラウザ側に古いページ情報が残っていると、変更前の状態が表示される場合があります。

このようなときは、

• ページを再読み込みする
• 強制再読み込みする
• ブラウザキャッシュを削除する
• シークレットウィンドウで確認する
• 別ブラウザで確認する

といった方法を試します。

ただし、キャッシュが原因と決めつけないことも重要です。

先に、

• GTMが公開済みか
• 正しいバージョンか
• Tag Assistantでは正常か

を確認してからキャッシュを疑うと、原因を見つけやすくなります。

キャッシュ系プラグインを使用している場合の注意点

WordPressでは、ページ表示を高速化するためにキャッシュ系プラグインを使うことがあります。

代表的な機能には、

• ページキャッシュ
• JavaScript圧縮
• JavaScript結合
• 遅延読み込み
• CDNキャッシュ

などがあります。

このような機能によって、GTMやGoogleタグの読み込みタイミングが変わったり、古いHTMLやJavaScriptが一時的に表示されたりする場合があります。

GTMの設定を変更したあとに挙動がおかしい場合は、

• WordPressキャッシュ
• CDNキャッシュ
• JavaScript最適化設定

を確認してみましょう。

ただし、プラグインによって仕組みが異なるため、むやみに設定を変更するのではなく、まずキャッシュを削除して再確認する程度から始めるのがおすすめです。

以前のバージョンに戻す方法

GTMの設定を変更して不具合が起きた場合は、以前の正常なバージョンへ戻すことができます。

これはGTMの便利な機能の一つです。

Google公式では、過去のコンテナバージョンを選び、そのバージョンを現在のコンテナへ戻したり、再公開したりできると案内しています。

たとえば、

「昨日までは正常だった」

「今日GTMを変更したあとから計測がおかしい」

という場合は、昨日まで使っていたバージョンと現在のバージョンを比較できます。

確認の流れは、

1. GTMの「バージョン」を開く
2. 正常だった時期のバージョンを探す
3. 変更内容を確認する
4. 必要に応じて以前のバージョンへ戻す
5. プレビューで確認する
6. 問題なければ公開する

となります。

特に複数のタグやトリガーを一度に変更した場合は、無理に全部を手作業で戻すより、正常だったバージョンへ戻した方が早いことがあります。

そのため、公開するときは、

• バージョン名
• 変更内容
• 公開日時

をきちんと残しておくことが大切です。

WordPress・Cocoonで起こりやすいGTMエラー

WordPressやCocoonでGoogleタグマネージャーを利用している場合、GTM側の設定が正しくても、WordPressのテーマやプラグイン、キャッシュ、JavaScript最適化などが原因で正常に動作しないことがあります。

特に注意したいのは、**「どの方法でGTMやGA4のコードを設置しているのか分からなくなっている状態」**です。

WordPressでは複数の方法でGoogle関連のコードを設置できるため、知らないうちに同じコードを重複して入れているケースがあります。

まずは次のように整理して確認しましょう。

確認項目	起こりやすい問題	確認する場所
GTMコード	設置場所の間違い	テーマ・プラグイン
Cocoon・プラグイン	GTMの二重設置	各設定画面
Site Kit	GA4設定の重複	Site Kit設定
キャッシュ	古い状態が残る	キャッシュプラグイン
JavaScript最適化	読み込み順の変化	高速化設定
テーマ変更	GTMコード消失	新テーマ・ソース

GTMコードを誤った場所に貼り付けている

WordPressへGTMを手動設置している場合は、コードを貼り付ける場所に注意が必要です。

Web用GTMコンテナでは、基本的に、

• 1つ目のコード → <head>内のできるだけ上
• 2つ目のコード → <body>開始タグの直後

へ配置します。

コードを途中だけコピーしたり、誤ったファイルへ貼り付けたりすると、GTMが正しく読み込まれない原因になります。

たとえば、

• footer.phpだけに設置した
• 2つのコードのうち片方だけ貼り付けた
• 別のコンテナIDのコードを使った
• HTMLとしてではなく通常の本文へ貼り付けた

といったケースです。

WordPressでは、テーマファイルを直接編集しなくても、テーマやプラグインからコードを挿入できる場合があります。

そのため、初心者の場合は、まず現在どの方法でGTMを設置しているのかを確認してから変更することが大切です。

CocoonとプラグインでGTMを二重設置している

Cocoon側の設定と、別のGTM設置プラグインの両方を利用している場合は、同じGTMコンテナが二重に読み込まれていないか確認しましょう。

たとえば、

• Cocoon側でGTMを設定
• GTM用プラグインでも同じコンテナIDを設定

という状態です。

このように同じコンテナを複数の方法で設置すると、タグの発火やデータ計測が複雑になる可能性があります。

確認したいのは、

• Cocoon側にGTM設定があるか
• GTM用プラグインを使っているか
• Site KitでTag Managerコードを設置していないか
• header.phpなどへ手動コードが残っていないか

です。

基本的には、GTMコンテナを設置する方法を1つに整理すると管理しやすくなります。

なお、Cocoonの設定項目や画面構成はバージョンによって変わる可能性があるため、実際の管理画面も確認してください。

Site KitとGTMでGA4が重複している

Site KitとGTMを両方利用している場合は、GA4をどの方法で設置しているのか確認しましょう。

ただし、ここは少し注意が必要です。

Site KitとGTMを同時に使っているだけで、必ずGA4が二重計測になるわけではありません。

Site Kit公式では、既存のAnalyticsタグやGTMコンテナを検出すると、重複を避けるためコード配置を自動的にオフにする場合があります。また、同じAnalyticsデータストリームに接続されたSite KitとTag Managerの構成では、単純にイベントが二重になるとは限らないことも案内されています。

そのため、確認すべきなのは、

• Site KitがGA4コードを実際に設置しているか
• GTM側にも同じGA4用Googleタグがあるか
• 同じ測定IDへ送信しているか
• 別プロパティへ送信していないか

です。

たとえば、Site Kit側で「Google Analyticsコードを配置」が有効で、GTMでも別のGA4設定を行っている場合は、実装内容を整理する必要があります。

Site Kitは既存タグを検出すると、コード配置をオフにして接続だけ行うこともできます。

重要なのは、Site Kitを使うかGTMを使うかという二者択一ではなく、どこからGA4タグを配信しているのかを把握することです。

キャッシュ系プラグインで変更が反映されない

GTMの設定を変更して公開したのに、WordPressサイトでは以前と同じ動作をする場合があります。

その原因の一つとして考えられるのが、キャッシュです。

WordPressでは、高速表示のために、

• ページキャッシュ
• ブラウザキャッシュ
• CDNキャッシュ
• JavaScriptキャッシュ

などが利用されることがあります。

たとえば、GTMコードを修正したあとも、古いHTMLがキャッシュから表示されていれば、変更内容がすぐ確認できないことがあります。

このような場合は、

• キャッシュプラグインのキャッシュ削除
• ブラウザの再読み込み
• シークレットウィンドウで確認
• CDNを利用している場合はCDN側も確認

してみましょう。

ただし、設定が反映されない原因が必ずキャッシュとは限りません。

先に、

• GTMが公開済みか
• 正しいコンテナIDか
• Tag Assistantでは正常か

を確認したあとでキャッシュを疑うと、原因を見つけやすくなります。

JavaScript最適化・遅延読み込みが影響している

WordPressの高速化プラグインには、JavaScriptを最適化する機能があります。

代表的なものは、

• JavaScriptの圧縮
• JavaScriptの結合
• 遅延読み込み
• 実行延期
• 不要スクリプトの除外

などです。

これらはページ表示を高速化するために便利ですが、設定内容によってはGoogleタグやGTMの読み込みタイミングへ影響する可能性があります。

Site Kit公式でも、JavaScriptファイルのminifyなどの最適化によって、Site Kit関連のJavaScriptエラーが発生する場合があると案内しています。

たとえば、

「高速化プラグインを設定したあとからTag Assistantでタグが確認できなくなった」

という場合は、最適化設定が関係している可能性があります。

確認するときは、

1. Tag Assistantで現在の状態を確認
2. 最近変更した高速化設定を確認
3. 必要に応じてテスト環境で一時的に設定を外す
4. 動作が変わるか確認

という順番がおすすめです。

ただし、速度改善の設定をむやみに全部解除する必要はありません。

原因を一つずつ切り分けるようにしましょう。

テーマ変更後にGTMコードが消えていないか確認する

WordPressのテーマファイルへGTMやGoogleタグを直接書き込んでいる場合は、テーマ変更にも注意が必要です。

Google公式でも、WordPressのテーマファイルへGoogleタグを直接設置した場合、テーマを変更するとheader.phpなどが置き換わるため、再度タグを設置する必要がある場合があると案内しています。

たとえば、

旧テーマ
→ header.phpへ直接GTMを設置

テーマ変更
→ 新しいheader.phpへ置き換わる

という流れになると、旧テーマに書いていたコードが新しいテーマには引き継がれません。

テーマ変更後は、

• GTMコンテナが読み込まれているか
• Googleタグが残っているか
• Tag Assistantで接続できるか

を確認しましょう。

また、親テーマのファイルを直接編集すると、テーマ更新でも変更内容が失われる可能性があります。

WordPressでは、テーマ・子テーマ・プラグインなど、どの方法でタグを管理しているかを記録しておくことも大切です。

「Googleタグが見つからない」と表示される原因と解決方法

Googleタグを設定したはずなのに、

「Googleタグが見つからない」

「タグを検出できない」

といった表示が出ることがあります。

この場合は、まずタグがサイトへ正しく設置され、対象ページで実際に読み込まれているかを確認します。

また、「Googleタグ」と「GTMコンテナ」は似た名称ですが、同じものではありません。

確認ポイントを整理すると次のとおりです。

確認項目	主な問題
GTMコンテナ	ページで読み込まれていない
測定ID・タグID	IDが間違っている
GoogleタグとGTM	種類を混同している
ページ単位	一部ページだけタグがない
データ送信	タグはあるが送信先に届かない

GTMコンテナ自体が読み込まれているか確認する

最初に、対象ページでGTMコンテナが実際に読み込まれているか確認しましょう。

たとえば、管理画面ではGTMを設定済みでも、

• コードが保存されていない
• テーマ変更で消えた
• プラグインを停止した
• 特定ページではコードが出力されていない

といった原因で、実際のサイトにはGTMが存在しないことがあります。

確認するときは、

• Tag Assistantでコンテナが認識されるか
• 正しいGTMコンテナIDが表示されているか
• 対象URLで確認しているか

を見ます。

Google公式でも、タグが検出できない場合は、コードが正しく読み込まれているかを確認することが基本とされています。

測定ID・タグIDが正しいか確認する

タグそのものは設置されていても、IDが間違っていると目的のGoogleサービスへ正しく接続できません。

代表的なIDには、

• GTM- → Google Tag ManagerコンテナID
• G- → GA4測定ID
• GT- → GoogleタグID

などがあります。

Site Kit公式でも、GA4の測定IDは「G-」で始まり、GoogleタグIDは「GT-」で始まると説明されています。

たとえば、

GA4で確認している測定ID
G-ABCDEFGHIJ

GTMで設定した送信先
G-1234567890

となっていれば、違うデータストリームへデータを送っている可能性があります。

確認するときは、

• GTMコンテナID
• GA4測定ID
• GoogleタグID
• 対象プロパティ

を混同しないようにしましょう。

GoogleタグとGTMコンテナの違いを確認する

初心者が特に迷いやすいのが、GoogleタグとGoogleタグマネージャーの違いです。

名前は似ていますが、役割が異なります。

種類	代表的なID	主な役割
Googleタグ	GT-、G-など	Googleサービスへデータ送信
GTMコンテナ	GTM-	複数のタグを管理・配信

Googleタグは、GA4やGoogle広告などへデータを送信するためのタグです。

一方、Google Tag Managerは、Googleタグやイベントタグなどをまとめて管理する仕組みです。

つまり、

GTMの中にGoogleタグを設定する

という使い方もあります。

Google公式では、Googleタグは複数のGoogleサービスへ接続できる再利用可能なタグとして案内されています。

「Googleタグが見つからない」と表示されたときは、GTMコンテナそのものを探しているのか、GA4用のGoogleタグを探しているのかを区別して確認しましょう。

対象ページだけタグが設置されていない場合を確認する

トップページではタグが見つかるのに、特定の記事だけ「タグが見つからない」と表示される場合があります。

この場合は、ページごとの出力状態を確認します。

たとえば、

• トップページだけ別テンプレート
• 固定ページだけ別レイアウト
• LPだけ専用テンプレート
• AMPや特殊ページ
• ページ単位でスクリプトを除外

といった構成では、一部ページだけGoogleタグやGTMが読み込まれていない可能性があります。

Google公式では、Googleタグを手動実装する場合、サイトの各ページへコードを配置するよう案内しています。

確認するときは、

1. トップページ
2. 通常の記事
3. 固定ページ
4. 問題が起きているページ

をそれぞれTag Assistantで確認してみましょう。

「サイト全体で設定したから大丈夫」と考えず、問題が出ているURLそのものを確認することが大切です。

タグは検出されるがデータが届かない場合を確認する

Tag AssistantなどでGoogleタグ自体は見つかるのに、GA4などへデータが届かないケースもあります。

この場合は、

「タグが存在しているか」

ではなく、

「タグが正しい送信先へ正常にデータを送っているか」

を確認します。

主な確認ポイントは次のとおりです。

• Googleタグが発火しているか
• 正しい測定IDか
• GA4のリアルタイムで確認できるか
• 内部トラフィック除外がないか
• Consent Modeで制限されていないか
• GTMの変更が公開済みか

Google公式では、Googleタグを設定したあと、Webサイトをテストしてタグの検出状況を確認し、データ収集開始まで時間がかかる場合があると案内しています。

たとえば、

Tag Assistant
→ Googleタグを検出

GA4リアルタイム
→ データなし

という場合は、タグ設置自体は成功している可能性があります。

その場合は、測定IDやGA4側の設定、Consent Modeなどへ確認範囲を移しましょう。

「タグがない問題」と「タグはあるがデータが届かない問題」を分けて考えると、原因を切り分けやすくなります。

同意モード・Cookie設定によるGTMエラー

GTMやGoogleタグの設定が正しいように見えても、Cookie同意バナーやConsent Mode（同意モード）の設定によって、タグの動作が変わることがあります。

たとえば、

• 同意前はタグが発火しない
• 同意後もタグが動かない
• GA4のデータが想定より少ない
• Tag Assistantで同意関連の警告が表示される

といったケースです。

Google公式では、Consent ModeはユーザーのCookieなどに関する同意状態をGoogleへ伝え、その状態に応じてGoogleタグの動作を調整する仕組みと説明しています。

主な確認項目を整理すると次のようになります。

確認項目	起こりやすい問題	確認方法
Consent Mode	同意状態が正しく伝わらない	Tag Assistant
同意チェック	タグがブロックされる	Tags Not Fired
CMP	Googleタグを必要以上にブロック	CMP設定
analytics_storage	許可・拒否状態が想定外	Consent画面
更新処理	同意後も状態が変わらない	Default・Update確認

Consent Modeとは何か

Consent Modeとは、サイト訪問者がCookieやデータ利用について許可・拒否した状態をGoogleタグへ伝えるための仕組みです。

同意モード自体がCookieバナーを表示するわけではありません。

CookieバナーやCMP（同意管理プラットフォーム）で取得したユーザーの選択を受け取り、その状態に応じてGoogle AnalyticsやGoogle広告などのタグの動作を調整します。

代表的な同意タイプには次のものがあります。

同意タイプ	主な役割
analytics_storage	Analytics関連の保存を制御
ad_storage	広告関連のCookieなどを制御
ad_user_data	広告目的のユーザーデータ送信への同意
ad_personalization	パーソナライズ広告への同意

たとえば、analytics_storageが拒否されている場合、Google Analyticsタグはその同意状態に応じて動作を調整します。

初心者の場合は、

Cookieバナー＝Consent Mode

と考えないようにしましょう。

Cookieバナーは「ユーザーの意思を確認するもの」、Consent Modeは「その意思をGoogleタグへ伝える仕組み」と考えると分かりやすいです。

同意設定によってタグが発火しない場合がある

Consent Modeを設定しているサイトでは、同意状態によってタグが通常とは異なる動きをすることがあります。

ただし、「拒否されたら必ずすべてのGoogleタグが発火しない」と考えるのは正確ではありません。

Google公式では、Consent Modeには大きく、

• 基本の同意モード
• 高度な同意モード

があります。

違いを簡単に整理すると次のとおりです。

方式	同意前・拒否時の主な動作
基本の同意モード	同意するまでGoogleタグをブロック
高度な同意モード	タグを読み込み、同意状態に応じて動作を調整

高度な同意モードでは、同意が拒否されている場合でも、Cookieを保存せずに同意状態などのシグナルを送信する場合があります。

一方、GTMで追加の同意チェックを設定している場合や、CMP側でGoogleタグ自体をブロックしている場合は、タグが「Tags Not Fired」に表示されることがあります。

したがって、「タグが発火しない＝設定ミス」とすぐ判断するのではなく、同意設定によって意図的に止まっているのかも確認しましょう。

CMPによってGoogleタグがブロックされていないか確認する

CMPとは、Consent Management Platformの略で、Cookieやデータ利用についてユーザーの同意を取得・管理する仕組みです。

CMPとGTMを組み合わせている場合、設定によってはGoogleタグが必要以上にブロックされることがあります。

Google公式も、Consent Modeを利用している場合にGoogleタグがブロックされる原因として、CMP側の設定を確認するよう案内しています。

確認したいポイントは次のとおりです。

• CMPでGoogleタグを完全ブロックしていないか
• 同意前と同意後で状態が正しく切り替わるか
• 同意後にdeniedからgrantedへ更新されるか
• GTMで不要な追加同意チェックを設定していないか
• Googleタグに独自のブロックトリガーを付けていないか

特にGoogle公式では、GoogleタグにはConsent Modeに対応した同意チェックが組み込まれているため、Googleタグへ不要な追加同意チェックを設定すると正常に動作しない場合があると案内しています。

たとえば、

Cookieバナーで「許可」を押した
↓
CMPでは許可状態になった
↓
しかしGTM側の追加条件が残っている
↓
Googleタグが発火しない

というケースです。

CMPを利用している場合は、GTMだけでなくCMP側の設定も一緒に確認しましょう。

Tag Assistantで同意状態を確認する

Consent Modeの確認には、Tag Assistantが便利です。

Google公式でも、Webサイトに実装した同意モードの確認方法としてTag Assistantを推奨しています。

確認するときは、

1. Tag Assistantでデバッグを開始する
2. 対象サイトへ接続する
3. Cookieバナーを表示する
4. 同意前の状態を確認する
5. 「許可」または「拒否」を選ぶ
6. 同意状態が正しく更新されたか確認する

という流れで進めます。

また、タグが発火していない場合は、

Summary → Tags → Tags Not Fired

から対象タグを確認します。

Google公式では、発火しなかったタグを開き、

• 同意条件を利用したトリガーや変数がある
• Required Additional Consentが表示されている

場合、同意設定によってタグがブロックされている可能性があると説明しています。

つまり、

「タグが動かない」

だけを見るのではなく、

どの同意状態で、なぜブロックされたのか

まで確認することが重要です。

同意モードを設定するときの注意点

Consent Modeは便利な仕組みですが、設定を誤ると、

• タグが必要以上にブロックされる
• 同意後も状態が更新されない
• GA4で想定どおり計測できない
• Google広告の計測へ影響する

といった問題につながる可能性があります。

設定するときは、次の点を意識しましょう。

• 同意前のデフォルト状態を確認する
• 同意後の更新処理を確認する
• CMPとGTMの役割を整理する
• Googleタグに不要な追加ブロックを設定しない
• 公開前にTag Assistantで確認する
• 法令対応は専門家やCMP提供元の案内も確認する

特に、Consent Modeは法的な同意バナーそのものではありません。

Google公式も、Consent ModeはCookieバナーやウィジェットを提供する機能ではなく、ユーザーの同意選択を受け取ってタグ動作を調整するものと説明しています。

プライバシー関連のルールは地域やサイトの運営内容によって異なるため、Consent Modeだけ設定すれば法令対応が完了すると考えないようにしましょう。

GTMエラーをTag Assistantで調査する方法

GTMでエラーが起きたときは、設定画面だけを見て原因を推測するより、Tag Assistantで実際の動きを確認する方が分かりやすい場合があります。

Tag Assistantでは、

• 発生したイベント
• 発火したタグ
• 発火しなかったタグ
• 変数の値

などを確認できます。

確認の基本的な流れは次のとおりです。

手順	確認すること
1	プレビューモードを開始
2	対象サイトへ接続
3	発生したイベントを確認
4	発火したタグを確認
5	発火しなかったタグを確認
6	変数の値を確認
7	修正後に再テスト

GTMの「プレビュー」をクリックする

まず、GTMのワークスペースを開き、画面右上にある「プレビュー」をクリックします。

プレビューを使うと、本番公開前でも現在のワークスペース設定をテストできます。

たとえば、

「お問い合わせボタンのクリックタグを作ったが、本当に動くか確認したい」

という場合、いきなり公開するのではなく、まずプレビューで確認します。

これにより、設定ミスを本番サイトへ反映するリスクを減らせます。

確認したいサイトURLを入力して接続する

「プレビュー」をクリックするとTag Assistantが開くので、確認したいサイトURLを入力します。

たとえば、

Example Domain

example.com

を入力して接続します。

接続できない場合は、

• URLが正しいか
• GTMコンテナが読み込まれているか
• 広告ブロッカーが影響していないか
• リダイレクトが発生していないか
• CSPなどでブロックされていないか

を確認します。

接続できたら、実際のサイト側で調査したい操作を行いましょう。

たとえば、

• ページを開く
• ボタンをクリックする
• スクロールする
• フォームを送信する

などです。

Summaryで発生したイベントを確認する

Tag Assistantへ接続すると、Summary画面から発生したイベントを確認できます。

イベントには、たとえば、

• Container Loaded
• DOM Ready
• Window Loaded
• Click
• Link Click
• Scroll Depth
• Form Submit

などがあります。

大切なのは、目的の操作をしたときに、対応するイベントが発生しているかを見ることです。

たとえば、

お問い合わせボタンをクリック
↓
Clickイベントが出ない

のであれば、タグ設定より前にクリックイベント自体を確認する必要があります。

一方、

Clickイベントはある
↓
タグは発火していない

のであれば、トリガー条件などへ原因を絞れます。

Tags Firedで発火したタグを確認する

対象イベントを選択すると、そのイベントで発火したタグを確認できます。

Tags Firedに目的のタグが表示されていれば、そのイベントではタグが発火しています。

たとえば、

クリックイベント
↓
GA4イベントタグがTags Firedに表示

となっていれば、GTM側ではタグが動いていることを確認できます。

ただし、タグが発火したからといって、送信先まで必ず正しくデータが届いているとは限りません。

そのため必要に応じて、

• 測定ID
• イベント名
• GA4リアルタイム
• Consent Mode

なども確認します。

Google公式も、Consent ModeのトラブルシューティングではSummaryのTags Firedを確認し、想定するタグが含まれているかを見るよう案内しています。

Tags Not Firedで発火しなかったタグを確認する

目的のタグが動いていない場合は、Tags Not Firedを確認します。

ここには、そのイベントでは発火条件を満たさなかったタグが表示されます。

たとえば、

「お問い合わせクリックタグ」

がTags Not Firedにある場合は、対象タグを開いて条件を確認します。

主な原因には、

• Click URLが条件と違う
• Click Textが一致していない
• Page URL条件が成立していない
• 除外トリガーがある
• 必要な同意が得られていない

などがあります。

Consent Modeを利用している場合、Google公式ではRequired Additional Consentの表示も確認ポイントとして案内しています。

つまり、Tags Not Firedは単に「失敗」と見るのではなく、なぜ条件を満たさなかったのかを調べる入口として使いましょう。

Variablesで変数の値を確認する

トリガー条件が合っているように見えるのにタグが発火しない場合は、Variablesも確認します。

Variablesでは、そのイベント時点でGTMが取得している値を見ることができます。

たとえばクリックイベントなら、

• Click URL
• Click Text
• Click Classes
• Click ID
• Page URL
• Page Path

などです。

たとえば、トリガーを、

Click Text 等しい お問い合わせ

と設定したのに、Variablesを見ると、

お問い合わせはこちら

となっていれば、完全一致しないため条件が成立しません。

この場合、

• 条件文字列を修正する
• 「等しい」から「含む」へ変更する
• 別の変数を利用する

などを検討できます。

推測でトリガーを書き直すより、Variablesに表示された実際の値を確認する方が確実です。

修正後にもう一度プレビューする

原因を見つけて設定を修正したら、そのまま公開せず、もう一度プレビューモードで確認しましょう。

おすすめの流れは、

1. 原因を確認する
2. タグやトリガーを修正する
3. 保存する
4. 再度プレビューする
5. 同じ操作を行う
6. Tags Firedを確認する
7. 問題なければ公開する

です。

たとえば、

Click URL条件を修正
↓
再プレビュー
↓
Tags Firedに表示
↓
GA4でも確認
↓
公開

という流れです。

この方法なら、「修正したつもりなのに別の問題を作ってしまった」という事態を減らせます。

GTMでは、確認 → 修正 → 再確認 → 公開という順番を習慣にすると、エラーを防ぎやすくなります。

GTMでエラーが起きたときの原因切り分け手順

Googleタグマネージャーでエラーが起きたときは、思いつく設定を次々に変更するより、確認する順番を決めて原因を切り分けることが大切です。

たとえば「GA4にイベントが表示されない」という場合でも、原因はGA4とは限りません。

実際には、

• GTMコンテナが設置されていない
• Tag Assistantに接続できていない
• 目的のイベントが発生していない
• タグが発火していない
• トリガー条件が間違っている
• GA4の測定IDが違う

など、複数の原因が考えられます。

Google公式でも、公開前にプレビューモードでタグを検証し、問題がなければ公開する流れが案内されています。

原因切り分けの基本手順を整理すると、次のとおりです。

STEP	確認する内容	問題があった場合
1	GTMコンテナ	設置方法を確認
2	Tag Assistant	接続状態を確認
3	イベント	操作・トリガー種類を確認
4	タグ発火	Tags Firedを確認
5	条件・変数	トリガーと値を確認
6	送信先	GA4などを確認
7	公開	本番環境へ反映

STEP1｜GTMコンテナが設置されているか確認する

最初に確認するのは、WebサイトにGTMコンテナが設置されているかどうかです。

ここが正常でなければ、その後のタグやトリガーを確認しても問題は解決できません。

確認したい項目は、

• 正しいGTMコンテナIDか
• GTMコードがサイトに読み込まれているか
• 対象ページにもGTMが入っているか
• テーマ変更などでコードが消えていないか
• 二重設置されていないか

です。

たとえば、GTMの管理画面では、

GTM-AAAAAAA

を使用しているのに、Webサイト側には、

GTM-BBBBBBB

が設置されていれば、別のコンテナを確認していることになります。

エラー調査では、まず土台となるコンテナが正しいかから確認しましょう。

STEP2｜Tag Assistantに接続する

GTMコンテナの設置を確認したら、次にTag Assistantへ接続します。

GTMのワークスペース右上にある「プレビュー」をクリックし、調査したいWebサイトのURLを入力します。

Google公式でも、

1. GTMのコンテナを開く
2. 「プレビュー」をクリック
3. Tag Assistantを起動
4. サイトURLを入力
5. 「接続」をクリック

という流れでプレビューとデバッグを行う方法が案内されています。

接続できない場合は、

• URL間違い
• GTMコード未設置
• 広告ブロッカー
• リダイレクト
• CSPなどのセキュリティ設定

を確認します。

ここで接続できれば、次は実際のイベントを調べます。

STEP3｜目的のイベントが発生しているか確認する

Tag Assistantへ接続できたら、実際に計測したい操作を行います。

たとえば、

• ページ表示
• リンククリック
• ボタンクリック
• スクロール
• フォーム送信

などです。

重要なのは、タグを見る前に目的のイベント自体が発生しているか確認することです。

たとえば、クリック計測なら、

ボタンをクリック
↓
Tag AssistantにClickイベントが表示

となっているか確認します。

もしクリックイベントそのものが表示されていなければ、タグの問題ではなく、

• クリックトリガーの種類
• JavaScriptの影響
• 対象要素の構造

などを調べる必要があります。

Google公式も、フォームやリンクのトリガーはJavaScriptの影響で正常に動かない場合があるため、公開前にプレビューモードでテストすることを推奨しています。

STEP4｜タグが発火しているか確認する

目的のイベントが確認できたら、次にそのイベントで対象タグが発火しているか確認します。

Tag Assistantでは、

• Tags Fired
• Tags Not Fired

から発火状況を確認できます。

たとえば、

Clickイベントあり
↓
GA4イベントタグがTags Firedに表示

なら、GTM側ではタグが発火しています。

一方、

Clickイベントあり
↓
GA4イベントタグがTags Not Fired

なら、イベント自体は発生しているものの、タグの発火条件を満たしていない可能性があります。

このように、

イベントがないのか、タグが発火していないのか

を分けて考えると、原因を大幅に絞り込めます。

STEP5｜トリガー条件と変数を確認する

タグが発火していない場合は、トリガー条件と変数を確認します。

たとえば、

Click Text 等しい お問い合わせ

という条件にしているのに、Tag AssistantのVariablesを見ると、

お問い合わせはこちら

になっている場合、完全一致しないためタグは発火しません。

確認したい主な変数は、

• Page URL
• Page Path
• Click URL
• Click Text
• Click Classes
• Click ID
• Form ID
• Scroll Depth Threshold

などです。

Google公式でも、トリガーは条件の設定方法によって想定外の動作をする場合があるため、プレビューモードでテストすることを推奨しています。

エラー時は、

「設定した値」

ではなく、

「実際にGTMが取得している値」

を見ることがポイントです。

STEP6｜GA4など送信先でデータを確認する

GTM側でタグが発火していることを確認したら、次に送信先を確認します。

GA4の場合は、

• リアルタイムレポート
• DebugView
• イベント

などを確認します。

Google公式でも、GTMから送信したAnalyticsイベントは、リアルタイムレポートやDebugViewで確認できると案内しています。

たとえば、

Tag Assistant
→ タグ発火

GA4リアルタイム
→ データなし

という場合は、

• 測定IDが間違っている
• 別プロパティへ送信している
• Consent Modeの影響
• 内部トラフィック除外
• GA4側の設定

などを確認します。

つまり、GTMでタグが発火した時点で「すべて正常」と判断しないことが大切です。

STEP7｜問題がなければGTMを公開する

プレビューモードで問題がないことを確認したら、最後にGTMを公開します。

Google公式では、

1. ワークスペースで「送信」をクリック
2. 「バージョンの公開と作成」を選択
3. バージョン名と説明を入力
4. 「公開」

という流れが案内されています。

たとえば、

バージョン名
「お問い合わせクリック計測修正」

説明
「Click URL条件を修正し、Tag Assistantで正常発火を確認」

のように記録しておくと、あとから変更内容を確認しやすくなります。

GTMでエラーが起きたときは、

設置 → 接続 → イベント → タグ → 条件 → 送信先 → 公開

という順番で確認すると、原因を効率よく切り分けられます。

GTMのエラーを防ぐために普段から行いたいこと

GTMのエラーは、設定ミスだけでなく、変更履歴が分からなくなったり、複数のタグやトリガーが増えすぎたりすることで起こることもあります。

そのため、エラーが起きてから対処するだけでなく、普段から分かりやすく管理することが重要です。

特に意識したいポイントは次のとおりです。

対策	主な効果
変更前に確認	元の設定を把握できる
分かりやすい名前	管理しやすくなる
プレビュー	公開前にミスを発見
バージョン記録	変更履歴を追える
少しずつ変更	原因を特定しやすい
定期整理	重複や不要設定を防ぐ

変更前に現在の設定を確認する

GTMを変更するときは、いきなりタグやトリガーを書き換えず、まず現在の状態を確認しましょう。

たとえば、

「クリックタグが動かないからトリガーを変更する」

場合でも、

• 現在のトリガー
• 使用している変数
• 発火対象ページ
• 既存のタグ
• 公開中のバージョン

を確認しておくと安心です。

特に複数のタグが同じトリガーを使っている場合、1つの変更が別の計測にも影響することがあります。

「何を変更したか分からない」という状態を防ぐためにも、変更前の状態を把握してから作業する習慣を付けましょう。

タグ・トリガー・変数に分かりやすい名前を付ける

GTMでは、タグやトリガーが増えてくると名前の付け方が重要になります。

たとえば、

タグ1

新しいタグ

クリック

のような名前では、あとから見たときに何の設定か分かりません。

次のような名前にすると管理しやすくなります。

種類	分かりにくい例	分かりやすい例
タグ	タグ1	GA4_お問い合わせクリック
トリガー	クリック	Click_お問い合わせボタン
変数	URL	ClickURL_外部リンク判定

名前を見るだけで、

• 何を計測するのか
• どのイベントか
• 何に使うのか

が分かるようにすると、設定ミスを減らしやすくなります。

特に数か月後に自分で見直したときにも理解できる名前を付けておきましょう。

公開前には必ずプレビューモードでテストする

GTMでは、設定を変更したあと、そのまま公開しないことが大切です。

Google公式も、タグやトリガーを公開する前にプレビューモードでテストすることを推奨しています。

確認するときは、

• タグが発火するべき場所で発火する
• 発火してはいけない場所では発火しない
• 必要なイベントが発生する
• 変数の値が正しい
• GA4など送信先でも確認できる

ことを見てください。

特に重要なのは、「発火するか」だけでなく「余計な場所で発火しないか」も確認することです。

たとえば、お問い合わせページだけで発火させるタグが、トップページでも発火していないか確認します。

公開時にバージョン名と説明を残す

GTMでは、公開するとコンテナのバージョンが保存されます。

Google公式でも、バージョン名と説明を入力して変更内容を分かりやすく記録することが推奨されています。

たとえば、

悪い例

バージョン名：
「修正」

説明：
「変更しました」

では、あとから何を直したのか分かりません。

おすすめは、

バージョン名
「GA4_スクロール90％イベント追加」

説明
「記事ページで90％スクロール時にGA4イベントを送信。Tag Assistantで動作確認済み」

のように具体的に残す方法です。

Google公式では公開履歴から、公開日時や公開したユーザーも確認できます。

問題が起きたときに以前のバージョンと比較しやすくなるため、説明は省略しない方がよいでしょう。

一度に大量の設定を変更しない

GTMでは、一度に多くのタグやトリガーを変更すると、エラーが起きたときに原因を特定しにくくなります。

たとえば、

• GA4タグを変更
• クリックトリガーを変更
• スクロール計測を追加
• フォーム計測を追加
• Consent Modeも変更

を一度に行い、その後エラーが出た場合、どの変更が原因なのか分かりにくくなります。

可能であれば、

1. 1つ変更する
2. プレビューする
3. 動作確認する
4. 次の設定へ進む

という流れがおすすめです。

特に初心者の場合は、小さく変更して、小さく確認する方が安全です。

定期的に不要なタグやトリガーを整理する

長くGTMを使っていると、使わなくなったタグやトリガーが残りやすくなります。

たとえば、

• 古いGA4テストタグ
• 使わなくなった広告タグ
• テスト用クリックトリガー
• 古い測定IDを使ったタグ
• 名前だけでは用途が分からない変数

などです。

不要な設定が増えると、

• 二重発火
• 誤発火
• 管理ミス
• 原因調査の難化

につながります。

定期的に、

• 現在使っているタグ
• 発火しているトリガー
• 参照されている変数
• 古いテスト設定

を確認しましょう。

ただし、不要そうに見えるタグをすぐ削除するのではなく、どこから参照されているか、現在使われているかを確認してから整理することが大切です。

GTMは設定を増やすことよりも、あとから見ても理解できる状態を保つことが重要です。

エラーを防ぐ基本は、

分かりやすく設定する → プレビューする → 変更を記録する → 少しずつ公開する

という運用を続けることです。

Googleタグマネージャーのエラーについてよくある質問

ここでは、Googleタグマネージャー（GTM）のエラーやトラブルについて、初心者が疑問に感じやすいポイントをまとめます。

GTMでは、Tag Assistantに接続できたからといって、すべての設定が正常とは限りません。また、タグが発火していても、GA4などの送信先まで正しくデータが届いているかは別に確認する必要があります。

GTMでエラーが出てもサイト自体には影響しませんか？

エラーの内容によって異なります。

GTMのタグが発火しないだけであれば、Webサイトの文章や画像が表示できなくなるとは限りません。しかし、GTMから読み込んでいるJavaScriptやカスタムHTMLタグなどの内容によっては、サイトの動作へ影響する可能性があります。

たとえば、

• GA4タグが発火しない → アクセス計測ができない
• 広告タグが発火しない → 広告計測に影響
• カスタムHTMLに誤ったJavaScript → ページ動作に影響する可能性

があります。

そのため、「GTMのエラーだからサイトには関係ない」と決めつけず、プレビューモードで確認しましょう。

Tag Assistantで「Connected」になれば正常ですか？

「Connected」と表示された場合、Tag Assistantと対象サイトが接続できていることは確認できますが、すべてのタグ設定が正常という意味ではありません。

Google公式によると、プレビューモードではサイトをTag Assistantへ接続したあと、どのタグが発火したか、どの順番で動作したかなどを確認できます。 (support.google.com)

接続後は、

• 必要なイベントが発生しているか
• Tags Firedに目的のタグがあるか
• Tags Not Firedに残っていないか
• Variablesの値が正しいか

まで確認してください。

つまり、

Connected＝接続成功

であって、

Connected＝GTM設定すべて正常

ではありません。

タグが発火していれば設定は正常ですか？

タグが発火していることは重要な確認項目ですが、それだけで完全に正常とは判断できません。

たとえば、GA4イベントタグがTags Firedに表示されていても、

• 測定IDが間違っている
• 別のGA4プロパティへ送信している
• イベント名が間違っている
• 二重発火している
• Consent Modeの設定が影響している

可能性があります。

そのため、

1. Tag Assistantで発火確認
2. タグの設定内容を確認
3. GA4など送信先でも確認

という流れがおすすめです。

GTMを公開してもすぐ反映されないことはありますか？

通常、正しいコンテナを公開すれば変更内容は本番サイトで利用できる状態になります。

ただし、

• ブラウザキャッシュ
• WordPressのキャッシュ
• CDN
• JavaScript最適化
• 誤ったコンテナを公開

などによって、変更されていないように見える場合があります。

Google公式では、変更内容を反映するには「送信」から「バージョンの公開と作成」を選択して公開する必要があると案内しています。 (support.google.com)

反映されない場合は、まず公開済みバージョンが正しいかを確認し、そのあとキャッシュなどを調べましょう。

GA4にデータが表示されるまで時間がかかりますか？

はい。GA4では、レポートの種類によってデータが反映されるまでの時間が異なります。

Google公式では、通常のレポートやデータ探索では、データ処理に24～48時間かかる場合があると案内しています。 (support.google.com)

一方、リアルタイムレポートでは通常、より早く確認できます。Google公式によると、リアルタイムデータは通常数分程度で処理されますが、遅延する場合もあります。 (support.google.com)

設定直後は、

• Tag Assistant
• GA4リアルタイム
• DebugView

を利用して確認するのがおすすめです。

GTMとGA4を両方設置すると二重計測になりますか？

ここは少し注意が必要です。

GTMを使うこととGA4を使うこと自体は問題ありません。 GTMからGA4用のGoogleタグを配信するのは一般的な使い方です。

問題になるのは、

• WebサイトへGoogleタグを直接設置
• GTMからも同じGoogleタグを配信

というように、同じ計測を二重実装している場合です。

Google公式でも、GoogleタグとTag Managerの両方を同じ目的で設置すると、データが過剰に計測されるなど意図しない結果になる可能性があるため、どちらか一方の実装方法を使うよう案内しています。 (support.google.com)

エラーを直したあと再公開する必要がありますか？

本番環境のGTM設定を変更した場合は、基本的に修正後の内容を公開する必要があります。

たとえば、

トリガー修正
↓
保存
↓
Tag Assistantで確認
↓
正常
↓
公開

という流れです。

Google公式でも、プレビューで動作を検証したあと、「送信」から変更を公開する手順が案内されています。 (support.google.com)

プレビューモードで正常になっただけでは、本番サイトへ修正内容が反映されていない場合があるため注意しましょう。

設定を間違えた場合は以前の状態に戻せますか？

はい。GTMではコンテナのバージョンが保存されるため、以前の設定へ戻すことができます。

Google公式では、バージョンは特定時点のコンテナ設定を保存したものであり、必要に応じて以前のバージョンへ戻して再公開できると案内しています。 (support.google.com)

たとえば、

「昨日までは正常だったが、今日の変更後からエラーが出た」

という場合は、正常だったバージョンと現在のバージョンを比較できます。

そのため公開時には、

• バージョン名
• 変更内容
• 公開日時

を残しておくことが大切です。

GTMエラーは設置・発火・送信・公開の順に確認しよう

Googleタグマネージャーでエラーが起きたときは、設定を最初から作り直すのではなく、どこまで正常に動いているかを順番に確認することが大切です。

基本は、

設置 → 接続 → イベント → 発火 → 送信 → 公開

という流れです。

原因を一つずつ切り分ければ、初心者でも「どこがおかしいのか」を見つけやすくなります。

今日覚えておきたい重要ポイント3つ

今回の記事で特に覚えておきたいポイントは、次の3つです。

• GTMエラーでは、まずコンテナが正しく設置されているか確認する
• Tag Assistantでイベント・タグ・トリガー・変数を順番に調べる
• 修正後はプレビューで確認してからGTMを公開する

特に大切なのは、「タグが発火しない」という結果だけで判断しないことです。

どの段階まで正常なのかを確認することで、原因を効率よく見つけられます。

GTMの症状別エラー・原因・解決方法早見表

代表的な症状を一覧にすると、次のようになります。

症状	主な原因	最初に確認すること
Tag Assistantにつながらない	URL・GTM未設置・ブロック	URLとコンテナ
タグが発火しない	トリガー条件	Tags Not Fired
タグが二重発火	二重設置・複数トリガー	タグ設置方法
GA4に表示されない	ID・送信・除外設定	測定ID・リアルタイム
クリックを計測できない	Click条件	Variables
フォーム計測できない	Ajax・送信方法	Form Submit
スクロール計測できない	距離・方向	Scroll Depth
設定変更が反映されない	未公開・キャッシュ	公開バージョン
Googleタグが見つからない	タグ未設置・ID違い	タグとID
同意後も動かない	Consent Mode・CMP	同意状態

この表を見ながら、自分の症状に最も近い項目から確認すると効率的です。

GTMエラー確認チェックリスト

エラーが起きたときは、次の項目を上から順番にチェックしてください。

• □ 正しいGTMコンテナIDを使用している
• □ GTMコンテナが対象ページで読み込まれている
• □ Tag Assistantへ接続できる
• □ 目的のイベントが発生している
• □ 対象タグがTags Firedに表示される
• □ トリガー条件が正しい
• □ Variablesの値が想定どおり
• □ GA4など送信先のIDが正しい
• □ 二重設置されていない
• □ Consent ModeやCMPでブロックされていない
• □ 最新の変更が公開されている
• □ キャッシュの影響がない

全部を同時に確認する必要はありません。

上から順番に確認して、問題が見つかった場所で修正するのがポイントです。

エラーが解決しないときの確認順序

何を確認してよいか分からなくなった場合は、次の順番に戻ってください。

順番	確認場所	判断すること
1	GTMコンテナ	設置されているか
2	Tag Assistant	接続できるか
3	Events	イベントが発生するか
4	Tags	タグが発火するか
5	Variables	値が正しいか
6	GA4など	データが届くか
7	Version	最新設定を公開したか

考え方はシンプルです。

GTMがあるか
↓
イベントがあるか
↓
タグが動くか
↓
正しいデータを送っているか
↓
本番へ公開されているか

この順番を守ると、確認箇所をむやみに増やさずに済みます。

次に読むおすすめGTM関連記事

GTMのエラーを減らすためには、トラブルが起きてから対処するだけでなく、最初の導入や初期設定を正しく行うことも大切です。

次に読む記事としては、**「Googleタグマネージャーの導入方法｜アカウント作成から初期設定まで完全ガイド」**がおすすめです。

参考元：

• Google タグ マネージャー ヘルプ
• Google Analytics ヘルプ
• Google公式 Site Kit ドキュメント
• Tag Assistant・Consent Mode公式解説

GTMの設置、発火、公開、GA4連携、同意設定などはGoogle公式情報を基に確認しています。WordPressやCocoon、各種プラグインの挙動は環境により異なるため、個別設定の確認も必要です。

まとめ

Googleタグマネージャーでエラーが起きたときは、やみくもに設定を変えるのではなく、GTMコードの設置、Tag Assistantでの接続、タグの発火、トリガーや変数、GA4への送信、公開状況の順に確認することが大切です。特に、二重設置や未公開、測定IDの間違い、キャッシュの影響はよくある原因です。プレビューモードで一つずつ切り分ければ、初心者でも原因を見つけやすくなります。エラー時は確認順序を決めて、落ち着いて対処しましょう。