HTTPステータスコード完全ガイド（2026）— API開発者のための実践リファレンス

HTTPステータスコードは単なる暗記事項ではない

すべてのHTTPレスポンスには3桁のステータスコードが含まれています。多くの開発者はある程度まで覚えています — 200は成功、404は見つからない、500はサーバーエラー。しかし、全体像はそれよりもはるかに興味深く、実用的です。

HTTPステータスコードを正しく理解すると、より良いAPIを設計し、デバッグを速め、リダイレクト・キャッシング・エラー処理についてより賢明な決断を下せるようになります。

作業中にコードをすばやく確認したい場合は、HTTP Status Codesツールをご利用ください。

---

5つのカテゴリ：全体構造を理解する

HTTPステータスコードは5つのクラスに分けられます。最初の数字がカテゴリを示します：

範囲	カテゴリ	一言
1xx	情報	「少々お待ちください...」
2xx	成功	「こちらです。」
3xx	リダイレクト	「あちらにあります。」
4xx	クライアントエラー	「リクエストに問題があります。」
5xx	サーバーエラー	「こちら側の問題です。」

この構造を頭に入れておくと、見慣れないステータスコードに遭遇しても、最初の数字だけでリクエスト側の問題かサーバー側の問題かを素早く判断できます。

---

2xx：成功コード

これが表示されれば良い状態です。ただし、2xxの中でも細かいコードは異なります。

200 OK

デフォルトの成功コードです。リクエストが成功し、レスポンスボディがあることを意味します。GETリクエストのデフォルト値であり、POST/PUTでも更新されたリソースを返す場合に使います。

201 Created

リソースが正常に作成されたとき — 通常はPOSTリクエストへのレスポンスです。新しいリソースを指すLocationヘッダーを含めるのがベストプラクティスです。

curl -X POST https://api.example.com/users \
  -H "Content-Type: application/json" \
  -d '{"name": "田中", "email": "tanaka@example.com"}'
# HTTP/2 201
# Location: /users/43

多くのAPIはすべてに200を返します。動作はしますが、手抜きな方法です。201とLocationヘッダーを返すことで、クライアント開発者により明確なインターフェースを提供できます。

204 No Content

リクエストは成功したが、返すコンテンツがない場合です。DELETE操作、またはボディを返す必要のないPUT/PATCHに適しています。

204にはボディを絶対に含めないでください。削除後にデータを返す必要がある場合は200を使います。

---

3xx：リダイレクト

リダイレクトは開発者が最も多くのミスを犯す領域です。SEOとキャッシングへの影響を見落としやすいためです。

301 Moved Permanently

リソースが新しいURLに恒久的に移動しました。ブラウザはこのリダイレクトを無期限にキャッシュします。検索エンジンはリンク評価（PageRank）を新しいURLに転送します。

注意: 301は一度キャッシュされると元に戻すのが非常に困難です。恒久的かどうか100%確信がない場合は302を使いましょう。

302 Found

一時的なリダイレクトです。ブラウザは従いますが、永続的にキャッシュしません。SEO価値は元のURLに残ります。A/Bテスト、メンテナンスページ、ログイン後のリダイレクトに適しています。

307 / 308

307は302のメソッド保持版（一時的）、308は301のメソッド保持版（恒久的）です。POSTリクエストをリダイレクトする際、メソッドがGETに変更されないことを保証します。

304 Not Modified

クライアントが条件付きGETを送り、キャッシュされたバージョンがまだ有効な場合です。サーバーはボディなしでステータスコードのみを送ります。これがHTTPキャッシングの仕組みです。

---

4xx：クライアントエラー

クライアントが誤ったリクエストを送った場合です。APIデバッグのほとんどはここで行われます。

400 Bad Request

不正なリクエストの包括的なコードです。必須フィールドの欠落、不正なJSON、型の不一致など。レスポンスボディにはできるだけ具体的な情報を含めましょう。

{
  "error": "validation_failed",
  "details": [
    { "field": "email", "message": "有効なメールアドレスを入力してください" },
    { "field": "age", "message": "正の整数である必要があります" }
  ]
}

