JSON Schema ⇄ Zod 変換

入力が違います。JSON to ZodはAPIレスポンスなどの「値のサンプル」から型を推測するツールで、必須かどうかや文字列のformatは分かりません。こちらは「JSON Schema」そのものを入力とするため、requiredやenum、minLength、format:emailといった制約情報がそのままZodのチェーン（.optional() / .enum() / .min() / .email()）に反映されます。手元にOpenAPIやJSON Schemaの定義がある場合はこちらが正確です。

JSON Schemaでは「requiredの配列に列挙されていれば必須」ですが、Zodでは「.optional()が付いていなければ必須」で、既定値が逆になっています。この変換ではその違いを吸収し、JSON Schema→Zodではrequiredに無いプロパティへ.optional()を付け、Zod→JSON Schemaでは.optional()の無いプロパティをrequired配列に集めます。

$refの参照先は展開せず、その位置はz.any()になり警告を表示します。共通定義を$defsに切り出しているスキーマは、参照先を手元で展開してから貼り付けるか、生成後にその部分だけ手で書き換えてください。allOfも交差型として表現できないため、先頭のスキーマのみを変換して警告を出します。

スキーマの骨組みとしては使えますが、業務ルール（メールドメインの制限、値どうしの整合性など）は元のJSON Schemaに書かれていない限り生成されません。またz.string().regex()に変換されるpatternは、JSON SchemaがECMAScript互換でない正規表現を使っている場合に挙動が変わることがあります。生成後に必ず内容を確認してください。

OpenAPIのcomponents.schemasはJSON Schemaなので、そのまま貼り付ければZodスキーマとz.inferによる型が同時に手に入ります。サーバーの定義とフロントの検証がずれるのを防げます。

コード側で先にZodスキーマを書いている場合、逆方向の変換でJSON Schemaを生成し、OpenAPIのcomponentsやドキュメントに貼り付けられます。

if文で書かれた検証を置き換えるとき、JSON Schemaがあれば出発点のZodスキーマを一気に生成できます。requiredやenumの取りこぼしが減ります。

LLMに書かせたJSON Schemaをそのまま貼り付けて、TypeScriptで動くZodスキーマに変換し、型と実行時検証の両方を得られます。

$refは参照先を解決せずz.any()になり、allOfは先頭のスキーマのみを変換します。if/then/elseやnotも非対応です。いずれも変換結果の下に警告として表示されるので、該当箇所は手で補ってください。

ブラウザ内で完結させるためコードを実行せず、テキストとして解析しています。z.object / z.array / z.union / z.enum / z.literal / z.record と主要なメソッドチェーンには対応していますが、変数に切り出したスキーマの参照や、.refine() のような任意の関数はJSON Schemaに表現できないため無視されます。

JSON Schemaのpatternはz.string().regex()に、逆方向ではその中身がpatternに入ります。JSON SchemaはECMAScript互換でない正規表現も許容するため、そのまま持ち込むと挙動が変わる場合があります。

このツールは移行のたたき台を作るためのものです。業務ルールや値どうしの整合性チェックは元のスキーマに書かれていない限り生成されません。本番のバリデーションに使う前に内容を確認してください。