先に要点
- HTTP ステータスコードは 3桁の数字で `通信の結果` を表すもの。`1xx 情報` `2xx 成功` `3xx リダイレクト` `4xx クライアントエラー` `5xx サーバエラー` の 百の位 でまず分類すると読みやすい。
- 百の位を覚えるだけで、`これは自分(ブラウザ / 呼び出し側)が悪い` `これはサーバ側が悪い` の 原因の所在 がほぼ判断できる。
- 実務でよく見るのは 200 / 301 / 302 / 304 / 400 / 401 / 403 / 404 / 405 / 429 / 500 / 502 / 503 / 504 あたり。これを実際の見え方と一緒に押さえれば、Web もAPI もトラブルシューティングの速度が大幅に上がる。
- `コードを覚える` ことより、` どこの層が返したコードか(クライアント / リバプロ / アプリ / 上流API)を意識する` ほうが本質的に役立つ。同じ 502 でも、CDN が返したのかオリジンが返したのかで原因がまったく違う。
404 はわかるけど 502 はなぜ起きるの？ 302 と 307 は何が違う？ 401 と 403 はどっちが認証でどっちが認可だっけ？ ── HTTP ステータスコードは、毎日触っているのに 聞かれると微妙に答えられない という人がとても多い領域です。
ステータスコードは 「単に番号を覚える」ではなく、どこに原因があるか を一瞬で見抜くための信号 として読めるようになると、Web 開発もインフラ運用も急に楽になります。
このページでは、2026年現在の Web / API 開発で実際によく見るコードに絞り、意味・実例・原因の切り分け方 を一度に押さえられるよう整理します。
具体的な仕様の細部は MDN のステータスコード一覧 も適宜参照してください。
まず大分類で頭に入れる
HTTP ステータスコードは 3桁の数字 で、最初の桁(百の位)で5つに分類されます。
| 分類 | 意味 | 原因の所在(ざっくり) |
|---|---|---|
| 1xx 情報レスポンス | 処理は続いている | 通常意識しない(プロトコル内部) |
| 2xx 成功 | リクエストは成功した | ―(問題なし) |
| 3xx リダイレクト | 別の場所へ移動を案内 | サーバ設定(意図したものが多い) |
| 4xx クライアントエラー | 呼び出し側に問題 | ブラウザ / 呼び出しコード / リクエスト内容 |
| 5xx サーバエラー | 受け取った側に問題 | アプリ / リバプロ / インフラ / 上流API |
これだけ覚えておくと、画面が真っ白でエラーが出た ときに まず番号を見て、4xx ならこちら側、5xx なら向こう側 という最初の振り分けが瞬時にできるようになります。
番号の細部はあとから引けますが、 どこから原因究明を始めるか を間違えないこと が、トラブルシュート時間の半分を決めます。
2xx 成功系 — 「成功」にも種類がある
まず正常系から。
206 Partial Content
レンジリクエスト(動画やダウンロードの一部取得)の成功。動画のシーク、ダウンロード再開などで裏で出ている。
「成功イコール200だけ」と思っていると、204 が返ってきたけどボディがないのでエラーだと誤解する といった事故が起きます。
特に API を書くときは、どの動作にどの 2xx を返すか を仕様で揃えるのが、後段の動作確認とエラーハンドリングを楽にします。
3xx リダイレクト系 — 場所が変わったよ系
移動 を伝えるコード群です。エラー ではなく 「お知らせ」なので、ブラウザは自動で追従します。
301 Moved Permanently
恒久的にリダイレクト。`http://example.com → https://example.com` のような 恒久的な引っ越し で使う。SEO 上もこちらが推奨。
302 Found(旧: Moved Temporarily)
一時的なリダイレクト。`ログインしていないと /login へ飛ばす` `メンテ中はメンテページへ` のような 状況依存 な遷移。
301 と 302 を混同するとブラウザや CDN のキャッシュ動作で痛い目を見ます。 恒久 → 301、一時 → 302 の使い分けは、サイト移転や HTTPS 化のときに必ず聞かれる定番ポイントです。
4xx クライアントエラー系 — 「リクエスト側」が悪い
このカテゴリは 呼び出し側に何か問題がある ことを伝えます。
400 Bad Request
リクエスト内容が不正。JSON が壊れている、必須パラメータが足りない、型が違うなど。API では `バリデーション NG` の代表選手。
401 Unauthorized(認証)
`本人確認に失敗` 状態。ログインしていない、トークンが期限切れ、ヘッダの認証情報が不正など。` ログインしてください` の合図。
403 Forbidden(認可)
`認証は OK だが、その操作を行う権限がない` 状態。一般ユーザーが管理ページを開いた、他人の投稿を編集しようとした、IP 制限に引っかかった等。
404 Not Found
その URL に対応するリソースが見つからない。記事削除済み、ルーティング設定漏れ、タイポが原因のことが多い。
408 Request Timeout
クライアントが期間内にリクエストを送り終えなかった。大きなファイルのアップロード時などで稀に出る。
413 Payload Too Large
送られてきた本文が大きすぎる。画像アップロード API でファイルサイズ上限を超えるケースなど。
415 Unsupported Media Type
`Content-Type が想定外`。`application/json` を期待しているのに `multipart/form-data` で送ってきた、など。
特に 401 と 403 を混同するケースは多いです。
401 は あなた誰？ / 403 は あなたはダメ と覚えると、認証 / 認可の文脈で迷わなくなります。
5xx サーバエラー系 — 「受け取った側」が悪い
5xx は 受け取ったサーバ側で問題が起きた ことを伝えます。クライアント側で同じリクエストを繰り返しても直らないのが特徴です。
500 Internal Server Error
アプリケーションが落ちた・例外が握りつぶされた、というケースの代表。` 内部のエラー、原因はサーバログを見るしかない` のが基本姿勢。
501 Not Implemented
` その機能はまだ実装していません` 系。実務で出てくる頻度は低い。
502 Bad Gateway
リバプロや CDN が上流(アプリ / API)から不正な応答を受け取った。` リバプロ ↔ アプリの間でアプリが落ちている` の典型サイン。
503 Service Unavailable
サーバが一時的に応答できない。メンテナンス中、過負荷、起動直後の初期化中など。`Retry-After` を見て少し待つのが基本対応。
504 Gateway Timeout
リバプロや CDN が上流からの応答を待ちきれずタイムアウト。アプリの処理が遅い / 上流API が応答返さない / ネットワークが詰まっている ときに出る。
521 / 522 / 523 など Cloudflare 拡張
Cloudflare などの CDN が独自に定義する `オリジン到達失敗` 系。`本物のサーバが返したコードではない` ことを見落とさない。
5xx の切り分けで一番大事なのは、 どのレイヤーが返したか を確認すること です。
たとえば 502 が出ているとき、それを返しているのが CDN なのか、リバプロなのか、アプリなのか で原因がまったく違います。
Server ヘッダや Via ヘッダ、応答時間、過去のログを見て、これは Cloudflare が返した 522 だな と気づける目線を持つと、復旧速度が劇的に変わります。
実務でハマりやすい誤読パターン
ステータスコードを正しく読めないと判断を誤る、典型的な落とし穴を整理します。
①4xx のはずなのに 200 を返すアプリ
`ステータスは 200、ボディに {error: '...'}` のような実装。クライアント側の例外処理が `ステータスコードしか見ない` 場合、エラーを見落とす。正しい 4xx を返す のが API の良い設計。
③ 404 と 410 の使い分け漏れ
`削除済みなのに 404` だけ返す実装が多い。SEO 観点では `恒久的に消した` ものは 410 Gone を返したほうが Google の認識が早い。
④ リダイレクトループ
301 や 302 が無限に続いている状態。ブラウザは `Too many redirects` で止まる。`HTTPS 化設定の重複` `ログイン状態の判定ミス` で起きやすい。
特に ①の 200 でエラーを返す API は、初期実装で割とよく見ます。
ステータスコードはアプリ層の文化で、ビジネスロジックの結果はボディで返す という設計はその時点では楽でも、後段で ステータスコードを信用できない API になり、運用や監視が非常に難しくなります。
トラブル時の切り分けフロー
実際にエラーが出たときに、コードから原因をたどる順番です。
「番号を見たら反射的に対処に飛びつかず、まず分類と発生源を切り分ける」が、ステータスコードを正しく扱う一番大事な姿勢です。
AI 時代の HTTP コード観
LLM を組み込んだサービスでは、上流 AI API(OpenAI / Anthropic 等)が レートリミット(429) や タイムアウト(504) を頻発させます。
OpenAI Responses API と Chat Completions の違い など AI 連携前提のアーキテクチャを設計するときも、「上流の AI が 429 を返したら自分のアプリは 503 を返す」のような HTTP コードに翻訳して中継する 設計 が増えてきています。
404 を返すページが大事な理由 と合わせて読むと、「返すべきコードと、返してはいけないコードの境界」への感度が上がります。
新しい API を設計するときは、このエラーは 4xx か 5xx か をまず明文化する習慣を身につけると、後段のクライアント実装や運用監視が楽になります。
代表的な HTTP ステータスコードに関するよくある質問
Q. 401 と 403 はどう違うのですか？
A. 401 は あなたが誰なのか分からない / 認証情報が無効、403 は あなたは認識しているが、その操作を行う権限がない です。401 はログイン画面に飛ばす、403 は 権限不足 と説明する、という UI 側の出し分けの違いにも直結します。
Q. 301 と 302 を間違えるとどうなりますか？
A. ブラウザと CDN、検索エンジンが恒久 / 一時を別物として扱うため、影響は大きいです。恒久に 302 を返すと、SEO 上の評価が新 URL に十分に引き継がれず、一時に 301 を返すと、戻したつもりが古い URL のままキャッシュされ続けます。 永続なら 301、一時なら 302 を徹底するのが安全です。
Q. 502 が出たときに最初に見るべき場所は？
A. アプリ(オリジン)が生きているか を最初に確認します。リバプロや CDN が 上流から不正な応答を受け取った ときに 502 を返すため、オリジンが落ちている タイムアウトしている 不正な HTTP を返している のいずれかが疑われます。アプリのログ → リバプロのログ → CDN のレポート、の順で追うのが効率的です。
Q. 429 が連発したときの対処は？
A. 雑にリトライしないことが最重要です。 Retry-After ヘッダの指示に従って待つ、指数バックオフ + ジッター で再試行間隔を伸ばす、同時実行数を絞る のが基本。バックエンドの負荷を増やすリトライは状況を悪化させます。
Q. API が成功時にも 204 を返すのは正しいですか？
A. 正しい使い方の一つです。削除に成功した 更新したがレスポンスとして返すものがない ようなケースで 204 は適切な選択。 ボディが空 = 失敗 と勘違いしないクライアント実装 をセットで考えるのが大事です。
Q. 4xx を エラー画面に表示しない のは問題ですか？
A. ユーザーへの表示文言と HTTP コードは分けて考えていいです。ただし、 HTTP コードはモニタリングと自動化の基盤 なので、「200 でエラーを返す」のはやめておきましょう。画面に出すメッセージはユーザー向けに優しく、コードは機械向けに正確に、が両立のコツです。
Q. ステータスコードを全部覚える必要はありますか？
A. ありません。実務で使うのは 20種類前後 です。あとは MDN や RFC を辞書として引けば十分。重要なのは 百の位の意味と、原因の所在を瞬時に切り分ける感覚 で、これは記憶よりも経験で身につく部分が大きいです。
参考リンク
- MDN: HTTP レスポンスステータスコード
- IETF: RFC 9110 HTTP Semantics
- MDN: HTTP リダイレクト
- MDN: HTTP 認証
- Cloudflare: Troubleshooting 5xx errors
- Google Search Central: HTTP ステータスコードと Google