このツールについて
フィクスチャファイルやリクエストボディの構文エラーは、わかりにくいテスト失敗の最も一般的な原因の 1 つです。このバリデーターは JSON を厳密な標準に照らしてチェックし、最初のエラーを行と列つきで報告します。正しい場合は、ドキュメントの構造（オブジェクト、配列、キー、深さ）の概要を表示します。構文ではなくデータの形を検証したい場合は、JSON Schema バリデーターを使ってください。
使い方
- チェックしたい JSON を貼り付けます。
- 結果バナーを確認します。緑は正しい JSON、赤はエラーメッセージと位置を示します。
- 報告された位置を修正すると、入力に合わせて結果が更新されます。
正しい JSON の条件
このバリデーターは、JSON.parse と同じ RFC 8259 の厳密な文法を適用します。ドキュメントは 1 つの値で、オブジェクト、配列、文字列、数値、true、false、null のいずれかです。そのため、ほとんどの API はオブジェクトを返しますが、単独の "hello" や 42 も正しい JSON です。
重複キーはよくある落とし穴です。標準ではオブジェクトの名前は一意であるべき（SHOULD）とされていますが、重複は禁止されておらず、JSON.parse は黙って最後の値を採用します。構文チェックでは {"id": 1, "id": 2} は検出されないため、コードレビューやリンターで重複に注意してください。
エラーメッセージの読み方
パースエラーの表現はブラウザごとに異なります。Chrome は「Unexpected token」や「Expected property name」といったメッセージを位置つきで表示し、Firefox は行と列を示します。いずれの場合も、示される位置はパーサーが処理をあきらめた場所であり、本当の誤り（カンマ抜け、閉じていないクォート、前の行の余計な括弧など）はその直前にあることがほとんどです。
自動テストで JSON を検証する
- Playwright：ボディが正しい JSON でない場合
await response.json()が例外を投げるため、テストはその行で失敗します。サーバーが JSON を HTML として送ることもあるので、response.headers()['content-type']も確認してください。 - REST Assured：
.contentType(ContentType.JSON)をアサートし、json-schema-validator モジュールのmatchesJsonSchemaInClasspath("order-schema.json")で構造をチェックします。 - Postman：
pm.response.json()は不正な JSON で例外を投げ、pm.response.to.be.jsonはコンテンツタイプをアサートします。 - 形や型（必須フィールド、フォーマット、enum）の確認には JSON Schema バリデーターを使います。構文の検証で証明できるのは、テキストが解析できることだけです。
JSON バリデーター のよくある質問
JSON の検証とスキーマ検証の違いは何ですか？
構文の検証では、テキストが整形式の JSON であることを確認します。スキーマ検証では、整形式の JSON が期待されるフィールド、型、制約（「id は必須の整数」など）を満たしているかを確認します。
エラー位置が本当の誤りより後ろを指すのはなぜですか？
パーサーは処理を続けられなくなった位置を報告します。カンマやクォートの抜けは、たいてい報告された位置の直前にあります。