HTTP ステータスコード — 3 桁で結果を読む
ステータスコードは百の位で 5 つに分類してから下 2 桁を読む。成功の 200/201/204、リダイレクトの 301/302/308、クライアント側の 401/403/404、サーバ側の 500/502/503 を切り分ける。
「404 と 403 の違いは？」に詰まらないために
エラー画面のスクリーンショットが送られてきて「これ直せますか」と聞かれる。404 なのか 403 なのか 503 なのかで原因も直し方もまったく違うのに、数字の顔つきだけではどれも同じに見える — ステータスコードは、暗記しようとすると数十個あって挫折する分野です。
暗記は要りません。ステータスコードは百の位で 5 つに分類してから、よく会う下 2 桁だけ読むのが正しい付き合い方です。3 点セットの 2 つ目「結果はどうだったか」は、まず百の位が答えてくれます。
調査の初手はこの分類で決まります。4xx ならまずリクエスト側（URL・認証・送った内容）を疑い、5xx ならサーバ側（アプリのログ・後段のサービス）を疑う。この向きを取り違えないだけで、原因調査の半分は終わっています。
百の位で 5 つに分類し、各クラスの中で「よく会う数個」だけ読み分ける — これがステータスコードの地図です。矢印の先の代表コードが、この章で扱うすべてです。
2xx — 成功にも使い分けがある
成功は 200 だけではありません。よく会う 3 つを並べます。
API を作る側になったとき、この 3 つを使い分けられるかどうかで、返事の読みやすさが変わります。「成功した」だけでなく「成功して、何がどうなったか」まで 3 桁で伝えるのが 2xx の使いこなしです。
小問 3-1 — 百の位で分類する
まず百の位で大分類し、成功系の下 2 桁を読み分けます。
Q1. ステータスコードの百の位の読み方として正しいものはどれですか。
4xx は「あなたの頼み方に問題がある」（存在しないパス、権限なし等）、5xx は「頼み方は受け取ったが、こちらの処理でしくじった」というサーバ側の障害です。この向きを逆に覚えると調査の初手を誤ります。百の位 → 下 2 桁の順で読む、が 3 桁を暗記せずに済ませるこの章の型です。
Q2. POST /orders で新しい注文の作成に成功したとき、意味として最も的確なステータスコードはどれですか。
201 は「成功し、その結果として新しいリソースが作られた」ことを明示する成功コードで、多くの API は作られたものの URL を Location ヘッダに添えて返します。200 でも間違いとまでは言えませんが「作られた」という情報が落ちます。204 は「成功したが返す本文はない」、301 はリダイレクトで、成功の中の使い分けとしては 201 が最も的確です。
Q3. DELETE /orders/7 が成功し、サーバは返すべき本文を特に持っていません。このとき自然なステータスコードはどれですか。
204 は「成功した。ただしボディは空である」という成功コードで、削除や更新のように返すものがない操作にぴったりです。404 は「見つからない」という失敗、500 はサーバ障害、100 は 1xx（処理の途中経過の連絡）で成功の報告ではありません。成功にも 200/201/204 の使い分けがある、というのが 2xx の読みどころです。
3xx — 「別の場所へどうぞ」の使い分け
3xx のレスポンスは「答えはここにはありません。Location ヘッダに書いた URL へどうぞ」という案内状です。ブラウザはこれを受け取ると自動で転送先にリクエストし直します。よく会うのは次の 3 つで、違いは 2 つの軸で読めます。
2 軸目の「メソッド保存」は歴史的経緯の産物です。301/302 では、古い実装との互換のために POST が GET に書き換えられて転送されることが許容されています。HTML ページの移転なら実害はほぼありませんが、API の POST が GET に化けると頼みごと自体が変わってしまう。そこで「メソッドを変えない」ことを明示した 307/308 が後から用意されました。恒久か一時か × メソッドを保存するか — この 2 軸で 4 つのコードは整理できます。
4xx と 5xx — 誰の問題かを言い当てる
4xx の中では、似て見える 3 兄弟の言い分けが重要です。
5xx の中では、この 3 つを切り分けられると障害対応の初手が変わります。
502 が読めると強いのは、現代の Web サーバの多くが「中継役（nginx など）+ 後ろのアプリ」という 2 段構成だからです。502 は中継役は生きていて、後ろが倒れていることまで教えてくれています。数字 1 つで、調べる場所が 1 段絞れるのです。
小問 3-2 — リダイレクトとエラーを切り分ける
3xx の使い分けと、4xx・5xx の中の切り分けです。実務での調査の初手が変わります。
Q4. サイトを http://example.com から https://example.com へ恒久的に移転しました。301 を選ぶ理由として正しいものはどれですか。
301 Moved Permanently は「この住所は今後ずっとあちらです」という宣言で、ブラウザは次回から直接新 URL へ行けるようこの転送をキャッシュでき、検索エンジンは評価を新 URL へ引き継ぎます。一時的な転送はそれをキャッシュ・登録されては困るので 302 Found を使います。恒久か一時か — この 1 語の違いが、SEO とキャッシュの挙動を分けます。
Q5. 308 Permanent Redirect が 301 と別に用意されている理由として正しいものはどれですか。
古いブラウザの実装に由来する経緯で、301/302 では POST が GET に書き換えられて転送されることが許容されています。POST のまま転送してほしい API では、これではボディごと頼みごとが変わってしまいます。308（恒久）と 307（一時）は「メソッドを保存する」ことを明示した新しいコードです。速度や HTTPS 専用といった違いではありません。
Q6. 管理画面 https://example.com/admin にログイン済みの一般ユーザがアクセスしたところ、拒否されました。「ページが存在しないのではなく、認証は済んでいるが権限が足りない」ことを表す最も的確なコードはどれですか。
403 は「あなたが誰かは分かったが、これをする権限がない」です。401 は名前に反して「未認証 — まず認証してください」で、認証情報を付けて再挑戦すれば通る可能性があります。404 は「そのパスにリソースが見つからない」。なお、管理画面の存在自体を隠したいサイトが権限不足にあえて 404 を返す実務もあり、コードは「サーバがそう主張している」ことの表明だと押さえておくと第 7 章のケースで効きます。
この章で持ち帰ること
- ステータスコードは百の位で 5 分類 — 途中経過 / 成功 / 転送 / クライアント側の問題 / サーバ側の障害。調査の初手はここで決まる
- 成功の使い分け: 200 汎用 / 201 作られた / 204 成功したが本文なし
- リダイレクトは恒久か一時か × メソッドを保存するかの 2 軸 — 301・302・308（と 307）。恒久はキャッシュされ SEO 評価も引き継がれる
- 401 未認証 / 403 権限不足 / 404 不存在、500 アプリ内部 / 502 後ろが倒れている / 503 一時的に無理を言い分ける
結果の読み方が身についたので、次章は 3 点セットの 3 つ目 — 往復書簡に添えられる「条件と補足」、ヘッダを読みます。