JSON→TypeScript型定義変換

JSONオブジェクト(またはJSON配列)を貼り付けると、対応するTypeScriptのinterface/type定義を自動生成します。

JSONからTypeScriptの型定義を作る

API のレスポンスを TypeScript で受け取るとき、まず必要になるのが型定義です。しかし入れ子の深い JSON を見ながら `interface` を手で書き起こすのは骨が折れますし、**プロパティの書き落としや型の取り違えが起きやすい作業**でもあります。このツールは JSON を貼り付けるだけで、対応する `interface`/`type` を自動で生成します。

生成では、値の JavaScript 上の型から TypeScript の型を推定します。**入れ子のオブジェクトは別の interface として切り出し**、配列は要素の型から `T[]` を導きます。ルート型の名前は自由に指定できるので、生成物をそのままプロジェクトへ貼り付けられます。**推定はあくまで貼り付けたサンプルに基づくため、省略されうるプロパティや `null` を取りうる項目は、生成後に `?` や union 型を自分で足してください。** 処理はすべてブラウザー内で完結します。

型定義を生成する手順

  1. JSON を貼り付ける API のレスポンス例などをそのまま入力します。オブジェクトでも配列でも構いません。
  2. ルート型の名前を決める 生成される最上位の interface 名になります。既定のままでも構いません。
  3. 生成結果を確認する 入れ子のオブジェクトは別の interface として切り出されて並びます。
  4. 省略可能な項目を手で補う **サンプルに現れない項目は推定できません。** `?` や `| null` は自分で足してください。
  5. コピーしてプロジェクトへ貼る そのまま `.ts` ファイルへ貼り付けられます。

使いこなすためのヒント

  • 配列の要素がすべてオブジェクトの場合、各要素のキーをマージして1つのインターフェースを生成します。要素によって存在しないキーは自動的にオプショナル(`?`)として扱われます。
  • ルート型の名前は初期値「Root」からお好みの名前(例: `User`・`ApiResponse`)に変更できます。ネストしたオブジェクトのインターフェース名は、そのプロパティ名から自動生成されます。
  • API レスポンスのサンプルJSONをそのまま貼り付ければ、フロントエンド実装で使う型定義のたたき台として素早く活用できます。
  • 生成されるのはあくまで構造から推論した型のたたき台です。実際のAPI仕様(nullable・必須項目等)と照らし合わせて手動で調整することをおすすめします。

こんなときに使えます

外部 API の型を用意する

ドキュメントに型定義が無い API でも、レスポンス例さえあれば出発点を作れます。

既存の JSON 設定ファイルに型を付ける

設定ファイルを型安全に読み込みたいとき、構造をそのまま型へ落とせます。

モックデータから型を起こす

フロントエンドを先に作る場面で、仮のデータから型を用意できます。

型の書き漏らしを検算する

手で書いた型定義と、生成された型を見比べて抜けを探せます。

TypeScript の用語

interface
オブジェクトの形を表す宣言です。**同名で複数回宣言すると自動的に合成される**点が type との違いです。
type エイリアス
任意の型に名前を付ける宣言です。union 型やプリミティブにも名前を付けられます。
省略可能プロパティ
`name?: string` のように `?` を付けた項目です。**貼り付けたサンプルからは推定できません。**
union 型
`string | null` のように、複数の型のいずれかを取りうることを表します。
入れ子オブジェクト
値がさらにオブジェクトになっている構造です。本ツールは別の interface として切り出します。
型推論
値から型を導くことです。**ここでの推論は貼り付けた1件のサンプルに基づくため、実際の API 仕様とは限りません。**

よくある質問

APIレスポンスのサンプルJSONから手作業で型定義を書き起こすのは時間がかかり、キー名の書き間違いや型の見落としが起きやすい作業です。自動生成することで、フロントエンド開発者が型定義作成にかかる時間を大幅に短縮でき、記述ミスも防げます。

配列内のすべての要素のキーをマージし、一部の要素にしか存在しないキーは自動的にオプショナルプロパティ(`?`)として扱われます。また同じキーでも要素によって型が異なる場合は、ユニオン型(`string | number`等)として表現されます。

生成される型定義は、あくまでサンプルJSONの構造から機械的に推論したものです。実際にはnull許容(nullable)かどうか・将来追加される可能性のあるフィールドなど、サンプルJSONだけでは判断できない情報があるため、API仕様書と照らし合わせて手動で調整することをおすすめします。

ネストしたオブジェクトのインターフェース名は、そのオブジェクトが格納されているプロパティ名から自動生成されます(例: `profile` というキーのオブジェクトは `Profile` という名前のインターフェースになります)。同名で異なる形状のインターフェースが必要になった場合は、末尾に連番を付けて区別します。
ツールくん

余談ですが ― 型推論ツールが解決する「型のズレ」問題

TypeScriptは静的型付けによってコンパイル時にバグを発見できる言語ですが、外部APIから受け取るJSONデータの型は、開発者が手動で定義しない限りTypeScriptコンパイラには分かりません。API仕様書とサンプルレスポンスに食い違いがあったり、フィールドが追加・削除されたりするたびに手動で型定義を更新する必要があり、この「型定義とAPIの実態のズレ」は多くのフロントエンドプロジェクトで悩みの種になってきました。

JSON→TypeScript変換ツールは、実際に返ってきたサンプルJSONから機械的に型を逆算することで、この作業を大幅に効率化します。同種のツールとしては quicktype(複数言語の型定義を生成できるオープンソースツール)が有名で、JSON Schema・GraphQLスキーマなど様々な入力形式にも対応した高機能な実装で知られています。

型推論の難しさは、JSON自体には「このフィールドは常に存在するのか」「将来nullになり得るのか」といった情報が含まれていない点にあります。そのため自動生成された型定義は万能ではなく、あくまで「今回のサンプルデータの構造」を反映したたたき台として扱い、実際のAPI仕様と照らし合わせて調整するのが実務上の定石とされています。