JSON→TypeScript変換

JSONの値から型宣言を組み立てる

このツールは、入力したJSONサンプルを読み取り、値の形に合うTypeScriptの型宣言を生成します。文字列は string、数値は number、真偽値は boolean、配列は要素の型を持つ配列として表し、ネストしたオブジェクトには関連する型を作ります。初期設定では Root という名前のinterfaceを出力し、設定を変えるとtype aliasにも切り替えられます。

たとえば {"id":42,"name":"Aoi","roles":["editor"]} を入力すると、id は number、name は string、roles は string[] と推定されます。JSONの null はキーがない状態とは異なり、値として扱われます。型宣言は入力されたサンプルからの推定結果であり、まだ観測していないAPI応答の形まで確定するものではありません。

似た名前でも意味が違う型を確認

interface とオブジェクト形式の type は、どちらもオブジェクトのプロパティとその型を記述できます。既定ではinterface形式ですが、設定からtype alias形式を選べます。配列に複数種類の値が含まれる場合は、要素型を union（たとえば string | number）で表すことがあります。オブジェクト配列のサンプル同士でキーが揃わない場合、見つからないキーが任意プロパティになることもあります。

任意プロパティの name?: string は「キー自体がない場合がある」ことを表します。一方、name: string | null は「キーはあり、値が文字列またはnull」という意味です。この区別は、呼び出し側で値を扱うときに役立ちます。

サンプルにない契約までは推測できない

空配列には要素の手掛かりがないため、オブジェクトのフィールドが空配列だけなら広い型として出力される場合があります。値の違う複数サンプルを用意すると、unionや任意プロパティを推定する材料が増えます。日付らしい文字列は推論設定により Date として扱われる場合がありますが、JSON上の値は文字列です。アプリ側で文字列を日付オブジェクトへ変換していないなら、生成後に型を見直してください。

貼り付けて型を整える手順

1. JSONサンプルを用意する

   APIレスポンスや設定ファイルから、代表的なJSONをコピーします。コメント、末尾カンマ、引用符のないキーなど、JavaScriptオブジェクト特有の記法は取り除いてください。複数の状態で値やキーが変わる場合は、その違いが分かるサンプルも準備します。

2. 入力して構文を確認する

   JSON入力欄に貼り付けます。「サンプル」で例を読み込み、「フォーマット」でインデントを整えられます。無効なJSONではエラーが表示され、変換結果は空になります。

3. 型名と出力設定を選ぶ

   型名を Root から UserResponse など用途の分かる名前に変更します。既定の型定義のみの出力を使うか、詳細設定でinterface/type aliasや日時推論、プロパティ名の扱いなどを調整します。

4. 結果を見直して持ち出す

   出力欄で入れ子の型、union、任意項目、null、空配列の表現を確認します。問題がなければコピーするか、型名をもとにした .ts ファイルをダウンロードします。

入力と推論について

JavaScriptのオブジェクトを貼ったらエラーになりますか？

JSONとして解析するため、キー名と文字列は二重引用符で囲み、コメント、undefined、関数、末尾カンマは使えません。真偽値とnullは小文字で true、false、null と記述します。

空配列の要素型が決まらないのはなぜですか？

[] には要素の値がないため、要素型を推定する根拠がありません。空配列を含むフィールドが広い型になったら、実際の値を含む代表サンプルを追加して結果を比べ、必要な型へ調整してください。

nullと任意プロパティは同じ扱いですか？

異なります。string | null は値としてnullを許し、name? はそのキーが存在しない場合を許します。実データでどちらが起きるかに沿って宣言を確認してください。

生成した型だけで受信データの検証もできますか？

型定義だけでは、実行時に外部から届いたJSONがその形かを検査しません。出力オプションで実行時チェック用の関数を含められる場合もありますが、生成内容を確認し、実際の入力に対する検証やエラー処理を別途実装してください。

採用前に確かめたいこと

生成結果は入力サンプルからの型推定であり、APIの完全な仕様書やデータ検証の代わりにはなりません。

• 複数の状態を含める：一つの例だけでは、任意キー、null、値の分岐、エラー応答などが抜けることがあります。正式な契約や複数の実例と照合してください。
• 名前の変更設定に注意：プロパティ名の最適化を使うと、生成宣言上の名前が元のJSONキーと異なることがあります。ランタイム値のキーまで自動変換されるわけではないため、読み取り側との対応を確認します。
• 静的型と実行時の値は別：interfaceやtype aliasを書いても、受信データ自体は変換されず、その宣言だけで妥当性も検査されません。必要ならパーサー、変換処理、実行時検証を用意します。
• 機密情報を避ける：本番データを貼る前に、トークン、個人情報、秘密値を架空の値へ置き換えてください。