HTTPレスポンスの中身とは?

Mar 12, 2026 · 3 min read

ブラウザがページを読み込むたび、あるいはJavaScriptでfetch()を呼び出すたびに、サーバーはHTTPレスポンスを返します。あなたが目にするのは、レンダリングされたページ、JSONデータ、エラーメッセージといった結果ですが、レスポンス自体には、多くの開発者が意識している以上の構造が含まれています。この構造を理解することで、DevToolsでのデバッグやコード内でのレスポンス処理において、より明確なメンタルモデルを得ることができます。

HTTPレスポンスは3つの部分から構成されます:ステータス行、ヘッダー、そしてオプションのボディです。

重要なポイント

すべてのHTTPレスポンスは3つの部分で構成されます:ステータス行(HTTP/2およびHTTP/3では:status疑似ヘッダー)、ヘッダー、そしてオプションのボディ。
ステータスコードは最初の桁でグループ化されます — 2xxは成功、3xxはリダイレクト、4xxはクライアントエラー、5xxはサーバーエラーを表します。
レスポンスヘッダーはキャッシング、セキュリティ、Cookie、コンテンツの解釈を制御します — ペイロードが何であるかだけでなく、どのように処理すべきかをブラウザに伝えます。
クロスオリジンリクエストでは、すべてのレスポンスヘッダーがフロントエンドのJavaScriptからアクセスできるわけではありません。サーバーは、デフォルトの安全なセット以外へのアクセスを許可するためにAccess-Control-Expose-Headersを使用する必要があります。

HTTPレスポンスの構造:ステータス、ヘッダー、ボディ

ステータス行

HTTP/1.1では、レスポンスは単一のステータス行から始まります:

HTTP/1.1 200 OK

この行には、プロトコルバージョン、3桁のステータスコード、そして人間が読める理由フレーズが含まれます。理由フレーズは情報提供のみを目的としており、ブラウザやクライアントが実際に動作するのはステータスコードに基づいています。

HTTPステータスコードは最初の桁でグループ化されます:

範囲	意味
1xx	情報(リクエストを受信、処理を継続)
2xx	成功(200 OK、201 Created、204 No Content)
3xx	リダイレクト(301 Moved Permanently、304 Not Modified)
4xx	クライアントエラー(400 Bad Request、401 Unauthorized、404 Not Found)
5xx	サーバーエラー(500 Internal Server Error、503 Service Unavailable)

HTTP/2とHTTP/3に関する注意: 上記のテキスト形式のステータス行は、HTTP/1.1のワイヤーフォーマットに特有のものです。HTTP/2とHTTP/3では、ステータス行は存在しません。代わりに、ステータスは:status疑似ヘッダー(例::status: 200)を介して伝達されます。セマンティクスは同一です — ステータスコードの意味は同じです — が、表現方法が異なります。DevToolsは表現を正規化するため、プロトコルバージョンに関係なく、おなじみのステータスコードが表示されます。

HTTPレスポンスヘッダー:実際の役割

レスポンスヘッダーはメタデータです。コンテンツが何であるかではなく、レスポンスをどのように処理すべきかをブラウザに伝えます。各ヘッダーは、大文字小文字を区別しない名前の後にコロンと値が続きます。

最もよく遭遇するカテゴリは以下の通りです:

コンテンツメタデータ

Content-Type: application/json; charset=utf-8 — ボディがどの形式であるか、どのようにデコードするかをブラウザに伝えます。
Content-Length: 1024 — ボディのサイズをバイト単位で示します。

キャッシング

Cache-Control: max-age=3600, public — レスポンスをどのくらいの期間キャッシュするかをブラウザとCDNに指示します。
ETag: "abc123" — リソースのフィンガープリントで、条件付きリクエストに使用されます。リソースが変更されていない場合、サーバーは完全なボディの代わりに304 Not Modifiedを返します。

セキュリティ

