← 記事一覧へ

ブログ

フォーム送信がコンバージョンとして計測されない原因と確認方法

公開 2026-07-21

フォーム送信 計測されないフォーム コンバージョン 計測問い合わせ 計測されないgtm フォーム トリガー 発火しない

「問い合わせは実際に届いているのに、コンバージョンだけが増えない」——フォーム送信を成果地点にしているサイトで、非常によく相談される症状です。メール通知は来ているのだから送信は成功している。それなのに広告やGA4のコンバージョンは0のまま。ここには、フォーム特有の「計測の落とし穴」が潜んでいます。

こんな状況に心当たりはありませんか？

  • 問い合わせのメールは届くのに、コンバージョンが フォーム送信だけ計測されない
  • 送信後に ページが切り替わらず、その場で「送信しました」と出る
  • GTMの 「フォーム送信」トリガーが発火しない
  • ボタンは押せているのに、計測イベントが飛んでいる気配がない
  • 複数ステップのフォームで、どの段階を成果とすべきか はっきりしない

この記事では、フォーム送信がコンバージョンとして計測されない原因を5つの論点に整理し、開発者ツールとGTMプレビューでの確認手順、そして「成功したという出来事」を合図に計測する確実な設計までまとめます。

まず整理：フォームの計測は「送信の起き方」で決まる

フォームの計測が落ちる原因の大半は、**「送信が実際にどう処理されているか」**を計測側が捕まえられていないことにあります。従来の「送信するとページが切り替わる」前提が、いまのフォームでは崩れているのです。

送信の起き方 計測側から見えること 崩れると起きること
ページ遷移あり 完了ページの読み込みを合図にできる そもそも遷移が起きず合図が来ない
AJAX送信（遷移なし） ページは変わらないので「何も起きていない」ように見える 読み込み起点のタグが動かない
イベント発火 送信成功の出来事を直接つかめる リスナー未装着だと出来事を取りこぼす

ポイントは、「ボタンが押された」と「送信が成功した」はまったく別の出来事だということです。以下の論点1〜5は、この「送信の起き方」を順番に潰していく流れになっています。

原因1：AJAX送信でページ遷移が起きず、完了の合図がない

いまの問い合わせフォームの多くは、送信ボタンを押してもページが切り替わりません。裏側で非同期（AJAX）にデータを送り、同じページのまま「送信ありがとうございました」を表示します。ユーザー体験としては快適ですが、計測にとっては大問題です。

多くの計測タグは、「完了ページが新しく読み込まれた」ことを発火のきっかけにしています。ページもURLも切り替わらないと、ブラウザから見れば「何も起きていない」のと同じで、タグが動きません。

  • 送信後、URLは同じまま 完了メッセージだけ差し替わる
  • 完了が モーダル（ポップアップ） で表示され、ページ自体は遷移しない
  • 「送信しました」が JavaScriptで描画 されるだけ

この場合は、ページ読み込みではなく「送信が成功したという出来事（イベント）」を合図にタグを動かす設計が必要です。合図の作り方は原因5で詳しく扱います。関連する完了ページ側の死角はサンクスページでコンバージョンが計測されない原因と確認方法も参照してください。

つまずきやすい例： 「完了メッセージはちゃんと出るのに計測されない」なら、まずAJAX送信を疑ってください。URLが変わらない完了は、ページ読み込み起点のタグでは捕まえられません。

原因2：イベントリスナーが付いておらず、送信をつかめていない

「送信という出来事で計測する」設計にしていても、その出来事を待ち構えるリスナーが正しく付いていないと、当然ながら何も起きません。ここは設計の意図と実装がずれやすい箇所です。

  • 計測用のスクリプトが、フォームが表示される前に一度だけ動いて終わっている（後から差し込まれたフォームには付かない）
  • 対象のフォームを別の要素と取り違えてリスナーを付けている
  • フォームが動的に生成される（ポップアップ・SPAの画面遷移後など）ため、付けたい相手がまだ存在しない

とくに、フォームが後から画面に現れるタイプでは、「ページ読み込み時に一度リスナーを付ける」だけでは間に合いません。フォームが出た後に付け直す、あるいは親要素側で受け止める設計が必要になります。

つまずきやすい例： 「トップの問い合わせは計測されるのに、ポップアップの問い合わせだけ計測されない」なら、後から出るフォームにリスナーが付いていない可能性が高いです。

原因3：GTMの「フォーム送信」トリガーが発火しない

