問い合わせフォームの見直し方｜入力前・エラー時・送信後で確認するポイント

アクセスはあるのに問い合わせが少ないとき、入力項目の数だけを見ても原因は切り分けられません。フォームを「入力前」「入力中・エラー時」「送信後」の3場面に分けて確認します。フォームが処理に必要な項目だけを求めているか確認し、各項目のラベルと入力条件を入力前に示してください。エラーでは場所・理由・直し方を具体的に伝え、エラー後も入力済み内容が保たれるか確かめます。送信後は受付完了と次の連絡方法・目安を知らせ、実際のスマートフォンで最後まで操作できるか確かめます。

この記事では、制作会社へ依頼する前に自社で試せる確認方法と、見つかった症状から改修の優先順位を決める方法を整理します。項目を減らすだけで終わらせず、問い合わせを始める判断から受付後の安心までを一続きの体験として見直しましょう。

問い合わせフォームは一連の体験で見る

入力前から送信後までの3段階を左から右へ結び、各段階の確認対象を対応付けるを整理した図 — 問い合わせフォームを入力前・エラー時・送信後の連続した体験として理解させるために、入力前から送信後までの3段階を左から右へ結び、各段階の確認対象を対応付けるを整理しています。

問い合わせフォームの問題は、入力欄の中だけで起きるとは限りません。フォームを開く前に必要な情報が分からず離脱する人もいれば、入力後のエラーで戻れなくなる人、送信できたか分からず同じ内容を送り直す人もいます。

そこで、確認範囲を次の3場面に分けます。「入力前」は、問い合わせの対象や準備する情報を理解して開始できるかを見る場面です。「入力中・エラー時」は、項目名、入力条件、エラーからの復帰を確かめます。「送信後」は、受付結果と今後の連絡が伝わるかを確認します。

W3CのForms Tutorialは、フォームを簡潔にし、処理の完了に必要な情報だけを求めること、各入力欄のラベルや説明を用意すること、成功とエラーの結果を利用者へ通知することを示しています。つまり、項目数、説明、エラー、完了表示は別々の修正ではなく、同じ送信体験を支える要素です。出典

W3C

最初の点検では、各場面をまたいで一人の利用者として操作してください。管理画面の設定項目を眺めるだけでは、説明を読んで入力し、間違いを直して送信する流れの詰まりは見つけにくいためです。

入力前に分かる情報を整える

フォームを開いた人が最初に判断したいのは、「自分の用件を受け付けてもらえるか」「何を準備すればよいか」「送った後はどうなるか」です。入力欄の直前に、その判断材料を短くまとめます。

フォームを始める前に示す内容

受け付ける問い合わせの目的と対象
入力にかかる時間の目安を表示する場合は、実機で測った現実的な時間
会社名、連絡先、相談内容など、手元に準備しておく情報
送信した情報の利用目的と、個人情報の取扱いを確認できる導線
返信に使う手段と、実際の運用で守れる連絡時期の目安

ここで長い説明を読ませるのではなく、入力を始めるか判断できる情報を先に置きます。対象外の相談や急ぎの連絡方法があるなら、フォーム入力後ではなく開始前に伝えた方が、利用者のやり直しと社内の振り分けを減らせます。

「所要時間約○分」と書く場合は、担当者がパソコンだけでなくスマートフォンでも入力し、平均ではなく無理なく完了できる時間を基にします。表示する根拠を持てない場合は、項目数や準備物を示す方が誤解を招きません。

必須項目を必要最小限にする

必須項目を減らすときは、項目を機械的に削るのではなく、その情報を誰がいつ使うかを確認します。営業分析にあると便利な情報と、初回返信に欠かせない情報を同じ扱いにすると、利用者へ事業側の都合を背負わせることになります。

現行フォームの項目を一覧にし、次の順で見直します。

その項目を使う社内担当者と業務を特定する
初回の受付・返信にないと処理できないかを確認する
初回連絡の後で聞ける情報か、任意回答にできる情報かを分ける
使用先を説明できない項目は削除候補にする

たとえば住所は、訪問先の確認が初回対応に必要な業種では必須候補です。一方、メールや電話で相談内容を確認してから対応地域を判断できるなら、都道府県だけにする、任意にする、後で聞くという選択肢があります。会社名や予算、希望時期も、すべてのフォームで一律に必須とせず、自社の受付手順に照らして決めます。

W3Cは、利用者には処理の完了に必要な情報だけを入力してもらい、無関係または過剰な情報を求めるとフォームから離れやすくなると説明しています。出典

W3C 項目を残すか迷ったときは、「この情報がないと初回対応のどの作業が止まるか」を答えられるかで判断してください。

ラベルと入力例で迷いを減らす

各入力欄には、入力中も見える項目名を置きます。入力欄の中に薄く表示されるプレースホルダーだけを項目名にすると、文字を入力した瞬間に説明が消え、何を直している欄か分かりにくくなります。

項目名の近くには、利用者が入力する前に知るべき条件を示します。必須か任意か、使える文字、文字数、日付や電話番号の形式などです。条件がない欄に不要な指定を増やすのではなく、実装上の制限がある欄だけ、短い説明と入力例を添えます。

表示例は、次のように役割を分けます。

ラベル：「メールアドレス」
入力例：「例：name@example.jp」
条件：「確認のため受信できるアドレスを入力してください」
状態：「必須」または「任意」を文字で表示する

デジタル庁の2024年3月29日版ガイドブックは、ラベルと入力欄を関連付けること、全角・半角、文字数、使用文字などでエラーになる場合は入力前に説明すること、必須などの情報を色だけで伝えないことを確認事項として挙げています。出典

ウィキメディア・コモンズ +1

