HTTPステータスコード:完全リファレンスガイド

2026年3月31日 · 12分で読めます

HTTPステータスコードとは?

HTTPステータスコードは、クライアントのリクエストに対してサーバーが返す3桁の数字です。リクエストが成功したか、リダイレクトされたか、エラーが発生したかを示します。ブラウザがページを読み込んだり、APIを呼び出したり、フォームを送信したりするたびに、サーバーはステータスコードで応答します。

ステータスコードは、サーバーがリクエストに何が起こったかを伝える方法だと考えてください。信号機が止まるか進むかを教えてくれるように、ステータスコードはアプリケーションに続行するか、再試行するか、エラーを処理するかを伝えます。

ステータスコードは、最初の桁に基づいて5つのカテゴリに分類されます:

• 1xx (情報): リクエストを受信し、処理を続行中
• 2xx (成功): リクエストを受信、理解、受理
• 3xx (リダイレクト): リクエストを完了するためにさらなるアクションが必要
• 4xx (クライアントエラー): リクエストにクライアント側のエラーが含まれている
• 5xx (サーバーエラー): サーバーが有効なリクエストの処理に失敗

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

クライアント(ブラウザやAPIクライアントなど)がHTTPリクエストを行うと、サーバーはそれを処理してレスポンスを返します。このレスポンスには常に最初の行にステータスコードが含まれ、その後にヘッダーとオプションのボディが続きます。

典型的なHTTPレスポンスは次のようになります:

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 1234

{"status": "success", "data": {...}}

ステータスコードはHTTPバージョンの直後に表示されます。この例では、200 OKがリクエストが成功したことをクライアントに伝えています。

ステータスコードは複数の目的を果たします:

• コミュニケーション: サーバーが結果を伝えるための標準化された方法を提供
• エラー処理: アプリケーションがコードに基づいてさまざまなシナリオをプログラム的に処理可能
• デバッグ: 開発者がリクエスト-レスポンスサイクルのどこで問題が発生したかを迅速に特定
• SEO: 検索エンジンがコンテンツのインデックス方法を理解するために使用
• キャッシング: ブラウザとCDNがキャッシング動作を決定するために使用

1xx 情報

情報ステータスコードは、サーバーがリクエストを受信し、処理を続行していることを示します。これらは暫定的なレスポンスであり、日常的なWebブラウジングではほとんど見られませんが、特定のプロトコルと最適化には重要です。

100 Continue

サーバーがリクエストヘッダーを受信し、クライアントはボディの送信を続行する必要があります。これは、クライアントがExpect: 100-continueヘッダーを送信して、完全なペイロードを送信する前にサーバーがリクエストを受け入れるかどうかを確認する大規模なアップロードで使用されます。

この最適化により、拒否されるリクエストに帯域幅を浪費することを防ぎます。たとえば、500MBのビデオファイルをアップロードする場合、認証失敗によりサーバーが拒否することがわかった後に、すべてのデータを送信したくありません。

POST /upload HTTP/1.1
Host: api.example.com
Content-Length: 524288000
Expect: 100-continue

// サーバーは100 Continueで応答
// その後、クライアントはリクエストボディを送信

101 Switching Protocols

サーバーは、クライアントが要求したプロトコルへの切り替えに同意します。Upgrade: websocketヘッダーを使用してHTTPからWebSocketにアップグレードする際に最もよく見られます。

WebSocketは、クライアントとサーバー間のリアルタイムの双方向通信を可能にし、チャットアプリケーション、ライブ更新、コラボレーションツールに不可欠です。

GET /chat HTTP/1.1
Host: example.com
Upgrade: websocket
Connection: Upgrade

// サーバーは101 Switching Protocolsで応答

103 Early Hints

この比較的新しいステータスコードにより、サーバーは最終レスポンスの前に予備ヘッダーを送信できます。サーバーがメインレスポンスを準備している間に、CSS、フォント、JavaScriptファイルなどのリソースのプリロードを開始するためによく使用されます。

Early Hintsは、ブラウザがページ読み込みプロセスの早い段階で重要なリソースのダウンロードを開始できるようにすることで、ページ読み込み時間を大幅に改善できます。

2xx 成功

成功コードは、見たいものです。リクエストが受信、理解、正常に受理されたことを示します。異なる2xxコードは、リクエストがどのように処理されたかについて微妙な情報を提供します。

200 OK

標準的な成功レスポンスです。リクエストが成功し、レスポンスボディに要求されたデータが含まれています。これはWeb上で最も一般的なステータスコードです。

データを返す成功したGETリクエスト、作成されたリソースデータを返す成功したPOSTリクエスト、更新されたリソースデータを返す成功したPUT/PATCHリクエストには200 OKを使用します。

GET /api/users/123 HTTP/1.1

HTTP/1.1 200 OK
Content-Type: application/json

{"id": 123, "name": "John Doe", "email": "[email protected]"}

201 Created

新しいリソースが正常に作成されました。これは、新しいリソースを作成するPOSTリクエストに対する適切なレスポンスです。レスポンスには、新しく作成されたリソースを指すLocationヘッダーを含める必要があります。

POST /api/users HTTP/1.1
Content-Type: application/json

