Cloudflare のキャッシュ命中率が 30% しかない？この 3 つのルールで 90% まで引き上げる

ブログの Cloudflare キャッシュ命中率が 30% 前後で停滞していました。画像や CSS などの静的リソースはキャッシュされるのに、HTML ページは毎回オリジンへ戻り、サーバーはリクエストでいっぱい。Cloudflare はデフォルトで HTML をキャッシュせず、Page Rules の設定方法もすでに廃止方向です。

Cache Rules と Edge TTL を調べて設定した結果、命中率は 30% から 90% へ、TTFB は 500 ミリ秒から 100 ミリ秒台へ、サーバー負荷は 90% 減りました。この記事では、HTML がキャッシュされない理由、Cache Rules の設定手順、効果の検証方法まで解説します。

Cloudflare はなぜデフォルトで HTML をキャッシュしないのか？

Cloudflare のデフォルトキャッシュ動作

まず Cloudflare のデフォルトキャッシュ戦略から。デフォルトでは静的リソース——画像（JPG、PNG、GIF）、スタイルシート（CSS）、スクリプト（JS）——だけがキャッシュされます。HTML ページ？残念ながらデフォルトではキャッシュされません。

なぜか？Cloudflare はリソースをキャッシュできるか、主に 3 条件で判断します：

1. Cache-Control ヘッダー：private、no-store、no-cache、max-age=0 が設定されていればキャッシュしない
2. レスポンスコード：特定の HTTP ステータスコードのみキャッシュ（200、301、404 など）
3. リクエストメソッド：GET のみキャッシュ。POST、PUT などは対象外

HTML ページは通常「動的コンテンツ」とみなされ、ユーザー固有の情報が含まれる可能性があるため、デフォルトではキャッシュしません。設計としては合理的です——ログイン機能があるサイトなら、HTML にユーザー名や個人情報が含まれることもあり、CDN にキャッシュして他の人に見せるわけにはいきません。

HTML をキャッシュしない本当の理由

要するに Cloudflare は安全のためこうしています。コミュニティフォーラムで、全サイトキャッシュをそのまま有効にした人の話を見ました。wp-login.php ログインページまでキャッシュされ、ログイン情報までキャッシュされたそうです。結果は想像に余りません——訪問者がキャッシュされたページから WordPress 管理画面に入れてしまう。考えるだけでゾッとします。

一方、サイトが静的コンテンツ中心なら、例えば：

• Next.js、Gatsby などで生成した静的ブログ
• 更新頻度の低い企業サイト、ドキュメントサイト
• 純粋な紹介ページ

HTML キャッシュでパフォーマンスは大きく向上します。ポイントは正しく設定し、管理画面・ログインなど除外すべきページを除外すること。

HTML キャッシュでどれくらい改善する？

Medium で誰かが共有したデータでは、HTML キャッシュ設定後、TTFB が 500 ミリ秒から 100〜160 ミリ秒に下がり、サーバー負荷が 90% 減ったそうです。かなりインパクトのある数字です。

なぜこんなに差が出るのか？シンプルです——以前は訪問者がサイトに来るたび、HTML をオリジンサーバーから取得し、サーバーがリクエスト処理・DB クエリ・ページレンダリングを行っていました。今は CDN がキャッシュ済み HTML をそのまま返し、オリジンサーバーは動きません。アクセスが増えるほど差は広がります。

Page Rules は廃止、Cache Rules でどう置き換える？

Page Rules の終焉

以前 Cloudflare を使っていたなら Page Rules を知っているはずです。「Cache Everything」オプションで HTML をキャッシュできました。残念ながら Page Rules は deprecated 扱いです。

タイムライン：

• 2024 年 7 月：新規登録の無料アカウントは Page Rules 不可
• 2025 年：Cloudflare が既存 Page Rules を新システムへ自動移行
• 今後の新規設定は Cache Rules

なぜ廃止？Page Rules は古く、設定の柔軟性が足りない。無料版は 3 ルールまで。複雑なキャッシュ戦略には物足りない。

Cache Rules の新しい世界

