CDN（シーディーエヌ）とは利用者の近くのサーバーにWebサイトのコピーを置き、そこから返して表示を速める仕組み。どう動くか・身近な利用例・CDN事業者の障害の公式報告・利用者にできることとできないこと【2026年10月版】

2026年10月13日・日本時間時点の情報です。 CDN（シーディーエヌ。Content Delivery Network、コンテンツ配信ネットワーク）とは、ウェブページ・画像・動画などのデータを、利用者に近い場所に置いた多数のサーバーから配信して、届け方を安定させ、速くする仕組みです。国家サイバー統括室（NCO）のハンドブック（2025年3月改訂）は、世界各地のサーバーにファイルのコピーを一時的に保存して遅延を解消する仕組みと説明し、Cloudflare・Akamai・Amazon・Fastly・Googleの公式の説明も、利用者の近くのサーバーにコピーを置いて返す仕組みと書いています。契約して使うのはサイトを運営する側で、見る側の設定は基本的に要りません（筆者の整理。AWSとCloudflareの説明は、費用や設定を運営者の話として書いています）。

3行まとめ

1. 国家サイバー統括室のハンドブック（2025年3月）、総務省の情報通信白書の用語解説（平成16年版＝2004年）、IETFのRFC 6707（2012年9月）がCDNを説明・定義し、Cloudflare・Akamai・Amazon・Fastly・Googleの5社は、近くのサーバーにコピー（キャッシュ）を置いて返す仕組みと説明している（2026年10月13日取得）。
2. 筆者は2026年10月13日3時32分から、このMacの curl で go.jp の公的機関8・大手2・CDN事業者5の計15サイトの応答ヘッダーを1回ずつ読んだ。ヘッダーに事業者名が出たのは10サイト、名前解決（CNAME）だけに出たのが3サイト、どちらにも出なかったのが2サイト（1回分の結果で、傾向を示すものではない）。www.digital.go.jp は age が303,575秒（3日12時間19分）で、同じコピーが返っていると筆者は読んだ（推測）。
3. CDN事業者の公式の障害報告は、2021年6月8日（Fastly）・7月22日（Akamai）・2025年11月18日と12月5日（Cloudflare）が原文で読める。Cloudflareのヘルプは、サイトの訪問者は問題を運営者に報告するよう書く。

特定のCDN事業者を勧めたり比べたりはしません。

CDNとは何か。国家サイバー統括室・総務省・IETFと事業者5社の原文

国家サイバー統括室（NCO）の「インターネットの安全・安心ハンドブック」Ver 5.10（2025年3月11日）の用語集は、CDN（Content Delivery Network の略）をこう説明しています。

「写真や動画など、データサイズが大きなものをインターネットで通信すると、通信が遅延してしまう問題が発生してしまうため、遅延を解消する目的で作られた。CDNサービスでは、世界各地にデータセンターが展開されていて、データセンターのサーバーには一時的にファイルのコピーが保存されている」

それより前の定義として、総務省の平成16年版（2004年）情報通信白書の用語解説は、CDNを次のように載せています。

「Contents Delivery Networkの略。コンテンツ配信ネットワーク。インターネット上で利用者に大容量のデジタルコンテンツを安定的・効率的に配信するために構築されるネットワークシステム」

IETF（インターネットの技術文書を決める団体）のRFC 6707（2012年9月）は、用語の節でこう定めています。

Content Distribution Network (CDN) / Content Delivery Network (CDN): Network infrastructure in which the network elements cooperate at Layers 4 through 7 for more effective delivery of Content to User Agents.

（訳：CDN。ネットワークの要素が、コンテンツを利用者のソフトウェアへより効果的に届けるために、レイヤー4〜7で協調するネットワーク基盤。）

事業者5社の公式の説明は次のとおりです。

