【入門編】HTTPステータスコードの分類(1xx-5xx) – HTTPプロトコル・通信規格実践ガイド

はい、承知いたしました。HTTPステータスコードについて、インフラやネットワークに初めて触れるエンジニアや初学者の方にも分かりやすく、親しみやすいブログ記事として執筆します。パケットの旅や身近な例えを交えながら、HTTPの基本からステータスコードの役割までを丁寧に紐解いていきましょう。

—

HTTPステータスコード、君は誰だ？～郵便配達員が教える、Webの「合図」～

みなさん、こんにちは！Webの世界の裏側、パケットが駆け巡るネットワークの深淵へようこそ。今日は、Webサイトを見るとき、あるいはAPIを叩くとき、必ずと言っていいほど目にする「HTTPステータスコード」という、ちょっと不思議な3桁の数字について、じっくりと紐解いていきたいと思います。

「1xx？ 2xx？ 404 Not Foundは知ってるけど、他は？」

そんな風に思っていませんか？大丈夫、大丈夫。今日は難しい専門用語はなるべく避けて、まるで郵便配達員さんが手紙を届けるように、Webのやり取りをイメージしながら、このステータスコードが一体何を意味しているのか、一緒に見ていきましょう。インフラやネットワークの世界に足を踏み入れたばかりのあなたにも、きっと「なるほど！」と思っていただけるはずです。

Webの「郵便配達」を想像してみよう

まずは、Webの通信って、どんな風に行われているのか、身近な「郵便配達」に例えてみましょう。

1. あなた（クライアント）: Webサイトを見たい、という「リクエスト（注文）」を出します。これは、あなたが「〇〇さんの住所にある、あの本が欲しい！」と配達員さんにお願いするようなもの。
2. Webサーバー: そのリクエストを受け取って、「はい、承知しました。今からお持ちしますね！」とか、「あいにく、その本は品切れでして…」といった「レスポンス（返事）」を返します。
3. 配達員さん（HTTPプロトコル）: あなたとWebサーバーの間を行き来する、まさに「通信のルール」そのもの。この配達員さんが、リクエストやレスポンスという「手紙」を正確に届けてくれるんです。

さて、この「レスポンス（返事）」の中に、必ず付いてくるのが、今日のお話の主役、「HTTPステータスコード」なんです。これは、配達員さんが「お届け物」を届けるときに、どんな状況だったのかを伝える「伝票番号」や「配達状況のサイン」みたいなものだと思ってください。

この3桁の数字を見るだけで、Webサーバーがあなたのリクエストに対して、どんな状況だったのかが、一目でわかるようになっているんです。

ステータスコードは「5つのクラス」に分けられる

このステータスコード、実は全部で100種類以上あるのですが、最初の1桁で大きく5つのグループ（クラス）に分けられています。まるで、郵便局が配達状況を「配達中」「配達完了」「不在」「宛先不明」みたいに分類しているのと同じですね。

では、その5つのクラスを、配達員さんの口調で見ていきましょう！

1xx: 「ちょっと待ってくださいね、確認中です！」（情報 – Informational）

このクラスは、まだリクエストの処理が完了していないけど、「ちゃんと受け取りましたよ！」「今、〇〇の準備をしてますよ！」といった、途中経過を伝えるためのコードです。HTTP/1.1より前のHTTP/0.9やHTTP/1.0ではあまり使われず、HTTP/1.1以降で導入されました。

`100 Continue`:
配達員さんの言葉: 「お荷物、受け取りました！もし大きなお荷物でしたら、その前に『本当に送って大丈夫？』って確認させてもらいますね。とりあえず、『OK、送っていいよ』っていう合図です！」
解説: クライアント（あなた）が大きなデータを送ろうとしたときに、サーバーに「このデータ、送っても大丈夫？」と事前に聞くことがあります。その際に、サーバーから「うん、大丈夫だよ。そのまま送ってきて！」と返ってくるのがこのコードです。
実務で見る？: ちょっとマニアックですが、大きなファイルをアップロードする際などに、通信の効率化のために使われることがあります。

2xx: 「はい、バッチリ成功しました！」（成功 – Success）

これは、あなたが「これ、やって！」とお願いしたことが、サーバー側で無事に完了したことを示す、とっても嬉しいコードです！

`200 OK`:
配達員さんの言葉: 「お待たせしました！ご依頼の品、無事にお届けしました！こちらがその中身です！」
解説: これが一番よく見る成功のサインです。Webページを表示してほしい、というリクエストに対して、サーバーがそのページのデータをちゃんと送ってくれた、という状態です。APIリクエストが成功して、データが返ってきたときもこれです。
実務で見る？: ほぼ全てのWebサイト表示やAPI通信で、成功時に表示されます。

