HTTPステータスコード完全ガイド：分類と代表例、SEO・API・運用で使える実務ベストプラクティス
エバープレイ編集部HTTPステータスコードとは — 基礎と実務での扱い方
HTTPステータスコードは、クライアント（ブラウザやAPIクライアント）からのリクエストに対してサーバが返す「処理結果」を示す3桁の数値です。数値の先頭桁で大まかなカテゴリが分かれ、さらに各コードごとに意味と期待される振る舞いが定義されています。Web開発や運用、API設計、SEO対策、キャッシュ戦略など様々な場面で非常に重要です。
ステータスコードの分類（1xx〜5xx）
- 1xx（情報）：処理が継続中であることを示す（例：100 Continue）。通常ブラウザ側で意識することは少ない。
- 2xx（成功）：リクエストが正常に処理された（例：200 OK、201 Created、204 No Content、206 Partial Content）。
- 3xx（リダイレクト）：追加のアクション（主に別URLへの移動）が必要（例：301、302、307、308、304 Not Modified）。
- 4xx（クライアントエラー）：クライアント側の問題（例：400 Bad Request、401 Unauthorized、403 Forbidden、404 Not Found、429 Too Many Requests）。
- 5xx（サーバエラー）：サーバ側の問題（例：500 Internal Server Error、502 Bad Gateway、503 Service Unavailable、504 Gateway Timeout）。
代表的なステータスコードの意味と使いどころ
- 200 OK：リクエスト成功。レスポンスボディに通常のデータが含まれる。
- 201 Created：リソース作成成功。Locationヘッダで新しいリソースURIを返すべき。
- 204 No Content：成功だがレスポンスボディはなし。PUT/DELETEの成功応答や、AJAXの空レスポンスに適する。
- 301 Moved Permanently：恒久的な移転。SEOでは原則的に元のURLの評価を新URLへ移す。
- 302 Found / 307 Temporary Redirect：一時的なリダイレクト。307はHTTPメソッドを保持（POST→POST）する点で302より明確。
- 308 Permanent Redirect：301と同様に恒久だが、メソッドを保持する点で307に対応する恒久版。
- 304 Not Modified：条件付きGET（If-None-Match / If-Modified-Since）で変更がなかった。キャッシュが利用される。
- 400 Bad Request：リクエストの文法や形式が不正。
- 401 Unauthorized：認証が必要。WWW-Authenticateヘッダで認証方式を示す。
- 403 Forbidden：認証はできているがアクセス権がない。
- 404 Not Found：指定したリソースが存在しない。
- 409 Conflict：リソースの状態に矛盾がある（例：同一リソースの競合更新）。
- 410 Gone：リソースが恒久的に存在しない（404より明確な「永久削除」）。SEOで削除を明示したいときに有用。
- 429 Too Many Requests：レート制限に達した。Retry-Afterヘッダで待機時間を返すことが推奨される。
- 500 Internal Server Error：一般的なサーバエラー。詳細をそのまま公開しないことがセキュリティ上の原則。
- 502 / 503 / 504：プロキシ／バックエンド関係の障害やサービス停止、タイムアウトを示す。
HTTP仕様と拡張（重要なRFCや実務ポイント）
ステータスコードの正式な定義は複数のRFCに分かれます。代表的なもの：
- RFC 7231（HTTP/1.1 Semantics and Content）— 多くの基本コードの定義
- RFC 7232（Conditional Requests）— If-Modified-Since / If-None-Match と 304の挙動
- RFC 7233（Range Requests）— 206 Partial Content とバイトレンジ
- RFC 7235（Authentication）— 401 と WWW-Authenticate
- RFC 6585 / RFC 7725 等— 428, 429, 431, 451 のような近年のステータスコードの定義
- RFC 7807（Problem Details for HTTP APIs）— APIエラー表現の標準化（application/problem+json）
HTTP/2やHTTP/3でもステータスコード自体は変わりません（トランスポート層が変わるだけ）。
実務で押さえるべきベストプラクティス
- 意味に合ったコードを返す：200を乱用せず、クライアントが適切に制御できるよう正しいコードを返す（例：認証失敗は401、権限不足は403）。
- 作成時は201 + Location：POSTで新規リソースを作ったら201とLocationヘッダを返す。
- 空レスポンスは204：成功なのにボディがない場合は204を使う。200で空ボディを返すとクライアントの扱いがやや曖昧になる場合がある。
- リダイレクトは適切に使い分ける：恒久移転は301/308、メソッド保持が必要な一時移転は307/308など。
- キャッシュと条件付きリクエストを活用：ETagやLast-Modifiedと304で帯域を節約する。
- エラーメッセージは安全に、問題詳細は規格化：内部情報を漏らさず、APIではRFC7807等に沿った構造化エラーを検討する。
- レート制限とRetry-After：429や503でRetry-Afterを返すことでクライアントに再試行戦略を促す。
- ログとメトリクスの設計：5xxの急増や特定エンドポイントの404/401比率の変化は障害や攻撃の兆候になり得る。
API設計・フロントエンドとの関係
APIを設計する際、HTTPステータスコードは「契約」の一部です。クライアントは数値で処理分岐を行い、開発者は仕様通りのコードとエラー構造（例：code/message/fields）を返すべきです。SPAやモバイルアプリでは、ネットワークエラー（タイムアウト）とHTTPエラー（4xx/5xx）を分けて扱うことでUXを改善できます。
よくある誤解と注意点
- 「200なら安全」ではない：200でもアプリケーションレベルのエラーを含むケースがある（レスポンスボディで詳細を伝えるが、これは非推奨な設計の場合がある）。
- カスタムステータスコードは避ける：標準外のコードはプロキシやライブラリで扱われない可能性がある。
- キャッシュヘッダとステータスを整合させる：304を返すならCache-Control/ETagの運用を正しく行う。
デバッグと運用で役立つポイント
- ログにステータスコードとURI、レスポンスタイムを必ず残す。5xxの増加は即アラート化。
- CDNやプロキシ（Nginx, Cloudflare等）は独自エラー（例：502/524など）を返すことがあるため、その意味を把握しておく。
- ブラウザ開発者ツールやcurlでステータスとヘッダを確認する（例：curl -I, curl -v）。
まとめ
HTTPステータスコードは単なる数値ではなく、クライアントとサーバ間の明確なコミュニケーション手段です。正しいコードを返すことでキャッシュ効率、クライアントの挙動、SEO、セキュリティが改善されます。API設計者やWeb開発者は、主要なコードの意味と関連ヘッダ（Location、Retry-After、WWW-Authenticate、ETagなど）を理解し、仕様（RFC）や最新の慣習に基づいて実装・運用することが重要です。
参考文献
- RFC 7231 — Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
- RFC 7232 — Conditional Requests
- RFC 7233 — Range Requests
- RFC 7235 — Authentication
- RFC 7725 — 451 Unavailable For Legal Reasons
- RFC 6585 — Additional HTTP Status Codes (e.g., 428, 429)
- RFC 7807 — Problem Details for HTTP APIs
- MDN Web Docs — HTTP response status codes（日本語）
投稿者プロフィール