• Cloudflare：「A content delivery network (CDN) is a geographically distributed group of servers that speeds up the delivery of web content by caching it closer to users.」（訳：地理的に分散したサーバーの集まりで、コンテンツをユーザーの近くにキャッシュして配信を速める。）
• Akamai：ほぼ同じ文で、キャッシュの代わりに「bringing it closer to where users are」（ユーザーのいる場所の近くに持ってくる）と書いています。
• Amazon（AWS）：「コンテンツ配信ネットワーク (CDN) は、相互接続されたサーバーのネットワークであり、データ量の多いアプリケーションのウェブページのロードを高速化します。」
• Fastly：解説ページは、利用者の地理的な位置に基づいてコンテンツを届ける分散サーバーの仕組みと説明しています。
• Google（Cloud CDN）：「Cloud CDN（コンテンツ配信ネットワーク）は、Google のグローバル エッジ ネットワークを使用して、ユーザーの近くからコンテンツを配信します。」

CDNはどう動くか。配信元のサーバーと、近くに置いたコピー

Akamaiの説明では、元のデータを持つサーバーが「オリジンサーバー」（配信元）、世界各地に置かれてコピーを持つサーバーが「エッジサーバー」で、置き場所はPoP（point of presence）とも呼ばれます。コピーを一時的に保存して使い回すことが「キャッシュ」です。

AWSの解説ページは、静的なコンテンツ（ロゴやヘッダー画像のように、利用者ごとに変わらないデータ）を例に、流れを次の順で書いています。

1. 配信元から遠い訪問者が、初めてそのコンテンツを求める。
2. リクエストは配信元に届いて返事が返り、同時に、その訪問者に地理的に最も近いCDNのPoPにも返事のコピーが送られ、保存される。
3. 次に、その訪問者か同じ場所の別の訪問者が同じものを求めると、「オリジンサーバーではなくキャッシュサーバーがレスポンスを送信します」（AWSの原文）。

「近くのPoPに届く」ところにはDNS（名前から住所を引く仕組み。DNSとは）が関わり、Amazon CloudFrontの開発者ガイドは、DNSがリクエストを、通常は遅延の面で最も近いPoPへ振り分けると書いています。Google Cloudの文書は、キャッシュに返事があって返す場合を「キャッシュ ヒット」、初めて求められて返せない場合を「キャッシュミス」と呼び、「キャッシュの特性上、特定のリクエストに対するレスポンスがキャッシュから返されるかどうかを予測することはできません」とも書いています。

すべてがコピーされるわけではなく、コピーは古くなる

AWSは、ニュースフィードやログイン状態のような動的なコンテンツについて「動的ウェブコンテンツではキャッシュはうまく機能しません。これは、ユーザーのリクエストごとにコンテンツが変化する可能性があるからです。」と書いています。Google Cloudの文書は、コピーが古くなる点も書いています。

「たとえば、撮影されて 1 時間以内の写真を保存する URL の場合、レスポンスの有効期限を 1 時間以内に設定します。こうしないと、古い写真がキャッシュから提供される可能性があります。」

CDNと取り違えやすいもの

• ホスティング（サイトのデータを置く契約）：Cloudflareは、CDNはコンテンツを置く場所ではなく、ホスティングの代わりにならないと書いています。
• ブラウザのキャッシュ：RFC 9111は、複数の利用者が使い回す「shared cache」と、1人専用の「private cache」を分けています。CDNのコピーは前者、ブラウザの中のコピーは後者で、設定画面で消せるのは後者です（筆者の読み。手順はブラウザのキャッシュをクリアする方法）。更新したはずのページが古く見える原因は、どちらにもありえます。

身近なところでは、動画・ニュース・ゲームの配信に使われている

AWSの解説ページは、Amazon CloudFrontの利用例として、ロイターのニュース配信、Huluの「20 GBps を超えるデータ」のストリーミング、ゲーム会社Kingの「毎日数百テラバイト」の配信を載せています（数字の時点はページに無し）。

筆者がこのMacで確かめたこと。応答ヘッダーとCNAMEに、CDNの名前は出るのか

2026年10月13日3時32分45秒から3時33分59秒（日本時間）に、このMacで次の2つを読むだけの操作をしました。設定は何も変えていません。curl -sI は、ページの中身ではなく返事の頭（応答ヘッダー）だけを求める操作で、転送（リダイレクト）先は追っていません。dig +short は名前に対応する住所を引く操作で、別名（CNAME）の連鎖だけを残しました。

