JSON Parse Error / Unexpected token の原因と解決方法

JSONを扱っていると、一度は遭遇するのが SyntaxError: Unexpected token というエラーメッセージです。API のレスポンスを処理しようとしたとき、設定ファイルを読み込もうとしたとき、突然このエラーが出て作業が止まってしまいます。

原因さえわかれば修正は簡単ですが、エラーメッセージだけでは何が悪いのか判断しづらいことも多いです。この記事では、JSON Parse Error の読み方と、よくある原因5つを具体例つきで解説します。

手っ取り早くエラー箇所を特定したい場合は、JSON Formatter にペーストすれば、エラーの行番号とともに原因が表示されます。

SyntaxError: Unexpected token の読み方

ブラウザやNode.jsでJSONをパースすると、構文エラーがある場合に次のようなメッセージが返ります。

SyntaxError: Unexpected token ' in JSON at position 42

このメッセージは3つの情報を含んでいます。

Unexpected token ' — パーサーが想定していない文字 '（シングルクォート）に遭遇した
at position 42 — JSON文字列の先頭から42文字目でエラーが発生した
SyntaxError — 構文自体が壊れている（値の問題ではなく、書き方の問題）

position の数値はバイト位置ではなく文字位置を指します。ただし、改行コードや空白もカウントされるため、手作業で数えるのは現実的ではありません。JSON Formatter のようなツールを使えば、該当箇所をすぐに特定できます。

よくある原因5つ

1. 末尾カンマ（trailing comma）

JavaScriptでは配列やオブジェクトの最後にカンマを付けても動作します。しかしJSONの仕様では、末尾カンマは許可されていません。

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

最後の 30, のカンマを削除する必要があります。

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

エディタのフォーマッタが自動で末尾カンマを付ける設定になっている場合、JSON ファイルでは無効にしておくとよいでしょう。

2. シングルクォート

Pythonの辞書やJavaScriptのオブジェクトでは ' を使えますが、JSONではダブルクォート " のみが有効です。

{'name': 'Alice'}

これは正しいJSONではありません。すべてダブルクォートに置き換えます。

{"name": "Alice"}

Pythonで辞書をJSON文字列にする場合は、str() ではなく json.dumps() を使ってください。str() はシングルクォートで出力してしまいます。

3. クォートなしのキー

JavaScriptではオブジェクトのキーにクォートが不要な場合があります。JSONでは、キーは必ずダブルクォートで囲む必要があります。

{name: "Alice"}

正しくはこう書きます。

{"name": "Alice"}

4. コメント

設定ファイルでよくある間違いです。JSONの仕様にはコメント構文が存在しません。

{
  // ユーザー名
  "name": "Alice"
}

// や /* */ はすべて取り除く必要があります。なお、tsconfig.json など一部のファイルはJSONC（JSON with Comments）という拡張仕様で書かれており、コメントが許可されています。ただし標準のJSONパーサーでは読めません。

JSONC・JSON5・_comment フィールド・除去スクリプトの使い分けは JSON にコメントは書ける？で詳しく比較しています。設定ファイルで「コメントを残したい」要件がある場合はそちらを参照してください。あるいは、JSONではなくYAMLで管理するという選択肢もあります。

5. BOM（Byte Order Mark）

UTF-8で保存したファイルの先頭にBOM（\uFEFF）が入っていると、パーサーがそれを不正な文字として検出します。

SyntaxError: Unexpected token  in JSON at position 0

at position 0 かつ見えない文字がトークンとして報告されている場合、BOMの可能性が高いです。テキストエディタでBOMなしUTF-8として保存し直すか、プログラム側で先頭のBOMを除去する処理を入れてください。

const cleaned = text.replace(/^\uFEFF/, '');
const data = JSON.parse(cleaned);

その他の原因

代表的な5つ以外にも、次のような原因でパースエラーが起きます。

括弧の対応ミス

閉じ括弧 } や ] が足りないと、多くの場合ファイル末尾でエラーが報告されます。ネストが深い JSON では、対応の取れていない括弧を目視で探すのは困難です。括弧の対応を表示できるフォーマッタを使うと時間を節約できます。

文字列内の制御文字

文字列の中に生の改行やタブが入っているとエラーになります。改行は \n のようにエスケープする必要があります。

