問い合わせフォーム改善の進め方｜入力・エラー・受付・計測のEFOガイド

問い合わせフォームの改善は、項目を減らしたり、ボタンを目立たせたりするだけでは終わりません。読者が必要な情報を理解して入力できること、間違いを直せること、送った内容が届き、担当者が対応できることまでつながって初めて、相談の入口として機能します。アクセスが増えても問い合わせにつながらないときは、フォームの前後を含めて確かめる必要があります。

この記事は、自社サイトの問い合わせを増やしたい企業の担当者に向けたEFO（入力フォーム最適化）の実務ガイドです。W3C、GOV.UK、Googleの一次資料と公開された設計例を参照し、点検、質問の整理、入力支援、エラー、受付、計測、改善依頼の順に解説します。記入例と数値例は説明用の架空例です。読み終えたら、自社フォームのどこを、何のために直すかを制作会社へ伝えられる構成にしています。

フォーム改善は、到達から担当者の対応までを確かめる

「問い合わせが少ない」を段階に分ける

最初に、サイトへ来た人が少ないのか、フォームへ進まないのか、入力後に送れないのかを分けます。フォームの到達が少ない場合は、サービスの対象や費用条件、相談できる内容、ページ内のリンクが伝わっていない可能性があります。入力を始めてから止まる場合は、質問の難しさ、必須情報の不足、操作やエラーが候補になります。同じ問い合わせ件数でも、確認する場所は違います。

さらに、送信できているのに担当者が気付かない問題もあります。メール通知の不達、管理画面を見る人の不在、休日の引き継ぎなどは、入力欄のデザインを変えても解消しません。「表示された」「送った」「保存された」「通知された」「返信した」を分けて、一つの相談がどう動くかを書き出してください。障害が見つかった場合は、色や文言の比較より先に直します。

平均完了率より、自社で数えられる状態を作る

フォームの目的が資料請求なのか、見積もり相談なのか、予約確定なのかで、必要な入力と完了の意味は変わります。他社の完了率をそのまま目標にすると、条件の違いを見落とします。自社では何を分母にし、何を一件と数えるかを先に決めましょう。フォームの表示回数、入力した人、送信操作、受付記録の件数は、同じ数字ではありません。

例えば、同じ人が送信ボタンを押し直すと、操作は二回でも相談は一件ということがあります。社内の動作確認や営業メールが混ざることもあります。数値を見始める段階で、除外するテスト、重複の扱い、新規相談の範囲をメモにしてください。基準を変えた日は記録し、計測方法を変更した前後の数字だけで改善効果を断定しないようにします。

最初の点検は、実際の相談場面を決めて行う

何となくフォームを眺めるより、「価格は未定だが改修を相談したい」「製品の故障を写真付きで伝えたい」のように、一つの用事を決めて試す方が問題を発見しやすくなります。説明用の架空データを使い、必要な情報が途中で分からなくならないかを確認します。正しい入力だけでなく、空欄、入力ミス、戻る操作も試してください。

本番で試す場合は、担当者とテストの日時・宛先・記録の扱いを決めます。可能なら実際の顧客へ通知しない検証環境を使い、公開後は合意したテスト受信先で最終確認します。問題を見つけたら、画面幅、操作順、期待した結果、実際の結果を残します。「使いにくい」という感想を、再現して直せる依頼に変えることが大切です。

質問は、初回対応で使う理由から整理する

項目ごとに、用途・担当者・聞く時期を決める

W3Cのフォーム解説は、手続きを完了するために必要な情報を尋ねることを勧めています。実務では、各項目について「誰が何の判断に使うか」「最初の連絡より前に必要か」を確認すると整理できます。項目数の少なさ自体を目標にすると、対応に必要な情報まで消してしまうことがあります。

例えば架空の設備修理窓口なら、訪問可否を判断する地域や、対象機種の情報が初回から必要な場合があります。一方、一般的な制作相談で請求先住所まで求める理由は別途検討できます。業種名だけで一律に決めず、実際の受付担当者へ確認します。削除する、任意にする、条件に応じて表示する、後で聞くという選択肢を並べて考えてください。

