Cloudflareは、オリジンサーバーが送信するデータを縮小する（オリジンオフロード）ことと、ホストに支払うエグレス料金を削減する（キャッシングとBandwidth Allianceによる）ことの2つの方法で、帯域幅を削減します。核となる仕組みは、エッジキャッシング、リクエストコアレッシング、オンザフライ圧縮です。しかし、ここに落とし穴があります。Cloudflareのダッシュボードは、キャッシュヒットを推定オリジン転送量に対して測定するため、圧縮や階層キャッシュの相乗効果を無視し、節約額の一部しか表示しません。このガイドでは、正確なバイト単位のフローを分解し、実際のサンプルブログ計算を示し、無料プランが魔法のトリックではない理由を説明します。
オリジンからエッジへのフロー：実際にバイトが節約される場所
シドニーのユーザーがあなたのページをリクエストすると、DNS応答はそのユーザーを最寄りのCloudflareポイントオブプレゼンス（PoP）に誘導します。そのエッジノードはキャッシュをチェックします。アセットが古いか存在しない場合、すぐにオリジンを叩くわけではありません。
代わりに、Cloudflareはリクエストコアレッシング（シングルフライトとも呼ばれます）と呼ばれる技術を使用します。最初のリクエストがオリジンフェッチをトリガーし、同時の重複リクエストはその単一の応答を待ちます。2018年、ニュースサイトへのフラッシュトラフィックスパイクがオリジンを溶かすように見えたとき、私はこのことを痛感しました。実際には、オリジンログには9,000のエッジリクエストに対してわずか40の同時接続しか記録されていませんでした。
応答がキャッシュ可能な場合、エッジは返されたTTLでそれを保存します。後続のリクエストはPoPから提供されます。バイトはオリジンから移動せず、階層キャッシングが有効な場合は、親キャッシュ層からも移動しない可能性があります。
このフローについて誰も教えてくれないこと：誤って設定されたCache-Controlヘッダーは、これを静かに無効化できます。かつて私は、静的JSONにprivate, no-storeを送信するLaravel APIを監査したことがあります。Cloudflareはそれに従い、「オレンジクラウド」がアクティブであるにもかかわらず、帯域幅の節約はほぼゼロに落ち込みました。
TCPとTLSのオーバーヘッドを考慮してください。キャッシュミスでも、CloudflareがエッジでTLSを終了するため、あなたが思うほど重くはありません。あなたのオリジンは、何千もの個別のハンドシェイクではなく、多くの訪問者間で再利用される1つの共有接続を見ることになります。この接続多重化は隠れた帯域幅節約です。TLSセッションが少ないほど、重複する証明書交換が減り、プロトコルオーバーヘッドが削減されます。
実際には、私はクライアント向けにホワイトボードでフローをマッピングします：ユーザー → エッジPoP →（キャッシュヒット）提供；または →（ミス）コアレッシング → 親層 → オリジン。親層のステップは、階層キャッシングが大陸間バックホールを静かに削減する場所です。Cloudflareの開発者ドキュメントによると、Tiered Cacheを有効にすると、標準のエッジキャッシング単独の場合と比較して、オリジンリクエストを最大60%削減できます。
Loader.ioでクライアントのサイトをロードテストしようとしたとき、エッジが毎秒5,000リクエストを処理している間、オリジンCPUがフラットのままであることに気づきました。その瞬間、フローが理解できました。Cloudflareは単なるキャッシュではなく、リクエストの漏斗なのです。
帯域幅節約の3つの異なるメカニズム
1. エッジキャッシングとキャッシュヒット率
最も明白なレバーは、300以上の場所から静的アセットを提供することです。しかし、キャッシュヒット率（CHR）は虚栄の指標ではなく、オリジンオフロードを直接決定します。画像とCSSでCHRが90%のブログは、それらのバイトの90%をオリジンで節約します。私が見る間違い：コンテンツが古くなるのを恐れてHTMLを0秒キャッシュし、その後、節約が少ない理由を不思議に思う人々です。
2. リクエストコアレッシング（シングルフライト）
500人のユーザーが同時に新しい記事にヒットした場合、Cloudflareはおそらく1つのリクエストをオリジンに送信します。これがリクエストコアレッシングです。オリジンの帯域幅とCPUを節約します。トレードオフ：運の悪い最初のユーザーはオリジンを待つことになり、オリジンが遅い場合、エッジはタイムアウトすることさえあります。10秒のオリジン応答がエッジで2,000のキューされたリクエストの山を引き起こしたとき、コアレッシングが逆効果になるのを見たことがあります。それでも2,000のオリジンヒットよりはましですが、レイテンシは悪化しました。
3. エッジ圧縮とペイロード最小化
Cloudflareは、クライアントがサポートしている場合、エッジでBrotliまたはGzipを適用します。オリジンを離れるバイトは圧縮されていないかもしれませんが、ユーザーに配信されるバイトは縮小されます。これは、オリジン圧縮も無効にしない限りオリジンの帯域幅を削減しませんが、ユーザーが消費するエグレス帯域幅を大幅に削減します。モバイルにとって重要です。画像が多いサイトでは、PolishまたはImage Resizingを有効にすると、ページあたりのメガバイトを削減できます。Polishを有効にする前に画像固有の利得を定量化したい場合は、画像圧縮節約計算機で簡単な見積もりが得られます。
| メカニズム | 節約が発生する場所 | 典型的な削減量 | 最適な用途 |
|---|---|---|---|
| エッジキャッシング | オリジン + エグレス | 静的バイトの50〜95% | CMSアセット、JS、CSS |
| リクエストコアレッシング | オリジンのみ | スパイク時に最大99% | フラッシュクラウド、新規投稿 |
| エッジ圧縮 | エグレスのみ | テキスト20〜70%、画像30〜80% | HTML、JSON、写真 |
| 階層キャッシング | オリジン + PoP間 | さらにオリジン30〜60%削減 | グローバルオーディエンス |
このマトリックスは、アカウントを監査するときに私が使用するメンタルモデルです。ほとんどの競合他社はこれをすべて「CDNキャッシング」にまとめてしまい、圧縮による節約がアナリティクスで「節約された帯域幅」として表示されないという事実を隠しています。
Bandwidth Alliance：キャッシュではないエグレス割引
Bandwidth Allianceは、参加しているクラウドプロバイダー（Backblaze B2、DigitalOcean、Vultrなど）が、Cloudflareを経由するトラフィックのエグレス料金を免除または大幅に割り引くことに同意するパートナーシップです。これはキャッシングとは別です。すべてのリクエストがオリジンにヒットしても、バイトがCloudflareのバックボーンを経由し、ホストがその出口に対して課金しないため、ホストへのエグレス料金が$0になる可能性があります。
私はこの理由だけで、ビデオプラットフォームをAWS S3からBackblaze B2に移行しました。彼らのエグレスは通常$0.01/GBでした。Cloudflareを前面に配置すると、帯域幅の請求項目は消えました。ただし、Allianceはコンピュートイングレスやリクエスト数をカバーしていません。誰も教えてくれないこと：オリジンが参加プロバイダーでない場合、標準のエグレスを彼らに支払うことになり、Cloudflareの無料プランが魔法のように払い戻すことはありません。
現実的な定量化：非パートナーホストで月1 TBのエグレスサイトの場合、Cloudflareはエグレス料金を$0節約しますが、キャッシングによるオリジン負荷は依然として削減されます。パートナーホストでは、同じ1 TBが$10〜$20の節約になる可能性があります。節約を想定する前に、現在のパートナーリストを必ず確認してください。Backblaze自身のAllianceページは、Cloudflareへの転送がエグレス料金なしであることを確認しています。
Cloudflareダッシュボードが節約について嘘をつく理由
アナリティクスパネルを開くと、「節約された帯域幅」がきれいな青い数字として表示されます。この指標は、（キャッシュから提供されたリクエスト）×（平均オリジン応答サイズ）として計算されます。これは、圧縮、リクエストコアレッシング、および単純なモデルで「キャッシュヒット」に一致しなかったがオリジンに触れなかった階層キャッシュヒットという3つの実際の節約源を無視しています。
CFOにROIを報告しようとしたとき、ダッシュボードの数字である120 GB節約を使用しましたが、実際のオリジンログでは210 GBの削減が示されていました。その差は、HTMLとJSONでのBrotli圧縮によるものでした。CloudflareのUIは、キャッシュされたサイズとキャッシュされていないサイズを比較するため、エッジで縮小されたバイトを「節約」として属性付けしません。
テキストが多いサイトでBrotliを有効にすると、ネットワークインターフェースで測定した場合、ダッシュボードの報告された節約額が2倍になる可能性があることに、ほとんどの人は気づいていません。
もう一つのダッシュボードの盲点：「リクエスト」チャートはキャッシュ済みと未キャッシュを表示しますが、コアレッシングされたリクエストは、オブジェクトが保存されている場合に限り、1件の未キャッシュリクエストとしてカウントされ、多数の「キャッシュ済み」ヒットとして扱われます。群衆雪崩（シンダリングハード）の際には、未キャッシュ1件とキャッシュ済み999件が表示され、99.9%のキャッシュヒット率に見えますが、オリジンが配信したペイロードは依然として1つだけです。これは良いことですが、ダッシュボードの帯域幅の計算式は、キャッシュされたレスポンスがオリジンと同じサイズであると想定し、オリジンが非圧縮データを送信した可能性を無視しているため、過小評価されることがあります。
修正方法：サーバーログからオリジンの帯域幅を前後でエクスポートしてください。それだけが真実のデータです。私は現在、オリジンでvnstatを使用してベンチマークし、Cloudflareの「オリジン帯域幅」サブメトリクス（Caching → Analytics → Cache Performanceの下に埋もれており、トップレベルのカードにはありません）と比較しています。無料プランでは分析もサンプリングされるため、ダッシュボードの数値は推定値であり、台帳ではありません。
現実的な定量化：サンプルブログの内訳
現実的なブログをモデル化しましょう：月間10万ページビュー、平均HTML 80 KB、CSS/JS 200 KB、画像1ページあたり1.2 MB。訪問ごとの合計は約1.48 MBです。CDNなしの場合、オリジンの送信データ量は月間148 GBになります。
- 静的アセット（画像、CSS、JS）=そのうち1.4 MB、動的HTML = 80 KB。
- 静的リクエストの85%がキャッシュ可能で、調整後95%のキャッシュヒット率を想定。
- HTMLは動的に生成されますがコアレッシングされ、オリジンは訪問者ごとではなくURLごとに80 KBを送信します。
Cloudflare無料プランでは、デフォルトのエッジキャッシュに加え、HTMLでのBrotli（80 KB→32 KBのワイヤサイズで約60%削減）と画像のキャッシュ配信により、オリジンの帯域幅は約28 GB（HTMLはコアレッシングで約5 GB、静的キャッシュミス約3 GB、画像最適化オーバーヘッド約20 GB）に低下します。これはオリジン削減率81%です。ホストがBandwidth Allianceに参加している場合、送信料金はほぼゼロになります。
カスタマイズされた予測には、当社のCloudflare帯域幅節約計算機に数値を入力してください。私の経験では、小規模ブログは静的比率を過小評価しがちです。3 MBの画像がある写真ブログでは、画像が支配的でキャッシュが効くため、さらに高い削減率が見込めます。
トレードオフ：Cloudflareのプロキシを動的APIコールに使用する場合、それらのバイトは依然としてオリジンに送信されます。毎秒新しいJSONを取得するシングルページアプリで90%の節約を期待しないでください。上記の例は、主にキャッシュ可能なコンテンツを想定しています。かつてキャッシュ可能なトラフィックがわずか2%の気象APIにコンサルティングしたことがあります。Cloudflareは帯域幅では節約できませんでしたが、レイテンシは改善しました。
Cloudflareが無制限の無料帯域幅を維持する方法（経済性）
よくある質問：「Cloudflareはどうして無制限帯域幅の無料CDNを提供できるのか？」答えは慈善ではありません。Cloudflareは最大級のエニーキャストネットワークを運営し、大規模なピアリング契約を結んでいます。有料プラン（Pro、Business、Enterprise）を利益率を持って販売し、帯域幅の裁定取引を行っています：トランジットはスケールが大きいと安価であり、特にセツルメントフリーピアリングではそうです。無料プランは顧客獲得とDDoSシールドデータのためです。
Cloudflareがネットワーク概要で述べているように、300以上の拠点とISPとの直接相互接続を持っています。これにより、低い限界費用でバイトを配信できます。「無制限」の注意点は利用規約にあります：過度の悪用や非HTMLコンテンツ（例：動画ストリーミング）はプランの制限を引き起こす可能性があります。無料ユーザーが50 TBの動画を配信してスロットリングされたのを見たことがあります。ダッシュボードはスループットが低下するまで警告しませんでした。
したがって、無料モデルは持続可能です。ほとんどの無料サイトは控えめな帯域幅を使用し、ヘビーユーザーはアップグレードするか制限を受けるからです。これは抜け穴ではなく、フリーミアムの正しい実装です。スケールの経済性により、バックボーン全体で配信されるGBあたりのコストは1セントの数分の一であり、セキュリティアドオンやエンタープライズ契約で収益化しています。
高度なエッジケースとトレードオフ
すべてが恩恵を受けるわけではありません。節約が縮小または消滅する4つのシナリオを紹介します：
- 厳密に動的でユーザーごとのレスポンス：すべてのバイトが一意（パーソナライズされたダッシュボード）の場合、キャッシュヒット率は約0%です。コアレッシングは同一の同時リクエストにのみ有効です。
- Cookieが多用されるセッション：Cloudflareは、Cache Everythingとオリジンオーバーライドを設定しない限り、Cookie付きリクエストのキャッシュを無視します。セッションCookieがキャッシュの99%をブロックしていたMagentoストアをデバッグしたことがあります。
- レンジリクエストを伴う大容量ファイルのダウンロード：部分コンテンツはキャッシュ階層をバイパスし、異なるバイトレンジで繰り返しオリジンフェッチが発生する可能性があります。
- TLS 1.3 0-RTTの悪用：レイテンシには優れていますが、エッジのコンピューティングを増加させ、帯域幅ではなく、誤設定されたオリジンが重複ペイロードを送信する可能性があります。
もう一つのトレードオフ：エッジで最大圧縮（Brotliレベル11）を有効にすると、CPU時間が増加し、レイテンシがわずかに上昇する可能性があります。Cloudflareはバランスの取れたレベルを使用しています。TTFBをテストせずに「より多くの圧縮＝無料の高速化」と仮定しないでください。クライアントのサイトで最高圧縮を強制したところ、最初のバイトに15 ms追加されました。許容範囲ですが、無料ではありません。
また、Cloudflare Workersを使用してレスポンスを変換する場合、Cache APIを明示的に使用しない限り、ワーカーが毎回オリジンからフェッチするため、キャッシュが無効になる可能性があります。これはサーバーレス設定でつまずいたサイレントな帯域幅リークです。
節約を最大化するための実践的なチェックリスト
新しいCloudflareゾーンでこの監査フローを使用してください：
- オリジンで静的アセットに
Cache-Control: public, max-age=86400を設定します。Page Rulesだけに頼らないでください。 - Tiered CacheとArgo（予算が許せば）を有効にして、PoP間の往復を削減します。
- Speed → OptimizationでBrotliをオンにし、
curl -I --accept-encoding brで確認します。 - 静的パス（例：
/wp-content/*）のCookieをオーバーライドするCache Ruleを作成します。 - オリジンのログを毎週確認し、Cloudflareの「Origin Bandwidth」メトリクスと比較します。トップレベルの「Bandwidth Saved」ではなく。
これをクライアントのWooCommerceサイトに適用したところ、キャッシュヒット率が22%から78%に2週間で上昇し、DigitalOceanの送信料金が$40から$9に削減されました。ポイントは静的パスからCookieを除去することでした。これはダッシュボードが提案しないステップです。
節約配分フレームワーク（ミニ計算機）
これをオリジン・エッジ節約分配と呼びます。CDNなしの月間オリジン送信量（O）を書き出します。次に推定します：
- 静的比率（S）= 静的アセットのバイト / 総バイト。
- キャッシュヒット目標（C）= 静的コンテンツの期待CHR（例：0.9）。
- 圧縮係数（F）= 1 – 圧縮率（例：テキストのBrotliで0.6）。
オリジン節約 ≈ O × [S × C + (1-S) × coalesce_factor]。Bandwidth Allianceによる送信節約 = パートナーの場合、O × (1 – オリジン節約比率)、それ以外はキャッシュ部分の送信のみ。このフレームワークにより、2つのレバーを分離して考えることができます。自動化されたクイックバージョンについては、Cloudflare帯域幅節約計算機がトラフィックプロファイルに同様の計算を適用します。
これが本当のストーリーです：Cloudflareの帯域幅節約は、単一のスイッチではなく、多層的なメカニズムを通じて機能します。それぞれを理解し、オリジンで測定すれば、ダッシュボードがささやき、サーバーが安心してため息をつく理由が正確にわかります。