{"name": "Jane Smith", "email": "[email protected]"}

HTTP/1.1 201 Created
Location: /api/users/124
Content-Type: application/json

{"id": 124, "name": "Jane Smith", "email": "[email protected]"}

202 Accepted

リクエストは処理のために受け入れられましたが、処理は完了していません。これは、サーバーが後で処理するためにリクエストをキューに入れる非同期操作に役立ちます。

一般的な使用例には、バッチ処理、メール送信、ビデオエンコーディング、およびHTTPレスポンスをブロックすべきでないその他の長時間実行操作が含まれます。

204 No Content

リクエストは成功しましたが、返すコンテンツがありません。これは、DELETEリクエストや、クライアントが更新されたリソースを返す必要がないPUT/PATCHリクエストで一般的に使用されます。

空のボディを持つ200 OKの代わりに204 No Contentを使用すると、帯域幅が節約され、意図が明確に伝わります。

DELETE /api/users/123 HTTP/1.1

HTTP/1.1 204 No Content

206 Partial Content

クライアントから送信された範囲ヘッダーにより、サーバーはリソースの一部のみを配信しています。これにより、再開可能なダウンロードと、クライアントが特定のバイト範囲を要求するビデオストリーミングが可能になります。

ビデオプレーヤーは、ファイル全体をダウンロードせずにビデオのさまざまな部分へのシークを可能にするために、これを広範囲に使用します。

3xx リダイレクト

リダイレクトコードは、クライアントがリクエストを完了するために追加のアクションを実行する必要があることを示します。これらは、URL管理、SEO、およびリソースが移動したときの下位互換性の維持に不可欠です。

301 Moved Permanently

リソースは、Locationヘッダーで指定された新しいURLに永続的に移動しました。ブラウザと検索エンジンは、新しいURLを使用するようにレコードを更新する必要があります。

これは、永続的なリダイレクトのための定番のステータスコードです。検索エンジンは古いURLから新しいURLにSEO価値を転送し、ブラウザはリダイレクトをキャッシュします。

GET /old-page HTTP/1.1

HTTP/1.1 301 Moved Permanently
Location: https://example.com/new-page

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

リソースは一時的に別のURLにあります。クライアントは、将来のリクエストには元のURLを使用し続ける必要があります。検索エンジンはこのリダイレクトでSEO価値を転送しません。

一般的な使用例には、A/Bテスト、メンテナンスページ、一時的なプロモーションページが含まれます。

303 See Other

リクエストへのレスポンスは、GETを使用して別のURLで見つけることができます。これは、POSTリクエストの後に結果ページにリダイレクトするために一般的に使用され、ユーザーが更新した場合の重複フォーム送信を防ぎます。

これは、WebフォームのベストプラクティスであるPost/Redirect/Getパターンを実装します。

304 Not Modified

リソースは、リクエストヘッダー(If-Modified-SinceまたはIf-None-Match)で指定されたバージョン以降変更されていません。クライアントはキャッシュされたバージョンを使用できます。

これにより、コンテンツが変更されていない場合に不要なデータ転送を回避することで、帯域幅の使用量が大幅に削減され、パフォーマンスが向上します。

307 Temporary Redirect

302に似ていますが、リダイレクト時にリクエストメソッドが変更されないことを保証します。元のリクエストがPOSTの場合、リダイレクトされたリクエストもPOSTになります。

308 Permanent Redirect

301に似ていますが、リクエストメソッドが変更されないことを保証します。これは、厳密なメソッド保持が必要なAPIとアプリケーション向けの、301の最新のより正確なバージョンです。

4xx クライアントエラー

クライアントエラーコードは、リクエストに不正な構文が含まれているか、クライアント側の問題により処理できないことを示します。これらのエラーは、クライアントが再試行する前にリクエストを変更する必要があることを意味します。

400 Bad Request

サーバーは、不正な構文、無効なリクエストメッセージフレーミング、または欺瞞的なリクエストルーティングのため、リクエストを処理できません。これは、他の4xxカテゴリに適合しないリクエストの一般的なエラーです。

一般的な原因には、不正なJSON、必須フィールドの欠落、無効なデータ型、またはAPI制約に違反するリクエストが含まれます。

POST /api/users HTTP/1.1
Content-Type: application/json

{"name": "John", "email": "not-an-email"}

HTTP/1.1 400 Bad Request
Content-Type: application/json

{"error": "Invalid email format"}

401 Unauthorized

認証が必要で、失敗したか、提供されていません。名前にもかかわらず、これは実際には「未認証」を意味します - クライアントは有効な資格情報を提供する必要があります。

レスポンスには、必要な認証方法を示すWWW-Authenticateヘッダーを含める必要があります。

GET /api/protected-resource HTTP/1.1

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="api"

{"error": "Authentication required"}

403 Forbidden

サーバーはリクエストを理解しましたが、承認を拒否します。401とは異なり、認証は役に立ちません - クライアントはこのリソースにアクセスする権限を持っていません。

ユーザーが認証されているが必要な権限を持っていない場合、またはIPアドレス、レート制限、その他のポリシーによってアクセスが制限されている場合に使用します。