Next.js のフォーム実装、もう 「事故」 らせない。 Server Actions × Zod で築く鉄壁の設計

バグに怯える夜にサヨナラを

「お問い合わせフォームを作ってください」

クライアントからそう言われたとき、あなたはどう感じますか？
「はい、簡単です！」と即答できるでしょうか。
それとも、一瞬だけ心の奥に重たい石が落ちるような感覚があるでしょうか。

かつての僕は、後者でした。

見た目はただの入力欄とボタン。
けれど、その裏側には無数の「落とし穴」が潜んでいることを知っているからです。
必須項目の抜け漏れ、不正なメールアドレス、サーバーエラー時の挙動、二重送信、そしてローディング中の UI 制御……。

これらを一つひとつ手作業で潰していく作業は、まるで地雷撤去のようでした。
「動くけれど、どこか不安」
そんなコードを本番環境にデプロイする夜は、正直言って生きた心地がしませんでした。

しかし、Next.js の Server Actions とスキーマ検証ライブラリ Zod に出会ってから、その景色は一変しました。

フォーム実装は「怖いもの」から、「型に守られた、堅牢なパズル」 へと進化したのです。

この記事では、僕が数々の失敗を経てたどり着いた、「もう二度と事故らせない、鉄壁のフォーム設計」 を共有します。

useEffect と API Routes の迷宮

少し前までの僕のフォーム実装は、正直言って「継ぎ接ぎだらけ」でした。

Pages Router 時代、あるいは React の `useEffect` を多用していた頃のコードを思い出すと、今でも冷や汗が出ます。

結果として出来上がるのは、「動いているけれど、誰も触りたくないスパゲッティコード」でした。
仕様変更が入るたびにどこかが壊れ、バリデーションをすり抜けた不正データがデータベースに保存されてしまう——そんな「事故」が、忘れた頃にやってくるのです。

サーバーとクライアントを 「型」 で繋ぐ

転機は、Next.js App Router の本格導入と共に訪れました。

Server Actions の登場です。

これにより、フォームの送信処理を「関数」として定義し、それを直接コンポーネントから呼べるようになりました。
API エンドポイントを意識する必要がなくなり、サーバー側のロジックとクライアント側の UI がシームレスに繋がったのです。

そして、そこに Zod という最強の盾を組み合わせる。

これが、僕が見つけた「鉄壁」の正体でした。

「あ、これなら事故りようがない」

初めてこの構成で実装し終えたとき、そう確信しました。
コード量は減っているのに、安心感は何倍にも増していたのです。

3 つのレイヤー

この（鉄壁の）設計は、大きく分けて 3 つのレイヤーで構成されています。

この分離が、メンテナンス性と堅牢性を劇的に高めます。

では、具体的な実装コードを見ていきましょう。
ここからは、僕が実際の案件や個人開発で使い回している「テンプレート」レベルの実装パターンを公開します。