Googleタグマネージャー（GTM）には「フォーム送信」という便利なトリガーがありますが、これは素直なHTMLフォームを前提にした仕組みで、いまのJavaScript制御フォームでは発火しないことが多いです。

  • フォームが送信直前に preventDefault() で本来の送信をキャンセルし、独自処理でデータを送っている（GTMが待つ「送信イベント」が起きない）
  • 入力チェック（バリデーション）でいったん止まり、GTMの検知タイミングとすれ違う
  • 送信後のリダイレクトが速すぎて、トリガーが動く前に画面が変わってしまう

つまり「フォーム送信トリガーを置いたのに動かない」のは、故障ではなくフォームの作りとトリガーの前提が合っていないケースがほとんどです。GTM全般が動かないときの切り分けはGTMでコンバージョンが計測されないときの確認手順も参照してください。

つまずきやすい例： JavaScriptで制御されたフォームでは、「フォーム送信」トリガーに頼らず、送信成功時にカスタムイベントを送る方式（原因5）に切り替えるのが確実です。

原因4：ボタンの「クリック」と実際の「送信」を取り違えている

苦し紛れに「送信ボタンのクリック」を成果として計測することがありますが、これは数字がずれる原因になります。クリックと送信成功は、別の出来事だからです。

  • ボタンを押したが、入力エラーで送信されなかった（クリックは計上、送信は失敗）
  • ユーザーが何度もボタンを連打した（1件の問い合わせが複数カウント）
  • 送信のサーバー側処理が失敗したのに、クリックだけは記録される

クリックを成果にすると、実際の問い合わせ件数より多めに膨らむ傾向があります。正しくは「送信が成功した」瞬間を成果とすべきで、そのためには次の原因5の設計が必要です。

つまずきやすい例： 「コンバージョン数が実際の問い合わせより明らかに多い」なら、送信成功ではなくボタンのクリックを数えている可能性を疑ってください。

原因5：確認方法と、確実に計測する設計

ここまでの原因は、最終的に**「送信したときに計測の信号が本当に飛ぶか」**を自分の目で見れば、多くが切り分けられます。手順はシンプルです。

  1. 問い合わせフォームを開き、ブラウザの開発者ツールを開く
  2. 「Network（ネットワーク）」タブで conversion や collect（GA4）などでフィルタする
  3. 実際にフォームを送信し、その瞬間に計測リクエストが飛ぶかを見る
  4. あわせて「Console」でエラーが出ていないか、送信のイベントが起きているかを確認する
  5. GTMを使っているなら、プレビューモードでフォーム送信時にトリガーが発火しているかを見る

そして、確実に計測する設計の基本は「送信が成功したという出来事を、自分で明示的に合図する」ことです。フォームの送信処理が成功した際のコールバック（成功時に呼ばれる処理）の中で、計測用のカスタムイベントを1回だけ送る——この方式なら、AJAXでもSPAでもモーダルでも、原因1〜4のほとんどを回避できます。

つまずきやすい例： 広告ブロッカーやトラッキング防止機能がオンだと、リクエスト自体がブロックされ「発火していない」ように見えます。確認はこれらをオフにしたクリーンな状態で行ってください。

サードパーティのフォームツール（iframe埋め込み）の落とし穴

フォームがHubSpot・Typeform・Formstackなどのサードパーティツール製で、ページにiframeとして埋め込まれている場合、そのiframe境界が計測の死角になります。iframeは独立した閲覧コンテキストであり、ページ側で動いているGTMはiframe内のイベントを検知できないため、フォーム送信トリガーは発火しません。

  • フォームがiframe内の別ドキュメントに存在し、クロスオリジン制限によってページ側のスクリプトからイベントを読み取れない
  • 一部ツール（例：HubSpotのJavaScript埋め込み）は送信成功時に親ページ側でコールバックを発火するが、これはスクリプト埋め込み方式でのみ有効で、素のiframeでは動かない
  • iframe内のリダイレクト型完了ページは、外側のページではページ読み込みイベントとして検知されない

対処法はツールによって異なります。フォームプロバイダーが送信成功時のJavaScriptコールバックやイベントを提供しているか確認してください（HubSpotのonFormSubmittedなど）。提供されていれば、そのコールバックからdataLayerイベントをプッシュし、コンバージョンタグのトリガーにします。親ページへのフックがないiframeのみの場合は、スクリプト埋め込み方式への切り替えか、バックエンドで送信を検知するサーバーサイド方式を検討してください。

つまずきやすい例： HubSpotやTypeformの埋め込みフォームで「GTMを設定したのに何も発火しない」場合、ほぼ確実にiframe境界の問題です。タグ自体のデバッグの前に、どの埋め込み方式を使っているか確認してください。