Cache Rules は Cloudflare の新しいキャッシュ設定システムで、はるかに強力です。最大の違い：

Page Rules 時代：「Cache Everything」を手動選択しないと全コンテンツをキャッシュできなかった

Cache Rules 時代：「Eligible for cache」（キャッシュ対象）を選ぶと Cache Everything が自動で有効になる

この変化は重要です。最初は「Cache Everything」オプションを探し回っていましたが、名前が変わっていただけでした。

また Cache Rules のマッチ条件は柔軟：

• URI パス、ファイル拡張子、ホスト名など複数条件でマッチ
• 正規表現に対応（あまり使いませんが）
• 複数条件の組み合わせが可能

移行時の注意点

まだ Page Rules を使っているなら、いくつか押さえておきましょう：

1. Cloudflare が移行を支援：2025 年に Page Rules を Cache Rules へ自動変換（自分で先に移行しても OK）
2. 移行されない設定あり：特に「Disable Security」「Disable Performance」は廃止され移行されない
3. 挙動に微妙な差：Cache Rules の「Eligible for cache」は Page Rules の「Cache Everything」に相当するが、実装ロジックに差がある

今のうちから Cache Rules を使うことをおすすめします。いずれ移行するなら早めの方が安心。Cache Rules の方が設定も分かりやすいです。

Cache Rules 設定実践：3 ルールで全サイトキャッシュ

理論はここまで。実践に入ります。管理画面の除外から全サイトキャッシュまで、3 本の Cache Rules を設定します。

Vultr - 高性能NVMeクラウドサーバー、世界32拠点、Dockerワンクリック展開対応

価格を見る →広告

準備：設定画面へ

Cloudflare コンソールにログインし、対象ドメインを選び：

1. 左メニューの「Caching」（キャッシュ）
2. 「Cache Rules」タブ
3. 「Create rule」（ルール作成）

ここから 1 本ずつ設定していきます。

ルール 1：管理画面・管理ページを Bypass（最高優先度）

なぜ最初？ 安全第一！管理画面・ログインページが絶対にキャッシュされないようにします。

設定手順：

1. Rule name（ルール名）：Bypass Admin Pages
2. When incoming requests match（マッチ条件）：
   • 「Custom filter expression」を選択
   • Field は「URI Path」
   • Operator は「contains」（含む）
   • Value に /wp-admin（複数パスは後で追加）
3. 除外パスを追加：「Or」をクリックして追加：
   • /wp-login.php（WordPress ログインページ）
   • /admin/（汎用管理パス）
   • /api/auth/（API 認証がある場合）
4. Then（実行操作）：
   • Cache eligibility で「Bypass cache」（キャッシュ迂回）
5. 優先度：1（最高優先度）

設定後「Deploy」（デプロイ）。これらのパスを含むリクエストはすべてキャッシュを迂回し、直接オリジンへ。

WordPress サイトの除外リスト例：

/wp-admin
/wp-login.php
/wp-json
/cart
/checkout
/my-account

サイトに合わせて調整してください。

ルール 2：静的リソースをキャッシュ（中優先度）

このルールは任意です。Cloudflare はデフォルトで静的リソースをキャッシュしますが、明示設定すると TTL をより精密に制御できます。

設定手順：

1. Rule name：Cache Static Assets
2. When incoming requests match：
   • Field は「File extension」
   • Operator は「is in」
   • Value：jpg png gif css js woff woff2 ttf svg ico（スペース区切り）
3. Then：
   • Cache eligibility で「Eligible for cache」
   • Edge cache TTL で「Use cache-control header if present, use default Cloudflare caching behavior if not」
4. 優先度：2

静的リソースはオリジンの Cache-Control を優先。未設定なら Cloudflare デフォルト TTL（ファイル種別により 4 時間〜1 ヶ月程度）。

ルール 3：それ以外をすべてキャッシュ（最低優先度）

本命です。HTML を含む残りすべてをキャッシュします。

設定手順：

1. Rule name：Cache Everything Else
2. When incoming requests match：
   • 「All incoming requests」（すべてのリクエスト）
   • より精密にしたい場合は「Custom filter expression」で特定パスを除外
