ゾッド 4

2025年5月20日原文(zod.dev)

概要

Zod 4 が正式リリース、パフォーマンスと効率が大幅向上
Zod 3との共存 で移行を簡易化、詳細はMigration guide参照
zod/v4-mini でバンドルサイズを大幅削減、特に厳しいプロジェクト向け
新機能 ：メタデータ管理、再帰型、ローカライズ、エラープリティプリント等
API刷新 と設計改善で今後の拡張・連携を強化

Zod 4: 新時代のTypeScriptスキーマバリデーション

リリースと移行戦略

Zod 4 は1年間の活発な開発を経て安定版として公開、 パフォーマンス・効率性・新機能 を大幅強化
Clerk OSS Fellowship による支援に感謝、開発期間延長にも柔軟に対応
移行の円滑化のため、 Zod 3とZod 4はzod@3.25で同時配信、既存エコシステムとの互換性維持
Zod 4の利用 は/v4サブパスからimportすること
将来的にはnpmで zod@4.0.0 としてパッケージルートからエクスポート予定、zod/v4サブパスも維持
詳細なバージョニング理由や破壊的変更は Migration guide やGitHub issueで確認すること

成長と背景

Zod v3.0 （2021年5月リリース）時点：GitHub stars 2,700、週60万ダウンロード
現在（Zod 4） ：GitHub stars 37,800、週3,100万ダウンロードに拡大
Zod 3の設計限界 を突破し、要望の多かった新機能・パフォーマンス向上・設計改善を一挙実現
最も投票数の多かったオープンissueの9/10を解決、新たな基盤として長期活用を目指す

パフォーマンス・効率性の向上

ベンチマーク
- 文字列パース：14倍高速化
- 配列パース：7倍高速化
- オブジェクトパース：6.5倍高速化
TypeScriptコンパイル効率
- tscの型インスタンス生成数：zod/v3で25,000超→zod/v4で約175に削減
- .extend()や.omit()の連鎖によるコンパイラ負荷を大幅軽減、10倍高速化
- tsgo compiler との連携で大規模スキーマでも編集性能を維持

バンドルサイズ削減とzod/v4-mini

コアバンドルサイズ
- zod/v3：12.47kb（gzip）
- zod/v4：5.36kb（gzip、57%削減）
zod/v4-mini 導入
- 機能APIをラップ関数化し、未使用APIのtree-shakingを容易化
- zod/v4-mini：1.88kb（gzip、zod@3比で85%削減・6.6倍小型化）
- バンドルサイズ厳格プロジェクト に推奨、詳細はzod/v4-mini docs参照

新機能・拡張

メタデータ管理
- スキーマに型付きメタデータを付与、schema registryで管理
- .meta()でグローバル登録、JSON Schema変換時も自動反映
再帰型サポート
- 型キャスト不要で再帰・相互再帰スキーマをシンプルに定義可能
ローカライズAPI
- エラーメッセージの多言語対応（現時点で英語のみ、今後拡充予定）
エラープリティプリント
- z.prettifyErrorでZodErrorを読みやすい文字列に変換可能
string format API刷新
- z.string().email()等のメソッドは非推奨、z.email()等のトップレベル関数推奨
- カスタムemail正規表現や共通パターンも提供
template literal型サポート
- TypeScriptのtemplate literal型をバリデーション可能に
数値型フォーマット
- 固定幅整数・浮動小数点型（int8, uint8, float32等）やBigInt型もサポート
高度なboolean coercion
- z.stringbool()でenvスタイルの真偽値変換、カスタマイズも可能
エラーAPIの統一・刷新
- errorパラメータに一本化、従来のmessage/invalid_type_error/required_error/errorMapは非推奨
discriminated unionの拡張
- union, pipe, ネストオブジェクト等もサポート、union同士の合成も可能
z.literal()の複数値対応
refinementの実装改善
- スキーマ内部で管理し、他のメソッドとの併用が容易に
.overwrite()導入
- 型を変更しない変換処理をrefinementとして記述可能、transformとの違い明確化
zod/v4/coreサブパッケージ
- zod/v4・zod/v4-mini共通の基盤、他ライブラリへの組み込み容易化
- スキーマライブラリ開発者向けにFor library authors guideも整備

今後・コミュニティ

ドキュメント・設計解説記事 を順次公開予定
GitHub DiscussionsやX/Bluesky でフィードバック・質問受付
ライブラリアーサー向けガイド でZod 3/4両対応やMini対応のベストプラクティスを解説

Zod 4は、TypeScriptバリデーションの新たな標準として、パフォーマンス・拡張性・開発体験を大きく進化させました。今後のエコシステム発展にも注目してください。

Hackerたちの意見

Zodは、見た中での代替案よりずっといいと思う。ただ、こういう明示的なバリデーションが必要っていうのは、現代のウェブ開発が進んできたところでの失敗のように感じる。フルスタック開発が同じ形を表現するのにこんなにたくさんの方法を必要とするのが本当にイライラする：JSの入力バリデーション、API定義のためのSwagger、サーバーサイドの入力バリデーション、スキーマ準拠のためのORM、TypeScriptはサーバーとクライアントで別々の定義が必要なことが多い。ほんとに面倒くさいよね。

└

