HTTPステータスコードとは
HTTPステータスコード（エイチティーティーピー・ステータス・コード）は、HTTP応答の結果を3桁の数値で示すコードで、成功、転送、利用者側エラー、サーバー側エラーなどに分類されます。
HTTP 応答の開始行に入り、ブラウザーやAPIクライアントへ「次に何をすべきか」を機械可読な形で伝えます。人向け画面の見出しではなくプロトコルの制御情報です。
ステータスコードだけで処理全体の成功は断定できません。200でもアプリケーション上の失敗を本文に返す設計があり、404でもサーバーとのHTTP通信自体は正常に成立しています。
先頭桁で分かる五つの分類
要求処理の途中経過を伝える暫定応答です。通常は後に最終応答が続きます。
要求を受け付け、コードごとに定めた意味で処理したことを示します。
別URIの利用やキャッシュ済み表現など、追加動作が必要な状態です。
要求の構文、認証、権限、対象資源、頻度などに問題があります。
要求は妥当に見えるものの、サーバー側が処理を完了できません。
標準HTTPステータスコードは100〜599の範囲です。先頭桁は大分類を示しますが、具体的な処理は三桁全体とメソッド・ヘッダーで決まります。
応答を読む順番
- どの要求への応答か確認するメソッド、対象URI、送信時刻、リダイレクトの連鎖を対応付けます。
- ステータスコードを特定する分類だけでなく三桁全体の標準意味を読みます。
- 関連ヘッダーを読むLocation、WWW-Authenticate、Retry-After、Allow、Cache-Controlなど、コードと組になる情報を確認します。
- 本文を別層として読む人向け説明やアプリケーション固有エラーコードが含まれる場合があります。
- 応答した機器を切り分けるオリジンサーバー、リバースプロキシ、ゲートウェイ、CDNのどこが生成したかをログ・ヘッダーで確認します。
理由句は判断材料にしない
HTTP/1.1ではステータスコードの後ろに理由句が見えることがありますが、内容は推奨文言に固定されず、空でもプロトコル上の意味は三桁コードで決まります。HTTP/2・HTTP/3では理由句を使いません。
プログラムは「OK」「Not Found」という英語文字列を比較せず、数値コードと標準意味を処理します。独自の日本語見出しを表示してもコード自体は変わりません。
最終応答と暫定応答
1xxは要求が継続中であることを伝える暫定応答です。たとえば要求本文を送ってよい、プロトコルを切り替える、といった合図に使います。原則としてクライアントはその後の最終応答を待ちます。
最終応答は2xx〜5xxで、要求に対する最終的なHTTP結果です。ただし3xxを受けたブラウザーが新しいURIへ別要求を送ると、利用者からは一連の一回の画面遷移に見えます。
クライアントエラーは利用者だけの責任ではない
4xxの「クライアント」はHTTP要求側という分類です。壊れたリンクを生成したサイト、期限切れトークンを渡したサーバー、プロキシが削除したヘッダーなどが原因でも、最終要求が要件を満たさなければ4xxになります。
同様に5xxでもオリジンサーバーのプログラムだけが原因とは限りません。ゲートウェイが上流サーバーへ接続できない、負荷分散装置がタイムアウトした、メンテナンスで利用不能など、応答を生成した層を特定します。
キャッシュと再試行はコード分類だけで決めない
「2xxはキャッシュ可能」「5xxは必ず再試行」のような一括処理は危険です。キャッシュできる条件は個々のステータス定義、メソッド、Cache-Control、Expires、認証状態などで決まります。
再試行はメソッドの冪等性、要求本文の再送可否、Retry-After、バックオフ、重複処理の危険を評価します。決済POSTを無条件に繰り返すと二重実行につながります。
未知のステータスコード
クライアントは登録されていないコードを受けても、先頭桁の分類を理解できる設計が求められます。たとえば未知の4xxは400に近い一般的な4xxとして扱えますが、キャッシュできる条件など個別コード固有の性質まで推測しません。
独自コードを公開APIで増やす前に、既存の標準コードと、機械判読可能なアプリケーションエラーの本文で表せないか検討します。監視では元の三桁値を失わず記録します。
HTTPステータスコードは応答の機械可読な結果分類です。三桁コード、メソッド、関連ヘッダー、本文、応答した中継点を一緒に読み、画面の文言や分類だけで原因・再試行・キャッシュを決めません。
HTTPの意味とステータスコード：RFC 9110「HTTP Semantics」