JSONからTypeScript型を自動生成｜配列・null・ネストの型推論
公開日：2026年10月3日 更新日：2026年9月15日 運営：シルギア（Analyzegear, Inc.） 対象ツール：JSON→TypeScript型定義 生成
APIのレスポンスや設定ファイルを扱っていると、手元にJSONはあるのに対応するTypeScriptの型がない、という場面によく出会います。このツールは、貼り付けたJSONをそのまま解析し、値の形から interface または type の定義を自動生成します。処理はすべてブラウザ内で完結し、入力はどこにも送信されません。ここでは何をどう推論しているのか、そして生成結果をどう読み・どう直すのかを、実際の入出力とともに説明します。
「値からの型推論」という考え方
このツールは JSON Schema のような仕様書からではなく、実行時に存在する値そのものから型を組み立てます。仕組みは単純で、値を再帰的にたどりながら、文字列なら string、数値なら number、真偽値なら boolean を割り当て、オブジェクトはネストした名前付きの型に切り出します。JavaScriptの数値に整数と小数の区別がないため、1 も 98.5 も等しく number になります。同様に "vip" のような文字列も string へ一般化され、リテラル型や列挙にはなりません。つまり「この値が取りうる代表的な形」を素早く型にするための道具だと考えると、出力の読み方が分かりやすくなります。
実際のJSONから型を起こしてみる
たとえば次の小さなJSONを入力するとします。id が 1、tags が ["x"]、meta が {"active": true} という3つのキーを持つオブジェクトです。
生成される型はまずルートの interface Root になります。中身は id: number、tags: string[]、そして meta: Meta の3行です。ここで meta の中身は独立した interface Meta として切り出され、active: boolean を持ちます。
注目したいのはネストした型の名前の付け方です。子オブジェクトの型名は、それを保持している親キー名を PascalCase にしたものになります。キー meta なら型 Meta、キー user_profile なら型 UserProfile です。同じ名前が複数現れる場合は Meta2 のように末尾へ連番が付き、必ず一意になります。ルート型名は既定で Root ですが、入力欄の隣で自由に変更できます。
配列・null・ネストの扱い方
配列は要素の型を調べてまとめます。全要素が同じ型なら T[]、複数の型が混ざると (A | B)[] のユニオン配列になります。たとえば [1, "x"] は (number | string)[] です。空配列は中身を判断できないため unknown[] になります。
オブジェクトの配列は特別扱いです。要素ごとに別々の型を作らず、全要素のキーの和集合をとって1つの型へ統合します。たとえば users が [{id:1, name:"a"}, {id:2, name:"b", admin:true}] の場合、生成されるのは Users という1つの型で、全要素にある id と name は必須、一部にしかない admin は admin?: boolean のようにオプション（?）になります。レスポンス配列から代表的な1型を得たいときに役立ちます。
null は既定でユニオンとして表現します。値が常に null のキーは null 単独、他の型と一緒に現れる場合は T | null です。オプションに切り替えると、null を型から外してキー自体を ?（省略可能）にできます。ただし常に null のキーは、本来の型が値からは分からない点に注意してください。
interface と type、どちらを選ぶか
出力形式は interface と type から選べます。生成される中身はほぼ同じで、interface Meta { active: boolean } と type Meta = { active: boolean } の違いです。使い分けの目安を挙げます。
- interface: オブジェクトの形を表すのが主目的で、後から宣言のマージや extends で拡張したいとき。
- type: ユニオンや交差、関数型など、オブジェクト以外の形も含めて別名を付けたいとき。
どちらを選んでも、識別子として使えないキーは自動でクォートされます。たとえば foo-bar や数字始まりの 1st、日本語キーなどは "foo-bar": string; のようにダブルクオートで囲まれ、そのままTypeScriptで有効です。readonly を付ける設定を使えば、各メンバーに readonly を付与した不変の型も作れます。
値からの推論という限界
この方式は手軽ですが、入力したサンプルに現れた値しか型に反映されません。実運用ではもう少し注意が要ります。
- サンプルに一度も出てこないキーは型に含まれません。省略可能なフィールドは、複数パターンを含むJSONを入力しないと ? が付きません。
- ある呼び出しでは値が入り別の呼び出しでは欠けるキーは、本来オプションでも、片方だけのサンプルだと必須と推論されます。
- 整数・小数の区別や、日付文字列・列挙のような意味づけは復元できません。すべて number や string に一般化されます。
つまり生成結果はあくまで下書きです。代表性のあるJSON（キーが揃った複数要素の配列など）を入力し、生成後に手で調整するのが確実です。
こんな場面で使う
いちばん相性が良いのは、外部APIのレスポンスから型を起こす作業です。ドキュメントに型が載っていないAPIでも、一度レスポンスをそのまま貼り付ければ interface の雛形がすぐ手に入ります。ほかにも、設定ファイルのJSONを型で受けたいとき、モックデータから型を用意したいとき、他人が書いたJSONの構造をざっと把握したいときにも便利です。処理は端末内で完結するため、社外に出せないレスポンスでも安心して試せます。生成した型をコピーして貼り付け、必要な箇所だけ手直しする、という流れが基本になります。