なぜサーバーにCDNを挟むのか調べたら、Webの仕組みそのものが見えてきた


Webサイトを公開するなら「CDNを使うと速くなる」という話はよく聞きます。

しかし私はふと疑問に思いました。

「なぜわざわざサーバーの前にCDNを置くのだろう?」

調べ始めると、CDNだけではなく、オリジンサーバー、リバースプロキシ、エッジコンピューティング、Cloudflare Pagesなど、現在のWebを支える技術がすべてつながって見えてきました。さらに実際の通信ログを追いかけたことで、教科書的な説明が「本当にそうなっている」と腹落ちする体験にもなりました。

今回はその内容をまとめます。


オリジンサーバーとは?

オリジンサーバーとは

「元データを持っているサーバー」

です。

例えばWordPressなら

Xserver
├ WordPress
├ PHP
├ MySQL
├ 画像
└ CSS

これがオリジンサーバーです。

利用者がアクセスすると

利用者

オリジンサーバー

毎回ここまで通信します。アクセスが増えるほどサーバーには負荷がかかります。


CDNとは?

CDN(Content Delivery Network)は

世界中にある配信サーバー

です。例えば東京・大阪・シンガポール・ロンドン・ニューヨークなどにエッジサーバーがあります。

利用者は

利用者

東京エッジ

へアクセスします。画像やCSSなどは

東京エッジ
├ logo.png
├ style.css
└ app.js

から返されます。そのためオリジンサーバーまで行かなくても済みます。

エッジサーバーとは?

エッジとは利用者に近い場所という意味です。

出版社が本社だとすると、全国の図書館が東京・大阪・福岡の支店にあたります。出版社まで行かなくても近所の図書館で本を借りられる——これがエッジの考え方です。


オリジンサーバー+CDN という現在の標準構成

利用者

Cloudflare

オリジンサーバー

Cloudflareはキャッシュ・HTTPS・DDoS対策・WAF・リバースプロキシなども担当します。オリジンサーバーはPHPやMySQLなど動的処理だけを担当します。

なぜCDNを挟むのか?理由は3つ

① 高速化 画像などは東京の利用者なら東京エッジから返します。海外サーバーまで行きません。

② サーバー負荷軽減 1000人が画像を見る場合、CDNが返せばオリジンサーバーは1000回処理しなくて済みます。

③ セキュリティ 利用者からはCloudflareしか見えません。オリジンサーバーのIPアドレスは一般公開されません。さらにDDoS対策・WAF・Bot対策もCloudflareが担当します。


リバースプロキシとの違い

実はCloudflareはCDNでもありリバースプロキシでもあります。

利用者

Cloudflare

オリジンサーバー

最初にCloudflareが通信を受けます。そして「キャッシュがあるか/Workersを実行するか/オリジンサーバーへ送るか」を判断します。まるで巨大な受付係です。


実際の通信を覗いてみた話

CDNを挟む構成と世界各地のエッジサーバー

ここまでは教科書的な説明ですが、実際にあるサイトの通信ログをブラウザの開発者ツールで観察してみると、この3層構造がそのまま現れていました。

① 速度    : タイル系JSONファイル → エッジが直接返す(東京なら東京から)
② 経済性  : 詳細データAPI → クリック時だけオンデマンドで叩く(無駄な負荷をかけない)
③ 防御    : cdn-cgi/challenge-platform → ボット/スクレイパーをエッジで判定・遮断

特に③が興味深く、cdn-cgi/ というURLパスはCloudflareがオリジンサーバーを経由せず、エッジ自身が処理する特別なパスでした。jsd(JS Detection)という文字列が含まれており、ブラウザが本物の人間が操作しているものかを判定する仕組みが動いています。

リクエスト先のIPアドレスを見ると 2606:4700:: という、Cloudflareに割り当てられたIPv6レンジでした。つまりこの通信は最初から最後までCloudflareのエッジ止まりで、オリジンサーバーには一切到達していません。

ブラウザ


Cloudflareエッジ(ここで完結)


オリジンサーバー(ここには来ていない)

これは「オリジンIP秘匿」が実際に機能している様子そのもので、セキュリティが単なるDDoS対策・WAFのレベルから、ブラウザそのものの真贋判定まで進化していることがよく分かる事例でした。


