バリデーション (validation) は、ユーザーが入力したデータやシステム間で受け渡すデータが、期待される条件を満たしているかを確認する処理です。フォームに入力されたメールアドレスが正しい形式か、パスワードが最低文字数を満たしているか、電話番号が数字だけで構成されているか - これらはすべてバリデーションの具体例です。

バリデーションは実行場所によって 2 種類に分かれます。クライアントサイドバリデーションはブラウザ上で即座にフィードバックを返し、ユーザー体験を向上させます。HTML5 の required、maxlength、pattern 属性や、JavaScript による動的チェックがこれに該当します。サーバーサイドバリデーションはサーバーで最終的な検証を行い、セキュリティを担保します。クライアントサイドのチェックは開発者ツールで簡単に回避できるため、サーバーサイドバリデーションは省略できません。

文字数に関するバリデーションは最も基本的かつ頻出するパターンです。Twitter (現 X) の 280 文字制限、SMS の 70 文字 (日本語) 制限、データベースの VARCHAR カラムの上限など、あらゆるシステムに文字数の制約があります。ここで問題になるのが「何を 1 文字と数えるか」です。絵文字の 👨‍👩‍👧‍👦 は見た目は 1 文字ですが、Unicode では 7 つのコードポイント (4 人の絵文字 + 3 つの ZWJ) で構成されます。プラットフォームによってこれを 1 文字と数えるか 7 文字と数えるかが異なるため、バリデーションの実装には文字数の定義を明確にする必要があります。

文字種のバリデーションも重要です。日本語のフォームでは「全角カタカナのみ」「半角英数字のみ」といった制約がよく見られます。正規表現で /^[\u30A0-\u30FF]+$/ (カタカナ) や /^[a-zA-Z0-9]+$/ (半角英数字) のようにチェックしますが、濁点・半濁点の結合文字や、長音記号「ー」の扱いなど、日本語特有のエッジケースに注意が必要です。

フォーマットバリデーションでは、メールアドレス、URL、日付、郵便番号などの形式を検証します。メールアドレスの正規表現は完全に RFC 5321 準拠にすると極めて複雑になるため、実務上は簡易的なパターンで検証し、最終的には確認メールの送信で到達性を検証するのが現実的です。

バリデーションエラーのメッセージ設計も品質に直結します。「入力エラーです」ではなく「パスワードは 8 文字以上で、英字と数字を含めてください」のように、何が問題で何をすれば解決するかを具体的に伝えることが重要です。エラーメッセージ自体にも文字数の制約があり (モバイル画面の表示幅、ツールチップの最大長など)、簡潔かつ明確な表現が求められます。