【仕組み解説】CDNはどうやってWebサイトを速くするのか — 配信・キャッシュ・更新を図解

ひよこ

遠くにあるサイトでも、CDNを使うと速くなるのはなぜ？

ペンギン先生

CDNはContent Delivery Networkの略で、複数の配信拠点からコンテンツを届ける仕組みだよ。大元のオリジンサーバーまで毎回取りに行く代わりに、配信拠点のエッジにあるコピーを使えるんだ。各地の配送拠点から届けるイメージで、通信の待ち時間や大元の負荷を減らせるよ。

ひよこ

自分の住んでいる街のエッジにつながるの？

ペンギン先生

必ず同じ街や地理的に一番近い場所とは限らないよ。たとえばCloudFrontはDNSを通じて、通常は通信の遅延が小さい配信拠点へ案内するんだ。距離だけでなくネットワークの経路なども関係する。CDNによって振り分け方や構成は違うよ。

ひよこ

エッジには、最初からサイト全部のコピーがある？

ペンギン先生

必要になったとき取得する方式が一般的だよ。使えるコピーがあればキャッシュヒットで返し、なければ別のキャッシュ層やオリジンへ取りに行く。保存が許される応答なら、後の要求に備えて保持するんだ。すべての要求がヒットするわけではなく、保存しない応答もあるよ。

ひよこ

一度保存されたら、サイトを更新しても古いまま？

ペンギン先生

期限や再検証、キャッシュの無効化で更新を扱うよ。ファイル名に内容のハッシュなどを付け、変更時にURLも変える方法もある。管理機能でCDNのコピーを無効にしても、利用者のブラウザに保存されたコピーまで消せるわけではないので、更新するHTMLと画像などを分けて考えるんだ。

ひよこ

no-cacheを返せば、CDNは保存しないの？

ペンギン先生

HTTPの基本では、no-cacheは再利用前に検証する指定で、保存禁止はno-storeだよ。CDNの設定も確認しよう。CloudFrontではMinimum TTLを0より大きくすると、オリジンがno-cache・no-store・privateを返しても、その最低期間はキャッシュされることがある。ヘッダーだけ見て安全だとは判断できないんだ。

ひよこ

マイページまで保存されたら、別の人に見えない？

ペンギン先生

共有するべきでない応答を同じコピーとして配ると、漏えいにつながるよ。個人向けのページやAPIは、共有キャッシュの対象から外すなどの設計が必要なんだ。privateなどの応答ヘッダーに加えて、CDNのキャッシュ設定と、同じ内容だと判定するキーを確認しよう。ログイン情報の違いを無視して共有しないことが大切だよ。

ひよこ

CDNを前に置けば、元のサーバーは守られる？

ペンギン先生

キャッシュが使えれば負荷を減らせるけれど、ミスや保存しない要求は元へ届くよ。CDNに備わる防御機能も製品や設定で違うし、オリジンへ直接到達できる経路が残っていれば別に守る必要がある。CDNの導入だけで、認証やアクセス制御、障害対策が不要になるわけではないんだ。

ひよこ

導入後は、何を見れば効果が分かる？

ペンギン先生

利用者が待つ時間、転送量、キャッシュのヒット率、オリジンへの要求数を見るとよいね。さらに、更新した内容が届くか、ログイン利用者ごとの応答を混ぜていないかも確かめる。速さと正しい内容の配信をセットで確認するのが大切なんだ。

更新するものによって方針を分ける

図は配信経路の簡略図で、リクエストのたびに世界中へ複製するという意味ではありません。CDNの無効化処理の反映時間、料金、キャッシュキーやTTLの優先順位はサービスごとに確認します。この記事ではCloudFrontの公式資料を具体例にしていますが、すべてのCDNが同じ設定を持つわけではありません。

次に読む：キャッシュの鮮度と再検証。

参考資料

確認日：2026年9月21日。

• AWS — How CloudFront delivers content — 遅延を基にした配信拠点の選択、ヒット・ミス、リージョンキャッシュとオリジンの関係。
• AWS — Manage content expiration — Cache-ControlとTTL設定、Minimum TTLが正の場合のno-cache・no-store・privateへの影響。
• AWS — Invalidate files to remove content — 無効化とファイル名のバージョニング、ブラウザなどに残るキャッシュの違い。
• RFC 9111 — HTTP Caching — 共有キャッシュとprivate、再検証とno-cache、保存禁止のno-store。