3. Then：
   • Cache eligibility で「Eligible for cache」
   • Edge cache TTL で「Ignore cache-control header and use this TTL」
   • 期間：7 days（1 週間）
4. 優先度：3（最低優先度）

なぜ 1 週間？ バランスの取れた値。短すぎ（1 日など）るとキャッシュ効果が薄い。長すぎ（1 ヶ月など）ると更新反映が遅い。ブログ・ドキュメントサイトなら 1 週間が妥当。

無料版の注意：無料アカウントの最短 TTL は 2 時間、Pro は 1 時間。更新頻度が高いなら短めに。

ルール実行順序が重要

Cloudflare は優先度の小さい順に実行：

1. ルール 1（優先度 1）：管理画面か確認、該当なら Bypass
2. ルール 2（優先度 2）：静的リソースか確認、該当なら適切な TTL でキャッシュ
3. ルール 3（優先度 3）：残りすべてを 1 週間キャッシュ

管理画面は確実にキャッシュされず、静的リソースは適切な TTL、HTML は 1 週間強制キャッシュ。

設定完了チェックリスト

3 ルール設定後、確認：

• ルール 1 の優先度が最高（数字が最小）
• 管理パスがすべて除外リストに入っている
• ルール 3 の TTL を更新頻度に合わせて調整した
• すべてのルールを Deploy 済み

設定完了！次は Edge TTL の落とし穴を見ていきます。

Edge TTL 設定詳解：これらの落とし穴を避ける

Edge TTL（エッジキャッシュ有効期限）はキャッシュ戦略の核心ですが、間違えやすいポイントでもあります。自分もここで何度かつまずきました。

Edge TTL の 3 モード詳解

Cloudflare の Edge TTL には 3 モードがあり、選び方が重要：

モード 1：Use cache-control header if present, bypass cache if not

• 意味：Cache-Control があれば従い、なければキャッシュしない
• 向いている場面：オリジンで Cache-Control を完璧に設定済み
• 所感：厳しすぎる。小規模サイトは Cache-Control 未設定が多く、実質キャッシュなし

モード 2：Use cache-control header if present, use default Cloudflare caching behavior if not（推奨）

• 意味：Cache-Control があれば従い、なければ Cloudflare デフォルト
• 向いている場面：一部だけ Cache-Control 設定、残りは Cloudflare に任せたい
• 所感：最もバランスが良い。多くのサイトに適する

モード 3：Ignore cache-control header and use this TTL

• 意味：オリジンの指示に関係なく、設定した時間で強制キャッシュ
• 向いている場面：静的サイト、キャッシュ戦略を把握している場合
• 所感：強引だが効果的。HTML 全サイトキャッシュ向き

HTML キャッシュにはモード 3 を推奨。多くのサイトは HTML に Cache-Control 未設定、または安全のため no-cache 設定。モード 1・2 ではキャッシュされない。モード 3 なら強制キャッシュ、シンプル。

TTL の選び方

サイトによって異なります。参考表：

無料版の制限：最短 2 時間。もっと短く設定できない場合はプラン制限です。

自分のブログは 1 週間 TTL。実際の体感は良好——新記事公開後に手動 Purge（後述）すれば、残りの時間は命中率が非常に高い。

よくある設定ミス（自分も経験済み）

ミス 1：管理画面の除外を忘れる

最初は手抜きで「Cache Everything」ルール 1 本だけ作ったら、WordPress 管理画面までキャッシュされました。ログイン時に古いページが表示され、操作後に手動でキャッシュ更新が必要で、かなりつらかった。

対処：必ず先に Bypass ルールを作り、優先度を最高に。

ミス 2：TTL が長すぎて更新が反映されない

KiloClaw - 企業向けマネージド OpenClaw、AI エージェントのオーケストレーションとスマートルーティングを加速

今すぐ始める →広告

一度 TTL を 1 ヶ月にしたら、記事タイトルを変えても訪問者には古いタイトルが表示され続けました。数日後にキャッシュが原因だと気づきました。

