HTTPステータスコードを理解すべき理由#

ECサイトの決済中に500エラーが発生し、お客様には「問題が発生しました」と表示されます。しかし、実際に何が起きたのでしょうか?サーバーは正常に動作しています。データベースも稼働しています。原因はまったく別の場所にあるのに、500というコードだけでは何もわかりません。

APIエンドポイントが429エラーを返し、モバイルアプリが再試行メッセージを表示せずにクラッシュしてしまいます。実際にはレートリミッターが正しく機能しているだけなのに、ユーザーはアプリが壊れていると思い込みます。

ステータスページには「すべてのシステムは正常です」と表示されているのに、お客様からはページが403 Forbiddenで読み込めないと報告が入ります。モニタリングがホームページしかチェックしていなかったため、検出できなかったのです。

HTTPステータスコードはシグナルです。何が間違っていて、どこを見ればよいのかを教えてくれます。ただし、各コードの意味を理解していればの話です。

このガイドでは、遭遇する可能性のあるすべてのHTTPステータスコードについて、何がトリガーになるのか、見たときに何をすべきかを解説します。

HTTPステータスコード:全体像#

HTTPレスポンスは5つのクラスに分類されます。

1xx (100-199): 情報レスポンス — 「リクエストを受信、処理中」
2xx (200-299): 成功 — 「すべて正常」
3xx (300-399): リダイレクション — 「別の場所を試してください」
4xx (400-499): クライアントエラー — 「あなた側の問題です」
5xx (500-599): サーバーエラー — 「私たち側の問題です」

各クラスは問題の所在を示します。4xxエラーが出ている場合は、リクエスト側に問題があります(URLの間違い、認証エラー、データの欠落など)。5xxエラーが出ている場合は、サーバー側に問題があります。

2xx 成功ステータスコード(すべて正常)#

200 OK#

意味: リクエストは成功しました。レスポンスボディには要求されたデータが含まれています。

遭遇する場面:

ブラウザがウェブページを読み込む
APIがJSONデータを返す
フォーム送信が成功する

例:

GET /api/users/123
Response: 200 OK
Body: {"id": 123, "name": "John", "email": "john@example.com"}

対応: 不要。すべて正常に動作しています。

201 Created#

意味: リクエストは成功し、新しいリソースが作成されました。レスポンスには新しく作成されたリソースが含まれます。

遭遇する場面:

新しいユーザーを作成するPOSTが201 Createdを返す
新しい注文の作成で201 Createdが返る
ファイルアップロードで201 Createdが返る

例:

POST /api/users
Request: {"name": "Jane", "email": "jane@example.com"}
Response: 201 Created
Body: {"id": 456, "name": "Jane", "email": "jane@example.com", "created_at": "2026-02-20T10:00:00Z"}

対応: 不要。リソースが正常に作成されました。

202 Accepted#

意味: リクエストは処理のために受け付けられましたが、まだ処理されていません。非同期処理に使われます。

遭遇する場面:

長時間実行ジョブの送信(動画エンコード、レポート生成など)
バッチ処理操作
バックグラウンドで処理されるタスク

例:

POST /api/batch-emails/send
Request: {"recipient_ids": [1,2,3,...,10000]}
Response: 202 Accepted
Body: {"job_id": "job_12345", "status": "queued"}

対応: タスクはキューに登録されました。ジョブIDを使って後でステータスを確認してください。

204 No Content#

意味: リクエストは成功しましたが、返すコンテンツがありません。

遭遇する場面:

DELETEリクエスト(削除成功、返すものなし)
レスポンスボディなしの成功したPATCH
Webhookの確認応答

例:

DELETE /api/users/123
Response: 204 No Content
Body: (空)

対応: 不要。アクションは成功しました。

3xx リダイレクションステータスコード(別の場所を試して)#

301 Moved Permanently#

意味: リソースは新しいURLに恒久的に移動しました。検索エンジンはインデックスを更新し、ブラウザは今後のリクエストで新しいURLを使用します。

遭遇する場面:

ウェブサイトがwww.oldsite.comからnewsite.comへ移行
古いAPIエンドポイントが新しいものに置き換わった
URL構造の変更