でも、こういうものの本質はそこなんだよ。一度やれば、後はダイナミックに他のものを生成できる。だから、Zodのスキーマを一度変更すれば、アプリ全体で型チェックしながら伝播するんだ。Zodのスキーマが真実のソースになるんだよ。

└

そうだね、少なくとも統合する方法があって、真実のソースとして扱うフォーマットに合意できるようにするべきだよね。他のフォーマットを生成するために。

└

それ以外にどうやってやるの？ trpcみたいなものでフルエンドツーエンドの型安全性を確保することもできるけど、それにはフロントエンドとバックエンドの両方でTypeScriptを使う必要がある（みんながそうするわけじゃないし）し、ウェブプラットフォームにだけ縛られることになる（だからモバイルとかは無理）。

└

TypeScriptが静的チェック/コンパイル時専用のシステムであることにこだわるのは、全体のエコシステムにとって悲しい傷だよね。TypeScriptにランタイムチェックをしてほしいわけじゃないけど、クラス、関数、オブジェクトのために使える型データをエクスポートしてほしい。TypeScriptは私たちが持っている最良の真実のソースのように感じるけど、実際には私たちが持っているものを反映しようとする試みの多くが独自に進んでいて、自分たちのモデルやビルダーを定義しなきゃいけない。君は反映がミッションの核心部分である5つの主要な領域を挙げていて、それぞれに複数の実装がある。古いTypeScript型エミッターやreflect-metadataがあって、これはランタイムでいくつかの型情報を提供するけど、非常に古いデコレーターやメタデータの仕様を対象にしていて、現在のバージョンではない。どれだけ正確か完全かはあまり分からないけど、TypeScriptが知っていることをどれだけ書き留めているか、どれだけ自分のモデルを定義してエクスポートしているかは分からない。https://www.npmjs.com/package/reflect-metadata もしかしたら、私たちは何かを統一する、集まる寸前にいるのかもしれないけど、今のところTypeScriptを介さずに、まだ別のレイヤーとして。Standard Schemaプロジェクトは、言うまでもなくほとんどのトップバリデーションライブラリからサポートを受けている。でも、これをAPI定義やORMツールに拡張するのは、まだ非常に初期の段階だよ。https://github.com/standard-schema/standard-schema?tab=readm...

└

すべてのAPIは実験的で、常に変化し進化している状態にあるよ、ウェブも含めてね。現状維持が許されるのは、ただ物事を終わらせたいクライアントや雇用者のためだけだよね。そういう文脈では、こういう複雑なレイヤーがあるおかげで、少なくとも請求可能な時間が増えるってことだね。

└

drizzleとHono、zodを使ってクライアントを作ってるんだ。だから、UIからクライアント、サーバー、DBまで、同じバリデーションと形を保ってるよ。

└

フルスタック開発が同じ形を説明するのにこんなに多くの方法を必要とするのは本当にイライラするよね。JSの入力バリデーション、API定義のためのSwagger、サーバーサイドの入力バリデーション、スキーマ準拠のためのORM、TypeScriptはサーバーとクライアントで別々の定義が必要だったりするし。めっちゃ面倒くさい。現代のウェブ開発が複雑だって文句を言ってる人たちが、TypeScript（もしそれが君のTSスキーマ定義とバリデーションライブラリなら）で全部置き換えようなんて提案したら、みんなビビるだろうね。

└

データをあちこちで再定義する必要は普通はないよ。zodに変換するためのコンバーターが山ほどあるし、zodから他のものへの変換も同様。もし既にJSONスキーマやswaggerスキーマがあるなら、そこからzodを生成すればいいし。TypeScriptのORMを使ってるなら、$10賭けてもいいけど、zodのジェネレーターがあるはずだよ。正直、zodはすごく人気が出てきて、私にとってはスタックの他の部分が頼れる統一的なスキーマ定義になってる。しかも、直接型を定義するから、開発者たちが実際に最新の状態に保ってくれるし（私の会社のswaggerドキュメントは常に変更に遅れをとってる）。

私は専門家じゃないけど、JSON-Schemaがいい選択肢かもしれないって思った。スキーマベースだから、TypeScriptじゃない言語でもバリデーターを実装できるし。https://ajv.js.org はそんなJSONスキーマライブラリの一つだよ。Zodはこれと比べてどうなの？

└

まあ、ZodはJSONの検証だけじゃないんだよ。変換なしではJSONで表現できないオブジェクト（日時やクラスのインスタンスなど）の検証もサポートしてる。もし必要なら、JSONの変換器としても使えるよ。例えば、スキーマを作って文字列を受け入れ、それをISO日付文字列として検証し、Dateオブジェクトとして出力することもできるんだ。

└

Zod 4はZodスキーマをJSON-Schemaに変換することをサポートしてる（ネイティブで、これまでもサードパーティのライブラリで可能だったけど）。一つの大きな違いは、前処理やリファインができること。Zodを使うと、検証を実行する前にコールバックを提供できるから、すごく便利でJSONでは表現できないことなんだ。これ、思ったよりも頻繁に役立つよ。例えば、MM/DD/YYYYをDD/MM/YYYYに変換してから日付として検証するみたいな感じ。

Hacker Newsで議論の続きを見る

ハクソク