生成前に用意するJSONサンプル

単一サンプルではなく差分を含む複数サンプルを使う

必須項目を「すべてのサンプルにある項目」で判定するには、通常系だけでなく任意項目なし、null、空配列、異なる配列要素を含む複数の.jsonファイルを読み込みます。貼り付け欄は1件のJSON文書として扱われるため、複数サンプルはファイル入力を使います。

サンプルに現れなかった値は推定できません。数値の範囲、文字列の長さ、許可するenum、追加プロパティの扱い、業務上の必須項目はAPI仕様や利用側の実装と照合します。

formatは文字列の見た目から推定されます。偶然メールアドレスやUUIDに見える識別子もあるため、意図した制約か確認してください。

生成されたJSON Schemaは仕様書の完成版ではなく、手作業を減らすための開始点です。代表サンプル以外の正常系・異常系データでも検証してください。

項目	自動生成できる内容	生成後に人が決める内容
型	object、array、string、integer、number、boolean、null	業務上許可する型、型変換の方針
必須項目	全件・共通・なしの3方式	API契約として本当に必須か
配列	共通itemsまたは位置別tuple	件数、重複、並び順の制約
文字列	UUID、日時、メール、IP、URI等のformat候補	長さ、pattern、formatを検証するか
値の候補	設定を有効にした場合のenum候補	将来値を含む正式な許可値
オブジェクト	propertiesとadditionalPropertiesの選択	$defs/$ref、条件分岐、業務ルール

サンプルから分かるのは観測したデータの構造です。サンプルに現れない正常値・異常値や業務上の契約までは完全に推定できません。

JSON SchemaのDialectや各バリデーターの対応範囲は更新されます。実装へ組み込むときは、利用するDialectを$schemaで明示し、対象ライブラリと連携先サービスの公式資料も確認してください。

注文APIでは、通常注文にだけ存在する配送先、キャンセル時だけ存在する理由、明細が空のケースなどがあります。成功例を1件だけ使うと、任意項目を必須と誤認したり、空配列の要素型を推定できなかったりします。

通常、キャンセル、明細なしの3種類を別々のJSONファイルとして読み込むと、すべてに存在する注文IDだけをrequiredにし、任意項目を残したSchemaの骨格を作れます。

サンプルへ実際の顧客情報や認証情報を入れる必要はありません。構造と値の種類を保ったダミーデータで生成できます。

生成されたSchemaをそのまま本番で使えますか？: 推奨しません。必須条件、数値範囲、文字列長、pattern、enum、additionalPropertiesなどをAPI仕様と照合し、正常系・異常系データで検証してください。
空配列からitemsの型を生成できますか？: 空配列には要素がないため型を確定できません。要素を持つ別サンプルを追加するか、生成後にitemsを手動で指定してください。

入力内容はブラウザ内で処理されます。元データを残したうえで、結果を確認してから保存・共有してください。