Cloudflare、こんなに無料でいいんだろうか ― 「クラウド」の定義が書き換わったことに気づかない人々へ

全世界で数百万人が同時にアクセスするようなサービスを設計し、AWSに毎月、数十万から数百万円という「血の滲むようなコスト」を支払い続けてきた立場から言わせてもらえば、今のCloudflareが提示している世界観は、もはや「CDN」なんていう可愛い言葉で呼べるものではない。かつて私たちがオンプレミスからAWSへ移行した時に感じたあのパラダイムシフトが、今、Cloudflareという「Supercloud」によって、さらに残酷な形で繰り返されている。

あえて、いま提供されているサービスを地べたから天井まで並べてみるとこんな感じだ。Cloudflare DNS, CDN, WAF, DDoS Protection, Bot Management, SSL/TLS, Zero Trust, Access, Gateway, WARP, Tunnel, Workers, Workers KV, Durable Objects, D1 (SQL Database), R2 (Object Storage), Workers AI, Vectorize, Hyperdrive, Pages, Images, Stream, Calls, Turnstile, Email Routing, Magic Transit, Magic WAN, Spectrum, Load Balancing, Pub/Sub, Queues, Analytics Engine, Zaraz, Pages Functions, Health Checks, Page Shield, Area 1 Security... これらがすべて、エッジという「究極の場所」で動き、「サーバー管理」を消し去った。しかも個人や小規模プロジェクトならほとんど「無料枠」の範囲内で、数千から数万人規模のアクティブユーザーを捌けてしまう。

コロナ禍に起きた「進化」

この進化のスピードを振り返ると、彼らがどれほど本気で既存のクラウドベンダーや中間層を「破壊」しにきているかがわかる。

2018年に正式リリースされたWorkersは、今や1日10万リクエストまで無料で、サーバーレスの常識だったデータ転送量（エグレスフリー/Egress Fee）の概念を過去のものにした。

2021年に登場したPagesは、静的サイトの帯域幅もリクエスト数も「無制限無料」という、インフラ屋泣かせの条件を突きつけてきた。

2022年にGA（一般公開）されたR2ストレージは、10GBの保存容量に加え、読み込み1,000万回、書き込み100万回が毎月無料で、何よりS3で我々を苦しめてきた「データ取り出し料金」を完全に撤廃した。

さらに、2024年に正式リリースされたSQLデータベースのD1に至っては、1日500万行の読み込み、10万行の書き込みを無料で提供している。

社内ツールを守るZero Trust（旧Teams、2020年〜）も、50ユーザーまでなら1円も払わずにVPN不要の環境が構築できてしまう。

いまだに「オンプレかクラウドか」なんて議論をしているのは、もはや時間の無駄でしかない。複雑怪奇なVPCの設計、サブネットの管理、NATゲートウェイのコストに頭を悩ませ、数千行のTerraformコードをメンテナンスするためにエンジニアの工数を溶かしてきた日々を思い返すと、Cloudflare WorkersとR2が提示する「インフラを感じさせないインフラ」は、魔法のようにさえ見える。正直、Stripeの決済系のような強固な金融エコシステムさえあれば、他のクラウドベンダーの出番はほとんどなくなってしまうのではないか。

IT技術の営業トークが過去のものになる

現場を知らない人間たちが机上でこねくり回した「モダンなアーキテクチャ」や「エンタープライズ向けソリューション」という言葉。それらは確かに「IT」と呼ばれてはいるが、「過去のイット(それ)でしかない」。令和の現在、「最前線の枯れたCloudFlare技術スタック」で作ったITサービスからのソレは、もう何光年も遠く離れた過去の話になっているのかもしれない。もちろんインフラ側、エッジ側の話なので、実際に我々ユーザーがスマホ経由で触れ、構築し、ユーザーに届けている「ITサービス」の最前線の話なのであるが。

かつてオンプレミスからAWSへ移行した時のあの衝撃以上の衝撃が、今、Cloudflareという「Supercloud」によって、さらに残酷な形で繰り返されている。数千万人のトラフィックを捌き、毎月数百万円のインフラコストと、それを維持するための膨大なマイクロサービスの知識、Cloudformation, Terraformのコード、そして人的工数を見続けてきた立場からすれば、今のCloudflareが提示している世界は、もはや「CDN」なんていう可愛い言葉で片付けられるものではない。

「スケーラビリティは？ これ以上上がらないのでは」という疑問