例:

GET /old-page.html
Response: 301 Moved Permanently
Header: Location: /new-page.html

対応:

ユーザー向け: ブラウザが自動的にリダイレクトに従います(透過的)
SEO向け: 恒久的な変更には必ず301を使ってください(Googleはページランクを引き継ぎます)
API向け: クライアントは新しいURLに更新する必要があります

302 Found(一時リダイレクト)#

意味: リソースは別のURLに一時的に移動しました。元のURLは依然として有効なため、ブラウザは新しいURLをキャッシュしません。

遭遇する場面:

メンテナンス中の一時リダイレクト
ログインページへのリダイレクト
A/Bテスト(一部のユーザーを一時的に新バージョンへリダイレクト)

例:

GET /products/discount-flash-sale
Response: 302 Found
Header: Location: /products/2026-flash-sale

対応: ブラウザは一時的にリダイレクトに従いますが、元のURLを引き続き主URLとして扱います。

304 Not Modified#

意味: リソースは前回のリクエスト以降変更されていません。キャッシュされたバージョンを使用してください。

遭遇する場面:

ブラウザが前回の訪問以降ウェブページが変更されたかを確認(更新日/ETagをチェック)
前回のリクエスト以降データが変わっていない場合、APIが304を返す
変更のないデータの再送を避けて帯域幅を削減

例:

GET /api/user-profile
Request Header: If-Modified-Since: 2026-02-19 10:00:00
Response: 304 Not Modified
Body: (空 — 以前のキャッシュバージョンを使用)

対応: ブラウザ/クライアントはローカルのキャッシュバージョンを使用します。

307 Temporary Redirect#

意味: 302と似ていますが、リダイレクト中もHTTPメソッドが変わらないことが保証されます。

技術的な違い:

302はメソッド変更を許容(リダイレクト後にPOST → GET)
307はメソッドを保持(リダイレクト後もPOST → POST)

遭遇する場面:

フォーム送信から確認ページへのリダイレクト(POST → POST)
メソッドを保持する必要があるAPIリダイレクト

重要な理由: 古いブラウザでは、POSTのリダイレクトをGETに変換してしまい、フォームデータが失われることがありました。307はこれを防ぎます。

4xx クライアントエラーコード(あなた側の問題)#

400 Bad Request#

意味: リクエストが不正です。サーバーが理解できませんでした。

遭遇する場面:

リクエストボディのJSONが不正
必須フィールドの欠落
パラメータ形式が不正
クエリ文字列の構文エラー

例:

POST /api/users
Request Body: {"name": "Jane" "email": "jane@example.com"}
                              ↑ カンマが欠落
Response: 400 Bad Request
Body: {"error": "Invalid JSON syntax"}

対応:

リクエストの書式を確認する
JSON構文を検証する
必須フィールドが揃っているか確認する
パラメータの型がAPI仕様に合致するか検証する

401 Unauthorized#

意味: 認証が失敗したか、認証情報が欠落しています。あなたが誰なのかを証明できていません。

遭遇する場面:

認証トークンが提供されていない
認証トークンが無効または期限切れ
ユーザー名/パスワードが間違っている
APIキーが欠落

例:

GET /api/user-profile
(Authorizationヘッダーなし)
Response: 401 Unauthorized
Body: {"error": "Authentication required"}

対応:

有効な認証情報を提供する(ログイン、APIキー、トークンなど)
期限切れトークンを更新する
認証情報が正しいか確認する

403 Forbidden#

意味: 認証は成功しましたが、このリソースにアクセスする権限がありません。

遭遇する場面:

ユーザーが他のユーザーのアカウントを削除しようとした
管理者専用エンドポイントへのアクセス試行
別組織のリソースへのアクセス試行
権限/ロール不足

例:

DELETE /api/users/999
(ユーザー123として認証済みで、ユーザー999を削除しようとしている)
Response: 403 Forbidden
Body: {"error": "You can only delete your own account"}

対応:

適切な権限を持つアカウントを使用する
必要に応じて権限の昇格を申請する
正しいリソースにアクセスしているか確認する

