ZodからValibotへの移行は必要か？バンドルサイズと記述力の比較

そこで候補に挙がるのが、ZodからValibotへの移行です。実際、ログインフォームのような比較的シンプルな検証では、Zodが約15.18〜17.7キロバイトになる測定例に対して、Valibotは約1.37キロバイトに収まる例があります。条件によっては、ValibotがZodより最大90％以上軽くなることもあります。

ただし、数字だけを見て移行を決めると、あとでスキーマの書き換えや周辺ライブラリとの接続に時間を取られます。ZodにはZod Miniや新しいバージョンによる最適化もあり、常にValibotが一方的に有利とは限りません。

この記事では、ZodとValibotの比較をバンドルサイズ、Tree-shaking、記述力、型推論、既存コードからの移行コストという五つの観点から整理します。私が特に見てほしいのは、単純な容量比較ではなく、なぜサイズ差が生まれるのかという仕組みです。そこが分かると、あなたのプロジェクトで移行すべきかどうかを、再現性のある形で判断できるようになります。

バンドルサイズ削減の仕組みは、ライブラリの設計にある

ZodとValibotの大きな違いは、スキーマを構成する機能が、どのような単位で提供されているかです。

Zodは、ひとつのスキーマオブジェクトに対してメソッドをつなげていく設計です。たとえば文字列のメールアドレスを検証する場合、Zodでは z.string().email() のように書きます。読み慣れている人にとっては自然で、スキーマが文章のように見える点も扱いやすさにつながっています。

一方、Valibotは各機能が独立した関数として提供されます。文字列のメールアドレスなら、pipe(v.string(), v.email()) のように、基本スキーマと検証処理をパイプラインとして組み合わせます。

この違いは、見た目だけの問題ではありません。モジュールが分割されていることで、バンドラーが実際に使われている関数だけを残しやすくなります。これがTree-shaking、つまり不要なコードを最終的なバンドルから取り除く仕組みです。

Valibotの関数単位設計がTree-shakingと相性がよい理由

フロントエンドのバンドルサイズを考えるとき、ライブラリ全体の容量と、あなたのコードが実際に利用する機能の容量は分けて考える必要があります。

ログイン画面で必要なのが、次のような処理だけだとします。

• ユーザー名が文字列であることを検証する
• メールアドレスの形式を検証する
• パスワードの長さを検証する
• 入力値をスキーマに通してエラーを扱う

このとき、画像の配列や日付変換、複雑なオブジェクト検証などを使っていないのであれば、それらの処理までブラウザへ送る必要はありません。

Valibotは、こうした処理を独立した関数として組み合わせる設計になっています。そのため、ビルド環境が適切に静的解析できれば、利用していない機能を削除しやすくなります。最小構成では600〜700バイト未満から始められるとされるケースもあり、入力フォームが少ない画面では効果が見えやすくなります。

ここで注意してほしいのは、Tree-shakingはライブラリを切り替えただけで自動的に最大効果が出る機能ではないということです。モジュール形式、バンドラー、インポート方法、利用しているAPI、圧縮方式などが影響します。

たとえば、同じValibotでも、不要な機能をまとめて読み込む書き方をしていれば、細かく関数を読み込む場合より削減効果が小さくなる可能性があります。反対に、Zod側でも利用する機能やバージョンを揃えれば、単純な比較より軽くなる場合があります。

バンドルサイズの差は、ライブラリ名だけで決まるものではありません。どの機能を、どの単位で読み込み、どの条件でビルドするかというプロセスの差です。

Zodは常に大きい、と決めつけない

ZodとValibotの比較で、もっとも避けたいのが、古い条件の測定結果だけで判断することです。

Zod側にもTree-shakingを意識した軽量版としてZod Miniが提供されており、Zodの通常版とValibotだけを比べて、Zod全体の設計を評価するのは正確ではありません。また、Zod v4など、バージョンによって内部実装やバンドルサイズの条件も変わります。

実際、全選択に近い比較例では、esbuildを使った場合にValibotが9.9キロバイト、圧縮後が3.4キロバイトだったのに対して、Zod v4は217キロバイト、圧縮後が42キロバイトという差が示されています。ただし、この種の比較は、どのAPIを利用したか、どのエントリーポイントから読み込んだか、バンドラーの設定をどうしたかによって意味が変わります。

