JSONのエラーを直す|Unexpected tokenから原因行を見つける手順

JSON.parseで構文エラーが出たときに、エラー位置の読み方、末尾カンマや引用符、改行とエスケープ、巨大JSONの切り分け、修正後の検証まで順番に解説します。

「Unexpected token」などのJSONエラーは、構文解析が止まった位置から前へ戻ると原因を絞れます。この記事では、値をダミー化した例で確認順を説明します。実行環境によってエラー文は異なりますが、基本の切り分け方は共通です。

1. JSONとJavaScriptオブジェクトの違いを押さえる

JSONはJavaScriptのオブジェクト記法に似ていますが、データ交換用のテキスト形式です。値はオブジェクト、配列、文字列、数値、truefalsenullに限られます。キーと文字列は二重引用符で囲み、末尾カンマを置きません。コメント、undefined、関数、NaNInfinityも使えません。これらの文法は、JSONの標準であるRFC 8259で定義されています。

たとえばJavaScriptの{ user: 'sample' }は、JSONでは{ "user": "sample" }と書きます。「JavaScriptとして書けるか」ではなく「JSONの文法に合うか」を見ます。設定ファイルの場所も不明なら、Claude Codeのフォルダ構成と設定ファイルの基本を先に確認します。

2. エラー位置は止まった地点として読む

JSON.parseは不正な入力でSyntaxErrorを投げます。文面は環境によって「Unexpected token」「at position 42」「line 3 column 8」などと異なります。表示位置は原因そのものではなく解析が止まった地点の場合があるため、直前のキー、値、区切りまで戻ります。

try {
  const data = JSON.parse('{"name":"sample","active":true,}');
} catch (error) {
  if (error instanceof SyntaxError) {
    console.error('JSON構文エラー:', error.message);
  } else {
    throw error;
  }
}

元のJSON全文や秘密を出さず、種類とメッセージだけ記録します。

エラー文に位置が出ない環境では、入力を短くしたコピーで再現させます。ログ自体の読み方が分からない場合は、Codexが途中で止まる原因をログから切り分ける方法も参考にしてください。

3. 末尾カンマと引用符を先に直す

最初に末尾カンマと引用符を見ます。次の例は、配列とオブジェクトの末尾に余分なカンマがあります。

 {
   "name": "sample",
   "roles": [
     "editor",
-    "viewer",
+    "viewer"
   ],
-  "active": true,
+  "active": true
 }

]}の直前にはカンマを置かず、キーと文字列には"を使います。一括置換を避け、エラー付近から一組ずつ半角記号で直します。

4. 改行とバックスラッシュのエスケープを確認する

文字列内の改行は\n、二重引用符は\"、バックスラッシュ自体は\\と書きます。

 {
-  "message": "1行目
-2行目",
-  "path": "C:\work\data.json"
+  "message": "1行目\n2行目",
+  "path": "C:\\work\\data.json"
 }

Windowsのパスでは\n\tが改行やタブになる場合があります。JavaScript文字列内ではエスケープが二段階になるため、.jsonファイルとソース内文字列のどちらを直すか先に固定します。

5. 巨大JSONは構造を保って小さく切る

巨大JSONはコピーを作り、秘密をダミー化します。位置が不明なら、トップ階層の要素やプロパティ単位で半分に分けます。文字数で切らず、{}[]を対応させて単独で解析できる形にします。

JSON.parseに失敗する側をさらに分け、最小単位まで絞ります。機密データはオンラインサービスへ貼らず、ローカルで検証します。

6. 修正後は構文と中身を別々に確かめる

JSON.parseの成功は構文が正しいという意味です。必要なキーの欠落や型の違いまでは検出しないため、期待する構造も確認します。JSON.parseが不正なJSONでSyntaxErrorを投げる動作は、ECMAScript仕様に定められています。

try {
  const data = JSON.parse(
    '{"name":"sample","roles":["editor"],"active":true}'
  );

  if (
    typeof data.name !== 'string' ||
    !Array.isArray(data.roles) ||
    typeof data.active !== 'boolean'
  ) {
    throw new Error('JSONの構造が想定と違います');
  }

  console.log('構文と構造を確認できました');
} catch (error) {
  console.error(error instanceof Error ? error.message : '不明なエラー');
}

修正前後を残し、「構文」「キーと型」「実処理」の順にテストします。

項目が多い場合や、同じ形式を継続して受け取る場合は、手書きの条件分岐だけでなくJSON Schemaも選択肢になります。JSON Schema Draft 2020-12では、JSON文書の構造を記述する中核仕様と、typerequiredなどで検証する語彙が定義されています。利用するライブラリが対応するDraft(仕様の版)は事前に確認してください。

7. 原因別の早見表

症状・エラー付近よくある原因最初に確認する箇所修正の方向
}または]の直前末尾カンマ直前の値の末尾最後のカンマを削除する
キーや文字列の先頭一重引用符、引用符の閉じ忘れ対になる二重引用符半角の"で囲む
文字列の途中未エスケープの改行・\"エラー位置の直前\n\\\"へ直す
NaNInfinity付近JSONにない数値表現値の生成元有限の数値かnullなどへ設計し直す
解析は成功するが処理で失敗キー不足、型の違い利用側が期待する構造キーと型を検証する
同名キーで値が変わるオブジェクト内のキー重複同じ階層のキー名キーを一意にする

RFC 8259はオブジェクトのキーを一意にすることを推奨しており、重複時の扱いは実装によって異なると説明しています。構文エラーにならない環境でも、同名キーは残さないほうが安全です。

8. よくある質問

Unexpected tokenは表示された文字を直せば解決しますか?

必ずしもそうではありません。表示された文字は解析が止まった地点で、原因が直前のカンマ、引用符、エスケープ漏れにある場合があります。位置の少し前から区切り記号を確認します。

JSONにコメントを書けますか?

標準のJSONにはコメント構文がありません。説明が必要なら別文書へ分けるか、利用側の仕様が許す場合だけ説明用のキーを設けます。JSONCなどの拡張形式は、標準JSONとして読む処理ではエラーになる可能性があります。

JSON.parseで成功すればデータは正しいですか?

構文は正しいと判断できますが、必要なキーや値の型までは保証されません。解析後にコードで確認するか、対応ライブラリを使ってJSON Schemaで検証します。

オンラインのJSON整形サービスへ貼ってもよいですか?

公開して問題ないデータに限ります。APIキー、個人情報、未公開の設定を含む場合は貼らず、ローカル環境で検証してください。整形方法を選びたい場合は、JSON整形ツールの比較も参考になります。

WindowsのパスをJSONへ書くとエラーになるのはなぜですか?

JSONの文字列では\がエスケープの開始記号だからです。.jsonファイルでC:\workを表すなら"C:\\work"と書きます。パス固有の切り分けは、Claude CodeでWindowsパスのエラーを直す方法も参照してください。

関連記事


一次情報の確認メモ(2026-07-24確認)

続き(結論と実データ)はnoteに置いています

ここでは手順のところまで書きました。実際に出た数字、うまくいかなかった条件、そのまま使える設定ファイルは、 note の記事にまとめてあります。

noteで続きを読む Xをフォローする