速度向上のためのCloudflare CDNキャッシュ戦略の最適化

堅牢なCloudflare CDNキャッシュポリシーの構成は、2026年にエンタープライズのウェブサイトの速度を最適化するうえで最も効果の高いエンジニアリング作業の一つです。多くのWebプラットフォームは、ページをレンダリングするためにすべてのユーザーリクエストがオリジンのデータベースサーバーまで到達しなければならないため、高いレイテンシに悩まされています。このオリジンへの依存はFirst Contentful Paint（FCP）およびLargest Contentful Paint（LCP）の速度指標を遅延させますが、静的なページレイアウトやアセットコンポーネントを世界中のエッジロケーションに保存すれば、最寄りのエッジロケーションから高速で低遅延の応答を配信できます。本ガイドでは、キャッシュの仕組み、Edge Cache TTLルール、動的なCookieバイパスの設定を分解して解説します。

[!TIP] キャッシュ最適化のヒント: ログイン中のユーザー情報を含むHTMLページをキャッシュしないようにしてください。リクエストヘッダーに特定のセッションCookie（WordPress CookieやカスタムのAuthトークンなど）が検出された場合にエッジキャッシュをバイパスするよう、常にCache Rulesを構成してください。

要点:

• Cloudflare CDNキャッシュはバックエンドサーバーのデータベースクエリを削減し、ホスティングコストを削減します。
• Cache Rulesを使うと、開発者はコンテンツタイプやディレクトリに基づいてカスタムのTTL値を設定できます。
• Cache Everythingルールの導入では、ユーザーデータの漏洩を防ぐためにセッションCookieのバイパス設定が必要です。
• 静的ページをエッジロケーションから直接配信することは、モバイル端末でCore Web Vitalsに合格するのに役立ちます。

キャッシュ構成: Page Rules と Cache Rules

配信パイプラインを最大限に活用するには、適切なダッシュボードの制御モデルを選択する必要があります。Cloudflare Developer Docs のキャッシュに関するガイドラインによれば、従来のPage RulesはモジュラーなCache Rulesに置き換えられつつあります。したがって、開発者は次の構成を実装すべきです:

デフォルトでは、CDNネットワークはメディア形式、スタイルシート、スクリプトのみをキャッシュします。そのため、3つの中核的なアセットオプションを構成する必要があります:

• HTMLキャッシュ: 瞬時のページ読み込みを実現するには、HTMLドキュメント構造をキャッシュするようCDNに指示する必要があります。これによりデータベースクエリが停止します。
• Cache-Controlヘッダー: SymfonyまたはPHPのバックエンドサーバーが、ページを保存する期間をエッジサーバーに指示するカスタムのs-maxageディレクティブを送信するように構成します。さらに、これによりカスタムのTTLルールが可能になります。
• ブラウザキャッシュTTL: サイトのレイアウトを変更したときにユーザーが更新を受け取れるよう、より短いブラウザキャッシュの有効期間（例: 4時間）を設定します。その結果、レイアウトの不一致の問題を防ぎます。

インタラクティブなWebポータルでは、すべてのページを一律にキャッシュすることはできません。したがって、2つの動的なバイパスルールを確立する必要があります:

• セッションバイパス: リクエストに認証またはセッションのCookieが含まれる場合にキャッシュをバイパスするようCDNに指示するルールを作成します。これにより、ログイン済みのユーザーは常にパーソナライズされた応答を受け取り、匿名の訪問者は引き続きエッジキャッシュから配信されます。
• クエリ文字列の並べ替え: キャッシュキーを評価する際に、軽微な分析用変数（UTMタグなど）を無視するようエッジデータベースキャッシュを構成します。その結果、キャッシュの断片化を防ぎます。

エンタープライズのエッジキャッシュ戦略を安全に展開するには、この技術的な検証シーケンスを進めてください。次の4つの最適化ステップを採用します:

1. HTTPヘッダーを監査する: オリジンサーバーが認証ブロックなしでクリーンなCache-ControlおよびVaryヘッダーを送信していることを確認します。
2. モジュラーなCache Rulesを作成する: 静的なカテゴリディレクトリを最大30日間保存するよう、対象のCache Rulesを構成します。
3. 認証の例外を作成する: ログインCookieが検出されたときにエッジキャッシュをバイパスするルールを作成します。
4. Purge APIのWebhookを展開する: ページを更新したときに自動化されたPurge APIリクエストをトリガーするよう、データベースの保存アクションを構成します。

パフォーマンス比較: エッジキャッシュ と オリジンフェッチ

速度面の利点を示すため、次の表に実際の読み込み指標を詳しく示します:

前提条件

ダッシュボードに触れる前に、次のものが整っていることを確認してください:

• すでにCloudflare経由でプロキシされているドメイン（グレー/DNSのみではなく、オレンジクラウドのDNS設定）。
• レスポンスヘッダーを設定できるよう、オリジン構成（Nginx、Apache、またはアプリケーション層）へのアクセス。
• パージを自動化する予定がある場合は、Zone → Cache PurgeにスコープされたAPIトークン。My Profile → API Tokensで作成します。
• 生のHTTPヘッダーを検査する手段: コマンドラインのcurl、またはChrome DevToolsのNetworkタブ。
• サイト全体に展開する前に試せる、ステージングURLまたは低トラフィックのパス。