数値は移行を検討するきっかけにはなりますが、最終判断はあなたのアプリケーションを実際にビルドしてからにしましょう。

ログインフォームで見る、ZodとValibotの実効サイズ

ライブラリの比較では、機能をすべて含めた容量よりも、実際の画面で何が残るかを見る必要があります。そこで、ログインフォームのような小さなユースケースを基準に考えてみます。

ログインフォームでは、スキーマはおおむね次のようになります。

Zodの書き方

Zodでは、型と検証ルールをひとつのチェーンにまとめます。

ユーザー名を必須の文字列にし、メールアドレスとパスワードを検証するなら、z.object() の中に z.string() や z.string().email() を配置していく形です。記述の流れが直感的で、既存のJavaScriptやTypeScript開発者にも読みやすいでしょう。

また、Zodではスキーマ自体が値の解析やエラー情報を持つため、スキーマから型を推論し、そのままフォーム処理やAPI通信へつなげやすい点が魅力です。

ログインフォームのように、画面側の入力とサーバーへ送るデータがほぼ同じであれば、Zodの記述は特に素直です。LaravelのAPIへ送信する前に、フロントエンド側で入力エラーを表示する場合でも、スキーマを一か所にまとめられます。

Valibotの書き方

Valibotでは、検証の各処理をパイプラインへ渡します。

文字列、メールアドレス、最小文字数などをそれぞれ関数として組み合わせるため、Zodのメソッドチェーンに慣れている場合は最初だけ違和感があるかもしれません。しかし、慣れてくると、どの処理をどの順番で適用しているかが明示されます。

たとえば、文字列として受け取り、その後にメール形式を検証するという流れが、pipe() の中にそのまま現れます。変換処理を追加する場合も、入力を受け取ってから出力へ変換する順番を意識しやすくなります。

ログインフォームだけなら、この違いは好みの範囲に感じるでしょう。しかし、APIレスポンスの整形や、フォーム入力の変換、複数段階の検証を組み合わせると、設計思想の違いがはっきり表れます。

測定例を比較するときの見方

ログインフォームの検証で確認されている測定例を整理すると、次のようになります。

この表で注目したいのは、Valibotの数値だけではありません。ログインフォームのような小規模な検証でも差が出る一方で、その差がアプリケーション全体の通信速度へ直結するとは限らない点です。

たとえば、画像やUIコンポーネント、地図ライブラリ、エディターなどが大量に含まれるアプリケーションでは、バリデーションライブラリを数キロバイト削減しても、全体の改善幅は限定的かもしれません。逆に、初期表示をできるだけ小さくしたい管理画面や、モバイル回線を強く意識するサービスでは、Valibotの軽量性が判断材料になります。

メソッドチェーンとパイプラインは、単なる書き方の違いではない

ZodとValibotの違いを説明するとき、メソッドチェーンとパイプラインという構文上の差だけで終わらせると、移行の判断を誤りやすくなります。

両者は、検証処理をどのように組み立て、どこに責務を置くかという設計思想にも違いがあります。

Zodはスキーマをひとつのまとまりとして扱いやすい

Zodのメソッドチェーンは、ひとつのスキーマを中心に考える設計と相性がよいものです。

文字列であること、メールアドレス形式であること、最小文字数を満たすことを、ひとつの値に対する連続した条件として書けます。そのため、スキーマを読む人は、対象の型とルールを同じ場所で追いかけられます。

また、Zodはフロントエンドだけでなく、サーバーサイドのTypeScriptコードでも利用されることが多く、既存の事例や周辺情報を探しやすい点があります。チーム開発で新しいメンバーが参加したときも、Zodの記述に触れた経験がある人なら、早い段階で読み解ける可能性があります。

既存のコードベースにZodが広く使われている場合、記述の読みやすさだけでなく、テスト、エラーハンドリング、フォームライブラリとの接続、APIクライアントとの統合まで含めて考えなければなりません。

Valibotは処理の組み合わせを明示しやすい

Valibotのパイプライン形式では、検証や変換を独立した処理として考えやすくなります。

これは、スキーマが複雑になったときにメリットがあります。入力値を受け取り、文字列として確認し、空白を処理し、形式を確認し、最後にアプリケーション内部で扱う値へ変換する、といったプロセスを順番に見せられるためです。

