CDNを入れているのに帯域コストが下がらないのはなぜか

先に要点

CDN は `入れれば自動で安くなる` 仕組みではなく、キャッシュできて、しかも当たる ときに効きます。
帯域コストが下がらないときは、キャッシュミス、動的配信、短い TTL、大きすぎる配信物 を疑う方が早いです。
CloudFront や Cloudflare を使っていても、オリジンまで毎回取りに行っていれば、オリジン転送も CDN 配信も両方発生 しやすいです。
まず見るべきなのは、`キャッシュヒット率` と `どのリクエストが MISS / BYPASS になっているか` です。

CDN は、表示速度を上げたり、オリジンサーバーの負荷を減らしたりする文脈でよく出てきます。
その延長で、CDN を入れたなら帯域コストも下がるはず と考えやすいです。

でも実際には、CDN を入れても請求があまり下がらないことがあります。
これは CDN が効いていない というより、効く前提を満たしていない ことが多いです。

今回は、なぜ CDN があるのに帯域コストが下がらないのかを、キャッシュの当たり方、オリジン往復、画像や動画の配信設計、料金の見え方に分けて整理します。
前提としての帯域の考え方は帯域コストとは？画像・動画・CDNで請求が膨らみやすい理由とつながりますが、今回は なぜ CDN で下がらないのか を主役にします。

まず前提: CDN は「キャッシュが効いた分だけ」助ける

CDN が強いのは、同じコンテンツを何度も求められるときです。
最初の1回はオリジンから取ってきても、その後はエッジから返せれば、オリジンの負荷も転送量も減らしやすくなります。

逆に言うと、次のようなものは効きにくいです。

毎回内容が変わるレスポンス
ログインユーザーごとに違うページ
キャッシュ禁止ヘッダーが付いた配信
URL が毎回変わるファイル

AWS CloudFront のドキュメントでも、キャッシュヒット率を上げることが CloudFront caches から直接返せる割合を増やす ために重要だと説明されています。
Cloudflare のドキュメントでも、CF-Cache-Status を見れば HIT MISS BYPASS EXPIRED などの状態を確認できます。

つまり、CDN の有無だけではなく、どれだけ HIT しているか が本体です。

下がらない理由1: キャッシュミスが多い

いちばん分かりやすい原因は、単純に MISS が多いことです。
MISS が多いと、毎回オリジンまで取得しに行くので、オリジン側の転送が減りません。

MISS が増えやすい例はこんなものです。

画像 URL に毎回違うクエリが付く
アセットのパス設計が不安定
配信数が少なく、同じファイルが何度も再利用されない
キャッシュを頻繁にパージしている

この状態だと、CDN 自体の配信費はかかるのに、オリジンの転送も減らず、思ったほど安くならない どころか、見え方次第では余計に高く感じることがあります。

下がらない理由2: 動的ページが多い

CDN は静的ファイルと相性がよいですが、動的ページはそのままだと効きにくいです。
たとえば次のようなページです。

ログイン後の管理画面
カートやマイページ
リアルタイムに変わる一覧
ユーザー権限ごとに表示が違う API

こうしたページは、人ごとに内容が違う ので、単純な共有キャッシュに乗せにくいです。
その結果、CDN を通っていても毎回オリジン処理が走り、帯域コストもオリジン負荷もそこまで下がりません。

下がらない理由3: TTL が短すぎる、または no-cache が強い

キャッシュできる設計でも、TTL が短すぎると効果は薄くなります。
すぐ期限切れになれば、実質的に何度も取り直すからです。

よくあるのは次のようなケースです。

Cache-Control が弱い
no-store や private が広く付いている
ステータスコードごとのキャッシュ設計が雑
更新が怖くて TTL を極端に短くしている

Cloudflare のドキュメントでも、レスポンスのキャッシュ状態やステータスコードごとの TTL 設計が整理されています。
更新とのバランスは必要ですが、全部すぐ失効 だと CDN を置いた意味がかなり薄くなります。