404 Not Found#

意味: リソースが存在しないか、サーバーがこのエンドポイントの処理方法を知りません。

遭遇する場面:

URLのタイプミス(/users/と/users)
エンドポイントが存在しない
削除されたリソース
APIバージョンが間違っている

例:

GET /api/users/nonexistent-id-12345
Response: 404 Not Found
Body: {"error": "User not found"}

対応:

URLのスペルを確認する
エンドポイントが存在するか確認する
API仕様を確認する
別のID/リソースを試す

405 Method Not Allowed#

意味: エンドポイントは存在しますが、このHTTPメソッドをサポートしていません。

遭遇する場面:

GETしか受け付けないエンドポイントでPOSTを使用
削除をサポートしないエンドポイントでDELETEを使用
PUTのみ許可されているのにPATCHを使用

例:

DELETE /api/domains/123
(domainsエンドポイントでDELETEがサポートされていない場合)
Response: 405 Method Not Allowed
Header: Allow: GET, POST, PUT

対応: 正しいHTTPメソッドを使用してください。レスポンスには通常、有効なメソッドを示すAllowヘッダーが含まれます。

408 Request Timeout#

意味: サーバーがクライアントからのリクエスト受信を待ちすぎて、あきらめました。

遭遇する場面:

大きなファイルをアップロード中の遅いクライアント
リクエスト中にネットワーク接続が切断
リクエストがサーバーのタイムアウトより長くかかった(通常30〜300秒)

例:

POST /api/upload
(遅い接続で500MBファイルをアップロードするのに10分かかる)
Response: 408 Request Timeout

対応:

リクエストを再試行する
大きなリクエストを小さなチャンクに分割する
ネットワーク接続を確認する
必要に応じてクライアントのタイムアウトを延ばす

429 Too Many Requests#

意味: リクエストが多すぎます。レート制限を超えました。

遭遇する場面:

APIのレート制限に到達(例: 100リクエスト/分)
メールを送りすぎた
ログインの総当たり攻撃
ウェブスクレイパーがサーバーに過度な負荷をかけている

例:

GET /api/users/123
(直近1分間で100回目のリクエスト)
Response: 429 Too Many Requests
Header: Retry-After: 60
Body: {"error": "Rate limit exceeded. Try again in 60 seconds"}

対応:

再試行前に待機する(Retry-Afterヘッダーを確認)
指数バックオフを実装する
大量の結果セットにはページネーションを使用する
再リクエストの代わりにローカルでキャッシュする

5xx サーバーエラーコード(私たち側の問題)#

500 Internal Server Error#

意味: サーバー側で何かが起こりましたが、サーバーは詳細を提供できません。

遭遇する場面:

コード内の未処理例外
データベース接続失敗
メモリ不足
予期しない条件

例:

POST /api/checkout
Response: 500 Internal Server Error
Body: {"error": "Something went wrong"}

なぜ曖昧なのか: サーバーはセキュリティ上の理由で、内部エラーの詳細をクライアントに公開しません。詳細なエラー情報は攻撃者に手がかりを与えてしまいます。

対応:

サーバーログで実際のエラーを確認する
サードパーティサービスの場合: サポートに連絡する
自社サービスの場合: エラーログを確認し、必要なら再起動、最近のデプロイをロールバックする

501 Not Implemented#

意味: サーバーがこのHTTPメソッドや機能をサポートしていません。

遭遇する場面:

サーバーがHTTP/2機能をサポートしていない
WebSocketがサポートされていない
一部のHTTPメソッドが実装されていない

例:

OPTIONS /api/users
(サーバーがOPTIONSメソッドをサポートしていない)
Response: 501 Not Implemented

対応: 通常は対応不要 — 別のメソッドやサービスを使ってください。最新のAPIではまれです。

502 Bad Gateway#

意味: サーバーが上流サーバーから無効なレスポンスを受け取りました。

実際のシナリオ:

リバースプロキシ(Nginx)がバックエンドに接続できない

Client → Nginx (gateway) → Node.js Backend
                ↑
         バックエンドがダウンまたは応答なし