Cookie同意とプライバシー制限がコンバージョンを静かに落とす

フォーム計測の実装が技術的に正しくても、Cookie同意とブラウザのプライバシー制限がコンバージョンの記録を阻むことがあります。これは原因1〜5とは異なるカテゴリの障害で、タグは発火しているのにデータが到達しないケースです。

  • Cookie同意バナーを拒否した（または操作しなかった）訪問者には広告用Cookieが書き込まれず、コンバージョンのリクエストがCookieなしになるか完全にブロックされる
  • SafariのITP（Intelligent Tracking Prevention）やFirefoxの強化型トラッキング防止がデフォルトでトラッキングCookieを制限・削除し、ウェブトラフィックの約35〜40%に影響する
  • 同意モードV2では、ad_storageが拒否されるとGoogleは匿名化されたpingのみを受信し、コンバージョンはモデリングによる推定値となる——直接計測ではないため、レポート上の数値が減る

結果として、フォームは正しく発火し問い合わせも届いているのに、Google Ads上のコンバージョン数が実際より少なく表示されます。プライバシー規制が厳しい地域（EU/EEA、英国）やSafari/モバイルSafariのトラフィック比率が高いサイトほど、この差は大きくなります。

失われたアトリビューションを回復するには、同意モードを有効にしてCookie拒否時のコンバージョンをモデリングし、拡張コンバージョン（後述）を設定してCookieの代わりにファーストパーティデータで照合します。Safari固有の損失についてはSafari ITPとコンバージョンの損失も参照してください。

つまずきやすい例： Cookie同意バナーを更新・厳格化するたびにコンバージョン数が減る場合、原因は計測のバグではなく同意によるデータ欠損です。

拡張コンバージョン：Cookieが失うアトリビューションを取り戻す

フォームには他の多くのコンバージョンにはない自然な優位性があります。コンバージョンが発生するまさにその瞬間に、メールアドレス・電話番号・氏名といったファーストパーティデータを収集しているからです。拡張コンバージョン（Enhanced Conversions）はこのデータを使い、Cookie制限で失われるアトリビューションを回復します。

仕組み：フォーム送信が成功した際、コンバージョンタグがユーザー提供データ（メール、電話、住所）をSHA-256でハッシュ化し、コンバージョンのリクエストと一緒に送信します。Googleがこのハッシュをログイン済みユーザーのデータと照合し、広告クリックへのアトリビューションを復元します——サードパーティCookieは不要です。

GTMでの設定手順：

  1. Google Adsのアカウントレベルで拡張コンバージョンを有効化（コンバージョン → 設定）
  2. GTMのGoogle Ads コンバージョン トラッキング タグを編集し「ウェブサイトからのユーザー提供データを含める」を有効化
  3. フォームのフィールド（メールは最低限必須、電話と氏名でマッチ率向上）を対応する変数にマッピング
  4. 公開して48〜72時間待ち、診断タブでタグの健全性を確認

フォームの場合、拡張コンバージョンは通常失われるコンバージョンの5〜25%を回復します。回復率は訪問者のGoogleログイン率に依存します。同意モードのモデリングと組み合わせれば、「届いた問い合わせ数」と「報告されるコンバージョン数」のギャップの大部分を埋められます。検証手順は拡張コンバージョンの検証を参照してください。

つまずきやすい例： 拡張コンバージョンを有効にしても、ユーザー提供データの変数が正しいフォームフィールドにマッピングされていないと、ハッシュが空になりマッチ率はゼロです。GTMプレビューモードでメール変数が実際に値を取得しているか必ず確認してください。

手元の確認だけでは分からないこと

自分でフォームを送信して発火を見るのは有効ですが、自分の手元で1回確認するやり方には構造的な限界が2つあります。

  1. 自分の環境＝本番のユーザー環境ではない。 あなたは同意バナーに同意済みで、拡張機能も社内IPの条件も違います。手元では送信時に問題なく発火しても、別環境の訪問者ではリスナーが付いていない・タグが落ちている、ということが起こります。
  2. 広告クリックがからむと確認が難しい。 「広告経由で来た人がフォーム送信したとき本当に計測されるか」をきちんと見ようとすると、本来はライブ広告をクリックして経路を再現する必要があり、これは自己クリックとして広告ポリシー違反のリスクを伴います。

「自分の操作では送信時に発火しているからOK」と判断すると、本番のユーザーがたどる実際の経路でデータが欠けている問題を見逃しがちです。

