HTTPステータスコードの基礎 — 保守ツールが監視で使う 200/301/403/500 の意味

WordPressサイトの保守作業では、「更新後にサイトが正常に表示されているか」を機械的に判定する場面が頻繁にある。人間が目で見て「大丈夫そうだ」と判断する代わりに使われるのが、Webサーバーがリクエストに対して返すHTTPステータスコードである。3桁の数字ひとつに、実は多くの情報が詰め込まれている。

補足: HTTPステータスコードは、Webサーバーがクライアント（ブラウザやプログラム）からのリクエストに応答する際、先頭に必ず付ける3桁の数字。200 OK のように、数字とその意味を表す短い文言がセットで返される。

先頭の数字が「大分類」を表す

ステータスコードは100の位で意味の大分類が決まっている。

範囲	分類	意味
1xx	情報	リクエストを受け取り処理を継続中（実務で意識する機会は少ない）
2xx	成功	リクエストが正常に処理された
3xx	リダイレクト	別の場所への案内が必要
4xx	クライアントエラー	リクエスト側（アクセスした側）に問題がある
5xx	サーバーエラー	サーバー側の処理が失敗した

この大分類だけでも、「200番台なら基本的に無視してよい」「500番台は必ず調査する」という一次判定ができる。保守ツールの自動監視も、まずはこの大分類で機械的にふるいにかけるところから始まる。

よく出会う個別コードの意味

大分類の中でも、保守作業で特に頻繁に目にするコードには個別の意味がある。

200 OK — リクエストが成功し、正常なコンテンツが返された。最も基本的な「正常」の状態
301 Moved Permanently — リクエストされたURLが恒久的に別のURLへ移動したことを示す。ブラウザはこれを受け取ると自動的に新しいURLへ再アクセスする。WordPressでは http→https への統一や、URL構造の変更時に使われる
403 Forbidden — サーバーはリクエストを理解したが、アクセス権限がないため拒否した。ログイン画面ではなく「見せない」という明確な意思表示。IP制限やBasic認証で保護されたサイトへの想定外アクセスなどで返る
404 Not Found — 該当するページが存在しない。記事のURLを変更した後に古いリンクへアクセスしたときなどに典型的に発生する
500 Internal Server Error — サーバー内部で処理中に予期しないエラーが起きた。PHPのFatal Error（構文エラー・存在しない関数の呼び出し・メモリ不足など）がこの形で表面化することが多く、WordPress保守で最も警戒すべきコードの一つ

これらの数字はRFC（Request for Comments、インターネット技術の標準仕様書）で定義された共通言語であり、どのサーバーソフトウェア・どのプログラミング言語で書かれたシステムであっても同じ意味で解釈される。

「0」という第6のステータス

実務上のステータス判定では、上記の1xx〜5xxに加えて「0」という特別な値を扱う場面がある。これはHTTPの仕様に定義された値ではなく、サーバーからそもそも応答が返ってこなかったことを表す、監視プログラム側の便宜的な表現である。DNS解決の失敗・接続タイムアウト・SSL証明書エラーなど、リクエストがサーバーに届く前の段階で失敗したケースがこれに当たる。

サーバーが「500です」と答えるのと、そもそも応答がなく沈黙するのとでは、原因の切り分けが大きく異なる。この2つを明確に区別しておくことは、監視の設計上重要な意味を持つ。

実例 — 更新前後の比較でロールバックを判断する仕組み

このアプリでは、WordPress本体・プラグインを1件ずつ更新するたびに、更新直後のHTTPステータスを取得して「悪化したかどうか」を判定し、悪化していればその更新だけをピンポイントでロールバックする設計を採っている。判定を担うのが maintenance_agent.py の _should_rollback() という関数で、ロジックは次のように単純化できる。

def _should_rollback(post_status, prev_status):
    post = int(post_status)
    prev = int(prev_status) if prev_status is not None else 200

    # サーバーレベル障害は常時発火
    if post >= 500 or post == 0:
        return True
    # 4xx 退行: 直前が 2xx/3xx だったときだけ発火
    if 400 <= post < 500 and prev < 400:
        return True
    return False

ここで先ほどの分類がそのまま判断基準になっている。

500番台または0（応答なし）は、直前の状態に関係なく常にロールバック対象とする。これはサーバーレベルの障害であり、更新前の状態がどうであれ明確な悪化と言えるため
400番台は「直前の状態が400番台未満だった場合のみ」ロールバック対象とする。ここが単純な「4xxが出たら即アウト」ではない理由は、保守対象のサイトの中には、意図的にBasic認証（401）やIP制限（403）をかけているステージング環境が含まれるためである。もし単純に「post_statusが4xxならロールバック」という判定にしてしまうと、更新前から401を返している認証保護サイトは、更新後も変わらず401を返しているだけなのに毎回誤ってロールバックが発火してしまう。「直前と比べて悪化したか」という差分で判定することで、こうした環境固有の状態を正常なベースラインとして扱える

さらに、この関数に渡す post_status を取得する _http_status_check_stable() という関数では、ステータスが0（応答なし）だったときだけ数秒待って1回だけリトライする仕組みが入っている。一時的な回線の揺れやTLSハンドシェイクの瞬間的な失敗を、サイト停止と誤判定して不要なロールバックを起こさないための配慮である。一方で500番台が返ってきた場合はリトライせず即座に異常と扱う。「応答がない」という不確実な状態と、「明確にエラーだと自己申告している」状態とで、扱いを変えているのがポイントである。

保守ツールにとってのステータスコードの価値

人間が毎回ブラウザでページを開いて目視確認する代わりに、この3桁の数字を機械的に読み取ることで、大量のページ・大量のサイトを一貫した基準でチェックできるようになる。ステータスコードという共通言語のおかげで、更新のたびに「壊れていないか」を人の注意力に頼らず、証跡を残しながら確認できる仕組みが成り立っている。

まとめ

コード	意味	保守での典型的な扱い
2xx	成功	正常。基本的に無視してよい
3xx	リダイレクト	意図した移動か確認
4xx	クライアントエラー	直前の状態と比較して悪化していないか確認
5xx	サーバーエラー	常に異常。優先的に調査・ロールバック対象
0（拡張表現）	応答なし	接続段階の失敗。リトライで一時的な揺れと切り分ける

3桁の数字の裏にある大分類と、その数字を「今回だけ」でなく「直前と比べてどう変わったか」という差分で読む視点があると、監視の設計は一段と正確になる。