LASSIC Media らしくメディア

導入：HTTPステータスコードとは

Webサイトを開いたりアプリからAPIを呼び出したりするたびに、ブラウザやアプリはサーバへリクエストを送り、サーバはその結果を返しています。このとき、結果の種類を人にもプログラムにも分かる形で伝えるために使われているのが、3桁の数字で構成されたHTTPステータスコードです。

本記事で扱うのは、Cookieやセッションのような「状態を保持する仕組み」ではなく、サーバが1回のリクエストに対して返す結果そのものを表す番号です。似た文脈で語られることの多いCookie・セッション（状態管理の仕組み）とは別の話として、まずは番号の意味を切り分けて理解しておくことが役立ちます。

ステータスコードは、リクエストが成功したのか失敗したのか、失敗したとしてもどのような種類の失敗なのかを、決まった番号の範囲で示す共通の合図です。200番台なら成功、400番台や500番台ならエラーというように、先頭の数字を見るだけである程度の状況をつかめる点が特徴でしょう。

普段は意識しないことも多いこの番号ですが、次のような場面では避けて通れないものです。

• Webサイトが正しく表示されない、あるいはページが見つからないという不具合の調査
• APIを呼び出した際に、成功・失敗をプログラムで判定する処理の実装
• サーバのログや監視画面で、障害の傾向をつかむための集計

ステータスコードの意味を押さえておくと、トラブルが起きたときにどこに原因がありそうかを大まかに見当づけられます。開発を発注する側であっても、報告や仕様のやり取りの中でこの番号が出てくる場面は少なくないでしょう。

ステータスコードは、ブラウザの画面上には直接表示されないことがほとんどです。普段利用しているサイトが問題なく開けているときは、裏側で200という番号が返っていることを意識する機会はまずありません。一方で、ページが表示されない、エラー画面が出る、アプリの操作が反映されないといった不具合が起きたときには、この番号が状況を読み解く手がかりになります。開発者ツールやサーバのログを確認すれば、実際にどの番号が返されていたかを追うことができるものです。以降では、番号の分類から代表的なコードの意味、実務での関わり方まで順に整理していきます。

番号の5分類

HTTPステータスコードは3桁の数字で表され、先頭の数字によって大きく5つのグループに分けられています。下2桁の細かい意味を覚えていなくても、先頭の数字を見るだけでおおまかな性質が分かるようになっているものです。

1xxは実務で目にする機会が比較的少ない分類です。処理の途中経過を知らせる位置づけのため、ブラウザやアプリの画面上で意識することはあまりないでしょう。一方で2xxから5xxまでの4つは、日々の開発や運用の中で頻繁に登場します。

ここで重要なのは、4xxと5xxがどちらも「エラー」を表す点は共通していても、原因の所在が異なるという点です。4xxはリクエストを送った側に見直すべき点があり、5xxはリクエストを受けたサーバ側に原因があるという違いになります。この切り分けについては、後の章であらためて取り上げます。

3xxのリダイレクトも、実務では見落とされがちな分類です。ページのURLを変更した際に301や302を適切に設定していないと、利用者が古いURLのままアクセスし続けてしまったり、検索エンジンが新旧どちらのURLを評価すべきか判断しにくくなったりすることがあります。エラーではないため見過ごされやすいものの、サイトの構成を変更する際には意識しておきたい分類でしょう。

また、番号の下2桁にも一定の傾向があります。200・400・500のように下2桁がゼロに近いコードは、それぞれの分類の中でも基本的な意味を持つ位置づけであることが多く、それ以外の番号はより具体的な状況を細分化して表す形になっています。すべての番号を暗記する必要はなく、まずは先頭の数字で大枠をつかみ、必要に応じて代表的な番号の意味を調べるという向き合い方で実務には対応しやすいでしょう。

代表的なコードとその意味

すべての番号を覚える必要はありませんが、実務でよく登場する代表的なコードについては、意味と疑うべきポイントをセットで押さえておくと役立ちます。