Cloudflareをちょっと触ってみて、ちょっとしたサービスを使ってネガティブな視点に立ってみよう。例えば「スケーラビリティは？ これ以上上がらないのでは」という疑念をぶつけることもできる。これは、従来の「データセンター」という箱の概念に囚われていると必ず出てくる、非常に鋭い指摘かもしれない。しかし、Cloudflareの設計思想は、私たちが慣れ親しんだ「サーバーを増強してスケールさせる」という発想とは根本から異なる。彼らのスケーラビリティに天井が見えない理由を、現場の視点で解剖してみた。

「スケールアップ」ではなく「Anycastによる分散」の極致

従来のクラウド（AWSなど）は、特定のリージョンの中にインスタンスを立て、負荷に応じてそれを増やす。いわば「一つの大きなバケツに蛇口を増やす」スケーラビリティです。

対して、CloudflareはAnycast（エニーキャスト）という魔法を使っている。 世界300都市以上に散らばるすべてのデータセンターが、「同じIPアドレス」で待ち構えている。

https://www.cloudflare.com/ja-jp/learning/cdn/glossary/anycast-network/

世界規模のロードバランシング：1箇所の拠点が限界に達しそうになれば、物理的に最も近い別の拠点にトラフィックが勝手に吸い込まれる。

単一障害点がない：彼らにとっての「スケーラビリティ」とは、ネットワークの帯域（現在は300Tbps超）そのもの。この「地球規模の網（ファブリック）」がパンクする時は、インターネットそのものが死ぬ時ともいえる。

「コンテナ」さえ捨てた、Isolateによる超軽量スケール

「Workersのスケーラビリティなんて、所詮はJavaScriptでしょ？」と侮る人もいるかもしれない。まず「V8ですが」で通じればいいんだけど。Cloudflare Workersが採用しているのは、Dockerのような重たいコンテナではなく、Google Chromeでも使われているV8 Isolateという仕組み。

オーバーヘッドがほぼゼロ：コンテナの起動（コールドスタート）に数秒かかるAWS LambdaやVercelのコールドスリーブに対し、Workersはミリ秒以下で起動する。

高密度な詰め込み：一台のサーバーで数千、数万の隔離されたスクリプトを同時に走らせることができます。

真のサーバーレス：ユーザーは「何台のサーバーが必要か」を考える必要すらない。リクエストが来た瞬間に、世界中の最も近い場所で実行される。これ以上のスケーラビリティはない。インターネットそのものの再設計。

課題は「ステート（状態）」の共有だけ

唯一の「天井」と言われていたのが、世界中に分散したデータの同期（Consistency）。しかし、これも以下の技術で解決されつつある。

Durable Objects：世界で唯一の「状態」を保証するオブジェクト。しかもTCPではなくWebsocket。

D1 / Hyperdrive：既存のDBにエッジから超高速にアクセスする仕組み。

「ステート（状態）」の呪縛からの解放

Lambdaでシステムを組もうとすれば、必ず「状態をどこに置くか」という壁にぶち当たる。RDS（データベース）に繋げば、複雑なVPC設計と高価なNATゲートウェイ（月額32ドル〜＋通信料）が必須になり、S3にデータを置けば、取り出すたびに「Egress Fee（データ転送量）」という名の罰金を徴収される。これらはすべて「技術的な制約」ではなく、単なる「ビジネスモデルの制約」だった、ということがよくわかるし、MVPを達成する上で多くの足枷となっていた。

Cloudflareは、この呪縛を具体的な「数字」で笑い飛ばしている。

R2ストレージ (2022年〜): 保存容量10GBまで無料。最大の特徴は「データ転送手数料が完全に0円」なことだ。S3なら数千ドルかかるような大規模配信も、ここではインフラの「地平線」の一部に過ぎない。

D1 SQL Database (2024年〜): 1日500万行の読み込み、10万行の書き込みが無料。エッジで動くSQLiteが、ステート管理のラストワンマイルを埋めてくれる。

Durable Objects (2021年〜): これこそが真のゲームチェンジャーかもしれない。サーバーレスでありながら「状態」を持ち、Websocketを繋ぎっぱなしにできる。チャットも、共同編集も、マルチプレイヤーゲームも、Redisや複雑なオーケストレーションなしに、数行のコードで世界中にスケールする。

LambdaでグローバルやDBとの接続でステートを管理していた。AIとの会話コンテキストをどこに保存するか悩んでいた。DOが使えるならサーバーレスでありながら、エッジで「状態」を保持し続けられる。AIとの膨大な会話コンテキストを、わざわざ遠くのDBへ取りに行く必要はない。DOがその場で抱え込み、Websocketを繋ぎっぱなしにして、低レイテンシで処理し続ける。もはやRedisも複雑な同期処理もいらない。