必須・任意・未定を、読者が迷わない形で示す

任意項目なのに空欄で送れない、必須の説明と実際の動作が違うと、利用者は先へ進めません。ラベルの表記と入力チェックを揃えます。「予算未定」「相談して決めたい」が実際に受け付けられるなら、その選択肢を用意する方法もあります。予算を入力しないと相談を受けられない運用なら、その理由や相談対象をフォームの前で説明します。

会社名、電話番号、部署名なども、必須かどうかは業務によります。電話が必要なら、折り返し連絡や当日の確認などの用途を示します。メールで対応できるのに電話を必須にする場合は、利用者の負担に見合う理由があるかを見直します。「任意」と書くだけでなく、入力しなかった場合に担当者がどう対応するかまで決めておきましょう。

質問一覧を使って、削減後の業務を確認する

次の表は、項目を整理するための架空の記入例です。最適な項目数や共通の正解を示すものではありません。現在のフォームを一行ずつ移し、用途が不明な欄を担当者と確認すると、見直す理由を共有できます。

質問を後で聞くなら、返信テンプレートや商談メモも変えます。フォームだけ簡単になり、担当者の聞き直しが増えると、対応時間や相談者の負担が移っただけかもしれません。見直し後は、初回返信までの時間、確認の往復、対応できない相談の割合も確認します。入力のしやすさと、相談を受けた後の仕事を一緒に整えましょう。

入力中は、何を書くかと操作する場所を分かりやすくする

ラベルを残し、入力例と説明を分ける

W3Cのラベルに関する資料では、入力欄を識別できる名前を対応付ける方法を説明しています。見た目の文字が近くにあるだけでなく、支援技術でも項目名を理解できる実装が必要です。制作会社には「入力欄とラベルが関連付けられているか」まで確認を依頼してください。

入力欄の中にだけ説明を置くと、文字を入れた後に何を尋ねられたか確認しにくくなります。項目名は外側に残し、記入例や条件は短い説明として分けます。相談内容なら「相談したいこと、現在の状況、希望時期など」と手掛かりを添える方法があります。長い例文をそのまま入力値に入れると、例文の消し忘れが起きるので、説明と回答を混ぜない設計にします。

入力形式は、受け付ける条件を必要以上に狭めない

ハイフンの有無、空白、名前の長さなどを過度に制限すると、正しい情報でもエラーになる場合があります。W3Cの入力検証の資料は、複数の表記を受け入れる考え方と、ブラウザ側だけでなくサーバー側でも検証する必要性を説明しています。入力支援と、受け取った情報を安全に扱う処理は両方必要です。

自動変換を入れる場合も、氏名や会社名まで一律に変えるのではなく、対象とルールを決めます。電話番号の区切りを受け付ける、前後の不要な空白を扱うといった処理は、保存先や連携先の条件も確認します。メールの形式をチェックできても、アドレスの持ち主や実際の到達までは確定しません。確認メールの役割と、返信できない場合の運用は別に考えます。

スマホのキーボードと、キーボードだけの操作を試す

スマホでは、文字入力用のキーボードが出た状態でラベルやエラーを確認できるか、下部の固定ボタンが入力欄を隠さないかを見ます。メールや電話など、内容に合った入力方式を設定できる箇所もあります。ただし、機種やブラウザで見え方が違うため、設定したという報告だけで終わらず、対象端末の画面で確認しましょう。

PCではTabキーで順に移動し、今どの欄を操作しているか分かるかを確認します。選択肢、同意欄、送信ボタンまで到達できることも必要です。スクリーンリーダーの確認は、名前や必須状態、エラーが伝わるかを含めて担当者へ依頼します。文字を拡大したときの確認を含む全体の点検は、企業サイトのアクセシビリティ改善ガイドも参考にできます。

エラーは、止める表示ではなく修正を助ける案内にする

間違った場所・理由・直し方をセットで伝える

