HTTP ステータスコードの設計思想 — RFC 9110 の 5 クラス分類と歴史的コードの運命
DDEVELOPER
開発(更新: 2026-09-04)9 分で読める

HTTP ステータスコードの設計思想 — RFC 9110 の 5 クラス分類と歴史的コードの運命

Web 開発者なら毎日目にする 200 OK, 404 Not Found, 500 Internal Server Error。しかし「なぜ 3 桁なのか」「なぜ先頭の数字でクラスが決まるのか」「418 I'm a teapot は本当に公式なのか」と問われると、即答できる人は少ないのではないでしょうか。本記事では RFC 9110 (HTTP Semantics, 2022) を一次資料に、HTTP ステータスコードの設計思想、30 年にわたる仕様の変遷、そして個性的なコードの物語を整理します。

#HTTP#ステータスコード#RFC 9110#Web#プロトコル

HTTP/0.9 にはステータスコードがなかった

Tim Berners-Leeが設計した初期のHTTP(後にHTTP/0.9と呼ばれる)は、驚くほどシンプルなプロトコルでした。リクエストは GET /path の1行だけ。レスポンスはヘッダーもステータス行もなく、本文がそのまま返される形式でした。

RFC 1945 (HTTP/1.0, 1996) は HTTP/0.9 のレスポンス形式を以下のように定義しています:

Simple-Response = [ Entity-Body ]

この形式には、成功・失敗を機械的に区別するステータス行がありません。本文で人向けの説明を返すことはできても、現在のHTTPのようにエラー、転送、条件付き応答をコードで伝える契約はありませんでした。

1992年の設計資料から RFC 1945 (1996) へ

HTTPの3桁ステータスコードはRFC 1945で初めて登場したわけではありません。W3Cに残る1992年のHTTP設計資料には3桁のコードと応答クラスがすでに記載され、別の設計メモはFTPの3桁コードを例として明示しています。後のRFCだけから「なぜ3桁か」を推測する必要はありません。

Tim Berners-Lee、Roy Fielding、Henrik Frystykが著した RFC 1945 (May 1996) はHTTP/1.0を文書化し、ステータスコードを含むレスポンスの先頭行を Status-Line として定義しました:

Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
例: HTTP/1.0 200 OK

RFC 1945は3桁の形式と先頭桁による分類を文書化しました。現在の実装で重要なのは、先頭桁だけでも応答クラスを判別できる点です。

HTTP/1.0で文書化されたステータスコードは15個でした。200, 201, 202, 204, 301, 302, 304, 400, 401, 403, 404, 500, 501, 502, 503です。これらの番号は現在のIANA台帳にもすべて登録されています。

5 クラス分類 — 先頭の数字が意味を決める

RFC 9110 §15 では、ステータスコードの先頭桁による 5 つのクラスを定義しています:

表が収まらない場合は、左右にスクロールできます。

クラス範囲意味代表例
1xx100-199情報応答 (Informational)100 Continue, 101 Switching Protocols, 103 Early Hints
2xx200-299成功 (Successful)200 OK, 201 Created, 204 No Content
3xx300-399リダイレクト (Redirection)301 Moved Permanently, 304 Not Modified
4xx400-499クライアントエラー (Client Error)400 Bad Request, 404 Not Found, 429 Too Many Requests
5xx500-599サーバーエラー (Server Error)500 Internal Server Error, 503 Service Unavailable

この分類の設計上の要点は、クライアントが未知のステータスコードを受け取っても、先頭桁で応答クラスを判断できることです。RFC 9110 §15 は、未認識のステータスコードを同じクラスの x00 と同等に扱うよう定めています。将来コードが追加された場合にも、既存クライアントがクラス単位で処理できる仕組みです。

未知のコードという理由だけで、キャッシュ保存が一律に禁止されるわけではありません。保存の可否は RFC 9111 §3 の条件で別途判断します。未知のコードでも、応答の max-age などの明示的な指定があり、no-store や共有キャッシュの制限など、その他の条件も満たせば保存が認められる場合があります。ただし、must-understand が付く応答や 206・304 の保存には、そのステータスコードの意味をキャッシュが理解している必要があります。クラスを判断できることと、無条件に保存・再利用できることは別です。

仕様の変遷 — RFC 2068 から現行HTTP仕様へ

HTTPの仕様は複数世代のRFCを経て整理されてきました:

表が収まらない場合は、左右にスクロールできます。

RFC年月バージョン備考
RFC 19451996-05HTTP/1.0HTTP/1.0として15個のコードを文書化
RFC 20681997-01HTTP/1.1初版。100 Continue 追加、持続的接続デフォルト化
RFC 26161999-06HTTP/1.1RFC 2068を廃止した改訂版。後にRFC 7230〜7235等で廃止
RFC 7230-72352014-06HTTP/1.16 分冊に分割。曖昧さを解消、ABNF を厳密化
RFC 9110-91142022-06HTTP意味論、キャッシュ、HTTP/1.1、HTTP/2、HTTP/3を分冊化。RFC 9110が各バージョンに共通する意味論を定義

