フォームと入力の検証 — 画面の検証は親切、サーバーの検証は守り

What — 2 つの検証は、役割が違う

フォームの検証には、画面（ブラウザ）での検証と、サーバーでの検証があります。似たことを確かめますが、目的が違います。

画面の検証は、利用者の手元で動くので、利用者が止められます。開発者ツールで送信の中身を書き換える、API を直接呼ぶ。どちらも画面の検証を通りません。だから、データを守るのはサーバーの検証だけです。

そして、満席かどうか、同じメールで申し込み済みかどうかは、DB を見ないと分かりません。画面では確かめようがない検証もあります。

押す → 送る
（反応が遅い）
もう一度押す → もう一度送る
→ 申し込み 2 件

満席で失敗 → 画面を作り直す
→ 入力が全部消える

エラーの見せ方

サーバーがエラーを返したとき、利用者が次に何をすればよいかが分かる形で見せます。

• 入力を消さない。長い備考を書き直させない
• どの欄の問題かを、その欄のすぐ近くに出す。ページの上に「エラーがあります」とだけ出しても、長いフォームでは見つからない
• 最初のエラーの欄に、カーソルを移す。画面を読み上げる道具を使う人にも、エラーがあったことが伝わる
• 満席のように欄に紐づかないエラーは、フォームの上にはっきり出し、次の行動（キャンセル待ち・別の日程）を示す

エラー設計の記事で見たとおり、サーバーはどの欄の、どんな問題かを機械が読める形で返します。画面はそれを欄に振り分けて表示します。

Why — なぜ同じ検証を 2 回書くのか

同じ規則を 2 か所に書くのは、重複ではないのか

「参加人数は 1〜10」という規則を、画面とサーバーの両方に書くことになります。凝集度と結合度で見た「同じ知識を 2 か所に書かない」に反するように見えます。

実際、規則が 2 か所にあると、片方だけ変えるずれが起きます。上限を 20 に上げたのに画面だけ 10 のまま、など。これを避けるには、規則を 1 か所に書き、画面とサーバーの両方から使う形が理想です。同じ言語で書いているなら、検証の規則を共有できます。

共有できない場合は、サーバーを正にします。画面の検証がずれていても、困るのは親切さだけです。サーバーがずれると、データが壊れます。

反応が遅いと、人はもう一度押す

二重送信は、利用者の不注意ではありません。押したのに反応が無ければ、もう一度押すのが正しい行動です。原因は、押したことが伝わっていない画面の側にあります。

押した瞬間に「送信中」と表示してボタンを押せなくすると、押したことが伝わり、もう一度押す理由がなくなります。これは二重送信を減らすと同時に、体験そのものを良くします。

演習 — まず自分で判断する

解説を読む前に、まず自分で判断してみてください。ここで一度詰まっておくと、 次の節の判断軸が「なるほど」ではなく「そう来たか」に変わります。