CDN・エッジ

Cache-Control きゃっしゅこんとろーる

キャッシュHTTPヘッダーCDNブラウザキャッシュTTLレスポンスヘッダー

Cache-Controlについて教えて

簡単に言うとこんな感じ！

Webページの「データをどのくらい手元に保存しておいていいか」をブラウザやCDNに指示する命令書だよ！「1時間はキャッシュしていいよ」「絶対に保存しないで」みたいなことをHTTPヘッダーに書いて伝えるんだ。

Cache-Controlとは

Cache-Controlは、WebサーバーがブラウザやCDN（コンテンツ配信ネットワーク）に対して「このデータをどのようにキャッシュ（一時保存）してよいか」を指示するためのHTTPレスポンスヘッダーです。Webページを表示するとき、画像やCSS・JavaScriptなどのファイルを毎回サーバーから取得していたら時間がかかりますが、Cache-Controlを使えば「一定期間はブラウザに保存しておいてよい」と伝えられるため、ページの表示が速くなります。

逆に、個人情報を含むページや常に最新の情報が必要なページには「キャッシュしないで」と指示することも重要です。Cache-Controlを正しく設定することは、サイトの速度・セキュリティ・コスト削減のすべてに直結する、地味ながら非常に重要な設定です。

リクエスト側（ブラウザ→サーバー）とレスポンス側（サーバー→ブラウザ）の両方で使えますが、実務でよく登場するのはレスポンスヘッダーとしての設定です。

Cache-Controlの主なディレクティブ（命令）

Cache-Controlは「ディレクティブ」と呼ばれるキーワードをカンマ区切りで並べて指定します。代表的なものを整理すると次のとおりです。

ディレクティブ	意味	使いどころ
`max-age=秒数`	指定した秒数だけキャッシュを有効とする	画像・CSS・JSなど変更が少ないファイル
`no-cache`	キャッシュは保存してよいが、必ずサーバーに新鮮さを確認する	常に最新を見せたいが速度も維持したいページ
`no-store`	一切キャッシュに保存しない	個人情報・金融情報など機密データ
`public`	CDNや共有キャッシュにも保存してよい	誰でも同じ内容が見えるコンテンツ
`private`	ブラウザにのみ保存し、CDNなど共有キャッシュには保存しない	ログイン後のマイページなど個人向けコンテンツ
`s-maxage=秒数`	CDN（共有キャッシュ）だけに適用するmax-age	CDNのTTL（保存期間）をブラウザと別に設定したいとき
`must-revalidate`	キャッシュが期限切れになったら必ずサーバーに確認する	古いキャッシュを絶対に使ってほしくないとき
`immutable`	コンテンツは絶対に変わらないと宣言し、再確認リクエスト自体を抑制する	ファイル名にハッシュを含むビルド成果物

設定例で見るイメージ

# 例1: 画像ファイル（長期キャッシュ）
Cache-Control: public, max-age=31536000, immutable

# 例2: HTMLページ（常に最新を確認）
Cache-Control: no-cache

# 例3: ログイン後のマイページ（キャッシュ禁止）
Cache-Control: no-store, private

# 例4: CDNには1時間、ブラウザには10分だけ保存
Cache-Control: public, max-age=600, s-maxage=3600

「no-cache」と「no-store」の違いを覚えよう

この2つは混同しやすい！

no-cache → 「保存はしていいけど、使う前に必ずサーバーに確認してね」（保管庫には入れるが封印する）
no-store → 「そもそも保存するな！」（保管庫に入れることすら禁止）

機密情報にはno-storeが必要で、no-cacheだけでは不十分な点に注意です。

歴史と背景

1996年: HTTP/1.0の時代、Expiresヘッダーで「この日時まで有効」という形式でキャッシュを制御していた。日時を絶対値で指定するため、サーバーとクライアントの時計がずれると誤動作するという問題があった
1997年: HTTP/1.1（RFC 2068）でCache-Controlが登場。相対的な秒数（max-age）で指定できるようになり、柔軟性と信頼性が大幅に向上した
1999年: RFC 2616でHTTP/1.1が改訂・整理され、Cache-Controlの仕様も明確化された
2000年代: CDNサービス（Akamai、CloudFront等）の普及により、public/privateやs-maxageの使い分けが実務上重要になった
2014年: immutableディレクティブがFirefoxによって提案・実装され、モダンなフロントエンドのビルドパイプライン（ハッシュ付きファイル名）と組み合わせる最適化手法として定着
2022年: RFC 9111でHTTPキャッシュの仕様が全面改訂・整理され、現在の標準となった

ブラウザキャッシュとCDNキャッシュの関係

Cache-Controlが影響するキャッシュは「ブラウザ」と「CDN」の2段階あります。それぞれに対して別々の指示が出せるのがポイントです。

Expiresヘッダーとの違い

Cache-Controlが登場する以前は Expiresヘッダー（「この日時まで有効」と絶対日時で指定するもの）が使われていました。

比較項目	Cache-Control（推奨）	Expiresヘッダー（旧来）
指定方法	相対的な秒数（`max-age=3600`）	絶対日時（`Expires: Sat, 01 Jan 2026 00:00:00 GMT`）
時計のズレ	影響なし	サーバーとクライアントの時計がずれると誤動作
柔軟性	高い（複数ディレクティブ組み合わせ可）	低い
優先順位	両方ある場合、Cache-Controlが優先	—

現在はCache-Controlを使うのが標準で、Expiresは後方互換のために残っている状態です。

規格・RFC番号	内容
RFC 9111	HTTP Caching。キャッシュ全般の仕様（2022年改訂版、現在の標準）
RFC 9110	HTTP Semantics。HTTPヘッダー全般の意味論的定義
RFC 2616	HTTP/1.1（旧版）。Cache-Controlが初めて正式定義された（現在はRFC 9111に置き換え済み）
RFC 8246	HTTP Immutable Responses。`immutable`ディレクティブの定義