APIが返ってこない…NetworkパネルでのAPIデバッグ手順

はじめに

「ボタンを押したのに画面が何も変わらない」「データが表示されるはずなのに空のまま」——フロントエンドの開発をしていると、こういった場面に一度は必ずぶつかります。原因がCSSなのかJavaScriptなのかAPIなのか、最初はどこから調べればいいかわからなくて途方に暮れることもありました。

そんなときに頼りになるのがNetworkパネルです。APIのリクエストとレスポンスをすべて記録してくれるので、「リクエストが飛んでいるか」「何が返ってきているか」を直接確認できます。この記事では、APIが返ってこないときにNetworkパネルでどう調査するかを、エラーの種類別に紹介します。

• ※本記事ではGoogle Chromeを前提に手順を紹介しています。
• ※本記事内のスクリーンショットは、検証用に https://httpbin.org の各エンドポイント（/delay/10、/status/404 など）を使って再現したものです。

まずNetworkパネルで確認すること

APIの問題を調査するとき、最初に確認するのは以下の2点です。

• リクエストが飛んでいるか — Networkパネルに該当のリクエストが表示されているか
• ステータスコードは何か — リクエストが飛んでいる場合、どんなコードが返ってきているか

Networkパネルはページを開いた状態でF12（またはCmd+Option+I）でDevToolsを開き、「Network」タブをクリックすると表示されます。リクエストの一覧が表示されない場合はページをリロードしてみてください。

一覧の中から調査したいAPIのリクエストを見つけたら、クリックして詳細を開きます。リクエストが多くて探しにくい場合は、上部のフィルター入力欄にAPIのURLの一部を入力すると絞り込めます。また「XHR」や「Fetch」フィルターを使うとAPIのリクエストだけを表示できるので便利です。

ステータスコードはリクエスト一覧の「Status」列に表示されています。コードによって原因と対処が変わるので、まずここを確認するのが調査の第一歩です。

リクエストが返ってこない（pendingのまま）ときの調査

ステータスコードが表示される前に、そもそもリクエストが「pending」のまま止まっているケースもあります。エラーが出ないぶん原因がわかりにくく、「フリーズしているのかエラーなのか判断できない」という状態になりがちです。

Networkパネルでの確認手順

該当リクエストの「Time」列を確認します。数値が表示されず「Pending」のままになっている場合、リクエストがまだ完了していません。

詳細を見るには「Timing」タブを開きます。ここでは以下のフェーズごとにかかった時間が表示されます。

• Waiting (TTFB) — サーバーがレスポンスを返すまでの待ち時間。ここが長い場合はサーバー側の処理（DB検索や外部API呼び出しなど）が遅い可能性が高い
• Content Download — レスポンスのダウンロードにかかった時間。レスポンスサイズが大きすぎる場合に伸びる
• Stalled — リクエストが送信待ちの状態。同時接続数の上限に達している場合などに発生する

「Waiting (TTFB)」が極端に長い、あるいはそのままタイムアウトしてしまう場合は、以下を確認すると原因の切り分けが早くなります。

• 同じAPIを直接叩いた場合（Postmanやcurlなど）でも同様に時間がかかるか確認し、フロント特有の問題かサーバー側の問題かを切り分ける
• サーバー側・フロント側それぞれで設定しているタイムアウト時間（axiosのtimeoutオプションなど）を確認する
• ネットワーク自体の問題（VPNやプロキシ経由でアクセスしている場合など）がないか確認する

「エラーコードが返ってこない＝正常」ではなく、「そもそも完了していない」というケースがあることを覚えておくと、調査の抜け漏れを防げます。

404 Not Found — リクエスト先のURLを確認する

404はサーバーが「そのURLは存在しない」と返しているエラーです。APIのエンドポイントのURLが間違っている場合がほとんどです。

Networkパネルでの確認手順

該当リクエストをクリックして「Headers」タブを開きます。「Request URL」に表示されているURLが正しいか確認します。

よくある原因は以下の通りです。

• URLのスペルミス（例：/users のつもりが /user になっている）
• 末尾のスラッシュの有無（/api/users と /api/users/ で挙動が変わる場合がある）
• 環境変数のURLが本番・開発で切り替わっておらず、存在しないURLを叩いている
• APIのバージョンが変わっていて古いURLを叩いている（例：/v2/users が /v1/users に変わっていた）

