Webフォームの実装において、エンジニアが神経を使う処理の一つが「バリデーション（入力値検証）」ではないでしょうか。正規表現を駆使し、XSS（クロスサイトスクリプティング）を防ぎ、データベースの整合性を守る――これはシステムを守るための堅牢な盾です。
しかし、視点を「ユーザー体験（UX）」に移したとき、バリデーションエラーは盾ではなく、ユーザーをゴールへ導く「案内」でなければなりません。
今回は、システム的な正しさとユーザーの使いやすさを両立させるための、バリデーションエラーの「伝える技術」について、特に「ユーザーを責めないメッセージング」に焦点を当てて解説します。
エラーメッセージの役割とは？
開発者にとってのエラーは「無効なデータ」の検出ですが、ユーザーにとってのエラーは「対話の拒絶」に映ります。
一生懸命に入力したフォームで、送信ボタンを押した瞬間に真っ赤な文字で「入力内容に誤りがあります」と表示される体験は、試験の解答用紙を埋め、提出した瞬間に、「名前が枠からはみ出ているので受け取りません」と無慈悲に告げられるようなものです。
優れたUIにおけるエラーメッセージの役割は、「誤りの指摘」ではなく「解決策の提示」です。
1. 伝える「タイミング」
メッセージの内容に入る前に、それを「いつ」伝えるかというUIの挙動について整理します。適切なタイミングは、ユーザーのストレスを大幅に軽減します。
入力完了時が基本
最もバランスが良いのは、ユーザーがそのフィールドの入力を終えて次の項目へ移動した（フォーカスが外れた）タイミングです。
入力中にリアルタイムで「メールアドレスの形式が不正です」と出し続けるのは避けましょう。まだ入力途中なのに「間違っている」と判定されるのは、ユーザーにとって過干渉であり、ストレスになります。
即時反映をが有効な例外
パスワードの強度チェックや、ユーザー名の重複確認など、「入力し終わってからダメだと言われるとダメージが大きい項目」については、入力中のリアルタイム判定が有効です。また、「全角カナのみ」のように制約が厳しい場合も、入力中にフィードバックを返すのが有効な場合があります。
送信時は最終手段
検証を送信ボタン押下時に行うのは、サーバーサイドでの整合性チェックなど、クライアント側で判定できないものに限定しましょう。例えば、長いフォームを入力し終えた後に最初の方のミスを指摘されるのは、離脱率を高める要因になります。
2. ユーザーを責めない「ライティング」
ここからが本題です。エラーメッセージの文言一つで、システムの人格が決まります。大切なのは「ユーザーは悪くない、システムの説明不足である」というスタンスを取ることです。
原則1：曖昧さを排除し、解決策を提示する
つい書いてしまいがちなのが、事実だけを告げるメッセージです。
- × 悪い例：
無効な入力です - × 悪い例：
エラーが発生しました (Code: 400)
これらは「何が」間違っていて、「どうすれば」直るのかが分かりません。ユーザーを迷子にさせないためには、具体的なアクションを提示します。
- 〇 良い例：
＠を含めたメールアドレスの形式で入力してください - 〇 良い例：
パスワードは8文字以上必要です
「不正な文字が含まれています」ではなく、「半角英数字で入力してください」と「やるべきこと」を書きましょう。
原則2：否定形を避け、肯定的な表現を使う
「禁止」「不正」「不可」といった強い否定語は、ユーザーに「怒られている」ような印象を与えます。これらはシステム視点の言葉です。
- × 悪い例：
半角数字以外は入力禁止です - × 悪い例：
そのユーザー名は使用できません
これを、ガイドするような肯定的な表現に書き換えます。
- 〇 良い例：
半角数字で入力してください - 〇 良い例：
このユーザー名はすでに使われています。別の名前を入力してください
「〜しないでください」ではなく、「〜してください」とポジティブな指示に変換することで、対話の質が変わります。
原則3：システム都合の専門用語を使わない
データベースのカラム名や、バリデーションライブラリのデフォルトメッセージがそのまま表示されていませんか？
- × 悪い例：
String型で入力してください - × 悪い例：
このフィールドは必須です
ユーザーの言葉に翻訳しましょう。
- 〇 良い例：
数字ではなく文字で入力してください - 〇 良い例：
お名前を入力してください
原則4：ユーザーの努力を無にしない
最も避けるべきは、システムエラーなどで入力内容がすべて消えてしまうことです。バリデーションエラーが発生した際は、入力された値を保持することが大前提です。
また、「全角で入力された数字をシステム側で半角に変換する」など、エラーとしてはじく前にシステム側で吸収できる揺らぎはないかを検討するのも、重要な「優しさ」です。
3. 視覚的な「伝える技術」
最後に、メッセージの見た目についてです。
色だけに頼らない
「赤文字＝エラー」は定石ですが、色覚多様性を持つユーザーには、赤色が警告として認識しづらい場合があります。 色だけでなく、アイコン（！や×マーク）を併用する、あるいは太字にするなど、形状の変化でも状態を伝えるようにしましょう。（アクセシビリティの確保）
入力欄との近接性
エラーメッセージをフォームの一番上にまとめて表示するパターンがありますが、項目数が多い場合、どの項目がエラーなのかを探す手間が発生します。 エラーメッセージは、**該当する入力フィールドの直下（または直近）**に表示し、色を変えた枠線などで関連付けを明確にします。
まとめ：エラー表示にこそ、性格が出る
正常系のルートは、誰が設計しても似た画面になります。しかし、異常系・準正常系であるエラー表示には、作り手の配慮やサービスの質が色濃く反映されます。
バリデーションエラーは、ユーザーがゴールにたどり着くための最後のハードルです。 「間違っています」と冷たく突き放すのではなく、「こうすればうまくいきますよ」と寄り添う。そんな「ユーザーを責めないUI」を、ぜひ意識してみてください。
同じ趣旨の記事、「エラーダイアログの「説明責任」：ユーザーを救う3つの要素」もご覧ください。
