JSONをインポートできないときは、最初にJSONそのものの構文を確認し、次に取り込み先が要求するデータ構造と照合します。以下のエラー表示はJavaScriptや一般的なバリデーターの代表例です。実際の文言やposition、line、columnはブラウザ、言語、ライブラリ、サービスによって異なります。

JSONのエラーメッセージはどう読むか

position 16は先頭から数えた文字位置、line 2 column 5は2行目の5文字目付近を表します。ただし、表示位置が原因の文字そのものとは限りません。カンマや閉じ括弧が不足すると、パーサーは次のキーまで進んでから異常に気付くためです。

  1. 表示された行と列を確認する
  2. その位置の直前にあるカンマ、引用符、括弧を見る
  3. JSONを整形して階層を確認する
  4. 構文が直ったら取り込み仕様と照合する

JSON総合診断では、構文エラーに加えて重複キー、大きな整数、空キー、配列内の項目差も確認できます。構文を直して読みやすくしたい場合はJSON整形も利用できます。

1. シングルクォート・特殊な引用符を使っている

代表的なエラー表示SyntaxError: Expected property name or '}' in JSON at position 1

JSONのキーと文字列は、半角のダブルクォートで囲みます。JavaScript風のシングルクォートや、文書ソフトが自動変換した“ ”のような引用符はJSONとして扱えません。

エラーになる例

{'name':'山田太郎'}

修正例

{"name":"山田太郎"}

修正方法:すべてを機械的に置換する前に、文字列内のアポストロフィまで変わらないか確認し、キーと文字列の囲みだけを半角ダブルクォートへ直します。

2. 項目や配列要素の間にカンマがない

代表的なエラー表示SyntaxError: Expected ',' or '}' after property value in JSON at position 8

オブジェクトの項目同士と配列の要素同士はカンマで区切ります。エラー位置は次のキー付近を示していても、実際の不足はその直前にあることがよくあります。

エラーになる例

{"id":1 "name":"山田太郎"}

修正例

{"id":1,"name":"山田太郎"}

修正方法:エラー位置の直前にある値と、次のキーまたは要素の境界を確認してカンマを追加します。

3. 最後の項目に余分なカンマがある

代表的なエラー表示SyntaxError: Expected double-quoted property name in JSON at position 8

JSONでは、オブジェクトや配列の最後の項目の後にカンマを置けません。JavaScriptのオブジェクトでは許可される書き方でも、JSONとしては構文エラーです。

エラーになる例

{"id":1,}

修正例

{"id":1}

修正方法:閉じる波括弧または角括弧の直前にあるカンマを削除します。

4. JSON内にコメントが含まれている

代表的なエラー表示SyntaxError: Expected ',' or '}' after property value in JSON at position 8

標準のJSONは // や /* ... */ のコメントに対応していません。設定ファイルを扱う一部の製品がコメントを許可していても、別のAPIやインポート機能では失敗します。

エラーになる例

{
  "id": 1 // 顧客ID
}

修正例

{
  "id": 1,
  "note": "顧客ID"
}

修正方法:コメントを削除します。説明自体がデータとして必要なら、取り込み仕様で許可されたキーへ文字列として入れます。

5. キーがダブルクォートで囲まれていない

代表的なエラー表示SyntaxError: Expected property name or '}' in JSON at position 1

JSONのオブジェクトキーは必ず文字列であり、半角ダブルクォートが必要です。JavaScriptのオブジェクトリテラルをそのままコピーすると起きやすいエラーです。

エラーになる例

{id:1,name:"山田太郎"}

修正例

{"id":1,"name":"山田太郎"}

修正方法:すべてのキーを半角ダブルクォートで囲みます。値が文字列の場合は値側にもダブルクォートが必要です。

6. バックスラッシュのエスケープが正しくない

代表的なエラー表示SyntaxError: Bad escaped character in JSON at position 16

JSON文字列ではバックスラッシュが特殊文字の開始になります。パスの \n は改行として解釈され、\d のような未定義の組み合わせはエラーになります。文字として残すには二重化が必要です。