もちろん、処理を細かく分けすぎると、かえってコードが読みにくくなる場合もあります。パイプラインだから必ず保守しやすいわけではなく、どの段階で何を保証するのかをチーム内で決める必要があります。

私は、Valibotを使うときほど、スキーマをただ短く書くのではなく、入力と出力の境界を意識して設計することをおすすめします。特にLaravel APIと連携する場合、ブラウザから送る値、Laravelが受け取る値、Laravel側で正規化された値が同じとは限りません。

API連携では、フロントエンドだけの型安全性にしない

Vue.jsやReactからLaravelのAPIへデータを送る場合、フロントエンドのスキーマバリデーションは、ユーザー体験を改善するための仕組みです。入力ミスを送信前に表示し、API通信の回数を減らし、画面上のエラーを分かりやすくする役割があります。

しかし、それはサーバー側のバリデーションの代わりにはなりません。

Laravelでは、リクエストクラスやバリデーションルールによって、サーバーへ届いた値を改めて検証します。ブラウザ上のコードは利用者が変更できるため、フロントエンドで検証済みだから安全だと考えることはできません。

この前提に立つと、Valibotへの移行で得られるのは、主にフロントエンドへ配信するコードの軽量化と、画面側の検証処理の設計改善です。Laravel側の検証処理まで自動的に軽くなるわけではありません。

InferInputとInferOutputで、入力と変換後の値を分ける

Valibotの型推論で見逃しにくい特徴が、InferInput と InferOutput の使い分けです。

通常の入力フォームでは、ユーザーが入力した値とアプリケーション内部で利用する値が同じとは限りません。たとえば、画面から受け取る数値が文字列になっているケースがあります。HTMLの入力要素やフォームライブラリの都合で、年齢や数量が "10" のような文字列として渡されることは珍しくありません。

この値を、スキーマの中で数値へ変換してから利用する場合、入力型は文字列を含み、出力型は数値になります。

Valibotでは、変換を含むスキーマに対して、入力側の型と出力側の型を分けて扱えます。

• InferInput は、スキーマへ渡す前の値を表します
• InferOutput は、検証や変換が終わった後の値を表します

この区別があると、フォーム入力とAPIリクエストの境界を整理しやすくなります。

入力型と出力型を分けるメリット

フロントエンドでは、同じデータが複数の段階を通過します。

まず、ユーザーがフォームへ入力します。次に、入力値を検証します。その後、必要に応じて空白を除去したり、文字列を数値へ変換したりします。最後に、APIへ送信するデータとして組み立てます。

このとき、すべてをひとつの型として扱うと、どの時点の値なのかが分かりにくくなります。入力型と出力型を分ければ、フォームの状態、検証後のデータ、API送信用のデータをそれぞれ適切に表現できます。

たとえば、次のような設計が考えられます。

1. フォームの入力値は、画面から渡される文字列中心の型として扱う

2. Valibotのスキーマで必須項目と形式を検証する

3. pipe() に変換処理を追加し、アプリケーション内部の型へ整える

4. InferOutput に基づいてAPI送信処理を組み立てる

5. Laravel側で改めてリクエストを検証する

このプロセスを意識すると、型推論を単なる補完機能ではなく、データの流れを説明するための仕組みとして利用できます。

Zodでも変換はできるが、表現の重点が異なる

Zodにも変換処理やスキーマからの型推論があります。そのため、入力値と出力値を扱えないわけではありません。

違いは、Valibotが入力型と出力型の区別を、設計上より前面に出している点です。入力と出力が異なるスキーマを多く扱う場合は、Valibotの考え方がコードの構造と合いやすいでしょう。

一方、入力値と出力値がほぼ同じで、検証条件もそれほど複雑でないなら、Zodのシンプルな記述のほうが理解しやすい可能性があります。

このあたりは、どちらが優れているかではなく、あなたのデータ処理にどの程度変換が登場するかで判断してみましょう。

ZodからValibotへ移行するときに起きやすい問題

既存プロジェクトでZodを使っている場合、Valibotへの移行は、パッケージ名を差し替えるだけでは終わりません。

