FIXER Tech Blog - Development

FIXER cloud.config Tech Blog

Webアプリを使いやすく！ 「入力チェック（バリデーション）」の正しい考え方

　本記事はFIXERが提供する「cloud.config Tech Blog」に掲載された「入力チェック（バリデーション）の考え方と設計と実装 - 考え方編」を再編集したものです。

はじめに

　この記事では、Webアプリケーションにおける入力チェック（バリデーション）を実装するにあたって勉強になったことをまとめました。

　Web開発において、ユーザーフレンドリーなバリデーション実装は重要な要素ですが、実際のプロジェクトでは時間や優先順位の関係で、細部への配慮が後回しになることがあります。

　適切なバリデーション設計はユーザー体験を大きく向上させるだけでなく、開発・保守の効率化にも繋がります。

　この記事を通して、より良いバリデーション実装のためのヒントを提供できれば幸いです。

バリデーションの基本的な考え方

■そもそもバリデーションって？

　入力チェック/バリデーション(Validation)とは、ユーザーが入力したデータが正しい形式や条件を満たしているかを確認する処理のことです。

　私たちの日常生活でも頻繁に利用されており、例えば、新しいアプリをインストールした際のアカウント登録画面で、「パスワードは8文字以上必要です」や「メールアドレスの形式が正しくありません」といったメッセージが表示されることがあります。

　下の画像のようなフォームでの入力チェックが典型的な例です。

■フロントエンドでのバリデーションの役割

　私は、フロントエンドでのバリデーションは以下の役割を担っていると考えています。

ユーザビリティの向上

　ユーザーが入力フォームに情報を入力する際、文字数が足りない場合や形式が間違っている場合など、即座にエラーメッセージを表示することで、ユーザーは迅速に正しい入力へ修正できます。

　これにより入力作業の効率が高まり、フォーム完了までの時間短縮にもつながります。

サーバーの負荷軽減

　明らかに不正な形式のデータ（生年月日のフィールドに電話番号を入力している等）や必須項目が未入力のデータをサーバーに送信すると、不要な通信（トラフィック）が発生します。

　フロントエンドでのバリデーションを実装することで、こうした無駄な通信を事前に防ぎ、サーバーリソースを効率的に使用できるようになります。

　特にユーザー数の多いサービスでは、この効果が積み重なり大きな負荷軽減につながります。

基本的なセキュリティ対策

　フロントエンドによるバリデーションは、意図しない攻撃からサーバーを保護する最初の防衛線として機能します。大量の無効なリクエストや過剰に大きなデータの送信といった単純な攻撃に対して、ある程度の抑止効果が期待できます。

　ただし、ブラウザの開発者ツールやHTTPリクエスト操作ツールを使用すれば、フロントエンドのバリデーションは比較的容易に回避できることを認識しておく必要があります。

　そのため、重要なビジネスロジックやセキュリティに関わるチェックは、必ずサーバーサイドでも実装することが不可欠です。

　フロントエンドのバリデーションはあくまで補助的な役割と捉え、多層防御の一部として位置づけるべきでしょう。

実装における注意ポイント

　この記事の冒頭で示したログインフォームのバリデーション例（下図参照）は、一見すると機能的に問題ないように見えるかもしれません。

　しかし、ユーザー体験の観点から見ると、このような実装にはいくつかの改善点があります。

　単にエラーメッセージを表示するだけでは、ユーザーに十分な情報や適切なガイダンスを提供できていない可能性があるのです。

　以下では、バリデーション実装において注意すべき重要なポイントを詳しく説明していきます。

　これらのポイントを押さえることで、ユーザーにとってより分かりやすく、ストレスの少ない入力フォームを実現できるでしょう。

■入力例を「常に」表示しよう

　バリデーションエラーを未然に防ぐためには、適切な入力ガイダンスを事前に提供することが重要です。

　ここでは、最も一般的な入力コンポーネントであるテキストフィールドを例に説明します。

　Googleが提唱するマテリアルデザインによると、テキストフィールドを構成するテキスト要素は以下のように定義されています。

Text fields – Material Design 3

　では、これらの要素のうち、入力例を記載するのに最適な場所はどこでしょうか？

　私は、標準で用意されているこれらの要素は入力例を表示する場所としては適切ではないと考えています。

ラベル

　ラベルは入力項目を識別するための基本要素であり、スクリーンリーダーによって読み上げられる重要な情報です。