対処：更新頻度に合わせて TTL を設定。多いなら短く、少ないなら長く。迷ったら 1 週間から。

ミス 3：Edge TTL と Browser TTL の混同

Edge TTL は CDN ノードのキャッシュ時間、Browser TTL は訪問者ブラウザのキャッシュ時間。独立しています！

• Edge TTL：Cloudflare CDN ノードがオリジンへ新コンテンツを取りに行く間隔
• Browser TTL：訪問者ブラウザが CDN に再リクエストする間隔

Edge TTL だけ設定して Browser TTL を設定しないと、CDN はオリジンに戻らなくても、ブラウザは頻繁に CDN へリクエストし、訪問者体感の速度向上は限定的。

対処：Browser TTL は「Respect origin」（オリジン設定に従う）または 1 日など妥当な値を設定。

手動キャッシュ削除：Purge Cache

コンテンツを更新したら？TTL 期限を待たず手動で消せます。

Cloudflare コンソールで：

1. 「Caching」メニュー
2. 「Purge Cache」エリア
3. 選択肢：
   • Purge Everything：全サイトキャッシュ削除（手っ取り早い）
   • Custom Purge：特定 URL のキャッシュ削除（精密）

通常は Custom Purge で更新したページだけ消します。全削除すると一時的にすべてのリクエストがオリジンへ向かい、サーバー負荷が急増します。

Tips：WordPress なら Cloudflare プラグインを入れると、記事公開時に関連ページのキャッシュを自動 Purge できて便利。

検証と最適化：キャッシュが本当に効いているか確認

設定が終わったら、効いているか確認しましょう。推測ではなくデータで。

方法 1：ブラウザ開発者ツール

最もシンプルで直接的。

1. Chrome（または他ブラウザ）を開く
2. F12 で開発者ツール
3. 「Network」（ネットワーク）タブ
4. サイトのトップページにアクセス
5. Network 一覧で HTML ドキュメント（通常最初のリクエスト）を選ぶ
6. 「Headers」（レスポンスヘッダー）を確認

注目ヘッダー：

cf-cache-status：ここが鍵！取りうる値：

• HIT：キャッシュヒット！CDN から配信、オリジン未使用
• MISS：未ヒット。今回オリジンへ行ったが、内容はキャッシュされる
• DYNAMIC：動的コンテンツ、キャッシュしない（Bypass ルールが効いている可能性）
• BYPASS：明示的にキャッシュ迂回（管理画面のはず）
• EXPIRED：期限切れ。CDN がオリジンへ更新取得

初回は通常 MISS、2 回目は HIT になるはず。ずっと DYNAMIC や BYPASS なら設定に問題。

age：CDN 上でキャッシュされてからの秒数。例：age: 3600 は 1 時間キャッシュ済み。

cache-control：オリジンが設定したキャッシュ戦略。Cloudflare で「Ignore cache-control」モードを使っていても表示されますが、Cloudflare は従いません。

方法 2：curl で検証

コマンドライン派なら curl が手早い：

curl -I https://your-website.com

レスポンスヘッダー全体が表示され、cf-cache-status が HIT か MISS か確認できます。

もっと詳しく見るなら：

curl -svo /dev/null https://your-website.com 2>&1 | grep -i "cf-cache"

Cloudflare 関連ヘッダーだけ表示されます。

方法 3：Cloudflare Analytics でキャッシュ指標

全体効果を見るなら Cloudflare コンソールへ：

1. ドメインを選択
2. 左メニュー「Analytics」
3. 「Caching」タブ
4. 「Cache Hit Ratio」（キャッシュ命中率）を確認

設定前は 30%、設定翌日に 85%、現在は 90% 前後で安定。同程度の伸びなら設定成功。

正常指標の目安：

• キャッシュ命中率：80% 以上を目標
• 帯域節約：明確な減少（多くのコンテンツがオリジンに戻らない）
• リクエスト数：CDN 側が増加、オリジン側が大幅減少

命中率を上げる上級テクニック

まだ足りないなら、これらを試してください：

テクニック 1：キャッシュウォームアップ