メソッドチェーンをパイプラインへ書き換える必要があり、スキーマの生成方法、エラー情報の扱い、フォームライブラリとの連携、テストの期待値まで確認することになります。

特に注意してほしいのが、Zodのスキーマメソッドを直接利用しているコードです。スキーマを組み合わせる処理や、任意項目、既定値、変換、カスタムエラーなどを多用している場合は、Valibot側で同じ概念をどの関数に置き換えるかをひとつずつ確認しなければなりません。

移行コストが大きくなりやすいケース

次のようなプロジェクトでは、バンドルサイズの削減効果だけで移行を決めないほうがよいでしょう。

• Zodのスキーマが多数の画面やAPIクライアントで共有されている
• フォームライブラリやデータ取得ライブラリがZodを前提に設計されている
• カスタムエラーや変換処理をZod独自の書き方で細かく組み立てている
• フロントエンドとサーバーサイドの両方でZodを利用している
• 既存テストがZodのエラー構造やメソッドに依存している
• チーム内でZodの知識が共有され、Valibotの学習時間を確保しにくい

こうした場合は、全体移行ではなく、まず新規画面だけでValibotを試す方法が現実的です。既存コードをすべて書き換えず、境界を決めて小さく導入すれば、移行後の問題を切り分けやすくなります。

新規プロジェクトではValibotを選びやすいケース

反対に、次のような条件なら、最初からValibotを採用する理由があります。

• 初期表示のバンドルサイズをできるだけ小さくしたい
• モバイル環境や低速回線での読み込みを重視している
• フロントエンドで必要な検証処理が限定されている
• 入力値から出力値への変換を明確に型で表したい
• スキーマを機能単位の関数として組み立てたい
• TypeScriptの型推論をフォームとAPIの境界で活用したい

ただし、新規プロジェクトでも、既存のチーム資産や採用予定のライブラリとの相性は確認してください。軽量であることは重要ですが、実装や保守に時間がかかれば、プロジェクト全体では別のコストが発生します。

実際に比較するときは、同じ条件でビルドする

ZodとValibotのバンドルサイズを比較するなら、測定方法を揃えることが欠かせません。

片方だけ開発用ビルドで、もう片方だけ本番用ビルドにすると、数字は簡単に変わります。圧縮前と圧縮後を混ぜてもいけません。さらに、ログインフォームだけを比較した結果と、ライブラリの機能を広く読み込んだ結果を同じ表で扱うと、何を比較しているのか分からなくなります。

私なら、次のような順番で確認します。

1. 同じバージョンのNode.jsと同じパッケージマネージャーを使う

2. 同じバンドラーと同じ本番ビルド設定を使う

3. ZodとValibotで同じ検証内容を実装する

4. 開発用コードやテストコードをバンドル対象から外す

5. 圧縮前と圧縮後の両方を記録する

6. ログインフォーム、登録フォーム、APIレスポンス検証など用途を分けて測定する

7. Zod Miniなど、比較対象となる軽量版も条件に含める

8. 初期チャンクに含まれるか、遅延読み込みされるかを確認する

最後の項目は、特に見落とされやすいところです。ライブラリの容量が小さくても、そのコードが初期表示のチャンクに含まれていなければ、最初の画面表示への影響は限定的です。逆に、すべてのページで共通利用されるスキーマが初期チャンクへ含まれているなら、数キロバイトの差が繰り返し効いてくることがあります。

バンドルサイズ以外に見るべき指標

容量を比べるときは、次の観点も一緒に確認しておくと、移行後の評価が安定します。

• 初期表示時に読み込まれるJavaScriptの容量
• 圧縮後の転送サイズ
• ビルド時間への影響
• 型チェックにかかる時間
• エラー処理の実装量
• フォームライブラリとの連携しやすさ
• APIレスポンス検証への適用しやすさ
• チームメンバーがコードを読めるか
• テストの書き換え量
• 将来のライブラリ更新に対応できるか

Valibotを採用する目的が、モバイル向け画面の初期表示改善なのか、スキーマの設計を整理することなのかで、見るべき指標は変わります。目的を決めずに容量だけを追うと、改善した数字は得られても、開発体験が悪くなる可能性があります。

どちらを選ぶべきかは、プロジェクトの境界で決まる

ここまでの内容を、実際の選択に落とし込んでみましょう。