「入力内容を確認してください」だけでは、何を直すか分かりません。メール欄が空なら返信先の入力が必要と伝え、形式が違うなら入力の例を示します。サーバーの障害や通信エラーを、利用者の入力ミスのように表示しないことも大切です。利用者が直せる問題と、サービス側で対応する問題では、案内する次の行動が変わります。

エラーは色だけで区別せず、文章でも示します。修正が必要な欄へ移動できるか、長いフォームの上に戻された後で対象を探し直す必要がないかを確認してください。実装の打ち合わせでは、未入力、形式違い、添付ファイルの条件違い、通信失敗について、それぞれ実際に表示する文章を決めると認識のずれを減らせます。

公開設計例：GOV.UKのエラー一覧から入力欄へ戻る

GOV.UK Design Systemのエラー一覧では、ページ上部の一覧から問題のある入力欄へリンクし、一覧と欄の近くの説明を揃える設計が公開されています。エラー一覧へキーボードのフォーカスを移すことも説明されています。利用者に、問題があることと直す場所をまとめて伝える公開例です。

例えば架空の見積もりフォームで、返信先と相談内容が空の場合、「返信先メールを入力してください」「相談内容を入力してください」を一覧にし、それぞれの欄へ移動できる形が考えられます。この文章と配置は応用例であり、GOV.UKの成果数値やAcquaの顧客実績を示すものではありません。見た目を似せるだけでなく、読み上げや移動後の操作を確認します。

入力途中の警告と、修正後に残る内容を点検する

入力を始めた直後に赤い警告を出し続けると、まだ回答を作っている人を急かすことがあります。一方、送信後まで何も分からないと、修正の負担が大きくなる場合もあります。どのタイミングで何を確認するかを項目ごとに決めます。入力中の即時チェックを入れれば一定割合で改善する、という一律の予測はできません。

エラー後は、正しく入力済みの内容が残るかを確認します。長文の相談をすべて書き直す必要があると、再送を諦める理由になります。添付ファイルを保持できない場合は、そのことと再選択の方法を伝えます。内容を残す仕組みには保存先や保持期間の判断も必要なので、共有端末での利用や扱う情報を踏まえて制作会社と設計してください。

確認画面と送信後の案内は、実際の処理に合わせる

画面を分けるかは、確認する内容の重さで決める

GOV.UKの質問ページの設計は、質問する理由、再入力を避けること、前へ戻れることを扱っています。複雑な手続きでは段階に分ける考え方が役立ちますが、短い相談フォームを機械的に一項目ずつ別ページへ分ける必要はありません。利用者がどの内容を確認したいかから判断します。

問い合わせの送信と、料金が発生する申し込みでは確認の重さが違います。確認画面を設けるなら、どの項目を修正できるか、戻ったときに入力が残るか、最終ボタンを押すと何が起きるかを明確にします。確認画面を省く場合も、送信前に入力内容を読み直せる配置を考えます。「次へ」と「送信」を同じ意味で使わず、実際の動作に合う表示にしてください。

送信処理・保存・通知・対応開始を分けて確認する

ボタンを押したことだけで受付完了と判定してはいけません。サーバーが処理を受け付けたか、必要な記録が保存されたか、通知先へ届くか、担当者が見る場所に表示されるかを確認します。どこまで成功したら完了画面を出すかは、フォームの構成によります。制作会社から処理の流れを説明してもらい、確認項目に落とし込みます。

通信が遅いときは、利用者が二度押ししたくなることがあります。処理中と分かる表示、重複受付への対応、失敗したときの再試行方法を確認してください。二度押しを防ぐためボタンを無効にしたまま、エラー後も再送できない状態にはしないようにします。対策を実装したことと、同じ相談が重複せず届くことを、別々に確認します。

公開設計例：完了の表示と「この後」を一緒に案内する

GOV.UKの完了ページには、受付番号や次の手続き、連絡先を示す例があります。公開サンプルでは申請の完了と、その後に担当窓口から連絡することが分けて説明されています。これは設計パターンの例であり、特定の問い合わせ増加を報告する事例ではありません。