新コンテンツの初回アクセスは必ず MISS。ユーザー初回から HIT にしたいなら事前に「ウォームアップ」：

新記事公開後、全ページを自分で一度アクセスして CDN に載せる。またはスクリプトでサイトを自動クロール。

Alibaba Cloud - 開発者向けクラウドの第一候補、Lighthouse サーバー15%OFF、プロジェクトの迅速な立ち上げを支援

15%割引を入手 →広告

テクニック 2：URL 形式の統一

同じページでも URL が違えば別キャッシュオブジェクト：

• https://example.com/page と https://example.com/page? は別
• https://example.com/page と https://example.com/page/ は別

リンク形式を統一し、無駄なキャッシュ MISS を避ける。

テクニック 3：不要な Query String の除去

URL にトラッキングパラメータ（?utm_source=twitter など）があると、パラメータ組み合わせごとに別ページ扱いになり、命中率が大幅に下がります。

Cloudflare の「Query String Sort」機能を Caching 設定で有効にすると、query パラメータをソートしてからキャッシュし、ある程度命中率が上がります。

より良い方法は Cloudflare Transform Rules で内容に影響しない query パラメータを剥がすこと。

よくある問題のトラブルシュート

問題 1：cf-cache-status がずっと DYNAMIC

考えられる原因：

• オリジンの Cache-Control が no-cache または private
• Cache Rule のマッチ条件が合っておらず、「Eligible for cache」に当たっていない

対処：Cache Rules のマッチ条件を確認し、HTML リクエストが含まれるように。モード 3（Ignore cache-control）なら強制キャッシュできるはず。

問題 2：命中率が 50〜60% で足りない

考えられる原因：

• 一部 URL に動的パラメータ付き
• オリジンの特定ヘッダーがキャッシュを阻止
• 設定直後で CDN ノードがまだキャッシュ中

対処：新設定後 1〜2 日待ち、CDN ノードに載る時間を確保。Analytics でどのリクエスト種別の命中率が低いか確認し、個別に最適化。

問題 3：更新後も訪問者に古い内容が見える

考えられる原因：TTL が長すぎる、または Browser Cache もキャッシュしている

対処：公開後に手動 Purge Cache。または自動化プラグイン（WordPress に多数あり）。

まとめ

ここまでの核心ステップを振り返ります：

1. Cloudflare がデフォルトで HTML をキャッシュしない理由：主に安全のため。動的コンテンツや機密ページのキャッシュを防ぐ
2. Page Rules から Cache Rules へ移行：Page Rules は廃止方向。Cache Rules の方が強力で柔軟。「Eligible for cache」が以前の「Cache Everything」に相当
3. Cache Rules を 3 本設定：
   • ルール 1（優先度 1）：管理画面・ログインページを Bypass
   • ルール 2（優先度 2）：静的リソースをキャッシュ
   • ルール 3（優先度 3）：それ以外（HTML）を強制キャッシュ、TTL は 1 週間推奨
4. Edge TTL モードの選択：HTML には「Ignore cache-control and use this TTL」で強制キャッシュ。更新頻度に合わせて期間を調整
5. 効果の検証：開発者ツールで cf-cache-status を確認、Analytics で命中率を確認。目標 80% 以上

自分で設定した後、命中率は 30% から 90% へ、TTFB は 500 ミリ秒から 100 ミリ秒台へ、サーバー負荷は 90% 減りました。効果は明確で、特にアクセスの多いサイトほど顕著です。

今すぐ試してみてください：

1. まず Cloudflare Analytics で現在のキャッシュ命中率を確認
2. 記事の手順どおり Cache Rules を 3 本設定（管理画面の除外を忘れずに！）
3. 1〜2 日待って Analytics で効果を確認

問題があれば確認：

• 管理ページは Bypass されているか？
• Cache Rules の優先度は正しいか？
• Edge TTL モードは適切か？

WordPress なら Cloudflare 公式プラグインの導入を強くおすすめします。記事公開時に自動でキャッシュを消してくれて、かなり楽です。

問題や最適化の経験があれば、コメント欄でぜひ共有してください。みんなで情報交換しましょう！