更新したのに反映されない時の診断手順
「更新したのに古いまま」は、キャッシュ設定の誤りだけでなく、配信層の不一致や無効化運用不足でも発生します。
最初に分ける観点
- HTMLが古いのか、APIレスポンスが古いのか、静的アセットが古いのか
- ブラウザだけ古いのか、CDN経由だけ古いのか、両方古いのか
- 初回アクセスだけ古いのか、継続的に古いのか
診断ステップ
- 1) Cache Not Working Troubleshooting で症状分類する
- 2) Cache Response Analyzer で単一レスポンスの方針を確認する
- 3) HTTP Cache Mismatch でブラウザ・CDN・オリジン差分を比較する
- 4) Cache-Control Inspect で no-store/no-cache/max-age/immutable を確認する
- 5) Cache Control Overview で用途別方針に戻して再設計する
リソース別の推奨方針（要点）
- HTML: 短TTL + validator（デプロイ反映優先）
- API: 機微データは no-store、公開データは validator 前提
- 静的アセット: versioned URL + long max-age + immutable
- CDN: s-maxage とブラウザ向け方針を分離
運用で詰まりやすい点
- URLバージョニングなしで immutable を付ける
- CDN purge の対象漏れや手順漏れ
- 配信層でヘッダーが上書きされ、意図と異なる値が返る
- 観測ポイントが揃っておらず、比較結果がぶれる
修正後の再確認
- 同一URLで新コンテンツが返るか（ブラウザ/CDN/オリジン）
- 再訪問で想定どおり 304 または再取得が発生するか
- デプロイ後の反映遅延がSLO内に収まるか
使うツール
- Cache Not Working Troubleshooting
- Cache Response Analyzer
- HTTP Cache Mismatch
- Cache-Control Inspect
- Cache Control Overview
- Cache Diagnostic
FAQ
- 更新反映が遅い時は最初に何を見るべきですか？
- まず HTML/API/静的アセットのどれが古いかを分離し、対象ごとにキャッシュ方針を確認してください。
- immutable は便利ですが常に付けて良いですか？
- URLバージョニングが前提です。固定URLに immutable を付けると更新が届きにくくなります。
参照仕様
次に見る（診断順）
site_map ルールに基づいて、次に確認すべきページを表示しています。
- Cache Not Working Troubleshooting — キャッシュが効かない症状をヘッダーから段階的に切り分け
- HTTP Cache Mismatch — キャッシュ不一致の原因候補を特定
- キャッシュ制御まとめ — Cache-Control/Pragma/Expires の使い分けを整理
- Cache-Control Inspect — Cache-Control ディレクティブを分解・解釈
- Cache Response Analyzer — レスポンスヘッダーからキャッシュ可否を判定
- Cache Diagnostic — キャッシュ関連ヘッダーを横断診断
- 症状別診断ガイド（入口） — キャッシュ/CORS/JWT/MIME系の実運用トラブルを、症状起点で最短導線に振り分ける総合ハブ
- 304が返らない時の診断手順 — ETag / Last-Modified と If-* の往復を確認して 304 不発を切り分ける
同テーマの導線
事例クラスタ一覧
実運用トラブル別に、最短の診断ルートへ入るためのシナリオ集
- 症状別診断ガイド（入口） — キャッシュ/CORS/JWT/MIME系の実運用トラブルを、症状起点で最短導線に振り分ける総合ハブ
- 304が返らない時の診断手順 — ETag / Last-Modified と If-* の往復を確認して 304 不発を切り分ける
- CORS preflight失敗時の診断手順 — OPTIONS応答、Allow-*、Origin条件を順に確認して preflight 失敗を解消する
- JWT 401/403 切り分け手順 — Authorization / WWW-Authenticate / claims / 署名検証を連携して 401 と 403 を分離する
- 429/503で再試行が止まらない時の診断手順 — Retry-After の秒/日時解釈とクライアント実装差を切り分け、過剰再試行を抑える
- nosniffでJS/CSSがブロックされる時の診断手順 — Content-Type と nosniff の不一致、404/302混入、配信経路の上書きを切り分ける
- Set-Cookie が保存されない時の診断手順 — Domain/Path/Secure/SameSite を順に確認して Cookie 非保持の原因を切り分ける
- OAuth戻りでログインが維持されない時の診断手順 — IdP戻りで起きる Cookie 不達を SameSite・Secure・Path/Domain・競合で順に切り分ける
- 同名Cookie競合で不安定な時の診断手順 — 同名CookieのPath/Domain差分・上書き順・送信衝突を整理して不安定挙動を解消する
- Cookie障害の運用チェックリスト — 保存失敗・OAuth戻り失敗・同名競合を一本化し、トリアージから恒久対策まで運用手順を標準化する