対象は、府省庁とIPAなど公的機関の go.jp のドメイン8つ（ipa・soumu・digital・nisc・cyber・jma・npa・mhlw）、大手2つ（www.apple.com/jp・www.nhk.or.jp）、CDN事業者5社の自社サイト（Cloudflare・AWS・Fastly・Google Cloud・Akamai）の計15です。Cookieの値、リクエストごとの識別子、場所を示す地域コードは、保存する前に伏せました（Cloudflareの文書は、Cf-Rayの末尾3文字をデータセンターの場所と書いています）。

ヘッダーの項目名か値に事業者名（cloudfront・cloudflare・fastly・akam）が入っていたのは10サイト（CloudFront 7、Cloudflare・Fastly・Akamai 各1）です。残る5サイトのうち www.mhlw.go.jp・www.apple.com・www.nhk.or.jp は、ヘッダーの server は「Apache」「Apple」「nginx」でしたが、名前解決の連鎖が「edgekey.net」から「akamaiedge.net」へ続きました（Akamai自身のサイトも「www.akamai.com.edgekey.net」を指しました）。逆に www.cyber.go.jp・www.jma.go.jp・www.cloudflare.com は、CNAMEの連鎖が出ませんでした。www.soumu.go.jp と cloud.google.com は、どちらにも出ませんでした。名前が出ないことはCDNを使っていない証拠にならない、というのが筆者の読みです。

「コピーが返ってくる」ことを数字で見る

同じURLに6秒おきに3回、HEADを送りました（3時32分46秒〜3時33分35秒）。

RFC 9111は、age を、応答が配信元で作られた（または検証された）時からの、送り手の推定時間（秒）と定めています。www.digital.go.jp の303,575秒は3日12時間19分で、応答の date は2026年10月9日6時13分11秒（UTC）のまま、6秒おきの3回で age が6秒ずつ増えました。AWSの公式のQ&A（re:Post Knowledge Center）は、x-cache が Hit from cloudfront なら「the request came from the cache of the edge location」（エッジのキャッシュから返った）と書いています。同じコピーが返り続けていた、というのが筆者の読みです（推測。CloudFrontの中は見ていません）。このページには「cache-control: max-age=0,no-cache」も付いていますが、CloudFrontの開発者ガイドは、運営者が決める最小TTL（キャッシュに置く最短の時間）が0より大きければ、no-cache があってもその時間はキャッシュすると書いています（このサイトの設定は外からは分かりません）。

www.ipa.go.jp は3回とも Miss で、応答には「cache-control: no-store」が付いていました。RFC 9111は、キャッシュに保存を禁じる指示と定めています。Missの理由まで筆者は確かめていません。

自分で見るには、Chromeの公式ドキュメントによると、開発者ツールをMacでは Cmd＋Option＋I、Windowsでは F12 または Ctrl＋Shift＋I で開き、Network パネルのリクエストの「Headers」タブで Response Headers を見ます。

CDNの障害で、多くのサイトが同時に見られなくなったことはあるか。事業者の公式報告4件

あります。事業者が自分で公開した報告を4件引きます（時刻は各社の報告のUTCで、日本時間への換算は筆者。報道は引いていません）。

• 2021年6月8日 9時47分（日本時間18時47分）・Fastly：「We experienced a global outage due to an undiscovered software bug that surfaced on June 8 when it was triggered by a valid customer configuration change.」（訳：見つかっていなかったソフトウェアの不具合が、顧客の有効な設定変更で呼び出され、世界規模の障害になった。）報告は、ネットワークの85%がエラーを返し、49分以内に95%が正常に戻ったと書いています。
• 2021年7月22日 15時45分（日本時間23日0時45分）・Akamai：「a software configuration update triggered a bug in our Secure Edge Content Delivery Network impacting that network's domain name service (DNS) system」（訳：ソフトウェアの設定更新が Secure Edge CDN の不具合を呼び出し、そのネットワークのDNSの仕組みに影響した。）影響は一部の顧客サイトに最長1時間で、報告は「this was not a cyberattack」（サイバー攻撃ではない）とも書いています。
• 2025年11月18日 11時20分（日本時間20時20分）・Cloudflare：「Cloudflare's network began experiencing significant failures to deliver core network traffic.」（訳：Cloudflareのネットワークが、コアの通信を届ける際に大きな障害を起こし始めた。）報告は、利用者にはCloudflareのネットワーク内の障害を示すエラーページとして現れ、原因はデータベースの権限変更でBot Management（ボット対策の機能）のファイルが2倍の大きさになったことで、サイバー攻撃ではないと書いています。コアの通信は14時30分（日本時間23時30分）までにほぼ正常になり、17時06分（日本時間19日2時6分）にすべて正常に戻りました。
• 2025年12月5日 8時47分（日本時間17時47分）・Cloudflare：報告は、9時12分に解消し影響は合計約25分（「~25 minutes total impact」）で、影響を受けたのは一部の顧客で、その分がCloudflareの配信するHTTP通信全体の約28%にあたり、React Server Componentsの脆弱性への対応中に行った、WAF（攻撃を防ぐ機能）の試験用の仕組みを止める変更が原因で、これもサイバー攻撃が原因ではないと書いています。

