はじめに
「うちのサイト、海外からだと表示が遅い」「アクセスが集中するとサーバーが落ちる」
こうした問題を解決する仕組みが CDN（Content Delivery Network） です。
YouTube、Netflix、Twitter ― 世界中のユーザーにコンテンツを高速配信しているサービスは、すべてCDNを使っています。この記事では、CDNの仕組みを図解で解説します。
この記事は 「図解でわかるWeb技術の仕組み」シリーズ の第6回です。
第5回：HTTPS・TLS通信の仕組みを先に読むと、よりスムーズに理解できます。
1. CDNとは ― コンテンツを「近く」に届ける
CDNの基本的な考え方
CDN（Content Delivery Network）は、世界中にエッジサーバーを配置し、ユーザーに最も近いサーバーからコンテンツを配信する仕組み です。
なぜCDNが必要なのか
物理的な距離は通信速度に直結します。
| 区間 | 片道レイテンシ（目安） |
|---|---|
| 東京 → 東京 | 1-5ms |
| 東京 → 大阪 | 5-10ms |
| 東京 → シンガポール | 70-90ms |
| 東京 → サンフランシスコ | 100-120ms |
| 東京 → ロンドン | 200-250ms |
光の速度には限界があるため、物理的に近い場所からコンテンツを返すのが最も効果的な解決策です。
CDNの3つのメリット
| メリット | 内容 |
|---|---|
| 高速化 | ユーザーの近くから配信することでレイテンシを削減 |
| 負荷分散 | オリジンサーバーへのアクセスを減らし、負荷を軽減 |
| 可用性向上 | エッジサーバーが分散しているため、一部の障害に強い |
2. エッジサーバーとオリジンサーバー
2つの役割
CDNは 2種類のサーバー で構成されます。
| サーバー | 役割 | 例 |
|---|---|---|
| オリジンサーバー | コンテンツの「原本」を持つサーバー | AWS EC2, S3, 自社サーバー |
| エッジサーバー | オリジンのコンテンツをキャッシュし、ユーザーの近くで配信 | CDNの各PoP（Point of Presence） |
エッジサーバーの選択方法
ユーザーのリクエストは、以下の仕組みで最寄りのエッジサーバーに振り分けられます。
1. ユーザーが cdn.example.com にアクセス
2. DNSが Anycast IP を返す
3. BGPルーティングにより、最も近いエッジサーバーにルーティング
4. エッジサーバーがキャッシュからレスポンスを返す（Cache HIT）
または、オリジンに問い合わせる（Cache MISS）
Anycast とは
同じIPアドレスを世界中の複数のサーバーに割り当てる技術です。ルーティングプロトコル（BGP）が自動的に最も近いサーバーにパケットを届けます。CDNの根幹を支える技術です。
3. CDNキャッシュの仕組み
CDNの最も重要な機能が キャッシュ です。
Cache MISS と Cache HIT
| 状態 | 動作 | レスポンス速度 |
|---|---|---|
| Cache MISS | エッジにキャッシュなし → オリジンに取りに行く | 遅い（200-500ms） |
| Cache HIT | エッジにキャッシュあり → 即座に返す | 速い（5-30ms） |
キャッシュの制御 ― Cache-Control ヘッダー
# オリジンサーバーのレスポンスヘッダーでキャッシュを制御
Cache-Control: public, max-age=86400, s-maxage=604800
# public → CDN（共有キャッシュ）に保存OK
# max-age → ブラウザキャッシュの有効期限（86400秒 = 24時間）
# s-maxage → CDNキャッシュの有効期限（604800秒 = 7日間）
コンテンツ種別ごとのキャッシュ戦略
| コンテンツ | Cache-Control 例 | 理由 |
|---|---|---|
| 画像・フォント | public, max-age=31536000, immutable |
変更されない。1年キャッシュ |
| CSS / JS | public, max-age=31536000 |
ファイル名にハッシュ付与で管理 |
| HTML | public, max-age=300, s-maxage=3600 |
更新頻度が高い。短めに設定 |
| API レスポンス | private, no-cache |
ユーザーごとに異なる。CDNキャッシュしない |
キャッシュ事故に注意
個人情報を含むレスポンス（マイページ等）を誤って public でキャッシュすると、他のユーザーの個人情報が表示される 重大インシデントにつながります。動的コンテンツには private または no-store を設定しましょう。
4. CDN の主要機能
CDNの役割はキャッシュだけではありません。
代表的な機能一覧
| カテゴリ | 機能 | 説明 |
|---|---|---|
| キャッシュ | 静的ファイル配信 | HTML, CSS, JS, 画像をエッジから高速配信 |
| 最適化 | 圧縮（Gzip/Brotli） | レスポンスサイズを50-80%削減 |
| 最適化 | 画像最適化 | WebP/AVIF変換・リサイズをエッジで自動処理 |
| セキュリティ | DDoS防御 | 大量アクセスをエッジで吸収し、オリジンを保護 |
| セキュリティ | WAF | SQLインジェクション・XSSをエッジでブロック |
| セキュリティ | TLS終端 | SSL証明書の管理・HTTPS通信をエッジで処理 |
| ルーティング | ロードバランシング | 複数オリジンへの負荷分散・フェイルオーバー |
| エッジ実行 | エッジコンピューティング | エッジでサーバーレス関数を実行 |
5. 主要CDNサービスの比較
どれを選ぶべきか
CDNを初めて使う / 個人プロジェクト
→ Cloudflare（無料プラン + 簡単導入）
AWSを使っている
→ CloudFront（S3 / ALB との連携が強力）
即時キャッシュパージが必須
→ Fastly（約150msでパージ完了）
大企業 / 大規模メディア
→ Akamai（世界最大規模のエッジネットワーク）
Cloudflare の導入例
# 1. Cloudflare にドメインを追加
# ネームサーバーを Cloudflare に変更するだけ
# 2. DNS設定でプロキシを有効化（オレンジのアイコン）
# → 全トラフィックがCloudflareのエッジを通過
# 3. キャッシュルールの設定（Cloudflare Dashboard）
# Page Rules や Cache Rules で細かく制御可能
CloudFront + S3 の構成例
# AWS CLI で CloudFront ディストリビューションを作成
aws cloudfront create-distribution \
--origin-domain-name my-bucket.s3.amazonaws.com \
--default-root-object index.html
# キャッシュの即時無効化（パージ）
aws cloudfront create-invalidation \
--distribution-id E1234567890 \
--paths "/*"
6. キャッシュ無効化（パージ）
CDNでキャッシュした内容を更新したいとき、キャッシュパージ（Invalidation） を行います。
パージの方法
| 方法 | 説明 | 用途 |
|---|---|---|
| パスパージ | 特定URLのキャッシュを削除 | 1ページだけ更新 |
| タグパージ | Surrogate-Key でまとめて削除 | 関連コンテンツを一括更新 |
| 全パージ | すべてのキャッシュを削除 | 大規模な変更時 |
パージに頼らない設計 ― Cache Busting
<!-- ファイル名にハッシュを含める -->
<link rel="stylesheet" href="/css/style.a1b2c3d4.css">
<script src="/js/app.e5f6g7h8.js"></script>
<!-- ファイル内容が変わればハッシュも変わる → 新しいURLとしてキャッシュ -->
<!-- パージ不要で、常に最新版が配信される -->
実務では Cache Busting が主流
Webpack, Vite 等のビルドツールは、出力ファイル名に自動でハッシュを付与します。これにより、CDNのキャッシュパージを意識せずに最新コンテンツを配信できます。
7. まとめ
| 項目 | ポイント |
|---|---|
| CDN | 世界中のエッジサーバーにコンテンツをキャッシュし、高速配信するネットワーク |
| エッジサーバー | ユーザーの近くに配置され、キャッシュからレスポンスを返す |
| Cache HIT/MISS | キャッシュがあれば即座に返す（HIT）。なければオリジンに取りに行く（MISS） |
| Cache-Control | キャッシュの有効期限や挙動を制御するHTTPヘッダー |
| セキュリティ | DDoS防御・WAF・TLS終端もCDNの重要な役割 |
| 選び方 | 個人 → Cloudflare / AWS → CloudFront / 大規模 → Akamai |
次回予告
第7回では 「WebSocket ― 双方向リアルタイム通信」 を図解で解説します。チャットアプリや株価のリアルタイム更新の裏側で何が起きているのか ― HTTPの限界とWebSocketの仕組みを一歩ずつたどります。
シリーズ目次
| # | テーマ |
|---|---|
| 1 | HTTPリクエスト/レスポンスの仕組み |
| 2 | Cookie・Session・JWTの違い |
| 3 | OAuth 2.0 の仕組み |
| 4 | DNS解決の流れ |
| 5 | HTTPS・TLS通信の仕組み |
| 6 | CDN の仕組みと役割（この記事） |
| 7 | WebSocket ― 双方向リアルタイム通信 |
| 8 | キャッシュ戦略（ブラウザ・サーバー・CDN） |
| 9 | CORS ― クロスオリジンの壁を理解する |
| 10 | REST API 設計の基本原則 |
「この記事が役に立った」と思ったら、LGTM とストックをお願いします。
@kotaro_ai_lab
AI活用や開発効率化について発信しています。フォローお気軽にどうぞ！