【実務・中級編】 HTTPステータスコード 2xx (成功系) の詳細とキャッシュ制御 – ネットワーク基礎とWebセキュリティ実践ガイド

【第15回】「200 OK」だけじゃメシが食えない！実務で差が出るHTTP 2xx系とキャッシュ制御の深層

おい、調子はどうか。今日もどこかの本番環境で、APIのレスポンスタイムやキャッシュの怪しい挙動に頭を抱えていないか？

インフラエンジニアやWebアプリケーション開発者にとって、HTTPのステータスコードは、ネットワークという暗闇の中で点灯する羅針盤だ。特に 2xx という「成功系」のステータスコードは、一見すると「すべてが順調に処理されました」という意味の平和なシグボルに見える。

だが、現場の修羅場をくり抜けてきた我々からすれば、ここにしこたまトラップが仕掛けられていることを知っている。
「なぜかブラウザが古いデータを返し続ける」
「リソースを作ったはずなのに、クライアントが次に何をすべきか迷っている」
「APIの仕様書通りに 201 Created を返しているのに、フロントエンドの fetch が想定外の挙動をする」

こうしたトラブルの原因の多くは、2xx ステータスコードの微細なセマンティクスと、HTTPキャッシュ制御ヘッダー（Cache-Control や ETag）の噛み合わせの悪さにある。

今回は、OSI参照モデルのトランスポート層やTCPの3ウェイハンドシェイクを抜け、アプリケーション層の主役であるHTTPの世界に踏み込み、「2xx系ステータスコードがキャッシュと後続リクエストに与える影響」を、実務の現場目線で徹底的に解剖していこう。

—

1. 2xx系ステータスコードの正しい哲学と、現場を救う使い分け

RFC 9110（HTTP Semantics）において、2xx は「クライアントからのリクエストが正常に受信され、理解され、受け入れられた」ことを示す。しかし、すべての「成功」が同じ意味ではない。API設計やWebフロントエンドの実装において、どのステータスコードを選択するかは、クライアント側のルーティングやキャッシュ戦略に直結する。

代表的な3つの成功ステータスとその実務的意味

200 OK: リクエストは成功し、ペイロードボディ（データ本体）にリソースが含まれている。最も汎用的だが、「デフォルトでキャッシュされやすい」という強烈な副作用を持つ。
201 Created: 新しいリソースの作成に成功した。レスポンスヘッダーの Location に作成されたリソースのURIを含めるのがRFCの作法だ。
204 No Content: リクエストは正常に処理されたが、レスポンスボディに返すデータが「無い」。主に PUT や DELETE、あるいは画面遷移を伴わない非同期の POST（「いいね！」のトグルなど）で真価を発揮する。

なぜステータスコードの選択を誤ると炎上するのか？

例えば、フロントエンドが POST /api/v1/items で新しいアイテムを作成したとする。この時、バックエンドが処理に成功したからといって適当に 200 OK と空のボディを返してしまうと、一部のHTTPクライアントやプロキシサーバーは「このリクエストはキャッシュ可能かもしれない」と誤認するリスクを生む。
さらに、クライアント側のJavaScript（Fetch API など）は、201 や 204 を受け取った際の処理分岐を明確に書くことで、無駄なJSONパースエラーを防ぎ、ネットワーク帯域を節約できるのだ。

—

2. キャッシュの魔力：2xxステータスコードと Cache-Control の相関関係

ブラウザやCDN（CloudflareやFastly、AWS CloudFrontなど）は、ネットワークの往復回数（RTT）を減らし、ユーザー体験を爆速にするためにHTTPキャッシュを活用する。ここで重要なのは、「すべての2xxレスポンスが同じようにキャッシュされるわけではない」という事実だ。

キャッシュの適格性（Cacheability）

RFC上、明示的なキャッシュヘッダー（Cache-Control や Expires）がない場合、200 OK に対するレスポンスであっても、ブラウザや中間キャッシュは「ヒューリスティックキャッシュ（推測に基づくキャッシュ）」を行うことがある。
一方で、201 Created や 204 No Content は、基本的にヒューリスティックキャッシュの対象外とされることが多いが、明示的に Cache-Control を指定しない限り、予期せぬキャッシュ動作を引き起こす原因になる。