AIが「エッジ」でスケールする新時代（2026年の現実）

もうこれ以上やめて！と思いたくなるCloudflareのイノベーションだが、この予測を最も裏切っているのがWorkers AI。今、彼らは全世界のエッジポイントにNVIDIA製のGPUを爆速で配備し続けている。

これは「推論の地産地消」。巨大なモデルを中央のデータセンターで動かすのではなく、ユーザーの目と鼻の先でAIを動かす。そして「スケーラビリティの再定義」であるといえる。ユーザーが増えれば増えるほど、各拠点のGPUが並列で動くだけ。中央集中型のAPI（OpenAIなど）が抱える「混雑による遅延」という天井を、物理的な距離で破壊していく。

ちなみに私はWorkersAIを使っていない。
さくらインターネットだったり、オンプレのGPUサーバーと組み合わせればいいことなので。

既存の「IT商人」への宣戦布告

「一体どんな経営者がこれをやっているんだ？」という疑問が湧くのは当然だ。CEOのマシュー・プリンス（Matthew Prince）たちの思想には、これまでの「ITベンダー商人」とは根本的に違う、ある種、既存の不透明なITビジネスモデルに対する「死ね！」というほどの強烈なメッセージを感じる。

彼らが一貫して戦っているのは、クラウド界の「不動産屋」たちだ。 AWSやGCPのような既存の巨人が、データの出し入れに高額な「通行料（Egress Fee）」を課し、一度入ったら二度と出られない「ホテル・カリフォルニア」のようなロックイン構造で肥え太る。Cloudflareはそれを「インターネットの歪み」として真っ向から否定している。実は個人開発者に人気のVercelだって、ベンダーロックインだらけだ。Supabase, Neon, VectorDBのような「一見素敵な開発者体験」に何度も苦しめられてきた私がいう。NodeJSのコードを読み直せ、そのプロジェクトにSSRやISRは本当に必要か？Nodeセキュリティ対策で泣いた日々を思い出してほしい。

cronやISR（Incremental Static Regeneration）
「静的ページを裏側で定期的に再生成する」はこんな感じでGithubActionsを書けばできる。

# .github/workflows/rebuild.yml
on:
 schedule:
   - cron: '0 * * * *'  # 1時間ごと
 workflow_dispatch:       # 手動トリガーも可

jobs:
 deploy:
   runs-on: ubuntu-latest
   steps:
     - uses: actions/checkout@v4
     - run: npm ci && npm run build
     - uses: cloudflare/wrangler-action@v3
       with:
         apiToken: ${{ secrets.CF_API_TOKEN }}

SSRはCloudflare Pagesで普通に動きます。

ベクトルデータベースの実装

Cloudflare内で完結する方法
① Vectorize（CF公式）

// Workers Paidで使える
const results = await env.VECTORIZE.query(queryVector, {
 topK: 10,
 returnMetadata: true
})
自家実装（D1を使う）
② D1 + コサイン類似度計算

-- SQLiteにベクトルをJSON配列で保存
CREATE TABLE embeddings (
 id TEXT PRIMARY KEY,
 content TEXT,
 vector TEXT  -- JSON配列 [0.1, 0.2, ...]
);
// Workers側でコサイン類似度を計算
function cosineSimilarity(a, b) {
 const dot = a.reduce((sum, ai, i) => sum + ai * b[i], 0)
 const normA = Math.sqrt(a.reduce((sum, ai) => sum + ai * ai, 0))
 const normB = Math.sqrt(b.reduce((sum, bi) => sum + bi * bi, 0))
 return dot / (normA * normB)
}
ただしベクトル数が増えると全件スキャンになって遅い。
小規模・PoC段階→ Vectorize（CF内で完結、Workers AIで埋め込み生成も可）

本格運用・独自モデル→ 自前Proxmox + pgvector
 （RTX 4000 Ada × 4があるので埋め込み生成も自前で可）
// D1にベクトルを保存
await db.prepare(`
 INSERT INTO embeddings (id, content, vector)
 VALUES (?, ?, ?)
`).bind(id, content, JSON.stringify(vector)).run()

// 全件取得してWorkers側で類似度計算
const rows = await db.prepare(
 'SELECT * FROM embeddings'
).all()