401 Unauthorized

認証が必要なリクエストに、クライアントが認証情報を提供していない、または無効な認証情報を提供した場合です。名前は「Unauthorized」ですが、実際には**認証（Authentication）**に関するコードです。

403 Forbidden

クライアントは認証されているが、そのリソースへのアクセス権限がない場合です。サーバーはあなたが誰か知っていますが、許可しないという意味です。

この区別は重要です：

• 他人のプライベートデータにアクセスしようとしたとき → 403
• トークンなしでAPIにアクセスしたとき → 401
• サブスクリプションプランに含まれない機能にアクセスしたとき → 403

404 Not Found

リソースが存在しない場合です。一部のAPIはセキュリティ上の理由から、ユーザーがアクセス権限を持たないリソースにも404を返します。リソースの存在自体を明かさないためです。

409 Conflict

リクエストが現在のリソースの状態と競合する場合です。既に存在するメールアドレスでユーザーを作成しようとしたとき、または楽観的ロックの失敗時に使います。

422 Unprocessable Entity

構文的には有効（JSONがパース可能、正しいContent-Type）だが、意味的に有効でない場合です。ビジネスルールの違反。多くの現代のAPIがバリデーションエラーに400ではなく422を好む理由です。

• 400: 「送られた内容をパースすることすらできません」
• 422: 「パースはできましたが、意味が通りません」

429 Too Many Requests

レート制限に達した場合です。Retry-AfterヘッダーとX-RateLimit-*ヘッダーを含めましょう。

418 I'm a Teapot

RFC 2324でエイプリルフールのジョークとして定義されたコードです。サーバーがティーポットなのでコーヒーを淹れることができないと拒否する、という内容です。なぜかGoogleが実際にこのコードを返す場合があります。インターネットが愛するユーモアです。

---

5xx：サーバーエラー

サーバー側に問題が発生した場合です。クライアントは悪くありません。

500 Internal Server Error

汎用的な「何かが壊れた」コードです。通常、未処理の例外を意味します。すべてをログに記録し、レスポンスにスタックトレースを公開せず、本番環境でアラートを設定しましょう。

502 Bad Gateway

ゲートウェイやプロキシとして動作するサーバーが、上流サーバーから無効なレスポンスを受け取った場合です。nginx + Node.jsの環境でNodeプロセスがクラッシュしたりタイムアウトしたりするときによく発生します。

503 Service Unavailable

サーバーが一時的にリクエストを処理できない場合です — 過負荷またはメンテナンス中。Retry-Afterヘッダーを含めましょう。

504 Gateway Timeout

ゲートウェイが上流サーバーから適時にレスポンスを受け取れなかった場合です。遅いDBクエリ、タイムアウトする外部API、実行制限に達したLambda関数の典型的な症状です。

---

REST API設計でのステータスコード

すぐに使える実践チートシートです：

GET /users → 200（リスト）

GET /users/ → 200（見つかった）、404（ない）、403（権限なし）

POST /users → 201（作成）、400/422（バリデーションエラー）、409（競合）

PUT /users/ → 200（更新、ボディあり）、204（更新、ボディなし）、404、409

DELETE /users/ → 204（削除）、404（ない）

一貫性が鍵です

最悪のAPIは一貫性のないAPIです。バリデーションエラーに400を使うか422を使うか、更新後にリソースを返すか（200）空のレスポンス（204）を送るかを決めて、全体で守り通しましょう。

すべてに200を使わないこと

{"success": false, "error": "not found"}を200で返すAPIがあります。クライアントライブラリを壊し、モニタリングを困難にし、よく確立された標準を無視する方法です。正しいステータスコードを使いましょう。

---

まとめ

HTTPステータスコードはクライアントとサーバー開発者間のコミュニケーションプロトコルです。正しく使うことは一種のプロフェッショナルな礼儀です。APIを利用するフロントエンド開発者から、深夜2時に本番インシデントをデバッグするオンコールエンジニアまで、全員の仕事を楽にしてくれます。

HTTP Status Codesツールをブックマークしておけば、作業中にすぐに確認できます。