098. Server-side Validation（サーバーでの厳格検証：真実を知る者による、最後の審判）

原理：逃げ隠れできない「最終防衛線」

ブラウザ（フロント）のチェックは「優しさ」、サーバー（バック）のチェックは「責任」

ブラウザでの検証（096. 097.）をどれだけ完璧にしても、それだけでは不十分です。 - ユーザーがわざとブラウザのチェックを無効にするかもしれない。 - 「その名前が既に使われているか」は、データベースを持っているサーバーにしか分からない。 - 通信経路の途中でデータが書き換えられるかもしれない。

「サーバーサイド（サーバー側）バリデーション」は、「届いたデータが本当に正しいか、データベースや複雑な計算と照らし合わせて最終確認すること」です。

HTMXの真骨頂は、この「サーバーでの厳しいチェック結果」を、ページ全体をリロードすることなく、エラーが起きた場所だけにピンポイントで表示できる点にあります。

実践：エラーメッセージを「現地」に届ける

1. エラー付きのフォームをそのまま返す

サーバー側でエラーが見つかったとき、サーバーは「エラーメッセージを含んだ、その入力箇所のHTML」を返します。

<!-- 送信前の状態 -->
<div id="username-area">
    <input type="text" name="username" hx-post="/check-user" hx-target="#username-area">
</div>

<!-- (サーバーがエラー時に返すHTML) -->
<div id="username-area" class="error">
    <input type="text" name="username" value="既にある名前">
    <span class="error-msg">この名前はすでに誰かが使っています！</span>
</div>

2. ステータスコード「422 Unprocessable Entity」

HTMXでバリデーションエラーを返すとき、サーバー側では「422（処理できないデータだよ）」という特別な番号（ステータスコード）を返すのが一般的です。これにより、ブラウザ（HTMX）側で「あ、これは失敗したんだな」と正しく判断できます。

3. ステップ・バイ・ステップ解説

サーバーでチェック: PHPやPython、Goなどのプログラムで届いたデータを精査します。
エラー部分を作成: エラーメッセージを添えた、その入力部品（パーツ）だけのHTMLを生成します。
レスポンス送信: ステータスコード 422（または 200 OK）と共に、そのHTMLを返します。hx-target により、画面のエラー箇所だけがパッと書き換わります。

比較：通常のページ遷移 vs HTMXのエラー表示

通常のフォーム送信

挙動: 送信→ページ全体がリロード→エラーが表示される。
不便: 入力していた他の項目が消えてしまったり、スクロール位置が戻ったりして不快。

HTMXのエラー表示

挙動: 送信→エラーのある入力欄だけが書き換わる。
快適: 他の項目には一切影響せず、ユーザーはそこだけを直せばいい。

まとめ：初心者のための「誠実な」エラー対応

サーバーサイド・バリデーションは、あなたのアプリの「正しさ」を守る盾です。

見た目はフロント、中身はバック: 「3文字以上」といった簡単なチェックはブラウザで。「重複チェック」などの本気のチェックはサーバーで。この役割分担がプロの仕事です。
ステータスコードの使い分け: 第3章の知識を思い出してください。成功（200）だけでなく、エラー（400番台）を正しく使い分けることで、HTMXはより賢く振る舞ってくれます。
エラー時こそ「親切」に: 「不正な入力です」だけでなく、「何をどう直せばいいのか」をサーバーからのHTMLに込めて返してあげましょう。

最後の審判を、最高のユーザー体験へ。サーバーサイド・バリデーションを磨き上げることで、どんな不正なデータも寄せ付けない、堅牢で信頼されるWebアプリを築いてください。次の記事では、想定外のトラブルに備える「エラーハンドリング（099. Error Handling）」をご紹介します。