`201 Created`:
配達員さんの言葉: 「ご依頼の品、『〇〇さん（新しいデータ）』、無事にお作り（作成）して、お届けしました！こちらがその情報です。」
解説: 新しいデータ（例えば、新しいユーザーアカウントや投稿記事）をサーバーに作成してもらったときに返されるコードです。作成されたデータの情報（URLなど）が一緒に送られてくることが多いです。
実務で見る？: Web APIで、何か新しいリソースを作成するPOSTリクエストが成功したときなどによく使われます。

// 例：APIで新しいユーザーを作成し、成功した場合のレスポンス
// レスポンスステータス: HTTP/1.1 201 Created
{
“message”: “ユーザーが正常に作成されました。”,
“user_id”: “user12345”, // 作成されたユーザーのID
“location”: “/users/user12345” // 作成されたリソースのURL
}

`204 No Content`:
配達員さんの言葉: 「ご依頼の件、承知いたしました！特に何もお渡しするものはありませんが、作業は完了しました！」
解説: リクエストは成功したけれど、返信するデータ（コンテンツ）は何もありません、という状態です。例えば、設定を変更するAPIリクエストが成功して、特に返信データが不要な場合などに使われます。
実務で見る？: APIで、データを更新（PUT/PATCH）したり、削除（DELETE）したりした際に、成功したが返答データがない場合に利用されます。

// 例：APIで設定を更新し、成功したが返信データがない場合
// レスポンスステータス: HTTP/1.1 204 No Content
// レスポンスボディは空っぽ

3xx: 「あちらに移動しましたよ！」（リダイレクト – Redirection）

このクラスは、あなたがお願いしたものが、「今はここにはないけど、代わりにこっちに行ってくださいね」と、別の場所やURLを教えてくれるコードです。

`301 Moved Permanently`:
配達員さんの言葉: 「おや？ご指定の住所は、もう古いようです。これからは、こちらの新しい住所（URL）に、ずっと移転しましたので、そちらへお越しください！」
解説: 以前のURLにあったコンテンツが、恒久的に別のURLに移動したことを示します。ブラウザは自動的に新しいURLへアクセスし直してくれるので、ユーザーは気づかないことも多いです。SEO（検索エンジン最適化）の観点でも重要です。
実務で見る？: WebサイトのURLを変更したとき（例: `http://example.com` → `https://example.com`）、またはドメイン名を変更したときなどに使われます。

// 例：古いURLへのリクエストに対するレスポンス
// レスポンスステータス: HTTP/1.1 301 Moved Permanently
Location: https://example.com // 新しいURLはこちらですよ！

`302 Found` (または `307 Temporary Redirect`)
配達員さんの言葉: 「あいにく、ご指定の場所は一時的に工事中です。別の場所（URL）で、一時的に対応していますので、そちらをご利用ください。また元に戻るかもしれません。」
解説: こちらは一時的な移動を示します。例えば、メンテナンス中のページへ一時的に誘導したり、特定のキャンペーンページへ一時的に飛ばしたりする場合に使われます。
実務で見る？: Webサイトのメンテナンス時や、一時的なURLの変更、A/Bテストなどで使われることがあります。`307`は、HTTPメソッド（GET, POSTなど）をそのまま引き継ぐことを明確にするために使われます。

// 例：一時的に別のURLへ誘導する場合
// レスポンスステータス: HTTP/1.1 302 Found
Location: /temporary-maintenance.html // 一時的なページはこちら

4xx: 「あれ？ちょっと、おかしいですよ！」（クライアントエラー – Client Error）

このクラスは、「あなた（クライアント）からのリクエストに、何か問題があるようです」と、サーバーが教えてくれるコードです。つまり、あなたの「お願い」の仕方に間違いがある、ということです。

`400 Bad Request`:
配達員さんの言葉: 「すみません、この荷物（リクエスト）は、宛先がめちゃくちゃだったり、送り方がルール違反だったりで、受け取れませんでした。もう一度、ちゃんと確認して送ってください。」
解説: リクエストの構文が間違っていたり、不正なパラメータが含まれていたりするなど、サーバーが理解できないほどひどいリクエストだった場合に返されます。
実務で見る？: APIリクエストで、必須のパラメータが抜けていたり、不正な形式で送信されたりした場合などに発生します。

// 例：APIリクエストで、必須の「name」パラメータが抜けていた場合
// レスポンスステータス: HTTP/1.1 400 Bad Request
{
“error”: “Bad Request”,
“message”: “必須パラメータ ‘name’ が見つかりません。”
}

`401 Unauthorized`:
配達員さんの言葉: 「このお荷物、中身を確認するために『身分証明書』が必要です。でも、あなたが提示したものじゃ、確認できませんでした。」
解説: リクエストされたリソースにアクセスするために、認証（本人確認）が必要なのに、それが提供されなかった、または無効だった場合に返されます。ログインが必要なページに、ログインせずにアクセスしようとしたときなどです。
実務で見る？: ログインが必要なAPIエンドポイントに、APIキーやトークンを渡さずにアクセスした場合などに発生します。

