先に要点
- Vercel、Netlify、Cloudflare Pages は 「フロント中心の静的・SSRデプロイ基盤」 として近い立ち位置で、選び方の差は 「Next.js特化」 「エッジ性能」 「料金」 で出ます。
- Render、Fly.io、Railway は 「バックエンドとDBもまとめて動かせる」 寄りで、Vercelとは目的レイヤーが違います。
- AWS Amplifyは 「AWSエコシステム前提のフロント基盤」。Vercelの代わりというより、「既にAWS中心ならAmplify」 が現実的。
- 選び方の軸は 「Next.jsか否か」 「フロントだけかバックも要るか」 「エッジ性能とコスト」 「ベンダーロックインの許容度」 の4つで整理すると迷いにくいです。
Vercelが流行ってるのは分かったけど、Netlify や Cloudflare Pages とはどう違うの？ Render や Fly.io はまた別物？
最近のWebアプリ開発では、デプロイ先の選択肢がかなり増えています。
ただ、どれも似たことができる ように見えて、実はそれぞれ得意領域がはっきり違います。流行ってるから Vercel で選ぶと、このサービスではこれができない で詰まる場面もあります。
この記事では、2026年5月時点の各サービス公式ドキュメントを確認しながら、Vercelと主要な競合サービスを比較し、どの案件にどれが向くか を整理します。
Vercel単体の基本は Vercelとは？何ができる？Next.jsとの相性・向いている案件・注意点を解説、流行の背景は Vercelが流行っている理由は？AIの影響もあるのか実務目線で整理 もあわせて読むと立ち位置が見えやすいです。
この記事は2026年5月時点の情報をもとに書いています。各サービスは料金・機能が頻繁に更新されるので、本番採用前は公式ドキュメントの最新情報も合わせて確認することを前提にしています。
まず大まかな立ち位置を分けて見る
比較対象を雑に並べてもわかりにくいので、まず 何を主役にしているか で3グループに分けます。
フルスタック寄り
Render / Fly.io / Railway。アプリも DB も同じプラットフォームで動かせる。長時間プロセスやワーカーも置ける。
Vercelの代わりを探す のか、Vercelとは別の場所で何かを動かす のかで、見るべきサービスが変わります。
主要サービスをひと言で
フロント特化型
Vercel
Next.jsの開発元が運営する、フロントエンド寄りデプロイ基盤。Preview Deployment、Edge Functions、画像最適化が標準装備。Next.js + AI機能 で最も推されている選択肢。
フロント特化型
Netlify
Vercelの古参ライバル。Jamstack ブームの先駆けで、静的サイト + サーバーレス関数 の元祖的存在。Astro、Eleventy、Hugo といった静的サイトジェネレータとの相性が良い。
フロント特化型
Cloudflare Pages
CloudflareのCDN網に直接デプロイするサービス。エッジ実行の性能と低価格 が圧倒的。Workers と組み合わせると、グローバル分散アプリが少コストで作れる。
フルスタック寄り
Render
Heroku の代わり を狙ったフルスタック基盤。Web サービス、ワーカー、Cron、PostgreSQL、Redis を1つのダッシュボードで管理できる。
フルスタック寄り
Fly.io
アプリを世界中のリージョンに配置できる 軽量Dockerホスティング。長時間プロセス、永続ボリューム、リアルタイム通信に強く、小さいAWSの代わり のような立ち位置。
フルスタック寄り
Railway
開発体験を最優先にしたフルスタック基盤。Git push して数十秒で動く のシンプルさ重視。スタートアップや個人開発で人気。
クラウド統合型
AWS Amplify
AWS が公式に提供するフロントエンド + バックエンド開発基盤。Cognito、AppSync、Lambda、DynamoDB と統合。AWS資産がすでにある組織向け。
機能面の比較
Next.js対応
| サービス | Next.js対応 | ISR / Edge | 画像最適化 |
|---|---|---|---|
| Vercel | ◎ 開発元、全機能対応 | ◎ ネイティブ | ◎ 自動 |
| Netlify | ○ 公式アダプタあり | △ 一部制限 | ○ Image CDN |
| Cloudflare Pages | ○ next-on-pages | ○ Workers連携 | ○ Cloudflare Images |
| Render | △ Node.jsとして動かす | × | × 別途実装 |
| Fly.io | △ Dockerで動かす | × | × 別途実装 |
| Railway | △ Node.jsとして動かす | × | × 別途実装 |
| AWS Amplify | ○ SSR/SSG対応 | △ Lambda@Edge | ○ Amplify Image |
Next.js を本気で使う なら、Vercel か Netlify か Cloudflare Pages の3択がほぼ前提。Render/Fly.io/Railway は Next.jsを動かせるが最適化はしない レベルです。
バックエンド・データベース
| サービス | 長時間プロセス | DB提供 | バックグラウンドワーカー |
|---|---|---|---|
| Vercel | × Functions最大10〜60秒 | ○ Vercel Postgres / KV | × |
| Netlify | × Functions制限あり | × 外部DB前提 | △ Background Functions |
| Cloudflare Pages | × Workers制限あり | ○ D1 / KV / R2 | × |
| Render | ◎ Web Service常時稼働 | ◎ PostgreSQL公式提供 | ◎ Background Worker |
| Fly.io | ◎ 24/7プロセス | ○ Postgres on Fly | ◎ Machine単位 |
| Railway | ◎ 常時稼働可 | ◎ PostgreSQL/MySQL/Redis | ◎ Worker Service |
| AWS Amplify | ○ Lambda経由 | ○ DynamoDB / RDS | ○ Lambda+SQS |
ここがフロント特化型とフルスタック寄りの分かれ目です。バッチ、ワーカー、長時間API が必要なら、Vercel単体では厳しい場面があります。
料金感(無料枠 + Pro入門価格)
| サービス | 無料枠 | 有料入門 | 課金軸 |
|---|---|---|---|
| Vercel | 100GB帯域 / 月 | $20/月(Pro) | 帯域、Function実行、ビルド時間 |
| Netlify | 100GB帯域 / 月 | $19/月(Starter) | 帯域、Function実行、ビルド時間 |
| Cloudflare Pages | 500ビルド/月、無制限帯域 | $5/月(Workers Paid) | リクエスト数 |
| Render | 750時間/月の無料Web枠 | $7/月〜 | プラン別固定 |
| Fly.io | 月$5の無料クレジット | 従量制 | CPU・RAM・帯域 |
| Railway | $5無料クレジット/月 | 従量制 | CPU・RAM・実行時間 |
| AWS Amplify | 無料枠あり | 従量制 | ビルド時間、ストレージ、リクエスト |
特にCloudflare Pagesの 無制限帯域 + 安いリクエスト課金 は、トラフィックが伸びるサービスでは強烈に効きます。
ユースケース別の選び方
第一候補：Vercel
Next.jsで新規Webアプリを立ち上げる
第一候補は Vercel。Next.jsの新機能対応が常に最速、AI SDKや v0との連携が前提で揃っているため、書いて動かして共有する までが最短です。
ただし、帯域コストが心配 エッジ性能を最大化したい なら Cloudflare Pages も有力。Netlify の方がDXが好き という人もいます。
第一候補：Cloudflare Pages
静的サイト・ブログ・ドキュメント
トラフィックが多いなら Cloudflare Pages。無制限帯域でコスト爆発しない。Netlify CMS と一緒に使いたい、既存Netlifyに乗っている なら Netlify継続でOK。Vercelでも問題なく動きますが、静的特化用途では他2つの方が安価になりやすいです。
Render / Railway / Fly.io
バックエンドAPI・常時稼働サーバーが要る
Vercelは厳しい領域。Render か Railway がシンプル、Fly.io はもう少し玄人寄り。Heroku が好きだった人 は Render が違和感少ない。AWSの土台が嫌で逃げたい個人開発者 は Railway や Fly.io が選ばれます。
Render / Railway
フロント + バックエンド + DB を一気に揃えたい
Render か Railway が定番。1つのダッシュボードで Web + API + Worker + DB + Redis が揃うので、構成図がシンプル。グローバル展開 まで意識するなら Fly.io、シンプルさ最優先 なら Railway。
AWS Amplify
既にAWSがある組織
AWS Amplify が無理なく入る選択肢。Cognito、IAM、S3、CloudFrontといった既存資産と統合しやすく、社内認証や監査要件にも合わせやすいです。逆に、AWSを使ってない組織がAmplifyだけ導入するメリットは薄め。
Fly.io
Dockerで何でも動かしたい
Fly.io。Dockerfileがあれば基本動く、永続ボリュームあり、複数リージョン配置あり、WebSocket安定。Vercel/Netlify では動かないアプリ を逃がす場所として使われやすいです。
Cloudflare Pages + Workers
グローバル分散・低レイテンシが最優先
Cloudflare Pages + Workers。世界300拠点超のエッジで実行、料金も安い。日本国内ユーザーだけが対象 なら、ここまで分散させなくてもOK。
ベンダーロックインの強さで見ると
移行のしやすさ という観点でも差があります。
| サービス | ロックイン度 | 移行難易度 |
|---|---|---|
| Vercel | 中 | Next.js固有機能(ISR、Image Optimization)を多用すると移行が重くなる |
| Netlify | 低〜中 | Netlify Functions固有部分が壁、それ以外は標準的 |
| Cloudflare Pages | 中 | Workers / D1 を使い込むと依存度が上がる |
| Render | 低 | 標準的なNode.js / Docker構成、移行しやすい |
| Fly.io | 低 | Dockerベース、最も移行しやすい |
| Railway | 低 | 標準構成中心、抜けやすい |
| AWS Amplify | 高 | Cognito / AppSync まで使うと事実上AWSから離れにくい |
将来的に他基盤へ移すかも を意識するなら、Render / Fly.io / Railway 寄りの方が抜けやすい構成になります。
逆に、そのプラットフォームで完結することを前提に最適化したい なら Vercel や Amplify を選ぶ方が機能を活かせます。
どう選ぶと迷わないか
選び方の軸を整理すると、次の4つで大半の判断ができます。
- Next.jsを使うか YES → Vercel / Netlify / Cloudflare Pages、NO → Render / Fly.io / Railway / Amplify
- バックエンド処理やDBもまとめたいか YES → Render / Fly.io / Railway、NO → Vercel / Netlify / Cloudflare Pages + 別DB
- トラフィックが多くなる見込みか YES → Cloudflare Pages(帯域無制限)、NO → どれでも無料枠で足りる
- AWS資産との統合が必要か YES → AWS Amplify、NO → 上記の中から選ぶ
この4軸を順に当てるだけで、候補は2〜3個に絞れます。
ありがちな選び方の失敗
1. 流行っている だけでVercelを選ぶ
Vercelは強力ですが、バッチ処理が要る 常時稼働ワーカーが要る 案件で選ぶと詰まります。Vercel が流行っているから ではなく、自分の案件がVercelの得意領域に合うか で判断する方が安全です。
Vercelが流行っている理由は？AIの影響もあるのか実務目線で整理 も合わせて読むと、流行の文脈と自分の案件のズレが見えやすくなります。
2. 料金表だけで Cloudflare Pages を選ぶ
Next.js の最新機能 や Image Optimization の挙動はVercelほど素直ではありません。帯域が増える前提なら強い、Next.js を最大限活かしたいならVercel のバランスで判断します。
3. AWS慣れで Amplify を選んでしまう
「Cognito の挙動」、AppSync のスキーマ管理、デプロイ周りの独自仕様 で詰まりやすいです。AWS がすでに前提にある組織 でだけ無理なく入る選択肢、と理解した方が安全です。
4. 全部 Render に寄せてDBごとロックインする
Renderは便利ですが、PostgreSQLを公式DBにしてアプリと密結合 させると、抜けるときに重くなります。本番DBは外部マネージド(Supabase、Neon)、アプリだけRender のような分離構成も検討の価値があります。
5. 1つに統一 を目指して苦しくなる
フロント
Vercel
ワーカー
Render
DB
Supabase
実務では、フロントはVercel、ワーカーはRender、DBはSupabase のような複合構成も普通にあります。
全部1つに乗せるよりも、それぞれの得意な場所に置く 方が運用が安定することも多いです。
小規模サービスのインフラはどこまで必要？ や クラウド・VPS・レンタルサーバーの違い もこの判断の参考になります。
まとめ
Vercelは強いですが、唯一の正解 ではありません。
他のサービスと比較すると、得意領域、料金構造、ベンダーロックインの強さでそれぞれ違いがあり、案件によっては Vercel 以外の方が合うことも普通にあります。
最後にもう一度、選び方の軸をまとめます。
- Next.js中心 + フロント主役 → Vercel
- 静的サイト + 大量トラフィック → Cloudflare Pages
- Jamstack の伝統的な構成 → Netlify
- バックエンド・ワーカー・DB込み → Render / Railway
- Docker + 永続ボリューム + グローバル → Fly.io
- AWS資産との統合前提 → AWS Amplify
流行っているから ではなく、案件の性質に合う場所に置く という基本に立ち返ると、デプロイ先選びはかなり迷いにくくなります。
Vercelと他サービス比較に関するよくある質問
Q. VercelとNetlifyの最大の違いは？
A. Next.js対応の深さです。VercelはNext.jsの開発元なので最新機能対応が常に最速。NetlifyはJamstack全般(Astro、Eleventy、Hugo)に強く、Netlify Identity Netlify CMS のような独自統合機能が魅力です。
Q. Cloudflare Pages は Vercel より安い？
A. トラフィックが多いほど顕著に安いです。Cloudflare Pages は帯域無制限、Workers Paid プランも月$5から。月数百GB〜TB級の帯域 が出るサイトでは桁違いのコスト差になります。
Q. RenderとRailwayはどう違う？
A. Render は Heroku の正統後継 、Railway は 開発体験を最優先した新世代。Render は安定運用と細かい設定、Railway は git push してすぐ動く のシンプルさが特徴です。
Q. Fly.io はどんなときに選ぶ？
A. Docker で動かしたい、永続ボリュームが要る、WebSocket やリアルタイム通信が中心、複数リージョン配置したい、のいずれかに該当するときです。Vercel系より玄人向けで、設定の自由度が高い分、難易度も上がります。
Q. AWS Amplify は Vercel の代わりになる？
A. AWSエコシステムを前提とした組織 でなら近い役割を果たします。ただし、フロント開発者の体験では Vercel の方が圧倒的に滑らか。AWS資産がない組織がAmplifyだけ導入する 場合は、Vercelの方が無理がないことが多いです。
Q. 複数サービスを組み合わせる構成はあり？
A. 普通にあります。フロント = Vercel、API = Render、DB = Supabase、画像 = Cloudflare R2 のような構成は実務でよくあります。「全部1つに寄せる」 必要はなく、それぞれの得意な場所に置く 方が運用が安定します。
Q. 個人開発で最初に選ぶならどれが無難？
A. Next.js を書くなら Vercel、それ以外なら Railway か Render。どれも無料枠で十分動くので、まず書いて公開する を最短で実現できます。本格運用に入ってから、料金や機能を見て移行を検討するので十分です。
各サービスの個別解説
このページは比較が中心です。各サービス単体の特徴・料金・使い方は個別記事で解説しています。
参考リンク
- Vercel: Documentation
- Netlify: Documentation
- Cloudflare Pages: Documentation
- Render: Documentation
- Fly.io: Documentation
- Railway: Documentation
- AWS Amplify: Documentation