JSON エラーで困ったときのチェックリスト

末尾カンマ（trailing comma）

JSON パーサが吐く典型的なメッセージは次のとおりです。

• Node.js: SyntaxError: Unexpected token } in JSON at position 15
• Python: json.decoder.JSONDecodeError: Expecting property name enclosed in double quotes: line 1 column 16 (char 15)
• ブラウザ DevTools: JSON.parse: unexpected character at line 1 column 16 of the JSON data

エラー位置を見ると「閉じ括弧の直前」を指しているのに気づくはずです。それが末尾カンマのサインです。

{
  "name": "Alice",
  "age": 30,
}

{
  "name": "Alice",
  "age": 30
}

なぜ弾かれるか： RFC 8259 のオブジェクト文法は value = false / null / true / object / array / number / string と定義されており、カンマの後には必ず次の要素が続く前提です。カンマで終わることを認める文法規則が存在しません。

よくある発生源： JavaScript/TypeScript のオブジェクトリテラルをそのままコピーしたとき。ESLint の comma-dangle: always-multiline ルールを適用した JS コードをコピペすると末尾カンマが自動で付いています。また Python の dict を str() や pprint で出力してもこの問題は起きませんが、手動で JSON 風に書くと末尾カンマを入れてしまいがちです。

シングルクォート

JSON では文字列もキーも 必ずダブルクォート で囲みます。シングルクォートは JSON の文法に存在しません。Node.js は SyntaxError: Unexpected token ' in JSON at position 0、Python は json.decoder.JSONDecodeError: Expecting value: line 1 column 1 (char 0) を返します。

{'name': 'Alice', 'city': "Tokyo"}

{"name": "Alice", "city": "Tokyo"}

なぜ弾かれるか： JSON の文字列定義は "（U+0022）で始まり " で終わる文字シーケンスのみです。シングルクォート（U+0027）は文字列を開始する構文要素として認められていません。

よくある発生源： Python の dict をそのまま print() したときが最多です。Python は文字列をシングルクォートで表示するため、{'key': 'value'} という出力が得られます。これをそのままログから貼り付けると即エラーです。正しくは import json; print(json.dumps(data)) で出力してください。Ruby の Hash#inspect でも同様の問題が起きます。

キーがクォートされていない

JavaScript のオブジェクトリテラルは {key: "value"} のようにキーをクォートなしで書けますが、JSON ではキーも必ずダブルクォートで囲む必要があります。Python で言えば json.decoder.JSONDecodeError: Expecting property name enclosed in double quotes がこれを示しています。

{name: "Alice", age: 30}

{"name": "Alice", "age": 30}

なぜ弾かれるか： JSON の object 定義は { string : value } であり、キー部分は必ず string（ダブルクォート囲み）でなければなりません。JavaScript エンジンが許容する「識別子をキーとして使う」構文は JSON には存在しません。

よくある発生源： JavaScript のコードスニペットや設定例をコピーしたとき。特に StackOverflow の古い回答や README サンプルに {port: 3000, host: "localhost"} のような JS オブジェクト表記が混在しています。Node.js の require('./config.json') で読む設定ファイルを JS オブジェクト表記で書いて気づかないケースも多いです。

コメントが入っている

JSON 仕様には // や /* */ のコメント構文がありません。コメントを含む JSON をパースすると、Node.js では SyntaxError: Unexpected token / in JSON at position 12 のようにスラッシュを異物として報告します。

{
  // データベース設定
  "host": "localhost",
  "port": 5432 /* デフォルトポート */
}

{
  "host": "localhost",
  "port": 5432
}

なぜ弾かれるか： Douglas Crockford は後のインタビューで「JSON からコメントを外したのは、人々がパース指示のコメントを入れ始め、相互運用性が壊れるのを防ぐためだった」と語っています。設計上の意思決定であり、単純な見落としではありません。

