フォームの入力エラーはどこで起きた？画面とGA4の記録を分けて確かめる

「送信ボタンを押した」と、何が違う？

押した操作、ブラウザの送信処理、GA4の送信イベントは別に読みます。どれか一つが記録されても、会社が相談を受け付けた証拠までそろったとは限りません。

図の入力欄とボタン、処理の記録、計測の記録、受付資料を見比べます。別の資料で確かめる内容があることに注目してください。

説明図の原画を開く

ボタンを押した記録から、残る欄を「成功」で埋めません。エラー文字が出たら、その文字と対象の欄も、計測とは別の観測として残します。

送信しようとした操作

利用者がボタンを押すなど、送信を始めようとした操作です。実際に次の処理へ進んだかは別に調べます。

ブラウザのsubmitイベント

HTMLのフォームで送信が行われる際のイベントです。入力内容を確かめる標準の仕組みが送信を止める条件では、このイベントまで進みません。すべての独自処理を、この一つの仕組みで説明するものではありません。

GA4のform_submit

Google公式がフォーム送信時のイベントとして説明する計測の記録です。GA4に何が取得されたかを読むもので、社内の保存先・通知・内容確認を代わりに証明するものではありません。

GA4のform_startは、同じセッションでフォームに初めて関わったときの記録です。開始と送信、イベント数と人数・相談案件数も分けます。本稿では、エラー表示のあった試行を、どの記録と対応させられるかを調べます。

根拠：Google公式のフォーム操作イベントと、MDNのsubmitイベントの説明。ボタンのクリック一般を、常に同じ送信結果とする定義ではありません。

標準の入力検証と独自の処理を分けて読む

画面に似たエラーが見えても、どこで入力を止める実装かによって調べる記録が違います。見た目だけで、ブラウザの標準機能か、フォーム側の独自処理かを決めません。

図は二つの別条件です。標準検証で処理が止まる観測と、独自検証の画面エラーとGA4記録が並ぶ観測を、上下の改善結果として読まないでください。

説明図の原画を開く

標準検証の例で分かるのは、ブラウザ側の送信イベントが起きていないことまでです。GA4の欄は未確認のままです。独自検証の別例ではGA4記録があっても、何がそれを生んだかは未確認です。

標準HTMLの検証が送信を止めた例

必須のメール欄が空で、「メールアドレスを入力してください」と出た架空例です。標準の入力検証で不正と判定され、ブラウザのsubmitイベントには進んでいません。MDNは、標準検証で入力が通らずinvalidが起きる場合、フォーム送信を止めるためsubmitイベントもないと説明しています。

ただし、この原票のGA4欄は未確認です。ブラウザ側の記録を見て、GA4も必ず記録なしと補ってはいけません。実サイトが同じ標準検証を使っているかも、担当者が実装と観測から確かめます。

独自の検証で差し戻す別例

もう一つの架空例は、「メールアドレスの形式を確認してください」と表示され、GA4の送信イベントには記録があります。標準検証の不正判定と、ブラウザのsubmitイベントは未確認です。独自のプログラムが、何をきっかけに検証・計測しているかを実装担当と調べる必要があります。

この組合せを、すべてのJavaScriptや画面遷移しないフォームで起こる仕様にはしません。また、入力検証が原因だと確定した例でもありません。標準機能を切る、タグを増やす、といった修正を先に選ばず、現在の処理を読みます。

根拠：MDNのDescription。同資料はフォーム要素のイベントと送信ボタンを区別し、スクリプトからの送信方法によってもイベントの扱いが異なると説明しています。ここでは実プログラムを実行していません。

同じフォームの、どの記録を照合する？

対象フォームと入力条件を決め、その試行の画面・処理・計測を対応させます。別フォームの集計と、一つのエラー画面を直接比べないようにします。

図では、対象フォーム、エラー文字を読む紙面、計測条件の資料を別に置いています。同じ確認対象かを調べる関係で、すべての条件が取得済みという印ではありません。

説明図の原画を開く

対応が分からなければ、その欄を未確認にします。数字の大小より先に、何を操作し、どの画面と記録を読んだのかを確かめてください。

1. 見積相談フォームを一つ選びます。対象ページと公開版か確認用かを実装担当と合わせます。Google公式のform_idはフォームのid属性、form_nameはname属性、form_destinationは送信先URLです。存在・取得が未確認の値を作らず、実装の値と計測の対象条件を照合します。
2. 入力条件と画面の文字を残します。必須欄が空なのか、形式の条件外なのか、どの操作をしたのかを区別します。エラーの対象欄と文字、確認時刻、端末・ブラウザ、比較期間を記します。入力内容そのものや実顧客の連絡先を解析へ送らないようにします。
3. 実装担当がブラウザ側の処理を読みます。標準検証が働いたか、独自の検証か、どの段階のイベントを記録しているかを確かめます。画面が赤いだけでは、ブラウザの不正判定が起きたという証拠にはしません。
4. 計測担当が同じ試行のイベントを読みます。既存の確認条件が整っている場合、GA4の「管理」→「データの表示」→「DebugView」で対象のデバッグ端末を選び、イベントと関連パラメータを確認します。見た画面の時刻・対象と対応させ、別の端末の記録を混ぜません。

DebugViewにはデバッグモードが必要です。新しい設定や接続が必要なら、担当者が権限と影響を確認します。プライバシーや同意の条件で表示されない場合もあるため、見つからないことだけで、操作自体がなかった、永久に計測されない、とまでは判断しません。

