HTTPリクエストとレスポンスを覗く — DevToolsで通信の中身を見る
バイブコーディング入門 — 第6回
前回までのおさらいと、今回のテーマ
第4回ではURLを5つのパーツに分解し、第5回ではURLの良い名前の付け方（RESTful）とCRUDを学んだ。URLは「住所」であり、良い住所には一定のルールがあるということだった。
今回のテーマは、その住所に「手紙」を届けるとき、実際に何が起きているのかを自分の目で確認することだ。
第1回で「Webアプリは手紙のやりとりで動いている」と説明した。ブラウザ（あなた）がサーバー（お店）にリクエスト（注文書）を送り、サーバーがレスポンス（商品）を返す。このやりとりは画面の裏側で毎秒何十回と行われている。
でも、普段この「手紙」を見ることはない。ページが表示されたら、それで終わりだ。
ところが、ブラウザにはこの手紙の中身を覗ける機能が最初から入っている。それがDevTools（デブツールズ）だ。正式には「開発者ツール」と呼ぶが、開発者でなくても使える。エラーが起きたとき「画面の裏で何が起きているか」を確認できるので、AIに的確な情報を伝えられるようになる。
この記事では、DevToolsの中でも「Networkタブ」（ネットワークタブ）だけに集中する。ここを見れば、ブラウザとサーバーの間でやりとりされている手紙の一覧と、その中身がすべて分かる。
DevToolsを開いてみよう
まず、DevToolsを開く方法を確認しよう。Google Chrome（グーグルクローム）を例に説明するが、Microsoft Edge（エッジ）でもほぼ同じ操作だ。
開き方は3つある。
1つ目: キーボードのF12キーを押す（Windowsの場合）。Macの場合は Command + Option + I を同時に押す。
2つ目: ページの何もないところを右クリックして「検証」（または「Inspect」）を選ぶ。
3つ目: Chromeのメニュー（右上の3つの点）→「その他のツール」→「デベロッパー ツール」を選ぶ。
どの方法でも同じ画面が開く。画面の右側か下側に、新しいパネルが表示されるはずだ。
パネルの上部にタブが並んでいる。Elements、Console、Sources、Networkなど。今回使うのは「Network」タブだ。これをクリックする。
Networkタブを開いた状態で、ページを再読み込み（F5キー、またはCommand + R）すると、画面にたくさんの行が表示される。1行が1つの「手紙のやりとり」だ。ページを1回表示するだけで、数十から数百の通信が行われていることが分かる。
Networkタブの見方
Networkタブに表示される一覧表の、主な列を説明する。
Name（名前）は、リクエスト先のURLだ。ファイル名や、APIのパスが表示される。たとえば page.tsx や /api/users といった文字列が見える。
Status（ステータス）は、サーバーからの返事を3桁の数字で表したものだ。この数字が通信の結果を教えてくれる。よく見るものを挙げる。
- 200: 成功。問題なくデータが返ってきた
- 301 / 302: 転送。「そのページは引っ越しました」という意味
- 404: 見つからない。URLに対応するページやデータが存在しない
- 500: サーバーエラー。サーバー側で何か問題が起きた
200番台は「うまくいった」、300番台は「別の場所を見て」、400番台は「あなたのリクエストに問題がある」、500番台は「サーバー側の問題」と覚えておくと便利だ。
Type（種類）は、取得したデータの形式だ。htmlはページの構造、cssはデザイン、jsは動作のプログラム、jsonはデータ、png/jpg/webpは画像。
Size（サイズ）とTime（時間）は、データの大きさと取得にかかった時間だ。ページの表示が遅いとき、どの通信に時間がかかっているかを特定するのに使える。
1つのリクエストを詳しく見る
Networkタブの一覧から、1つの行をクリックすると、その通信の詳細が右側（または下側）に表示される。ここに「手紙の中身」がすべて書いてある。
詳細パネルには複数のタブがある。重要なものを3つ紹介する。
Headers（ヘッダー）— 手紙の封筒
Headers（ヘッダー）は、手紙の「封筒」にあたる部分だ。中身（本文）ではなく、誰が誰にどういう形式で送ったかという情報が書かれている。
Request Headers（リクエストヘッダー）は、ブラウザがサーバーに送った封筒だ。主な項目を見てみよう。
- Request URL: リクエスト先のURL（宛先）
- Request Method: GET、POSTなどのHTTPメソッド（第5回で学んだもの）
- Content-Type: 「この手紙の中身はこういう形式です」という宣言
- User-Agent: 「この手紙を送っているのはChromeブラウザです」という自己紹介
Response Headers（レスポンスヘッダー）は、サーバーが返した封筒だ。
- Status Code: 200、404などの結果コード
- Content-Type: 「返すデータの形式はJSONです」「HTMLです」という宣言
ヘッダーの項目は数十個あるが、全部を理解する必要はない。エラーが起きたとき、Status CodeとRequest URLを確認できれば十分だ。
Preview / Response — 手紙の中身
Preview（プレビュー）またはResponse（レスポンス）タブには、サーバーから返ってきたデータの本体が表示される。
HTMLページなら、ページのソースコードが見える。API（/api/users のようなURL）なら、JSONデータが整形された状態で表示される。たとえば次のような内容だ。
{ "users": [ { "id": 1, "name": "田中太郎", "email": "tanaka@example.com" }, { "id": 2, "name": "佐藤花子", "email": "sato@example.com" } ] }
これが、サーバーからブラウザに送られてきた「手紙の中身」だ。ブラウザはこのデータを受け取って、画面に表示している。
Previewタブは見やすく整形された状態、Responseタブは生のテキストデータが表示される。内容は同じだ。
Timing — 手紙の配達時間
Timing（タイミング）タブには、通信にかかった時間の内訳が表示される。接続にどれくらいかかったか、サーバーの処理にどれくらいかかったか、データのダウンロードにどれくらいかかったか。
ページの表示が遅いとき、このタブを見れば「サーバーの処理が遅いのか」「データが大きすぎてダウンロードに時間がかかっているのか」が分かる。ただし、使うのは速度の問題が起きたときだけでよい。
エラーが起きたときのDevToolsの使い方
DevToolsの真価は、何か問題が起きたときに発揮される。3つの典型的なシナリオを見てみよう。
シナリオ1: ページにデータが表示されない
CursorやClaude Codeで作ったアプリを開いたら、ページは表示されるがデータが空っぽ。商品一覧があるはずなのに、何も出てこない。
Networkタブを開いて、赤く表示されている行を探す。赤い行はエラーが起きた通信だ。たとえば /api/products のStatusが404になっている。
この情報があれば、AIに正確に伝えられる。「/api/products にアクセスすると404が返っています。app/api/products/route.ts ファイルが正しい場所にあるか確認してもらえますか」。
第4回で学んだURL構造の知識と組み合わせると、原因の見当がつけやすくなる。
シナリオ2: ボタンを押しても何も起きない
「保存」ボタンを押したのに、画面に変化がない。保存されたのか、されていないのか分からない。
Networkタブを見ると、ボタンを押した瞬間に新しい行が追加されるはずだ。その行のStatusが500になっていたら、サーバー側でエラーが起きている。Responseタブを見れば、エラーの詳細メッセージが書いてあることが多い。
「保存ボタンを押すと POST /api/tasks に送信されますが、500エラーが返っています。レスポンスに 'Column name cannot be null' と出ています」。これだけ伝えれば、AIはデータベースのカラム名の問題だとすぐに分かる。
シナリオ3: ページの表示が異常に遅い
ページは開くが、表示されるまで10秒以上かかる。
Networkタブで、Timeの列を確認する。どの通信に時間がかかっているかが一目で分かる。たとえば /api/reports のリクエストに8秒かかっていたら、レポートデータの取得が遅いということだ。
「/api/reports のレスポンスに8秒かかっています。データ量が多すぎるか、クエリが重いかもしれません」と伝えれば、AIは適切な対処法（ページネーション、キャッシュなど）を提案してくれる。
Networkタブのフィルター機能
通信の数が多くて目的の行を見つけにくいとき、フィルター機能が便利だ。Networkタブの上部にフィルターボタンが並んでいる。
- All: すべての通信を表示（デフォルト）
- Fetch/XHR: APIへの通信だけを表示。アプリのデータ取得を確認したいときに使う
- JS: JavaScriptファイルだけを表示
- CSS: スタイルシートだけを表示
- Img: 画像だけを表示
- Doc: HTMLドキュメントだけを表示
バイブコーディングで最もよく使うのは「Fetch/XHR」フィルターだ。これをクリックすると、ページの見た目に関する通信（画像やCSS）が消えて、APIとのデータのやりとりだけが表示される。エラー調査のときは、まずこのフィルターをかけると見通しが良くなる。
手を動かして確認してみよう
理屈だけでは分かりにくいので、実際に手を動かしてみよう。特別なアプリは不要だ。普段使っているWebサイトで練習できる。
ステップ1: DevToolsを開く
Chromeで好きなWebサイト（Amazonでも、Xでも、noteでも）にアクセスする。F12キー（Macの場合はCommand + Option + I）でDevToolsを開き、Networkタブを選ぶ。
ステップ2: ページを再読み込みする
F5キー（MacはCommand + R）でページを再読み込みする。Networkタブに通信の一覧がずらりと表示される。
ステップ3: 通信の数を見る
一覧の下部に「○○ requests」と表示されている。1ページを表示するだけで、これだけの通信が行われている。
ステップ4: 1つの行をクリックして中身を見る
Statusが200になっている行を1つクリックして、Headersタブを確認する。Request URLやStatus Codeが表示されているはずだ。
ステップ5: Fetch/XHRフィルターをかけてみる
上部のフィルターから「Fetch/XHR」を選ぶ。表示が大幅に減り、データのやりとりだけが見える。Responseタブを開くと、JSONデータが表示されていることがある。
この5つのステップを1回やるだけで、DevToolsの基本的な使い方が身につく。
AIにエラー情報を伝えるテンプレート
DevToolsで確認した情報をAIに伝えるとき、次のテンプレートを使うとスムーズだ。
（症状）〇〇のページで△△が表示されません。 （DevToolsの情報）Networkタブを確認したところ、□□へのリクエストが×××（ステータスコード）を返しています。 （レスポンスの内容）レスポンスに「▲▲」というメッセージが含まれています。
具体例:
「商品一覧ページで商品が表示されません。Networkタブを確認したところ、GET /api/products へのリクエストが500エラーを返しています。レスポンスに 'relation products does not exist' というメッセージが含まれています」
この伝え方をすると、AIは「データベースに products テーブルが存在しない」という原因に即座にたどり着ける。「画面が動きません」という伝え方だと、AIは何十もの可能性を検討しなければならない。
よくある不安と答え
DevToolsを開くとサイトが壊れたりしないか？
壊れない。DevToolsは「見るだけ」のツールだ。通信の内容を眺めているだけで、サイトには何の影響もない。いつでも閉じられるし、閉じれば元に戻る。安心して開いてほしい。
Networkタブに表示される情報は他の人に見られるか？
あなた自身のブラウザの中だけの話だ。DevToolsに表示される情報は、あなたのパソコン上でだけ見える。他の人に送信されることはない。
エラーの赤い行が出ていても気にしなくていいものはあるか？
ある。広告や解析ツールの通信がエラーになっていることがある。これらはサイトの動作には影響しないことが多い。自分が作っているアプリの場合、/api/ で始まるURLの通信や、自分のドメインの通信に注目すれば十分だ。
Safariでも同じことができるか？
できる。ただし、Safariでは最初にDevToolsを有効にする設定が必要だ。「Safari」メニュー→「設定」→「詳細」→「Webデベロッパ用の機能を表示」にチェックを入れる。その後は、Command + Option + I で開ける。表示される内容はChromeとほぼ同じだ。
まとめ
DevTools（開発者ツール）のNetworkタブを使えば、ブラウザとサーバーの間で行われている通信の一覧と中身を確認できる。ステータスコード（200は成功、404は見つからない、500はサーバーエラー）を見れば通信の結果が分かり、ResponseタブやPreviewタブでデータの中身を覗ける。エラーが起きたとき「何が起きているか」を自分の目で確認して、その情報をAIに正確に伝える。これだけで、問題解決のスピードが大きく変わる。
次回は「HTTPメソッドの使い分け — GET・POST・PUT・DELETEで何が変わるか」。第5回でCRUDと一緒に登場したHTTPメソッドを、もう少し深く掘り下げる。
参考リファレンス
- Chrome DevTools 公式ドキュメント「ネットワーク アクティビティの調査」— Googleが提供するDevToolsの使い方ガイド
- 前回: 第5回「いいURLの設計 — RESTfulという考え方」（/articles/vc-005）
- 次回: 第7回「HTTPメソッドの使い分け — GET・POST・PUT・DELETEで何が変わるか」（/articles/vc-007）
- バイブコーディング入門 カリキュラム（/vibe-coding）
