概要

HTTPの理解を実務で役立てるには、実際の通信を観察して原因を切り分ける力が重要です。ブラウザのDevToolsと curl を使うと、URL、メソッド、ヘッダー、ボディ、ステータスコードを確認しながらHTTPの問題を具体的に調査できます。

なぜHTTPデバッグが重要か

Webの不具合は、画面の問題に見えても、実際にはHTTP通信の失敗であることがよくあります。通信を直接見られるようになると、原因の切り分けが速くなります。

次のような不具合は、HTTPを確認しないと原因が見えにくいです。

• ボタンを押してもデータが表示されない
• ログイン直後に未ログイン状態へ戻る
• APIが一部環境だけ失敗する
• 本番だけCORSエラーになる
• ファイルアップロードが通らない
• 画面は開くがCSSや画像が読めない

こうした問題では、次を確認できるかが重要です。

• どのURLへ送っているか
• どのメソッドを使っているか
• どんなヘッダーが付いているか
• どんなボディを送っているか
• ステータスコードは何か
• レスポンスヘッダーとレスポンス本文は何か

まず見るべき基本項目

HTTPデバッグでは、毎回見る項目を固定すると調査が安定します。最初はURL、メソッド、ステータスコード、ヘッダー、ボディの順で十分です。

DevToolsで何を確認するか

ブラウザで起きる不具合は、まずDevToolsのNetworkタブを見るのが基本です。ブラウザ特有のCookie、CORS、プリフライト、リダイレクトも追いやすいのが強みです。

主に見る場所:

• Network: HTTP通信の一覧
• Console: CORSエラーやJavaScript例外
• Application: Cookie、Storage
• Security: HTTPSや証明書関連

Networkタブの基本的な見方

Networkタブでは、1つ1つのHTTP通信を一覧で確認できます。まずは対象リクエストを選び、Headers、Payload、Responseを見る流れを覚えると十分です。

基本手順:

1. DevToolsを開く
2. Network タブを開く
3. ページを再読み込みするか、該当操作を実行する
4. 対象リクエストを選ぶ
5. Headers、Payload、Response、Timing を確認する

Headersで見るポイント

Headersでは、URL、メソッド、ステータス、送受信ヘッダーをまとめて確認できます。最初の切り分けの中心になる場所です。

特に見たい項目:

• Request URL、Request Method、Status Code
• Request Headers: Authorization、Content-Type、Cookie、Origin
• Response Headers: Content-Type、Set-Cookie、Location、Cache-Control、Access-Control-Allow-Origin

これを見るだけで、かなりの問題が絞れます。

Payloadで見るポイント

POSTやPUT、PATCHでは、送信内容自体が間違っていることがあります。Payloadを見ると、実際に何が送られたか確認できます。

確認したいこと:

• JSONの構造
• 必須項目が入っているか
• 値の型が想定通りか
• フォーム送信かJSON送信か

画面では入力したつもりでも、フロントエンドのバグで空文字が送られていることがあります。

Responseで見るポイント

Responseでは、サーバーが実際に返した本文を確認できます。エラー原因の詳細はここに入っていることが多いです。

{
  "error": "validation_failed",
  "details": {
    "email": "must be a valid email address"
  }
}

500 だけ見て終わるのではなく、本文も確認することが重要です。

Consoleと合わせて見る

ブラウザでは、通信失敗がJavaScriptエラーやCORSエラーとしてConsoleに出ることがあります。NetworkだけでなくConsoleも見ると情報が補完されます。

特にConsoleで見つけやすいもの:

• CORSエラー
• JavaScript例外
• fetch や axios の失敗ログ
• Mixed Content 警告

CORSでは、Network上はサーバー応答が見えていても、Consoleにブラウザ制約のエラーが出ます。

ApplicationタブでCookieを見る

ログイン状態やセッション不具合は、NetworkだけではなくCookieの保存状態まで見ると切り分けやすくなります。

確認したい例:

• Set-Cookie がレスポンスにあるか
• 保存されたCookieが存在するか
• HttpOnly、Secure、SameSite の設定
• 次回リクエストで Cookie が送られているか

ログインが維持されないときは、次をセットで見ます。

1. ログインレスポンスの Set-Cookie
2. Applicationタブ上のCookie保存状態
3. 次のリクエストの Cookie

curlで何ができるか

curl はHTTP通信をCLIから直接試せるツールです。ブラウザを介さずに疎通確認、ヘッダー確認、API動作確認ができるため、フロントエンド要因とAPI要因を切り分けるのに役立ちます。

curl が便利な場面:

• API単体の疎通確認
• 認証ヘッダー付きリクエストの再現
• JSON送信の動作確認
• リダイレクトやレスポンスヘッダー確認
• 本番・ステージング・ローカルの比較

よく使う curl オプション

GETの確認

curl -i https://api.example.com/products/1

確認ポイント: 200 か 404 か、Content-Type は何か、本文は期待通りか

JSONをPOSTする