Content-Security-Policy — ブラウザがスクリプト、スタイル、その他のリソースをどのソースから読み込めるかを制限します。
Strict-Transport-Security — 指定された期間、HTTPSでのみ接続するようブラウザに指示します。

Cookie

Set-Cookie: session=xyz; HttpOnly; Secure — Cookieを保存するようブラウザに指示します。単一のレスポンスには、Cookieごとに1つずつ、複数のSet-Cookieヘッダーを含めることができます。

重要な制約が1つあります:すべてのレスポンスヘッダーがフロントエンドのJavaScriptからアクセスできるわけではありません。デフォルトでは、Fetch APIはクロスオリジンレスポンスから「安全な」ヘッダーの小さなセットのみを公開します。JavaScriptがそれらを読み取れるようにするには、サーバーがAccess-Control-Expose-Headersに追加のヘッダーを明示的にリストする必要があります。

レスポンスボディ

ボディは実際のペイロード — HTML、JSON、画像、ファイルです。すべてのレスポンスにボディがあるわけではありません。204 No Contentや304 Not Modifiedレスポンスは意図的にボディを省略します。これらの場合、ステータスコード自体がメッセージです。

Content-Typeヘッダーは、ボディに到着するものをどのように解釈するかをブラウザに伝えます。

知っておく価値のある一般的でない機能

HTTPレスポンスには、103 Early Hintsのような情報レスポンスも含まれることがあります。これにより、サーバーはメインレスポンスが到着する前にプリロードするリソースを提案できます。トレーラー — ボディの_後_に送信されるヘッダー — は、HTTP/1.1(チャンク転送エンコーディング使用時)およびHTTP/2とHTTP/3にトレーリングヘッダーとして存在しますが、日常的なフロントエンド作業ではほとんど遭遇しません。これらは知っておく価値がありますが、DevToolsで頻繁に目にすることはありません。

まとめ

HTTPレスポンスを封筒として考えてください。ステータスコードは配達が成功したかどうかを伝えます。ヘッダーは外側の指示書です — 取り扱い注意、開封後は冷蔵保存、24時間で期限切れ。ボディは中身です。何かが壊れたときは、まずステータスコードを確認し、次にヘッダーを確認してください — 通常、何が間違っていて次に何をすべきかを正確に教えてくれます。

よくある質問

Content-Lengthはレスポンスボディの正確なサイズをバイト単位で指定します。Transfer-Encodingは、通常chunkedに設定され、ボディが事前に決定された合計サイズなしで断片的に送信されることを意味します。HTTP/1.1では、レスポンスはどちらか一方を使用します。チャンクエンコーディングは、サーバーが最終サイズを事前に知らない動的に生成されるコンテンツで一般的です。

クロスオリジンリクエストの場合、Fetch APIはデフォルトでCORS安全リストに含まれる限定されたレスポンスヘッダーのセットのみを公開します。これには、Cache-Control、Content-Language、Content-Type、Expires、Last-Modified、Pragmaが含まれます。JavaScriptから他のヘッダーにアクセスするには、サーバーがAccess-Control-Expose-Headersレスポンスヘッダーにそれを含める必要があります。

サーバーがリクエストを正常に処理したが、返すボディがない場合に204 No Contentを使用します。これは、DELETE操作やクライアントがレスポンスで更新されたデータを必要としないフォーム送信で一般的です。確認ペイロードや更新されたリソースをクライアントに送り返したい場合は、200 OKがより適切です。

F12またはCtrl+Shift+IでDevToolsを開き、Networkタブに移動し、リスト内の任意のリクエストをクリックします。Headersパネルには、リクエストヘッダーとレスポンスヘッダーの両方が表示されます。リクエストタイプでフィルタリングしたり、特定のヘッダー名を検索したりすることもできます。Responseタブには、サーバーから返された生のボディコンテンツが表示されます。

Gain control over your UX

See how users are using your site as if you were sitting next to them, learn and iterate faster with OpenReplay. — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.