JSON→TypeScript変換 | サンプルJSONから型定義を自動生成

APIレスポンスや設定ファイルのJSONを貼り付けると、キーと値から型を推測してTypeScriptのinterfaceまたはtype定義を生成するツール。ネストしたオブジェクトや配列もたどって個別の型に分解し、readonly・全フィールドoptionalの付与まで切り替えられる。

💡 このツールについて

外部APIを叩いて返ってきたJSONに型を付けたいとき、フィールドが20個も30個もあると手でinterfaceを書くのは骨が折れる。ネストが深くなればUserの中のaddress、addressの中のgeo…と子オブジェクトごとに型を切り出す必要があり、写し間違いも起きやすい。

このツールはサンプルのJSONを1つ貼るだけで、その構造から型を起こす。値が文字列ならstring、整数でも小数でもnumber、true/falseはboolean、nullはnull、配列は要素の型に[]を付けて推論する。子オブジェクトはRootの下にAddressのような名前で別定義として切り出すので、ネストが深くても読みやすい形にまとまる。配列がオブジェクトの並びなら、要素の型RootItemを定義したうえでtype Root = RootItem[]のエイリアスを添える。

interfaceとtypeはボタンで切り替えられる。書き換えを禁止したいモデルにはreadonlyを、サーバーが省略しうるフィールドが多いレスポンスには「全フィールドoptional」を付けて?を一括で付与できる。生成された定義はそのままコードへ持っていける下書きとして使える。

🧐 よくある質問

Q. ネストしたオブジェクトはどう扱われますか？ キー名を先頭大文字にした別の型として切り出される。userの中のprofileならProfileという名前で独立した定義が作られ、親の型はそれを参照する形になる。

Q. 配列の型はどう推測されますか？ 最初の要素を見て推論する。[1, 2, 3]ならnumber[]、オブジェクトの配列なら要素型〇〇Itemを定義して配列にする。空配列は型が判別できないためunknown[]になる。

Q. interfaceとtypeはどちらを選ぶべきですか？ 拡張（extends）や宣言のマージを使うならinterface、ユニオンや交差・関数型を含めるならtypeが向く。オブジェクトの形だけを表すこのツールの出力では、どちらでもほぼ同じ。チームの規約に合わせて選べばよい。

Q. 整数と小数で型は変わりますか？ 変わらない。TypeScriptには整数型がなく、1も1.5もすべてnumber。日付やID文字列もstringとして推論されるので、必要なら後からDateやリテラル型に手で絞り込む。

Q. nullが混じったフィールドはどうなりますか？ そのフィールドの値がnullならnull型として推論される。実際には「値が入ることもあればnullのこともある」フィールドが多いので、出力後にstring | nullのようなユニオン型へ手直しすると実用的になる。

📚 豆知識

TypeScriptの型推論は構造的部分型（structural typing）を採用していて、名前ではなく「形が同じか」で互換性を判定する。だからサンプルから起こしたinterfaceの名前が本来のドメイン名と違っても、形さえ合えば代入できてしまう。便利な反面、意味の違う2つの型がたまたま同じ形だと取り違えに気づけない落とし穴もある。実務ではブランド型（type UserId = string & { __brand: 'UserId' }）のような工夫で形だけの一致を防ぐテクニックが知られている。サンプル起こしの型はあくまで出発点で、null許容やリテラル型による絞り込み、日付のDate化などを足して初めて「本番で使える型」になる。