📐 JSON Schema 検証
JSON Schema を使って JSON をバリデートします。型不一致・必須プロパティ欠落・enum 外・正規表現違反などのエラーを位置付きで表示。Draft 7 / 2019-09 / 2020-12 対応。
結果がここに表示されます。
🔗 関連ツール
📖 つまずきやすいポイント
Ajv 8 で JSON Schema (Draft 7 / 2019-09 / 2020-12) を実行し、型不一致・必須欠落・enum 外などをフィールドパス付きで表示します。処理はブラウザ内で完結します。「エラーが 0 件」は「データが正しい」ではありません — スキーマが緩ければ何でも通るからです。JSON Schema でつまずくポイントのほとんどは、書いたつもりの制約が実際には効いていないことに集中しています。
| ケース | 何が起きるか | どうする |
|---|---|---|
| format: email と書いたのに不正なメールが通る | format は既定では注釈であって、検証しません。これは実装の手抜きではなく JSON Schema の仕様どおりの挙動で、format の検証は「必須ではない語彙」と定義されています — 実装が対応していなくても準拠を名乗れます。Ajv も同じで、ajv-formats を別途読み込まない限り email・date-time・uri・uuid はすべて素通りします。スキーマを書いた人は検証しているつもり、実行側は素通し、という食い違いが本番まで気付かれないのが厄介な点です。 |
サーバー側では必ず ajv-formats を入れてください — const addFormats = require("ajv-formats"); addFormats(ajv); の 2 行です。移植性を優先するなら pattern で正規表現を書くほうが確実で、どの実装でも同じ結果になります (ただしメールアドレスの完全な正規表現は現実的でないので、^[^@\s]+@[^@\s]+\.[^@\s]+$ 程度に留めて、実在確認は確認メールで行うのが定石です)。スキーマを共有する相手がいる場合は「format を検証する前提かどうか」を明記してください — ここが暗黙になっていると、受け側の実装次第で検証の強さが変わります。 |
| required を書いたのにプロパティが欠けても通る | 置き場所を間違えているケースがほとんどです。required はオブジェクトのスキーマ直下に、キー名の配列として書きます — {"type":"object","properties":{...},"required":["id","name"]} の形です。properties の中に "required": true と書くのは Draft 3 の書き方で、現在の Draft では単に「未知のキーワード」として無視されます — エラーにすらならないので気付けません。同じ理由で、綴りを間違えた requred や minLenght も黙って無視されます。 |
Ajv を strict: true で動かしてください — 未知のキーワードや矛盾する型指定をエラーとして報告するようになり、この種の「静かに効いていない」制約を全部あぶり出せます。合わせて、スキーマ自体にテストを書いてください — 「通るべきデータ」だけでなく「通ってはいけないデータ」を必ず 1 件以上入れるのが要点です。前者だけのテストは、スキーマが空でも通ります。ネストしたオブジェクトの必須は、そのオブジェクトのスキーマの中に書きます — 親の required は子のキーには届きません。 |
| additionalProperties: false を書いたのに余計なキーが通る | allOf や $ref と組み合わせた瞬間に効かなくなります。理由は、additionalProperties が「同じスキーマオブジェクトの中に書かれた properties」しか見ないからです。基底スキーマを allOf で継承して子側で additionalProperties: false と書くと、基底で定義したプロパティすら「追加のプロパティ」と見なされ、正しいデータが全部落ちます。逆に基底側に書くと、子で足したプロパティが弾かれます。JSON Schema でいちばん多くの時間が溶ける箇所で、スキーマの継承を使った時点でほぼ必ず踏みます。 |
2019-09 以降なら unevaluatedProperties: false を使ってください — こちらは allOf や $ref で評価済みのプロパティを差し引いてから判定するので、継承と併用できます。これがまさにこの問題を解決するために追加されたキーワードです。Draft 7 に留まる必要がある場合は、継承をやめてスキーマを 1 枚に展開する (バンドル時にフラット化する) ほうが早いです。なお、API の入力検証で未知のキーを弾くべきかは設計判断です — 弾くとクライアントの前方互換性が失われ、フィールドを 1 つ足すだけで既存クライアントが壊れます。入力は弾く、出力は許す (Postel の原則) が無難です。 |
$schema をきちんと書いてください — 省略すると実装が既定のドラフトを勝手に選び、同じスキーマが環境によって違う意味になります。とくに Draft 7 と 2020-12 では配列のキーワードが変わっています: タプル (位置ごとに型が違う配列) の指定は items の配列形式から prefixItems に移り、2020-12 の実装で Draft 7 のタプル記法を読ませると、配列の全要素に 1 番目の型が適用されます — エラーにならず、意味だけが静かに変わります。もう 1 点、バリデーションが通ったデータをそのまま信用しないでください。JSON Schema が保証するのは形であって、「その ID が実在するか」「金額と明細の合計が一致するか」といった業務上の整合性は対象外です。スキーマ検証は入口のフィルタであって、ドメインの検証の代わりにはなりません。
📖 使い方
-
1
JSON Schema を入力左側のテキストエリアに JSON Schema (Draft 7 / 2019-09 / 2020-12) を貼り付けます。「サンプル」ボタンで動作確認用のスキーマが読み込まれます。
-
2
検証する JSON データを入力右側のテキストエリアにバリデートしたい JSON データを貼り付けます。どちらかを編集するたびに自動でバリデーションが実行されます。
-
3
バリデーション結果を確認して修正エラーがある場合はフィールドパス・エラーメッセージ・パラメータが一覧表示されます。エラーを参考に JSON データまたはスキーマを修正してください。
❓ よくある質問
どの Draft バージョンに対応していますか?
format バリデーション (email・date 等) は機能しますか?
JSON Schema とは何ですか?
🐛 このツールで問題が発生しましたか？
完全無料・登録不要。再現手順だけでも結構です。届いたご報告は運営者に直接届き、修正の参考にします。
ご報告ありがとうございます！
運営者に届きました。改善の参考にさせていただきます。