CloudflareとVercelを比較｜失敗しない選び方

こんにちは。Osukeラーニング、運営者の「osuke」です。

AI codingでsiteやWeb appを作れたのに、「Cloudflare、Vercel、Netlifyのどこへ公開すればよいか」「無料のまま商用利用できるか」「アクセスが増えたら突然止まったり請求されたりしないか」と迷っていませんか。3社ともGit連携、独自domain、HTTPS、preview deployに対応しますが、得意なframeworkと無料枠超過後の挙動は同じではありません。

結論からいうと、Next.jsを最短で公開するならVercel、formや共同reviewを含むfrontend運用ならNetlify、静的配信からAPI、D1、R2までedgeへまとめるならCloudflareが基準です。ただし「1社ですべて」を先に決める必要はありません。Vercelでapp、R2でmedia、CloudflareでDNSと配信のように、移行しにくいdataと移しやすいfrontendを分ける選択もできます。

この記事はosuke本人の利用体験としては書かず、2026年8月31日時点の3社公式資料13件と、Xで公開された8件の移行・併用・料金・cache運用事例を照合しました。Xの結果は各投稿者のprojectに限られるため、料金、上限、framework対応は公式資料を優先します。Cloudflare全体が初めてならCloudflareの機能と無料範囲から確認してください。

記事のポイント

• Next.jsのzero-configと新機能追従はVercelが基準
• NetlifyはDeploy Preview・atomic deploy・Formsをまとめやすい
• Cloudflareはstatic assetとWorkers・D1・R2の統合に向く
• Free超過時の停止範囲と有料移行条件まで比較して選ぶ

Cloudflare・Vercel・Netlifyの違い

3社の差は「表示が速いか」だけではありません。frameworkとの距離、staticとdynamicの課金単位、previewの運用、databaseやstorageとの接続、無料枠超過時の停止範囲を分けて比較すると、自分のprojectに必要な条件が見えてきます。

3社の結論をproject別に比較する

Cloudflare、Vercel、Netlifyは競合でありながら、同じ設計思想のserviceではありません。Vercelはframeworkを理解したfrontend cloudで、特にNext.jsをほぼ設定なしでdeployできます。NetlifyはGitからのbuild、Deploy Preview、atomic deploy、Formsなどを一つのworkflowへまとめます。Cloudflareはglobal network上のstatic assetsとWorkersを入口に、D1、R2、KV、Durable Objectsなどをbindingで接続するplatformです。

Xではおりばー氏が0→1はVercel Proの月額20ドル、databaseは移行性で選び、storageはR2、media配信はCloudflareという併用案を公開しています。これは「勝者を1社決める」より、変更頻度とdata portabilityで役割を分ける例です。frontendは再deployしやすい一方、databaseや大量画像は移行時間とegress costが膨らむため、最初に分離しておく価値があります。

初心者は、まず4問で候補を絞ってください。Next.js固有機能を多用するならVercel、問い合わせformとreviewを早く用意したいならNetlify、API・database・object storageをCloudflare内で組みたいならCloudflareです。HTML、Astro、Viteなど静的出力できるsiteは3社すべて候補なので、無料枠、production deploy回数、独自domain、停止条件で最終判断します。

静的siteとpreview deployを比較する

portfolio、blog、documentationのようにbuild後のHTML・CSS・JavaScriptを配るsiteは、3社ともGit pushから公開できます。Cloudflare公式Static Assetsではstatic asset requestが無料・無制限で、asset保存の追加料金もありません。dynamicなWorker scriptを呼んだrequestだけがWorkersの料金・上限へ入るため、静的部分とAPI routeを分けるほどcostを読みやすくできます。

Netlify公式Deploy overviewの強みはatomic deployです。すべての変更fileがuploadされるまでproductionへ切り替わらず、途中でHTMLだけ新しくCSSが古い状態になりません。Pull RequestごとのDeploy Preview、branch固定URL、過去deployへのinstant rollbackも同じ画面で扱えます。reviewerは公開前のURLを見て、画面上からfeedbackを残せます。

Cloudflare Pagesにもbranch・Pull RequestごとのPreview deploymentがあり、defaultでX-Robots-Tag: noindexが付きます。VercelもGit pushとPRごとにpreview URLを作ります。差が出るのは「previewがあるか」ではなく、承認者、password保護、環境変数、production deployのcredit消費、rollbackの手順です。実際のteam人数で1本のPRを通し、操作回数を比べます。

Full-stackとedge処理を比較する

login、SSR、API、database更新があるappでは、static hostingの比較だけでは足りません。Cloudflare WorkersはV8 isolateでrequestを処理し、D1、R2、KVなどをbindingで呼べます。VercelはFunctionsとframework-aware cache、NetlifyはFunctionsとEdge Functionsへbuild結果を振り分けます。同じJavaScriptでもNode.js API、filesystem、native package、execution regionの対応が異なります。