見た目に項目名があるだけでなく、制作担当者にはラベルと入力欄をプログラム上でも関連付けられているか確認します。これにより、画面読み上げソフトを使う人も、どの項目を操作しているか把握しやすくなります。

エラーの場所と直し方を示す

エラー発見から修正完了までに必要な情報を順番に示すを整理した図 — 分かりにくいエラー表示と、修正しやすいエラー表示の違いを整理するために、エラー発見から修正完了までに必要な情報を順番に示すを整理しています。

エラー表示は「間違っています」と知らせるだけでは足りません。利用者が送信まで戻れるように、どこで、なぜ、どう直すかを一続きで伝えます。

「入力内容に誤りがあります」という全体メッセージだけでは、複数の欄から原因を探さなければなりません。「メールアドレス：@を含む形式で入力してください。例：name@example.jp」のように、対象項目、理由、修正例が分かる文にします。赤い枠線だけに頼らず、エラーを示す文字と入力欄の近くの説明を組み合わせます。

エラーが複数ある場合は、フォーム上部に件数と一覧を出し、各メッセージから該当欄へ移動できると修正しやすくなります。W3CのUser Notificationでは、エラー一覧に項目のラベル、分かりやすい原因、修正方法、形式条件を含め、該当する入力欄へのページ内リンクを設ける方法が示されています。出典

W3C

修正後に送信操作へ戻れるかも確認します。最初のエラー欄へ画面表示と操作の対象（フォーカス）が移るか、直した後に次のエラーへ進めるか、エラー一覧が更新されるかを試してください。

さらに優先して見るのが入力保持です。メールアドレスを直しただけなのに、問い合わせ本文や会社名まで消えるフォームは、利用者に同じ作業を繰り返させます。空欄送信と形式違いを意図的に起こし、エラー後も問題のない入力内容が残るかを確認します。保持されない場合は文言修正だけでは直らない可能性があるため、制作担当者へ「どの操作で、どの項目が消えたか」を伝えます。

送信後の不安を残さない

送信ボタンを押した後、画面が少し変わるだけでは受付結果を判断できません。完了ページまたは同じ画面内の通知で、送信を受け付けたことを見出しと本文ではっきり示します。W3Cも、成功メッセージは操作の完了を確認するために欠かせないとしています。出典

W3C

完了表示には、利用者が次に迷う情報をまとめます。受付控えをメールで送るか、担当者からメールと電話のどちらで連絡するか、連絡までの目安はいつかを、自社の運用に合わせて書きます。目安を表示するなら、繁忙時でも守れる内容にしてください。

自動返信メールを使う場合は、送信した内容の控え、送信先の会社名、今後の連絡方法を確認できるようにします。自動返信を送らない設計なら、完了画面でそのことが分かるようにし、「メールが来ないので送れていないのでは」という不安を残さないようにします。

利用者向けの完了表示と、社内への通知メールは別々に確認してください。画面に完了と出ても社内通知が届かない、社内には届いても利用者に完了が伝わらないという問題は起こり得ます。正常送信のテストでは、ブラウザの表示、利用者への控え、社内の受信を一組として記録します。

スマートフォンで実送信前まで試す

パソコンのブラウザ幅を狭めるだけでは、ソフトウェアキーボードが開いたときの見え方、指での押しやすさ、画面のスクロールは十分に確認できません。390px相当の画面を目安にしつつ、普段使っている実際のスマートフォンで操作します。

デジタル庁のガイドブックは、スマートフォンでは画面が小さく、ボタンやリンクを指でタップするため大きさへの配慮が要ること、多様な入力を使う場合はシミュレーターだけでなく実機で複数回テストすることを勧めています。出典

ウィキメディア・コモンズ +1

テスト用の問い合わせであることを社内受信担当者と共有し、次の順で確認します。

フォームを開き、見出し、説明、必須・任意、個人情報の案内が横スクロールなしで読める
何も入力せず送信し、エラーの件数、場所、理由、直し方が分かる
メールアドレスなどへ形式違いを入力し、入力前の条件とエラー文が一致している
エラーを直した後も、ほかの入力済み内容が残り、最初のエラー欄へ戻りやすい
キーボードで入力欄や送信ボタンが隠れず、拡大やスクロールをしても操作できる
正常な内容を入力して送信し、完了表示、利用者向け控え、社内受信を確認する
見つかった問題を「入力前」「エラー時」「送信後」に分け、端末名、ブラウザ、操作、結果とともに記録する

一度に直す場所を決めるため、記録には「使いにくい」だけでなく再現手順を残します。たとえば「送信後に上部へ戻ったが、エラー欄まで移動できない」「メール形式を直すと本文が消える」と書けば、制作担当者は表示、入力チェック、データ保持のどこを調べるか判断しやすくなります。

症状から改修優先度を決める

見つかった問題は、見た目の違和感から並べるのではなく、送信を妨げる度合いで整理します。利用者が完了できない問題を先にし、その後にやり直し、説明不足、社内運用の負荷を見ます。

症状から決める改修優先度
症状	先に確認する箇所	優先理由
送信できない、同じエラーを繰り返す	必須判定、形式チェック、送信ボタン、送信処理	問い合わせが完了しないため、最優先で実装または設定を直す
エラー後に入力内容が消える、戻れない	入力保持、エラー欄への移動、画面のスクロール位置	利用者へ入力のやり直しを強いるため、表示調整より先に直す
項目名・条件・エラー理由・完了結果が分からない	ラベル、入力説明、エラー文、完了画面	文言や表示で直せる場合があり、症状を場面別に切り分けやすい
不要な情報が多い、社内で振り分けにくい	必須項目、問い合わせ種別、通知先、受付手順	送信を妨げる問題を解消した後、利用者と受付担当双方の負担を減らす