JSON構文エラーの原因と直し方｜UtilityBox実務ガイド

このガイドで防ぐ問題

APIレスポンスや設定ファイルを貼り付けても解析できないとき、エラー位置の周辺から原因を特定します。

JSONエラーは、エラー表示された位置そのものではなく、その直前のカンマや引用符が原因になっていることがあります。大きなJSONを目視だけで探すより、まずパーサーが示す位置を起点に構造を小さく切り分けます。

また、JavaScriptのオブジェクト記法とJSONは同じではありません。コメント、undefined、NaN、シングルクォート、末尾カンマはJavaScriptでは見かけても、標準JSONではそのまま使えません。

WORKED EXAMPLE

末尾カンマと引用符漏れを直す例

APIテスト用に手作業で編集したJSONで、2種類の構文ミスが入った例です。

処理・確認前

{
  "name": "UtilityBox",
  enabled: true,
  "tags": ["csv", "json",],
}

処理・確認後

{
  "name": "UtilityBox",
  "enabled": true,
  "tags": ["csv", "json"]
}

この例で確認するポイント

キーはダブルクォートで囲みます。
配列やオブジェクトの最後の要素へ末尾カンマを残しません。
整形後に構文だけでなく値の型も確認します。

エラー位置の1文字前から確認する

パーサーは「ここから先を解釈できない」位置を返すため、原因が数文字前にあることがあります。エラー位置の行だけでなく、前の行のカンマ、閉じ括弧、文字列の終端を確認します。

長い1行JSONは一度整形できない場合でも、エディタの行番号や文字位置を使って対象付近を切り出すと原因を見つけやすくなります。

構文が直っても型を変えない

エラー修正時に "00123" を 123 へ変えると、構文は正しくてもIDの意味が変わります。true/false、null、数値、文字列を修正前後で比較してください。

特に長いIDや電話番号、郵便番号は計算対象ではないため、数値へ変換しない方が安全な場合があります。

APIエラーとJSON構文エラーを分ける

JSONとして正しくてもAPI仕様に合わなければ400エラーになります。構文が通った後は、required、型、列挙値などをJSON SchemaやAPI仕様書で確認します。

「パースできる」と「APIが受理する」は別の検証段階として扱うと、原因切り分けが速くなります。

問題が起きる主な原因

キーや文字列をダブルクォートで囲んでいない。
最後の要素に末尾カンマがある。
コメント、undefined、NaNなど標準JSON外の値を含む。

安全に作業する手順

1
元データを保存し、整形ツールで構文エラー位置を確認します。
2
該当位置の直前にあるカンマ、引用符、括弧を確認します。
3
修正後に再解析し、値の型が変わっていないか確認します。

結果を利用する前の確認項目

ルート要素がオブジェクトまたは配列になっている。
文字列内の改行や引用符がエスケープされている。
長いIDが数値精度で変化していない。

作業完了前のチェックリスト

エラー位置の直前も確認した
キーと文字列をダブルクォートで囲んだ
末尾カンマやコメントを除いた
IDなどの型を勝手に変えていない
構文修正後に再パースした
API仕様上の必須項目は別途確認した

この方法の限界と注意点

JSON5やJavaScriptオブジェクトは標準JSONとは異なります。
整形に成功しても業務上の必須項目までは検証されません。

UtilityBoxのガイド方針

ツールの操作方法だけでなく、結果を誤用しないための具体例、確認項目、処理の限界、元データを保管すべき場面まで記載します。原因・手順・完了判定・限界を運営者が確認したガイドだけを一覧と検索対象へ掲載します。

品質確認の方法と更新方針を確認する →

JSON構文エラーの原因と直し方