Cloudflare Pagesは何が違う?

私は現在、Astro と Cloudflare Pages を使っています。構成は

Mac

GitHub

Cloudflare Pages

世界中のエッジ

利用者

になります。WordPressのようなオリジンサーバーはありません。GitHubへ git push すると、Cloudflareが HTMLをビルドし、世界中へ配信してくれます。つまりホスティングとCDNを同時に提供しているサービスです。

オリジンサーバーは本当に無いの?

これは最初に疑問に思ったところでした。

結論は、データは必ずどこかに保存されています。Cloudflare Pagesでは、Cloudflare内部の分散ストレージに保存され、そこからエッジへ配信されます。つまり「オリジンサーバーが無い」ではなく、自分で管理するオリジンサーバーが無いという意味なのです。

Cloudflare Workersとは?

Workersはエッジで動くJavaScriptです。

利用者

東京エッジ

Worker

D1(Database)

という構成になります。PHPサーバーが不要になり、API・ログイン・レビュー投稿などをエッジで処理できます。

管理画面はWordPressのように最初から用意されてはいないので、Astro + Workers構成では自分で作る必要があります(Admin → Worker → D1)。最初は少し大変ですが、必要な機能だけ作れるのでシンプルです。

スパム対策にはTurnstile・レート制限・JWT認証・Bot対策・メール認証などを組み合わせることで、かなり安全なサイトを作れます。


現代のWebは役割分担している

以前はレンタルサーバーだけで全部やっていました。現在は

GitHub

Pages

Workers

D1

R2

CDN

のように専門サービスへ分割されています。そのため高速で、スケールしやすく、メンテナンスもしやすくなっています。


Cloudflareが「ほう助」と認定された訴訟

ここまではCDNの良い面を見てきましたが、技術には必ず光と影があります。

補足として、悪質なサイトは**防弾サーバー(オフショアサーバ)**という、ログが残らないサーバーをさらに挟んで匿名性を高めるケースがあるそうです。

Cloudflareは実際に訴訟を受けています。理由は違法配信ほう助。海賊版サイトが著作権侵害を行っていることを通知していたにもかかわらず、通知から1カ月以内に配信を停止しなかった点が、出版権の侵害にあたるとされました。

① 具体的な侵害の通知を受けていた

② 技術的にサービス停止が可能だった(やればできた)

③ 契約時に運営者の身元確認(KYC)をしていなかった、責任あり

これら3つが揃って「ほう助」と認定された

もしCDN/プロキシのようなサービスを将来作ることがあれば、この判決から得られる実務的な教訓は次の3点です。

  • 侵害通知を受け取る窓口(report / abuseフォーム)をきちんと持つ
  • 通知を受けたら、合理的な期間内に一次対応するワークフローを持つ
  • 契約者の本人確認を、最低限のレベルでも実施する

CDN事業者の立場で考えると、これは構造的に板挟みです。

判断しすぎると:表現の自由・検閲の問題になる 判断しなさすぎると:海賊版や個人情報晒しサイトに、技術的な「隠れ蓑」と「高速配信網」をタダで提供してしまう

実際に個人情報を晒す違法サイトの通信を調べたとき、Cloudflareのボット対策(challenge-platform)がきちんと機能している様子を見ましたが、それは同時に「運営者のオリジンIPに一切近づけない」という防御にもなっていました。CDNは技術的に中立であり、それをどう使うかは運営者次第——という構造がよく分かる事例でした。


最後に

最初は「CDNってキャッシュサーバーでしょ?」くらいに思っていました。

しかし調べていくと、CDNは単なるキャッシュではなく、セキュリティ・リバースプロキシ・エッジコンピューティング・API・ホスティングまで担う巨大なプラットフォームへ進化していました。そして実際の通信ログを追いかけたことで、その仕組みが「教科書通りに本当に動いている」ことも確認できました。

そして私自身も現在使っている Astro + GitHub + Cloudflare Pages は、その最先端の考え方の上に成り立っていることを知りました。

今後はWorkersやD1も学び、サーバーをほとんど意識せずに動くモダンなWebサービスを作っていきたいと思います。

**Webの世界は「サーバーを借りる」から、「世界中のエッジで動かす」時代へ移り変わっています。**それを理解できたことが、今回一番の収穫でした。