JSON Validator・JSON Linter・JSON Schemaの違いとは？用途を実例で解説

JSONを解析できてもAPIに拒否されることがあります。Validatorが有効と判定しても、Linterが警告を出すこともあります。矛盾ではありません。3つの道具は別の質問に答えています。

JSON Validatorはテキストが正しいJSONか、JSON Linterは品質や一貫性のルールを満たすか、JSON Schemaはデータがどの構造と制約を満たすべきかを扱います。

> 実用的な順番は、構文検証 → Lint → Schema検証です。

「Validator」が指す2つの意味

JSON Validatorという名称は、しばしば2種類のツールに使われます。

1. 構文Validator：JSON.parseなどでJSONテキストの文法を確認します。

1. JSON Schema Validator：SchemaとJSON Instanceを受け取り、InstanceがSchemaを満たすか確認します。

Json WorkのJSON Validatorは主に前者です。JSON Schema公式資料のValidatorは通常、後者を意味します。設計書では syntax validator と schema validator を明記すると誤解を防げます。

JSON Validator：解析できるかを確認する

RFC 8259は、オブジェクト、配列、文字列、数値、真偽値、nullなどのJSON文法を定義しています。次の例はカンマがないため無効です。

{
  "id": 101
  "name": "Alice"
}

構文Validatorは、カンマ不足、引用符や括弧の閉じ忘れ、不正なエスケープ、引用符のないキー、undefinedやNaNといった非対応値を検出します。

一方、次は構文上は有効です。

{
  "id": "one hundred",
  "email": "not-an-email",
  "active": "yes"
}

構文Validatorは、idが整数であるべきか、activeがbooleanであるべきかを知りません。「正しいJSONテキストか」だけを判定します。エラー位置はJSON Validatorで確認し、JSONに近い壊れた入力はJSON Repairで候補を作ってから内容をレビューしてください。

JSON Linter：品質と一貫性を確認する

Lintはルールベースの静的分析です。JSON文法とは違い、すべてのLinterに共通する唯一のルール集があるわけではありません。ツールやチームが保守性とリスクに応じてルールを選びます。

{
  "user_id": 101,
  "userName": "Alice",
  "isActive": "true"
}

このJSONは有効ですが、Linterは snake_case と camelCase の混在、booleanらしい値が文字列であること、同一フィールドの型の揺れ、過度なネストなどを指摘できます。

ただし警告は必ずしも誤りではありません。上流仕様が文字列 "true" を要求している可能性もあります。JSON Linterは暗黙の規約を見える化しますが、契約なしに業務上の正解を証明するものではありません。

JSON Schema：データ契約を定義する

JSON Schemaは、型、必須プロパティ、配列要素、長さ、数値範囲、enum、組み合わせ条件などを表現する標準化された語彙です。公式サイトでは検証、相互運用、ドキュメント化が主要用途として紹介されています。

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "properties": {
    "id": { "type": "integer" },
    "name": { "type": "string", "minLength": 1 },
    "email": { "type": "string", "format": "email" },
    "active": { "type": "boolean" }
  },
  "required": ["id", "name", "email"],
  "additionalProperties": false
}

Schemaはルール文書であり、実行プログラムではありません。AjvやPython jsonschemaなどのSchema Validatorが実データに適用します。公式チュートリアルもSchemaとInstanceを区別しています。

実装設定にも注意が必要です。formatはValidatorと設定によって、強制条件ではなく注釈として扱われる場合があります。formatの公式解説を確認し、Draft、Validator、オプションをチームで固定してください。

JSON Schema生成ツールでサンプルから初期Schemaを作成し、範囲、長さ、パターン、enum、追加プロパティの方針を人が補うのが安全です。

同じAPIデータに対する3つの答え

{
  "id": "101",
  "name": "Alice",
  "email": "alice@example.com",
  "active": "true"
}

• • Validator：成功。JSON文法は正しいためです。

• • Linter：警告の可能性。idとactiveの型が不自然に見えますが、意図は断定できません。

• • Schema Validator：失敗。上のSchemaでは id はinteger、activeはbooleanです。

構文が有効 ≠ スタイルが一貫 ≠ データ契約に適合

比較表

推奨パイプライン

1. Syntax gate：生テキストを解析できるか確認。

1. Lint gate：命名、一貫性、チーム規約を確認。

1. Schema gate：明示したDraftの契約に照らして検証。

1. Business gate：権限、状態、フィールド間の業務ルールを検証。

「終了時刻は開始時刻より後」「このユーザーに閲覧権限がある」など、Schemaだけでは扱いにくいルールもあります。Schema成功を業務処理の安全性と同一視しないでください。

AjvでSchemaを検証する

import Ajv from "ajv";

const schema = {
  type: "object",
  properties: {
    id: { type: "integer" },
    name: { type: "string" },
    active: { type: "boolean" }
  },
  required: ["id", "name"],
  additionalProperties: false
};

const data = { id: "101", name: "Alice", active: true };
const ajv = new Ajv({ allErrors: true });
const validate = ajv.compile(schema);
if (!validate(data)) console.log(validate.errors);

Ajvは id がintegerでないことを報告します。公式ガイドは、Schemaを一度コンパイルして検証関数を再利用する方法を推奨しています。入力がネットワークの生テキストなら、Schema検証より前にJSON解析が必要です。

よくある誤解

• • Validator成功はデータ全体の正しさを保証しません。

• • Lint警告はチーム規約に照らして判断し、機械的に直すものではありません。

• • 1つのサンプルから生成したSchemaは最終契約ではありません。

• • JSON Schemaはカンマや引用符を修復しません。

まとめ

Validatorは正しい構文、Linterは品質と一貫性、JSON Schemaは構造とデータ契約を守ります。1つを選ぶのではなく順番に組み合わせるのが信頼できる方法です。

JSON Validatorで構文を確認し、JSON Linterで品質を点検し、JSON Schema生成ツールで保守可能な契約を作成できます。すべてブラウザ内で処理されます。