Cloudflareは2026年5月1日の投稿で、2025年の2件を避けられたはずの再発防止の作業を完了したと書いています（同社自身の評価）。4件の報告が書く直接のきっかけは、どれもソフトウェアの不具合や設定の変更でした。

利用者の側でできること、できないこと

Cloudflareのヘルプ（Cloudflare 5xx errors。表示は2026年6月5日の更新）は、こう書いています。

「Cloudflare Support only assists the domain owner to resolve issues. If you are a site visitor, report the problem to the site owner.」

（訳：Cloudflareのサポートが助けるのはドメインの所有者だけである。サイトの訪問者である場合は、問題をサイトの運営者に報告する。）

同じページは、サイトの運営者がホスティング事業者に連絡する時に伝える情報として、エラーの番号とメッセージ、時刻とタイムゾーン、エラーが出たURLを挙げています。

CDNのキャッシュを消す操作は、本記事が読んだ2社の文書では、契約者の側の操作です。Google Cloudの文書は「無効化は、Google Cloud CLI または Google Cloud コンソールで行うことができます」と書き、Cloudflareの文書は、消す操作の上限を「per account」（アカウントごと）に置いています。訪問者がCDN側のキャッシュを消す方法は、本記事が読んだ文書には見当たりませんでした。

次の3つは、公式の文書の記述ではなく、筆者の提案です。

1. 時間を置いて開き直す。 先の4件では、復旧は事業者側の作業（設定の取り消しなど）で行われました。
2. ほかのサイトが開けるか見る。 開けないのが自分の回線なら、CDNは関係ありません。手順はWi-Fiにつながらない時の確かめ方にあります。
3. 事業者の状況ページを見る。 開発者ツールで事業者が分かれば、公開ページがあります。本記事が開けたのは、Cloudflare Status・Fastly Status・Google Cloud Service Health です（2026年10月13日3時27分）。

CDNについて、本記事が確かめていない点

• 15サイトの結果は、3時32分前後の1回分のHEADの応答です。GETや時刻を変えた結果とは違う可能性があり、公的機関や大手サイトの傾向としては読めません。
• CloudFrontの開発者ガイド（PDF版・全1,487ページ）を全文検索した範囲では、x-cache の値を定めた節は見当たりませんでした。Hit の意味は、ログの項目 x-edge-result-type の定義（「The server served the object to the viewer from the cache.」）と上のQ&Aで確かめています。Fastlyの x-cache は、公式のドキュメントが「Indicates whether the request was a HIT or a MISS.」（HITかMISSかを示す）と書いています。
• 総務省の「国民のためのサイバーセキュリティサイト」の用語集（取得した11ページ）にCDNの項は見当たりませんでした。IPAの解説は確かめていません。
• 障害の公式報告は、取得した3社4件の範囲です。AWSやGoogleのCDNの障害報告、国内事業者のCDN、報道が伝えた個別のサイトへの影響、各社の最新の稼働状況は調べていません。

CDNの定義・仕組み・障害報告に引いた公式ページ（2026年10月13日取得）

取得した時刻は、出典の一覧の各行に書きました（3時21分〜3時34分。後から足した資料は7時37分〜7時45分）。