// 例：認証が必要なAPIへのアクセス
// レスポンスステータス: HTTP/1.1 401 Unauthorized
WWW-Authenticate: Basic realm=”Restricted Area” // どのような認証が必要かを示す

`403 Forbidden`:
配達員さんの言葉: 「あなた（クライアント）は、このお荷物（リクエスト）を受け取る権限がありません。たとえ身分証明書が正しくても、あなたには渡せません。」
解説: 認証は成功した（あるいは必要ない）けれど、そのリソースにアクセスする権限がない場合に返されます。例えば、一般ユーザーが管理者ページにアクセスしようとした場合などです。`401`とは違い、認証しても無駄なケースです。
実務で見る？: ファイルのパーミッション設定が原因で、Webサーバーがそのファイルを提供できない場合や、特定のユーザーグループしかアクセスできないリソースへのアクセス試行時などに発生します。

`404 Not Found`:
配達員さんの言葉: 「すみません、ご指定の住所（URL）には、そのお荷物（リソース）は見当たりませんでした。もしかしたら、もう存在しないか、住所が間違っているかもしれません。」
解説: これは皆さん、一番よく知っているかもしれませんね！リクエストされたURLに、該当するリソース（Webページやファイル）が存在しない場合に返されます。
実務で見る？: 存在しないWebページへのリンクをクリックしたとき、URLを間違って入力したとき、APIで存在しないIDを指定したときなどに表示されます。

// 例：存在しないページへのアクセス
// レスポンスステータス: HTTP/1.1 404 Not Found

5xx: 「うわぁ、ごめんなさい！サーバー側で問題が起きた！」（サーバーエラー – Server Error）

このクラスは、「あなた（クライアント）からのリクエストは正しかったのに、サーバー側で何か予期せぬ問題が発生して、処理できませんでした」という、サーバー側の悲鳴のようなコードです。

`500 Internal Server Error`:
配達員さんの言葉: 「大変申し訳ございません！こちらの配達員（サーバー）の内部で、予期せぬトラブルが発生してしまい、ご依頼の品を処理できませんでした。原因を調査しますので、少々お待ちください…」
解説: Webサーバー自身に何らかの予期せぬエラーが発生した場合に返される、いわば「汎用的なサーバーエラー」です。コードのバグ、設定ミス、データベースへの接続失敗など、原因は多岐にわたります。
実務で見る？: Webサイトが突然表示されなくなったり、APIがエラーを返したりする原因として、最もよく目にするエラーの一つです。

// 例：サーバー側で予期せぬエラーが発生した場合
// レスポンスステータス: HTTP/1.1 500 Internal Server Error

`503 Service Unavailable`:
配達員さんの言葉: 「大変申し訳ございません！ただいま、配達員（サーバー）がメンテナンス中であったり、あまりにも多くの注文が殺到して、一時的に対応できません。しばらく経ってから、もう一度お試しください。」
解説: サーバーが一時的にリクエストを処理できる状態にない場合に返されます。これは、メンテナンス中であったり、サーバーの負荷が高すぎたりする場合によく使われます。
実務で見る？: 大規模なイベントでWebサイトへのアクセスが集中したときや、定期メンテナンス中に表示されることがあります。

// 例：サーバーが一時的に利用できない場合
// レスポンスステータス: HTTP/1.1 503 Service Unavailable
Retry-After: 3600 // 例: 1時間後に再度試してください、といった指示

まとめ：ステータスコードはWebの「共通言語」

さて、いかがでしたでしょうか？ HTTPステータスコードは、Webサーバーとクライアント（ブラウザやアプリ）が、お互いの状況を正確に伝えるための、とっても大切な「共通言語」なんです。

1xx: 「確認中だよ！」
2xx: 「成功したよ！」
3xx: 「あっちに行ってね！」
4xx: 「君のリクエストがおかしいよ！」
5xx: 「ごめん、サーバー側で問題が…」

これらのコードを理解することは、Webサイトのデバッグや、API連携のトラブルシューティングにおいて、原因を特定する強力な手がかりとなります。

例えば、

「ページが表示されない…」 → まずは200 OKになっているか、それとも4xxや5xxが出ていないか確認！
「APIからデータが返ってこない…」 → 401 Unauthorizedなら認証情報を、403 Forbiddenなら権限を、400 Bad Requestならリクエストパラメータを見直す！
「サイトが遅い、たまに繋がらない…」 → 503 Service Unavailableが出ていないか、サーバーの負荷状況を確認！

このように、ステータスコードは、Webの裏側で何が起こっているのかを読み解くための、まさに「地図」であり「羅針盤」なのです。

今日から、Webサイトを見たり、APIを叩いたりするたびに、ふとこのステータスコードを意識してみてください。きっと、Webの世界がもっとクリアに見えてくるはずですよ！

それでは、また次回の通信でお会いしましょう！

—