通常レポートの集計を見るときも、フォームの条件と期間を残します。パラメータをレポートで使うには、カスタムディメンション等の条件があります。今の権限で確認できなければ、その限界を記して計測担当へ質問します。この記事の制作で、デバッグ設定の有効化や実フォームへの試験送信を行ったわけではありません。

根拠：フォーム識別パラメータと利用条件、Google公式のDebugView。図の期間・端末はそろえるための方針です。

確認画面へ進んだら、受付済みでよい？

確認画面への到達と、最終送信・社内受付は分けます。画面の呼び名だけで、相談が担当者へ届いたと報告しません。

図は入力後に確認画面へ進んだ、さらに別の架空例です。確認画面とGA4の記録はありますが、社内受付の資料は未確認です。

説明図の原画を開く

この例が示すのは、確認画面へ進んだという観測までです。先の二例を直して成功した結果ではなく、最終送信が完了したという意味にも変えません。

原票の三例目には、エラー表示なし、標準検証の不正判定なし、GA4の送信イベントあり、画面表示ありという記録があります。ただし画面は「確認画面」です。エラー文字そのものの欄とブラウザの送信イベントは未確認で、社内受付・根本原因・変更後の結果も分かっていません。

実際に確認を計画するときは、その画面が入力内容を見直す途中なのか、サーバーの処理結果なのか、実装担当へ聞きます。続けて受付担当が、対応する内容を所定の保存先で読めるか、担当への通知と別に確かめます。見ていない受付を、画面表示やイベントの記録で埋めないでください。

三つの例に、同じ人・セッションという対応はありません。共通欄の期間・端末も確認をそろえる方針です。未確認を0件、存在しない、失敗、成功に読み替えず、明示された否定の記録とも区別してください。

何を直すかは、観測と仮説を分けて決める

「エラーが見えた」「GA4に記録があった」は観測で、その組合せの理由は別に調べます。原因を示す資料がなければ、設定変更や入力項目の削除を急ぎません。

図は、画面の文字、処理、計測、受付の資料を見比べて質問を決める関係です。変更案の紙面は提案で、修正成功の記録ではありません。

説明図の原画を開く

表示の問題はフォーム担当、イベントの対象とタイミングは計測・実装担当、受付は受付担当と確認します。一つの未確認を、別の資料の記録だけで原因確定にしないことが要点です。

エラーの文字が分からない

どの入力欄に、何が問題と表示されたかを先に確認します。W3Cの説明では、検出された入力エラーの対象と内容を文字で知らせることが示されています。文言の設計自体は、既存の問い合わせフォーム改善の記事へ分けています。

エラー表示とGA4記録が並ぶ

イベントが何をきっかけに取得されたか、同じフォーム・試行かを調べます。すべての計測を止める、別イベントを作るといった作業を、原因の証拠なしに始めません。

画面は確認できても受付が見られない

受付担当へ対象と確認範囲を伝えます。保存先や期間が違う可能性も未確認として残し、フォーム故障や永久未配信と断定しません。

エラーを継続的に測りたい場合

入力エラーの観測が必要なら、「どのフォームで、どの条件のエラー表示を、一試行の中でどう記録するか」を先に決めます。表示された回数を、そのまま困った人数や失った案件数にしません。同じ人の再操作や、入力エラーと通信・サーバー処理の失敗も区別します。

Google公式は、独自イベントを作る前に、自動収集や推奨イベントで目的を満たせるかを確認するよう説明しています。現在のイベントで何が分かるかを読んでから、必要なら計測担当が定義・実装・重複の扱いを設計します。エラーの発生を調べるための記録と、受付成果として評価する条件は別です。ここでは新しいイベント名やコードを作成していません。

変更する場合は、対象、変更内容、担当者、確認する条件を残します。変更後は同じフォーム・入力条件・端末等で、エラー表示、ブラウザ処理、計測、画面、受付を再確認する計画にします。以前と集計の定義が変わるなら、その区切りも明示します。これは今後の確認方法で、三つの架空例を修正前後に並べるものではありません。

根拠：W3Cの入力エラー識別の説明、Google公式の独自イベント。実サイトのアクセシビリティ全体適合や、計測改善の成果を認定する記事ではありません。

まとめ：エラーを見た試行を、別々の記録で確かめる

画面にエラーがある試行を、GA4の送信記録だけで成功・失敗や原因にまとめないでください。対象と条件を決め、どの資料で何を確認したかを対応させます。

図の対象フォームとエラー文字、処理・計測・受付の資料を見比べます。調べる関係であり、送信と受付が完了した一本道ではありません。

説明図の原画を開く

標準検証でブラウザの送信処理が止まる例でも、GA4の未知はそのままです。独自検証でGA4記録が見える別例は、同じ結果が全実装で起きる証拠ではありません。確認画面に進んだ例も、社内受付まで確認済みにはなりません。

開始・送信と実際の相談の違い全体は、既存のフォーム開始・受付確認の記事で扱います。必須項目やエラー文言の設計はフォーム改善、相談前の情報から受付までの全体改善はBtoBサイトの問い合わせ改善へ分けています。

記録が整理できず、表示・計測・受付のどこから確かめるか迷う場合は、対象ページと観測できた範囲を添えてDREEXYへ相談できます。支援範囲・費用・受付可否は個別に確認してください。

2026年10月23日に公式の必要主文を確認しました。三例は説明用で、実際の件数・率・計測IDはありません。実フォーム送信、実GA4/GTM設定、実顧客情報の取得、根本原因・変更後の成果・実サイトの適合は確認していません。