Request URLをそのままコピーしてブラウザのアドレスバーに貼り付けて直接アクセスしてみると、URLが正しいかどうかを手早く確認できます。

401 / 403 — 認証・権限エラーを調査する

401はリクエストに認証情報がない（または期限切れ）、403は認証はできているが権限がないというエラーです。見た目は似ていますが原因が異なります。

Networkパネルでの確認手順

「Headers」タブの「Request Headers」セクションを確認します。認証方式はAPIによって様々ですが、代表的な方法の一つとして、Authorization ヘッダーにトークンを付けて送る設計（Bearer認証など）がよく使われています。ここで確認すべきポイントは以下の通りです。

• Authorizationヘッダーが存在するか — そもそもヘッダーが送れていない場合、フロント側でトークンのセットが漏れている
• トークンの値が正しいか — Bearer の後ろにトークンが入っているか、値が空になっていないか確認する
• トークンが期限切れになっていないか — JWTの場合、トークンをデコードして有効期限（exp）を確認できる

注意：本番トークンを外部サイトに貼らない

JWTのデコードにはjwt.ioのようなツールが便利ですが、開発中のダミートークンであれば問題ない一方、本番環境で発行された実際のトークンを外部サイトに貼り付けるのはセキュリティ上おすすめできません。トークンの内容が第三者のサーバーに送信されるリスクがあるためです。

本番トークンを確認したい場合は、ブラウザのDevTools ConsoleでJWTのペイロード部分を自分でデコードする方法が安全です。

// JWTの構造: header.payload.signature
const token = "コピーしたトークン";
const payload = token.split('.')[1];
console.log(JSON.parse(atob(payload)));

Consoleにコードを貼り付けようとすると、Chromeが「allow pastingと入力してください」という警告を表示することがあります。これはコードの貼り付け全般に対する安全機能なので、指示に従って入力すれば問題なく先に進められます。

これでexp（有効期限）やiat（発行日時）などのクレームをローカルで確認できます。

また、「Response」タブを開くとサーバーからのエラーメッセージが確認できます。「Token expired」「Invalid token」など、エラーの原因が文字で返ってきていることも多いので、合わせて確認しておきましょう。

403の場合はトークン自体は有効でも、そのユーザーにそのリソースへのアクセス権限がないケースが多いです。「ログインはできているのにデータが取れない」という場合は、権限設定をバックエンド側と確認するのが近道です。

500 Internal Server Error — レスポンスの中身を確認する

500はサーバー側で何らかのエラーが起きていることを示します。フロントのコードには問題がなく、バックエンド側に原因があることがほとんどです。

Networkパネルでの確認手順

「Response」タブを開いて、サーバーから返ってきたエラーメッセージを確認します。サーバーの実装によっては、エラーの詳細がJSON形式で返ってくることがあります。

{
  "error": "Internal Server Error",
  "message": "Cannot read properties of undefined",
  "stack": "TypeError: Cannot read properties..."
}

このようなエラー情報が返ってきていれば、バックエンド側の問題であることを特定できます。エラーメッセージをそのままバックエンドの担当者に共有すると、原因の特定がスムーズになります。

実際にステータスコードが500になっているリクエストのHeadersタブを確認すると、以下のように「Status Code: 500 Internal Server Error」が表示されます。

同じリクエストの「Response」タブを開くと、実際にJSON形式でエラー内容が返ってきていることが確認できます。

ただし、常にJSON形式で返ってくるとは限りません。以下は実際に500系のステータスを検証した際のResponseタブの例ですが、サーバーやインフラ（ロードバランサーなど）の都合でJSONではなくHTML形式のエラーページが返ってくることもあります。この場合でも、まずは「何らかのサーバー側エラーが起きている」という事実がわかれば調査の第一歩としては十分です。

「Payload」タブも合わせて確認しておきましょう。フロントから送っているリクエストボディの中身が正しいか確認することで、「バックエンドが期待するデータ形式と異なるものを送っていた」という問題を切り分けられます。

上の例はGETリクエストのクエリパラメータ（Query String Parameters）が表示されているケースですが、POSTリクエストでbodyを送っている場合も同じ「Payload」タブの中に内容が表示されます。どちらの形式でも、ここで送信内容が意図した通りになっているかをまず確認するのが基本です。