以下のすべてのステップを実行するにはFreeまたはProプランで十分です。Cache Rulesはすべてのプランで利用できますが、一部のキャッシュキーのオプションとTiered Cacheは上位ティアに限られます。

ステップ1: オリジンから正しいCache-Controlヘッダーを送信する

Cloudflareは、オリジンが積極的に禁止していない場合にのみ、レスポンスをキャッシュ可能として扱います。HTMLが決してキャッシュされない最も一般的な理由は、オリジンがすべてのリクエストでSet-Cookieヘッダーまたは制限的なCache-Controlを返していることです。

オリジンで明示的なディレクティブを設定します。Nginxの場合:

1location ~* \.(css|js|woff2|jpg|png|webp|svg)$ {
2    add_header Cache-Control "public, max-age=31536000, immutable";
3}
4
5location / {
6    # HTML: short browser life, long shared (edge) life
7    add_header Cache-Control "public, max-age=0, s-maxage=86400";
8}

s-maxageディレクティブはCloudflareエッジのような共有キャッシュを対象とし、一方max-age=0は訪問者のブラウザに再検証を続けさせるため、デプロイ後に古いHTMLが表示されることはありません。フィンガープリント付きアセットのimmutableトークンは、ブラウザにそれらを一切再検証しないよう指示します。

アプリケーション駆動のレスポンス（PHPまたはSymfony）では、同じ意図をコードで表現します:

1$response->setPublic();
2$response->setMaxAge(0);            // browser
3$response->setSharedMaxAge(86400);  // edge / s-maxage

認証済みまたはパーソナライズされたレスポンスは明示的にオプトアウトする必要があります。そうしないと、範囲の広いルールがあるユーザーのページを別のユーザーに配信してしまう可能性があります:

1Cache-Control: private, no-store

ステップ2: Cache RuleでHTMLをキャッシュ対象にする

デフォルトでは、CloudflareはHTMLをDYNAMICとしてマークし、決して保存しません。これを変更するには、Caching → Cache Rules → Create ruleでルールを作成します。

動的なものをすべて除外しつつ、キャッシュしたいページに一致する式を記述します:

1(http.host eq "example.com"
2  and not starts_with(http.request.uri.path, "/wp-admin")
3  and not starts_with(http.request.uri.path, "/cart")
4  and not starts_with(http.request.uri.path, "/checkout")
5  and not starts_with(http.request.uri.path, "/my-account"))

次に、ルールのアクションを設定します:

• Cache eligibility: Eligible for cache – 古い「Cache Everything」の動作に相当する最新の設定です。
• Edge TTL: Use cache-control header if present を選び、ステップ1で設定したs-maxageが優先されるようにします。ヘッダーがない場合は1日などの固定値にフォールバックします。
• Browser TTL: Respect origin。

ステップ3: ログインユーザーが決してキャッシュされないようCookieバイパスを追加する

これはほとんどのガイドが省略するステップであり、省略するとデータが漏洩するステップです。適格性ルールの上に配置する2つ目のルールを追加し、本物のセッションCookieが存在するときは常にバイパスを強制します。CloudflareはCache Rulesを上から下へ評価するため、より前にあるバイパスルールは認証済みの訪問者に対して常に優先されます。

1http.cookie contains "wordpress_logged_in_"
2or http.cookie contains "wp-postpass_"
3or http.cookie contains "woocommerce_items_in_cart"
4or http.cookie contains "comment_author_"

アクションをBypass cacheに設定します。WordPress以外のスタックでは、Cookie名をフレームワークのセッション識別子（PHPSESSID、laravel_session、connect.sidなど）に置き換えます。範囲を厳密に絞ってください。ここで_gaのような広範な分析用Cookieに一致させると、すべての匿名訪問者に対しても誤ってキャッシュがバイパスされてしまいます。

ステップ4: キャッシュキーを正規化する

トラッキングパラメーターだけが異なる2つのURLは、1つのキャッシュオブジェクトを共有すべきです。適格性ルール内でCache Key → Query Stringを開き、Ignore specific query string parametersを選択して、分析用のキーを列挙します:

1utm_source, utm_medium, utm_campaign, utm_term, utm_content, fbclid, gclid

これにより/pricing?utm_source=newsletterと/pricing?gclid=123が単一のキャッシュエントリにまとめられ、ヒット率を数千のほぼ重複したキーに断片化させる代わりに向上させます。

キャッシュのHITまたはMISSを確認する方法

ルールが機能していると決めつけず、必ず測定してください。Cloudflareが配信するすべてのレスポンスにはcf-cache-statusヘッダーが付いています。同じURLを2回リクエストし、その変化を観察します:

1curl -sI https://example.com/ | grep -i cf-cache-status
2# First request:  cf-cache-status: MISS
3# Second request: cf-cache-status: HIT

遭遇する値と、それぞれの意味は次のとおりです:

常にDYNAMICしか表示されない場合、適格性ルールが発動していません。式内のホスト名を確認し、続いてオリジンがHTMLドキュメントでCache-Control: privateやSet-Cookieを送信していないか確認してください。

よくある落とし穴とトラブルシューティング

• すべてのレスポンスにSet-Cookieがある。 Cloudflareは、Cookieを設定するレスポンスをキャッシュしません。分析プラグイン、CSRFトークン、A/Bテストツールは、HTMLドキュメントに頻繁にCookieを付与します。そのロジックを非同期リクエストに移すか、キャッシュ可能なパスでヘッダーを削除してください。
• 匿名訪問者に対するBYPASS。 ほぼ常に、範囲が広すぎるCookieバイパスルールが原因です。_gaのような汎用的なCookieが式に一致しています。バイパスを本物のセッションCookieのみに制限してください。
• デプロイ後の古いページ。 Edge TTLは役割を果たしています。単にパージを忘れているだけです。TTLを数秒に短縮するのではなく、公開時に対象を絞ったパージをトリガーしてください。
• Varyヘッダーが無視される。 CloudflareはAccept-Encodingでのみキャッシュを分岐します。任意のVary: User-AgentやVary: Cookieのために別々のコピーを保持することはありません。Varyに頼るのではなく、レスポンシブCSSやWorkerを介してデバイス固有のマークアップを配信してください。
• Development Modeが有効のまま。 これは3時間キャッシュをバイパスし、すべてのレスポンスを密かにキャッシュ不可のように見せます。テストの前にオフになっていることを確認してください。

本番環境の考慮事項と自動パージ

単一のパスが正しく動作するようになったら、低トラフィックの時間帯にルールをサイト全体へ拡大し、Caching → Overviewでヒット率を監視します。健全な静的サイトなら余裕を持って90%を超えます。

ゾーン全体ではなく変更された部分だけをパージするようCMSを接続します。URL単位で対象を絞ったパージは、隣接するページをキャッシュ内で温かい状態に保ちます:

1curl -X POST \
2  "https://api.cloudflare.com/client/v4/zones/${ZONE_ID}/purge_cache" \
3  -H "Authorization: Bearer ${CF_API_TOKEN}" \
4  -H "Content-Type: application/json" \
5  --data '{"files":["https://example.com/pricing"]}'

これを公開フックから呼び出せば、編集者の更新が数秒以内に公開される一方で、それ以外はすべてキャッシュされたままになります。大規模なカタログの場合は、関連するURLをCache Tag（Enterprise）の背後にまとめるか、プレフィックス単位でパージし、Tiered Cacheを有効にして、MISSがオリジンに到達する前に地域の親を経由させることでグローバルなヒット率を高めます。

実績ある英国のCloudflareコンサルタントと提携する

これらのキャッシュに関する判断を正しく行うことで、オリジンサーバーを保護し、すべての訪問者に対するページ配信を高速化できます。Mecanikは、技術的SEO監査 のプロフェッショナルサービスと、Web開発 ページを通じたインフラのスケーリングを提供しています。当社はSymfonyのエッジ統合、カスタムのCloudflare Cache Rules、エッジネイティブなデプロイを専門としています。技術スコーピングワークショップのご予約は、今すぐお問い合わせください。

よくある質問(FAQ)

Cloudflare CDNキャッシュとは何ですか？ Cloudflare CDNキャッシュとは、ウェブサイトのページ、画像、スクリプトファイルの静的なコピーを世界中に配置されたエッジサーバーに保存するプロセスです。この構成により、ユーザーのリクエストを最も近い物理サーバーから配信でき、ウェブサイトの読み込み時間を短縮します。

ユーザーデータを漏洩させずにHTMLページをキャッシュするにはどうすればよいですか？ HTMLを安全にキャッシュするには、リクエストヘッダーにセッションCookieまたは管理者Cookieが存在するときに発動する「Bypass Cache」アクションを備えたCache Ruleを構成します。この設定により、ログイン中のポータルユーザーは常にオリジンのデータベースから動的コンテンツを取得します。

Edge TTLとBrowser TTLの違いは何ですか？ Edge TTL（Time-To-Live）は、Cloudflare CDNサーバーがコンテンツを保存してから、オリジンサーバーに新しいコピーを要求するまでの期間を決定します。一方、Browser TTLは、訪問者のローカルブラウザキャッシュがファイルを保持する期間を決定します。

なぜクエリ文字列のキャッシュがウェブサイトのパフォーマンスに影響するのですか？ クエリ文字列（UTMトラッキングタグなど）が正規化されていない場合、CDNは各バリエーションを一意のURLとして扱い、オリジンサーバーへの重複したリクエストを生成します。キャッシュキーの正規化を構成すると、このクロールの重複を防げます。

エッジキャッシュはCore Web Vitalsのスコアを改善できますか？ はい、HTMLとメディアアセットをエッジサーバーから直接配信することで、Time-to-First-Byte（TTFB）とLargest Contentful Paint（LCP）の時間が最小化されます。その結果、このキャッシュ戦略はモバイルのページ速度ランキングを直接的に改善します。