　この要素は簡潔かつ明確であるべきです。

　ラベルに入力例を記載してしまうと、以下のような問題が生じると考えられます。

・フォーム全体の視認性が低下し、どの項目が何を求めているのかが一目で把握しづらくなります
・スクリーンリーダーの読み上げが冗長になり、必要な情報を聞き取りにくくなります
・ラベルが長くなりすぎるとレイアウト（特にモバイル画面）が崩れる可能性があります

プレースホルダ

　プレースホルダは入力欄に薄く表示されるテキストで、あくまでも入力欄の目的や入力内容の種類を補足的に示すためのものです。

　本来、入力例や詳細な入力規則を示すための要素ではありません。

　プレースホルダに入力例を記載してしまうと、以下のような問題が生じると考えられます。

・ユーザーが入力を始めると即座に消えてしまうため、入力途中で例を再確認することができません
・プレースホルダは通常、薄い色で表示されるため、視覚的に認識しづらい場合があります
・スクリーンリーダーによってプレースホルダが適切に扱われない場合があります

サポートテキスト

　サポートテキストは入力フィールドの下部に配置され、入力に関する追加情報を提供するための要素です。

　一見すると、入力例を記載するのに適しているように思えます。

　サポートテキストに入力例を記載してしまうと、以下のような問題が生じると考えられます。

・エリアのしたに先に確認すべき入力例が書かれているので視線動線が不自然です
・多くのUIフレームワークやデザインシステムでは、サポートテキストにはエラーメッセージを表示します
・エラーが発生した場合、記載していた入力例や入力規則は、エラーメッセージに置き換えられてしまいます
・つまり、ユーザーが最も入力例を必要とする「エラーが発生した時」に限って、入力例が表示されません

ではどこに配置すべきか

　これまでの標準的な要素には課題があることを踏まえ、私がおすすめするのは、ラベルの真下に独立した要素として入力例を配置する方法です。

　この配置には、以下のようなメリットがあります。

　上から「項目名（何を入力するか）」→「入力例（どのように入力するか）」→「実際の入力欄」という自然な視線の流れに沿っています。

　また、入力中やエラー発生時も常に表示され続けるため、ユーザーはいつでも入力例を参照できます。

　ほかにも、アクセシビリティの観点からも優れています。

　スクリーンリーダーを使用するユーザーは、ラベルと入力例を別々の要素として認識できるため、必要に応じて入力例の読み上げをスキップしたり、聞き直したりすることができます。

　この方法は標準的なコンポーネント構成からは少し外れますが、ユーザビリティとアクセシビリティの両面で大きなメリットをもたらします。

　多少の実装コストはかかるものの、ユーザー体験の向上という点で十分に価値のある改善と言えるでしょう。

■チェックのタイミングを調節しよう

　バリデーションを実装する際、検討すべき重要な要素の一つが「チェックのタイミング」です。

　すべての入力規則を同じタイミングでチェックするのではなく、各ルールの性質に適したタイミングでチェックを実行することで、ユーザー体験を大幅に向上させることができます。

　適切なタイミングでフィードバックを提供することは、ユーザーのフラストレーションを減らし、スムーズなフォーム入力を促進します。

　バリデーションのタイミングには主に以下の3つがあり、それぞれに適した使い分けが重要です。

　おもなチェックのタイミングには、「入力中（リアルタイム）」、「フォーカスが外れた時（ブラー）」、「フォームを送る時（サブミット）」の３つがあります。

　これらを適切に組み合わせることで、より直感的で使いやすいフォームを実現できるでしょう。

リアルタイム

　ユーザーが文字を入力するたびに即座にフィードバックを提供します。

　このリアルタイムバリデーションは、ユーザーにとって有益な即時フィードバックを提供できる一方で、過剰に使用するとユーザー体験を損なう可能性があります。

ブラー

　ユーザーが次の項目に移動した（フォーカスが外れた）時点でフィードバックを提供します。

　ブラーバリデーションは入力中は邪魔せず、入力完了後すぐにフィードバックを提供するため、ユーザーは自然なリズムで内容の修正を行うことができ、フラストレーションが減少します。

サブミット

　ユーザーが送信ボタンをクリックした時点で最終的なフィードバックを提供します。

　サブミットバリデーションはユーザーがすべての入力を完了した後、複数の項目間の関連性・整合性を考慮したフィードバックを提供します。

