CDNとは、分散した配信拠点を介してコンテンツを届ける基盤
CDN（Content Delivery Network）は、利用者とオリジンの間でリクエストを受け、キャッシュ、経路最適化、接続再利用、TLS終端などにより配信を支える分散ネットワークです。
典型的な構成では、公開ホスト名のDNS設定等によりリクエストがCDNのPOP（Point of Presence）またはedge locationへ到達します。AWS CloudFrontの説明では、DNSがリクエストを適切なPOPへ送り、edgeに対象オブジェクトがあれば利用者へ返し、なければ設定に従ってoriginへ要求します。originの応答は到着した先頭バイトから利用者へ転送され、条件を満たすオブジェクトは次回のために保存されます。ただしPOP、regional edge cache、tiered cache、shield等の階層は製品固有で、すべてのCDNに同じ構成があるわけではありません。
originは正規の応答を作る上流
originはWebサーバー、ロードバランサー、オブジェクトストレージ、API等です。CDNは通常、originの代わりにアプリやデータベース処理を完結するものではありません。cache miss、期限切れ、再検証、非キャッシュ対象、書き込み要求ではoriginまたは上流処理が必要です。
edgeは利用者に近い配信・中継地点
edgeはキャッシュ応答だけでなく、TLS終端、圧縮、ルール、WAF、bot対策、edge compute等を提供する場合があります。ただし機能と実行順序、対応地域、制限は製品・プランごとに異なります。「物理的に最も近い拠点」より、遅延、経路、障害、容量、ポリシーを含めて適切な拠点が選ばれると捉えます。
CDNとキャッシュは同義ではなく、CDNはoriginを自動的に不要にしない
キャッシュは以前の応答を再利用する仕組みで、ブラウザ、proxy、アプリ、データベース等にもあります。CDNは分散配信基盤であり、cacheはその主要機能の一つです。キャッシュしない動的要求でも、CDNを通してTLSやセキュリティ機能を適用できます。反対に、CDNを経由してもcache keyが細分化されすぎたり、応答が保存不可だったりすればorigin負荷はほとんど減りません。
具体例：cache hit・missから配信経路とorigin削減率を読む
以下は仕組みを理解するための説明値です。実サービスでは、cache-eligible requestの分母、REVALIDATEDやSTALEの扱い、多段cache、subrequest、range request、bot、エラー、edge functionの内部要求により値が変わります。事業者のダッシュボード定義とoriginログを照合してください。
リクエストのキャッシュヒット率
850 hits ÷ 1,000 eligible requests = 85%
同じ期間・ホスト・cache behaviorで、キャッシュ対象1,000件のうち850件が有効なedge cacheから返った例です。全リクエストを分母にするか、BYPASSや非対象を除くかは製品で異なります。hit ratioだけで利用者体験を判断せず、hit時・miss時のlatencyとstatusも見ます。
単純化したorigin request削減率
1 − (150 origin requests ÷ 1,000 viewer requests) = 85%
100件のMISSと50件の同期再検証がoriginへ届き、850件のHITでは届かなかったと仮定した例です。実際にはtiered cacheが下位edgeのmissを吸収する場合、edge functionが複数subrequestを出す場合、origin shieldやrequest collapsingが働く場合があり、edgeの非hit数とorigin要求数は一致しません。
1つの画像を初回と2回目に要求したとき
- 1入口：利用者が`/assets/app.a1b2.css`を要求すると、DNSやCDN事業者の経路制御により、要求を処理するedgeへ到達する。HTTPSでは利用者とedgeのTLS接続が確立される。
- 2照合：edgeはmethod、host、pathを基本に、設定したquery string、header、cookie等からcache keyを作る。同じURLでも応答を変える入力をkeyから落とすと誤配信し、不要な入力を含めすぎるとhit率が下がる。
- 3初回MISS：保存済みの有効な応答がなければ上位cacheまたはoriginへ転送する。originから200応答を受け、保存条件とTTLを満たせばcacheへ格納しつつ利用者へ返す。最初の利用者はorigin経路の待ち時間を受ける。
- 4次回HITまたは再検証：同じkeyで応答がfreshならedgeから返す。staleならETagのIf-None-Match等で再検証し、304なら保存済みbodyを再利用できる。purge、eviction、期限切れ、別edgeでは再びMISSになり得る。
CDNの効果は「距離が短い」だけではありません。originへの往復を省くHIT、接続再利用、多段cache、圧縮等が組み合わさります。一方、cold cacheや非キャッシュAPIではorigin経路が残るため、origin自体の性能・容量・冗長化も必要です。
適用例：何をCDNで配信し、何を共有キャッシュしないか
ファイル拡張子だけで決めず、同じcache keyの利用者へ同じ応答を返してよいか、変更がいつ反映されるべきか、認証・個人情報・Cookieに依存するかで判断します。`Cache-Control`だけでなく、CDN側のminimum TTLやcache ruleがorigin指示を上書きしないかも確認します。
表は横方向にスクロールできます
| 対象 | 基本方針 | 向いている理由 | 主な注意点 |
|---|---|---|---|
| 版管理した静的資産 | 長いTTLで共有cache | hash付きCSS、JavaScript、画像、fontはURLが内容ごとに変わるため再利用しやすい | HTMLから新URLへ切り替え、古い資産を即削除しない。immutableと長期TTLはversioned URLと組み合わせる |
| 公開HTML・記事 | 短いTTLまたは再検証 | 同じURLの公開内容を多くの利用者へ配信でき、origin負荷を軽減しやすい | 更新反映、preview、ログイン状態、AB test、言語・端末差、Cookie、エラー応答のcache条件を設計する |
| ダウンロード・動画 | 共有cacheとRange対応 | 大容量objectの配信距離とorigin転送を減らし、急増時の配信を分散しやすい | Range request、署名URL、権限失効、seek、ファイルサイズ上限、転送費、権利管理を確認する |
| 公開GET API | 条件付きで短時間cache | 同一queryに同一応答を返す天気・商品一覧等は短いTTLでburstを吸収できる場合がある | query正規化、認可、地域、通貨、language、pagination、更新許容時間、error cacheをkeyとTTLへ反映する |
| 認証後・個人別ページ | 原則bypassまたは厳密な分離 | CDN経由のTLS、WAF、rate limit、動的中継は利用できる | 共有cacheへ個人情報を保存しない。Authorization、session cookie、tenantを無視したkeyは重大な情報漏えいを起こす |
| POST・更新処理 | originへ中継 | フォーム送信やCRUDはCDNを入口にしてsecurity policyを適用できる | 通常の共有cacheによる高速化対象ではない。timeout、body上限、retry、idempotency、WAF誤検知を確認する |
| 障害時のstale配信 | 許容範囲だけ明示設定 | originが一時的に応答できないとき、期限切れの公開内容を限定時間返して閲覧を継続できる場合がある | 価格、在庫、法令、認証、緊急告知等は古い表示の損害を評価する。staleは自動の完全障害対策ではない |
「動的コンテンツだからCDN不可」「CDNだから全部cache」はどちらも誤り
動的生成したHTMLやAPIでも、利用者間で共有できる応答なら短時間cacheや再検証が可能です。反対に拡張子が画像でも、権限付きの私有画像や署名条件があるなら無条件共有できません。cacheability、cache key、TTL、認可をURLパターン単位で文書化します。
導入前に決める6項目
CDN事業者の比較より先に、アプリがどの入力で応答を変え、何秒古くてもよく、originをどの経路から受け付けるかを決めます。既定値任せにせず、代表URLごとの期待するcache statusとsecurity boundaryをテスト可能にします。
cache対象とHTTP method
pathごとにGET・HEAD・OPTIONS・POST等の扱い、status code、response header、object sizeを確認します。HTML、asset、API、download、error responseを別behaviorにし、Set-CookieやAuthorizationを含む応答を共有してよいか明記します。
cache keyとvariant
host、pathに加え、応答を本当に変えるquery、header、cookieだけをkeyへ含めます。language、compression、device、tenant、currency等を落とすと誤配信し、tracking queryや一意sessionを含めるとobjectが細分化されhit率と容量効率が落ちます。
TTL・再検証・無効化
`s-maxage`、`max-age`、`no-cache`、`no-store`、`private`、ETag、Last-Modifiedの意味をRFCと事業者実装で確認します。更新頻度、許容陳腐化、purge範囲、versioned URL、rollback、緊急削除の手順をrelease設計へ含めます。
origin保護とTLS
利用者→edgeとedge→originの双方でHTTPSを使い、証明書、SNI、Host、redirectを確認します。S3等はOAC、custom originは認証済みheader、mTLS、firewall allowlist等、対応方式でCDN以外からの直接到達を制限し、secretを定期更新します。
可観測性と障害動作
HIT、MISS、BYPASS、EXPIRED、REVALIDATED、STALE等の意味を製品文書で確認し、edgeとoriginのrequest、bytes、status、latencyを同じ時間軸で監視します。origin timeout、5xx、DNS、証明書、purge、設定反映、単一地域障害を試験します。
費用・上限・濫用対策
利用者向け転送、origin向け転送、request、function、WAF、log、purge、専用IP等の課金単位と無料枠を確認します。大容量bot、cache-busting query、range濫用、hotlink、攻撃時にも費用が増え得るため、budget alertとrate limitを用意します。
hit ratioは高いほど常に良いわけではない
個人別APIを無理に共有してhit率を上げれば安全性を損ないます。逆に、更新頻度が高く低流量のobjectは正しく設定してもhitしにくい場合があります。cache-eligible対象ごとに、origin offload、p50/p95 latency、stale率、error率、正確性、費用を合わせて評価します。
CDNと関連技術の違い
製品は複数機能を一体提供するため境界が重なりますが、役割を分けると設計漏れを見つけやすくなります。CDNを導入しても、DNS、origin、load balancer、アプリ、databaseの責任は残ります。
| 用語 | 主な役割 | CDNとの違い・関係 |
|---|---|---|
| キャッシュ | 以前の応答・計算結果・データを保存して再利用する仕組み | CDN以外のbrowser、OS、application、databaseにも存在する。CDNはshared HTTP cacheを分散配置する場合がある |
| リバースプロキシ | 利用者の前面で要求を受け、上流サーバーへ転送する中継 | CDN edgeもreverse proxyとして働くが、単一拠点のproxyは分散配信網とは限らない |
| ロードバランサー | 複数のbackendへ要求を振り分け、health check等で処理先を選ぶ | origin側でapplication instanceを分散することが多い。CDNのglobal routingやedge cacheとは層が異なる |
| DNS | domain nameをIPアドレス等の接続情報へ解決する | CDNへの入口を向ける手段だが、DNS自体がHTTP応答をcacheして配信するわけではない |
| Webホスティング | Webサーバー、storage、runtime等を提供し、正規のcontent・applicationを動かす | CDNのoriginになり得る。CDNを使ってもoriginの保守、backup、security、capacityは必要 |
| edge compute | edgeでcodeを実行し、redirect、認証、変換、応答生成等を行う | CDN事業者が提供する機能の一つ。実行時間、runtime、状態、地域、料金、cacheとの順序に制限がある |
| WAF・DDoS対策 | 不正・過剰な通信を検知、制限、吸収するsecurity control | CDNに統合されることがあるが、自動的に全攻撃を防ぐ意味ではない。rule、origin bypass、L7 cost attackを設計する |
| object storage | file・objectを耐久的に保存し、APIやHTTPで取得可能にする | CDNのoriginとして使えるが、storageの公開設定とCDN cacheは別。private originと署名accessを設計する |
「CDNを使えばSEOが上がる」は因果を省略している
CDNは検索順位を購入する機能ではありません。Google Search CentralはCDN利用自体を問題とせず、cold cacheでは最初のcrawlがoriginへ届き、crawl急増時にはorigin容量へ注意するよう説明しています。配信速度や可用性の改善が利用者体験やcrawl可能性へ寄与する場合はありますが、内容品質、index可否、canonical、status、renderingが正しいことが前提です。CDN移行時はrobots.txt、noindex、redirect、host、TLS、error cacheを確認します。
安全に導入・運用する6ステップ
いきなり全URLをcacheせず、観測可能な小さい範囲から始めます。変更前後でURL、response body、header、status、latency、origin request、費用を比較し、異常時に即時bypassまたはrollbackできる状態を作ります。
- 1
1. 配信対象とvariantを棚卸しする
代表URLをasset、public HTML、public API、authenticated、upload、admin、errorへ分類します。method、query、header、cookie、Authorization、Set-Cookie、language、tenant、personal data、更新頻度、最大size、Rangeの有無を記録します。
- 2
2. DNS・証明書・origin経路を準備する
検証用hostでCDNを設定し、viewer TLSとorigin TLS、Host header、SNI、redirect、IPv4/IPv6、CNAME、CAA、証明書更新を確認します。originへ直接届く公開addressを残す場合は、bypassされるsecurity riskを評価します。
- 3
3. cache policyをURL群ごとに定義する
cacheability、cache key、TTL、stale、error cache、compression、forward header/cookie/queryを明記します。最初は版管理したstatic assetから始め、public HTMLやAPIは短いTTL・再検証で段階的に追加します。private応答はbypassを確認します。
- 4
4. security boundaryと失敗条件を試験する
別user・別tenant・別language・別currencyでbodyが混ざらないこと、logout後にprivate contentが残らないことを確認します。origin直アクセス、header偽装、cache deception、poisoning、oversized request、WAF false positive、5xx・timeout時動作も検証します。
- 5
5. release・purge・rollbackを自動化する
static assetはcontent hash付きURLを基本にし、HTMLから新versionへ切り替えます。同じURLを緊急更新する場合のpurge対象、完了確認、rate limit、費用を決めます。purge直後のMISS集中でoriginが過負荷にならないよう段階反映やpre-warmを評価します。
- 6
6. edgeとoriginを継続監視する
request、bytes、cache status、hit ratio、latency、4xx/5xx、TLS、WAF、origin load、費用をpath・region・status別に監視します。synthetic testでHIT期待URLとBYPASS期待URLを定期確認し、設定変更、証明書期限、log欠損、急なcache-bustingをalertにします。
CDNは可用性の一部であり、完全な障害対策ではない
edge cacheが残っていれば一部の公開GETを返せる場合がありますが、cold object、dynamic request、write、authentication、database処理はoriginへ依存します。CDN事業者自身の障害、誤設定、DNS障害、証明書問題、global purge、WAF誤遮断もあります。複数origin、health check、stale許容、bypass、status page、運用権限、変更承認を事業継続要件に合わせます。
事実確認に用いた一次資料・公式資料
概念の根拠と実装例を分けて確認しています。RFC 9111はHTTP cacheの標準、AWS・Cloudflare資料は各製品の実装例です。製品固有の既定値をCDN全体の普遍的仕様として扱わないでください。
- AWS CloudFront Developer Guide：How CloudFront delivers content
- RFC 9111：HTTP Caching
- AWS CloudFront Developer Guide：Understand the cache key
- Cloudflare Docs：Origin Cache Control
- AWS CloudFront Developer Guide：Invalidate files to remove content
- AWS CloudFront Developer Guide：Restrict access to files
- Cloudflare Docs：Cloudflare cache responses
- Google Search Central Blog：CDNs and crawling
- AWS：CloudFront pricing
CDNのよくある質問
CDNとキャッシュは同じですか？
同じではありません。cacheは応答等を保存・再利用する仕組みで、CDNは分散配信基盤です。CDNはcacheを使いますが、非キャッシュ要求の中継、TLS、WAF等も担えます。
CDNを導入すると必ずWebサイトが速くなりますか？
必ずではありません。cache hitならorigin往復を省けますが、cold cache、動的処理、誤ったcache key、遠いorigin、重いedge処理では改善しないことがあります。実測で比較します。
動的コンテンツやAPIにもCDNを使えますか？
使えます。中継やsecurity機能だけを使う方法と、共有可能なGET応答を短時間cacheする方法があります。認証・個人情報・更新許容時間を先に確認します。
Cache-Control: no-cacheは保存禁止ですか？
RFC上、no-cacheは再利用前の検証を要求する指示で、保存禁止はno-storeです。ただしCDN側の実装・設定で挙動が変わるため、response headerとcache statusを実測します。
CDNを使えばDDoS攻撃を防げますか？
防御層にはなりますが完全保証ではありません。契約機能、WAF・rate limit、origin非公開化、applicationの高コスト処理、攻撃時課金、運用体制まで設計します。
更新したのに古いファイルが出るのはなぜですか？
edgeまたはbrowserの保存済み応答がfreshだからです。静的資産はversioned URL、同一URLの内容は短いTTL・再検証・対象を絞ったpurgeを使います。
CDNを使うとSEO順位が上がりますか？
直接の順位保証はありません。速度・安定性を改善できる場合はありますが、content品質、index設定、status、canonical、renderingが前提です。移行時の誤遮断やerror cacheにも注意します。
キャッシュヒット率は何%なら良いですか？
一律の基準はありません。対象URLの共有可能性、更新頻度、流量、分母定義で変わります。origin offload、latency、正確性、error、費用と合わせて判断します。
CDN設計に関係する用語
まとめ：CDNはcache key・鮮度・origin保護まで設計する
CDNは、利用者とoriginの間に分散したedgeを置き、cache可能な応答を再利用し、非cache要求も中継する配信基盤です。HITではorigin往復を省けますが、MISS、再検証、動的要求、writeは上流へ到達します。コンテンツ別にcacheability、key、TTL、versioning・purge、stale、security boundaryを決め、edgeとoriginのrequest、bytes、latency、status、費用を同じ時間軸で監視してください。個人情報の共有、古い重要情報、origin bypass、purge後の負荷集中を防げて初めて、安全な高速化になります。
執筆・事実確認
Finite Field 編集部
Web配信、HTTP、server、security、可観測性を扱う編集部が、IETF RFC、AWS、Cloudflare、Google Search Centralの一次資料・公式資料を照合し、標準仕様と製品固有挙動を分離して確認しました。
CDN・cache・配信基盤の相談
速度だけでなく、誤配信とorigin依存を含めて設計します
CDNを導入したのにorigin負荷が下がらない、個人別応答のcacheが不安、更新が反映されない、edgeとoriginの数字が合わない、DDoS・費用急増へ備えたい場合に、配信経路、cache policy、origin protection、log・dashboard、release・rollbackを整理します。
個別開発を相談対象システム、データ分類、利用地域、契約、可用性要件、予算を確認したうえで対応可否をご案内します。特定の速度、hit率、SEO順位、攻撃防御、費用削減、無停止を事前に保証するものではありません。