「Next.js のアプリ、Vercel に置くべき？それとも Cloudflare や AWS の方が安い？」——技術選定の相談で最も多い問いの一つです。ネット上の比較記事は「Vercel は高い」か「Vercel 一択」かの極端なポジショントークに偏りがちで、判断材料になりません。
この記事は、Vercel を含む複数の Next.js 製プロダクトを実運用してきた立場から、できる限り偏りなく4つの選択肢を比較し、「どの規模・どの要件にどれを選ぶか」の意思決定フレームワークを示します。Vercel の機能は公式ドキュメントに忠実に、競合は確立された一般的特性で評価します（各社の価格・上限は変動するため、最終判断は必ず各公式で最新値を確認してください）。
結論を先に：万能の正解はありません。 「開発速度・手離れ＝Vercel」「帯域コスト・広域エッジ＝Cloudflare」「AWS統合・統制＝AWS」「多フレームワークJamstack＝Netlify」。以下で軸ごとに分解します。Vercel を選んだ後の本番運用は Vercel 本番運用ガイド を参照してください。
4つの選択肢を一言で
| 基盤 | 一言でいうと | 最も向く場面 |
|---|---|---|
| Vercel | Next.js の純正基盤。DX と手離れが最高 | Next.js を速く・安全に出したい。少人数・スタートアップ |
| Netlify | 多フレームワーク対応の Jamstack 基盤 | 多様な SSG/フロント、Vercel に近い DX を別ベンダーで |
| Cloudflare（Pages + Workers） | 広域エッジ＋安い帯域 | グローバル配信・帯域コスト最優先・エッジ実行 |
| AWS（Amplify Hosting / 自前 ECS・Lambda＋OpenNext） | 深い AWS 統合と完全な制御 | VPC/コンプライアンス/既存AWS資産/大規模統制 |
軸①：開発体験（DX）と Next.js 追随
Vercel は Next.js の開発元であり、新機能（App Router、Cache Components/PPR、Server Actions、use cache 等）が最速で・ゼロ設定で本番に乗ります。プレビューURL・Instant Rollback・Rolling Releases・ISR・画像最適化が「考えなくても」効く（デプロイ・キャッシュ）。
- Vercel：◎ Next.js なら最高。新機能の互換性で悩む時間がほぼゼロ。
- Netlify：○ DX は近い。多フレームワーク対応。Next.js 追随は Vercel に一歩譲る。
- Cloudflare：△〜○ Pages は良い。ただし Next.js の最新機能をフルに動かすには OpenNext などのアダプタや設定が要る場合がある。
- AWS（自前）：△ Amplify Hosting は改善したが、SSR/ISR/画像最適化を自前で組むと OpenNext/SST 等の作り込みが必要。制御は最大だが DX は最小。
DX はコストです。少人数チームでは「設定・互換性・運用に溶ける時間」が最大の支出。Vercel の DX が人件費を直接節約する局面は多い。
軸②：コンピュートモデル
| 基盤 | 実行モデル | 含意 |
|---|---|---|
| Vercel | Fluid Compute（通常の Node.js/Python を同一リージョン・同一価格で、1インスタンス複数リクエスト） | フル Node.js 互換。コールドスタート低減。I/O 主体ほど安い（Functions） |
| Netlify | Netlify Functions（AWS Lambda ベース）／Edge Functions | 一般的なサーバーレス。Lambda 互換の制約 |
| Cloudflare | Workers（V8 isolates） | 超低遅延・広域。ただし Node.js 互換に穴があり、ネイティブモジュールや一部 API で詰まることがある |
| AWS | Lambda / ECS / Fargate など自由 | 何でもできる。が、すべて自分で設計・運用 |
Cloudflare Workers は「世界中のエッジで V8 isolate を即起動」する点が技術的に強力で、レイテンシとスケールに優れます。一方、完全な Node.js 互換が要る（既存の npm パッケージをそのまま動かす）なら Vercel の Fluid Compute が無難です。2026年の Vercel は「Edge ではなく Fluid（通常 Node.js）を推奨」しており、互換性の罠を避けつつ低レイテンシを得られます。
軸③：コスト（帯域・使用量・TCO）
ここが最も誤解されます。「基盤の単価」ではなく「総保有コスト（TCO）」で見るべきです。
帯域・使用量の単価傾向
- Cloudflare：帯域コストに圧倒的に強い。R2 は egress（下り転送）無料、Workers の無料枠も大きい。大量配信・メディア配信ではコスト最安帯になりやすい。
- Vercel：使用量課金は Active CPU 方式（CPU 実行時間のみ課金・I/O 待ち非課金）で I/O 主体アプリは効率的（コスト）。ただし帯域（Fast Data Transfer）・画像最適化・関数使用量は規模が大きくなると相対的に高くなりやすい。キャッシュ設計で大きく変わる。
- Netlify：Vercel と近い構造。プランと帯域従量。
- AWS（自前）：単価は最安にしうるが、設計・運用・監視の人件費が乗る。
TCO で考える
総保有コスト(TCO) = インフラ費 + 運用人件費 + 機会損失(遅さ・障害)
- 少人数で速く出す：Vercel の開発速度・手離れが人件費を大きく節約。多少のインフラ単価差を上回ることが多い。
- 大規模配信・帯域支配的：Cloudflare の帯域優位が効く。あるいは AWS で作り込む。
- 既に強い AWS チームがある：自前 AWS の単価優位を運用力で回収できる。
正直な指針：月数千〜数万 PV のプロダクトで「Vercel は高い」は多くの場合幻想です。請求が跳ねるのは、キャッシュ未設計（毎回関数が走る）か画像最適化の使いすぎが原因のことが大半。Vercel はキャッシュ設計とコスト最適化で十分に安く運用できます。本当に帯域が支配的な大規模配信になって初めて、Cloudflare/AWS への移行が経済合理になります。
軸④：エッジ・グローバル配信
- Cloudflare：エッジネットワークの広さ・近さは随一。エッジ実行（Workers）と組み合わせると、超低遅延の動的処理が作れる。
- Vercel：グローバル CDN ＋ Fluid のクロスリージョン/AZ フェイルオーバー。関数は既定単一リージョン（Pro/Ent で複数）。エッジ実行より「通常 Node.js を近くで」路線。
- Netlify：CDN ＋ Edge Functions。
- AWS：CloudFront ＋ Lambda@Edge / 自前マルチリージョン。最大の自由度、最大の運用。
軸⑤：ロックインと出口戦略
- Vercel/Netlify：標準フレームワーク（Next.js 等）で書く限り、コードのロックインは小さい。Vercel 固有機能（Edge Config、Blob、Firewall ルール、Rolling Releases）に依存するほど移行コストは上がる。
- Cloudflare：Workers ランタイム・D1・KV・Durable Objects に深く乗ると固有性が高い。
- AWS（自前）：IaC（Terraform/CDK）で組めば再現性は高いが、AWS 前提の設計になる。
実務の知恵：アプリのコアロジックはフレームワーク標準で書き、プラットフォーム固有機能は境界（薄いアダプタ）越しに使う。これで「速く Vercel で出す → 必要なら移行」の選択肢を残せます（ETC: 変更しやすさ の原則）。
意思決定フローチャート
Q1. Next.js を使い、開発速度と手離れが最優先？
→ YES：Vercel（迷ったらここ。少人数・スタートアップの既定解）
Q2. 帯域・メディア配信がコストの支配項？ 広域エッジ実行が要る？
→ YES：Cloudflare（R2 egress無料・Workers）
Q3. 既存AWS資産・VPC内通信・厳格なコンプライアンス/統制が要る？
強い基盤運用チームがある？
→ YES：AWS（Amplify Hosting or 自前 ECS/Lambda + OpenNext/SST）
Q4. 多様なフレームワークのJamstackを別ベンダーのDXで？
→ YES：Netlify
該当が複数 → 「コアはVercelで速く、配信の重い部分だけCloudflare/AWS」の
ハイブリッドも有効（例：アプリ=Vercel、大容量メディア=R2/S3+CDN）
ケース別おすすめ
| ケース | おすすめ | 理由 |
|---|---|---|
| スタートアップの新規 SaaS（Next.js） | Vercel | 速度と手離れで人件費を節約、プレビュー/ロールバックで安全に出荷 |
| グローバルなメディア/EC（大量配信） | Cloudflare or ハイブリッド | 帯域コスト最優先、エッジ低遅延 |
| 金融・医療・公共（VPC・監査・統制） | AWS | コンプライアンス・ネットワーク統制・既存統合 |
| 多フレームワーク・代理店制作 | Netlify / Vercel | 多様な案件に均質なDX |
| 既に AWS に全資産、専任SRE在籍 | AWS 自前 + OpenNext | 単価優位を運用力で回収 |
まとめ：基盤選定は「設計判断」
「どれが一番いい？」に唯一解はありません。要件（速度・コスト構造・統制・チーム体制）から逆算するのが技術選定です。
- Next.js × 速度・手離れ → Vercel（少人数の既定解。請求は設計で十分下げられる）
- 帯域・広域エッジ → Cloudflare
- AWS統合・統制・大規模 → AWS（Amplify/自前+OpenNext）
- 多フレームワーク Jamstack → Netlify
- TCO（インフラ＋人件費＋機会損失）で判断し、必要ならハイブリッド
私は特定ベンダーの代理ではなく、御社の要件に最適な基盤を一緒に選ぶ立場で支援します。Vercel を選ぶ場合の本番運用・コスト最適化・移行も、他基盤との比較設計も承ります。
本記事の Vercel に関する記述は Vercel 公式ドキュメント（2026年6月時点）に基づきます。競合各社の価格・上限・機能は変動します。本番採用前に各社公式で最新値を必ずご確認ください。