Cloudflare 02：CDN とキャッシュ ― 近くで返す

一言でいうと：近くの拠点が「写し」を覚えておく

CDN（Content Delivery Network）は、世界中に置いた拠点にファイルの写しを持たせ、利用者のいちばん近くの拠点から返す網です。写しを覚えておくことをキャッシュと呼びます。

Cloudflare の場合、特別な申し込みは要りません。01号で見たオレンジの雲（プロキシ）にした名前なら、最初からキャッシュが効いています。利用者のリクエストはエニーキャストで近くの拠点に届き、その拠点に写しがあれば、そこで返事が完結します。

もともと Cloudflare は、この CDN と、攻撃からの守り（04号）を無料で提供する会社として広まりました。今も、多くの人が Cloudflare から得ているいちばん大きな恩恵は、このキャッシュです。

ただし、何でも覚えればよいわけではありません。人によって中身が違うものを覚えて、別の人に返してしまうと大事故になります。この号の後半では、その線引きを見ていきます。

最初の1回は MISS：オリジンに取りに行く

キャッシュの動きを1つずつ追います。

利用者が logo.png を求めたとき、近くの拠点にまだ写しが無い場合、拠点はオリジンに取りに行きます。オリジンから受け取ったファイルを利用者に返しながら、同時に写しとして保存します。この状態を MISS と呼びます。

大事なのは、写しは拠点ごとに持つという点です。東京の拠点に写しがあっても、大阪の拠点には無いかもしれません。Cloudflare の拠点は世界中に数百あるので、人気のないファイルは、拠点ごとに毎回 MISS になりがちです。

この「拠点ごとに MISS する」問題を和らげるのが、拠点を階層に分けて、下の拠点が上の拠点に聞くようにする Tiered Cache です。これは11号で詳しく扱います。

また、写しはずっと残るとは限りません。拠点の容量には限りがあり、あまり求められないファイルは、期限の前でも追い出されることがあります。

2回目からは HIT：オリジンに行かずに返す

同じ拠点に同じファイルが求められると、今度は写しから返します。これが HIT です。オリジンには何も届きません。

HIT のときの返事は、利用者の近くで完結するので速く、オリジンは何もしなくて済みます。人気のファイルほど、1回の MISS のあとに何万回もの HIT が続きます。

キャッシュがどれだけ効いているかは、HIT の割合（キャッシュ率）で測ります。管理画面の Caching の分析で、期間ごとの割合や、よく MISS しているファイルを確かめられます。

キャッシュの調整は、この表のどれが原因かを見極めて、1つずつ直していく作業です。

既定で覚えるのは「拡張子」で決まる静的ファイル

何も設定しないとき、Cloudflare は何を覚えるのでしょうか。答えは、URL の拡張子が決められた一覧に入っているファイルです。

一覧には、CSS・JavaScript・画像（png・jpg・webp・svg など）・フォント（woff2 など）・PDF・動画・圧縮ファイルなど、誰が見ても同じになりやすい種類が並んでいます。一覧の全体は公式のドキュメントにあります。

逆に、HTML は既定では覚えません。拡張子の無い URL（/about のような）や、API の JSON の応答も同じです。こうした応答は cf-cache-status: DYNAMIC になります。

なぜ HTML を覚えないのでしょうか。HTML は、ログインしている人の名前が入っていたり、カートの中身が入っていたりと、人ごとに違う可能性があるからです。人ごとに違うページを覚えてほかの人に返すと、情報漏えいになります。安全側に倒して、既定では覚えないのです。

一覧に入っていても、覚えないことがあります。

この既定を広げる（HTML も覚える）、狭める（この画像は覚えない）のが Cache Rules です。

キャッシュキー：何を「同じもの」とみなすか

拠点は、写しに名札を付けて覚えています。この名札がキャッシュキーです。リクエストが来ると、拠点は名札を作り、同じ名札の写しがあれば HIT になります。

既定のキャッシュキーは、ほぼ URL 全体（ホスト名・パス・? の後ろのクエリ文字列）です。つまり、次の3つは別々の写しになります。

2行目は、わざと別物にするよい使い方です。ファイルを更新したら ?v=3 にすれば、古い写しを消さなくても、新しい中身が配られます。ファイル名に版やハッシュを入れる（app.3f9a2c.js）のも同じ考え方で、ビルドの道具がよくやってくれます。

問題は3行目です。広告やメールのリンクに付く utm_... のような、中身に関係ないクエリで写しが増えると、同じ画像なのに MISS が繰り返されます。

Cache Rules では、キャッシュキーに含める・外すクエリを決められます。「utm_ で始まるものは無視する」「v だけを使う」といった形です。逆に、言語や端末の種類でページが変わるなら、その違いをキーに含めないと、英語のページが日本人に返る、といった事故が起きます。

2つの時計：Edge TTL と Browser TTL

写しには期限があります。期限までの時間を TTL（Time To Live）と呼びます。キャッシュには、2つの別々の時計がある点が大事です。

どちらも長いほうが速く見えますが、違いがあります。拠点の写しは、パージ（後のページ）で消せます。ブラウザの中の写しは、消せません。Browser TTL を1年にしてしまうと、ファイルを直しても、一度見た人のブラウザには1年間古いファイルが残ります。

そこで、よく使われる組み合わせは次のとおりです。

Edge TTL と Browser TTL は、オリジンの Cache-Control から決まるのが基本で、Cache Rules で上書きできます。

期限が切れたら「まだ同じ？」と聞く

