Webの「呼吸」を制御せよ：Cache-Controlが語るキャッシュ戦略の深淵
Webエンジニアとしてキャリアを積んでいくと、必ず「ブラウザが古いデータを表示している」「CDNでキャッシュが消えない」という、一見単純だが根の深いトラブルに直面する。その正体は、多くの場合 `Cache-Control` ヘッダーの誤解にある。
RFC 9111（旧 RFC 7234）で定義されるこのヘッダーは、単なる設定値ではない。クライアント、プロキシ、CDN、そしてサーバーが織りなす「Webの通信フロー」そのものを制御する、極めて重要な指揮棒だ。今回は、現場で泥をすすってきた経験から、この「キャッシュの作法」を解き明かそう。
—
1. キャッシュ制御の4つの騎士：主要ディレクティブの正体
現場で最も頻出する `Cache-Control` のディレクティブには、明確な「役割分担」がある。これらを混同すると、パフォーマンスの低下だけでなく、致命的な情報漏洩や整合性エラーを招く。
max-age: 「賞味期限」の定義
`max-age=
- 実務のコツ: 静的アセット（画像やJS）には1年（31536000秒）を指定し、ファイル名にハッシュ値を付与する「キャッシュバスティング」と組み合わせるのが現代の定石だ。
no-cache: 「確認を怠るな」という命令
ここが最大の誤解ポイントだ。「キャッシュするな」ではない。「キャッシュして良いが、使う前に必ずサーバーに検証（Validation）をかけろ」という意味だ。EtagやLast-Modifiedを使って、304 Not Modifiedが返ることを期待する挙動である。
no-store: 「記憶を消せ」という命令
これが真の「キャッシュ禁止」。ブラウザもCDNも、ディスクやメモリにいかなるデータも保存してはならない。個人情報や機密性の高いAPIレスポンスには、必ずこれを付与する。
must-revalidate: 「期限切れは許さない」という命令
`max-age` で指定した期間が過ぎたら、必ずオリジンサーバーに再検証せよ、という指示だ。ネットワークが切断されている場合、古いキャッシュを返すことすら許さず、504 Gateway Timeoutを返せ、という極めて堅牢な挙動を求める際に使う。
—
2. 通信フロー：ブラウザとサーバーの「会話」を覗く
`curl` を使えば、この挙動は一目瞭然だ。以下のコマンドで、サーバーが何を語りかけているかを確認してほしい。
ヘッダー情報を詳細に確認する
curl -I https://api.example.com/data/user-profile
通信のシーケンス（簡略図）:
1. リクエスト: `If-None-Match: “etag-value”` を乗せて送信。
2. 検証: サーバーは現在のデータと Etag を比較。
3. 判定:
- 変わっていなければ `304 Not Modified`（ボディなし、高速化）。
- 変わっていれば `200 OK`（新しいボディを送信）。
これを理解していると、Web APIの設計時に「無駄な帯域を削る」ための最適解が自然と見えてくるはずだ。
—
3. 実践：インフラ・アプリケーション設定例
現場では、アプリケーションコードだけでなく、Nginxなどのフロントエンドでの設定も重要だ。
Nginxでの設定例（サーバー側）
`nginx.conf` で、特定のディレクトリに対してキャッシュ戦略を強制する設定だ。
location /static/ {
# 1年間キャッシュさせ、ブラウザに保存を許可
expires 1y;
add_header Cache-Control “public, immutable”;
}
location /api/ {
# APIレスポンスはキャッシュさせない（厳格な制御）
add_header Cache-Control “no-store, no-cache, must-revalidate, proxy-revalidate”;
}
フロントエンド（Fetch API）での制御
ブラウザ側の挙動を制御する際は、`cache` オプションを活用する。
// Fetch APIでのキャッシュ制御例
fetch(‘/api/v1/resource’, {
method: ‘GET’,
// ‘no-cache’: キャッシュを確認してから使う
// ‘no-store’: キャッシュを一切使わない
// ‘reload’: 強制的にサーバーから取得
cache: ‘no-cache’
})
.then(response => response.json())
.then(data => console.log(data));
—
最後に：シニアからのアドバイス
トラブルシューティングの際、ブラウザの「開発者ツール（Networkタブ）」を眺めるだけで終わっていないだろうか？
`Response Headers` を確認し、`X-Cache` ヘッダー（CDN利用時）や `Age` ヘッダーを追跡してほしい。`Age` が増え続けているのにデータが更新されない場合、それはキャッシュ階層のどこかで「賞味期限」が意図せぬ設定になっている証拠だ。
ネットワークは嘘をつかない。プロトコルの仕様を読み解き、パケットの流れを想像できるようになれば、どんな難解なキャッシュトラブルも必ず解決の糸口が見つかる。君たちの健闘を祈る。
コメント