■入力規則を表示しよう

　入力規則（バリデーションルール）はユーザーが正しく入力するために必要な情報です。

　入力規則を事前に表示することで、ユーザーの入力ミスを減らし、スムーズな操作を実現できます。

　多くの場合、入力規則はエラーが発生した後にのみ表示されますが、事前に表示しておくことでユーザーは最初から何が求められているかを理解できます。

　これにより、エラーメッセージを見てから修正するという手間が省け、フォーム入力をよりスムーズに完了できるようになります。

表示場所

　入力規則は、基本的にラベルと入力例の間に配置することが望ましいです。

　この位置に配置することで、ユーザーの視線動線にそって入力操作を補助することができます。

表現内容

　入力規則を表示する際は、表現方法にも注意を払うことが大切です。

　効果的な入力規則は内容だけでなく、伝え方にも工夫が必要です。

　入力規則では、否定的な表現を避け、できるだけ肯定的な表現を使用することをおすすめします。

　例えば「〜してはいけません」という禁止事項の列挙ではなく、「〜を含めてください」という推奨事項として伝えると、ユーザーは何をすべきかを明確に理解できます。

　肯定的な表現は心理的にも受け入れやすく、ユーザーの行動を自然に導きます。

　また、技術的な用語は可能な限り使用せず、一般のユーザーにもわかりやすい表現で説明することが重要です。

　特に、システム内部の用語や開発者にとっては当たり前の言葉でも、一般ユーザーには理解困難なことがあります。

　わかりやすく肯定的な表現を用いることで、ユーザーはフォーム入力に対する不安を減らし、自信を持って操作を進めることができるようになります。

■入力規則の表示とバリデーション処理を統合しよう

　フォーム入力において、入力規則の表示とバリデーション処理は密接に関連していますが、多くの実装ではこれらが別々に管理されています。

　例えば、HTMLでは入力規則を説明するテキストを記述し、JavaScriptでバリデーション処理を実装するといった具合です。

　基本的に一つのフィールドに対して、複数の入力規則が指定されている場合、その数に応じたエラー表示が用意されているはずです。

　パスワード入力を例にすると、「8文字以上必要です」「大文字を含めてください」「数字を含めてください」といった複数の条件があります。

　これらの入力規則とバリデーション処理を統合することで、コードの保守性向上や動的なフィードバックを実現できます。

　入力規則が多い場合や、画面スペースが限られている場合は、ツールチップやアコーディオンといった UI パターンを活用するとよいでしょう。

　これらの手法を使うことで、画面の煩雑さを抑えながらも、必要な情報にアクセスしやすい環境を提供できます。

　例えば、フォーカス時やホバー時など、ユーザーが実際に入力しようとしている時にのみ詳細な入力規則を表示する方法が効果的です。

　通常時はサポートテキスト領域に最も重要なエラーメッセージのみを表示し、入力時に表示されるツールチップ内に収めるといった工夫ができます。

　モバイル画面では特に限られたスペースを有効活用する必要があるため、アコーディオン形式で入力規則を折りたたんでおき、タップで展開できるようにするなどの対応も検討に値します。

　このようなアプローチは、画面の視認性を保ちながらも、ユーザーが必要とする情報に適切にアクセスできるバランスを実現します。

　ただし、あまりに情報へのアクセスが複雑になりすぎないよう、操作性にも配慮することが大切です。

おわりに

　バリデーションは単なる入力チェックの機能にとどまらず、ユーザー体験の質を左右する重要な要素です。

　適切なタイミングでの明確なフィードバック、常に参照できる入力例や入力規則の提示、そして統合された管理方法は、ユーザーの混乱やフラストレーションを軽減し、スムーズなフォーム入力体験を実現します。

　この記事が皆様の実装に少しでも役に立てば幸いです。

　次の記事ではこれらの考えをもとにバリデーション機能の設計を行ってきます。

第一回：入力チェック（バリデーション）の考え方と設計と実装 - 考え方編
第二回：入力チェック（バリデーション）の考え方と設計と実装 - 設計編
第三回：入力チェック（バリデーション）の考え方と設計と実装 - 実装編

江藤皓史／FIXER
有明高専卒24入社
チョコミント/TRPG/まーちゃんごめんね

■関連サイト

• cloud.config Tech Blogのエントリー
• cloud.config Tech Blog
• FIXER