HTTPステータスコードの究極ガイド

HTTPステータスコードは、Webサーバーのリクエスト処理の結果を示します。これらは5つのクラスにグループ化され、各クラスは異なる応答カテゴリを表します。これらのコードを理解することは、Web開発者、API設計者、システム管理者、そしてWeb技術を扱うすべての人にとって不可欠です。ステータスコードにより、ブラウザ、モバイルアプリ、他のサーバーなどのクライアントは、リクエストがどうなったか、次にどう進むべきかを理解できます。

HTTPステータスコードの仕組み

クライアントがHTTPリクエストをサーバーに送信すると、サーバーは3桁のステータスコードとそれに続く人間が読める理由フレーズで応答します。ステータスコードの最初の桁は応答のクラスを定義します。残りの2桁は特定の分類役割を持ちませんが、各クラス内で粒度を提供します。ステータスコードは、RFC文書で公開された仕様に基づいてInternet Assigned Numbers Authority（IANA）によって定義されています。2025年現在、70以上の公式に登録されたHTTPステータスコードがありますが、一般的に使用されているのは約30〜40です。

クイックリファレンス

1xx - 情報

これらのコードは、サーバーがリクエストヘッダーを受信し、クライアントが本文の送信を続行すべきこと、またはサーバーが別のプロトコルに切り替えていることを示します。これらは実際の本文コンテンツのない暫定応答です。

100 Continueステータスは、Expect: 100-continueリクエストヘッダーと組み合わせてよく使用されます。クライアントがこのヘッダーを送信すると、大きなペイロードを送信する前に確認を待ちます。これにより、サーバーがヘッダーだけでリクエストを拒否する場合の帯域幅の無駄を防ぎます。

101 Switching ProtocolsはWebSocket接続の基盤です。クライアントがUpgrade: websocketヘッダーを送信すると、サーバーは101で応答してHTTPからWebSocketへのプロトコル切り替えを確認し、リアルタイム双方向通信を可能にします。

103 Early Hintsは比較的新しい追加（RFC 8297）であり、サーバーが最終応答に必要となる重要なリソース（CSS、JavaScript、フォント）に関するヒントをブラウザに送信できます。これにより、完全な応答が準備できる前にブラウザがこれらのリソースのプリロードを開始でき、認識されるパフォーマンスが向上します。

2xx - 成功

これらのコードは、クライアントのリクエストが正常に受信、理解、受理されたことを示します。すべての開発者が見たいと思うカテゴリです。

200 OKは最も一般的なステータスコードです。リクエストが成功し、応答本文に要求されたデータが含まれていることを示します。GETリクエストの場合、本文にはリソース表現が含まれます。POSTリクエストの場合、アクションの結果が含まれます。

201 Createdは、POSTまたはPUTリクエストの結果として新しいリソースが作成された場合に返すべきです。応答には、新しく作成されたリソースのURLを指すLocationヘッダーを含めるべきです。例えば、新しいユーザーを作成した後、ユーザーのプロフィールURLをLocationヘッダーに含めて201 Createdを返します。

204 No Contentは、応答本文が空のDELETEリクエストやPUT更新に便利です。操作が成功したが返すものがないことをクライアントに伝えます。ブラウザは現在のドキュメントビューを変更すべきではありません。

3xx - リダイレクト

これらのコードは、クライアントがリクエストを完了するために追加のアクションを取る必要があること、通常は別のURLへのリダイレクトに従うことを示します。

301と302の区別はSEOにとって重要です。検索エンジンは301リダイレクトを恒久的なものとして扱い、元のURLのランキングパワーを新しいURLに転送します。302リダイレクトは元のURLが戻ることが期待されるため、SEO値を転送しません。

304 Not Modifiedは、If-Modified-SinceやIf-None-Match（ETags）などの条件付きリクエストヘッダーと組み合わせて使用されます。クライアントがリソースのキャッシュバージョンを持っている場合、サーバーにリソースが変更されたかどうかを尋ねることができます。変更されていない場合、サーバーは本文なしで304を返し、両側の帯域幅を節約します。