Zodを継続する判断が自然なケース

Zodを継続してよいケースは、決して少なくありません。

既存のスキーマが安定しており、バンドルサイズがアプリケーションの問題になっていないなら、移行による恩恵は限定的です。スキーマの書き換えには、実装時間だけでなく、レビューやテスト、仕様確認の時間も必要になります。

また、サーバーサイドのTypeScriptコードとスキーマを共有している場合も、Zodを継続する価値があります。フロントエンドだけValibotへ移すと、同じ仕様を別のライブラリで表現することになり、二重管理が発生するかもしれません。

Zod Miniや利用するAPIの見直しによって、現在のバンドルサイズを下げられる可能性もあります。まずは現状のビルド結果を確認し、Zodを残したまま改善できる部分がないか見てみましょう。

Valibotへの移行を検討しやすいケース

Valibotへの移行を検討しやすいのは、次のような場合です。

初期バンドルがすでに大きく、分析ツールでバリデーションライブラリが無視できない割合を占めているなら、軽量化の効果を見込めます。特に、ログインや会員登録のように、多くの利用者が最初に通過する画面へ含まれている場合は、検討する意味があります。

また、スキーマで変換処理を多く扱う場合も、Valibotの入力型と出力型の分離が役立ちます。フォーム入力からAPI送信用のデータへ整えるプロセスを明確にしたいなら、関数を組み合わせる設計がチームの考え方に合う可能性があります。

ただし、移行を進めるなら、いきなり全体を置き換えないようにしてください。まず一つのフォームや、一つのAPIレスポンス検証から始めて、記述量、エラー処理、テストの再現性を確認します。

段階的な移行で確認するポイント

段階的に進めるときは、ZodとValibotを同じプロジェクト内で併用する期間が発生します。ここでルールを決めないと、スキーマごとに書き方が変わり、かえって保守性が下がります。

最初に、どの範囲をValibotで担当するか決めましょう。たとえば、新規のフロントエンドフォームだけに限定する、APIレスポンスの検証だけに使う、共有パッケージには導入しない、といった境界を設けます。

次に、エラー形式をアプリケーション側で吸収します。ZodとValibotではエラー情報の扱い方が異なるため、画面コンポーネントがライブラリ固有の形式へ直接依存すると、後の変更が難しくなります。

最後に、同じ入力に対して同じ結果になるかをテストします。正常値だけでなく、空文字、余分な空白、形式違い、境界値、欠落した項目、APIから返ってきた予期しない値まで確認しておくと、移行による挙動の変化を見つけやすくなります。

移行の成否は、置き換えたファイル数ではなく、入力から出力までのプロセスを同じ品質で再現できるかで決まります。

Laravelとフロントエンドの間でどう使い分けるか

Laravelをバックエンドにして、Vue.jsやReactで画面を構築している場合、スキーマバリデーションは三つの場所に分かれます。

ひとつ目は、ユーザーが入力するフォームです。ここでは、入力直後にエラーを表示し、送信前に明らかな不備を取り除くことが目的です。

二つ目は、API通信の直前です。フォームの状態をAPIのリクエスト形式へ変換し、必要な項目が揃っているかを確認します。

三つ目は、APIから返ってきたレスポンスです。サーバーが常に想定どおりのデータを返すとは限らないため、フロントエンド側でもレスポンスの形を確認しておくと、画面の予期しないクラッシュを防ぎやすくなります。

この三つをすべて同じスキーマで表現できるとは限りません。フォーム入力では空文字を許容していても、API送信時には値が必要になることがあります。レスポンスでは、Laravelが日時を文字列として返す一方、フロントエンド内部では日付オブジェクトへ変換したい場合もあります。

そのため、スキーマを無理に一つへ統合するより、入力、送信、出力という境界ごとに責務を分けたほうが、コードの意図は明確になります。

Valibotのパイプラインと InferInput、InferOutput は、このような境界を設計する場面で使いやすい考え方です。一方で、既存のLaravel APIとZodを組み合わせた構成がすでに安定しているなら、移行によって境界が増えないかを慎重に見てください。

フロントエンドのバンドルが大きいなら、先に原因を分解する

ZodからValibotへの移行を考える前に、バンドルサイズ全体の原因を確認することも大切です。