XではSai Krishna氏がSuperblog v2をNetlifyからHetzner＋Cloudflareへ移し、customerが変更した時だけcacheをpurgeする構成へ再設計したと報告しています。通常時のVPS loadはほぼzeroになったという本人の結果です。Cloudflareだけへ全面移行した例ではありませんが、static cacheとorigin computeを分離するとvariable costを抑えられることを示します。

「edgeだから常に速い」とは断定できません。databaseが1地域にあり、edgeから毎回遠距離queryを行えばlatencyは増えます。逆にauthentication、redirect、A/B test、cache判定のようにdataを少しだけ読む処理はedgeへ置きやすいです。1 requestで何回のsubrequestを行うか、dataはどこにあるか、Node.js packageはruntimeで動くかを図にしてからplatformを選びます。

Next.jsの対応と移行costを比較する

Vercel公式Next.js資料は、Vercel自身がmaintainするNext.jsをzero-configurationでdeployし、SSR、streaming、Image Optimization、cache revalidationをplatform側で統合すると説明しています。最新のNext.js機能を早く使い、adapterの差を調べる時間を減らしたいなら、Vercelを比較の基準にするのが自然です。

NetlifyはOpenNext adapterでNext.js 13.5以降の主要機能をzero config対応し、SSR、ISR、Server Actions、image optimizationを自動構成します。ただしEdge Runtime指定のSSRがNode function regionで動く、middlewareのfilesystemやC++ addonsは使えないなどのlimitationsがあります。zero configでもVercelと同じruntimeになるわけではありません。

Cloudflareは2026年8月時点で新規Next.js appへvinextを推奨していますが、vinextはbetaで、既存production appにはcompatibility checkが必要です。既存OpenNext appはOpenNext adapterを維持できるものの、Node.js Middlewareなど未対応項目があります。XでもBicen Dinh氏がVercelからCloudflareへの移行は1-clickではなく調整が必要だったと述べています。移行costを月額差へ含めてください。

無料枠と超過後の挙動を比較する

Cloudflare Workers公式Pricingではstatic asset requestが無料・無制限、Workers Freeのdynamic requestは1日100,000回です。Paidは最低5ドル/月で10 million requests/月と30 million CPU milliseconds/月を含み、超過はrequestとCPU timeで課金されます。data transferの追加料金はありません。Freeのdynamic上限を超えるとError 1027になり、static assetまで同じ条件で課金されるわけではありません。

VercelはHobbyが0ドル、Proが20ドル/月で、Proには20ドルのusage creditがあります。Hobbyはpersonal・non-commercial向けで、100GB Fast Data Transfer/月、1 million Function Invocationsなどの上限があります。公式Hobby docsでは、多くの場合、上限超過後は30日経つまで該当featureを使えません。Proの追加usageは従量課金で、Spend Managementのpause optionを有効にしなければ金額設定だけで自動停止しません。

Netlifyのnew accountはcredit制で、Freeは300 credits/月のhard limit、Personalは9ドルで1,000、Proは20ドルからで3,000です。10,000 web requestsが2 credits、1GB bandwidthが20、production deploy 1回が15、Functions 1GB-hourが10です。Freeでlimitへ達すると同accountのprojectsがpauseするため、複数siteを1 accountへ置く人は合算を見ます。

Cloudflare・Vercel・Netlifyの選び方

ここからはproject別に第一候補を決めます。評判だけで選ばず、公開頻度、framework、共同作業、dataの置き場所、停止許容時間を条件へ変え、最後に同じrepositoryでpreview testを行います。

Portfolio・blogなら公開頻度で選ぶ

HTML、Astro、Vite、static exportしたNext.jsで作るportfolioやblogは、Cloudflareがcostを単純化しやすい候補です。static asset requestが無料・無制限なので、画像を含むbuild結果をそのまま配り、contact APIだけWorkerへ分離できます。更新が月1〜4回でdynamic処理が少ないなら、速度差より独自domain、DNS、preview、rollbackの操作性を重視してください。

XではKeisuke Nishitani氏が古いsiteをNext.js＋AmplifyからNext.js＋Vercel、Astro＋Vercel、Astro＋Cloudflare Workers、Cloudflare DNSへ段階的に更新しています。framework変更、hosting変更、DNS変更を一度に行わず、各段階で動作を確認した例です。静的siteならhostingを先にpreviewし、最後にDNSを切り替えるとrollbackしやすくなります。

Netlify Freeはcredit-based accountでproduction deploy 1回が15 creditsのため、300 creditsをdeployだけへ使うと20回分です。実際はbandwidthやweb requestsも同じcreditから消費します。また、2026年8月19日以降にFreeで作ったpublic projectはPowered by Netlify badgeが表示されます。brand表示を避けたいportfolioはPersonal以上も比較してください。

Next.js中心ならVercelを基準にする

