問い合わせフォームは、入力画面だけを見て公開可否を決めず、入力エラー、送信完了、自動返信、担当者受信までを一連で試します。正常送信とエラー送信の両方を行い、自動返信と担当者宛ての通知は別々に確認してください。端末はPCと390px相当のスマホ画面を使い、テスト日時、入力条件、受信結果、修正担当を記録してから公開を判断します。
この記事は、フォームを新設・改修したものの、どこまで試せばよいか分からない中小企業の担当者や、開業前にホームページを準備している人に向けたものです。送信完了画面が表示されても、メールが正しい宛先へ届いたとは限りません。訪問者側、送信処理、社内受付の三つを切り分けて確認すると、送信漏れと使いにくさの両方を見つけやすくなります。
問い合わせフォームの公開前テストは3つの経路で確認する
公開前テストでは、訪問者が入力を始めてから社内担当者が内容を確認できるまでを、一つの受入テストとして扱います。受入テストとは、実際の利用を想定し、公開してよい状態かを利用者側の視点で確かめる作業です。
確認経路は「訪問者側」「送信処理」「社内受付」の三つです。どれか一つだけを見ても、問い合わせが最後まで届くかは判断できません。
訪問者側で確かめること
訪問者側では、項目名、必須表示、入力説明、入力しやすさ、エラー表示、送信ボタンまでを確認します。社内では意味が通じる項目名でも、初めて訪れる人には「何を書けばよいか」「どの形式で入力すればよいか」が伝わらないことがあります。
W3CのForms Tutorialでは、各入力欄を識別できるラベル、入力方法の説明、入力内容の検証、成功やエラーの通知などが、フォームを利用しやすくする要素として整理されています。処理に不要な情報まで求めず、短く簡潔なフォームにする考え方も示されています。[1]
送信処理で確かめること
送信処理では、入力した内容が送信され、完了画面が表示され、自動返信と社内通知が生成される流れを確認します。画面上では成功しているように見えても、メール生成や宛先設定の段階で問題が起きる場合があるため、画面とメールを別項目として判定します。
テスト用の入力には、実在する顧客の個人情報を使わず、社内で確認できる氏名表記、メールアドレス、電話番号、問い合わせ文を用意します。問い合わせ文の先頭へ「公開前テスト」と入れ、送信時刻も控えておくと、通常の問い合わせと区別して照合できます。
社内受付で確かめること
社内受付では、通知が設定したメールアドレスへ届くか、担当者が内容を読めるか、返信に使うアドレスが正しいかを確認します。共有メールアドレスで受ける場合は、実際に対応する担当者がその受信箱を閲覧できることまで試してください。
フォームの制作担当者が「送信できた」と判断し、受付担当者が「届いていない」と気づくまで間が空くと、公開後の問い合わせを見落としかねません。送信操作をする人と受信を確認する人を分けられる場合は、同じテスト番号や送信時刻を共有し、一件ずつ照合します。
入力画面とエラー表示を確認する
入力画面は、正しい情報を入れたときだけでなく、未入力や形式違いの状態でも確認します。正常入力だけでは、必須設定の漏れや、エラー文の分かりにくさを見つけられません。
項目ごとに、画面へ表示される名称と実際に求める情報が一致しているかを見ます。「お名前」と表示しながら会社名まで求めていないか、「電話番号」とだけ書いて入力例がなく、ハイフンの可否が分からない状態になっていないか、といった点を確認します。任意項目は空欄のままでも送信できるか、必須項目には画面上で必須だと分かる表示があるかも対象です。
エラー送信では、フォームに存在する項目に合わせて次の条件を試します。
- 必須項目を一つ空欄にする
- メールアドレスへ形式の異なる文字列を入れる
- 確認用メールアドレス欄がある場合は、二つの内容を一致させない
- 入力文字数や選択数に制限がある場合は、その範囲を外す
- 同意チェックが必須の場合は、未選択のまま送信する
W3CのValidating Inputでは、必須項目をラベルで明確に示すこと、メールアドレスなど一般的な入力形式を検証すること、誤りを利用者へ通知することが解説されています。電話番号など複数の表記が想定される情報については、入力形式を過度に限定しない考え方も示されています。[2]
エラーが出たかどうかだけでなく、利用者が修正箇所を迷わず見つけられるかを見ます。エラー文がページ上部にしかなく該当欄が分からない、入力した内容がすべて消える、何が不正なのか説明されない、といった状態は修正候補です。
正常条件は「エラーを出すこと」ではありません。どの項目を、どのように直せば送信できるかが分かり、修正後に入力内容を保ったまま再送信できるところまで確認します。複数のエラーを同時に出した場合も、未修正の項目が残っていることを把握できるか試してください。
送信完了とメール受信を分けて確認する
送信ボタンを押した後は、完了画面、自動返信、社内通知の三つを別々に記録します。一つが正常でも、残り二つが正常とは限らないためです。
完了画面では、送信が完了したことが明確に分かるか、利用者が同じ内容を何度も送ってしまうような表示になっていないかを確認します。完了後に案内する連絡方法や返信目安を掲載している場合は、現在の社内運用と一致しているかも見直します。
自動返信は、フォームに入力したテスト用メールアドレスで受信します。宛名、送信元名、件名、問い合わせ内容の控え、連絡先など、設定している項目が正しく差し込まれているかを確認してください。文字化け、改行崩れ、古い社名や連絡先が残っていないかも目視します。受信確認後に文面まで整えたい場合は、自動返信メールに入れる内容と書き方も確認できます。
社内通知は、実際に問い合わせ対応へ使う受信箱で確認します。宛先が現担当者または共有アドレスになっているか、件名だけでフォーム経由だと分かるか、入力内容が欠けずに届くかを見ます。通知メールからそのまま返信する運用なら、返信先が訪問者のメールアドレスになるかもテスト対象です。
自動返信と社内通知が見つからないときは、受信箱の検索だけで済ませず、迷惑メールフォルダや振り分けルールも確認します。迷惑メールへ入っていた場合は「届いたから合格」とせず、日常業務で担当者が気づける受信経路かどうかで判断します。送信時刻、受信時刻、受信先を控えると、どこで止まったかを制作担当者へ伝えやすくなります。
PCとスマホで同じテストを行う
PCで正常に送信できても、スマホでは入力欄やボタンが画面からはみ出すことがあります。端末ごとに別の内容を試すのではなく、同じ入力条件とエラー条件を使い、結果を比較してください。
PCでは通常利用しているブラウザでフォームを開き、画面幅を広げた状態だけでなく、ウィンドウを狭めた状態でも表示を確認します。スマホは実機での確認が望ましいものの、準備できない場合はブラウザの表示確認機能などで390px相当の横幅を基準にします。その後、公開前に少なくとも一度は実機で送信操作まで行うと、画面上のキーボードやタップ操作も確認できます。
スマホでは、次のような操作上の問題がないかが確認点です。
- 項目名、入力欄、補足文が途中で切れていない
- 選択肢や同意欄を指で押しやすい
- 送信ボタンが他の要素と重ならず、画面内で見つけられる
- メールアドレスや電話番号を入力しやすい
- エラー文が表示されたとき、該当項目まで戻れる
- 画面を横へ動かさなくても入力と送信を完了できる
HTMLの入力形式に応じて、スマホでは日付選択や画面上のキーボードなどの入力補助が表示される場合があります。W3Cの資料でも、メールアドレス、日付、数値などに対応する入力形式と、端末側の入力補助が解説されています。[2]
スマホ表示の合否は、見た目がPCと同じかではなく、利用者が迷わず入力、修正、送信できるかで決めます。装飾の差があっても操作に支障がなければ公開を止める理由にはなりません。一方、必須項目が見えない、ボタンが押せない、エラー後に先へ進めない状態は、公開前に直す対象です。
テスト結果を記録して公開の合否を決める
テストは、実施した事実だけでなく、条件と結果を残して初めて公開判断に使えます。担当者の記憶だけに頼ると、修正後の再確認が抜けたり、「誰かが受信を見たはず」という状態になったりします。
テスト開始前に、送信する人、受信を確認する人、修正する人、公開を決める人を決めます。少人数の会社では同じ人が複数を兼ねても構いませんが、記録上は役割を分けてください。IPAの「中小企業の情報セキュリティ対策ガイドライン」は、個人事業主や小規模事業者を含む中小企業を対象とし、経営者が認識・実施する指針と、社内で対策を進める手順や手法をまとめています。フォームのテスト表も、担当と判断を曖昧にしない社内手順として扱うと運用しやすくなります。[3]
| 確認対象 | 正常条件 | 異常時の判断 | 担当 |
|---|---|---|---|
| 入力画面 | 項目名・必須表示・説明が一致する | 入力条件を推測しないと進めない場合は修正 | 画面確認担当 |
| エラー表示 | 該当箇所と直し方が分かる | 不正な内容を送れる、または修正箇所が分からない場合は公開停止 | 制作・修正担当 |
| 送信完了 | 1回の操作で完了が明示される | 完了しない、二重送信を招く場合は公開停止 | 送信担当 |
| 自動返信 | テスト用アドレスへ正しい文面が届く | 未着、差し込み誤り、古い情報があれば修正 | 送信担当 |
| 担当者受信 | 運用する受信箱へ内容が欠けずに届く | 未着、誤送信、内容欠落があれば公開停止 | 受付担当 |
| スマホ操作 | 390px相当で入力・修正・送信できる | 押せない、読めない、先へ進めない場合は公開停止 | 端末確認担当 |
この表では、未確認を正常扱いにせず、各行の担当者が結果を記入してから合否を決めます。「公開停止」は公開前に修正と再テストが必要な状態です。
実施時は、次の順で一つずつ確認します。
- 公開予定のフォームURL、テスト日時、使用端末、ブラウザを記録した
- 正常な入力内容で送信し、完了画面まで進んだ
- 必須項目の未入力やメール形式違いでエラーを出した
- エラー箇所と直し方が分かり、修正後に送信できた
- 自動返信をテスト用メールアドレスで受信した
- 担当者通知を実運用の受信箱で確認した
- 迷惑メールフォルダと振り分けルールも確認した
- PCで正常送信とエラー送信を行った
- 390px相当のスマホ画面で同じ条件を試した
- 不具合ごとに修正担当と再テスト日を記録した
- 公開を止める不具合が残っていないことを確認した
正常送信できない、入力エラーを無視して送れる、担当者通知が届かない、別の宛先へ届く、スマホで送信ボタンを押せない状態は、公開を止める不具合として扱います。文言の微調整など公開後でも対応できる項目とは分け、公開前に直す範囲を社内で合意してください。
修正後は、不具合があった箇所だけでなく、その箇所を含む一連の経路を再度試します。たとえば社内通知の宛先を直した場合も、入力から完了画面、自動返信、担当者受信まで通して確認します。修正によって別の設定へ影響が出ていないかを同じ条件で確かめるためです。
公開後もフォームテストを運用へ組み込む
公開前に合格したフォームも、その後の変更や受信環境の更新で状態が変わることがあります。公開直後、フォーム変更後、定期点検の三つを再テストのタイミングとして社内予定へ入れ、結果を同じ記録先へ残します。
公開直後は、本番URLから一件送信し、公開前と同じ受信箱へ届くところまで確認します。テスト用の画面と公開画面でURLや設定が異なる場合があるため、公開作業の完了確認として行います。
項目の追加、通知先の変更、自動返信文の修正、フォームを置くページの改修をした後も、変更箇所だけを眺めて終わらせません。正常送信、エラー表示、自動返信、担当者受信、スマホ操作を一続きで再確認します。
変更がなくても、月次点検など社内で続けられる頻度を決めてテスト送信します。点検日、送信条件、受信結果、確認者を残し、担当交代時にも記録先を引き継いでください。実際の問い合わせだけを確認機会にすると、問い合わせが来ない期間は不具合を発見できないため、定期的な点検日を設けます。
公開後に「送信できない」「自動返信は来るが社内へ届かない」といった問題が見つかった場合は、公開後に送れない・届かない問題が起きた場合の切り分け方で、障害が起きている箇所を順に確認できます。
公開判断のために行う最初の一歩は、公開予定のフォームURLを開き、この記事のチェックリストに沿って正常送信を一回行うことです。その送信を起点に、エラー表示、自動返信、担当者受信、スマホ操作まで確認し、未確認項目と修正担当を残してください。
参考資料
- 「Forms Tutorial」World Wide Web Consortium（W3C）Web Accessibility Initiative、2026年3月27日更新（2014年9月初版公開）。原文を見る
- 「Validating Input」World Wide Web Consortium（W3C）Web Accessibility Initiative、2019年7月27日更新。原文を見る
- 「中小企業の情報セキュリティ対策ガイドライン」独立行政法人情報処理推進機構（IPA）セキュリティセンター、2016年11月15日公開、2026年7月3日最終更新（第4.0版は2026年3月27日公開）。原文を見る
