JSON Schema バリデーター

使い方

左に JSON Schema、右に検証したい JSON ドキュメントを貼り付けてください。バリデーターは Ajv(Another JSON Validator、JS で最も使われるライブラリ)を `allErrors: true` で実行するため、最初の 1 件だけでなく失敗箇所がすべて報告されます。各エラーには失敗フィールドへの JSON Pointer、拒否したスキーマキーワード(`required`・`type`・`minLength`・`format` など)、人間が読めるメッセージが含まれます。検証は入力に応じて随時走るため、貼り付けて編集しながらエラーが消えたり現れたりするのを見られます。

API コントラクトの設計、公開されたスキーマに対するサンプルペイロードの検証、Webhook の受信側がボディを拒否し続ける原因の特定などに使ってください。本ツールは `ajv-formats` を同梱しており、標準フォーマットチェック(`email`・`date-time`・`uri`・`uuid`・`ipv4`・`regex`)がそのまま動きます。スキーマとデータはブラウザの外に出ません。社内フィールド名や個人情報を含むペイロードでも安心です。実行時に自前のコードで使う場合も、同じ Ajv ライブラリが多くのサーバ側 / CLI バリデーター(`ajv-cli`・NestJS の validation pipe・Fastify のスキーマなど)を動かしています。

例

schema:
{
  "type": "object",
  "required": ["id", "email"],
  "properties": {
    "id":    { "type": "integer", "minimum": 1 },
    "email": { "type": "string", "format": "email" },
    "tags":  { "type": "array", "items": { "type": "string" }, "uniqueItems": true }
  }
}

data:
{ "id": 1, "email": "[email protected]", "tags": ["admin", "founder"] }

✓ valid

schema: (same as above)

data:
{ "id": -3, "email": "not-an-email", "tags": ["a", "a"] }

✗ 3 errors
/id     minimum  must be >= 1
/email  format   must match format "email"
/tags   uniqueItems  must NOT have duplicate items (items ## 1 and 0 are identical)

schema:
{
  "$defs": {
    "Address": {
      "type": "object",
      "required": ["city"],
      "properties": { "city": { "type": "string" }, "zip": { "type": "string", "pattern": "^[0-9]{5}$" } }
    }
  },
  "type": "object",
  "properties": {
    "home":   { "$ref": "#/$defs/Address" },
    "office": { "$ref": "#/$defs/Address" }
  }
}

data:
{ "home": { "city": "Seoul" }, "office": { "city": "Tokyo", "zip": "100-0001" } }

✗ 1 error
/office/zip  pattern  must match pattern "^[0-9]{5}$"

よくある質問

関連する概念

JSON Schema は JSON データの「形」を記述するための語彙です。どのフィールドが必要か、どの型を取るか、どの値が許されるか、配列の構造がどうあるべきか、などです。仕様のドラフトは 2026 年時点で Draft 2020-12 で *停止* しており、2022 年に標準化トラックが IETF に移されたものの、現時点で正式な RFC はまだ出ていません。それでも主要なエコシステム(Ajv・Python の jsonschema・Swagger / OpenAPI 3.1・AWS API Gateway・JSON Forms など)は 2020-12 か前任の 2019-09 を実装しています。古いコードは依然として 2018 年の準 LTS 的チェックポイントだった Draft 07 を参照することがあります。

語彙は大きく 4 領域をカバーします。**構造**: `type`・`properties`・`required`・`items`・`additionalProperties`・`patternProperties`。**制約**: `minimum`・`maximum`・`minLength`・`maxLength`・`pattern`・`uniqueItems`・`enum`・`const`。**合成**: `allOf`(すべて満たす)・`anyOf`(少なくとも 1 つ)・`oneOf`(ちょうど 1 つ)・`not`・`if / then / else`。**再利用**: 名前付きサブスキーマの `$defs`、JSON Pointer か絶対 URI で参照する `$ref`、安定した名前付き対象を作る `$anchor`。実運用のスキーマで使われるキーワードは合計 5〜10 個程度で、ロングテールは主に仕様自身の自己記述やエッジケース向けに存在します。

隣接する 3 つの考え方があります。**OpenAPI**(旧 Swagger)は JSON Schema を HTTP API 記述フォーマットで包んだもので、3.1 が完全準拠、3.0 は分岐した部分集合です。**TypeScript の型** はコンパイル時に同様の領域を扱いますが、ランタイム側はブリッジ(`zod`・`io-ts`・`runtypes`・`valibot`・`typia` など)が必要です。TypeScript はコンパイル時に消えてしまうためです。**Protocol Buffers** と **GraphQL SDL** は同じ問題を異なる構文で解きます。protobuf はスキーマ + バイナリのワイヤフォーマット、GraphQL はスキーマ + クエリ言語というアプローチです。JSON Schema が勝つのは、すでに JSON を扱っていて、トランスポートを書き換えずに検証を載せたい場合です。