はじめに：「定番の質問」が示す、現在の常識の限界
Cloudflareのアーキテクチャについて、インフラエンジニアの方々とお話していると「ある挙動」についての確認を求められます。
「東京のデータセンターに障害が出た場合、次はどの拠点（大阪、シンガポール等）に切り替わる設定になっていますか？ その順序は決まっていますか？」
これは、従来のオンプレミスやパブリッククラウドで長年システムを構築してきたエンジニアにとって、極めて真っ当な確認事項です。「プライマリがダメならセカンダリ」という冗長構成を明確に定義することは、システムの信頼性を担保する上で必須の作法だったからです。
しかし、この質問には無意識のうちに唯一の選択肢としている「インスタンス運用」という、コスト構造に限界を迎えている巨大な課題があります。
今回は、この質問を入り口に、私たちの現状、そして次世代のインフラがもたらす解決策について考えます。
1. インスタンス運用の限界
なぜ、私たちは「次の場所」や「順序」を気にするのでしょうか。
それは、従来のクラウドが「特定の場所（リージョン）に、特定のスペックの箱（インスタンス）を用意する」モデルだからです。
このモデルでは、エンジニアは常に以下の「スケールとコストのジレンマ」と戦わなければなりません。
ピーク時のトラフィック予測（キャパシティプランニング）：
「来週のキャンペーンでユーザーが急増するかもしれない」。そのために、あらかじめインスタンスを増強しておく必要があります。読み間違えればサーバーダウン、機会損失です。
「待機」に対するコスト（オーバープロビジョニング）：
スパイクに備えて多めにインスタンスを起動しておけば安心ですが、アクセスが少ない夜間でも課金は発生し続けます。つまり、「何もしていないサーバー」に対して高いコストを支払い続けているのです。
オートスケーリング運用の煩雑さ：
「負荷に応じて自動で増減させればいい」と言いますが、閾値の設定、ウォームアップの時間、スケールアウトの速度……。これらを適切に設計・チューニングし続けるには、高度なスキルと多大な人的コスト（運用工数）が必要です。
「東京が落ちたら次は大阪」と決めたくなる心理は、「大阪にも同じだけのキャパシティを用意し、そのコストを計算し、切り替え手順を確立しなければならない」という、運用設計の重圧から来ているのではないでしょうか。
2. 「従来型クラウド」と「エッジクラウド」
ここで、視点を変える必要があります。Cloudflareが提唱するモデルは、単なる「便利なクラウド」ではありません。アーキテクチャの思想が根本的に異なります。
従来型クラウド（Centralized Computing）：
「処理をする場所（リージョン）」が決まっています。ユーザーは遠く離れたデータセンターまでデータを運び、そこで処理を行い、結果を持ち帰ります。「その場所が落ちたらどうするか」は最大の関心事の一つになります。また、サービス提供においてスケール設計にも気を使う必要があり、ボトルネックを生みやすいです。
エッジクラウド（Distributed Computing）：
「処理をする場所」が固定されていません。ネットワークそのものがコンピュータです。ユーザーのすぐ近く（エッジ）で処理が行われるため、高速です。そして、スケールを設計する必要がなく、ボトルネックを生みにくく、コスト構造にも優れます。
これを説明するにはまず「Anycast」の概念理解が必要です。
Cloudflareのネットワークでは、「東京の次は大阪」といった固定された切り替え順序は存在しません。Anycast技術により、世界中のデータセンターが単一の巨大なネットワークとして振る舞います。
もし東京への経路が閉ざされれば、トラフィックは「その瞬間に最も合理的で近い場所」へ自動的に吸い込まれます。場所の切り替えを人間が設計する必要はありません。ネットワークが自律的に行います。
3. 「真のサーバーレス」は、Anycastとエッジでのみ実現する
Anycastによって「場所」から解放されたとき、今度は「スケール」の概念も変わります。
世の中には多くの「サーバーレス」サービスが存在しますが、その多くは実は「リージョン依存」です。「サーバーレス」と言いながら、「どのくらいのサイズを」「どこのリージョンで動かすか」を選択しなければならないものが大半です。
これに対し、Cloudflare Workers / Workers AI などが実現するのは「真のサーバーレス」です。
場所からの解放:
コードをデプロイすれば、世界中の数百拠点で同時に待機状態になります。開発者は「どこで動かすか」を意識する必要すらありません。
予測不要のオートスケール:
1リクエストが来れば1つ動き、100万リクエストが来れば100万動く。事前のプロビジョニングも、オートスケーリング設定も不要です。
コスト構造の変革:
リクエストが処理されている「瞬間（ミリ秒単位）」にしか課金されません。アクセスがない時間に「待機」しているサーバーにお金を払う必要はゼロになります。
DDoS も飲み込むスケーラビリティ:
インスタンス数に上限がある世界とは異なり、ネットワーク全体で負荷を受け止めるため、突発的なアクセス集中や攻撃ですら、特別な対応なしに処理します。
Anycastによるトラフィックの誘導と、エッジでの瞬時のコード実行。この2つが揃って初めて、私たちは「インスタンスの管理」から真に解放されるのです。
ブログの抜粋：
Cloudflareにおける重大な決定の一つが、我々が「（Amazonの創設者である）ベゾスのルール」と呼ぶ規則の実施でした。必要なことは2つです。
- CloudflareのエンジニアがCloudflareのために新機能を構築する時は、できる限りWorkersを使わなければならない。
- Cloudflareのために構築するAPIまたはツールは、サードパーティのWorkers開発者も自由に使えなければならない。
4. AI時代こそ、インスタンスベースの限界が露呈する
そしてこの議論は、現在爆発的に普及している AI の分野でこそ、より深刻な問題となります。
AIを動かすためのGPUインスタンスは非常に高価です。
そして、IT予算は無限ではありません。AIにリソースを注ぐ一方で、ランサムウェア対策やゼロトラストの実装といった「セキュリティ」も、企業の存続に関わる最重要課題であり、予算を削ることは許されません。
従来のマインドセットで「AI サービス」を作ろうとすれば、高価なGPUインスタンスを確保し、アクセスが来ない時間帯も維持費を払い続け、急なトラフィック増には「インスタンス確保競争」に勝たなければなりません。トラフィックが増えれば増えるほど、このコストと管理の難易度は指数関数的に跳ね上がります。
ここでも、答えはエッジクラウドにあります。
AI を、エッジで行う「Workers AI」のような仕組みを使えば、「動作した分だけ課金」というモデルが可能になります。高価なGPUを専有して待機させる無駄から解放され、AIの民主化をコスト面からも技術面からも支えることができるのです。
そして Cloudflareのエッジクラウドでは、「ネットワークそのもの」が巨大なセキュリティバリアとして機能します。
サービスが走る場所は、すでに世界最高レベルのDDoS保護が備わっており、WAF そしてゼロトラストなどのオプション機能に同一ポータルから直ぐにアクセスできます。ユーザーは「サービスを作り、動かすこと」だけに集中しやすい環境が得られます。
おわりに：「運用」から「価値創造」へ
冒頭の問いへの本質的な答えはこうかもしれません。
「もう、その心配（場所の設計やキャパシティの確保）はしなくていいんです」
インスタンスが起動しているか監視し、トラフィックを注視し、空転しているサーバーにコストを支払う。そんな「インフラのお守り」にエンジニアのリソースを割く時代は終わりつつあります。
場所（リージョン）の制約はAnycastが取り払い、容量（スケール）の制約はエッジ上のサーバーレスが解決します。
私たちがすべきことは、複雑なフェイルオーバーの順序やスケールを設計することではありません。「ネットワークそのものがコンピュータ」となった基盤の上で、どのようなビジネス価値を生み出すかを考えることなのです。
そしてこの基盤決して新しいものではありません。Cloudflare が 15年間で作り上げて、実績を重ね続けた基盤なのです。
Cloudflare Reference Architecture