企業の相談窓口なら、「受付した内容」「返信する方法」「返信の目安」「連絡がない場合の確認先」を実際の運用に合わせて示す方法があります。二営業日以内などの期限は、担当者が守れると確認してから掲載します。自動返信が届いたことは、担当者が内容を読んだこととは異なります。その違いが利用者にも伝わる文章に整えましょう。

受付後の案内を具体化する際は、自動返信メールの文面例と未着時の対応を参照してください。営業時間外の案内、返信の目安、公開前に確かめる項目をまとめています。

安心して送れる説明と、受付を続けられる運用を用意する

情報の用途と連絡方法を、業務の実態に合わせて伝える

読者は、入力した情報が何に使われ、どの方法で連絡されるかを気にすることがあります。フォームの近くには情報の取り扱いを確認できる案内を置き、電話を求めるなら用途も説明します。「営業電話はしません」「すぐ返信します」といった言葉は、実際の対応と一致している場合だけ使います。安心させるための文言が、運用と矛盾しないようにしてください。

必要以上に機密情報を書かせない説明も役立ちます。初回相談で詳しい顧客情報やログイン情報が不要なら、入力を求めない方針を明確にします。契約書や画面を添付する必要がある場合は、何を送るか、何を伏せるか、別の受け渡し方法を使うかを案内します。個別の法的判断は扱う情報や事業に応じて確認し、汎用テンプレートの文章だけで済ませないようにします。

迷惑送信対策は、正しい相談者が通れるかも確かめる

迷惑送信が増えている場合は、どの種類が多いかを見て対策します。自動投稿、不適切な添付、同じ内容の連続送信などでは、確認する箇所が異なります。認証や制限を強めれば終わりではなく、通常の相談者が操作できるか、入力に時間がかかる人が排除されないかを検証します。利用するサービスの設定と障害時の扱いも確認してください。

「迷惑送信がゼロになった」という結果だけでは、正常な送信まで止めていないか分かりません。許可した検証データが届くこと、失敗時に説明が出ること、別の連絡先が必要な場合に案内されることを確かめます。受付ログは必要な人だけが見られる状態にし、保管する情報と期間を決めます。入力しやすさと保護の両方を、実際の運用で確認しましょう。

メール通知だけに頼らず、担当と不在時の対応を決める

受付通知を一人だけに送っている場合、休暇や退職、メール設定の変更で見落とすことがあります。誰が最初に確認し、誰へ割り当て、いつまでに返答するかを決めます。通知の受信先を増やすだけでは、全員が誰かの対応を待つ状態になることもあります。担当済み、対応中、返信済みなど、相談の状態が分かる場所を用意してください。

メールが届かない場合に確認する場所、フォームの設定を変更できる担当、障害時の連絡先も記録します。公開後の保守では、送信の仕組みと通知経路を変更したときに再確認が必要です。制作会社が変わる場合は、サイトの引き継ぎガイドを使い、フォームの権限、保存データ、通知設定を受け渡しの対象に含めます。

効果測定は、送信操作と有効な相談を混ぜない

解析イベントが何を表すかを、受付記録と照合する

Googleの拡張計測機能の説明には、フォームの操作開始を扱うform_startと、送信を扱うform_submitがあります。自社のフォームでどの操作がイベントになるかは、実装と設定を確認する必要があります。イベントが記録されたことだけを、担当者へ相談が届いた証拠として扱わないでください。

検証では、正常送信、入力エラー、通信失敗、二度押し、完了ページの再読み込みを試し、それぞれ何が数えられるかを確認します。成功時だけ記録したいイベントが、失敗時にも発生していないかを見ます。解析で取れない利用もあり得るため、解析の件数と受付記録が常に一致する前提にはせず、違いの理由と使い分けを記録します。

架空の数値例で、どこが改善したかを読み分ける

以下は計算方法を示す架空例です。同一期間に、フォームへ到達した対象セッションが200、そのうち入力を開始したセッションが80、受付に成功したセッションが30だったとします。成功は同一セッション内で重複して数えません。到達を分母にした受付率は30÷200で15%、入力開始を分母にすると30÷80で37.5%です。比較に使う単位と集計条件を揃え、どちらの率かを表の名前にも書きます。