エラーになる例

{"path":"C:\new\data"}

修正例

{"path":"C:\\new\\data"}

修正方法:Windowsパスなどのバックスラッシュを \\ として記述します。改行を入れたい場合は意図的に \n を使います。

7. 波括弧と角括弧の種類・数が合っていない

代表的なエラー表示SyntaxError: Expected ',' or ']' after array element in JSON at position 13

オブジェクトは { }、配列は [ ] で閉じます。階層が深いJSONでは、途中の閉じ括弧が抜けたり、種類を取り違えたりしやすくなります。

エラーになる例

{"items":[1,2}

修正例

{"items":[1,2]}

修正方法:整形してインデントごとに開始と終了を対応させます。エラー位置より前にある、まだ閉じられていない階層を確認します。

8. 複数のJSONがそのまま連結されている

代表的なエラー表示SyntaxError: Unexpected non-whitespace character after JSON at position 9

通常のJSON文書に置けるルート値は1つだけです。1行に1オブジェクトを置くJSON Lines(NDJSON)は別形式であり、通常のJSONインポートでは読み込めないことがあります。

エラーになる例

{"id":1}
{"id":2}

修正例

[
  {"id":1},
  {"id":2}
]

修正方法:取り込み先がJSON Linesに対応しているか確認します。通常のJSONが必要なら、複数オブジェクトを1つの配列へまとめます。

9. 同じオブジェクト内でキーが重複している

代表的なエラー表示警告例: Duplicate key "status" at path $.status

重複キーは標準的なJSONパーサーで構文エラーにならず、後の値だけが残る場合があります。そのためインポート自体は成功しても、先の値が黙って失われる危険があります。

エラーになる例

{"status":"new","status":"done"}

修正例

{"status":"done"}

修正方法:どちらの値が正しいか元データと仕様で確認し、キーを1つにします。複数の状態を持たせる設計なら配列など、仕様に合う構造へ変更します。

10. 取り込み先の型・必須項目・ルート構造と違う

代表的なエラー表示エラー例: $.users[0].id must be integer / required property "name" is missing

この例はJSONとして正しいため、JSON.parseではエラーになりません。しかし取り込み先がidを整数、nameを必須としていれば検証で失敗します。ルートに配列を要求するシステムへオブジェクトを渡す場合も同様です。

エラーになる例

{"users":[{"id":"101"}]}

修正例

{"users":[{"id":101,"name":"山田太郎"}]}

修正方法:API仕様、JSON Schema、サンプルファイルと比較し、ルート型、必須キー、値の型、nullの可否、許容値、日付形式、件数・サイズ制限を合わせます。

原因が分からないときの確認順

  1. ファイル全体を診断する空ファイル、文字コード、BOM、構文エラーの位置を確認します。
  2. 引用符・カンマ・括弧を直す最初の構文エラーから1件ずつ修正し、毎回もう一度解析します。
  3. 重複キーと数値を確認する構文が正常でも値が失われたり、長い整数が変化したりする問題を調べます。
  4. 取り込み先の仕様と比較するルート型、必須キー、型、null、許容値、日付、件数、サイズを確認します。
  5. 少量データで再試行する元ファイルを残し、可能なら少数レコードで登録結果まで確認します。

複数のエラーがある場合、パーサーは最初の1件だけを表示することがあります。1件直した後に別のエラーが出ても、修正が失敗したとは限りません。先頭から順番に解消してください。

まとめ

JSONのインポートエラーは、構文エラー、データを失う可能性がある問題、取り込み仕様との不一致に分けると確認しやすくなります。まず引用符、カンマ、コメント、括弧、ルート値を直し、その後で重複キー、必須項目、値の型を確認します。

エラー表示の行や列だけを見るのではなく、その直前も確認してください。構文が正常になっても、利用先のAPIやシステムの仕様に合うとは限らないため、最後に正式な仕様書やJSON Schemaと照合します。