Cache系ツールの使い分け

キャッシュ問題は「保存されない」「再検証されない」「層ごとに挙動が違う」の3系統に分けると解決が早くなります。

最初に選ぶべきツール（症状ベース）

• 更新したのに反映されない → Cache Not Working Troubleshooting
• 304にならず毎回200 → Cache Diagnostic
• CDN経由だけ古い/違う → HTTP Cache Mismatch

ツール役割マップ

• Cache Not Working Troubleshooting: 症状ベースで入口を決める
• Cache Response Analyzer: 単一レスポンスの可否判定
• HTTP Cache Mismatch: 環境間の差分比較
• Cache Diagnostic: ヘッダー横断で総合診断
• Cache Control Overview / Inspect: 方針整理とディレクティブ詳細確認

実務フロー（推奨）

1. 1) 症状を固定し、最初の1ツールで入口を決める
2. 2) Response Analyzer または Diagnostic でヘッダー根拠を取る
3. 3) CDN差分があれば Mismatch へ進み、配信層を分離して確認する
4. 4) 最後に Cache-Control 方針を Overview/Inspect で整理して再発防止する

調査時に必ず採取するヘッダー

• Response: Cache-Control / ETag / Last-Modified / Expires / Age / Vary
• Request: If-None-Match / If-Modified-Since / Cache-Control
• 経路情報: Via / X-Cache / CDN応答識別ヘッダー
• 同一URLでブラウザ・CDN・オリジンの3点取得

リソース種別ごとの方針

• HTML: 短TTL + 再検証（no-cache または短い max-age）
• API(JSON): 機微データは no-store、公開系は validator 前提
• 静的アセット: versioned URL + long max-age + immutable
• CDN: s-maxage とブラウザ向け指示を分けて設計

比較対象ツール

• Cache Not Working Troubleshooting
• Cache Response Analyzer
• HTTP Cache Mismatch
• Cache Diagnostic
• Cache Control Overview
• Cache-Control Inspect

よくある誤り

• HTMLにも immutable を付けてしまい、更新反映が遅延する
• ETag/Last-Modified を返していても If-* リクエスト確認をしていない
• ブラウザとCDNの結果を同じ層として比較してしまう

修正後の再確認ポイント

• 初回200→再取得304の遷移が再現するか
• デプロイ後に旧HTMLが残らないか（stale期間の観測）
• CDN purge後に Age が意図通りリセットされるか
• Varyキー変更時にキャッシュ分岐が増えすぎていないか

運用ランブック（障害時）

1. まず「壊れている層」を特定（ブラウザ/CDN/オリジン）
2. 一時回避が必要ならHTMLだけ短TTL化して影響縮小
3. 恒久対策はURLバージョニングとvalidator整備で実施
4. 再発防止としてヘッダー差分監視を定例化

FAQ

最初に使う1本が分からない時は？

症状が「更新反映遅延」なら Troubleshooting、「304不発」なら Diagnostic、「層差分」なら Mismatch から始めてください。

Cache-Control Inspect と Overview の違いは？

Inspect は個別レスポンスの解釈、Overview は方針設計とディレクティブ整理に向いています。

参照仕様

• RFC 9111 (HTTP Caching)
• RFC 9110 (HTTP Semantics)