この例で受付記録も30件あり、そのうち新規案件の相談が20件で、残りが営業メールや既存顧客の連絡だった場合、新規相談は別に20件と報告します。その後の見積もりや受注は、さらに別の状態です。件数が増えても新規相談が減ったなら、フォーム改善以外に流入元や案内内容も確認します。率だけを高く見せるため、途中で対象や除外条件を変えないことが大切です。

解析には、回答内容や個人を特定する情報を流さない

Googleの個人を特定できる情報に関する注意事項を確認し、通常の解析イベントに氏名、メールアドレス、問い合わせ本文を入れない設計にします。入力値がURLやページタイトル、独自のイベント項目へ混ざることも点検対象です。単に入力欄を画面で隠しただけでは、解析へ送られる内容を確認したことになりません。

分析に必要なのは、どのフォームのどの段階か、成功か失敗かといった状態で足りる場合があります。顧客対応の詳細は権限を管理した受付システムで扱い、解析では集計に必要な情報へ絞ります。録画型の分析ツールを使う場合も、入力内容が記録されない設定と実際の出力を確認します。担当者の確認用画面にも、本物の顧客データを無用に広げないようにします。

改善依頼は、優先順位・合格条件・公開後の確認を決める

送れない不具合を先に直し、比較する変更を絞る

正常な内容が送れない、エラーを直せない、受付通知が届かないといった不具合は、ボタンの色を比べる前に対応します。次に、初回に不要な質問、理解しにくい説明、スマホでの操作を見直します。変更する理由と確認方法を一緒に記録し、修正した場所だけでなく、前後の操作がつながるかを検証してください。

A/Bテストを行う場合は、何を比較し、どの指標と期間で判断するかを先に決めます。一律に各100件あれば判定できるわけではありません。基準の率や検出したい差、流入量などで必要な条件が変わります。件数が少ない窓口では、まず利用者に近い人の操作観察と不具合の修正を進め、少数の送信増減だけで勝敗を断定しない方法が現実的です。

制作会社へ渡す依頼メモを作る

依頼時は「問い合わせを増やしたい」から一段具体化します。次の項目を埋めると、調査、修正、運用変更の範囲を話し合いやすくなります。まだ分からない数値は未計測と書き、推測で埋める必要はありません。

• 対象：フォームのURL、用途、想定する相談者、担当窓口。
• 現状：困っている操作、発生する端末、再現手順、確認日。
• 質問：各項目を初回に聞く理由と、必須・任意の扱い。
• 修正案：変える表示や動作、変える理由、後で聞く情報。
• 合格条件：入力保持、エラーからの移動、重複、受付と通知。
• 確認方法：検証環境、テストデータ、受信先、計測の除外方法。
• 公開対応：担当者、実施日時、復元方法、異常時の連絡先。
• 評価：分母と件数の定義、集計期間、相談内容を確認する担当。

例えば「電話番号を任意にする」依頼なら、必須マーク、ブラウザとサーバーのチェック、確認画面、通知メール、連携先の必須条件まで対象を確認します。見た目の印を消すだけでは、空欄で送れるとは限りません。変更する画面と受け取り側をセットで見積もってもらうと、公開後の手戻りを減らせます。

公開後は、相談が届いて対応できる状態を維持する

公開直後は、合意した方法で正常送信から受信までを確認し、計測の二重発生や入力内容の欠けを見ます。その後は、比較できる期間のデータが集まってから、到達、入力、受付、新規相談を振り返ります。広告の変更や繁忙期などの条件も残し、前後比較だけでフォームの効果を言い切らないようにします。

フォームは、公開して終わる部品ではありません。サービス内容、担当者、返信方法、外部ツールが変わったときも点検が必要です。まずは、自社の相談を一つ想定し、入力から担当者の対応まで確認するところから始めてください。Acquaのホームページ制作・改善の対応範囲を確認し、フォームの現状調査や改善を相談することもできます。

一次資料の確認日：2026年9月9日。公開された設計パターンと説明用の架空例を区別しています。特定の完了率や問い合わせ増加を保証する内容ではありません。