問い合わせフォームの改善は、入力欄を短くするだけでは終わりません。訪問者がフォームを見つけられない、エラーを直せない、送信できても担当者に通知が届かない、返信が遅れる。どの段階で止まっているかによって、直す場所は変わります。
この記事では、フォームへ進む前から社内の返信までを5段階に分け、公開ページで試せる点検方法を示します。サイト全体の改善手順は親記事のホームページ公開後の運用・改善ガイドで扱っています。本記事はその中でも、問い合わせフォームと送信後の引き継ぎに絞った手順です。
まず「どこで止まったか」を分ける
フォームの閲覧数、入力開始、送信操作、送信成功、担当者の受信、返信は異なる出来事です。たとえば入力開始が少ないなら導線や目的説明を、エラーが多いなら入力形式や案内を、送信成功後に連絡が来ないなら通知先や社内対応を確認します。アクセスだけを見て「項目が多いから問い合わせが少ない」と決めつけないことが出発点です。
Googleアナリティクスの拡張計測にはform_startとform_submitがありますが、Googleの説明では前者はフォームとの最初の操作、後者は送信時のイベントです。form_submitの数だけで、サーバーでの受理や担当者への到達まで完了したとは判断しません。イベントの設計と確認はGA4での問い合わせ計測も参照してください。
導線から返信まで：5段階の公開前・改善時QA
次の表は、企業サイトのフォームを点検するために作った確認表です。特定の顧客案件の測定結果ではありません。PCとスマートフォンで、可能ならキーボード操作も含めて試し、日時・端末・結果・担当者を残します。
スマートフォンでは、次の表を左右にスクロールして確認できます。
| 段階 | 訪問者・担当者に起きること | 実際に試すこと | 残す確認結果 |
|---|---|---|---|
| 1. フォームに進む | 相談先と次の行動が分かる | サービスページから問い合わせへ進めるか。ボタンの文言と遷移先が一致するか。スマートフォンでも見つかるか | 入口URL、端末、遷移先、行き止まりの有無 |
| 2. 入力する | 必要な項目と用途が分かる | 各項目の見えるラベル、必須・任意、入力例、個人情報の利用目的を確認。スマホのキーボードと拡大表示でも入力できるか | 項目ごとの必要理由、表示・操作の問題 |
| 3. エラーを直す | 何を直せばよいか分かる | 未入力、誤ったメール形式、全角・半角の違いを試す。項目名と直し方が文字で伝わり、入力済み内容が不必要に消えないか | テスト入力、表示された文言、再入力の要否 |
| 4. 送信結果を知る | 送れたか判断できる | 正常送信と通信失敗を試す。完了表示が明確か、二重送信を防げるか、失敗時に再試行先が分かるか | 完了画面または表示、受付記録、失敗時の案内 |
| 5. 社内で受け取り返信する | 担当者が内容を見て対応できる | テスト送信が正しい宛先・管理画面に届くか。休日・担当不在・迷惑メール判定でも見落とさないか。返信担当と期限の決め方があるか | 受信時刻、通知先、担当者、返信と未対応の記録 |
1〜4が正常でも5が止まれば、訪問者からは「送ったのに返事がない」状態になります。逆に通知が正常でも、エラーを直せない人は送信まで進めません。同じテスト送信を最後まで追ってください。
入力項目は「少なさ」より必要理由で決める
W3C WAIのフォームの手引きは、手続きに必要な情報だけを求めること、各入力欄にラベルと説明を設けることを勧めています。項目を減らす際は、受付時に不可欠な情報と、返信後に聞ける情報を分けます。
たとえば、架空の「Webサイト制作の初回相談フォーム」を設計すると仮定した場合、次のように検討できます。これは実際のフォーム仕様や成果を示す表ではありません。
スマートフォンでは、次の表を左右にスクロールして確認できます。
| 項目例 | 初回の判断例 | 理由・次の確認 |
|---|---|---|
| 連絡用メールアドレス | メールで返信するなら必須 | 入力形式を確認し、誤入力時の修正案内を用意する |
| 相談内容 | 最小限を求める | 詳細な仕様書は初回から強制しない |
| 氏名・会社名 | 受付業務で必要か確認する | 不要なら後で聞く選択肢を残す |
| 電話番号 | 折り返し電話が必要な場合だけ必須を検討 | メールで連絡できるなら任意にできないか確認する |
| 予算・希望公開日 | 初回に必須か再検討する | 未定でも相談できるなら「未定」を選べる形にする |
この判断は業務ごとに変わります。項目を減らした後は、問い合わせ内容の不足で何度も聞き直す状態になっていないかも見ます。
個人情報の扱いも入力体験の一部です。個人情報保護委員会のFAQは、ホームページの入力画面で本人から連絡先を取得する場合、原則として利用目的の明示が必要だと説明しています。取得状況から目的が明らかな場合などの例外もあるため、フォームの目的・利用範囲に合う表示を確認してください。同意チェック欄が常に必要だと決めつけないことも大切です。
読めるラベルと、直せるエラーにする
項目名を薄いプレースホルダーだけに置くと、入力後に何の欄か分かりにくくなります。W3C WAIは、目的を示すラベルを付け、必須か任意か、形式などを案内するよう説明しています。
エラーは「入力内容に誤りがあります」だけで終えず、項目名と直し方を文章で示します。赤色だけに頼らず、該当欄へ戻れるようにします。W3Cの入力検証は、電話番号などの表記ゆれに寛容であることと、サーバー側でも確認することを説明しています。過度な全角・半角指定や意味のない書式制限を見直します。
送信後には成功と失敗を区別した短い文を出します。W3Cの通知の手引きは、完了確認とエラーの修正方法を伝えることを勧めています。「送信完了」と表示されるだけで社内に届いたことまで保証されないので、担当者側の受信確認も別に行います。
計測は「送信ボタンを押した」と「受付できた」を分ける
改善前後を比べるには、同じ定義と期間で「フォームへの入口」「入力開始」「送信操作」「受付成功」「担当者の対応」を見ます。指標の組み立て方は企業サイトの問い合わせ率の考え方を参照してください。対象期間や条件が違う数字を並べても、フォーム変更の影響は判断できません。
GA4でイベントを設定する場合は、クリックだけを成功とせず、完了画面やサーバー側の受付記録などと照合します。メールアドレス、氏名、相談本文などをイベント名・パラメータ・URLへ含めないようにします。Googleアナリティクスの公式ヘルプは、個人を特定できる情報を送らないよう求めています。
改善の順番は、まず重大な断線から
- 送信できない、成功表示が誤る、通知が届かない問題を先に直す。
- 項目名や必須・任意、エラー文、スマートフォンとキーボード操作を直す。
- 項目の必要性を見直し、後で聞ける質問を移す。
- 同じ条件で受付成功と対応状況を計測し、必要なら導線や文言を見直す。
よくある質問
送信完了ページは必須ですか？
別ページは必須とは限りません。フォーム内の完了表示でも、成功したこと、次に何が起こるかが明確なら確認できます。ただし表示上の成功と実際の受付・通知を区別して試します。
form_submitが計測されていれば問い合わせは届いていますか？
届いたとは限りません。GA4のイベントは担当者のメール受信や返信まで表しません。実際の受付記録と通知先をテスト送信で確認してください。
まとめ
フォーム改善は、フォームに進む・入力する・エラーを直す・送信結果を知る・担当者が受け取るという経路を実際に通すことから始めます。5段階の記録を残せば、直す順番をチームで共有できます。
