CDNのブラウザキャッシュは「一律1年」ではなくパスの更新運用で設計する

画像配信CDNに Cache-Control ヘッダーが付いておらず、ブラウザキャッシュがまったく効いていない——PageSpeed Insights の「効率的なキャッシュ保存期間を使用する」警告の典型的な原因です。対処自体は CloudFront の Response Headers Policy（Custom header + Override origin）などで簡単に付与できますが、落とし穴は TTL の決め方にあります。

「全ファイル一律で1年 + immutable」は危険

キャッシュ改善の手順書としてよく提示されるのが public, max-age=31536000, immutable の一律適用です。しかしこれをそのまま適用すると、次の問題が起きます。

• 固定ファイル名のまま内容を差し替える運用のパスでは、古いファイルが利用者のブラウザに最長1年残り続ける
• 個人情報を含むファイル（帳票CSVなど）を配信するパスにまでキャッシュ指示が付いてしまう

パスごとに「URLが変わる運用か」で使い分ける

TTL はファイル種別ではなく、そのパスの更新運用で決めます。

| パスの運用 | 推奨設定 | 理由 | |---|---|---| | 内容更新のたびに新しいファイル名（UUID等）が発行される | 1年 + immutable | URL 自体が変わるので古いキャッシュが参照されることがない | | 固定ファイル名のまま内容が差し替わる・誤登録の差し替えがありうる | 数分程度の短い TTL | 差し替え後もキャッシュが強く残るリスクを許容時間内に抑える | | 個人情報を含むファイルが混在する | キャッシュ設定を付与しない | 共有・永続キャッシュ自体がリスク |

実際の案件では、当初「更新頻度が低いから7日間」としていたプロダクト系画像のパスも、誤登録時にキャッシュが残るリスクを重視して5分に揃えました。TTL の長さは「どれだけ変わらないか」より「間違って配信されたとき、何分で消えてほしいか」から逆算するほうが安全です。

運用上のポイント

• エッジキャッシュ（Cache Policy）とブラウザキャッシュ（Response Headers Policy）は別物。ブラウザ向けヘッダーの追加だけならエッジ側 TTL には触れない
• Override origin を有効にすれば、オリジン（S3等）側にヘッダーがなくても確実に付与できる
• 反映後は curl -sI <URL> | grep -i cache-control で確認し、数日後に PageSpeed Insights を再実行して警告の解消を確かめる