JSON → TypeScript ジェネレーター

型推論ルール

• null → 省略可能な null（field?: null）
• 文字列 → string
• 数値 → number
• 真偽値 → boolean
• 空配列 → unknown[]
• オブジェクト配列 → マージされたインターフェース + ItemName[]
• 混合プリミティブ配列 → Union型（例: (string | number)[]）
• ネストオブジェクト → 独立した名前付きインターフェース

例

以下のJSONを入力すると:

{"user": {"name": "Alice", "age": 30}, "tags": ["admin", "user"]}

次のように生成されます:

interface RootObject {
  user: User;
  tags: string[];
}

interface User {
  name: string;
  age: number;
}

例：API レスポンス

{
  "user": {
    "id": 42,
    "name": "Alice",
    "email": "alice@example.com",
    "roles": ["admin", "editor"],
    "preferences": { "theme": "dark", "notifications": true },
    "lastLogin": null
  },
  "pagination": { "page": 1, "perPage": 20, "total": 143 }
}

から次の型が生成されます。

interface RootObject {
  user: User;
  pagination: Pagination;
}

interface User {
  id: number;
  name: string;
  email: string;
  roles: string[];
  preferences: Preferences;
  lastLogin?: null;
}

interface Preferences {
  theme: string;
  notifications: boolean;
}

interface Pagination {
  page: number;
  perPage: number;
  total: number;
}

ルートのインターフェースが先頭に来て、ネストしたインターフェースは見つかった順に続きます。null の値は型 null として出力され、省略可能になります。1つのサンプルからは値があるときの型がわからないためです。API ドキュメントを確認して lastLogin: string | null のように直してください。

例：形の異なる要素を含む配列

{
  "items": [
    { "id": 1, "name": "a", "tags": [] },
    { "id": 2, "price": 9.5, "tags": ["x", 1] }
  ],
  "messages": [
    { "type": "text", "content": "hi" },
    { "type": "image", "url": "/a.png" }
  ]
}

から次の型が生成されます。

interface RootObject {
  items: ItemsItem[];
  messages: MessagesItem[];
}

interface ItemsItem {
  id: number;
  name?: string;
  tags: (unknown[] | (string | number)[]);
  price?: number;
}

interface MessagesItem {
  type: string;
  content?: string;
  url?: string;
}

配列内のオブジェクトはすべてマージされ、一部の要素にしかないキーには ? が付きます。messages は実際には type で区別される2つの形です。マージ後のインターフェースは「url を持つ text メッセージ」のような不正な組み合わせも通すので、判別可能なユニオン型に書き直します（TypeScript Handbook: Narrowing）：

type Message =
  | { type: "text"; content: string }
  | { type: "image"; url: string };

例：同じキー名のオブジェクトが 2 つある場合

{
  "order": { "id": "A-1001", "meta": { "createdBy": "alice", "source": "web" } },
  "payment": { "status": "paid", "meta": { "provider": "stripe", "fee": 0.3 } }
}

から生成される型：

interface RootObject {
  order: Order;
  payment: Payment;
}

interface Order {
  id: string;
  meta: Meta;
}

interface Meta {
  createdBy: string;
  source: string;
}

interface Payment {
  status: string;
  meta: PaymentMeta;
}

interface PaymentMeta {
  provider: string;
  fee: number;
}

order.meta は Meta という名前になります。payment.meta はフィールドが違うので別のインターフェースになり、親の名前を前に付けた PaymentMeta になります。order.meta と同じフィールドなら、両方とも Meta を共有します。2 つをすべて省略可能なフィールドの Meta にまとめると、どちらの API も返さないオブジェクトまで受け入れてしまうため、形ごとに型を分けています。名前がまだ使われている場合は番号を付けます（Meta2）。ネストしたキーがルートと同じ名前でも、ルートは指定した名前のままです。

手で直すところ

• null のフィールド：?: null を実際の型と | null に置き換えます。
• 空配列：[] は unknown[] になるので要素の型を補います。
• 日付：ISO 8601 文字列と Unix タイムスタンプはそれぞれ string・number のままです。
• 識別子として使えないキー（user-name、2fa）は引用符付きで出力されます。TypeScript として有効です。
• PaymentMeta や Meta2 のような名前は JSON のキーから作られます。用途に合わせて名前を変えてください。
• 有効な型名にならないキー（2fa、空のキー）は、インターフェース名の先頭に T を付けます（T2fa）。プロパティ自体は元のキーを引用符付きで使います。

制限

• 入力は有効な JSON である必要があります（コメントや末尾のカンマは不可）。エラーメッセージに位置が表示されます。
• 型は貼り付けたサンプルだけから決まります。サンプルでは文字列でも本番で数値になることがあるフィールドは string のままです。
• interface の代わりに type を使用を選ぶと、各宣言は type Name = { ... } になります。