実務において、APIサーバーを構築する際は、以下の原則を頭に叩き込んでおいてほしい。

1. 動的なAPIレスポンス（200 OK でユーザー固有のデータを返す場合）:
基本的には Cache-Control: no-store を付与し、キャッシュさせてはならないデータであることを明示する。
2. 静的なリソースや公開データ（200 OK）:
Cache-Control: public, max-age=3600, s-maxage=86400 のように、ブラウザ側とCDN側の有効期限を明確に切り分ける。
3. 副作用のあるリクエスト（201 Created, 204 No Content）:
これらのレスポンスに対してキャッシュが残ることは稀だが、万全を期すために Cache-Control: no-store を設定し、古いキャッシュのバースト（キャッシュ汚染）を防ぐのがプロのインフラエンジニアの処世術だ。

—

3. 実践：ネットワークパケットの挙動とキャッシュ検証

百聞は一見に如かず。実際に curl コマンドを叩いて、レスポンスのステータスコードとキャッシュ関連のヘッダーがどのようにやり取りされているかを確認してみよう。

検証用Python（Flask）サーバーのコード

まずは、異なる 2xx ステータスコードと適切なキャッシュヘッダーを返すミニマムなAPIサーバーを準備する。

# app.py
from flask import Flask, jsonify, request, make_response

app = Flask(__name__)

# 200 OK + キャッシュ制御の例
@app.route('/api/resource', methods=['GET'])
def get_resource():
    data = {"id": 1, "name": "Zero Trust Network Architecture"}
    response = make_response(jsonify(data), 200)
    # ブラウザにはキャッシュさせず、CDNには60秒キャッシュを許可、バックグラウンド検証を指示
    response.headers['Cache-Control'] = 'public, max-age=0, s-maxage=60, stale-while-revalidate=30'
    response.headers['ETag'] = '"ztnc-v1-hash"'
    return response

# 201 Createdの例
@app.route('/api/resource', methods=['POST'])
def create_resource():
    # 新規作成成功時は明示的に no-store を指定し、Locationヘッダーを付与
    response = make_response(jsonify({"status": "created"}), 201)
    response.headers['Location'] = '/api/resource/2'
    response.headers['Cache-Control'] = 'no-store'
    return response

# 204 No Contentの例
@app.route('/api/resource/1', methods=['DELETE'])
def delete_resource():
    # ボディを持たないため、204を返す
    response = make_response('', 204)
    response.headers['Cache-Control'] = 'no-store'
    return response

if __name__ == '__main__':
    app.run(port=5000, debug=True)

このスクリプトを立ち上げ、手元のターミナルから curl でリクエストの挙動を追ってみよう。

ターミナルでのパケット・ヘッダー検証 (curl)

まずは GET /api/resource を叩き、どのようなヘッダーが返ってくるか確認する。-i オプションでHTTPレスポンスヘッダー全体を表示させよう。

$ curl -i http://localhost:5000/api/resource

【出力結果のイメージ】

HTTP/1.1 200 OK
Server: Werkzeug/3.0.1 Python/3.11.4
Date: Wed, 25 Oct 2023 12:00:00 GMT
Content-Type: application/json; charset=utf-8
Content-Length: 53
Cache-Control: public, max-age=0, s-maxage=60, stale-while-revalidate=30
ETag: "ztnc-v1-hash"
Connection: close

{
  "id": 1,
  "name": "Zero Trust Network Architecture"
}

ここで注目してほしいのが Cache-Control と ETag だ。クライアント（ブラウザやAPIクライアント）は、次回このリソースにアクセスする際、If-None-Match: "ztnc-v1-hash" ヘッダーを付与してリクエストを送る。サーバー側のデータに変化がなければ、サーバーはボディを返さずに 304 Not Modified を返し、ネットワーク帯域を極限まで節約する。これがHTTPキャッシュの醍醐味だ。

次に、リソース作成時の 201 Created の挙動を見てみよう。

$ curl -i -X POST http://localhost:5000/api/resource

【出力結果のイメージ】

HTTP/1.1 201 Created
Server: Werkzeug/3.0.1 Python/3.11.4
Date: Wed, 25 Oct 2023 12:05:00 GMT
Content-Type: application/json; charset=utf-8
Content-Length: 21
Location: /api/resource/2
Cache-Control: no-store
Connection: close