ロードバランサーが正常なバックエンドに到達できない

Client → Load Balancer → Backend Servers
                      ↑
           すべてのバックエンドがダウンまたは遅延

APIゲートウェイがマイクロサービスに到達できない

Client → API Gateway → Auth Service (down)
                    → User Service
                    → Order Service

発生する理由:

バックエンドサーバーがクラッシュ
ネットワーク接続が失われた
上流サーバーが遅くタイムアウト
上流が不正なレスポンスを返した

例:

GET /dashboard
Response: 502 Bad Gateway

裏側で起きていること:

Nginxがリクエストを受信
localhost:3000のNode.jsサーバーへ転送を試みる
接続拒否(サーバーが起動していない)
Nginxが返したレスポンス: 502 Bad Gateway

対応:

バックエンドサービスが稼働中か確認: docker ps、pm2 status、systemdのステータス
バックエンドへのネットワーク接続を確認
バックエンドのクラッシュログを確認
クラッシュしている場合はバックエンドサービスを再起動
ロードバランサーのルーティングが正しいか確認

503 Service Unavailable#

意味: サーバーが一時的にリクエストを処理できません(メンテナンス、過負荷、依存関係のダウンなど)。

遭遇する場面:

サーバーが再起動中
サーバーが高負荷状態(全接続が使用中)
データベースがダウンまたは移行中
サードパーティの依存関係がダウン
デプロイ進行中(トラフィックが一時停止)

例:

GET /api/users
Response: 503 Service Unavailable
Header: Retry-After: 600
Body: {"error": "Server is undergoing maintenance. Try again in 10 minutes"}

メンテナンス時に503を返す理由:

クライアントに「これは一時的なものなので後でやり直してください」と伝える
ブラウザやクライアントが自動的に再試行することを把握できる
検索エンジンは503を不利に扱わない(500はバグのように見えるが、503はそうではない)

対応:

待ってから再試行する(Retry-Afterヘッダーで待ち時間を確認)
ステータスページでメンテナンス時間枠を確認
内部サービスの場合: デプロイ完了を待ち、ログを確認

504 Gateway Timeout#

意味: サーバーが上流サーバーから時間内にレスポンスを受け取れませんでした。

遭遇する場面:

バックエンドサーバーが遅すぎる
ネットワーク遅延が高すぎる
データベースクエリに時間がかかりすぎている
上流サーバーがハングしている

例:

バックエンドリクエスト:
GET /api/heavy-report
30秒待機...
タイムアウト!
Response: 504 Gateway Timeout

実例の原因:

Client → Nginx (30秒タイムアウト) → Node.js Backend (60秒のクエリ)
                                  ↑
                  Nginxは30秒であきらめる
                  バックエンドはまだクエリを実行中

対応:

バックエンドのパフォーマンスを確認する
遅いデータベースクエリを探す
コードを最適化する
データベースインデックスを追加する
操作が正当に長くかかる場合はタイムアウトを延ばす
長い操作は非同期ジョブに分割する

HTTPステータスコードリファレンス表#

コード	名称	カテゴリ	意味
200	OK	成功	リクエスト成功
201	Created	成功	リソース作成済み
202	Accepted	成功	リクエストを処理キューに登録
204	No Content	成功	成功、レスポンスボディなし
301	Moved Permanently	リダイレクト	恒久的に新しいURLを使用
302	Found	リダイレクト	一時的に別のURL
304	Not Modified	リダイレクト	キャッシュバージョンを使用
307	Temp Redirect	リダイレクト	リダイレクト時にHTTPメソッドを保持
400	Bad Request	クライアントエラー	不正なリクエスト
401	Unauthorized	クライアントエラー	認証が必要
403	Forbidden	クライアントエラー	アクセス拒否
404	Not Found	クライアントエラー	リソースが存在しない
405	Method Not Allowed	クライアントエラー	HTTPメソッドが間違い
408	Request Timeout	クライアントエラー	リクエストが時間切れ
429	Too Many Requests	クライアントエラー	レート制限
500	Internal Server Error	サーバーエラー	一般的なサーバーエラー
501	Not Implemented	サーバーエラー	機能が未サポート
502	Bad Gateway	サーバーエラー	上流サーバーのエラー
503	Service Unavailable	サーバーエラー	サーバーが一時的にダウン
504	Gateway Timeout	サーバーエラー	上流が遅すぎる