500が返ってきたときに「フロントの問題かバックエンドの問題か」を切り分ける基本的な考え方は、「Payloadが正しければバックエンドの問題、Payloadが間違っていればフロントの問題」です。まずここを確認するだけで、原因の所在がかなり絞り込めます。

CORSエラー — コンソールとNetworkパネルを合わせて確認する

CORSエラーはやや特殊で、Networkパネルだけでは原因が把握しにくいエラーです。ブラウザが「別のオリジンへのリクエストが許可されていない」と判断してリクエストをブロックするため、Networkパネルでは正常に見えるのにデータが取れないという状況が起きます。

CORSエラーの見つけ方

CORSエラーが起きているときは、まずConsoleパネルに以下のようなメッセージが表示されます。

Access to fetch at 'https://www.yahoo.co.jp/' from origin 'https://httpbin.org'
has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present
on the requested resource.

このメッセージが出ている場合、Networkパネルで該当リクエストを確認すると「Response Headers」に Access-Control-Allow-Origin ヘッダーが存在しないか、許可されていないオリジンになっています。

上の例では、Response Headersの一覧の中に Access-Control-Allow-Origin が存在しないことがわかります。これがCORSエラーの直接の原因です。

CORSエラーの原因と対処

CORSはバックエンド側の設定で制御されています。フロントエンド側でできることは限られており、基本的にはバックエンドに Access-Control-Allow-Origin ヘッダーを正しく返してもらうよう依頼することになります。ただし、開発環境に限ってはフロント側のプロキシ設定で回避できる場合もあります。

また、CORSエラーはプリフライトリクエスト（OPTIONSメソッド）が失敗して起きるケースもあります。Networkパネルのフィルターを「All」にして、OPTIONSのリクエストが200を返しているかも合わせて確認してみてください。

リクエストが飛んでいないときの調査手順

Networkパネルを確認しても、そもそも該当のリクエストが一覧に表示されていない場合があります。このケースはAPIの問題ではなく、フロントのコードでリクエストが実行されていないことがほとんどです。

確認すべきポイントは以下の通りです。

• Consoleにエラーが出ていないか — リクエストを送る前の処理でエラーが起きて、処理が止まっている可能性がある
• fetch()やaxiosの呼び出しが実行されているか — ブレークポイントやconsole.logで、リクエストを送るコードが実際に到達しているか確認する
• 条件分岐で処理がスキップされていないか — if文の条件が想定と異なり、リクエストを送る処理がスキップされているケースがある
• Preserve logがオフになっていないか — ページ遷移やリダイレクトが絡む場合、Preserve logをオンにしないとログがリセットされてしまう

「Preserve log」はNetworkパネル上部のツールバーにあります。

「Networkパネルに何も表示されない＝APIの問題ではない」と切り分けられるだけで、調査の方向性がぐっと絞れます。

ステータスコード別チェックリスト

調査の起点として、よくあるパターンを表にまとめました。次に似た問題が起きたときの目印にしてください。

やってみてわかったこと

APIのデバッグで一番大事だと感じたのは、「フロントの問題かバックエンドの問題かを早めに切り分けること」です。どちらの問題かわからないまま闇雲にコードを触っても、時間だけが過ぎていきます。

Networkパネルを使えば、「リクエストは正しく飛んでいるか」「レスポンスは何が返ってきているか」をすぐに確認できます。この2点を最初に確認するだけで、「これはバックエンドに確認が必要な問題だ」「フロントのコードを直す必要がある」という判断がかなり速くなりました。

チーム開発では、バックエンドの担当者に「こういうリクエストを送ったら、こういうレスポンスが返ってきた」とNetworkパネルのスクリーンショットを添えて共有するだけで、やりとりがスムーズになることも多いです。

おわりに

APIが返ってこないときの調査は、慣れるまで「どこから手をつければいいかわからない」という状態になりがちです。でもNetworkパネルでリクエストとレスポンスを確認する習慣がつくと、ほとんどのケースで原因の見当がつくようになります。

まずは次に「APIがうまく動かない」という場面に遭遇したとき、Networkパネルを開いてステータスコードを確認するところから始めてみてください。