{
  "status": "created"
}

Location: /api/resource/2 が返されていることに注目してほしい。モダンなフロントエンドフレームワークやAPIクライアントは、このヘッダーを読み取って自動的に詳細画面へルーティングを飛ばす設計にできる。そして Cache-Control: no-store があるため、この作成リクエストのレスポンスがブラウザの履歴キャッシュなどに残る事故を防げる。

—

4. フロントエンド（Fetch API）での実務的なハンドリング

インフラやバックエンドがどれだけ完璧なステータスコードとキャッシュヘッダーを返しても、フロントエンド側の実装が雑だとすべてが台無しになる。
JavaScriptの Fetch API を使った、堅牢なエラー・ステータスハンドリングのコード例を見ておこう。

// フロントエンドでの非同期API呼び出しのベストプラクティス
async function createNewItem(itemData) {
  try {
    const response = await fetch('/api/resource', {
      method: 'POST',
      headers: {
        'Content-Type': 'application/json',
      },
      body: JSON.stringify(itemData),
    });

    // 2xx系であっても、コードごとの分岐を厳密に行う
    if (response.status === 201) {
      // Locationヘッダーから新規リソースのURIを取得
      const location = response.headers.get('Location');
      console.log(`リソースの作成に成功しました。移動先: ${location}`);
      
      const result = await response.json();
      return { success: true, location, data: result };
    } 
    
    if (response.status === 204) {
      console.log('処理は成功しましたが、データはありません。');
      return { success: true, data: null };
    }

    // 想定外の2xxや、その他のステータス
    if (!response.ok) {
      throw new Error(`サーバーエラーまたはクライアントエラーが発生しました: ${response.status}`);
    }

  } catch (error) {
    console.error('通信またはパース処理で異常が発生しました:', error.message);
    throw error;
  }
}

ここで重要なのは、fetch はサーバーが 4xx や 5xx を返してもネットワークエラー（例外）を投げないという点だ。さらに、2xx の中でも 201 や 204 ではレスポンスボディが空である可能性が高いため、安易に response.json() を呼び出すと SyntaxError (Unexpected end of JSON input) を引き起こす。
実務の現場では、「ステータスコードを確認してからボディのパース方法を変える」という防衛的プログラミングが絶対に欠かせない。

—

5. シニアが教える！現場のトラブルシューティングTips

最後に、私がこれまでの現場で幾度となく遭遇した「2xxとキャッシュにまつわるトラップ」と、その処方箋を授けておく。

トラップ1: 「APIを修正したのに、画面に反映されない！」

原因: ユーザーのブラウザや、途中のCDN（あるいはプロキシ）が古い 200 OK のレスポンスをキャッシュし続けている。
対策:
開発段階ではブラウザのDevToolsで「Disable cache」にチェックを入れるのは基本中の基本。
本番環境であれば、リソースのURIにクエリパラメータ（例: ?v=2.1.0）を付与するか、ETag / Last-Modified を用いた条件付きリクエスト（Conditional Request）が正しく機能しているかを、curl -H "If-None-Match: ..." で検証する。

トラップ2: 「DELETEやPOSTなのにキャッシュされてしまった」

原因: 不適切なプロキシサーバーや古いリバースプロキシが、非べき等なメソッド（POST や DELETE）のレスポンスをキャッシュルールに違反して保持してしまった。
対策:
確実に Cache-Control: no-store または Pragma: no-cache をすべての非GETレスポンスに付与する。セキュリティの観点からも、機微なデータを含む POST や PUT のレスポンスにキャッシュを許可してはならない。

—

おわりに

たかがステータスコード、されどステータスコード。
2xx というたった3文字の数字の裏側には、TCPセッションを流れるパケットのやり取り、ブラウザのメモリ管理、そしてCDNのキャッシュアルゴリズムが複雑に絡み合っている。

「動けばいいや」でコードを書くプログラマーから、ネットワークとプロトコルの挙動を掌中で操る真のインフラ・Webエンジニアへ。今日のこの知識が、次のデバッグの夜を少しでも早く終わらせるための羅針盤となれば幸いだ。

それじゃあ、また次の現場で会おう。健闘を祈る！