バリデーションライブラリが数十キロバイト含まれていたとしても、同じチャンクに数百キロバイトのUIコンポーネントや画像処理ライブラリが含まれていれば、そこを先に見直すほうが効果的な場合があります。

逆に、アプリケーションが小さく、フォームとAPI通信が中心であれば、Valibotの軽量性が相対的に大きな意味を持ちます。

次のような順番で原因を切り分けてみましょう。

1. 本番ビルドの初期チャンクを確認する

どのライブラリが最初の画面に含まれているかを見ます。

2. Zodがどのエントリーポイントから読み込まれているか確認する

通常版を使っているのか、軽量版を利用できるのかを確認します。

3. スキーマを共通モジュールから一括読み込みしていないか確認する

一つのフォームしか使わない処理が、全画面の共通チャンクへ入っている可能性があります。

4. 動的インポートで分離できる画面か確認する

管理画面や設定画面など、初期表示に不要な検証処理は遅延読み込みできるかもしれません。

5. それでも削減余地があるか測定する

原因がValibotへの移行で解決する問題なのか、別の構成変更が必要なのかを判断します。

この順番を踏むと、ライブラリの変更が目的化しにくくなります。軽量なライブラリを選ぶこと自体はよいのですが、バンドルに含まれている理由を理解しないまま移行すると、期待した改善が得られないことがあります。

ZodとValibotの違いを、開発チームの視点で整理する

個人開発では、作者自身がスキーマの設計と保守を担当するため、構文の好みが選択へ大きく影響します。自分が読みやすく、数か月後にも意図を追えるほうを選ぶことは、十分に合理的です。

一方、チームで開発する場合は、個人の好みだけでなく、次のような点も関係します。

• 新しく参加したメンバーが構文を理解しやすいか
• エラー処理の方針を共有しやすいか
• スキーマの責務をレビューで確認できるか
• フロントエンドとバックエンドの境界を説明できるか
• テストで入力と出力の差を表現しやすいか
• 将来のライブラリ更新に対応できるか

Zodはメソッドチェーンによるまとまりのよさがあり、Valibotは関数単位とパイプラインによる構造の明示性があります。

たとえば、単純なフォームを短く書きたいなら、Zodの読みやすさが魅力になります。複数の変換処理や入力と出力の差を明示したいなら、Valibotの設計が合いやすいでしょう。

ここで、どちらかを絶対的な正解にする必要はありません。フロントエンドの新規フォームだけValibot、既存の共有スキーマはZodという選択もできます。ただし併用するなら、どの領域で何を使うのか、エラー形式をどこで統一するのかを先に決めてください。

結論：移行は必要ではなく、目的があるときに価値が出る

ZodからValibotへの移行は、すべてのプロジェクトに必要な作業ではありません。

Valibotは、関数単位のモジュール設計によってTree-shakingを活かしやすく、スキーマの構成によってはZodと比較して最大90％以上のバンドルサイズ削減が期待できます。ログインフォームの測定例でも、Zodが約15.18〜17.7キロバイト、Valibotが約1.37キロバイトという差が示されています。

また、pipe() を中心とした記述と、InferInput、InferOutput による入力型と出力型の分離は、フォーム入力からLaravel APIへの送信、そしてレスポンスの検証までを整理するうえで役立ちます。

その一方で、Zodにはメソッドチェーンの読みやすさ、既存エコシステム、豊富な利用実績があります。Zod Miniやバージョン差もあるため、Zodは常に重く、Valibotへ移れば必ず改善するという判断は避けてください。

まずは本番ビルドを測定し、どの画面でどの程度のサイズが読み込まれているかを確認しましょう。そのうえで、Valibotを小さなフォームやAPIレスポンス検証へ導入し、記述力、エラー処理、テスト、開発チームの理解しやすさを確認してみてください。

数字の軽さだけでなく、入力から出力までの仕組みを無理なく説明できるか。そこまで含めて納得できるなら、Valibotへの移行は単なる容量削減ではなく、フロントエンドのデータ処理を見直すよい機会になります。次は、あなたのプロジェクトで最も小さく切り出せるスキーマを一つ選び、同じ条件でZodとValibotのビルド結果を測定してみましょう。

Related reading: DockerイメージのAlpineとSlim：軽量化と互換性を巡る二つの選択肢.