307と308は、302や301がPOSTをGETに変更する可能性があるのとは異なり、元のリクエストで使用されたHTTPメソッドを保持します。この区別は、リクエストメソッドの保持が重要なAPIエンドポイントにとって重要です。

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

これらのコードは、クライアントが問題のあるリクエストを送信したことを示します。エラーはクライアント側にあります。サーバーは正しく動作しています。

400 Bad Requestはクライアントエラーのキャッチオールです。不正な構文、無効なクエリパラメータ、不正なリクエスト本文などによりサーバーがリクエストを処理できない場合に使用します。クライアントが問題を修正できるよう、常に応答本文に説明的なエラーメッセージを含めてください。

401 Unauthorizedは、クライアントが有効な認証資格情報を提供していない場合に返されます。応答には、サーバーが期待する認証方式（Basic、Bearer、Digestなど）を示すWWW-Authenticateヘッダーを含めるべきです。

403 Forbiddenは401とは異なり、クライアントは認証済みですが十分な権限を持っていません。例えば、通常のユーザーが管理エンドポイントにアクセスしようとした場合、401ではなく403を返すべきです。

404 Not Foundは最もよく知られているHTTPステータスコードです。サーバーが要求されたリソースを見つけられないことを示します。リソースが存在するが隠されているかどうかを明らかにしないように注意してください。存在しないリソースと forbidden リソースの両方に404を返すことは一般的なセキュリティ慣行です。

409 Conflictは、バージョンの競合がある場合にREST APIに便利です。例えば、PUTリクエストが、クライアントが最後にフェッチしてから別のユーザーによって変更されたリソースを更新しようとする場合です。

429 Too Many RequestsはAPIのレート制限に不可欠です。クライアントが次のリクエストを行うまで待つべき時間を示すRetry-Afterヘッダーを含めるべきです。

5xx - サーバーエラー

これらのコードは、サーバーが有効なリクエストの処理中にエラーが発生したことを示します。問題はサーバー側にあります。

500 Internal Server Errorはサーバー側の障害のキャッチオールです。無効なクライアントリクエストに対して返すべきではありません — それらには4xxコードを使用します。500応答は、サーバーの処理ロジックで何かが間違っていたことを示します。

502 Bad Gatewayは通常、プロキシまたはロードバランサーが上流サーバーから無効な応答を受信したときに発生します。例えば、アプリケーションサーバーがクラッシュしたり不正な応答を返したりすると、リバースプロキシはクライアントに502を返します。

503 Service Unavailableは、サーバーが一時的に過負荷またはメンテナンスのためにダウンしている場合に使用します。クライアントとクローラーがいつ再試行すべきかを知ることができるよう、Retry-Afterヘッダーを含めてください。これはデプロイメントウィンドウやトラフィックスパイク時に一般的に見られます。

504 Gateway Timeoutは、チェーン内の1つのサーバー（例：リバースプロキシがアプリケーションサーバーと通信している）が別のサーバーからタイムリーな応答を受信しない場合に発生します。デフォルトのタイムアウトは通常、インフラストラクチャに応じて30〜120秒です。

ステータスコード使用ガイド

HTTPステータスコード使用のベストプラクティス

状況に最も適した具体的なステータスコードを常に使用してください。503や504の方が適切な場合に汎用的な500エラーを返すと、APIコンシューマーのデバッグが困難になります。応答本文に説明的なエラーメッセージと一意のエラー識別子を含めてデバッグに役立ててください。REST APIの場合は、クライアントがプログラムで処理できる機械可読なエラーコードも含めることを検討してください。最後に、コンテンツネゴシエーションを通じて要求されたコンテンツタイプをエラー応答が尊重することを確認してください。APIクライアントにはJSONを、ブラウザベースのエラーページにはHTMLを返します。

HTTPステータスコードの意味や適切な使用法を思い出す必要がある場合は、HTTPステータスコードリファレンスツールをクイックルックアップに使用してください。