HTTP ステータスコード一覧

HTTP ステータスコード一覧の使い方

1. 1テキストを入力またはペーストします
2. 2「変換する」ボタンをクリックします
3. 3結果を確認してコピーします

良いHTTP ステータスコード一覧の判断基準

エラー画面や API レスポンスで見慣れないステータスコードに出会ったら、まず本ツールでコードの意味と利用シーンを調べ、下の判断基準で原因の切り分けを進めてください。コードは「どちら側に原因がありそうか」を示すヒントであり、コード単体で原因を断定するものではありません。

• 百の位のカテゴリから切り分けを始めたか

  4xx はクライアント側（リクエスト内容）起因、5xx はサーバー側起因という大分類がスタート地点です。個別のコードの意味を調べる前に、まずどちら側を疑うべきかを百の位で判断します。

• コードだけで原因を断定していないか

  同じコードでも原因は複数あり得ます。コードはあくまで分類で、実際の原因はレスポンスボディのエラーメッセージやサーバーログと合わせて特定します。

• 4xx ならリクエスト内容を見直したか

  URL の打ち間違い・必須パラメータの欠落・認証情報の不足など、送っている側の内容をまず確認します。サーバー障害を疑う前に、自分のリクエストが仕様通りかを見直すのが先です。

• 5xx ならサーバー側の状態を確認したか

  サーバーログ・直前のデプロイ・依存している外部サービスの稼働状況を確認します。5xx は受け取る側では直せないことが多いため、運用側への連絡や時間を置いた再試行が基本の対応になります。

• 似た者同士のコードの定義を確認したか

  認証まわりの 401 と 403、リダイレクトの 301 と 302 など、混同しやすいコードがあります。API 設計やドキュメント作成で使う前に、一覧で定義の違いを確認してから選びます。

• キャッシュやリダイレクトの影響を考えたか

  3xx 系はブラウザや中間サーバーのキャッシュに影響され、古い挙動が残ることがあります。挙動が説明できない時は、キャッシュを無効にした状態で再確認すると切り分けが進みます。

ありがちな失敗例（NG → 改善）

API 設計でコードを毎回調べ直す手間

バックエンド開発で API 設計する時、「リソース作成成功は 200？ 201？」「バリデーションエラーは 400？ 422？」「レート制限は 429？」と毎回 MDN を見に行くのは時間の無駄。本ツールは主要 26 コードを一覧 + 検索 + カテゴリ絞り込みですぐ確認できます。各コードの「利用シーン」も併記しているため、設計判断にすぐ使えます。

コードカテゴリ別ガイド

【1xx Informational】100 Continue / 101 Switching Protocols（プロトコル切替） 【2xx Success】200 OK（一般成功）/ 201 Created（POST 成功）/ 204 No Content（DELETE 成功） 【3xx Redirection】301 恒久移動 / 302 一時 / 304 キャッシュ / 307 メソッド維持一時 / 308 メソッド維持恒久 【4xx Client Error】400 構文エラー / 401 認証 / 403 権限 / 404 不在 / 409 競合 / 422 バリデーション / 429 レート制限 【5xx Server Error】500 内部 / 502 Bad Gateway / 503 メンテ / 504 タイムアウト

よく迷うコードの使い分け

【200 vs 201 vs 204】データ返す = 200 / リソース作成 = 201 / 削除成功で本文不要 = 204

【301 vs 302 vs 307 vs 308】恒久移動 + メソッド変更可 = 301 / 一時移動 + メソッド変更可 = 302 / 一時 + メソッド維持 = 307 / 恒久 + メソッド維持 = 308。SEO では 301 / 308 がリダイレクト先に評価引き継ぎ。

【401 vs 403】認証情報なし or 不正 = 401 / 認証 OK だが権限不足 = 403。WWW-Authenticate ヘッダの有無で判別。

【400 vs 422】JSON パース失敗 / 必須欠落 = 400 / フォーマットは合うが値が不正（email 形式違反等） = 422

