現場で使えるChrome DevTools実践ガイド 第8章:NetworkパネルでのHTTP通信確認

Webアプリは、ユーザーの操作に応じてサーバーと通信し、データを取得・送信しています。
通信が失敗する、期待したデータが取得できない、CORSエラーが発生するなどの問題に直面したとき、最も頼れるのが「Networkパネル」です。

この章では、HTTPリクエストの中身の確認やレスポンスタイムの分析、CORSエラーの読み解き方までを解説し、通信トラブルを可視化して根本原因を突き止める力を身につけます。


8.1 リクエスト/レスポンスの内容確認

Networkパネルでは、ページで発生した全てのリクエスト(HTML/CSS/JS/APIなど)を一覧で確認できます。

基本の操作:

  1. ページをリロードしてリクエスト一覧を表示
  2. 気になる行をクリック → 詳細ペインが表示される
  3. Headers, Payload, Response, Preview などで詳細確認

チェックポイント:

  • Request URL:どこにリクエストしているか
  • Request Method:GET / POST / PUT / DELETE など
  • Request Payload:送信したパラメータ(POSTのFormやJSONなど)
  • Response:サーバーから返ってきた生データ(JSON, HTMLなど)

💡 ユースケース:

  • APIから「空のレスポンスが返る」→ 実はクエリパラメータが間違っていた
  • ボタン押下時に通信が起きない → JavaScriptエラーでAPI呼び出しに至っていなかった

8.2 ステータスコード、レスポンスタイム、ヘッダーの理解

ステータスコードの基本:

  • 200:成功
  • 304:キャッシュから読み込み(通信自体は行われていない)
  • 404:リソースが見つからない
  • 500:サーバー内部エラー
  • 403 / 401:認証・認可エラー

レスポンスタイム確認:

  • Networkパネルの「Waterfall(滝グラフ)」で、DNS, 接続, リクエスト, レスポンスの時間を色分けで確認
  • 表示列に「Time」「Latency」「Size」などを追加して比較分析も可能

ヘッダーの見どころ:

  • Request HeadersAuthorizationContent-Type など
  • Response HeadersContent-Type, Cache-Control, Access-Control-Allow-Origin など

💡 活用例:

  • 「APIにリクエストは飛んでいるのに反応がない」→ CORS ポリシーによりレスポンスがブロックされていた
  • 「画像の読み込みが遅い」→ サーバーの Cache-Control ヘッダーが正しく設定されていなかった

8.3 CORSエラーの読み解き

CORS(Cross-Origin Resource Sharing)エラーは、異なるオリジン(ドメイン/ポート/プロトコル)間の通信制限によって起こるブラウザのセキュリティ機構です。

よくあるCORSエラー:

  • Access to fetch at 'https://api.example.com' from origin 'http://localhost:3000' has been blocked...
  • 原因:サーバーが Access-Control-Allow-Origin を適切に返していない

DevToolsでの確認ポイント:

  • Networkタブでリクエストを選択し、「Response Headers」に Access-Control-* ヘッダーがあるか確認
  • OPTIONS メソッド(プリフライトリクエスト)の有無やステータスコードにも注意

解決の方向性(サーバー側対応):

  • サーバーが Access-Control-Allow-Origin: * もしくは適切なドメインを返すよう設定
  • Access-Control-Allow-Methods, Access-Control-Allow-Headers などの設定も併せて確認

💡 開発時の一時回避:

  • Chromeの CORS 拡張を使う(本番ではNG)
  • proxy 設定(例:Reactの vite.config.tswebpack-dev-server

🧑‍💻 実践課題

課題:バックエンドAPIとの通信が「成功しているのに表示されない」原因を調査せよ

  1. Network タブで該当APIのリクエストを特定
  2. Request Payload を確認し、送信データに誤りがないか確認
  3. Response タブで返却されたJSONデータを確認
  4. ステータスコードが200でも、Preview で中身が空、または想定外であることを確認
  5. JavaScriptでの描画処理に進んで調査

📝 まとめ

  • Networkパネルは、HTTPリクエスト/レスポンスのすべてを可視化する最重要ツール
  • レスポンスの中身、ステータスコード、通信時間、ヘッダー情報の確認が可能
  • CORSエラーはクライアントではなくサーバー側の設定ミスで起こることがほとんど。エラー文とヘッダーで原因を特定できる

Networkパネルを使いこなせば、API連携の失敗の**“見えない壁”が見えるようになり、冷静に対処できるようになります。**

mh

Related Posts

現場で使えるChrome DevTools実践ガイド 第9章:Applicationパネルとストレージの確認

現場で使えるChrome DevTools実践ガイド 第7章:Performanceパネルでパフォーマンス分析

You Missed

Google Cloud Platform エンジニア向け教科書:実践から認定まで : 第3章:IAM(Identity and Access Management):GCPの「誰が」「何に」「何ができるか」を管理する門番

  • 投稿者 mh
  • 6月 2, 2025
  • 1 views

現場で使えるChrome DevTools実践ガイド 第9章:Applicationパネルとストレージの確認

  • 投稿者 mh
  • 6月 2, 2025
  • 2 views

Kubernetes Learning 第29章:RBACの基礎とロール設計 〜「誰が、何を、どこで」できるのかを制御する〜

  • 投稿者 mh
  • 6月 2, 2025
  • 4 views

Android application development 第33章:実践ミニアプリ:天気情報アプリ

  • 投稿者 mh
  • 6月 2, 2025
  • 4 views

Google Cloud Platform エンジニア向け教科書:実践から認定まで : 第2章:リージョンとゾーン、グローバルリソース:GCPの「物理的な場所」の考え方

  • 投稿者 mh
  • 6月 1, 2025
  • 8 views

現場で使えるChrome DevTools実践ガイド 第8章:NetworkパネルでのHTTP通信確認

  • 投稿者 mh
  • 6月 1, 2025
  • 13 views