2026年10月8日にMDNのHTTP概要とCache-Control、RFC 9110を本文まで再確認した。CDNは利用者に近いキャッシュや中継を置いて配信距離・負荷を減らす設計で、originの認可を置き換える仕組みではない。Cache-Control、Vary、ETag、期限と無効化をコンテンツの性質ごとに決め、個人情報やCookieに依存する応答を共有キャッシュへ出さないこと、更新反映と障害時のフォールバックを実測することを判断軸にする。
30秒で要点
- CDNは、配信拠点を分散し、保存してよい応答を再利用する仕組みです。元データを持つオリジンをすべて置き換えるものではありません。
- キャッシュにあるか、まだ新鮮か、利用者へ再利用してよいかで経路が変わります。近い拠点が必ず最速とは限らず、効果は実際の地域・回線・応答で測ります。
- 公開画像と会員ページでは設定が違います。速さだけでなく、古い内容の残り方、利用者情報の混入、料金、障害時の戻し方を決めて導入します。
画像を多く使うページが遠い地域で遅い、同じ資料の配信で元サーバーの負荷が増える。こうした問題ではCDNが候補になります。ただし、ページ内の重いJavaScriptや遅いデータベース処理まで、導入だけで直るわけではありません。
この記事では、CDNがどこで応答するか、何を保存するか、更新と障害にどう備えるかを順に説明します。実CDN、DNS、アカウントへの設定変更は行わない入門です。
オリジンと配信拠点を分けて考える
オリジンは元のファイルや応答を提供するサーバー、エッジは利用者への配信を担う分散拠点です。コンビニの例なら、オリジンは供給元、エッジは各地の店、キャッシュは店の在庫に相当します。
ただし、この例えでは在庫の保存期限や個人ごとの商品を見落としやすくなります。Webでは「コピーがある」だけでなく、いま使ってよいコピーかを確認します。期限が切れた応答は再確認が必要になる場合があります。
表が収まらない場合は、横にスクロールできます
| 場所 | 役割 | 別に必要な仕事 |
|---|---|---|
| ブラウザ | 利用者の端末で応答を保持・表示する | 表示、端末側の保存、画面の処理 |
| CDN | 分散拠点で配信・キャッシュなどを行う | 保存条件、経路、無効化、利用者の区別 |
| オリジン | 正本のファイルや動的な応答を提供する | 認証・認可、データ処理、更新、復旧 |
CDNとブラウザは同じキャッシュではありません。CDN側を更新しても利用者の端末に古い応答が残ることがあり、逆もあります。
キャッシュに当たる場合と、元へ取りに行く場合
次は要求経路を読むための説明図です。実ネットワークの距離・時間・拠点数を表すものではありません。
利用者 → CDN
├─ 再利用できる応答がある → 利用者へ返す
├─ 応答がない／再利用条件を満たさない → オリジンへ
└─ 古い応答がある → 条件に応じてオリジンへ再確認
オリジン → CDN → 利用者
└─ 保存が許され、設定に合うときにキャッシュする応答が再利用できれば、オリジンへの問い合わせを減らせます。ミスした場合や更新確認が必要な場合は、オリジンへの通信が残ります。ルーティングは事業者の方式やネットワーク状態に左右され、「地図上で最も近いサーバーが常に選ばれる」とは限りません。
有効期限と再確認を混同しない
HTTPキャッシュの指示には、保存、鮮度、再確認など異なる役割があります。RFC 9111のCache-Controlを基準に、実際のCDNの設定がどう扱うかを確認します。
表が収まらない場合は、横にスクロールできます
| 指示の例 | 読むべき意味 | 誤解しやすい点 |
|---|---|---|
max-age | 応答を新鮮として扱える時間の条件 | 永久に同じ内容を返す指定ではない |
no-cache | 保存した応答を再利用する前の検証が必要 | 保存そのものを一切禁止する意味ではない |
no-store | 応答を保存しないよう求める | それだけで通信や全保存先の機密性を保証しない |
設定の優先関係も確認します。たとえばCloudflareのデフォルトのキャッシュ動作には、ファイル種別や応答ヘッダーなどによる条件があり、HTMLやJSONが一律に既定でキャッシュされるわけではありません。これはCloudflareの当該設定の説明で、すべてのCDNの共通仕様ではありません。
保存しやすい公開ファイルから考える
表が収まらない場合は、横にスクロールできます
| コンテンツ | 主な検討事項 |
|---|---|
| 公開画像、CSS、JavaScript、フォント | 更新時にURLを変えるか、古い版が残ってよい時間はどれだけか |
| 公開PDF、動画 | サイズ、範囲取得、権利、転送量、更新方法 |
| 公開HTML、公開API応答 | 更新頻度、鮮度、条件別の応答、再確認 |
| 会員情報、注文内容、個人ごとの検索結果 | 他人へ共有してよいか。キャッシュ対象にする前の個別設計 |
拡張子だけで保存可否を決めません。同じURLでもログイン状態や要求ヘッダーなどによって応答が変わる場合があります。会員A向けの内容を会員Bへ返すような設定は、表示速度の問題より重大です。権限のある人が、キャッシュキー、認証、Cookie、共有してよい範囲を確認してください。
動的な応答でも配信経路を短縮したり、エッジで処理したりするサービスがあります。ただし、その機能と「誰にでも同じ応答を共有してよいか」は別の判断です。
期待する効果と、残る負担を分ける
CDNを検討する効果は、配信の待ち時間、オリジンの負荷、転送費用、アクセス増への対応などです。どれが改善するかは、ヒット率、利用者の地域、ファイルサイズ、元の性能によって変わります。
架空の同じ期間に公開画像への要求が1000回あり、そのうち800回をCDNだけで応答し、残り200回がオリジンへ進んだとします。この単純モデルの要求ヒット率は800÷1000＝80%です。再確認や別の要求は含めていません。
表が収まらない場合は、横にスクロールできます
| 架空の観測 | 値 | この値だけでは分からないもの |
|---|---|---|
| 対象画像への要求 | 1000回 | サイト全体のアクセス数 |
| CDNだけで応答 | 800回 | 800人という人数 |
| オリジンへ進む要求 | 200回 | 認証・再確認など他の処理量 |
| 要求ヒット率 | 80% | 転送バイトの削減率、売上の増加率 |
大きいファイルほどミスしているなら、要求ヒット率が高くても転送量はあまり減らない可能性があります。CDN料金とオリジン料金、リクエスト数、転送量、ログ、セキュリティ機能などを合計します。無料・低価格の枠があっても、自社の必要機能と利用量で条件を確認してください。
表示が速くなったことと、問い合わせや購入が増えた因果関係も別です。導入前後の利用者層、ページ内容、端末・回線、キャンペーンなどが変われば、単純比較では判断できません。Core Web Vitalsと業務への影響も参照できます。
障害時も、必ず配信を続けられるわけではない
オリジンが停止しても、保存済みの応答を一定条件で返せる構成はあります。しかし、未保存のファイル、期限や設定の条件、認証を伴う処理、書き込みまで代行できるという意味ではありません。CloudFrontの期限・古い応答の扱いにも条件があります。
DDoS緩和やWAFを組み合わせられるサービスでも、対象プラン、設定、検知、誤検知、オリジンへ直接到達できる経路などの確認が必要です。「CDNを通したのでアプリの脆弱性対策は不要」とは考えません。
停止時の連絡先、誰が変更できるか、DNS・TLS・オリジン設定をどう戻すか、戻した先がアクセスを受け切れるかを運用手順に含めます。
サービス選定は、名前より条件をそろえる
Cloudflare、Akamai、Fastly、CloudFront、Azure系やGoogle Cloud系の配信サービスなど、候補は複数あります。個別の料金やサービス名、機能範囲は変わるため、この一覧を現行プランの比較表としては使いません。
比較では、対象地域、必要なファイル、認証やキャッシュの例外、無効化方法、TLS、ログ保持、セキュリティ機能、費用、サポート、切戻しの責任を同じ条件でそろえます。単一の速度テストだけで選ばず、実際の利用条件に近い検証を計画します。
公開画像一つで、更新と戻し方まで確かめる
導入する場合は権限者が小さい検証環境から進めます。オリジンの指定やDNSの切替方式は事業者ごとに異なり、常にCNAME一件で済むとは限りません。既存の証明書、他のサービスへの影響、設定の記録を先に確認します。
最小の確認では、公開画像一つについて、初回と次回の応答、キャッシュ状態、更新後に新しい内容が見えるまで、認証付きページが混ざらないこと、切戻しの手順を確かめます。速さだけでなく正しい内容を届けられることが条件です。
この記事の架空の経路図と算数は、実CDNの動作やDNS・TLS設定を検証した証拠ではありません。Webパフォーマンスの全体像、サーバーの基本、TLS入門と合わせ、遅い箇所と責任範囲を絞ってください。
