問い合わせフォームや資料請求フォームで「入力内容に誤りがあります」と表示されたものの、どこを直せばよいのか分からなかった経験はないでしょうか。
入力エラー自体は、どのフォームでも起こります。必須項目の見落とし、メールアドレスの入力途中、電話番号の桁数不足、添付ファイルの容量超過など、原因はさまざまです。
問題は、エラーが発生することではなく、利用者が修正方法を判断できないことです。エラー箇所が分からない、入力した内容が消える、送信ボタンを押しても反応が見えないといった状態が続けば、問い合わせを送ろうとしていた人でも画面を閉じてしまいます。
そのため、エラーメッセージは単なる警告文ではなく、入力内容を修正して送信を完了してもらうための案内として設計する必要があります。
この記事では、フォームのエラーメッセージを見直したい方に向けて、項目別の文言例、表示位置、入力チェックのタイミング、スマートフォンでの表示、入力内容の保持、システムエラーとの区別まで解説します。
後半では、文言変更だけで対応できるケースと、JavaScriptやPHP、データベース、メール送信処理まで確認した方がよいケースの違いも紹介します。
エラーメッセージには、最低限次の3つの情報が必要です。
たとえば、「メールアドレスが不正です」という文章では、何が不足しているのか分かりません。
「メールアドレスの形式が正しくありません。例：info@example.co.jp」と表示すれば、利用者は入力例を見ながら修正できます。
同じように、「必須項目です」ではなく「お問い合わせ内容を入力してください」、「文字数を超えています」ではなく「お問い合わせ内容は1,000文字以内で入力してください」とした方が、次の操作が明確になります。
既存フォームで多いのは、エラーが発生したことだけを表示し、修正場所と修正方法を利用者に探させている構成です。
UIイメージ：情報が不足している例と改善例
問題のある例
入力欄の色以外に説明がないため、修正内容を判断できません。
改善した例
問題のある項目と修正方法を、入力欄の近くで確認できます。
エラーメッセージは、すべての項目に共通する文章を使うより、入力条件に合わせて個別に用意した方が分かりやすくなります。
会社名には英字、数字、記号、法人格などが含まれる場合があります。入力可能な文字を厳しく限定すると、実在する社名を登録できないことがあるため、制限の必要性を確認します。
メールアドレスの形式が正しくても、実在するアドレスかどうかまでは画面上の入力チェックだけでは判断できません。本人確認が必要なサービスでは、確認メールや認証コードを利用します。
ハイフンを受け付ける場合は、「ハイフンの有無はどちらでも構いません」と案内できます。全角数字を自動的に半角へ変換する仕様であれば、利用者に再入力を求める必要があるかも確認します。
予約フォームでは、画面を開いた時点では空いていた時間が、送信時点で埋まる場合があります。この場合は入力ミスではなく、予約状況の変化であることを伝えます。
文字数制限がある場合は、入力前から上限を表示し、入力中にも現在の文字数を確認できるようにすると、送信時のエラーを減らせます。
ファイル添付では、形式、容量、件数、通信のどこで問題が起きたのかを分けて表示します。
「アップロードに失敗しました」だけでは、別のファイルを選ぶべきか、同じファイルでもう一度試すべきか分かりません。
エラーメッセージが具体的でも、システムの入力条件と一致していなければ利用者を迷わせます。
たとえば、ハイフン付きの電話番号を登録できるのに「数字のみで入力してください」と表示するのは不適切です。10MBまで添付できる仕様なのに「5MB以下」と書かれていれば、不要な再操作を求めることになります。
フォームを改修する際は、画面の文章だけでなく、JavaScript、PHPなどのサーバー処理、データベースの文字数制限も確認する必要があります。
これらの条件が異なると、画面上では問題がないように見えても、送信後に登録エラーが発生します。
エラーメッセージは、フォーム上部だけに表示する方法と、問題のある入力項目の近くに表示する方法があります。
どちらか一方ではなく、次のように役割を分けると確認しやすくなります。
UIイメージ：画面上部の要約と項目直下の説明
上部の項目名から、該当する入力欄へ移動できるリンクを付ける方法もあります。
長いフォームの下部にある送信ボタンを押した後、画面位置が変わらないと、上部のエラー表示に気付かれないことがあります。
送信時にエラーがあった場合は、最初のエラー項目またはエラー要約へ画面を移動させます。
固定ヘッダーがあるサイトでは、移動後に項目名がヘッダーの下へ隠れないようにします。入力欄だけでなく、項目名とエラーメッセージを同時に確認できる位置へ移動させることが重要です。
赤い枠線や背景色は、エラー箇所を見つける補助になります。ただし、色だけでは状態を正確に伝えられません。
枠線の色に加えて、項目直下の文章や警告アイコンを使用します。必須ラベルにも赤色を使っている場合は、必須表示とエラー表示の区別も必要です。
すべての項目を入力中から確認すると、まだ書き終わっていない段階で警告が表示されます。メールアドレスの最初の1文字を入力しただけで「形式が正しくありません」と出れば、操作を急かされているように感じられます。
入力欄からフォーカスが外れた時点で確認すれば、入力途中の警告を避けながら、送信前に修正できます。
ページを開いた直後から、未入力の必須項目をすべてエラー表示する必要はありません。利用者が送信または次の画面へ進もうとした時点で案内します。
UIイメージ：項目ごとに入力確認のタイミングを変える
入力途中の全項目を常時確認するのではなく、操作に応じて表示します。
入力内容を修正した後も赤い枠やエラーメッセージが残っていると、利用者はまだ送信できないと判断します。
再確認できる項目は、条件を満たした時点でエラー表示を解除します。
「入力内容を確認しました」と表示する場合も、システムが確認できた範囲に限定します。メールアドレスの形式が正しいことは確認できても、そのアドレスが実在するとは限りません。
エラーメッセージが分かりやすくても、入力済みの内容が消えてしまえば、利用者は最初から入力し直さなければなりません。
エラー後の再表示では、原則として次の内容を保持します。
パスワードや決済情報など、安全上の理由から再表示しない項目もあります。その場合は、再入力が必要であることを画面上で案内します。
ブラウザの仕様上、エラー後にファイル選択欄へ以前選んだファイルを自動設定することはできません。
添付ファイルが必要なフォームでは、エラー後に選び直してもらうか、送信前にファイルだけ一時アップロードして保持する方法があります。
一時アップロードを使用する場合は、未送信ファイルの削除期限、閲覧権限、ファイル形式、ウイルス対策も確認します。
スマートフォンでは、画面幅が狭いうえ、入力中はソフトウェアキーボードが表示されます。送信ボタンを押した後にエラーが発生しても、該当項目が画面外にあれば、何も起きていないように見えることがあります。
UIイメージ：スマートフォンで未修正項目を案内する
送信後に項目名、入力欄、エラー文が同時に見えるかを実機で確認します。
メールアドレス、電話番号、数字などは、入力内容に適したキーボードを表示すると入力ミスを減らせます。
HTMLの入力タイプやinputmodeを指定し、スマートフォンでどのキーボードが表示されるか確認します。ただし、キーボードの種類だけに入力条件を任せず、送信時にはサーバー側でも確認します。
フォームから送信できない原因は、利用者の入力だけではありません。通信の切断、メールサーバーの障害、外部サービスの停止、データベースへの登録失敗などもあります。
通信障害が発生しているのに「入力内容に誤りがあります」と表示すると、利用者は正しい内容を何度も変更することになります。
現在、通信上の問題により送信を完了できませんでした。入力内容はこの画面に保持されています。恐れ入りますが、時間を置いてもう一度お試しください。お急ぎの場合は、電話窓口までご連絡ください。
このように、次の内容を案内します。
システム内部のファイル名、サーバーのパス、SQLエラー、例外メッセージなどを画面へそのまま表示してはいけません。利用者向けの案内とは別に、運用担当者が原因を確認できるログを記録します。
画面上では送信エラーになっていても、サーバー側では問い合わせの登録が完了している場合があります。
利用者が再送信すると、同じ問い合わせ、予約、注文が複数登録される可能性があります。受付IDや処理IDを使用し、同じ内容を重複登録しない制御が必要になることがあります。
JavaScriptによる入力チェックを使えば、送信前にエラーを表示できます。ただし、ブラウザ側の確認だけでは十分ではありません。
JavaScriptが動作しない環境や、意図的に画面の確認処理を通さず送信されるケースもあるため、PHPなどのサーバー側でも入力内容を確認します。
両方の条件が異なると、画面上では問題なしと表示された後、送信処理でエラーになります。
必須項目、文字数、日付、ファイル形式などは、共通の仕様に基づいて実装します。
フォームから送信された内容を、顧客管理システム、予約システム、メール配信サービス、チャット通知などへ連携する場合があります。
フォームへの登録は成功しても、外部サービスへの連携だけが失敗することもあります。その場合に、利用者へ送信失敗と表示するのか、受付は完了として運用側で再連携するのかを決めておく必要があります。
受付結果、メール送信結果、外部連携結果を別々に記録できれば、どの処理で問題が起きたか確認できます。
見た目ではエラーが分かっても、スクリーンリーダーやキーボード操作では状態が伝わらないことがあります。
フォーム上部のエラー要約から各入力欄へ移動できるようにすると、項目数の多いフォームでも修正箇所を確認できます。
同じ項目で繰り返しエラーが発生している場合、エラーメッセージだけを変更しても改善しないことがあります。
たとえば、都道府県名の表記違いが頻繁に起きるのであれば、文章を変更するよりプルダウンへ変更した方が確実です。
郵便番号から住所を自動入力する、会社名候補を表示する、予約可能な日付だけ選択できるようにするなど、エラーが起きにくい入力方法へ変更する選択肢もあります。
次のような問題であれば、HTML、CSS、JavaScriptの比較的小規模な変更で対応できる場合があります。
ただし、既存フォームが外部サービスやCMSのプラグインで作られている場合は、変更できる範囲が限られることがあります。
設定画面だけで変更できるのか、テンプレート編集が必要なのか、プラグイン本体の更新で変更が消えないかを確認します。
次の問題は、画面上の文章だけでは解決できません。
この場合は、JavaScriptだけでなく、PHPなどの送信処理、セッション、データベース、メールサーバー、外部APIまで確認します。
UIイメージ：画面だけの問題と、送信処理を含む問題
画面側の変更で対応できる例
HTML、CSS、JavaScriptの変更で対応できる場合があります。
送信処理まで確認する例
PHP、データベース、メール、APIなどの確認が必要です。
既存フォームの改修を依頼する際は、「エラーメッセージを分かりやすくしたい」だけでなく、現在困っている状況を具体的に伝えると、調査範囲を判断しやすくなります。
再現できる操作手順や画面のスクリーンショットがあると、原因を確認しやすくなります。
「送信できない」という現象でも、ブラウザ側の入力チェック、サーバー処理、メール送信、外部APIなど、原因となる場所は複数あります。画面だけを見て結論を出さず、送信後の処理まで確認できる開発会社へ相談することが重要です。
フォームの改善を依頼する場合は、デザインや文言だけでなく、送信処理と運用まで確認できるかを見ます。
フォームは、画面、送信処理、メール、管理画面が連続して動く機能です。表示部分だけを変更すると、既存の受付処理へ影響することもあります。
改修前に現在の処理を確認し、変更する範囲と変更しない範囲を明確にしてから作業を進める会社を選ぶと安心です。
予約、問い合わせ、申込フォームを含むWebシステムの例については、 医療向けシステム開発例や 学校向けシステム開発例でも紹介しています。
フォームのエラーメッセージは、入力ミスを知らせるだけの文章ではありません。利用者が問題のある項目を見つけ、修正し、送信を完了するための案内です。
文言には、問題のある項目、送信できない理由、修正方法を具体的に記載します。表示位置はフォーム上部の要約と入力項目直下の説明を併用し、送信後には最初のエラー箇所を画面内に表示します。
エラー後も入力内容を保持し、スマートフォンでも項目名とエラー文を確認できるようにします。通信やサーバーの問題は入力エラーと分け、入力内容が保持されているか、再試行できるか、代替の連絡方法があるかを案内します。
また、既存フォームの問題は、文章やCSSの変更だけで解決できるとは限りません。入力内容が消える、二重登録が発生する、メールが届かないといった場合は、JavaScript、PHP、データベース、メール送信、外部サービスとの連携まで確認する必要があります。
現在のフォームで「どこまで直せばよいのか分からない」という場合は、表面のエラーメッセージだけでなく、送信から受付完了までの処理を確認できる開発会社へ相談してください。既存の仕組みを確認したうえで必要な変更範囲を判断すれば、現在の機能を維持しながら、利用者にも運用担当者にも分かりやすいフォームへ改善できます。