JSON Schema 検証ツール

例：住所フォームの郵便番号

日本の住所のときだけ郵便番号と都道府県を必須にする、よくある if / then の書き方です。IME で入力したまま送られてきたデータを検証します。

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "required": ["country", "name"],
  "properties": {
    "country": { "enum": ["JP", "US"] },
    "name": { "type": "string", "maxLength": 20 },
    "furigana": { "type": "string", "pattern": "^[ァ-ヶー　]+$" }
  },
  "if": { "properties": { "country": { "const": "JP" } } },
  "then": {
    "required": ["postalCode", "prefecture"],
    "properties": { "postalCode": { "type": "string", "pattern": "^\\d{3}-\\d{4}$" } }
  }
}

{
  "country": "JP",
  "name": "山田太郎",
  "furigana": "やまだたろう",
  "postalCode": "１０５-００１１"
}

エラー 3 件、3 か所（Draft 2020-12）。
（ルート） (1 行 1 列): 必須プロパティ "prefecture" がありません ["then" 経由]  スキーマ #/then/required
/furigana (4 行 15 列): パターン ^[ァ-ヶー　]+$ に一致しません  スキーマ #/properties/furigana/pattern
/postalCode (5 行 17 列): パターン ^\d{3}-\d{4}$ に一致しません ["then" 経由]  スキーマ #/then/properties/postalCode/pattern

then から来たエラーには「“then” 経由」と付くので、if の条件が成り立ったために必須になった項目だとわかります。郵便番号は数字が全角なので \d に一致しません。

同じスキーマとデータを Python の jsonschema 4.26.0 で検証すると、郵便番号はエラーになりません。Python の re では \d が全角数字にも一致するためです。JSON Schema の pattern は ECMA-262 の正規表現と定められているので、このツール（Ajv）の判定が仕様どおりです。サーバー側を Python で検証しているなら、全角を半角に変換してから検証するか、[0-9] のように書くと両者がそろいます。

例：全角スペースが混ざった JSON

IME をオンにしたまま JSON を手で書くと、全角スペースや「」が紛れ込みます。JSON.parse は「Unexpected token」としか言いませんが、このツールは文字と位置を示します。

{ "type": "object", "required": ["name"] }

{
  "name":　"山田太郎"
}

データが正しい JSON・YAML・JSON Lines ではありません。
2 行 10 列：全角文字 "　" があります。JSON の記号と空白は半角です

エラーをクリックすると、データ欄でその文字が選択されます。全角のコロン ：、カンマ ，、引用符 「」 “” も同じように指摘します。

例：draft-04 の古いスキーマ

古いツールが生成したスキーマには draft-04 のものが残っています。draft-04 の exclusiveMaximum は真偽値で、maximum の値を含まないことを表します。

{
  "$schema": "http://json-schema.org/draft-04/schema#",
  "type": "object",
  "required": ["score"],
  "properties": {
    "score": { "type": "number", "minimum": 0, "maximum": 100, "exclusiveMaximum": true },
    "rank": { "const": "A" }
  }
}

{ "score": 100, "rank": "B" }

エラー 1 件（Draft 4）。
/score (1 行 12 列): < 100 でなければなりませんが、100 です  スキーマ #/properties/score/maximum
* #/properties/rank の不明なキーワード "const" は無視されます。

const は draft-06 で追加されたキーワードなので、draft-04 では無視されます（Python jsonschema の Draft4Validator も同じ判定です）。同じスキーマをメニューで 2020-12 に切り替えると、真偽値の exclusiveMaximum は 2020-12 では不正なので、スキーマ自体のエラーになります。

スキーマ自体が仕様に合っていません（Draft 2020-12）：
#/properties/score/exclusiveMaximum: number でなければなりませんが、boolean です
* $schema は Draft 4 ですが、メニューで Draft 2020-12 を指定しています。

「判定できません」と表示される場合

