📖 HTTP ステータスコード一覧・意味辞典 の使い方
1xx(情報)・2xx(成功)・3xx(リダイレクト)・4xx(クライアントエラー)・5xx(サーバーエラー)の HTTP ステータスコード一覧を網羅した辞典ツールです。コード番号やキーワードで即検索でき、API 開発・エラーハンドリング・SEO を意識したリダイレクト設計の確認に活用できます。
🚀 ステータスコードを調べる →📌 このツールでできること
- 🔍 キーワード検索:コード番号(例:
404)または名称・キーワード(例:Not Found)で即検索 - 🏷️ カテゴリフィルタ:1xx / 2xx / 3xx / 4xx / 5xx のカテゴリボタンで絞り込み表示
- 📋 全コード収録:RFC 準拠の標準コードに加え、実務でよく使われるコードを網羅
- 💡 用途説明カード:各コードの意味・一般的な用途・使用例をカード形式で表示
- 🌙 ダーク / ライトテーマ対応
🚀 使い方
-
コード番号またはキーワードで検索する
検索ボックスにコード番号(例:422)またはキーワード(例:unauthorized・認証・リダイレクト)を入力します。入力のたびにリアルタイムで結果が絞り込まれます。コード番号の一部(例:50)を入力すると 500・501・502… のように前方一致で絞り込まれます。 -
カテゴリボタンで絞り込む
1xx / 2xx / 3xx / 4xx / 5xx のカテゴリボタンをクリックしてカテゴリで絞り込みます。「4xx エラーの一覧を見たい」「3xx リダイレクト系を全部確認したい」という場合に便利です。キーワード検索とカテゴリフィルタは同時に適用できます(例:4xx カテゴリ内で「auth」を検索)。 -
コードカードで意味・用途を確認する
表示されたカードで各コードの正式名称(英語)・意味・一般的な用途・使用例を確認します。意味だけでなく「どのような場面で返すべきか」という設計指針も記載しています。 -
「全て表示」でリセットする
「全て表示」ボタンを押すとフィルタ・検索をリセットして全コードを表示します。俯瞰的に全ステータスコードを眺めて体系を把握したいときに使ってください。
💡 よく使う HTTP ステータスコード一覧
✅ 2xx — 成功
- 200 OK:リクエスト成功。GET・PUT・PATCH のレスポンスとして最もよく使われる。
- 201 Created:リソースの作成成功。POST でリソースを新規作成したときに返す。
Locationヘッダで作成されたリソースの URI を示すことが多い。 - 204 No Content:成功したがボディなし。DELETE や一部の PUT で使われる。
↩️ 3xx — リダイレクト
- 301 Moved Permanently:恒久的なリダイレクト。URL 変更時に SEO 的に重要。ブラウザ・検索エンジンがリダイレクト先をキャッシュする。
- 302 Found:一時的なリダイレクト。ログイン後のリダイレクトなどに使われる。
- 304 Not Modified:キャッシュが有効。ブラウザは保存済みのリソースを使用してよい。
❌ 4xx — クライアントエラー
- 400 Bad Request:リクエストの形式や内容が不正。バリデーションエラーの汎用コード。
- 401 Unauthorized:認証が必要・認証失敗。
WWW-Authenticateヘッダで認証方式を示す。「Unauthorized」という名称だが実態は「Unauthenticated(未認証)」。 - 403 Forbidden:認証済みだがアクセス権限なし。認可(Authorization)の失敗。
- 404 Not Found:リソースが存在しない。最も有名なエラーコード。
- 422 Unprocessable Entity:リクエスト形式は正しいが内容が処理できない。バリデーションエラーに使う API が多い(FastAPI のデフォルト等)。
- 429 Too Many Requests:レートリミット超過。
Retry-Afterヘッダで再試行タイミングを示す。
💥 5xx — サーバーエラー
- 500 Internal Server Error:サーバー内部エラー。予期しない例外の汎用エラーコード。
- 502 Bad Gateway:上流サーバーからの不正なレスポンス。ロードバランサー・リバースプロキシの背後のサービスが落ちているときに多い。
- 503 Service Unavailable:サービス一時的に利用不可。メンテナンス中やサーバー過負荷時に使う。
🆚 迷いやすい HTTP ステータスコード比較
- 301 と 302:恒久移転か一時移転かで使い分けます。SEO を意識した URL 移転では 301 が基本です。
- 401 と 403:未認証か、認証済みだが権限不足か、という違いです。
- 400 と 422:構文エラーや形式不正は 400、入力内容の妥当性エラーは 422 が典型です。
- 500 と 503:想定外の内部障害は 500、一時停止や過負荷など復旧見込みのある停止は 503 が適しています。
🧭 HTTP ステータスコードを調べるコツ
検索欄ではコード番号だけでなく、not found、認証、リダイレクト、バリデーション のようなキーワードでも絞り込みできます。まず 4xx / 5xx のカテゴリを選び、その後にキーワードで絞ると目的のコードに素早くたどり着けます。
実装確認とあわせて HTTP リクエスト送信 を使うと、実際に返ってきたレスポンスコードと意味を突き合わせながらデバッグできます。API 実装時は 200 / 201 / 204、認証系は 401 / 403、入力エラーは 400 / 422 といった軸で見ると整理しやすいです。
💡 活用例
REST API 開発中のステータスコード選択
REST API を設計・実装する際、レスポンスに適切なステータスコードを選ぶ判断が必要です。「新しいリソースを POST で作成したときは 200 か 201 か」「バリデーションエラーは 400 か 422 か」「削除成功時は 200 か 204 か」といった迷いを素早く解消できます。チーム内でコードの使い分けルールを統一する際の参考資料としても活用できます。
エラーハンドリング実装時の確認
フロントエンドから API を呼び出す際のエラーハンドリング実装時、各ステータスコードに対してどのような処理(再試行・ログイン画面への遷移・エラーメッセージ表示・ユーザーへの通知)を行うべきかを確認できます。401 と 403 の違いを正しく理解してハンドリング処理を分岐させることで、UX の向上やセキュリティの強化につながります。
クライアント・チームへの説明資料
「API が 422 を返している」「なぜ 403 になるのか」という問い合わせに対して、ステータスコードの意味を説明する際の参考資料として使えます。エンジニア以外(QA・PM・デザイナー)にも伝わりやすい日本語での説明が確認できるため、コミュニケーションコストを下げられます。
SEO・リダイレクト設定の確認
サイトリニューアル・URL 変更時に 301(恒久的リダイレクト)と 302(一時的リダイレクト)のどちらを使うべきかを確認できます。301 は検索エンジンにリンクジュース(SEO 評価)を引き継ぐシグナルを送り、302 は元の URL に評価を残します。誤って 302 を使い続けると SEO に悪影響が出る可能性があります。
HTTP の学習・試験対策
Web 開発の学習や IT 系の資格試験(基本情報技術者・応用情報技術者・AWS 認定ソリューションアーキテクト・Google Cloud 認定など)で HTTP ステータスコードの知識が問われる場面に対応できます。1xx〜5xx のカテゴリ別に整理された一覧で体系的に学習でき、よく出題される 200・301・401・403・404・500 の違いを集中的に確認できます。
Nginx・Apache などの Web サーバー設定確認
Nginx の設定で return 301 https://example.com$request_uri; と書いた場合、301 が何を意味するかを即確認できます。エラーページのカスタマイズ(error_page 404 /404.html;)や、メンテナンスページの 503 返却設定の際にも各コードの意味を確認しながら作業できます。
🔍 HTTP ステータスコードの技術的背景
HTTP ステータスコードは RFC 7231(HTTP/1.1)および RFC 9110(HTTP Semantics)で標準化された3桁の数値コードです。Web サーバーがクライアントのリクエストに対して処理結果を伝えるために使用します。
ステータスコードの分類
- 1xx(Informational):処理継続中の暫定レスポンス。
100 Continue・101 Switching Protocols(WebSocket 接続確立時)など。 - 2xx(Successful):リクエストの受け付けと処理成功。
200・201・204など。 - 3xx(Redirection):リクエストを完了するために追加アクションが必要。
301・302・304など。 - 4xx(Client Error):クライアント側の誤りによるエラー。
400・401・403・404・429など。 - 5xx(Server Error):サーバー側の問題によるエラー。
500・502・503など。
REST API 設計でのベストプラクティス
適切なステータスコードを返すことは、API の使いやすさと自己説明性を高めます。4xx と 5xx を正しく区別することで、クライアント側がエラーの原因(自分の問題かサーバーの問題か)を判断できるようになります。
FastAPI・Express でのステータスコード返却例
# FastAPI (Python) の例
from fastapi import FastAPI, HTTPException
from fastapi.responses import JSONResponse
app = FastAPI()
@app.get("/users/{user_id}", status_code=200)
def get_user(user_id: int):
user = db.get(user_id)
if user is None:
raise HTTPException(status_code=404, detail="User not found")
return user
@app.post("/users", status_code=201)
def create_user(user: UserCreate):
new_user = db.create(user)
return new_user
@app.delete("/users/{user_id}", status_code=204)
def delete_user(user_id: int):
db.delete(user_id)
return None # 204 No Content はボディなし
// Express (Node.js) の例
app.get('/users/:id', (req, res) => {
const user = db.get(req.params.id);
if (!user) return res.status(404).json({ error: 'User not found' });
res.status(200).json(user);
});
app.post('/users', (req, res) => {
const newUser = db.create(req.body);
res.status(201).location(`/users/${newUser.id}`).json(newUser);
});
// 認証ミドルウェア
app.use('/admin', (req, res, next) => {
if (!req.user) return res.status(401).json({ error: 'Authentication required' });
if (!req.user.isAdmin) return res.status(403).json({ error: 'Insufficient permissions' });
next();
});
よく使われる HTTP レスポンスヘッダとの組み合わせ
| ステータスコード | 一緒に使うヘッダ | 説明 |
|---|---|---|
| 201 Created | Location | 作成されたリソースの URI を指定 |
| 301/302 | Location | リダイレクト先 URL を指定 |
| 304 Not Modified | ETag, Last-Modified | キャッシュ検証に使用 |
| 401 Unauthorized | WWW-Authenticate | 認証スキーム(Bearer・Basic)を指定 |
| 429 Too Many Requests | Retry-After | 再試行可能になる時刻・秒数を指定 |
| 503 Service Unavailable | Retry-After | メンテナンス終了・復旧予定時刻を指定 |
HTTP/1.1・HTTP/2・HTTP/3 でのステータスコード
HTTP のバージョン(1.1・2・3)が変わっても、ステータスコード自体は RFC 9110 で共通に定義されています。HTTP/2・3 ではプロトコルレベルの効率化(ヘッダー圧縮・多重化)が行われますが、ステータスコードの意味は同じです。101 Switching Protocols は HTTP/1.1 での WebSocket へのアップグレードに使われますが、HTTP/2 以降では異なるメカニズム(CONNECT メソッド)が使われます。
⚙️ よく使う API 設計パターンとステータスコード
CRUD 操作の標準的なステータスコード
| HTTP メソッド | 操作 | 成功時 | エラー時 |
|---|---|---|---|
| GET | リソース取得 | 200 OK | 404 Not Found |
| POST | リソース作成 | 201 Created | 400/422 Validation Error |
| PUT | リソース完全更新 | 200 OK | 404 / 422 |
| PATCH | リソース部分更新 | 200 OK | 404 / 422 |
| DELETE | リソース削除 | 204 No Content | 404 Not Found |
認証・認可フローのステータスコード
| 状況 | コード | 理由 |
|---|---|---|
| トークンなし・未ログイン | 401 | 認証が必要(Unauthenticated) |
| トークン期限切れ | 401 | 再認証が必要 |
| ログイン済みだが権限不足 | 403 | 認可エラー(Unauthorized) |
| 存在を隠したいリソース | 404 | Security through obscurity |
| レートリミット超過 | 429 | Retry-After ヘッダで再試行時間を示す |
❓ よくある質問
- Q. よく出る 404 や 500 もこのページで確認できますか?
- はい。404、500、301、401、403、422、429 など頻出コードを一覧と検索の両方で確認できます。カテゴリ別に眺めたいときはツール本体、違いまで理解したいときはこのガイドが向いています。
- Q. 401 と 403 の違いは何ですか?
- 401 Unauthorized は「認証(Authentication)が必要または失敗した」ことを意味します(名前と意味が直感に反するので注意)。403 Forbidden は「認証済みだがそのリソースへのアクセス権限(認可: Authorization)がない」ことを意味します。ログインしていない → 401、ログインしているが管理者ページにアクセス → 403 という使い分けが一般的です。
- Q. 400 と 422 の使い分けは?
- 400 Bad Request はリクエストの構文やフォーマット自体が不正な場合(JSON の構文エラーなど)に使います。422 Unprocessable Entity はフォーマットは正しいが、内容が処理できない場合(バリデーションエラー:メールアドレスの形式が不正など)に使います。FastAPI はバリデーションエラーに 422 を返すのがデフォルトです。
- Q. 404 を返すべきか 403 を返すべきか迷います。
- セキュリティ上の観点から、アクセス権限のないリソースに対して 403 を返すとリソースの存在が明らかになってしまう場合は、あえて 404 を返すことがあります(Security through obscurity)。公開リソースの場合は 403、存在を隠したい場合は 404 を返す設計が一般的です。
- Q. 301 と 302 は SEO にどう影響しますか?
- 恒久的な URL 変更であれば 301 を使うのが一般的です。302 は一時的な転送の意図を示すため、恒久移転なのに 302 を使うと検索エンジンへのシグナルが弱くなることがあります。
- Q. 502 と 503 の違いは?
- 502 Bad Gateway はリバースプロキシ・ロードバランサーが上流サーバーから無効なレスポンスを受けた場合に返します。上流サービスがクラッシュしている時に多く見られます。503 Service Unavailable はサーバーが一時的に処理できない状態(過負荷・メンテナンス)を示します。
Retry-Afterヘッダで再試行時間を伝えることが推奨されています。 - Q. 全ステータスコードを確認できますか?
- はい。IANA に登録されている全ての標準 HTTP ステータスコードを収録しています。カテゴリフィルタで「全て」を選択すると、1xx から 5xx まですべてのコードを一覧で確認できます。
📚 関連書籍・商品 PR
※ 本リンクはアフィリエイト広告を含みます。