Zod入門 — TypeScriptで型とバリデーションを一致させるスキーマ検証

Posted at 2026-06-29

はじめに

TypeScript を使っていても、実行時のデータは型では守れません。
フォーム入力や API のレスポンスは、期待した形とは限らないからです。
型はコンパイル時のチェックで、実行時には消えてしまいます。

そこで必要になるのが、実行時のバリデーションです。
その定番ライブラリが Zod です。
スキーマを1つ書くだけで、検証と型の両方が手に入ります。

この記事の対象読者

この記事で得られることは次の3つです。

なお、この記事は仕組みと使いどころの理解を目的とします。
具体的な API の書き方には踏み込みません。
バージョンは Zod v3 系を前提とします。

Zod は TypeScript 向けのスキーマ宣言・バリデーションライブラリです。
「スキーマ」とは、データの形を定義したものです。

たとえば「名前は文字列」「年齢は0以上の数値」といったルールです。
このルールを Zod のスキーマとして1つ書きます。
あとは、そのスキーマで実際のデータを検証できます。

特徴は、スキーマから TypeScript の型を自動で導き出せる点です。
検証のルールと型が、常に一致した状態を保てます。

Zod の価値は、バリデーションを手書きする場合と比べると分かります。

TypeScript で型を定義しても、実行時のチェックは別に必要です。
そのため、多くの場合こうなります。

つまり、型と検証を二重に管理することになります。
片方だけ直して、もう片方を直し忘れる。
この食い違いが、バグの温床になります。

Zod はスキーマを「一つの真実の源」にします。
スキーマから型を導出するので、型と検証が必ず一致します。
二重管理がなくなり、修正もスキーマ1か所で済みます。

Zod の流れは、1つのスキーマを中心に考えると分かりやすいです。

ポイントは、型と検証が同じスキーマから生まれることです。
スキーマを直せば、型も検証も同時に変わります。
だから両者がずれません。

検証に成功すると、型のついた安全なデータが得られます。
失敗すると、どこがどう違うかが構造化されて返ります。

「スキーマが一つの真実の源になる」のが Zod の核心です。
型のための定義と、検証のための定義を、別々に書かなくて済みます。

Zod が支持される理由を整理します。

特に型推論は強力です。
スキーマを書くだけで、対応する型が手に入ります。
型を別途書く必要がないため、記述量と保守の手間が減ります。

Zod が活きるのは「外から来るデータ」を扱う場面です。
信用できない入力を、境界で検証するのに向いています。

ユースケース	役割
フォーム入力	送信値の検証（React Hook Form と連携できる）
API の入出力	リクエスト・レスポンスの形を保証する
環境変数	起動時に設定値の不足や誤りを検出する
外部データの取り込み	JSON など未知の形を安全な型に変換する

React Hook Form と組み合わせると、フォーム検証がさらに楽になります。
スキーマを1つ渡すだけで、入力チェックと型が両立します。