HTTPステータスコード一覧 — 200・301・400・401・403・404・500の意味と使い分け

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

この章では、ステータスコードの体系的な分類と、実務でよく遭遇するコードの意味を整理します。すべてを暗記する必要はありません。まずは先頭の数字でカテゴリを判断し、よく使うコードだけ意味と使い分けを押さえるのが実務のやり方です。

学習者

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

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

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

よく使うステータスコード早見表

まずは次のコードを読めれば、ブラウザのNetworkタブやAPIレスポンスの調査で困る場面が大きく減ります。

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層構造がフロントエンドにとって扱いやすいレスポンス設計です。

Next.jsで実際にJSONレスポンスやエラーレスポンスを返す実装は、Route HandlersとAPI Routeで扱っています。この章で整理したステータスコードを、NextResponse.json(..., { status }) にどう落とし込むかを確認できます。

DevToolsでステータスコードを確認する

Chrome DevToolsのNetworkタブを開くと、各リクエストの Status 列にステータスコードが表示されます。色分けされているので、一目でエラーの有無がわかります。

実務でよくある調査フロー

APIの呼び出しがうまくいかないとき、DevToolsで確認する順番は決まっています。

fetchでステータスコードをハンドリングする

fetch はHTTPエラー（4xx、5xx）でも 例外を投げない 点に注意が必要です。ネットワークエラー（サーバーに繋がらない等）でのみ例外が発生します。

const response = await fetch('/api/users/1');
 
// fetchはHTTPエラーでもrejectしない — 明示的なチェックが必要
if (!response.ok) {
  // response.ok は status が 200-299 の場合に true
  if (response.status === 404) {
    console.error('ユーザーが見つかりません');
  } else if (response.status === 401) {
    console.error('ログインが必要です');
    // ログイン画面にリダイレクトする等の処理
  } else {
    console.error(`APIエラー: ${response.status}`);
  }
  return;
}
 
const user = await response.json();

まとめ

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

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