curl -i \
  -X POST \
  -H "Content-Type: application/json" \
  -H "Accept: application/json" \
  -d '{"name":"Keyboard","price":5000}' \
  https://api.example.com/products

確認ポイント: Content-Type を付けているか、JSON構文が正しいか、201 か 400 か

認証付きリクエスト

curl -i \
  -H "Authorization: Bearer xxxxxx" \
  -H "Accept: application/json" \
  https://api.example.com/me

これで成功するなら、ブラウザ側の認証ヘッダー付与やCookie送信に問題がある可能性があります。

Cookieを使う

# ログインしてCookieを保存する
curl -i -c cookies.txt \
  -X POST \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "email=test@example.com&password=secret" \
  https://example.com/login

# 保存したCookieで再アクセスする
curl -i -b cookies.txt https://example.com/mypage

DevToolsとcurlの使い分け

ブラウザ起点の不具合はDevTools、API単体の確認は curl が得意です。両方を使い分けると切り分けが速くなります。

典型的な切り分け手順

1. DevToolsで失敗した通信を見る
2. URL、メソッド、ヘッダー、ボディを控える
3. curl で同じ通信を再現する
4. curl でも失敗するか確認する
5. 分岐する
   • curl でも失敗 → APIやサーバー設定側を調査する
   • curl では成功 → ブラウザ、CORS、Cookie、JS実装を調査する

ステータスコード別の見方

2xx

2xxは成功ですが、「期待した形で成功しているか」は別問題です。本当に正しいデータが返っているか、Content-Type が正しいか、Cookieが設定されているかを確認します。

3xx

3xxはリダイレクトです。Location ヘッダーの確認が重要です。よくある例: 未ログインで /login へ飛ばされる、HTTPからHTTPSへ転送される。

4xx

4xxはクライアント側リクエストに問題があることが多いので、ヘッダーやボディを重点的に見ます。

5xx

5xxはサーバー側障害を疑いますが、入力によって再現する場合もあります。どの入力で起きたか、再現条件は何か、サーバーログに対応するエラーがあるかを確認します。

よくある調査パターン

ログインできない

認証系は、レスポンスだけでなくCookie保存と次回送信まで見ないと判断できません。

1. ログインAPIのステータスコード
2. レスポンスの Set-Cookie
3. ApplicationタブのCookie保存状態
4. 次回リクエストの Cookie
5. 401 / 403 の有無

CORSで失敗する

CORSはConsoleとNetworkをセットで見ると切り分けやすいです。

1. ConsoleのCORSエラー文
2. OPTIONS が飛んでいるか
3. Origin の値
4. Access-Control-Allow-Origin
5. Access-Control-Allow-Headers
6. Access-Control-Allow-Credentials

JSON送信が失敗する

JSON送信では、本文内容と Content-Type の不一致が典型的です。

1. Content-Type: application/json が付いているか
2. PayloadのJSONが正しいか
3. サーバーがJSON受け取りを想定しているか
4. 400 や 415 が返っていないか

本番だけ動かない

本番だけ失敗する場合は、環境差分を疑うのが基本です。

確認したい差分: URL、ドメイン、HTTPS有無、CORS許可オリジン、Cookie属性、認証方式、リバースプロキシやCDN設定

調査結果を共有するときのコツ

デバッグは自分だけで完結しないことが多いため、再現条件とHTTP情報を簡潔に共有できるとチーム開発で強いです。

共有に含めたい情報: 発生日時、環境（ローカル/ステージング/本番）、URL、メソッド、ステータスコード、リクエストヘッダー（秘匿情報はマスク）、リクエストボディ（個人情報は伏せる）、レスポンスヘッダー、レスポンスボディ、画面操作手順、curl で再現できるか

事象:
商品作成APIが本番で 401 になる

再現手順:
1. 管理画面で商品作成
2. 保存ボタンを押す

確認結果:
- URL: https://api.example.com/products
- Method: POST
- Status: 401
- Request Headers: Authorization が付いていない
- Request Body: {"name":"Keyboard","price":5000}
- Response Body: {"error":"unauthorized"}

補足:
curl で Authorization を付けると成功する

よくあるつまずき

まとめ

HTTPデバッグでは、URL、メソッド、ステータスコード、ヘッダー、ボディを観察するのが基本です。ブラウザのDevToolsで実際の画面操作に紐づく通信を確認し、curl でAPIを単体再現すると、問題の切り分けが大幅にしやすくなります。

• Web不具合はHTTP通信を直接見ると切り分けやすい
• まずはURL、メソッド、ステータス、ヘッダー、ボディを見る
• DevToolsではNetwork、Console、Applicationが重要
• curl ではヘッダー、JSON送信、認証付きリクエストを再現できる
• ブラウザと curl を使い分けると、フロントエンド要因とAPI要因を分けやすい
• 4xxはリクエスト側、5xxはサーバー側を中心に疑う
• 調査結果は再現条件とHTTP情報をセットで共有すると実務で役立つ