const results = rows.results
 .map(row => ({
   ...row,
   score: cosineSimilarity(queryVector, JSON.parse(row.vector))
 }))
 .sort((a, b) => b.score - a.score)
 .slice(0, 10)

ベクトル数    処理時間（Workers内）
100件        ✅ 数ms
1,000件      ✅ 数十ms
10,000件     ⚠️ 数百ms（Workers 30秒制限に近づく）
100,000件    ❌ タイムアウト
D1自家実装はPoC・小規模なら動きます。本番はVectorizeか自前Proxmox+pgvectorが現実解かも。

彼らの発想は「場所貸し」ではない。「世界中のネットワークの隙間（エッジ）を、最も効率的なコードの実行場所に変える」という、純粋な最適化の思想だ。自分たちがインターネットの「配管」を握っているからこそ、その配管を通るコードの追加コストはゼロに近い。だから「無料」にできる。既存のベンダーが必死に守ろうとしている「マージン」という名の不合理を、圧倒的な物理インフラの効率性で焼き払おうとしているのかもしれない。

結論：スケーラビリティに天井はあるのか？

物理的なネットワーク帯域が無限でない以上、いつかは成長曲線が緩やかになる日は来る。しかし、それは「技術的な限界」というより、「地球の裏側まで光が進む速度（物理法則）」という限界に近いもの。今まで数百万、数千万を投じて「自分たちのインフラ」を必死に拡張（スケール）させてきた努力が、CloudflareとGithubという「地球規模のインフラ」に溶けて無効化されてしまうことへの、無意識の恐怖かもしれません。一方で、AI時代にソロ開発者となってみた「現場の人間」からすれば、この「Supercloud」の拡張性は、個別のサービスが追いつけるレベルを疾うに超えていますし、GPUやオンプレ要素もProxmoxやRunpodで解決できそう。

「何を言ってるのかよくわからない」と言われる牧童(wrangler)のつぶやき

しかし、これだけの破壊的進化を遂げているにもかかわらず、世の中の「自称専門家」たちはまだ静か。最大限に配慮して表現すれば、それはおそらく、彼らがこのSupercloudの真価を知らないからではなく、あるいは「Cloudflareを使えば無料で済みます」と言ってしまうと、自らの職分や、重厚長大なシステムを構築することで得られる対価（あるいは自尊心）を失ってしまうからではないだろうか。数百万のコストをかけて構築していたものが、実は牧童(wrangler, Cloudflare CLIの名前)の「wrangler deploy」の一瞬のつぶやきで終わる現実を直視するのは、プロとして勇気がいることだ。だが、この数年のCloudflareの成長は本物であり、これを知らずに古い「ベストプラクティス」に固執している人は、技術的にも経営的にも決定的な損をしている。

では、Cloudflareがこけたら、インターネットは終わりなのだろうか。実際、2025年後半や2026年2月に起きたBGPルートリークによる障害を覚えている人も多いだろう。Cloudflareが倒れれば、世界中のかなりの割合のWebサービスが道連れになる。これは現代のインターネットにおける「巨大な単一障害点」だ。対抗馬としては、エッジコンピューティングに特化したFastlyや、老舗のAkamai、フロントエンドに強いVercelなどが存在する。しかし、これほどまでのサービス密度を「一つのプラットフォーム」として統合し、かつ「無料から始められる」という圧倒的なエントリーの低さで提供している存在は、他に見当たらない。

実際にはAWSやGCPプロジェクトをVercelに移し、CFに移しつつ、分散や評価を行っている。

ここまで書いて「何言ってるのか、よくわからない」というIT技術者、経営者は、まずは自分が作ってきたサービスがCloudflareの「無料枠」という名の宇宙を使い切れるかどうかを試験しておくべきだろう。そこには、私たちが一生かけても使い切れないほどの「余白」が広がっているし、現在のCloudflareの使い手は、その土俵の上で仕事をしている。

「AI開発で云々」という話の土俵以前に、コロナ禍以降で、Cloudflareがここまで進化しているということを、現在のIT事業者はどこまで理解しているだろうか。

私たちは今、特定のデータセンターに依存する「クラウド」から、ネットワークそのものが知能を持つ「スーパークラウド」への移行期に立っている。この波に乗るか、あるいは「昔はこうだった」と言い続けるか。その選択が、次の10年の勝敗を分けることになるだろう。

「でも技術サポートが…セキュリティが…」という最後のキーはAI開発が解決した

「でも、トラブルが起きた時の技術サポートが心配だ」「セキュリティの細かい設定を自動化できないか」――そんな、保守的な組織が最後にしがみつく「懸念のキー」も、昨今のAI開発が完全に解決してしまった。