Edge TTL が過ぎた写しは、すぐ捨てられるわけではありません。拠点はオリジンに、写しに付いていた ETag（中身の指紋）や Last-Modified を送って「まだ同じですか？」と確かめます。変わっていなければ、オリジンは 304 Not Modified という短い返事だけを返し、拠点は写しの期限を延ばして返します（REVALIDATED）。変わっていれば新しい中身を受け取ります（EXPIRED）。これが効くには、オリジンが ETag か Last-Modified を返している必要があります。

基本は、オリジンの Cache-Control で決める

キャッシュの設定は、Cloudflare の管理画面だけで決めるものではありません。基本は、オリジンが応答ごとに `Cache-Control` ヘッダーで伝えるものです。どの応答が人ごとに違うかを一番よく知っているのは、アプリ自身だからです。

# ファイル名に版が入った静的ファイル：1年覚えてよい
Cache-Control: public, max-age=31536000, immutable

# HTML：ブラウザは毎回確かめる、CDN は60秒覚えてよい
Cache-Control: public, max-age=0, s-maxage=60

# ログイン後の画面や個人情報：誰も覚えてはいけない
Cache-Control: private, no-store

CDN だけに別の指示を出したいときは、CDN-Cache-Control や、Cloudflare だけが読む Cloudflare-CDN-Cache-Control というヘッダーも使えます。ブラウザ向けの Cache-Control はそのままにして、拠点の時間だけ長くできます。

オリジン側で正しく書いておけば、Cloudflare 以外の CDN に替えたときもそのまま通用します。

Cache Rules：既定を上書きする

オリジンを直せない、あるいはまとめて指定したい場合は、Cache Rules で既定を上書きします。管理画面の Caching → Cache Rules で作ります。

1つのルールは「もし（条件）なら、こうする（設定）」の形です。条件の書き方は、09号のルール全般と共通のルール式です。

# ルール1：ブログの HTML も覚える
条件: starts_with(http.request.uri.path, "/blog/")
設定: Eligible for cache / Edge TTL = 1時間

# ルール2：管理画面と API は絶対に覚えない
条件: starts_with(http.request.uri.path, "/admin")
   or starts_with(http.request.uri.path, "/api")
設定: Bypass cache

設定できることの例です。

ルールは上から順に評価され、あとのルールが前のルールの設定を上書きします。「全体に効く広いルール」を上に、「例外」を下に置くのが基本です。HTML を覚えさせるときは、ログインしている人のリクエスト（セッションの Cookie がある）を除く条件を必ず入れてください。

答え合わせ：cf-cache-status ヘッダー

設定したら、本当に思いどおりに動いているか確かめます。Cloudflare を通った応答には、`cf-cache-status` というヘッダーが付いています。

curl -sI https://example.com/img/logo.png | grep -i -E "cf-cache-status|age|cache-control"

Age ヘッダーは、写しが作られてから何秒たったかを表します。HIT なのに Age が小さいままなら、写しがすぐ追い出されているのかもしれません。

注意点として、MISS を1回見ただけで「効いていない」と判断しないことです。写しは拠点ごとなので、別の拠点を通れば MISS になり得ます。同じ場所から2〜3回叩いて確かめてください。

パージ：古い写しを消す

ファイルを直したのに、拠点に古い写しが残っている。そんなときはパージ（キャッシュの消去）をします。管理画面の Caching → Configuration から、または API で行います。

以前は URL の指定以外は企業向けプランだけの機能でしたが、2025年から、すべての消し方が全プランで使えるようになりました。ただし、プランごとに API を呼べる回数に上限があります。

curl -X POST "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/purge_cache" \
  -H "Authorization: Bearer $CF_API_TOKEN" \
  -d '{"files":["https://example.com/img/logo.png"]}'

「すべて消す」は気軽に使わないでください。消した直後は世界中の拠点で一斉に MISS になり、オリジンに負荷が集中します。パージに頼るより、ファイル名に版を入れて「新しい名前の別物」として配るほうが、安全で確実です。

料金と制限

CDN とキャッシュの基本は、無料プランから使えます。

Cache Reserve は、写しが拠点の容量から追い出されてしまう問題への答えです。写しを R2（22号）の上に長く保存しておき、拠点に無いときはそこから返します。オリジンまで戻る回数を減らせますが、保存量と読み書きの回数に応じて料金がかかります。

1ファイルの上限や、ルールの本数、パージの回数は、プランや時期で変わります。公式の Limits のページで確かめてください。

注意点として、Cloudflare の利用規約では、動画や大量の大きなファイルを CDN で配ることには制限があります。動画を配るなら31号の Stream、大きなファイルは R2 を使うのが想定された道です。

※2026年9月時点の情報です。料金・上限は変わるので、公式で確かめてください。

よくある落とし穴

キャッシュは、効かないと遅いだけですが、効きすぎると事故になります。

1つ目は特に注意してください。「全部覚える」設定は速さの面では魅力的ですが、人ごとに違うページを別の人に返すと、個人情報の漏えいになります。覚えてよいかどうかは、アプリ側の `Cache-Control` で明示するのが一番の防ぎ方です。

もう1つ、開発中に「キャッシュのせいで変更が見えない」と感じたら、管理画面の Development Mode で一時的にキャッシュを止められます（一定時間で自動で戻ります）。

他の号とのつながり

キャッシュは、「オリジンに行かずに済ませる」ための仕組みの中心で、多くの号と関わります。

Workers（18号）からは、fetch() にキャッシュの指定を付けたり、caches.default で写しを直接読み書きしたりできます。API の応答のように、ふつうは覚えないものを「条件付きで少しだけ覚える」といった細かい制御が必要になったら、Workers の出番です。