表の中でも401と403は混同されやすい組み合わせです。401は「誰なのかを確認できていない」状態、403は「誰であるかは分かったうえで、その先に進む権限が無い」状態を指します。なお、認証・認可の仕組みそのものやセッションの管理方法については本記事の主題ではないため、ここでは意味の違いに触れるにとどめます。

502・503・504は、いずれもサーバ側の問題を示す点で共通していますが、原因の性質は少しずつ異なるものです。502は中継先からの応答が不正な形式だったことを示し、503はサーバが一時的に処理を受け付けられない状態、504は依存先からの応答が時間内に返ってこなかったことを表します。障害報告を受け取る際は、どのコードが出ていたかによって疑う先を変える必要があるでしょう。

429も近年よく見かけるコードの一つです。外部のAPIを呼び出す構成が増えるにつれて、短時間に大量のリクエストを送った際の上限超過を示す429に遭遇する場面が増えてきました。エラーというよりは、呼び出し側に一定の間隔を空けて再送するよう促す性質の応答であり、一律にエラー扱いとして処理を止めるのではなく、時間を置いて再試行する設計が組み込まれているかどうかが実務上のポイントになります。

200番台の中にも、201（Created）や204（No Content）のように、200とは少し異なる意味を持つコードがあります。201は新しいリソースが作成されたことを示し、204は処理は成功したものの返す本文が無いことを示すものです。API設計の細部にこだわる場合は、こうした200番台の使い分けも意識する余地があるでしょう。

4xxと5xxの違いが重要な理由

4xxと5xxはどちらもエラーを示す番号ですが、原因の所在という点で大きく性質が異なります。4xxはリクエストを送った側、つまりURLの指定ミス・権限不足・認証切れといったクライアント側の問題を表すものです。一方の5xxは、リクエスト自体は妥当であったにもかかわらず、サーバ側のバグや過負荷、依存しているサービスの障害といった、サーバ側の問題によって発生します。

この違いが重要なのは、障害調査の第一歩となる切り分けに直結するためです。4xxが大量に発生している場合は、リンク切れや仕様変更に伴うURLの不整合、あるいは認証まわりの設定を見直す方向で調査が進みます。反対に5xxが増えている場合は、アプリケーションのコードやインフラ、外部サービスとの連携部分を疑うことになるでしょう。原因の所在を誤って調査を始めると、対応が的外れになり時間を浪費してしまいます。

もう少し具体的に見てみましょう。あるページで404が急増したとします。この場合、まず疑うのはリンク先のURLが変更されたか削除されたかという、クライアント側から見たリクエスト内容の不整合です。サーバのプログラム自体に手を加えなくても、リダイレクト設定やリンクの修正だけで解消することが少なくありません。一方、あるAPIで500が急増した場合は、リクエストの内容そのものは正しいにもかかわらずサーバ側の処理で例外が発生している可能性が高く、アプリケーションのコードやデータベースとの接続、依存しているサービスの状態を確認する必要が出てきます。

この責任分界を曖昧にしたまま対応を進めると、クライアント側の問題であるにもかかわらずサーバの改修に着手してしまったり、逆にサーバ側の不具合を利用者の操作ミスと片づけてしまったりする恐れがあります。ステータスコードを最初に確認する習慣が定着していれば、こうした的外れな対応を防ぎ、原因調査にかかる時間を短縮しやすくなるでしょう。特に、社外のパートナーやベンダーと連携して開発・運用を進めている場合、4xxか5xxかという最初の切り分けは、どちらの担当範囲に一次対応を依頼すべきかを判断する材料にもなります。

下の図は、クライアントからのリクエストがサーバに届いてから、結果として2xx・3xx・4xx・5xxのいずれかに分類されるまでの流れと、4xxと5xxで責任の所在が分かれる様子を示したものです。

実務での関わり

HTTPステータスコードは、実務のさまざまな場面で関わってくる基礎知識です。代表的な関わり方を整理すると、次のようになります。