HTTPステータスコードの問題をデバッグする方法#

ステップ1: ステータスコードを特定する#

ブラウザの場合:

デベロッパーツールを開く(F12)
Networkタブに移動
失敗したリクエストを確認
Status列にコードが表示される

ターミナルの場合:

curl -i https://example.com/endpoint
# 1行目に表示: HTTP/1.1 200 OK

アプリケーションの場合:

エラーログを確認する
レスポンスオブジェクトを確認する
ほとんどのフレームワークはステータスコードを露出している

ステップ2: 意味を理解する#

カテゴリを使いましょう。

2xx? 想定通りに動作している
3xx? リダイレクト先を確認
4xx? リクエストの形式と権限を確認
5xx? サーバーログと上流の依存関係を確認

ステップ3: レスポンスボディとヘッダーを確認する#

レスポンスボディ: ほとんどのAPIはエラーの詳細を含めます。

{
  "error": "User not found",
  "message": "No user with ID 12345",
  "code": "USER_NOT_FOUND"
}

レスポンスヘッダー: 重要なものは以下です。

Retry-After — 再試行までの待ち時間(429、503)
Allow — 有効なHTTPメソッド(405)
Location — リダイレクト先(3xx)
WWW-Authenticate — 認証方法(401)

ステップ4: コードクラスに応じた対応を取る#

4xx クライアントエラー:

間違ったデータを送りましたか?リクエストを修正
URLにタイプミスはありますか?修正
権限がありませんか?アクセスを申請
エンドポイントが間違っていますか?仕様を確認

5xx サーバーエラー:

サーバーは稼働中ですか?稼働状況を確認
ログにエラーが出ていますか?エラーを修正
上流がダウンしていますか?復旧を待つ
デプロイされましたか?必要ならロールバック

実例: 502 Bad Gatewayをデバッグする#

シナリオ:

GET /api/checkout
Response: 502 Bad Gateway
お客様が購入を完了できない

ステップ1: 502であることを確認 ✓ レスポンスヘッダーにHTTP/1.1 502 Bad Gatewayと表示

ステップ2: 502の意味を確認 ✓ 上流サーバーが正しく応答していない

ステップ3: 問題の診断

バックエンドサービスは稼働中ですか?

docker ps
# 出力: checkout-serviceが稼働していない

✗ checkoutサービスがクラッシュ

ステップ4: 根本原因を特定

ログを確認:

docker logs checkout-service
# Out of memory error!
# Java heap space exhausted

ステップ5: 修正

メモリを増やす:

docker-compose up -d --build

または再起動:

docker restart checkout-service

ステップ6: 検証

curl -i https://api.example.com/api/checkout
# HTTP/1.1 200 OK ✓

ステータスコードをリアルタイムにモニタリングする

モニタリングすべき理由

お客様より先にダウンタイムを検出する
特定エンドポイントだけに影響する5xxエラーをキャッチする
4xxエラーを追跡してAPIの誤用を発見する
429のレート制限を監視してスケーリングのタイミングを判断する

何を監視すべきか

重大(ダウンしたら即通知):

重要なエンドポイント(checkout、login、payment)での5xxエラー

重要(調査が必要):

429エラーの急増(レート制限はキャパシティに近づいているサイン)
502/504エラーの増加(上流の劣化)
403/401エラーの増加(総当たり攻撃の可能性)

情報(トレンドの追跡):

404エラー(間違ったURLがリクエストされている?)
400エラー(クライアントが不正なリクエストを送っている?)

Nova Uptimeでステータスコードを監視する#

Nova UptimeのアップタイムモニタリングはHTTPステータスコードをリアルタイムで追跡します。

