Zodによるバリデーションのイメージ

「型定義だけじゃ、まだ不安」なあなたへ

TypeScriptでコードを書き、型定義を完璧に整えた。コンパイルエラーもゼロ。
それなのに、実行時にAPIから予期せぬデータが届いてアプリがクラッシュする……。そんな苦い経験はありませんか？

TypeScriptの型はコンパイル時にのみ存在し、ブラウザで動くときには消えてしまいます。つまり、「外部から来るデータ」が本当に正しいかどうかは、実行時にチェックするしかないのです。

Zod：型安全を「ランタイム」に持ち込む

そこで登場するのが Zod です。
Zodは、データの「スキーマ（設計図）」を定義し、実行時にその通りであるかを厳格にチェックします。

  • 不適切なデータを入り口で遮断: string を期待していたのに null が来たら、即座にエラーを出して後続の処理を守ります。
  • 型定義も同時に手に入る: スキーマを定義すれば、そこから TypeScript の型も自動的に抽出できます（z.infer<T>）。

スキーマを書く手間を「ゼロ」に

Zodは非常に強力ですが、複雑なJSONに合わせてスキーマを手書きするのは、それなりに骨の折れる作業です。

当サイトの JSON→Zod変換ツール は、そんな「スキーマ定義の面倒くささ」を解消するために作りました。お手元のJSONを貼り付けるだけで、対応する Zod スキーマを一瞬で生成します。

基本的なワークフロー

  1. APIから返ってくるJSONをコピーする。
  2. ツールに貼り付けて、Zod スキーマ（z.object({...})）を生成。
  3. 生成されたコードをプロジェクトに貼り付けて、Schema.parse(data) でバリデーションを開始！
import { z } from 'zod';

// ツールで生成されたスキーマ
const UserSchema = z.object({
  id: z.number(),
  name: z.string(),
});

// 実行時のチェックと型抽出が同時に行える
type User = z.infer<typeof UserSchema>;
const safeData = UserSchema.parse(rawData);

APIレスポンスでの実用例

実務では、一覧APIの一部フィールドだけが null になる、日付が文字列で返る、数値IDが文字列に変わる、といった小さなズレが起きます。

{
  "id": "123",
  "name": "Ada",
  "lastLoginAt": null
}

このJSONから生成したスキーマは、そのまま使うだけでなく、仕様に合わせて調整します。id を数値に変換する設計なら z.coerce.number()、ログイン日時が未設定でもよいなら z.string().datetime().nullable() のように直します。ツールでたたき台を作り、境界条件だけ人間がレビューする流れにすると、手書きミスを減らしながら現実のAPI仕様にも合わせられます。

まとめ

データの境界線を守ることは、システムの堅牢性を守ることです。
「たぶん大丈夫だろう」という推測を、Zodによる「確かな検証」に変えましょう。手書きの手間はツールに任せて、より本質的なロジックの実装に集中してください。