—

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

slug: “cloudflare-cdn-architecture”

pubDate: “2026-06-29”

tags: [“インフラ”, “CDN”, “Cloudflare”, “セキュリティ”, “Web技術”]

heroImage: “/images/cloudflare-hero.png”

—

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を実行するか／オリジンサーバーへ送るか」を判断します。まるで巨大な受付係です。

—

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


ここまでは教科書的な説明ですが、実際にあるサイトの通信ログをブラウザの開発者ツールで観察してみると、この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 は、その最先端の考え方の上に成り立っていることを知りました。

また更に、VPNからCloudflare＋ゼロトラストにも以降しているとのことで「個人が社内システムにアクセスする手段」としてのVPNは、明確に終わりが見えている技術です。一方で「拠点同士をつなぐ」役割のVPNは、SASEという大きな枠組みの中に統合されつつも、しばらくは形を変えて残ります。

エンジニアとして実務に落とすなら、「今からVPNを新しく導入する理由は薄くなっている。既存のVPN運用も、置き換えの計画は持っておいた方がいい」というのが現時点での結論でした。

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

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