HTTPステータスコード — 200・404・500の意味と実務での読み方

HTTPレスポンスの先頭には、3桁の ステータスコード が必ず含まれます。これは「リクエストがどうなったか」をクライアントに伝える番号です。

この章では、ステータスコードの体系的な分類と、実務でよく遭遇するコードの意味を整理します。すべてを暗記する必要はなく、先頭の数字でカテゴリを判断し、詳細は都度調べる のが実務のやり方です。

学習者

200 と 404 はなんとなく分かるけど、401 と 403 の違いとか 500 番台とか…正直あいまい。

ステータスコードの5つのカテゴリ

最も重要なのは 4xxと5xxの区別 です。「リクエストを送った側の問題か、受けた側の問題か」を切り分けるのが、トラブルシューティングの第一歩です。

2xx — 成功系

GET /api/users/1 → 200 OK + ユーザーデータ
POST /api/users  → 201 Created + 作成されたユーザー
DELETE /api/users/1 → 204 No Content

3xx — リダイレクト系

301と302の違いは 恒久的か一時的か です。

• 301: 「このURLは永遠に使わない。新しいURLをブックマークして」 → 検索エンジンもインデックスを書き換える
• 302: 「今だけ別の場所に行って。元のURLはまた使う」 → 検索エンジンのインデックスは変えない

4xx — クライアントエラー系

クライアント（リクエストを送った側）に問題がある場合のコードです。

401と403の違い

この2つは混同されやすいですが、明確に違います。

// 401 — 「あなた誰？」（認証されていない）
GET /api/admin/users
Authorization: (なし)
→ 401 Unauthorized

// 403 — 「あなたは知ってるけどダメ」（権限がない）
GET /api/admin/users
Authorization: Bearer <一般ユーザーのトークン>
→ 403 Forbidden

400と422の使い分け

実務では400で統一しているAPIも多いですが、フロントエンドがエラーの種類を判別してUIに出し分ける必要がある場合、422を使うと便利です。

5xx — サーバーエラー系

サーバー側の問題でリクエストを処理できなかった場合のコードです。

実務での5xxの読み方

500 → アプリケーションコードのバグ（未処理の例外など）
502 → リバースプロキシ(Nginx等)がアプリサーバーに繋がらない
503 → メンテナンス中、またはサーバーが過負荷
504 → アプリサーバーの処理が遅すぎてプロキシがタイムアウト

502と504は リバースプロキシ（NginxやCloudflare）が返す ことが多いです。アプリサーバーのプロセスが落ちていれば502、処理に時間がかかりすぎれば504が出ます。

APIレスポンスの設計指針

ステータスコードは「正しく返す」だけでなく、エラーレスポンスのボディにも詳細を含める のが良いAPIの条件です。

// よくないエラーレスポンス
{ "error": "Bad Request" }
 
// 良いエラーレスポンス
{
  "error": {
    "code": "VALIDATION_ERROR",
    "message": "メールアドレスの形式が不正です",
    "field": "email"
  }
}

ステータスコードで「何が起きたか」の大枠を伝え、ボディで「具体的に何が問題か」を伝える。この2層構造がフロントエンドにとって扱いやすいレスポンス設計です。

まとめ

• ステータスコードは 先頭の数字 でカテゴリが決まる（2=成功、3=リダイレクト、4=クライアントエラー、5=サーバーエラー）
• 401は未認証、403は権限なし — 混同しやすいが意味が違う
• 4xxはリクエスト側の問題、5xxはサーバー側の問題 — この切り分けがデバッグの起点
• エラーレスポンスには ステータスコード + ボディの詳細 の2層で情報を返す

次の章では、リクエストとレスポンスに含まれる ヘッダーとCookie の仕組みを見ていきます。