型生成

JSONからTypeScriptレスポンスの違いが見える型定義へ

サンプルのtagの欠落とscoreのnullを比べてください。契約がある場合はSchema補助モードを選べます。

JSONからTypeScript

JSON入力

解析と生成はこのブラウザー内で行い、入力は送信・保存しません。

TypeScript出力

生成設定

欠落したフィールドは省略可能に、nullはそのまま、空配列はunknown[]になります。strictNullChecksの利用を推奨します。

3宣言・省略可能なプロパティ1件

JSONからTypeScriptへの変換では、たまたま取得した一件をAPI全体の仕様だと考えないことが大切です。フィールドが省略されるケースや値の種類が変わるケースも配列に含めると、見落としを減らせます。

このページでは、値が空であることとプロパティが存在しないことを別々に表現します。生成した型はレビューの出発点です。まだ観測していないレスポンスや業務上の条件については、API仕様と照合してください。

JSONからTypeScriptに変換する理由

配列全体から省略を見つける

JSONからTypeScriptへの型生成は配列の先頭だけでなく全要素を使います。一部のレコードにtagがなければ省略可能に、scoreが数値とnullならユニオン型になります。異なる意味を同じ設定で置き換えません。

二つのレコードを型へまとめ、欠落した欄を破線、明示的なnullを空のマーカーで示す図。

サンプルにない情報を契約で補う

Schemaには必須プロパティやenumの候補を指定できます。入力モードを明示してから使ってください。未対応の制約はパスを示して停止するので、制約を無視した型を完成品として渡すことはありません。

サンプルと構造の契約が別々の経路から型宣言のカードへつながる図。

型を使う前に確認すること

01

比較するレコードを同じ配列に入れる

複数の入力を連結するのではなく、一つのJSON配列にまとめます。同じ構造位置のオブジェクトを比較するため、別の場所にある同名のプロパティまで同一モデルにはなりません。

02

入力モードとサンプルを揃える

モード変更は入力を消しません。「サンプル」は選択中のモードに合う内容を読み込みます。Schemaではrequiredを使い、サンプル用の全項目を省略可能にする設定は無効になります。

03

変更後の結果を確認する

自動生成は編集後350ミリ秒待って実行します。オフにすると生成ボタンが現れ、Ctrl/Cmd+Enterも使えます。入力や設定が変わるとコピーとダウンロードを無効にし、最新の生成が成功してから再開します。

値の違いを宣言に反映

配列の要素型を集める

数値と文字列が混ざればユニオン型にします。ネストした配列も調べ、空配列と要素のある配列が同じ位置にあれば既知の要素型を採用します。まったく手掛かりがなければunknown[]です。固定長タプルは作りません。

省略可能とnullを分ける

一部のオブジェクトに存在しないフィールドには?を付けます。nullは実際の値として残し、それしかなければ型もnullです。プロジェクトのstrictNullChecksを有効にすると、この違いが型チェックに反映されます。

プロパティ名を変えずに型へ

インターフェース自動生成ではRootを起点にネストした宣言名を作り、衝突時には数字を付けます。空白やハイフンのあるキーは引用符で保持します。ルート名は予約語を除く64文字以内のASCII識別子です。

明示的な契約も入力できる

TypeScript型生成の補助入力は、基本型、properties、required、単一items、真偽値additionalProperties、スカラーenum/const、限定的なanyOfに対応します。JSON型定義の宣言形式、export、2文字または4文字の字下げを選べます。

推論の範囲と扱わないもの

サンプルから推測しない情報
日付やUUIDらしい文字列もstringのままです。文字列から列挙型を推測せず、配列オブジェクトをフィールド単位でまとめるため、判別用の値と他のフィールドの組み合わせも保持しません。未観測の変体は追加して確認してください。
実行時の検証コードは出さない
出力は静的な宣言です。パーサー、クラス、Zod、シリアライザーは生成しません。integerはnumberとなり、整数や精度を保証しません。additionalProperties=falseも実行時に余分なプロパティを拒否する仕組みではありません。
Schemaは明記した部分だけ
参照、定義、oneOf/allOf、条件、format、パターン、長さ、範囲、タプルなどはエラーになります。オブジェクトや配列用のキーワードには明示的なtypeが必要です。追加プロパティのSchema、複合値のenum、安全な大きさを超える数値リテラルも扱いません。
厳密な単一JSONを入力する
コメント、末尾カンマ、重複キー、JSONLは拒否します。構文エラーは行と列を表示します。自動修復、URL取得、ファイル取込、一括変換はありません。普通のデータにtypeがあってもSchemaとは自動判定しません。
上限を超えたら途中結果を渡さない
入力500,000文字、深さ100、50,000ノード、出力1,000,000文字、1,000宣言までです。超過した結果はコピーできません。フィールドの証拠がない空オブジェクトには、広すぎる{}ではなくunknownのインデックスシグネチャを使います。

JSONからTypeScriptへの変換に関する質問

日付の文字列をDate型として推論しますか?

いいえ。日付らしいテキストもstringです。JSONにDateオブジェクトは存在しないため、実行時にDateへ変換する処理を別に書かずに型だけ変えると、実際の値と型が食い違います。

interfaceとtypeはどちらを選べばよいですか?

プロジェクトの宣言方針に合わせて選べます。interfaceはオブジェクト宣言に使われます。配列、基本型、ユニオンがルートの場合は、interfaceを選んでも外側にはtype別名が必要です。

省略可能なフィールドとnullはどう型付けされますか?

一部のレコードで欠落していれば?、値がnullならnullを含む型です。JSONからTypeScriptへの変換では、nullを省略可能へ勝手に置き換えません。数値とnullがあればnumber | nullになります。

TypeScriptの型は実行時にJSONを検証しますか?

宣言はJavaScriptの実行時には残りません。型アサーションを使っても外部入力の安全性は確認できないので、受信時には用途に合う検証処理を別に用意してください。

この型をAPI全体の正しい仕様として使えますか?

入力したサンプルの範囲では参考になりますが、API全体を保証しません。省略やエラーのケースも追加し、必要なら明示的なSchemaとAPI文書を確認してから採用してください。

推論結果で気になる点がありますか?

複数のレスポンスで試す

JSONからTypeScriptへの変換に複数の応答例を渡し、省略可能なフィールドとnullを確認してから、宣言をプロジェクトへ持ち帰りましょう。