App Router、Server Components、Server Actions、ISR、next/imageを使うappは、まずVercelでpreviewを作ると本来の動作を確認できます。Vercelで失敗するならcodeやNext.js設定、他社だけで失敗するならadapterやruntime差という切り分けができます。新機能を導入するたびにcompatibility matrixを追いたくないteamには、月額差以上の時間短縮になります。

Bicen Dinh氏のX事例では、Next.js appがVercel Freeを約2か月で超え、20ドル/月の提示後にCloudflareへ移行しました。調整と最適化後、本人環境では性能がほぼ同じで投稿時点の支払いは0だったと述べています。一方、chetan kumar氏も複数projectをVercelからCloudflareへ移し、現在のbuildにはCloudflareが合うと報告しています。どちらも「Cloudflareが常に安く同速」を保証するものではありません。

判断には開発時間を含めます。月20ドルを避けるためにadapter対応へ8時間使うなら、時給換算では初月に回収できない可能性があります。逆にtrafficやimage配信が増え、毎月の従量費が継続するなら移行testの価値が高まります。VercelのUsageで上位metricを特定し、cache、image、function、transferのどれが原因かを見てから、CloudflareまたはNetlifyで同じrouteを測ります。

Formsと共同reviewならNetlifyを選ぶ

marketing site、採用site、event LPのように、非engineerも公開前の画面を確認し、問い合わせを受けるprojectではNetlifyが候補です。Deploy PreviewはPRごとに作られ、Netlify Drawerから画像・動画・browser情報付きのfeedbackをissue trackerへつなげられます。Formsはcredit-based planでsubmission数が無料・無制限ですが、spam対策と個人情報の保存方針は別途必要です。

Netlifyのatomic deployは、build全体が揃ってからproduction URLを一度に切り替えます。公開直後に問題があれば、過去のsuccessful deployを新しいbuildなしでinstant rollbackできます。複数人が文章、画像、formを同時に触るsiteでは、単なるhosting料金より「壊れた状態を見せない」「承認後だけ公開する」という運用価値が大きくなります。

一方でXには、framp氏が過去のNetlify利用後にすべてをCloudflare Freeへ移した例と、Gene氏がNetlifyからCloudflareへ移行した例があります。どちらも条件と数値が不足しているためNetlify全体の評価には使えませんが、credit、build、機能依存を定期的に見直す必要はあります。Free 300 creditsへ複数projectを詰め込まず、project別usageを毎週確認します。

API・DB・storage統合ならCloudflareを選ぶ

API、SQLite系database、image storage、bot対策を一つのaccountで組みたいならCloudflareが有力です。WorkerからD1、R2、KV、Durable Objects、Workers AIへbindingで接続でき、外部API keyをbrowserへ出さずにserver処理をまとめられます。Static Assetsとdynamic routeを同じWorkerへ持てるため、frontendとAPIのdeploy単位も揃えられます。

ないと氏はprofile siteをVercelからCloudflareへ完全移行し、独自domain設定を誤ると第三者に悪用される危険へ注意を促しています。hosting移行が成功しても、旧projectのcustom domain、DNS record、preview URL、environment secretsを残すとattack surfaceになります。新siteを確認後、旧provider側のdomain associationを解除し、不要recordを整理します。

Cloudflareへ統一すると学ぶ対象も増えます。WorkerのCPU time、subrequest、D1 rows、R2 operationsは別metricで、static requestだけ見てもcostは分かりません。まずCloudflare Workersの始め方で1 APIを公開し、次にWorkersの無料枠と料金を確認してください。最初から全serviceへdataを置かず、移行・backup・export手順も一緒に作ります。

同じrepositoryで移行testを行う

最終判断は比較記事の点数ではなく、自分のrepositoryを候補先へpreview deployして行います。production domainを動かす前に、build、homepage、dynamic route、image、form、loginの5項目を確認してください。各platformで30分ずつ触り、初回build時間、2回目build時間、p95 response、月額見込み、rollback時間を同じsheetへ記録します。

移行はfrontend、dynamic処理、data、DNSの4段階に分けます。新providerのtemporary URLでfrontendを確認し、read-only dataを接続し、writeを短時間だけ切り替え、最後にDNSを変更します。TTLを事前に下げ、旧環境を24〜72時間残し、error rateとform送信を監視します。問題があればDNSまたはwrite先だけを戻せる状態にします。

Xの事例を見ても、完全移行、Vercel＋R2の併用、NetlifyからHetzner＋Cloudflareへの分離など答えは一つではありません。今日の1stepは、同じrepositoryを最有力候補へpreview deployし、production trafficを流さず5項目を記録することです。無料枠の数字より、「超えた時にどう止まり、何分で戻せるか」まで確認できたplatformを選んでください。

Cloudflare、Vercel、Netlifyの比較は、最安料金だけでは決まりません。Next.jsへの近さ、共同review、dataの置き場所、無料枠超過時の停止範囲で向き不向きが変わります。迷ったら、Next.jsはVercel、共同reviewとFormsはNetlify、static＋edge servicesはCloudflareを初期値にし、同じrepositoryの実測で入れ替えてください。