下がらない理由4: そもそも配信物が大きすぎる

CDN は転送元を分散したり、オリジン往復を減らしたりできますが、ファイルそのもののサイズは勝手には小さくしません。
元データが大きいままなら、HIT していても 配る量そのもの は大きいままです。

特に効きやすいのは次のようなものです。

高解像度画像をそのまま配っている
動画を直接大きいまま返している
PDF や ZIP が大きい
API が不要な項目を大量に返している

つまり、CDN があるのに高い ときは、キャッシュ以前に 1回あたり何MB出ているか を見る必要があります。
帯域コストは 回数 × 1回の重さ で効くので、片側だけ最適化しても限界があります。

下がらない理由5: CDN とオリジンの両方で課金が見える

AWS の請求で混乱しやすいのがここです。
CloudFront を使うと、CloudFront 側の配信費が見えます。一方で、キャッシュミスならオリジンへの取得も発生します。

ただし AWS の CloudFront 料金ページでは、CloudFront と AWS origin 間の data transfer costs are automatically waived when serving traffic through CloudFront という説明があります。
つまり、AWS オリジン相手なら、CloudFront からオリジンへ取りに行く通信 の見え方は直接インターネット向け転送と違います。

それでも請求全体としては、

CloudFront から利用者への配信
リクエスト課金
そもそもの大きいファイル配信

が残るので、CloudFront にしたのに全体が激減しない のは普通にありえます。

Cloudflare でも、キャッシュが効かなければオリジンまでの fetch が増えますし、配信量自体が大きければゼロにはなりません。

最初に見るべき指標

原因を当てるには、まず次の順で見るのが分かりやすいです。

キャッシュヒット率
MISS BYPASS EXPIRED が多いパス
サイズの大きい配信物
動的ページと静的ファイルの比率
パージ頻度と TTL 設定

CDN があるかどうか ではなく、何が HIT していて、何が毎回オリジンへ行っているか を見た方が、対策に直結します。

じゃあどう見直すべきか

打ち手としては、次の順がやりやすいです。

1. 静的に配れるものを分ける

ログイン画面の HTML まで丸ごとキャッシュしようとするより、まずは画像、CSS、JS、公開ファイルのような 共通で配れるもの を分ける方が効きます。

2. URL とキャッシュヘッダーを安定させる

同じファイルなら同じ URL で返し、更新時だけファイル名やバージョンを変える方が、キャッシュが育ちやすいです。

3. 1回あたりのサイズを下げる

画像圧縮、レスポンス削減、動画配信方式の見直しは、CDN の有無に関係なく効きます。

4. 動的配信は動的配信として割り切る

全部を CDN で解決しようとせず、動的ページはオリジン最適化、静的ファイルは CDN 最適化で分けた方が現実的です。

まとめ

CDN を入れているのに帯域コストが下がらないのは、たいてい CDN が無意味 だからではありません。
キャッシュできない、キャッシュが当たらない、1回あたりが重い のどれか、あるいは複数が重なっていることが多いです。

要するに、見る順番はこうです。

本当に HIT しているか
MISS や BYPASS が多いのはどこか
そもそも配信物が大きすぎないか
動的ページを無理に CDN へ期待していないか

この順で見ると、CDN が悪い のではなく、設計のどこで効いていないか がかなり見えやすくなります。

関連で読むなら、帯域全体の考え方は帯域コストとは？画像・動画・CDNで請求が膨らみやすい理由、請求書の追い方は転送量課金はどこで増える？クラウド請求書で最初に見るべき項目、CDN 自体の基本は CDNとは？何が速くなるのか、どこまで必要なのかを解説がつながります。

参考情報

AWS CloudFront Docs: Caching and availability
AWS CloudFront Pricing: Amazon CloudFront pricing
Cloudflare Docs: Cache responses
Cloudflare Docs: How the Cache works