CDN（Content Delivery Network）は、WebサイトやAPI、動画、ファイル配信を支える「中継レイヤー」です。キャッシュヒットではオリジンサーバーへの通信を省き、キャッシュしないリクエストでもTLS終端、WAF、レート制限、経路最適化などを適用できます。ただし、設定を誤ると古い情報の配信、個人情報の混在、費用増加、SEO上のクロール障害を招くため、導入よりも設計と検証が重要です。
CDNは「利用者とオリジンの間に置く分散配信・制御レイヤー」
CDNの価値は、すべてのデータを最寄りのサーバーへ複製することではありません。どのリクエストを同じ応答として扱うか、何秒まで古くてよいか、オリジンへ誰を通すかをルール化し、利用者に近い拠点で処理できる通信を増やすことです。
CDNとは？意味と構成要素をわかりやすく整理
CDN（Content Delivery Network、コンテンツ配信ネットワーク）とは、利用者と本来の配信元であるオリジンサーバーの間でHTTPリクエストを受け、分散した拠点からコンテンツを配信・中継する基盤です。公開ドメインのDNSをCDNへ向けると、利用者のリクエストは遅延や経路、障害、容量などを考慮して処理拠点へ送られます。
CDNの中心的な機能は共有キャッシュですが、それだけではありません。製品や契約によって、TLS終端、HTTP/2・HTTP/3、圧縮、画像変換、WAF、DDoS対策、bot管理、レート制限、エッジコード、ログ、署名URLなどを提供します。したがって、「CDN＝キャッシュサーバー」ではなく、「キャッシュを含む分散リバースプロキシ基盤」と考えると理解しやすくなります。
オリジンサーバー
正規のコンテンツやアプリケーション応答を作る上流です。Webサーバー、ロードバランサー、オブジェクトストレージ、APIなどが該当します。
エッジ・POP
利用者からの通信を受ける分散拠点です。保存済み応答の配信、TLS、圧縮、ルール、セキュリティ処理などを行います。
キャッシュ
以前のHTTP応答を保存し、条件を満たす次回リクエストへ再利用する仕組みです。ブラウザキャッシュとCDNの共有キャッシュは別物です。
リバースプロキシ
利用者の前面でリクエストを受け、上流へ転送する役割です。CDNのedgeもリバースプロキシとして動きますが、単一拠点のproxyがCDNとは限りません。
CDN・キャッシュ・DNS・ロードバランサーの違い
| 用語 | 主な役割 | CDNとの関係 |
|---|---|---|
| CDN | 分散した拠点でコンテンツを配信・中継し、経路・キャッシュ・セキュリティを制御 | 利用者とoriginの間に置く配信レイヤー |
| キャッシュ | 保存した応答や計算結果を再利用 | CDNの主要機能の一つ。browser、application、databaseにも存在 |
| DNS | ドメイン名を接続先へ解決 | 利用者をCDNへ向ける入口。DNS自体はWeb本文を配信しない |
| ロードバランサー | 複数backendへリクエストを振り分ける | 多くはorigin側のアプリケーションを分散。CDNのedge配信とは層が異なる |
| Webホスティング | Webサーバー、ストレージ、実行環境を提供 | CDNのoriginになり得る。CDN導入後も保守・backup・capacityは必要 |
| WAF | 不正なHTTP通信を検知・遮断 | CDNに統合される場合があるが、ルール設計と誤検知対応は別途必要 |
CDNの仕組み：リクエストからcache hit・missまで
CDNの仕組みは、リクエストの入口、キャッシュキーの作成、保存済み応答の鮮度判定、オリジン取得、応答の保存という順に追うと理解できます。以下は一般化した流れであり、regional cacheやtiered cacheなどの中間層は製品によって異なります。
DNS・経路制御でCDNのedgeへ到達
利用者がURLへアクセスすると、公開ホスト名のDNS設定やCDN事業者の経路制御により、リクエストを処理するPOPへ到達します。HTTPSでは利用者とedgeの間でTLS接続が確立されます。
リクエストからcache keyを作る
CDNはhost、pathを基本に、設定したquery string、header、cookie、methodなどを組み合わせてcache keyを作ります。同じkeyは「同じ応答として扱う」という意味です。
保存済み応答が新鮮ならHIT
同じkeyの応答が保存され、TTL内などの条件を満たしていればedgeから返します。originへの往復がなくなるため、遅延と上流負荷を減らせます。
なければMISS、期限切れなら再検証
保存済み応答がなければ上位cacheまたはoriginへ取得します。期限切れでもETagやLast-Modifiedを使って再検証し、304 Not Modifiedなら保存済みbodyを再利用できます。
条件を満たす応答を保存し、利用者へ返す
originから届いたstatus、header、bodyを利用者へ転送し、cacheabilityとTTLの条件を満たす場合は次回のために保存します。Set-Cookie、Authorization、status code、object sizeなどの扱いは実装と設定を確認します。
具体例：1,000件のうち850件がHITした場合
次の数字は仕組みを理解するための説明例です。実際のダッシュボードでは、キャッシュ対象だけを分母にするか、BYPASSやREVALIDATEDをどう数えるか、多段cacheをどこで測るかが製品ごとに異なります。
850 HIT ÷ 1,000 eligible requests = 85%キャッシュ対象1,000件のうち850件が有効なedge cacheから返った例です。hit率だけでなく、HIT時とMISS時の応答時間も分けて見ます。
1 − (150 origin requests ÷ 1,000 viewer requests) = 85%850件ではoriginへ届かなかったと仮定した単純計算です。tiered cache、request collapsing、subrequestがあると、非HIT数とorigin要求数は一致しません。
cache key・TTL・Cache-ControlがCDN設計の中心
CDNの成否を決めるのは拠点数よりも、何を同じ応答として扱うかを決めるcache keyと、いつまで再利用してよいかを決めるTTLです。ここを曖昧にすると、同じ利用者向けの応答が細かく分かれてHIT率が落ちるか、異なる利用者の応答が混ざるかのどちらかが起こります。
cache keyには「応答を本当に変える値」だけを含める
- 基本：host、path、必要なquery stringを基準にする
- 含める候補：language、currency、tenant、画像formatなど、originの応答を変える値
- 避けたい候補：一意のsession ID、追跡用query、膨大な種類のUser-Agentなど、不要な細分化を生む値
- 認証後ページ：Authorizationやsession cookieを無視して共有しない。原則BYPASSとし、共有する場合は厳密に分離する
主要なCache-Controlディレクティブ
| 指示 | 主な意味 | 実務上の注意 |
|---|---|---|
max-age | 応答を新鮮とみなす秒数 | browserと共有cacheの双方に影響。共有cacheだけ別にしたい場合はs-maxage等を検討 |
s-maxage | 共有cache向けの鮮度時間 | CDNではmax-ageより優先される。事業者の実装と上書きルールを確認 |
public | 共有cacheで保存可能と明示 | 認証付き応答を共有する場合は、内容が本当に全員共通か厳密に確認 |
private | 共有cacheでは保存しない | browserなど私的cacheでの保存は許容し得る。機密情報はno-storeも検討 |
no-cache | 再利用前に再検証を要求 | 保存禁止ではない。ETagやLast-Modifiedと組み合わせると304でbodyを再利用できる |
no-store | 保存を禁止 | 個人情報、決済、機密性の高い応答で検討。CDNルールが上書きしないか確認 |
must-revalidate | staleな応答を無断で再利用しない | origin障害時に古い応答を返したくない重要情報に使うが、可用性とのトレードオフ |
stale-while-revalidate | 再検証中に一定時間stale応答を返す | 応答待ちを減らせるが、製品の実装差と重要情報の陳腐化を評価 |
stale-if-error | origin error時に一定時間stale応答を許容 | 障害時の閲覧継続に使えるが、価格・在庫・法令情報では慎重に設定 |
immutable | 鮮度期間中は内容が変わらないと示す | 内容ハッシュ付きCSS・JS・画像など、URLがversionごとに変わる資産と組み合わせる |
RFC上の意味とCDN製品の既定動作は分けて確認します。CDN側のCache Rules、minimum TTL、status code TTLなどがoriginのヘッダーを上書きする場合があります。
用途別のヘッダー例
# 内容ハッシュ付き静的ファイル
Cache-Control: public, max-age=31536000, immutable
# 公開HTML：browserは5分、共有CDNは1時間
Cache-Control: public, max-age=300, s-maxage=3600
ETag: "page-v42"
# 個人情報を含む認証後ページ
Cache-Control: private, no-store例は出発点です。更新要件、事業者のルール、ブラウザcache、再検証、stale許容を含めてテストしてください。
CDN-Cache-ControlとCache-Statusも押さえる
RFC 9213では、一般のCache-Controlとは別にCDNなど特定の共有cacheへ指示を出す考え方と、CDN-Cache-Controlヘッダーが定義されています。browserのTTLとCDNのTTLを分けたいときに有用ですが、利用するCDNが対応しているか、独自ヘッダーとの優先順位を確認します。
RFC 9211のCache-Statusは、cacheがリクエストをどう扱ったかを標準化された形式で示すヘッダーです。すべてのCDNが常時付与するわけではないため、実際にはAge、Via、CF-Cache-Status、X-Cacheなど製品固有のヘッダーやログも併用します。
CDNを導入する5つのメリット
CDNのメリットは「サーバーが近くなる」だけではありません。キャッシュヒットでorigin処理を省くこと、接続や圧縮をedgeで最適化すること、急増した通信を分散することが組み合わさって効果が生まれます。
表示・ダウンロードを高速化しやすい
利用者に近いedgeから応答し、originへの往復を省くことで、画像、CSS、JavaScript、公開HTML、動画などの待ち時間を短縮できます。
originのCPU・帯域・接続数を減らせる
同じ応答をedgeで再利用すれば、Webサーバー、ストレージ、API、データベースへ届く要求と転送量を減らせます。
アクセス急増を吸収しやすい
ニュース掲載、キャンペーン、動画公開、ソフトウェア配布などで同じコンテンツへアクセスが集中した際、分散拠点で処理できます。
一部の公開コンテンツを障害時も返せる
stale配信を許容した公開GETでは、originが一時的に応答できないときに保存済み内容を返せる場合があります。完全な障害対策ではありません。
攻撃をoriginの前で制御しやすい
WAF、DDoS対策、bot管理、レート制限、TLS終端をedgeで適用し、originの公開範囲を狭められます。
効果はHITする通信に偏る
cold cache、個人別API、POST、書き込み、認証、database処理はoriginへ依存します。CDN導入後も上流の性能・冗長化・監視は必要です。
CDNのデメリット・導入時の注意点
CDNは便利ですが、通信経路と状態を一層増やします。導入前より速くなっても、更新・障害・セキュリティの切り分けが難しくなるため、メリットだけで判断しないことが大切です。
古い情報が残る
TTL、browser cache、edge cache、regional cacheが重なり、更新後も古いHTMLや画像が表示されることがあります。versioned URL、再検証、対象を絞ったpurgeを設計します。
個人情報が混ざる危険
session、tenant、Authorization、Cookieを無視した共有cacheは重大な情報漏えいにつながります。認証後ページは原則bypassし、別userでの試験を必須にします。
MISS時は経路が増える
利用者→CDN→originとなるため、cacheできない通信ではedge処理や接続の分だけ遅くなる場合があります。動的APIは実測で判断します。
費用が読みにくい
転送量、request、function、WAF、log、purge、専用IPなど課金軸が増えます。攻撃やhotlink、cache-busting queryでも費用が増える可能性があります。
障害点・設定点が増える
CDN自身の障害、DNS、証明書、WAF誤遮断、設定反映、global purgeなどが追加されます。bypass・rollbackと権限管理が必要です。
製品ごとの用語差が大きい
HIT、MISS、BYPASS、DYNAMIC、EXPIRED、STALE、UPDATINGなどの定義が異なります。ダッシュボードの分母とログ仕様を公式文書で確認します。
CDNに向くコンテンツ・共有キャッシュしない通信
拡張子だけで判断せず、同じcache keyの利用者へ同じ応答を返してよいか、何秒古くてもよいか、認証・個人情報に依存するかで分類します。
CDNとSEOの関係：順位を直接上げる機能ではない
CDNを使うだけで検索順位が上がるわけではありません。速度と可用性が改善すれば、ユーザー体験やクロールの安定へ間接的に寄与する可能性はありますが、コンテンツ品質、検索意図への適合、index可否、canonical、HTTP status、内部リンク、レンダリングが正しいことが前提です。
Google Search Centralは、CDNをoriginと利用者の間に置く中継として説明し、CDN利用自体を問題としていません。一方で、cold cacheではGooglebotの最初の取得がoriginへ到達することがあり、クロール急増時にはorigin容量にも注意が必要です。HTTP cachingを適切に使えば、再取得の効率化や配信負荷の低減につながります。
CDN導入・移行時のSEOチェック
- status：通常ページは200、移転は適切な301・308、存在しないURLは404・410を返す
- robots：robots.txt、noindex、X-Robots-TagをCDNルールやerror pageで誤って変更しない
- canonical：CDN用ホスト名ではなく公開する正規URLを示し、Host headerとredirectを確認する
- crawler遮断：WAF・bot対策・rate limitがGooglebotや主要crawlerを誤遮断しない
- error cache：一時的な5xxや403を長時間cacheしない。復旧後に古いerrorが残らないか確認する
- rendering：CSS、JavaScript、画像、fontが403・CORS・署名期限切れにならず、モバイルでも読み込める
- 速度：HITだけでなくcold cache、HTML、LCP画像、第三者script、origin応答も測定する
CDNのセキュリティ：WAFだけでなくorigin保護とcache境界を見る
CDNは攻撃通信をoriginの前で受けられるため有力な防御層ですが、導入しただけで安全になるわけではありません。CDNを迂回してoriginへ直接アクセスできれば、WAFやrate limitを回避される可能性があります。
利用者→edge、edge→originをHTTPSにする
viewer側だけでなくorigin側もTLSで保護し、証明書名、SNI、Host header、redirect、TLS versionを確認します。
origin直アクセスを制限する
OAC、署名付きrequest、mTLS、認証済みcustom header、firewall allowlist、private networkなど、対応方式でCDN以外の経路を閉じます。
private contentは署名と期限を設計する
署名URL・Cookie、権限失効、cache key、Range request、download再開を合わせて確認し、URL漏えい時の影響を限定します。
cache poisoning・deceptionを試験する
keyに入らないheaderやpath解釈差を悪用して有害な応答を共有させたり、認証ページを静的ファイルのように見せて保存させたりする攻撃を想定します。
DDoS対策として期待できること・できないこと
CDNは大規模ネットワークで通信を吸収し、既知の攻撃をedgeで遮断し、HITする静的要求をoriginへ送らないことで耐性を高められます。しかし、認証APIや検索などoriginで高コスト処理を行うL7攻撃、cache-busting、正規ユーザーに似たbot、攻撃時の従量課金は別途対策が必要です。
CDNを安全に導入する7ステップ
最初から全URLをcacheせず、観測しやすい静的ファイルから段階的に広げます。変更前後でURL、body、header、status、latency、origin request、費用を比較し、異常時にbypassまたはrollbackできる状態を作ります。
1. URLとデータを分類する
static asset、public HTML、public API、authenticated、upload、admin、errorへ分け、method、query、header、cookie、個人情報、更新頻度、最大size、Rangeの有無を記録します。
2. 成功指標と許容範囲を決める
p95 latency、origin request・bytes、error率、費用、何秒古くてよいか、障害時にstaleを返すかを決めます。「HIT率だけ」を目標にしません。
3. 検証用ホストでDNS・TLS・origin接続を確認する
viewer TLSとorigin TLS、Host、SNI、IPv4・IPv6、CNAME、CAA、redirect、証明書更新を確認します。本番切替前に同じURL・headerで比較します。
4. URL群ごとにcache policyを定義する
cacheability、cache key、TTL、stale、error cache、compression、forwardするheader・cookie・queryを明記します。最初はhash付きassetから始めます。
5. security boundaryを試験する
別user、別tenant、別language、別currencyでbodyが混ざらないこと、logout後にprivate contentが残らないこと、origin直アクセスが制限されることを確認します。
6. release・purge・rollbackを準備する
static assetはcontent hash付きURLを基本にし、HTMLから新versionへ切り替えます。緊急purgeの対象、完了確認、rate limit、費用、purge後のMISS集中を想定します。
7. 小さく公開し、edgeとoriginを同時に監視する
一部host・path・trafficから開始し、request、bytes、cache status、latency、4xx・5xx、TLS、WAF、origin load、費用を同じ時間軸で確認します。
導入後の確認方法：curl・ヘッダー・ログで見る
ブラウザの体感だけでは、browser cache、CDN cache、origin処理のどこが効いているか判断できません。同じURLを複数回取得し、response headerとCDN・originログを照合します。
まずはresponse headerを確認する
# headerのみ確認
curl -I https://example.com/assets/app.a1b2.css
# cache-bustingせず、同じURLを数回確認
curl -sS -D - -o /dev/null https://example.com/article/
# 特定headerやstatusを抽出
curl -sS -D - -o /dev/null https://example.com/ \
| grep -Ei '^(HTTP/|age:|cache-control:|etag:|vary:|cache-status:|cf-cache-status:|x-cache:)'見るべき指標
| 指標 | 何が分かるか | 注意点 |
|---|---|---|
| cache status | HIT、MISS、BYPASS、EXPIRED、STALE、REVALIDATEDなど | 名称・分母・多段cacheの扱いは製品ごとに異なる |
Age | 共有cacheに保存されてからの概算秒数 | 再検証、purge、eviction、階層移動でreset・欠落する場合がある |
| origin request | 実際に上流へ到達した要求数 | edgeの非HIT数と一致しない場合がある |
| origin bytes | 上流からCDNへ転送した量 | 大容量object、Range、圧縮、多段cacheを考慮 |
| p50・p95・p99 latency | 平均では見えない遅い利用者・MISSを把握 | HIT・MISS、地域、path、status別に分ける |
| 4xx・5xx | WAF誤遮断、origin error、証明書・DNS問題 | error responseがcacheされていないか確認 |
| 費用 | transfer、request、function、WAF、logなどの増減 | bot、hotlink、攻撃、cache-bustingを分けて見る |
よくあるトラブルと確認順
更新したのに古い
browser cache → edgeのAge・status → TTL・s-maxage → purge対象 → 上位cache → origin bodyの順に確認します。
HIT率が上がらない
cache対象、Set-Cookie、Authorization、queryのばらつき、Vary、minimum TTL、object eviction、traffic量を確認します。
別ユーザーの内容が出る
直ちにcacheをbypass・purgeし、cache key、Cookie、Authorization、tenant、Vary、URL正規化を調査します。重大事故として扱います。
CDN経由だけ502・SSL error
origin証明書名、SNI、Host header、TLS version、firewall、origin timeout、DNS解決、IPv6を確認します。
CDNサービスを選ぶときの比較ポイント
「拠点数が多い」「無料で使える」だけでは選べません。自社の利用地域、コンテンツ、認証、運用体制を基準に、次の項目を比較します。
配信地域と実測latency
利用者の多い国・地域で、HITとMISS、HTMLと大容量fileを測定します。公称拠点数だけで決めません。
cache ruleの表現力
path、status、header、cookie、query、TTL、stale、purge、tiered cacheを要件どおり設定できるか確認します。
origin保護・private配信
OAC相当、mTLS、private network、署名URL・Cookie、鍵管理、権限失効を確認します。
WAF・DDoS・bot対策
標準範囲、追加料金、ルール上限、managed rule、rate limit、ログ、緊急対応窓口を確認します。
ログ・分析・エクスポート
cache status、origin latency、request ID、WAF、地域、費用を外部基盤へ送れるか、保持期間と遅延を見ます。
料金とサポート
転送、request、purge、function、log、WAF、専用機能、最低契約、攻撃時課金、サポート時間を同じ想定trafficで比較します。
CDNに関するよくある質問
CDNとキャッシュは同じものですか？
同じではありません。キャッシュは応答を保存・再利用する仕組みで、CDNは利用者とoriginの間に置く分散配信基盤です。CDNはcacheのほか、TLS、WAF、経路制御、動的通信の中継も担えます。
CDNを導入すると必ずWebサイトが速くなりますか？
必ずではありません。HITではorigin往復を省けますが、cold cache、動的処理、細分化しすぎたkey、重いedge処理では改善が小さい場合があります。導入前後を同じ条件で実測します。
動的コンテンツやAPIにもCDNは使えますか？
使えます。共有可能なGET応答だけを短時間cacheする方法と、cacheせずにCDNを経由させ、TLS、WAF、rate limitを適用する方法があります。認証・個人情報を含む応答は原則共有しません。
Cache-Controlのno-cacheは保存禁止という意味ですか？
保存禁止ではありません。no-cacheは保存した応答を再利用する前に再検証する指示です。保存自体を禁止する指示はno-storeです。CDN側ルールによる上書きも確認します。
WordPressサイトにもCDNは必要ですか？
必須ではありません。海外閲覧、大容量画像、アクセス急増、origin負荷が課題なら有効です。小規模な国内サイトでは、画像圧縮、不要plugin削減、server・database改善を先に行う方が効果的な場合もあります。
CDNを使うとSEO順位が上がりますか？
直接の順位保証はありません。速度・可用性の改善がユーザー体験やcrawl安定へ寄与する場合はありますが、content品質、index設定、canonical、status、renderingが前提です。
CDNはDDoS攻撃を完全に防げますか？
完全には防げません。CDNは防御層になりますが、WAF、rate limit、origin非公開化、applicationの高コスト処理対策、攻撃時課金の監視、緊急対応を組み合わせます。
キャッシュヒット率は何％なら良いですか？
一律の基準はありません。静的資産では高くしやすい一方、更新頻度の高いHTMLや個人別APIでは低くても正常です。origin offload、latency、error、正確性、費用と合わせて判断します。
更新したのに古いページが表示されるのはなぜですか？
browserまたはCDNの保存済み応答がまだfreshだからです。静的資産は内容ハッシュ付きURL、HTMLは短いTTL・再検証、緊急更新は対象を絞ったpurgeを使い分けます。
事実確認に用いた一次資料・公式資料
HTTPの標準仕様と、各CDN製品の実装例を分けて確認しています。製品固有の既定値やstatus名を、CDN全体の普遍的仕様として扱わないでください。
IETF・RFC
AWS CloudFront公式資料
Cloudflare公式資料
Google Search Central公式資料
まとめ：CDNはcache key・鮮度・origin保護まで設計する
CDNは、利用者とoriginの間に分散したedgeを置き、cache可能な応答を再利用し、cacheしない通信も中継する配信基盤です。HITではorigin往復を省けますが、MISS、再検証、動的要求、書き込みは上流へ到達します。
安全に導入するには、コンテンツ別にcacheability、cache key、TTL、versioning・purge、stale、認証境界を決め、edgeとoriginのrequest、bytes、latency、status、費用を同じ時間軸で監視してください。個人情報の共有、古い重要情報、origin bypass、purge後の負荷集中を防げて初めて、CDNは持続的な高速化になります。
- 最初に：URLとデータを公開・共有可能・個人別へ分類する
- 設定で：応答を変える値だけをcache keyへ含め、TTLと更新方法を決める
- 安全性で：origin直アクセス、認証後ページ、cache poisoning・deceptionを試験する
- 運用で：HIT率だけでなくorigin offload、p95 latency、error、費用を追う
Finite Field 編集部の更新方針RFCなどの標準仕様と、CDN各社の製品固有挙動を分けて確認します。拠点数や料金だけで評価せず、公開後の更新、セキュリティ、障害時動作、費用まで含めて実務で使える情報へ更新します。