GA4のイベントが1件も届かないときの調べ方｜ページビューだけ記録されている状態の見分け方
GA4のイベントが1件も届かないときの調べ方｜ページビューだけ記録されている状態の見分け方
GA4のレポートを開くと、ユーザー数もページビューも毎日きちんと動いている。ところが、ボタンのクリックやフォーム送信といった自分で設定したイベントだけが、いつまで経っても1件も記録されない。「設定が反映されるまで時間がかかるのかな」と待っているうちに、数週間が過ぎている——。
先に結論を書きます。ページビューが動いていることは、イベント計測が動いている証拠にはなりません。GA4のページビューとカスタムイベントは送信の経路が別で、イベントだけが死ぬ壊れ方が実際に存在します。しかもこの壊れ方は、エラーが一切出ないまま静かに起こるため、レポート画面をいくら眺めても原因にたどり着けません。
弊社は名古屋でホームページの制作・運用を行っており、自社サイト（記事170本規模）の計測基盤も自分たちで運用しています。その自社サイトで実際に「ページビューは正常・イベントは全滅」という状態を切り分けて復旧させた経験をもとに、正しい確認手順と、この故障が生まれる典型的な仕組みを解説します。
正しい確認は「送信側」ではなく「到達側」で行う
イベントが届かないとき、多くの方はまず「タグが入っているか」を確認します。ページのソースを表示して、計測タグが存在することを確かめて安心する。しかしこの確認方法では、今回のような故障は検出できません。タグは入っていて、一部は動いてすらいるからです。
確認は次の順で行ってください。ポイントは、コードを眺めるのではなく実際にイベントがGA4に到達するかどうかを見ることです。
- GA4のリアルタイムレポートを開いたまま、自分でサイトの計測対象ボタンをクリックする。数十秒以内にそのイベント名がリアルタイムに現れるかを見る。現れなければ、設定の反映待ちではなく故障です
- 実ブラウザの開発者ツールでコンソールを開き、
typeof window.gtagと打つ。"function"が返れば送信関数は生きています。"undefined"が返ったら、それが原因です（後述する典型パターン） - ブラウザに実際に届いたHTMLを確認する。ここで重要なのは、開発環境のソースコードではなく「公開サーバーが返している実物」を見ることです。ビルドツールを使っている場合、書いたコードと出力されるコードは同じではありません
この順番にする理由は単純で、1番で届いていればそもそも問題がなく、届いていなければ2番・3番で原因の場所が特定できるからです。逆に「タグがあるか」から始めると、タグは存在するため「問題なし」と誤判定して調査が振り出しに戻ります。
「ページビューだけ動く」状態はこうして生まれる
弊社の自社サイトで実際に確認した事例を紹介します。サイトはビルドツール（静的サイトジェネレーター）で構築しており、計測タグは全ページに出力され、レポート上もページビューは正常でした。ところが、LINE相談ボタンのクリックとお問い合わせフォーム送信のイベントは1件も届いていませんでした。
原因は、ビルドツールが計測スクリプトを関数で包んで出力していたことです。
GA4の計測タグは、gtag という関数を定義して window（ページ全体で共有される領域）に公開し、各所からその関数を呼んでイベントを送る仕組みです。ところが、ビルドツールの一部の機能（変数をスクリプトに埋め込む機能など）を使うと、出力時にスクリプト全体が即時実行関数で包まれます。すると gtag 関数はその包みの中に閉じ込められ、外の世界からは window.gtag が undefined（存在しない）になります。
ここで質の悪いことに、初期設定の gtag('config', …) は包みの内側から呼ばれるため正常に動きます。ページビューはこの初期設定が送るので、レポート上は計測できているように見える。一方、ボタンのクリック処理など包みの外側から window.gtag を呼ぶイベントはすべて失敗する。これが「ページビューだけ動く」状態の正体です。
エラーが1件も出ない理由
さらにこの故障は、ブラウザのコンソールにエラーを残しません。イベント送信のコードが「gtag が存在すれば呼ぶ」という安全な書き方（オプショナルチェーン ?.() など）になっていると、存在しない場合は何もせず黙って通過するからです。安全に書いたことが、かえって故障を隠します。
この状態を放置すると何が起きるか。弊社の事例では、お問い合わせフォームのコンバージョン計測が動いていない期間が生まれていました。広告やSEOの成果判断はコンバージョン数を前提にするので、計測が止まったままだと「成果が出ていない」と誤った判断を重ねることになります。イベント計測を実装したら、必ずリアルタイムレポートで到達を1回確認するところまでをセットにしてください。
修正は1行、しかし検証はブラウザで
原因がこのパターンだった場合、修正自体は window.gtag = gtag; という1行を計測スクリプトに足し、関数を明示的に外へ公開するだけです。ただし修正後の検証も、コードを見て終わりにせず実ブラウザで typeof window.gtag → 実クリック → リアルタイム到達確認まで行ってください。
イベントが届かない、その他の典型原因
切り分けの過程で押さえておきたい、同じ「見た目は正常」系の原因を挙げます。
| 状態 | 起きること | 確認方法 |
|---|---|---|
| 再ビルド・デプロイでタグごと消えた | ある日を境に計測が全て止まる | 公開中のHTMLに測定ID（G-XXXX）が含まれるかを検索 |
| 一部のページだけタグが無い | 特定ページだけ計測ゼロ | 全ページ分のHTMLを機械的に確認（1ページ見て安心しない） |
| 送信関数が公開されていない（前述） | ページビューのみ動く | typeof window.gtag |
| イベント名の綴り違い | 送った側と見る側で名前が不一致 | リアルタイムに「何かしら」は届くか |
特に注意したいのが上の2つです。サイトをリニューアルしたり再ビルドしたりすると、計測タグの設定が引き継がれず丸ごと消えることがあります。また、静的に書き出す構成のサイトは1ページごとに独立したHTMLファイルが生成されるため、トップページだけ修正しても残りの全ページは直っていないという事態が起こりえます。確認した1ページのことしか、確認できたとは言えません。デプロイ後は主要ページを一括で機械的にチェックする運用にしておくと、この種の事故を未然に防げます。
復旧後：イベントを「コンバージョン」として登録するときの注意
イベントが届くようになったら、重要なイベント（フォーム送信・LINE相談クリックなど）をGA4のキーイベントとして登録します。ここにも実務上のつまずきどころがあります。
GA4の管理画面では、送信され始めたばかりのイベントをすぐ登録できないことがあります。画面上の登録方法はイベント一覧から選ぶ方式ですが、新しいイベントが一覧に載るまで最大24時間かかるためです。急ぐ場合はGA4のAdmin APIを使うと、一覧への掲載を待たずに事前登録できます。なおAPIで設定を書き換えるには、閲覧者権限では拒否されるため、編集者以上の権限が必要です。
もうひとつはカウント方法です。GA4のキーイベントは「イベントごとに1回」と「セッションごとに1回」を選べます。たとえばLINE相談ボタンが複数ページにある場合、同じ人が3ページでボタンを押しても、相談見込みとしては1人です。「何回押されたか」ではなく「何人が行動したか」を成果として数えたいイベントは、セッションごとに1回を選ぶと実態に合います。
まとめ：タグの存在ではなく、イベントの到達を確認する
- ページビューが動いていても、イベント計測が生きている証拠にはならない。別経路で、イベントだけ死ぬ壊れ方がある
- 確認は「タグが入っているか」ではなく、リアルタイムレポートへの到達で行う。実クリック→数十秒で表示、が動作の証明
- ビルドツールがスクリプトを関数で包み、
window.gtagが公開されないのが典型原因。実ブラウザのtypeof window.gtagで一発で分かる - 安全な書き方のイベント送信は、壊れていてもエラーを出さない。エラーが無いことは正常の証拠にならない
- デプロイ・リニューアルの後は、計測タグが全ページに残っているかを機械的に確認する
計測は、売上に直結するボタンやフォームの成果を数える土台です。「数字が入っているから大丈夫」ではなく、数えたいイベントが実際に届いているかを一度確かめてみてください。もし自社サイトの計測設定に不安があれば、現状の確認からお手伝いします。お気軽にご相談ください。