モニターが200を返す? サイトは稼働中 ✓
モニターが404を返す? URLが間違っているかエンドポイントが削除された ✗
モニターが429を返す? レート制限を受けている ⚠️
モニターが502/503を返す? バックエンドの問題 ✗
モニターが504を返す? タイムアウト、最適化が必要 ⚠️

Nova Uptimeでは以下が確認できます。

どのステータスコードが返されているか
いつ発生し始めたか
どのエンドポイントが影響を受けているか
時系列での推移

HTTPステータスコードとSEO#

検索エンジンはステータスコードを使ってページのインデックス方法を判断します。

200 OK: このページをインデックスする(通常)

301 Moved Permanently: インデックスを更新して新しいURLを指す

302 Found: 古いURLをインデックスに保持し、リダイレクトに従わない

304 Not Modified: 再クロールしない、最新版が現行

401/403: インデックスしない(アクセス拒否)

404 Not Found: インデックスから削除(ページが消えた)

410 Gone: インデックスから削除(ページが消え、戻ってこない)

429/503/504: あとで再試行(一時的な問題)

5xxエラー: サイトの問題の可能性あり、Googleはクロールを減速させる

サイトの健全性で重要なポイント:

恒久的なURL変更には301を使う(SEO評価を維持)
410を使ってページが消えたことを明示的にGoogleへ伝える
5xxエラーはすぐに修正する(Googleは壊れているサイトを後回しにする)
インデックス対象外のコンテンツでの404を防ぐためにrobots.txtを実装する

まとめ:HTTPステータスコードクイックリファレンス#

すべて正常:

200 OK — 通常の成功
201 Created — 新しいリソースが作成された
204 No Content — 成功、レスポンス不要

別の場所へリダイレクト:

301/302 — 新しいURLへリダイレクトに従う
304 — キャッシュバージョンを使用

あなたが間違えた:

400 Bad Request — リクエストの形式を修正
401 Unauthorized — 認証情報を提供
403 Forbidden — 権限がない
404 Not Found — URLが間違い
429 Too Many Requests — ペースを落とす、レート制限を受けている

私たちが間違えた:

500 Internal Server Error — サーバーログを確認
502 Bad Gateway — バックエンドサービスがダウン
503 Service Unavailable — サーバーが一時的にダウン
504 Gateway Timeout — バックエンドが遅すぎる

Nova Uptimeでモニタリング: Nova UptimeのHTTPモニタリングはこれらのエラーを即座にキャッチし、お客様が気づく前に通知します。重要なエンドポイントを監視し、ステータスコードのトレンドを追跡し、5xxエラーが急増したらアラートを受け取れます。

最終更新日: 2026年2月20日

HTTPステータスコードを理解すべき理由#

HTTPステータスコード:全体像#

2xx 成功ステータスコード(すべて正常)#

200 OK#

201 Created#

202 Accepted#

204 No Content#

3xx リダイレクションステータスコード(別の場所を試して)#

301 Moved Permanently#

302 Found(一時リダイレクト)#

304 Not Modified#

307 Temporary Redirect#

4xx クライアントエラーコード(あなた側の問題)#

400 Bad Request#

401 Unauthorized#

403 Forbidden#

404 Not Found#

405 Method Not Allowed#

408 Request Timeout#

429 Too Many Requests#

5xx サーバーエラーコード(私たち側の問題)#

500 Internal Server Error#

501 Not Implemented#

502 Bad Gateway#

503 Service Unavailable#

504 Gateway Timeout#

HTTPステータスコード リファレンス表#

HTTPステータスコードの問題をデバッグする方法#

ステップ1: ステータスコードを特定する#

ステップ2: 意味を理解する#

ステップ3: レスポンスボディとヘッダーを確認する#

ステップ4: コードクラスに応じた対応を取る#

実例: 502 Bad Gatewayをデバッグする#

ステータスコードをリアルタイムにモニタリングする

モニタリングすべき理由

何を監視すべきか

Nova Uptimeでステータスコードを監視する#

HTTPステータスコードとSEO#

まとめ:HTTPステータスコード クイックリファレンス#

Monitor Your Website Before It Goes Down

HTTPステータスコードリファレンス表#

まとめ:HTTPステータスコードクイックリファレンス#