「送信したつもり」を減らす問い合わせフォームの直し方

問い合わせフォームは、見積もりや予約の相談を受け付ける入力欄です。送信ボタンを押した後に何も分からなければ、客は受付できたか判断できません。この記事では、サービス担当者が入力から受付完了までを点検し、直すべき表示を記録する方法を紹介します。

基にするのは、Webをさまざまな人が利用できるようにするW3C WAIのフォーム解説です。同資料は、送信の成功・失敗を知らせ、エラーには分かりやすい修正方法を添えるよう案内しています。[1] 以下の見積もりフォーム、文言、記入表は独自の編集提案です。実在企業の画面や実測した改善結果ではありません。

参照確認日：2026年9月15日。公式資料に基づく点検ガイドであり、実アカウントでの設定や送信は確認していません。

クリックと受付完了を分けて考える

最初に決めるのは、何を確認できたら「受け付けました」と表示するかです。本記事の点検では、ボタンを押したこと、内容を送る処理、受け付けた結果を分けます。ボタンの反応だけを見て受付成功と判断しないためです。

説明には、法人向けの清掃見積もりを依頼する架空のフォームを使います。客が会社名や相談内容を入力し、サービス側が依頼を受け付けてから、担当者が連絡する想定です。見積もり依頼の受付は、清掃の予約確定を意味しません。

この例では、サービス側で依頼の受付を確認できたときに、完了の案内を表示する設計を提案します。受け付けたか分からない状態は、成功にも失敗にも決めつけず、別の確認対象として扱います。受付記録をどこで確認するかは、自社のフォームを管理する担当者と先に決めておきます。

何を書く欄か、入力した後も分かるようにする

入力欄には、用途が分かる名前を付けます。この名前を「ラベル」と呼びます。WAIは、ラベルと入力欄を対応付けることを案内しており、見た目だけでなく、画面の内容を音声で伝える読み上げソフトにも関わります。[2]

清掃見積もりの例なら、「名前」だけでは会社名か担当者名か迷います。「ご担当者名」とすれば、書く対象を絞れます。欄の中の薄い記入例だけに頼らず、入力した後も欄の名前が見える構成を提案します。

必ず入力する欄には「必須」と表示します。WAIは、必須項目をラベルで明示し、仕組みの側にも必須であることを設定する方法を説明しています。[3] 任意の電話番号を空欄にしただけで送れなくなるなど、表示と実際の条件が食い違わないかも点検します。

以下は、担当者が自社フォームを読みながら埋めるための独自の記入表です。「表示案」は客に見せる文章、「確認事項」は社内で決める条件を指します。架空の欄名を、自社の見積もりフォームにある欄名へ置き換えて使います。

点検する欄	改善前の例	表示案	確認事項
氏名	名前	ご担当者名（必須）	会社名とは別に必要か
連絡先	メール	返信先メールアドレス（必須）	この宛先へ返信する運用か
電話	電話番号	電話番号（任意）	空欄でも送信できるか
相談内容	内容	清掃場所と相談内容（必須）	見積もりに必要な説明があるか

「内容」を具体化する場合も、不要な情報まで求めないようにします。この例なら「事務所・店舗などの種類と、相談したい内容をご記入ください」という補足案が考えられます。客が何を書けば相談を始められるかを、実際の受付担当者が判断して決めます。

エラーは、場所と直し方を一緒に伝える

エラー表示の役割は、失敗を知らせるだけではありません。客が直す欄を見つけ、その場で修正できる案内にします。WAIは、フォーム上部のエラー一覧に該当する欄名、問題の説明、修正方法、欄へ移動するリンクを含める方法を示しています。[1]

独自の改善前の例を「入力エラーです」とします。これだけでは、会社名、メールアドレス、相談内容のどこを見るべきか分かりません。改善案では、上部に「返信先メールアドレスを確認してください」と表示し、その欄の近くで不足している内容を伝えます。

例えば、説明用の入力値を「tanaka」とした場合、改善案は「返信先メールアドレスに@がありません。メールアドレス全体を入力してください」です。この文言は、実際に@の不足を検出した場合に使う想定です。別の理由で受け付けられないときまで、同じ文章を表示しないようにします。

赤い枠だけで済ませず、文章でも問題を示す案にします。会社名と相談内容が正しく入っているなら、そのまま残し、メールアドレスだけ直せるかも確認します。入力内容を残す範囲は、扱う情報と自社の安全上の条件に合わせて決めます。

修正できたかを見る際は、最初のエラー表示だけで終えません。メールアドレスを直した後、古いエラーが残っていないか、別の欄が空に戻っていないか、もう一度送信できるかまで追います。修正のたびに相談内容を書き直させる状態なら、その再入力を改善対象として記録します。

入力途中と送信後を同じ扱いにしない

日付などは、入力し終わるまで指定の形になりません。WAIも、入力中の確認が適さない場合を挙げ、別の欄へ移ったときに確認する例を示しています。[1] 何文字か入力した段階で毎回強い警告を出す必要があるか、欄ごとに検討します。

電話番号については、WAIが区切り方など複数の書き方を受け入れる考え方を示しています。[3] 自社の受付処理がハイフン付き・なしの両方を扱えるなら、客に書き直しを求めない案を検討できます。対応できない場合は、入力前の説明とエラーの案内で、同じ書き方を示します。

完了画面は、受け付けた内容と次の案内を分ける

受付後は、何が完了したのかを具体的に書きます。WAIは、成功を知らせる表示を重視し、ページの主な見出しやページタイトルで結果を伝える方法を紹介しています。[1] 清掃見積もりの例なら、「完了」より「見積もりのご依頼を受け付けました」とする案が考えられます。

