search

Found

info 概要

JSON Schema (draft-07 / 2019-09 / 2020-12) とインスタンスを貼り付けて検証し、各エラーを JSON Pointer のパス・キーワード・メッセージ表で一覧化

📘 使い方

  1. ドラフト (draft-07 / 2019-09 / 2020-12) を選ぶ
  2. JSON Schema を上の枠に貼り付け
  3. 検証対象の JSON インスタンスを下の枠に貼り付け
  4. 結果カードとエラー表で違反箇所を確認

JSON Schema バリデーター

待機中
Schema とインスタンスを貼り付けると検証が走ります。

※ JSON Schema のコアキーワード (type / required / enum / const / properties / items / allOf / anyOf / oneOf / not など) に対応。$ref / $defs、dependentSchemas、contains、if/then/else、unevaluatedProperties/Items は解決しません。

Article

JSON Schema バリデーター | draft-07 / 2019-09 / 2020-12 を切替できるブラウザ内 validator

API のレスポンスや OpenAPI から切り出した断片を JSON Schema で検証するための軽量ツール。3 つの主要ドラフトをワンクリックで切り替えながら、エラーを JSON Pointer 形式のパス・キーワード・メッセージで一覧表示する。

💡 このツールについて

JSON Schema は API 契約・設定ファイル・フォーム入力など「どんな構造の JSON を許すか」を宣言的に書くための仕様で、OpenAPI / Swagger / GraphQL ベンダー拡張・JSON-LD など多くのエコシステムで採用されている。とはいえ実務でハマりやすいのは「Schema 単体は読めても、特定インスタンスがどの keyword でコケるか」を素早く突き止めるところ。ajv-clinpm i -g するほどでもないが、エディタ拡張だと依存切り替えが面倒、というレビュー直前のチェックに使える。

このツールは draft-07 / 2019-09 / 2020-12 の 3 ドラフトを切替トグルで指定でき、ネイティブ JSON.parse でパース後に subset の validator を回す。エラーは instancePath(JSON Pointer)+ keyword + 日本語メッセージの 3 列で表示され、深い properties ネストでもどこで何が外れたかが一目で分かる。「最初の 1 件で止める」モードを併用すれば、巨大 schema の早期 fail デバッグも素早く回せる。

カバーしている keyword は type / required / enum / const / minLength / maxLength / pattern / minimum / maximum / exclusiveMinimum / exclusiveMaximum / multipleOf / minItems / maxItems / uniqueItems / prefixItems / items / minProperties / maxProperties / additionalProperties / patternProperties / format (subset) / allOf / anyOf / oneOf / not / false schema など主要なコア機能。一方で $ref / $defs の参照解決、dependentSchemascontainsif/then/elseunevaluatedProperties / unevaluatedItems解決しない ため、これらに依存する schema を貼ると一部 keyword が黙って素通りする。複雑なリファレンス込みの schema は ajv 等の完全実装に回す前段の sanity check として位置付けるのが安全。

🧐 よくある質問

Q. ドラフトを切り替えると挙動はどう変わりますか? 2020-12 では items が単一スキーマのみ意味を持ち、配列指定は prefixItems に分離されている。当ツールは prefixItems を 2020-12 想定で実装しつつ、2019-09 / draft-07 でも array-items を従来通り受け付ける。exclusiveMinimum / exclusiveMaximum は draft-07 以降すべて数値として扱う。

Q. format チェックの精度はどの程度ですか? email / uri / url / uuid / date / time / date-time / ipv4 / ipv6 / hostname を内蔵正規表現で軽くチェックする subset 実装。RFC 完全準拠ではないので、uuid の variant ビット精査や date-time の閏秒解釈などは厳密にしたいなら ajv-formats を併用する。

Q. $ref を含む schema を貼っても動きますか? parse 自体は通るが、$ref 先のスキーマは展開されないため、参照先の制約は適用されないまま valid と判定される可能性がある。$ref の解決が必要な検証は ajv などの完全実装を使うのが安全。

Q. エラーが多すぎて読みにくい場合は? 「エラー収集」を「最初の1件」に切り替えれば、最初に見つかった違反だけ返す early-exit モードで動く。深いネストの schema でどの keyword から崩れているかを段階的に追える。

Q. 何件まで貼り付けて検証できますか? 明示的な上限は設けていない。ただし JSON.parse 時点でブラウザのメモリと CPU を消費するため、数 MB クラスの巨大インスタンスは CI / バックエンドの ajv に回す方が現実的。1 リクエスト分の payload や fixture 単位の検証に向く。

Q. 検証結果のテーブルを再利用したいです。 エラー表の下の「コピー」ボタンで instancePath / schemaPath / keyword / message を含む JSON 配列がクリップボードに入る。GitHub Issue・PR コメント・テストレポートにそのまま貼れる。

📚 豆知識

JSON Schema の歴史をたどると、draft-04 (2013) → draft-06 (2017 春) → draft-07 (2017 末) → draft-2019-09 → draft-2020-12 と、命名が「番号」から「年月」に切り替わっている。これは IETF Working Group が「draft」という単語を「未完成」ではなく「リビジョン番号」として扱う方針を明確化したため。実務上は「最新版を追えば良い」というよりも「自社が依存する OpenAPI ツールチェーンが対応している draft」を選ぶのが正解で、AWS SAM・Stripe API・Cloudflare API ドキュメントなどは draft-07 にロックしているケースが多い。

国内では JSON Schema をデータバリデーション目的だけでなく、フォーム自動生成 (@rjsf/corevue-form-generator) や設定ファイルの IntelliSense 補完 (VS Code の json.schemas) に活用するパターンも増えている。description / examples / default などの註釈系 keyword は validation には影響しないが、エディタ補完では強力な UX 要素になる。