JSON Schema バリデーター

JSON Schema バリデーターとは？

// A 5-line schema that catches three real bugs
const schema = {
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "properties": {
    "id":    { "type": "integer", "minimum": 1 },
    "email": { "type": "string", "format": "email" },
    "age":   { "type": "integer", "minimum": 0, "maximum": 150 }
  },
  "required": ["id", "email"],
  "additionalProperties": false
};

// Three bugs the schema catches:
const bad = { "id": "42", "age": 200 };
//   /id   → type: expected integer, got string
//   /email → required: missing
//   /age   → maximum: 200 > 150

// In Node:        new Ajv().compile(schema)(bad)  // false; ajv.errors has the paths
// In Python:      jsonschema.validate(bad, schema)
// In the browser: this tool — same errors, same paths, no install

主な機能

例

{
  "id": 42,
  "email": "alice@example.com",
  "age": 30
}

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "properties": {
    "id": { "type": "integer", "minimum": 1 },
    "email": { "type": "string", "format": "email" },
    "age": { "type": "integer", "minimum": 0, "maximum": 150 }
  },
  "required": ["id", "email"],
  "additionalProperties": false
}

{
  "id": "42",
  "age": 200
}

{
  "type": "object",
  "properties": {
    "id": { "type": "integer" },
    "email": { "type": "string", "format": "email" },
    "age": { "type": "integer", "maximum": 150 }
  },
  "required": ["id", "email"]
}

{
  "type": "order.created",
  "data": { "orderId": "ORD-001234", "totalUsd": 49.99 }
}

{
  "oneOf": [
    {
      "properties": {
        "type": { "const": "order.created" },
        "data": {
          "type": "object",
          "properties": {
            "orderId": { "type": "string", "pattern": "^ORD-[0-9]{6}$" },
            "totalUsd": { "type": "number", "minimum": 0 }
          },
          "required": ["orderId", "totalUsd"]
        }
      },
      "required": ["type", "data"]
    },
    {
      "properties": {
        "type": { "const": "order.refunded" },
        "data": { "type": "object", "required": ["refundId"] }
      },
      "required": ["type", "data"]
    }
  ]
}

[
  { "sku": "A1", "qty": 3 },
  { "sku": "B2", "qty": 5 },
  { "sku": "A1", "qty": 3 }
]

{
  "type": "array",
  "minItems": 1,
  "uniqueItems": true,
  "items": {
    "type": "object",
    "properties": {
      "sku": { "type": "string", "pattern": "^[A-Z][0-9]+$" },
      "qty": { "type": "integer", "minimum": 1 }
    },
    "required": ["sku", "qty"]
  }
}

使い方

1. 1

   JSON Schema を貼り付ける

   Schema を右パネルに投入してください。$schema URI があればバリデーターが Draft を自動判別し、なければツールバーで Draft 2020-12 / 2019-09 / Draft-07 を選択します。

2. 2

   JSON データを貼り付ける

   検証したい JSON ドキュメントを左パネルに投入します。入力中に検証が走り、200 KB を超える大きな入力は手動 Validate ボタンに切り替わって入力がもたつかないようにします。

3. 3

   エラーリストを読む

   各エラーには JSON Pointer パス、keyword、1 行の説明が含まれます。エラーをクリックして該当箇所へジャンプし、修正するとエラー数がリアルタイムで減少します。

JSON Schema のよくある落とし穴

{ "qty": 1.0 }   schema: { "type": "integer" }   → error: not an integer

{ "qty": 1 }     schema: { "type": "integer" }   → valid

{ "properties": { "name": { "type": "string", "required": true } } }

{ "properties": { "name": { "type": "string" } }, "required": ["name"] }

{ "properties": { "id": { "type": "integer" } } }   accepts: { "id": 1, "foo": "bar", "x": null }

{ "properties": { "id": { "type": "integer" } }, "additionalProperties": false }

{ "type": "string", "nullable": true }   in 2020-12: nullable is just an unknown keyword

{ "type": ["string", "null"] }   in 2020-12: explicitly allows null

pattern: "[A-Z]+"   accepts: "helloX"   (because X matches)

pattern: "^[A-Z]+$"   accepts only: "HELLO"

oneOf: [ { type: "string" }, { type: "string", maxLength: 10 } ]   on: "hi"   → error: matches both

anyOf: [ { type: "string" }, { type: "string", maxLength: 10 } ]   on: "hi"   → valid

主なユースケース

API リクエストの検証

デプロイ前にリクエストボディとエンドポイントの schema を貼り付けて確認しましょう。テストでカバーしきれない 400 レスポンス（必須フィールド欠落、型違反、範囲外の数値）を事前に捕まえられます。

Webhook Payload の検証

ベンダーが送ってきた payload をハンドラーが拒否しますか？実 payload を自分の schema、次にベンダー公開 schema で検証してください。両者の差分がバグの正体です。

設定ファイルの Lint

package.json、tsconfig.json、helm values.yaml — どの設定ファイルにも公開 schema があります。Schema と設定を貼り付ければ、タイプミスを試行錯誤なしに発見できます。

OpenAPI コンポーネントのテスト

OpenAPI 3.1 ドキュメントから schema コンポーネントを取り出して貼り付け、サンプル payload を検証します。Mock サーバーを立てるより速く、決定的で、SDK も不要です。

フォーム送信のプリフライト

フロントエンド検証の実装前にサンプルフォーム payload を貼り付け、想定どおりに拒否し受け入れることを確認したうえで、同じ schema をクライアントとサーバーに展開しましょう。

データパイプライン契約チェック

ETL 出力がドリフトしましたか？サンプル行と下流 schema を貼り付ければ、どの producer が変わり、どのキーが壊れたかを特定できます。10,000 行のリトライを発動させる前に。

技術詳細

Draft 2020-12 準拠

公開された Draft 2020-12 仕様（keyword、型システム、format 語彙）を実装。Ajv 8.x と ajv-formats の出力でクロスチェック済みです。

JSON Pointer エラーパス

エラーは RFC 6901 JSON Pointer（/user/email/0）を使用。各 keyword 失敗はデータ内の解決可能な単一位置を指し、曖昧さや文字列検索は不要です。

内部 $ref の解決

単一ドキュメント内の $ref ポインター（#/$defs/foo、#/properties/bar）を解決します。循環参照は検出して報告。外部 HTTP $ref はプライバシー保護のため無効化されています。

ベストプラクティス

additionalProperties: false を必ず設定

入力契約（リクエストボディ、設定ファイル、キューメッセージ）では、未知のキーは大抵バグです（タイプミス、誤って混入したフィールド、攻撃者の探り）。既定で拒否しましょう。

再利用するサブ schema は $defs に

同じ形を 2 度インラインで書けば、いずれずれていきます。共有定義を $defs に移し、$ref で参照しましょう。単一の真実の源があれば、変更は一度で全所に反映されます。

業務ロジックの前に検証する

JSON.parse 直後、解析済み構造に触れる前に schema 検証を実行してください。型ナローイング、デフォルト値補完、永続化はいずれも契約成立を前提とします。まず成立を保証しましょう。

よくある質問