チェックリスト：フォーム送信の計測を確認する

  • 実際にフォームを送信し、開発者ツールのNetworkで計測リクエストの発火を確認した
  • Consoleに送信時のエラーが出ていないか確認した
  • AJAX送信（ページ遷移なし）の場合、送信成功イベントで発火する設計になっているか確認した
  • 後から出るフォーム（ポップアップ・SPA）にもリスナーが付いているか確認した
  • GTM利用時は、プレビューモードでフォーム送信時にトリガーが発火するか確認した
  • ボタンのクリックではなく「送信成功」を成果として計測しているか確認した
  • 複数ステップフォームでは、どの段階を成果とするか明確に決めた
  • 広告ブロッカー・トラッキング防止・社内IP除外をオフにしたクリーンな環境で確認した
  • サードパーティのフォーム埋め込み（HubSpot、Typeformなど）の場合、親ページへのコールバックが利用できる埋め込み方式か確認した（素のiframeではないか）
  • Cookie同意設定と同意モードがコンバージョンのリクエストをブロックしていないか確認した
  • 拡張コンバージョンを有効にしている場合、GTMプレビューでユーザー提供データの変数が実際に値を取得しているか確認した

よくある質問（FAQ）

Q. 問い合わせメールは届くのに、コンバージョンが計測されません。 A. メール通知はフォームツールのサーバー側処理、コンバージョンはブラウザ側の計測タグで、別経路です。AJAX送信でページ遷移が起きず発火していない（原因1）か、送信をつかむリスナーが付いていない（原因2）のが代表的です。実際に送信して発火を確認してください。

Q. GTMの「フォーム送信」トリガーを置いたのに発火しません。 A. JavaScript制御のフォームでは、preventDefault()やバリデーションでGTMの検知とすれ違い、発火しないことが多いです（原因3）。送信成功時にカスタムイベントを送る方式に切り替えるのが確実です。

Q. 完了メッセージは表示されるのに計測されないのはなぜ？ A. URLが変わらないAJAX送信やモーダルで、計測タグの発火きっかけ（ページ読み込み）が起きていない可能性が高いです（原因1）。送信成功イベントで発火する設計にする必要があります。

Q. コンバージョン数が実際の問い合わせ件数より多いです。 A. 送信成功ではなくボタンのクリックを数えている可能性があります（原因4）。連打や送信失敗もカウントされるため膨らみます。「送信が成功した」瞬間を成果にしてください。

Q. HubSpot（またはTypeform）の埋め込みフォームで何も計測されません。 A. フォームがiframeとして埋め込まれている場合、ページ側のGTMはiframe内のイベントを検知できません——クロスオリジン制限によりアクセスがブロックされます。プロバイダーのスクリプト埋め込み方式に切り替え、JavaScriptコールバック（HubSpotのonFormSubmittedなど）からdataLayerイベントをプッシュし、そのイベントでコンバージョンタグを発火させてください。

Q. 手元では計測できているのに、Google Adsのコンバージョン数が実際の問い合わせより少ないです。 A. Cookie同意とブラウザのプライバシー制限が最も可能性の高い原因です。Cookieを拒否した訪問者やSafari/Firefoxのユーザーは、フォーム送信に成功してもコンバージョンのリクエストがブロックされるかCookieなしになります。同意モードと拡張コンバージョンを有効にしてギャップを埋めてください。

Q. 複数ステップのフォームでは、どこを成果にすべき？ A. 最終送信の成功を成果にするのが基本です。途中の「次へ」を発火点にすると、離脱した人まで計上されて水増しになります。各ステップの到達を別イベントで見たい場合は、成果とは分けて設計してください。

まとめ：フォームは「送信成功の出来事」で計測する

フォーム送信が計測されない原因は、①AJAX送信で遷移が起きない、②リスナー未装着、③GTMのフォーム送信トリガー不発、④クリックと送信の取り違え、⑤複数ステップの成果地点の曖昧さ——に集約されます。いずれも「ページ読み込み」を合図にする古い前提から抜け出し、送信が成功したという出来事を自分で明示的に合図する設計にすれば、多くが解決します。確認の全体像はコンバージョン計測の検証チェックリストも活用してください。

ただし、手元での発火確認には限界があります。本番環境で、別環境の訪問者も含めた実際の経路でも、フォーム送信が正しく記録されているかまで踏み込むことが、本当の意味での「計測できている」確認です。診断の入口としてはコンバージョンが出ないときの診断ガイドも参照してください。

ConversionOKは、外部の独立した実ブラウザであなたの本番ページにアクセスし、フォーム送信時に実際に送信される計測リクエストを傍受して検証します。自分の広告をクリックする必要も、社内環境の影響を受けることもありません。まずは無料の静的チェックで、フォーム計測の入口を確認してみてください。