よくある発生源： VS Code の settings.json や tsconfig.json は JSONC（JSON with Comments）形式を採用しているため、コメントが書けます。これを他のパーサ（例: JSON.parse() や Python の json.load()）で読もうとすると即エラーです。また ESLint の .eslintrc.json は実は JSONC で処理されています。

括弧の対応関係が崩れている

ネストが深い JSON で最も見つけにくいバグです。{ と }、[ と ] の数が合っていても、位置が間違っていれば壊れます。エラーメッセージは Unexpected end of JSON input（閉じが足りない）か Unexpected non-whitespace character after JSON data（閉じが多い）になります。

{
  "users": [
    {"name": "Alice"},
    {"name": "Bob"}
  }
]

{
  "users": [
    {"name": "Alice"},
    {"name": "Bob"}
  ]
}

なぜ起きるか： 手書きや文字列連結で JSON を組み立てると、コピペ時に閉じ括弧の順序が入れ替わります。特に「配列の最後の要素を削除したとき」に括弧だけ残るパターンが多いです。

よくある発生源： API レスポンスをログに出力したとき、ログ行数の上限でレスポンスが途中で切れることがあります。この場合 Unexpected end of JSON input が出ますが、自分のコードに問題はなく、ログ設定かネットワーク層を疑うべきです。また、HTTP ストリームが途中で切断された場合も同じエラーになります。

文字列内のエスケープ忘れ

JSON 文字列内で特別な意味を持つ文字はエスケープが必須です。エラーメッセージは Bad escaped character in JSON や Invalid \escape（Node.js）として現れます。

エスケープが必要な文字の一覧：

• \" — ダブルクォート
• \\ — バックスラッシュ
• \/ — スラッシュ（オプション、省略可能）
• \n — 改行（LF）
• \r — 復帰（CR）
• \t — タブ
• \uXXXX — Unicode コードポイント

{"path": "C:\Users\Alice\Documents"}

{"path": "C:\\Users\\Alice\\Documents"}

なぜ弾かれるか： \U・\A・\D は JSON の定義済みエスケープシーケンスではないため、パーサは「不正なエスケープ」として拒否します。JavaScript の文字列では \U は単に U として扱われますが、JSON パーサはより厳格です。

よくある発生源： Windows ユーザーがファイルパスをそのまま JSON に貼り付けたとき。また JS の template literal 内で改行を含む文字列を作り、それを JSON 文字列値としてそのままシリアライズしようとしたときも同様です。実際の改行文字（U+000A）は JSON 文字列の中に直接置けないため、\n に変換する必要があります。

数値の先頭 0

0123 のように数値リテラルが 0 で始まると JSON では不正です。Node.js は SyntaxError: Unexpected number in JSON at position 6、Python は json.decoder.JSONDecodeError: Extra data: line 1 column 4 (char 3) を返します（0 単体はパースされ、123 が余分なデータとして扱われます）。

{"zip_code": 01234, "id": 007}

{"zip_code": "01234", "id": "007"}

なぜ弾かれるか： 歴史的に 0 で始まる数値リテラルは8進数として解釈される言語（C、Java、JavaScript の旧仕様）があり、相互運用上の曖昧さを生みます。JSON はこの曖昧さを仕様レベルで排除するため、0 単体か 0. 以下の小数点数以外で 0 から始まる数値を禁止しています。

よくある発生源： 郵便番号・電話番号・社員番号など、「数字だが先頭 0 が意味を持つ」フィールドを数値型で格納しようとしたとき。データベースから取得した NUMERIC 型フィールドを、そのまま JSON に入れるケースで踏みます。これらのフィールドは常に文字列として JSON に入れるのが正解です。

NaN / Infinity / undefined

JSON の数値型は IEEE 754 の有限な数のみを表現します。NaN・Infinity・-Infinity・undefined はサポート外です。Node.js では SyntaxError: Unexpected token N in JSON at position 8（NaN の場合）または SyntaxError: Unexpected token I in JSON at position 8（Infinity の場合）が出ます。

