JSON to TypeScript
JSONデータをTypeScriptインターフェースまたは型定義に自動変換
// JSON入力後、TypeScript型定義が自動生成JSON to TypeScriptとは？
JSON to TypeScript は、JSON の構造を解析して TypeScript の interface や type 定義を生成するツールです。API レスポンス、設定ファイル、サンプルペイロード、モックデータを型付きのフロントエンドや Node.js プロジェクトに素早く取り込むときに役立ちます。オブジェクト、配列、ネストしたプロパティ、任意フィールド、基本型を推測し、補完やコンパイル時チェックの出発点を作れます。ただし、人による確認は必要です。1 つの JSON 例には全フィールドが含まれないことがあり、空配列は要素型を示さず、実際の API は null や複数パターンを返す場合があります。
使い方
使い方
- 左の入力ボックスにJSONデータを貼り付けるか、サンプルボタンをクリックしてサンプルを読み込みます
- オプションを設定します：ルート型名の指定、interface/typeスタイルの選択、exportの追加有無など
- 右側に対応するTypeScriptの型定義が自動生成されます
- 「コピー」ボタンをクリックして生成された型定義をクリップボードにコピーします
- TypeScriptプロジェクトに型定義を貼り付けて使用します
型生成のヒント
- 代表的なJSONサンプルを使用してください。1つのサンプルだけでは、実際のAPIのすべてのオプショナルフィールド、nullable値、union型を網羅できない場合があります。
- コミット前に生成された名前を確認してください。特にネストされたオブジェクトでは、自動生成されるインターフェース名が一般的すぎる可能性があります。
利用シーン
仕組み
JSON to TypeScriptは基本的に「構造推論」プロセスです。ツールはJSONツリーの各ノードを再帰的に走査し、各値のランタイム型をTypeScript型にマッピングします：string → string、number → number、boolean → boolean、null → null、object → サブinterface、array → 要素型の配列。出力はTypeScriptの`interface`宣言（または「type」出力モード選択時は`type`エイリアス）のセットと、オブジェクト値フィールドから抽出されたネストされたinterfaceで構成されます。 推論の難所は配列におけるunion型と単一型の判断です。配列のすべての要素が同じ型の場合、出力は`T[]`（同次配列）です。要素が異なる型を持つ場合、それらの型のunionが出力されます：`[1, 'a', true]`は`(number | string | boolean)[]`となります。入力がリテラル値と構造化された値が混在するオブジェクト（例：`{ id: 1, name: 'Alice', tags: ['admin', 'editor'] }`）の場合、各フィールドは独自の型を持ちます。プリミティブ値が混在するオブジェクトでは、ページはunionではなく単一のinterfaceを出力します。これはTypeScriptコードが期待するものであり、JSONオブジェクトがレコード型としての性質を持つことに対応します。 複数のサンプルオブジェクト（典型的なユースケース：JSON配列を貼り付ける）は、形状の交差によってマージされます。すべてのサンプルに存在するフィールドは必須となり、いずれかのサンプルで欠けているフィールドはオプション（`fieldName?: T`）となります。これはAPIレスポンスにとって正しい振る舞いです。200 OKレスポンスは1つの形状、404レスポンスは別の形状であり、両者のunionが正しいTS型となります。単一サンプルの場合、すべてのフィールドが必須です。 名前の正規化は、多くの「JSON to TS」ツールが不十分な箇所です。JSONキーは通常snake_case（`user_id`、`created_at`）またはcamelCase（`userId`、`createdAt`）です。TypeScriptの慣例ではinterface名はPascalCase（`UserProfile`、`AuditEntry`）、プロパティ名はcamelCaseです。ページはJSONキーをcamelCaseに変換し（すでにcamelCaseまたは単語の場合はそのまま保持）、interface名はPascalCaseに変換します。内部オブジェクトは名前付きinterfaceとして抽出されます：`{ user: { name, age } }`は`interface User { name: string; age: number; }`となり、親は`interface Root { user: User; }`となります。再帰構造（`children: TreeNode[]`フィールドを持つツリーノード）は、サイクルを明確にするために`interface`ではなく前方`type`宣言を使用した自己参照となります。 「ルート」トグルは配列ルートとオブジェクトルートの違いです。JSON配列はwrap-arrayトグルに応じて`type Root = Item[]`または`interface Root { items: Item[]; ... }`となります。JSONオブジェクトはトップレベルでフラットなinterfaceになります。日付文字列（RFC 3339 / ISO 8601）は`string`ではなく`Date`としてタグ付けでき、UUID、メール、URLはstrictモードトグルがオンの場合にブランド型（`type UUID = string & { readonly __brand: 'UUID' };`）としてタグ付けできます。 JSDocの生成はヒューリスティックです。`email`という名前のフィールド（値が基本的なメール正規表現に一致する場合）には宣言の上に`/** user email */`のようなコメントが付きます。`id`、`name`、`url`、`created_at`/`createdAt`、`updated_at`/`updatedAt`、`description`、`title`も同様です。コメントはベストエフォートであり、人間が書いたものとは見なされません。人間が編集するための出発点です。ページは出力をそのまま任意のTSファイルに配置できるよう`export`修飾子も出力し、スキーマ再生成時に手動編集が上書きされることを防ぐための`// generated by json-to-typescript, do not edit by hand`ヘッダーも含みます。
- アトミック型マッピング：JSONのstring/number/boolean/nullはTypeScriptのstring/number/boolean/nullに1対1でマッピング。大きな整数（>2^53）はBigIntが必要で、値がNumber.MAX_SAFE_INTEGERを超える場合ページは`bigint`としてタグ付けする。
- 配列型推論：すべての要素を走査して型のunionを取る。同一型は`T[]`に畳み込まれ、異なる型は`(A | B | C)[]`を形成。空配列は要素型が不明なため`unknown[]`となる。
- ネストされたオブジェクトの抽出：内部オブジェクトは自動的に名前付きinterfaceとしてリフトアップされる。再帰構造はTypeScriptの型チェッカーで前方参照が明確になるよう`type Name = ...`（`interface`ではなく）を使用。
- オプショナルフィールド検出：複数のサンプルオブジェクトをマージする際、すべてのサンプルに存在するフィールドは必須、いずれかのサンプルで欠けているフィールドはオプション（`fieldName?: T`）となる。単一サンプル入力ではすべてのフィールドが必須と标记される。
- 命名規則：JSONキーはプロパティ名としてcamelCaseに変換（user_id → userId、created_at → createdAt）、interface名はPascalCaseに変換（UserProfile、AuditEntry）。単語のキーはそのまま保持。キー内の数字は保持。先頭が数字の場合は有効なTS識別子となるようアンダースコアをプレフィックス。
- ルートトグル：配列ルート → `export type Root = Item[]`（wrap-arrayオンの場合は`{ items: Item[]; }`でラップ）。オブジェクトルート → 単一の`export interface Root { ... }`。再帰構造はまずスタブの前方宣言を受け取る。
- JSDocコメント：既知のフィールド名（email、id、name、url、createdAt、updatedAt、description、title）に対するヒューリスティックなコメント生成。出力には`export`修飾子と手動編集を抑止する`// generated, do not edit by hand`ヘッダーが含まれる。
- strictモード：ブランド型（UUID、Email、URL、Date）、readonly修飾子、exactOptionalPropertyTypes、noUncheckedIndexedAccessへのオプトイン。strictモードがオンの場合、ページは`type UUID = string & { readonly __brand: 'UUID' };`を出力し、ダウンストリームコードが生の文字列と型付き値を区別できるようにする。
使用例
シンプルなオブジェクトを interface に変換
{"id": 1, "name": "Alice", "active": true}
->
interface User {
id: number;
name: string;
active: boolean;
}ネストしたオブジェクトからサブ interface を生成
{"user": {"name": "Alice", "address": {"city": "NYC"}}}
->
interface Root {
user: User;
}
interface User {
name: string;
address: Address;
}
interface Address {
city: string;
}配列を readonly タプルに変換
[{"id": 1}, {"id": 2}]
->
interface Item {
id: number;
}
type Root = readonly Item[];よくある質問
どのような TypeScript 構造を生成しますか？
デフォルトでは interface を生成し、オブジェクトの形ごとに 1 つ作成します。任意のフィールドには ? マーカーを使用します。配列は T[] になります。型が混在する配列は和集合になります。認識可能なフォーマット (例えば ISO 日付) の文字列は、ブランド型を選択しない限り string のままです。一部のページでは 'interface' の代わりに 'type' エイリアスを提供します。
ネストされたオブジェクトはどう処理されますか？
それぞれ異なるネスト構造ごとに、プロパティパスにちなんだ名前 (User、UserAddress、UserPreferences) の独自インターフェースが生成されます。2 つのプロパティが同じ形を共有する場合、ジェネレータが重複排除するかは設定次第です。出力を確認し、必要に応じて手動で統合してください。
プロパティは必須ですか、任意ですか？
デフォルトでは、サンプルに存在するプロパティは必須としてマークされます。一部の配列要素にあって他の要素にはないプロパティは、`?` 付きで任意としてマークされます。サンプルが多くのありうる形のうちの 1 例である場合は、「すべて任意」を切り替えてください。
null と undefined はどう扱われますか？
JSON の null は TypeScript の `null` (undefined ではない) になります。文字列のときも null のときもあるプロパティは `string | null` となります。JSON には undefined が存在しないため、ジェネレータが直接 `undefined` を出力することはありません。
ユニオン型や判別可能ユニオンはどうですか？
配列に複数の異なるオブジェクト形が含まれている場合、ジェネレータはインターフェースのユニオンを出力します。判別子フィールドは自動検出しません。網羅的な型絞り込みが必要な場合は、判別可能ユニオン (例えば 'kind' タグ) として手動で書き換えてください。
JSON はアップロードされますか？
いいえ。変換は JS ベースの JSON パーサーと文字列テンプレートを使用してブラウザ内で実行されます。貼り付けた JSON は端末から送信されません。
バックエンドが実際に返すものと一致しますか？
サンプルの精度に応じてのみ一致します。常にスキーマ (Zod、io-ts、Yup) でランタイムデータを検証してください。TypeScript の型はランタイムで消去されるため、バックエンドが例から逸脱しても捕捉できません。