特に重要なのは 2022 年の改訂です。RFC 9110 は「HTTP/1.1 の仕様」ではなく「HTTP の意味論」として再定義されました。ステータスコードの定義は HTTP/1.1、HTTP/2、HTTP/3 のすべてで共通です。トランスポート層 (TCP, QUIC) が変わっても、ステータスコードの意味は変わりません。

418 (Unused) — エイプリルフールRFCに由来する予約コード

418 I'm a teapotRFC 2324 (1998 年 4 月 1 日) に登場します。この文書はInternet StandardではないInformational RFCで、HTCPCP (Hyper Text Coffee Pot Control Protocol) というコーヒーポットをHTTPで制御するジョーク仕様です。

ティーポットにコーヒーを淹れるよう要求すると 418 I'm a teapot が返される、という設定です。

現行のIANA台帳とRFC 9110 §15.5.19では、418の名称は "(Unused)" です。RFC 2324の歴史的な意味は残っていますが、現行HTTPの用途として割り当てられているコードではありません。新しい実装では使用せず、歴史的背景と現在の登録状態を分けて理解する必要があります。

402 Payment Required — 初期資料から現行仕様まで用途が未確定

402 Payment Required はW3Cに残る1992年のステータスコード資料にすでに登場し、HTTP/1.1初版のRFC 2068 (1997)にも収録されました。現行のRFC 9110 §15.5.3でも「reserved for future use (将来の使用のために予約)」と記されています。長い歴史があっても、相互運用可能な標準用途は現在も定義されていません。

仕様は用途を具体化していないため、支払い失敗や契約状態などへ独自に割り当てても相互運用可能な標準用法にはなりません。APIで採用する場合は、HTTP標準の意味として扱わず、独自契約であることを明記する必要があります。

103 Early Hints — パフォーマンス最適化の新顔

103 Early HintsRFC 8297 (2017 年 12 月) で定義された情報応答です。RFC 8297自体の文書カテゴリはExperimentalであり、最終応答より前にヒントを送る仕組みを定義しています。

用途は明確で、サーバーが最終レスポンス (200 OK) を準備している間に、先行して Link ヘッダを送信し、ブラウザに CSS・フォント・JavaScript の先読み (preload) を開始させます:

HTTP/1.1 103 Early Hints
Link: </style.css>; rel=preload; as=style
Link: </app.js>; rel=preload; as=script

(... サーバーが DB 問い合わせ等を実行中 ...)

HTTP/1.1 200 OK
Content-Type: text/html
...

103は「最終レスポンスの前に送る暫定レスポンス」という1xxクラスの役割を体現しています。一方、仲介者が転送しない場合やクライアントがヒントを利用しない場合もあるため、最終応答だけでも正しく動作する設計が必要です。利用環境の対応状況と効果は実測して判断します。

IANA レジストリ — ステータスコードの「戸籍」

HTTP ステータスコードの公式な一覧は IANA (Internet Assigned Numbers Authority) が管理する HTTP Status Code Registry にあります。

2026年9月3日に確認した台帳の表示上の最終更新日は2025年9月15日で、個別に登録されたコードは64件です。このうち104は2026年11月13日までの期限付き登録であり、恒久的な一覧とは限りません。100-599の範囲には未割り当ての番号も多く残っています。件数や期限は将来変わるため、実装時には台帳の最新版と各行の参照仕様・登録状態を確認します。

IANAにない番号を製品固有の拡張として使う実装もあります。しかし、IANA未登録コードに標準化された意味はありません。RFC 9110に従うクライアントは未知のコードを同じクラスのx00相当として扱いますが、個別の意味を理解できるとは限らないため、公開APIでは相互運用性に注意が必要です。

まとめ

  • 初期HTTP(後のHTTP/0.9)にはステータス行がなく、レスポンスは本文のみ
  • 1992年のW3C資料に3桁コードがすでにあり、RFC 1945 (1996) はHTTP/1.0として15個のコードと先頭桁分類を文書化
  • 5 クラス (1xx-5xx) の設計: 未知のコードも先頭桁で適切に処理できる前方互換性
  • RFC 9110 (2022) で「HTTP Semantics」として再整理、HTTP/1.1/2/3 共通の意味論に
  • 418: RFC 2324での歴史的名称はI'm a teapot、現行台帳では(Unused)
  • 451: レイ・ブラッドベリ『華氏 451 度』へのオマージュ、法的制限の明示に使用
  • 402 Payment Required: 1992年の歴史資料にも登場するが、現行仕様でも将来用に予約
  • 103 Early Hints: 最終応答前にLink等のヒントを送れる情報応答
  • IANA台帳は2025年9月15日時点で64件(期限付きの104を含む)

参考文献・ソース

記事作成に関する注記

本記事は AI(大規模言語モデル)を編集補助として活用して作成しています。 公開前に編集者が内容を確認していますが、事実誤認・仕様の解釈ミス・最新情報との齟齬が含まれる可能性があります。 重要な判断を行う際は、本文中の一次ソースや公式ドキュメントを必ずご自身でご確認ください。 誤りにお気づきの場合は、お問い合わせフォームよりご連絡いただけると助かります。

🔧 関連ツール

📚 関連記事