2023年の後半、あるクライアントのEコマースストアフロントをVercelから移行しました。1ヶ月の請求が$340だったからです。中程度のトラフィックのSaaS。特に問題があったわけではありません。創業者から金曜日の午後に電話がかかってきて、本当に不安そうな声でした。正直なところ、良い言い訳がありませんでした。私はVercelをデフォルトにしていました。知っていたプラットフォームだから、セットアップが速いから、Next.jsのドキュメントが基本的にそれを使うことを想定していたからです。Cloudflare Pagesへの移行は1日で完了し、月額コストを約$22に削減しました。それ以来、より注意深く見守っています。
ですから、Seahawkでクライアント作業を通じて両プラットフォームを運用してきた2026年の現在の立場はこうです：Cloudflare Pagesは大幅に成熟し、Vercelも進化し続けており、「どちらを使うべきか」という問いへの答えはブランドへのロイヤルティではなく、あなたが実際に何を構築しているかによる部分が大きいということです。
価格の現実（そしてVercelが今でも問題な部分）
Vercelの無料プランはサイドプロジェクト向けに本当に優れています。Hobbyプラン、無制限のデプロイ、プレビューURL、充分なビルド分。Pro（月額$20/ユーザーあたり）に移行すれば、ソロ開発者なら問題ありません。しかし、エージェンシーはどうでしょうか。ユーザーあたりのモデルが積み重なります。6人の開発者がいるチームなら、1つのリクエストを処理する前に月額$120です。その上、帯域幅、Edge Functionの呼び出し、画像最適化を追加すると、請求は2009年のモバイル電話契約のように見え始めます。何に支払っているのかいつも明確ではありませんでした。
Cloudflare Pagesは根本的に異なる経済モデルに基づいています。無料プランには無制限のサイト、無制限のリクエスト、月間500ビルドが含まれています。Proプランは月額$20で固定。ユーザーあたりではありません。Seahawkにとってこの違いは重要です。複数のクライアントのビルドを単一のアカウントから管理しているからです。2025年初頭の典型的な月の数字を計算しました：14のアクティブプロジェクト、合計で約210万のエッジリクエスト。Cloudflareでは$20を支払いました。Vercelの同等の使用量のティアでは、アクティブなアドオンによって約$180～$220の見積りが出ました。
とはいえ、Vercelの料金体系は実質的な価値をもたらします。詳しくはすぐ後で述べます。
帯域幅と出力トラップ
これが、手遅れになるまで誰も警告してくれないことです。Vercelは Pro プランで 1TB 以降の帯域幅に対して課金します。悪くない話に聞こえます。ほとんどのプロジェクトはそこに到達しません。しかし、大きなレスポンスを返す Edge Functions や、サーバー側の画像処理を行うプロジェクトは、不釣り合いに見える方法で帯域幅を消費できます。
Cloudflareのネットワーク全体は、プラットフォーム内での計量されない出力で動作します。Cloudflareの料金ページはこれを明記しています。WorkersおよびPages Functions のリクエストは、無料の1日あたり10万リクエスト後、100万リクエストあたり $0.30 で課金されます。それは透明性があります。予測可能です。安心できます。Cloudflare's pricing page makes this explicit. Workers and Pages Functions requests are priced at $0.30 per million after the free 100k daily requests. That's transparent. Predictable. I can sleep.
エッジネットワークカバレッジ：Cloudflareが有利だが、魔法ではない
Cloudflareは 2026 年現在、世界中に 300 を超えるデータセンターを保有しています。Vercelはより小さなリージョンセットで動作し、主にAWSインフラストラクチャによってサポートされています。ほとんどのUKおよびヨーロッパのプロジェクトでは、エッジでのコールドスタートレイテンシーの差は実質的ですが控えめです。ラゴス、ムンバイ、サンパウロのユーザーに同時にサービスを提供するSaaSプロダクトの場合、Cloudflareのカバレッジギャップはほぼゼロまで縮まります。
2024年、東南アジア全体のユーザーにサービスを提供する多言語SaaSプロジェクトに携わりました。最初はVercelで立ち上げており、シンガポールからの p99 レイテンシーは約380msで推移していました。悪くはありません。API ミドルウェアを Cloudflare Workers に移行して、95ms まで削減しました。コードはほぼ同じです。異なるのはエッジノードの密度です。
Workers vs Edge Functions：ランタイムの相違
ここが本当に技術的で本当に重要な部分です。Vercel Edge Functions は V8 アイソレートモデルで実行され（Cloudflare Workers と同じ哲学）、VercelのインフラストラクチャとNext.jsミドルウェアシステムにより緊密に結び付けられています。Cloudflare Workers はこの分野で長年の実績があります。Workers ランタイムは Web Crypto、Streams、KV、R2、Durable Objects、および Vercel に直接的な同等物がない一連のバインディングをサポートしています。Workers runtime supports Web Crypto, Streams, KV, R2, Durable Objects, and a suite of bindings that have no direct equivalent on Vercel.
エッジでの永続的な状態が必要なもの（プレゼンスインジケータ、共有状態を伴うレート制限、リアルタイム協調編集機能など）を構築している場合、Cloudflare Durable Objects は本当に有用であり、今日の Vercel にはそれらに匹敵するものはありません。
とはいえ、Next.js 14以上のアプリをApp Routerでデプロイし、ゼロコンフィグISR、Edgeストリーミング、RSCセットアップで「そのまま動く」ミドルウェアが欲しいなら、Vercelの方がスムーズなパスです。これは意見ではなく、@cloudflare/next-on-pagesアダプタを使ってVercelのNext.js統合をCloudflare Pages上で複製しようとするたびに目にする現実です。動きます。ただ、摩擦がないわけではありません。@cloudflare/next-on-pages adapter. It works. It's just not frictionless.
開発者体験：正直な話
ここは慎重に考えたいです。DXは主観的で、かつ部族色の濃い議論が最も多い領域だからです。単に実際に観察していることを説明させてください。
Vercelのダッシュボードは美しいです。プレビューデプロイメントは瞬時です。GitHubの統合は私が使ったどこよりも優れています。ブランチをプッシュすると、ウォームキャッシュで45秒以下でプレビューURLが本番になり、PRのデプロイメントコメントはCore Web Vitals、ビルド時間、直接リンクを表示します。そのフィードバックループは速く、気持ちがいいです。特に、リンクをクリックして変更を見たい非技術的なクライアントをオンボーディングしているときは、それが重要です。feels good. That matters, especially when you're onboarding a non-technical client who wants to click a link and see their changes.
Cloudflare Pagesは2022年頃のWorkerに無理やり付け加えたような感じだった時代以来、ダッシュボードをかなり改善してきました。ビルドシステムは今では速く、プレビューデプロイメントは十分に機能し、Pages + Workers統合（wrangler.tomlを通じて）は本当に素晴らしいです。しかし、Cloudflareの製品面の心的モデルはより広く、したがってより難しいです。Workers、Pages、R2、KV、D1、Durable Objects、Pages Functionsがあり、それらすべてが若干異なる設定サーフェスを持っています。developers.cloudflare.comのドキュメントは徹底的ですが、散漫です。wrangler.toml) is genuinely nice. But the mental model of Cloudflare's product surface is broader and therefore harder. You've got Workers, Pages, R2, KV, D1, Durable Objects, Pages Functions, and they all have slightly different configuration surfaces. The documentation at developers.cloudflare.com is thorough but sprawling.
正直なところ、Seahawkのジュニア開発者がVercelに1日で慣れるのを見てきました。Cloudflare Pagesは、誰かが自分の関数がWorkerなのかPages Functionなのか、どの設定ファイルが何を支配しているのかについて疑うのをやめるまでに約1週間かかります。
ローカル開発とWrangler
Cloudflareのwrangler dev CLIは優れています。Workers実行時のローカルシミュレーションを実行し、ほとんどのバインディングをサポートします。しかし「シミュレーション」が重要な言葉です。ローカルで動作したコードを本番環境のエッジネットワークで異なる動作をするようにシップしました。これはKVがプレビューと本番でどのように動作するかの微妙な違いのためです。2025年の小さなバグ、ステージングで捕まった、しかし半日かかりました。wrangler dev CLI is good. It runs a local simulation of the Workers runtime and supports most bindings. But "simulation" is the operative word. I've shipped code that worked locally and behaved differently on the actual edge network because of subtle differences in how KV behaves in preview versus production. Small bug in 2025, caught in staging, but it cost me half a day.
Vercelのvercel devコマンドはいくつかのエッジケースではより限定的ですが、標準的なNext.jsプロジェクトではほぼ常に本番環境の忠実な複製です。その予測可能性は重要です。vercel dev command is more limited in some edge cases but it's almost always a faithful replica of production for standard Next.js projects. That predictability matters.
Next.js以外のフレームワークサポート
これは過小評価されている議論だ。Vercel は機能的には Next.js ホスティング企業で、その他のものもサポートしているにすぎない。SvelteKit、Nuxt、Astro、Remix、SolidStart はすべて動作し、よく動作する。しかし Next.js が機能を最初に手に入れ、デフォルトが優れており、明らかに主な用途だ。
Cloudflare Pages はフレームワークへの忠誠心がない。Astro on Pages は喜びだ。SvelteKit adapter for Cloudflare は保守され、安定している。2024年半ばから Pages で複数の Astro プロジェクトを実行しているが、ビルド時間は同じサイトの同等の Vercel デプロイメントより速い（私自身のビルドログに基づくと、平均でおよそ 30～40% 高速）。
チームが Next.js から移行しているか、プロジェクト全体で複数フレームワークを構築している場合、Cloudflare Pages はより不可知論的で、その不可知論は時間とともに価値を生む。
2026年で各々を選ぶ場合
率直に言おう。これが実際に使う判断ロジックだ：
以下の場合は Vercel を選ぶ：
- プロジェクトが Next.js ファーストで App Router を深く使用している（RSC、ストリーミング、ISR、すべて）
- クライアントがプレビューデプロイメントを見て、技術的な摩擦なくコメントする必要がある
- チームが小規模（1～3人の開発者）で、1席あたりのコストは無視できる
- Next.js の一級サポートが価値あるものを構築している
Cloudflare Pagesを選ぶべき場合：
- エージェンシーまたはソロオペレーターで、4〜5個以上のライブプロジェクトを運用している
- 最もスムーズなNext.js DXよりも、コスト予測可能性が重要である
- Workers バインディング（KV、R2、Durable Objects、D1）がアーキテクチャの一部として必要である
- ユーザーベースがグローバルに分散しており、米国以外のリージョンにおけるエッジレイテンシーが重要である
- Next.jsに限定されず、フレームワークの柔軟性を求めている
Seahawk Media のクライアント業務に限定すると、以下のように分けている：マーケティングサイト、コンテンツ重視のビルド、Astroベースのものは Cloudflare Pages。クライアントの開発チームがすでにそのエコシステムにいる複雑な Next.js SaaS プロダクトは Vercel。
誰も話さない一つのこと：サポート
Vercel Pro はメールサポートを提供する。Enterprise はさらに充実している。レスポンシブで、チームは Next.js を深く理解している。木曜日の午前2時にクライアント立ち上げ前にデプロイメントパイプラインで何かが壊れたとき、ISR の再検証が内部でどのように機能しているかを実際に理解している人から返信をもらえることには価値がある。
Cloudflare の Pages 特有のサポートモデルは、歴史的に言うと...ムラがある。Discord コミュニティはアクティブで Workers チームはアクセス可能だが、Pages 特有のサポートチケットは望ましいより解決に時間がかかることがある。2025年に改善されたが、それでも Vercel にサポートの優位性を与える（ダジャレで申し訳ない）。
FAQ
FAQ
Cloudflare Pages は 2026 年現在、本当に本番環境対応していますか？
はい、間違いなく対応しています。「Cloudflare Pages はまだベータ版」という認識は時代遅れです。本格的な本番ワークロードが稼働しています。Pages プラットフォームのステータスは一貫して堅牢です。主な注意点は Next.js アダプター（コミュニティメンテナンス、公式ではない）と、Cloudflare の広範な製品体系の学習曲線です。Pages platform status has been consistently strong. The main caveats are around the Next.js adapter (which is community-maintained, not first-party) and the learning curve around Cloudflare's broader product surface.
Cloudflare Pages で Next.js App Router を使用できますか？
@cloudflare/next-on-pages アダプター経由で使用できます。Server Components、動的ルート、ミドルウェアを含む、App Router 機能の相当な部分をサポートしています。ただし、Vercel 固有のインフラストラクチャに依存する機能（Vercel API 経由のオンデマンド再検証など高度な ISR）は、動作しないか回避策が必要です。複雑な Next.js アプリを構築している場合は、コミットする前に特定の機能要件をテストしてください。@cloudflare/next-on-pages adapter. It supports a significant subset of App Router features including Server Components, dynamic routes, and middleware. But some features that rely on Vercel-specific infrastructure (like advanced ISR with on-demand revalidation via the Vercel API) either don't work or require workarounds. If you're building a complex Next.js app, test your specific feature requirements before committing.
Vercel の無料プランはクライアントサイト向けに機能しますか？
技術的にはそうですが、Hobby プランの Vercel 利用規約は商用利用を制限しています。有料クライアント向けに構築する場合は、Pro に移行すべきです。これは曖昧な領域ではなく、彼らが長期間放置することはありません。クライアント作業には Pro を使用してください。
SEO パフォーマンスではどのプラットフォームが優れていますか？
どちらのプラットフォームもデフォルトで SEO を提供しません。しかし、エッジデリバリーと Core Web Vitals は関連しており、どちらのプラットフォームも適切な実装で優れた LCP と CLS スコアを実現できます。Vercel の Image Optimisation API（next/image 経由）はより成熟していて設定しやすいです。Cloudflare の Image Resizing 機能（Pro プラン以上で利用可能）はより手動設定が必要ですが、スケール時にはコストが安くなります。next/image) is more mature and easier to configure. Cloudflare's Image Resizing feature (available on Pro plans) requires more manual setup but is less expensive at scale.
Netlifyはどうですか？まだ関連性がありますか？
Netlifyはまだ存在していて、特にNetlifyの深いワークフローを持つJAMstackチームで使われ続けています。ただし、2026年のマインドシェア、採用、プラットフォーム投資という観点では、CloudflareとVercelの両方に顕著に後れを取っています。2023年頃からは、新しいプロジェクトにNetlifyを推奨していません。
---
2026年のプラットフォーム選択は、Twitterスレッドがいうほど劇的ではありません。どちらも機能します。どちらも信頼できます。本当の決定は、コストモデルとあなたのビジネスのアライメント、フレームワークアライメントとあなたのチームのアライメントについてのことです。フレームワークのドキュメントが「デプロイ」ボタンに表示しているものにデフォルト設定するのではなく、意図的にその判断を下してください。