次に、客が待つべき連絡を示します。返信の目安を載せるなら、受付担当者が守れる条件を確認してから決めます。自動返信メールを送らない仕組みなのに、「確認メールを送りました」と書かないことも点検項目です。

以下は独自の説明用比較です。「改善後」は表示の提案であり、問い合わせ増加などの成果を確認した意味ではありません。

場面	改善前の例	改善後の表示案
受付成功	完了しました	見積もりのご依頼を受け付けました
次の案内	ありがとうございました	担当者から、入力されたメールアドレスへご連絡します
予約との区別	お申し込み完了	この時点では清掃の予約は確定していません
受付結果が不明	エラー。再送してください	受付結果を確認できませんでした。再送前に、下記の確認窓口へお問い合わせください

最後の案は、実際に受付状況を確認できる窓口を用意する前提です。掲載時は、自社の既存の確認窓口と必要な情報を続けて記載します。窓口がない場合は、そのまま使わず、受付状況を調べられる方法から設計し直します。

見積もり依頼の受付と予約確定を一つの「完了」でまとめないことで、客に伝える約束を明確にできます。予約サービスでも、単なる相談受付なのか、日時まで確定したのかを実際の処理に合わせて書き分けます。画面の文言だけ先に強めないことが判断基準です。

公式の例を見てから、自社のテスト用フォームで点検する

まず、必須入力とメールアドレスの形式確認がどう働くかを、公式の例で見ます。サービス担当者はWAIの入力確認の解説を開きます。ここは自社フォームの設定画面ではなく、説明と入力例を読む場所です。[3]

「Validating required input」は必須入力を確認する項目です。「Validating common input」はメールアドレスなど一般的な入力形式を確認する項目です。後者の「Email」欄に説明用の文字列「tanaka」を入れると、正しいメールアドレスの形式でない入力を試せます。表示や確認のタイミングには利用環境による違いがあるため、特定の警告が必ず出るとは扱いません。[3]

次に、自社のフォームを管理する担当者が用意したテスト用ページへ切り替えます。テスト用とは、本物の見積もり依頼や営業通知を発生させずに動きを確認する場所です。そのページのURL、必要な閲覧権限、通知先、受付記録の確認場所を受け取ってから進めます。資料には個別サービスの管理画面は載っていないため、設定のボタン名はここでは指定しません。

入力から受付までを一件ずつ記録する

この点検では、客が修正を終えて受付結果を理解できるかを確かめます。テスト用フォームの会社名には「フォーム点検用」、相談内容には「動作確認用。実際の見積もり依頼ではありません」と入力する案にします。返信先には担当者が管理するテスト用メールアドレスを使い、実在顧客の情報は使いません。

1. 必須の相談内容を空欄にして、自社フォームの送信ボタンを押します。未入力の欄と直し方が分かるかを記録します。
2. 相談内容を入力し、メールアドレス欄に説明用の「tanaka」を入れて送信を試します。エラーの対象と理由が一致するかを見ます。
3. メールアドレスを管理下のテスト用アドレスへ直します。会社名と相談内容が残っているかを見てから送信します。
4. 完了の案内を読み、管理担当者に受付記録を照合してもらいます。表示と記録が一致しなければ、成功として記録しません。

以下も独自の記入例です。「未実施」はまだ試していない状態、「表示のみ確認」は受付記録まで照合していない状態です。合否だけでなく、どこまで見たかを残します。

試す条件	見る箇所	記録例	改善・再確認すること
相談内容が空欄	欄名と修正案内	説明用：赤枠だけ	未入力であることを文章で示す
メール形式が不正	他の入力欄	説明用：相談内容が消えた	内容を残して再試験する
正しい内容で送信	完了案内と受付記録	表示のみ確認	管理担当者が記録を照合する
受付結果が返らない	結果不明の案内	未実施	管理担当者が安全に再現できるか確認する

読み上げでの確認も、見た目の点検とは分けて残します。WAIのラベル解説の「Associating labels explicitly」は、欄名と入力欄を明示的に対応付ける説明です。[2] エラーの通知方法は、フォーム通知の解説の「Listing errors」で確認できます。[1] 実装担当者には、欄名とエラーが読み上げでも対応して伝わるかの確認を依頼します。

入力の形を画面側で確認するだけでは、安全性の確認は完了しません。WAIは、データを受け取って処理するサーバー側でも入力を確認する必要があると説明しています。[3] 本記事の点検で、安全性全体やすべての利用環境への対応を検証したとは扱いません。

AgentSignalで、ページ内の操作を確かめる

AgentSignalを利用中で対象ページの録画が残っている場合は、「Web録画」でそのページを含む訪問を選びます。再生すると、どこを押したか、どこまで画面を進めたかを確認できます。フォームの記事なら入力エラーの前後、料金ページなら申込案内までの操作が確認候補です。

録画だけで離脱の理由や注文の成立は断定できません。画面で見えた操作を、ページの説明や実際の受付記録と合わせて調べます。録画されていない過去の操作は再生できないため、取得条件と保存期間も確認してください。

最初に直すのは、客が次へ進めない表示

記録した問題から、「どこを直すか分からない」「入力が消える」「受け付けたか分からない」を先に選ぶ案を提案します。担当者、直す文言、再試験する条件を一組にして残せば、見た目を変えただけで作業を閉じずに済みます。

人に頼まれた作業を進めるAIがフォームを操作する場合も、エラーを直し、受付結果を確かめるという確認観点は残します。今回の資料はAI向け機能の検証資料ではなく、WebMCPなど特定の技術への対応だけで問題が解決するとは判断できません。

文言を直した後は、同じ入力条件で再試験します。案内が分かるようになったかと、問い合わせが増えたかは別の確認です。まずは入力から受付までのつまずきを記録し、未確認の受付処理を残さないように進めます。