{"score": NaN, "ratio": Infinity, "val": undefined}

{"score": null, "ratio": null, "val": null}

なぜ弾かれるか： NaN と Infinity は JavaScript の識別子であり、JSON の value に識別子は存在しません（true/false/null という3つのキーワードだけが例外として定義されています）。

よくある発生源： Python の json.dumps() はデフォルトで float('nan') を NaN として出力します（RFC 違反ですが Python 仕様）。これを JavaScript 側で JSON.parse() するとクラッシュします。対処は json.dumps(data, allow_nan=False) で例外を出すか、simplejson ライブラリを使って null に変換するかです。JavaScript の JSON.stringify() は NaN・Infinity・undefined を黙って null に変換します。受け取り側が気づかずに処理を続けることがあるため、送信前にバリデーションを挟むことを推奨します。

UTF-8 BOM が混入している

BOM（Byte Order Mark、U+FEFF）が JSON ファイルの先頭に混入していると、パーサから見た最初の文字が { ではなく \ufeff になります。結果として SyntaxError: Unexpected token in JSON at position 0（トークン部分が空白や文字化けに見える）や、Python の json.decoder.JSONDecodeError: Expecting value: line 1 column 1 (char 0) が出ます。エラー位置が「line 1 column 1」なら、まず BOM を疑ってください。

EF BB BF 7B 22 6E 61 6D 65 22 3A 22 41 6C 69 63 65 22 7D
→ {"name":"Alice"}

7B 22 6E 61 6D 65 22 3A 22 41 6C 69 63 65 22 7D
→ {"name":"Alice"}

なぜ起きるか： Windows の「メモ帳」やいくつかの Excel エクスポート機能は、デフォルトで UTF-8 BOM 付きでファイルを保存します。UTF-16 には BOM が必須ですが、UTF-8 での BOM は「あってもよい」程度の存在であり、多くの JSON パーサは対応していません（RFC 8259 では UTF-8 BOM を明示的に禁止しています）。

よくある発生源： Excel でデータを CSV に書き出した後、それを加工して JSON にしたとき。Windows 端末でメモ帳を使って設定ファイルを編集したとき。CI/CD 環境では問題ないが、手元の Windows 環境でだけエラーになる、という症状ならまず BOM を疑います。

検出と除去： Linux/Mac なら file config.json コマンドで UTF-8 Unicode (with BOM) text と表示されます。除去は sed -i '1s/^\xEF\xBB\xBF//' config.json（macOS は sed -i '' '1s/...'）または VS Code でファイルを開き、右下のエンコーディング表示をクリックして「UTF-8 (BOM なし)」で保存し直します。

改行コードや見えない空白

JSON 文字列値の中に制御文字（U+0000〜U+001F）が直接含まれると不正です。また、非破壊スペース（U+00A0）やゼロ幅スペース（U+200B）、ゼロ幅非ジョイナー（U+200C）などが JSON のキーや値の周辺に混入すると、見た目は正常でもパーサが拒否します。エラーメッセージは Invalid character や Unexpected token（トークン部分が空白に見える）として出ます。

{"message": "Hello
World"}

{"message": "Hello\nWorld"}

なぜ起きるか： JSON の文字列定義では、エスケープされていない制御文字（U+0000〜U+001F）を文字列内に直接置くことを禁止しています。改行（U+000A）も制御文字なので、\n としてエスケープする必要があります。

よくある発生源： Web フォームから送信されたテキストを JSON に直接埋め込んだとき。特に <textarea> の内容はユーザーが自由に改行を入れられるため、バックエンドで JSON.stringify() を通さずに文字列連結で JSON を組み立てると改行が生で入ります。また、Wikipedia や Google Docs からコピーしたテキストには非破壊スペースが含まれていることが多く、これがキー名に混入すると「キーが存在するのに undefined が返る」という症状が出て非常に気づきにくいです。