{"message": "Hello
World"}

正しくは次のように書きます。

{"message": "Hello\nWorld"}

先頭ゼロのある数値

JSON の数値は先頭にゼロを付けられません。007 は不正な値で、7 などの標準的な数値表記にする必要があります。

undefined や NaN

JavaScript の undefined と NaN は JSON の値として使えません。undefined を含むオブジェクトをシリアライズすると、多くのシリアライザはそのキーを省略するかエラーを投げます。NaN や Infinity も同様に拒否されます。

環境ごとのエラーメッセージの違い

同じ構文エラーでも、エラーメッセージは実行環境によって異なります。検索するときの手がかりになるよう、代表的な環境のメッセージを整理します。

環境 / ランタイム	典型的なエラーメッセージ	読み取れること
ブラウザ (Chrome / Firefox)	`Unexpected token < in JSON at position 0`	先頭の `<` は、JSON ではなく HTML エラーページが返ってきたサイン。ネットワークタブで実際のレスポンスを確認する
Node.js	`Unexpected token } in JSON at position 142`	position の数値で位置を特定できる
Python	`json.decoder.JSONDecodeError: Expecting property name enclosed in double quotes: line 3 column 5`	行番号と列番号の両方を表示する
Java (Jackson)	`JsonParseException: Unexpected character ('}' (code 125)): was expecting double-quote to start field name`	期待した文字と実際の文字の両方を明示する

特にブラウザで Unexpected token < in JSON at position 0 が出た場合は、API が JSON ではなく HTML のエラーページ（404 や 500 のページ）を返している可能性がほぼ確実です。JSON の構文ではなく、リクエスト先やステータスコードを疑ってください。

FormatArc でエラー箇所を確認する

5つの原因を把握していても、数百行あるJSONファイルから問題箇所を目視で探すのは大変です。JSON Formatter を使えば、ペーストするだけでエラーの行番号と内容が日本語で表示されます。

使い方は3ステップです。

JSON Formatter を開く
左側のエディタにJSONを貼り付ける
「変換」ボタンを押す

正しいJSONであれば整形された結果が右側に表示されます。構文エラーがあれば、エラーメッセージに行番号が含まれるので、該当行を修正して再度変換すればよいでしょう。

ブラウザ内で処理が完結するため、APIキーや個人情報を含むJSONでも安心して使えます。データがサーバーに送信されることはありません。

パースエラーを未然に防ぐ

エラーが出てから直すよりも、いくつかの習慣でパースエラーの大半を防げます。

JSON を生成するときは文字列連結ではなく JSON.stringify()（各言語の標準シリアライザ）を使う
エディタで保存時に JSON を検証する設定を有効にする（VS Code・IntelliJ・Sublime Text はいずれも対応）
CI に検証ステップを追加する。python -m json.tool < config.json のような簡単なチェックで、本番に届く前に壊れたファイルを検出できる
手書きで編集するときは、リアルタイムに検証できるツールを使う

なお、信頼できないオンラインツールに業務データを貼り付けるのは避けてください。どのツールが安全かの見分け方はオンライン変換ツールは安全かで解説しています。FormatArc はすべての処理をブラウザ内で完結し、データを外部に送信しません。

JSON が適さない場合

コメントを書きたい、複数行の文字列を扱いたい、複雑なネスト設定を管理したいといった要件で JSON の制約と頻繁に戦っているなら、YAML を検討する価値があります。YAML はコメントに対応し、複数行テキストも自然に扱え、設定ファイルとしては読みやすいことが多いです。

ただし YAML はインデントに敏感で、暗黙の型変換など独自の落とし穴もあります。両者は必要に応じて相互変換できるので、ケースに応じて使い分ければ十分です。詳しくは YAML と JSON の違いを参照してください。

まとめ

JSON Parse Error の大半は、この記事で紹介した5つのパターンのいずれかに該当します。エラーメッセージの Unexpected token と position を手がかりに原因を絞り込めますが、ファイルが大きい場合はツールに頼るのが効率的です。

JSONの書き方に不安がある場合は、JSONの書き方ガイドも参考にしてください。整形の基本テクニックについてはJSON整形の基本でまとめています。Chrome 拡張でAPIレスポンスを自動整形したい場合は、JSON整形のChrome拡張おすすめ比較も参考になります。curl で API レスポンスをデバッグ中に構文エラーに遭遇した場合は、curl レスポンスの JSON 整形方法で jq や python を使ったワンライナー整形を解説しています。