【404 vs 410】「もう存在しない」を SEO に伝えたい = 410（Gone）。404 は「将来復活するかも」のニュアンス

今回試した検索条件

実際の挙動を確かめるため、実在するコード（404、および混同しやすい 401）と、実在しない番号（999）を検索窓に入れて結果を見ました。以下はいずれも本ツールの実際の表示です。

実処理結果（実在するコードと存在しない番号を引いたとき）

「404」を検索すると、1 件が表示され、内容は次のとおりでした。 404 | Not Found | リソース不在 | 存在しない URL / ID

混同しやすい「401」を検索したときも 1 件が表示され、内容は次のとおりでした。 401 | Unauthorized | 認証必要 | Authorization ヘッダ未設定 / トークン期限切れ

一方、実在しない「999」を検索すると、表示件数は 0 件となり、結果の表は空になりました。このとき「見つかりません」といった案内メッセージは出ず、表が空のまま残るだけでした。

検索して分かったクセ

実在するコードを入れると、コード番号・名前・説明・主な利用シーンが1行の表として返ります（404 なら「Not Found／リソース不在／存在しない URL・ID」という具合です）。検索窓はコード番号のほか名前や説明でも絞り込める作りで、画面にはカテゴリ（1xx Informational 〜 5xx Server Error）での絞り込みも用意されています。表示件数は「1 件表示」「0 件表示」のように件数が出ます。これらは今回引いた3件（404・401・999）で観測できた挙動であり、収録された全コードで内容の正しさまで確認したわけではありません。

崩れた点と、構造上の限界

はっきり崩れたのは、実在しない番号を引いたときの扱いです。999 を検索すると 0 件になりますが、「そのコードは一覧にありません」といった案内は出ず、表が空になるだけでした。検索した本人は、番号の打ち間違いなのか、そもそも一覧に無いコードなのかを、画面から判断できません。また、今回試した 999 のように一覧に無い番号は 0 件になります。本ツールは主要な標準コードの早見表であり、独自に拡張された番号までは収録していない点に注意してください。

このツールに任せないほうがよい判断

実装時に「このケースで何番を返すべきか」の最終判断を、この一覧の一言説明だけで決め切るのは避けたほうが安全です。たとえば 401 と 403、400 と 422 のように意味が近いコードは、上の「よく迷うコードの使い分け」も併せて読み、要件に照らして選んでください。仕様の厳密な定義が要る場面では、一次情報（各 RFC や MDN のドキュメント）で裏を取るのが確実です。

表示された説明をそのまま使うかの判断基準

表示される説明は、短い早見表として使う分には十分です。そのまま設計メモや社内ドキュメントに引き写してよいのは、今回 1 件で返った 404 や 401 のように定義がはっきりしたコードを、概要として共有する場面までです。API のレスポンス仕様書のように厳密さが問われる文書へ転記するときは、コードの意味を一次情報で確認し、自社の要件に合わせて説明文を書き足してください。実在しない番号で 0 件になったときは、コードの打ち間違いか、標準外の番号かをまず疑うと切り分けが早くなります。

ステータスコード運用でやりがちな誤り

1つ目: 全部 200 で返す → エラー時も 200 + body にエラー JSON は anti-pattern。HTTP セマンティクス壊す。

2つ目: 5xx を「クライアント原因」で返す → サーバ無関係のクライアント不正は 4xx。5xx は CloudWatch / Datadog のアラート対象。

3つ目: 認証関連で「401 Forbidden」と書くドキュメント → 「Forbidden」は 403。本来は「401 Unauthorized」。混同が業界全体で多い。

4つ目: Retry-After ヘッダ忘れ → 429 / 503 は Retry-After（秒数 or HTTP-date）を付けると親切。

5つ目: CORS のプリフライト失敗 → ブラウザは「CORS エラー」と表示するが、実態は 4xx / 5xx の HTTP レスポンス。サーバログで確認。