2026年現在、Gemini CLI, Codex, Claude codeによるセキュリティ対策、加えてCF自身のAI Security for Apps はマルチベクトル型の攻撃をリアルタイムで自動検知し、Log Explorer がAIによる分析で「何が起きたか」を即座に言語化する。これまで熟練のインフラエンジニアが数時間かけてログを漁っていた作業は、一瞬のプロンプトで終わる。Workers AI や AI Gateway によって、高度なセキュリティと可観測性は、高価なサポート契約ではなく「標準機能」として組み込まれた。

もちろん、CloudFlare内部のAI機能だけではない。既存のシステムをCloudFlareに書き換えるのは、Claude CodeなりGeminiなりCodexなりがやってくれる。バイブスに乗っておっちょこちょいをするのか、AI駆動開発を体制としてつくるのかの違いだ。インフラ側の問題だから、お客様にご迷惑をおかけしないように時間をかけて移行するだけの計画も価値もできる。

大事なことなので2回でも3回でも云う。

私がこんなところにこんなブログを書いているのもそのせいで、
「本当は秘密だけど…」としておくか、
旧来の"パワープレイ"で働かせるようなITを人月をかけてやり続けるかだ。

もちろん、私はその分野で運用技術者として飯を食う人々の気持ちにもなっているので「Cloudflareで何でも解決ですよ！！」とは言わない。

ただ最近は「Cloudflareでやれば無料だし、メンテも楽になりそう　そう設計すべきだよなあ…」という思想に立っているし、私がその視点で若いエンジニアや中堅のエンジニアやCTOだったとしたら、既存のSaaSやソフトウェアプロダクトで「飯が食えているうちに」「できるだけ早く」「Cloudflareに移行して評価せよ」というおふれを出すべきだと思う。そうしないと、若い人たちはもっと自由で先進的な開発環境、開発体験に行ってしまうだろう。

Cloudflareの弱点「インターネットの終わり」

Cloudflareから宣伝広告案件をもらっているわけでもないのでここから先はネガティブな話を書く。

最大の問題は「Cloudflareがこけたら、インターネットは終わる」。実際、彼らは今や全世界のトラフィックの約2割を捌く「インターネットの正面玄関」であり、巨大な単一障害点（SPOF）であることは否定できない。対抗馬としては、パフォーマンス特化のFastlyや、絶対的安定を誇る老舗のAkamai、フロントエンド体験で先行するVercelなどが存在する。しかし、これほどまでのサービス密度を一つのプラットフォームに統合し、かつ「無料から始められる」という圧倒的なエントリーの低さで提供している存在は、他に見当たらない。

「WordPressすら引っ越しするのは大変」

先ほど「自社のSaaSを引っ越してみたらわかる」と書いたけど、きっとその辺のジュニアエンジニアに「WordPressを引越してみて」と頼んでみたら、多分とんでもなくハマった上に、泣き出す可能性すらある。それでその上司は、「CFはWordPressすら引越できない」と断定してしまうだろうか。
そう嘆く人は、まだ「サーバーという箱」を移し替える発想から抜け出せていない。確かにこれまでのLAMP環境をそのままCloudflareに持ち込むのは容易ではない。しかし最近はPHPをWebAssembly(Wasm)へコンパイルし、Workersの上で動かし、データベースをD1に直結するという、変態的ですらある解法が存在する。

それは単なる「引っ越し」ではなく、15年以上続くWebのレガシーを、エッジネイティブな「純粋なコード」へと昇華させる儀式だ。手間はかかる。だが、一度その次元に到達してしまえば、もはやセキュリティパッチやミドルウェアの更新に怯える日々は過去のものになるのかもしれない。

Vercelに置いたものを全てCloudflareに引っ越したくなる

「GitHubで開発したものを全てVercelにデプロイしたくなる」がちょっと前までの開発者の常識だったとすれば、「Vercelで開発したものを全てCloudflareに引っ越したくなる」が現状だろうか。

私たちは今、特定のデータセンターに依存する「クラウド」から、ネットワークそのものが知能を持つ「スーパークラウド」への移行期に立っている。Cloudflareが倒れれば世界が止まるかもしれないというリスクを恐れて、この圧倒的な恩恵を拒絶するのか。あるいは、浮いた数百万のコストと数千時間の工数を「サービスの付加価値」に回すのか。その選択が、次の10年の勝敗を分けることになるだろう。

2026/04/14加筆。続きます。不運なことに！