FormatArc JSON Formatter の実行結果FormatArc JSON Formatter の実行結果
公開日: 2026-03-18更新日: 2026-07-29

JSON Parse Error の原因5つと解決方法｜Unexpected token の読み方

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

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

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

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
}

配列でも同じエラーが起きます。

{
  "colors": ["red", "green", "blue",]
}

"blue" の後ろのカンマを削除すればパースできます。エディタのフォーマッタが自動で末尾カンマを付ける設定になっている場合、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の可能性が高いです。ファイルから取り除く方法は 3 つあります。

  • VS Code: ステータスバーのエンコーディング表示をクリックし、「エンコーディング付きで保存」から BOM なしの「UTF-8」を選ぶ
  • コマンドライン: sed -i '1s/^\xEF\xBB\xBF//' file.json
  • hex エディタ: ファイル先頭の 3 バイト（UTF-8 BOM の EF BB BF）を削除する

ファイルの保存方法を制御できない場合（ユーザーのアップロードを読み込むときなど）は、プログラム側で先頭の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 も同様に拒否されます。

症状別の直し方: token u / token o / end of input

エラーメッセージに含まれる文字そのものが、原因を大きく絞り込む手がかりになります。次の 3 つの変種はいずれも JSON ファイルの中身ではなく、「パーサーに渡す前」の段階に問題があるパターンです。なお Unexpected token < が出た場合は JSON ではなく HTML が返ってきたサインです（後述の環境別エラーメッセージ表を参照）。

Unexpected token u in JSON at position 0

JSON.parse に文字列 "undefined" が渡っています。u はその 1 文字目です。パースしようとした値が、その時点で undefined だったことをほぼ確実に意味します。

const raw = localStorage.getItem("settings"); // キーが存在しないと null
JSON.parse(undefined); // SyntaxError: Unexpected token u in JSON at position 0

パースの前に値が本当に存在するか確認してください。本文が空の API レスポンス、存在しないストレージキー、変数名のタイプミスが典型的な原因です。

Unexpected token o in JSON at position 1

"[object Object]" という文字列をパースしようとしたときのエラーです。position 0 の [ は配列の開始として妥当なので、パーサーは position 1 の o で失敗します。JSON 文字列ではなく JavaScript オブジェクトそのものを JSON.parse に渡すと、暗黙の文字列変換によってこの形になります。

const data = { name: "Alice" };
JSON.parse(data); // data が "[object Object]" に変換され Unexpected token o

その値はすでにパース済みです。そのまま使うか、ディープコピーが目的なら stringify / parse の往復ではなく structuredClone(data) を使ってください。

Unexpected end of JSON input

JSON が完結する前に文字列が終わっています。よくあるのは空文字列（JSON.parse("")）と、途中で切れたレスポンス（中断されたネットワークリクエストや書き込み途中のファイル）の 2 つです。まず生の文字列の長さをログに出してください。長さが 0 なら、問題は JSON の構文ではなくパーサーに渡す前の段階にあります。

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

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

環境 / ランタイム典型的なエラーメッセージ読み取れること
ブラウザ (Chrome / Firefox)Unexpected token < in JSON at position 0先頭の < は、JSON ではなく HTML エラーページが返ってきたサイン。ネットワークタブで実際のレスポンスを確認する
Node.jsUnexpected token } in JSON at position 142position の数値で位置を特定できる
Pythonjson.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 の構文ではなく、リクエスト先やステータスコードを疑ってください。

デバッグの切り分け手順

エラーが数行のファイルなら目視で直せますが、API レスポンスや大きなファイルでは、切り分けの順序を決めておくと速く解決できます。

  1. JSON Formatter にペーストして、エラーの行番号と内容を確認する
  2. 報告された position の少し手前まで確認する。実際のミスはエラー位置より前の行にあることが多い（例: 10 行目のカンマ漏れが 11 行目でエラーになる）
  3. 上で挙げた原因 5 つ（末尾カンマ・シングルクォート・クォートなしキー・コメント・BOM）に該当しないか確認する
  4. コードが生成した JSON なら、シリアライズ処理を確認する。文字列連結で JSON を組み立てている箇所は典型的なバグの温床
  5. API から受け取った JSON なら、パースの前に生のレスポンスとエンコーディングを確認する

fetch でレスポンスを受け取る場合は、response.json() を使う前に生テキストとステータスを確認すると、HTML エラーページ・空レスポンス・途切れたレスポンスを 1 箇所で見分けられます。

const response = await fetch("/api/data");
const raw = await response.text(); // response.json() ではなく、まず生テキストで受ける

if (!response.ok) {
  console.error(`HTTP ${response.status}:`, raw.slice(0, 200));
} else if (!raw) {
  console.error("レスポンス本文が空"); // Unexpected end of JSON input の典型原因
} else {
  try {
    const data = JSON.parse(raw);
  } catch (e) {
    console.error("JSON parse 失敗:", e.message, raw.slice(0, 200));
  }
}

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

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

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

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

正しい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 を使ったワンライナー整形を解説しています。