Ajv が誤った結果を出すことがわかっている入力では、有効・無効を表示せず「判定できません」と理由を表示します。コピーしたテキストと JSON も同じです（"state": "unknown"、"valid": null）。よくあるのが、20 桁の伝票番号を数値のまま送ってくる API です：

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "properties": {
    "slipNo": { "type": "integer", "minimum": 1 },
    "amount": { "type": "integer", "minimum": 0 }
  }
}

{ "slipNo": 20261002123456789012, "amount": 1980 }

判定できません（Draft 2020-12）：検証プログラムが正しく検証できないケースに当たるため、有効・無効の結果を出していません。理由は下にあります。
判定できません。理由：
- データに JavaScript で正確に表せない数値があります：20261002123456789012 は 20261002123456790000 として読まれ、スキーマは数値を比較します。
* データの /slipNo の数値 20261002123456789012（1 行目）は JavaScript で正確に表せないため、20261002123456790000 として読まれます。

JavaScript の数値（倍精度浮動小数点数）では 20261002123456789012 を正確に表せず、20261002123456790000 として読まれます。スキーマがこの値を比較するため、読み替えた値で判定すると結果が間違うおそれがあります。伝票番号は文字列で送り、"type": "string" と pattern で桁数を検査するのが確実です。0.1 や 1.0 のように正確に読める数値はそのまま判定します。

数値のほかに、$dynamicRef、unevaluatedItems / unevaluatedProperties と contains・then か else のない if・anyOf / oneOf 内の items の組み合わせ、相対参照と入れ子の $id（Ajv のスタックがあふれる）、$vocabulary を変えたメタスキーマ、データにもある __proto__ プロパティも同じ扱いです。

エラーのまとめ方

Ajv は oneOf / anyOf で失敗したすべての分岐のエラーを並べます。「カード」と「銀行口座」の 2 種類の支払い方法でカード番号の桁数を間違えると、Ajv の出力は 5 件になり、そのうち 3 件は関係のない銀行口座の分岐から来ます。このツールは /payment に 1 件だけ表示し、最も近い分岐（エラーが最も少ない分岐。const の判別フィールドが合わない分岐は後回し）を開き、残りは折りたたみます。分岐が $ref でも同じです。

他のオンラインツールとの比較

2026-10-02 に、Bing（日本）で「JSON Schema 検証」の 1 位だった ToolkitsLab の JSON Schema 検証ツールで同じ入力を試しました。

どちらもブラウザ内で動作し、テスト中にデータを含む通信はありませんでした。

制限

• 検証エンジンは Ajv 8.18（ajv-formats 3.0.1、ajv-draft-04 1.0.0）です。公式の JSON Schema Test Suite（必須テスト）では、draft-04 が 618 件中 616 件、draft-07 が 929 件中 927 件、2020-12 が 1,301 件中 1,210 件で期待どおりの結果になり、残り（2 件、2 件、91 件）は「判定できません」になります。誤った結果になるテストはありません。判定はスキーマとデータの構造だけで決めるため、$dynamicRef を含むスキーマはすべて「判定できません」になり、Ajv が正しく扱えていたテストも一部含まれます。
• $ref の URL はダウンロードしません。
• JavaScript で正確に表せない数値（9007199254740993、1.0000000000000001、1e400 など）は行番号付きで注意を表示し、スキーマが数値を比較するときはそのドキュメントを「判定できません」にします。スキーマ側や YAML データにある場合は常に「判定できません」です。multipleOf は 10 進数の値で判定するため、19.99 は 0.01 の倍数、0.3 は 0.1 の倍数になります（Ajv のように浮動小数点数で割ると倍数ではないと判定されます）。重複したキーは最後の値だけが残り、注意を表示します。
• YAML のエラーはパスだけを表示し、行番号は出ません。
• 1 MB を超える入力は「検証」ボタンで実行し、20 MB を超えるファイルは読み込みません。

サンプルデータからスキーマを作るなら JSON → JSON Schema、YAML の構文だけを確認するなら YAML バリデーター、API 定義全体を検証するなら OpenAPI バリデーター を使ってください。