• 監視・ログの集計：サーバのアクセスログや監視ツールでステータスコードを集計すると、4xxと5xxそれぞれの発生比率や推移から、障害の傾向をつかみやすくなります。特定のURLで404が増えている、あるいは特定の時間帯に503が集中しているといった傾向は、原因調査の手がかりになるものです。
• API設計：APIを設計する際は、処理結果に応じて適切なコードを返す設計が欠かせません。すべてを200で返してしまうと、呼び出す側のプログラムが成功と失敗を区別できず、エラー処理が正しく機能しなくなる恐れがあるでしょう。
• SEOへの影響：検索エンジンとの関係でも、ステータスコードは意味を持ちます。ページを恒久的に移転する際に301を正しく返さなかったり、実際には存在しないページを200で返す、いわゆるsoft404の状態になっていたりすると、検索エンジンからの評価に影響が及ぶことがあるものです。

コードレビューや発注後の検収の場面では、次のような観点を確認しておくと、後々のトラブルを減らしやすくなります。

• エラーが発生した際に、状況に応じた適切なステータスコードを返しているか
• エラーメッセージが、原因を推測できる程度に具体的な内容になっているか
• すべてのレスポンスを200で返すなど、コードの使い分けを省略していないか
• 移転したページに対して、301など適切なコードでリダイレクトが設定されているか

ステータスコードの使い分けは、開発が終わった後の運用フェーズになって初めて重要性に気づかれることも少なくありません。監視の仕組みを整える段階から、どのコードをどう扱うかをあらかじめ決めておくことが、後の障害対応をスムーズにする土台になるでしょう。

監視の仕組みという観点では、単に「エラーが何件出たか」を数えるだけでなく、4xxと5xxを分けて集計しておくことが役立ちます。両者を合算した「エラー件数」だけを見ていると、クライアント側の一時的な操作ミスが増えているだけなのか、サーバ側で障害が起きているのかを区別できず、対応の優先度を誤ってしまう可能性があるためです。ダッシュボードやアラートの設計段階で、4xxと5xxを別々の指標として扱うようにしておくと、異常の兆候に早く気づきやすくなるでしょう。

外部のパートナーに開発や運用を委託している場合は、ステータスコードの扱いを仕様として明文化しておくことも一つの方法です。例えば「入力値が不正な場合は400を返し、エラーメッセージに不正な項目名を含める」といった具体的な取り決めがあれば、担当者が変わってもエラーハンドリングの品質にばらつきが出にくくなります。反対に、こうした取り決めが無いまま開発が進むと、担当者ごとにエラーの返し方が異なってしまい、後から利用する側が挙動の予測を立てにくいシステムになりがちです。

まとめ

HTTPステータスコードは、サーバがリクエストの結果を3桁の番号で示す共通の合図です。先頭の数字によって1xxから5xxまでの5分類に整理されており、なかでも4xxはクライアント側、5xxはサーバ側に原因があるという違いは、障害調査の第一歩として押さえておく価値があります。

200や404、500といった代表的なコードの意味を知っておくことは、開発だけでなく、監視・API設計・SEOといった実務の各所で役立つものです。番号の意味を正しく理解し、状況に応じた適切なコードを返す設計になっているかを確認することが、安定した運用につながっていくでしょう。

相談するメリット

「エラー発生時にどのステータスコードを返すべきか設計を見直したい」「監視ログを集計しているが、障害の傾向をうまく把握できていない」といったお悩みがあれば、LASSICにご相談ください。

LASSICでは、ニアショア開発体制を活かし、API設計におけるエラーハンドリングの整備や、監視・ログ集計の仕組みづくり、障害切り分けの体制構築まで、受託開発の一環として対応しています。既存システムのステータスコードの返し方を棚卸しするところから、あわせてご相談いただけます。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

サービス詳細・お問い合わせはこちら

出典

• MDN Web Docs「HTTP レスポンスステータスコード」
• Wikipedia「HTTPステータスコード」

Tweet