外部JSONの読み込みでパースエラーになるときの確認点

取得成功とパース成功は別物

fetchがステータス200を返しても、中身が正しいJSONとは限りません。Networkでは取れているように見えても、返ってきた本文がHTMLのエラーページだったり、末尾に余計な文字が混じっていたりすると、パースの段階で落ちます。

まず切り分けるべきは「取得は成功しているか」と「中身が正しいJSONか」の2点です。取得が失敗しているなら404やパスの問題、取得は成功しているのにパースで落ちるなら、中身そのものを疑います。

Content-Typeの不一致を疑う

サーバーが返すContent-Typeがapplication/jsonでなくtext/htmlなどになっていると、本文がJSONでなくエラーページのHTMLである可能性があります。Networkで該当リクエストのResponseを開き、中身が本当にJSONかHTMLかを目で確認すると、原因が一気に絞れます。

よくあるのは、パスのずれで本来のJSONではなく404のHTMLページが返り、それをJSONとしてパースしようとして失敗するケースです。エラー文に予期しないトークンが出ているときは、本文の先頭が < で始まっていないか（HTMLでないか）を疑うと当たります。

症状別チェック表

外部JSONの読み込みでパースエラーになるときの確認点は、症状を分けずに直そうとすると原因探しが長引きます。まず「自分だけで起きるのか」「全員で起きるのか」「特定ブラウザだけか」「差し替え後だけか」を切り分けます。

確認順序を固定すると、相対パス、ファイル名、キャッシュ、認証、外部読み込みのどこで止まっているかが見えます。修正後はローカル確認だけで終わらせず、実際の共有URLで再表示して、相手と同じ条件で直ったことを確認します。

• 自分だけ表示されない: キャッシュ、ログイン状態、ブラウザ拡張、端末幅を確認する
• 全員で表示されない: ファイル構成、相対パス、大文字小文字、アップロード漏れを見る
• 一部だけ崩れる: CSS/画像/JSごとに読み込みエラーを分ける
• 差し替え後だけ古い: URL、キャッシュ、更新対象ファイルの取り違えを確認する

パースエラーの原因を切り分ける手順

中身を直接見れば、何が混入してパースを壊しているかはたいてい分かります。次の順で確認します。

1. F12のNetworkで該当JSONのResponseタブを開き、本文を目視する
2. 先頭が { や [ で始まっているか、< で始まるHTMLになっていないか確認する
3. 末尾に余計なカンマや文字、複数のオブジェクトが連結されていないか見る
4. Content-Typeがapplication/json系になっているか確認する
5. 本文をそのままコピーして、JSONとして妥当かをチェックする

BOMや不可視文字の混入

ファイル先頭にBOM（バイトオーダーマーク）という不可視の文字が付いていると、見た目は正しいJSONでもパースが先頭で失敗することがあります。エディタの保存形式をBOMなしのUTF-8にすると解消することが多いです。

ほかにも、全角スペースの混入、末尾の余分なカンマ、コメント（JSONはコメント非対応）の書き込みなどが定番の原因です。見た目では分かりにくいので、本文を妥当性チェックにかけて、何行目の何が悪いかを機械的に特定すると早く直せます。

正しく配信される環境で確認する

Content-Typeの扱いやファイルの返り方は配信環境によって変わるため、ローカルで直接開いた状態だけでは本番の挙動を再現できません。本番に近い配信でResponseを確認しながら直すのが確実です。

ギガサイト便はJSONを含むZIPをドロップすると 〇〇.giga-site.com でHTTPS配信され、NetworkのResponseで実際に返る本文とContent-Typeを確認できます。本文がHTMLになっていないか、BOMが混じっていないかを見ながら直し、同じURLのままZIPを差し替えて再検証できます。関係者だけで切り分けたいときは認証を併用すると安全です。