DEV Community

スシロー
スシロー

Posted on

【2026】Vercel vs Cloudflare Pages 移行ガイド：料金・移行コストで選ぶ

#saas #devops #tutorial #webdev

結論（おすすめ1つ）

個人・小規模チームには Cloudflare Pages を推奨する。

無料枠の帯域制限がなく、エッジ関数（Workers）との統合がシームレスなため、Next.js 以外のフレームワークや静的サイト中心のプロジェクトであれば移行コストに見合うリターンが得やすい。一方、App Router や Server Actions を深く使い込んだ Next.js プロジェクトは Vercel に留まる方が現実的だ。

比較表（料金/無料枠/移行コスト/対応言語）

項目 Vercel Cloudflare Pages
無料枠 あり（帯域・ビルド分数に上限あり） あり（帯域無制限、ビルド上限あり）
有料プラン料金 公式の料金ページで要確認 公式の料金ページで要確認
チーム機能 無料プランは個人利用のみ 無料プランでも複数メンバー可
サーバーレス実行時間上限 プランにより異なる（公式要確認） Workers の制約に依存（公式要確認）
Next.js サポート ネイティブ（開発元） @cloudflare/next-on-pages 経由で対応
対応フレームワーク Next.js/Nuxt/SvelteKit 等 同左＋静的サイト全般
カスタムドメイン 無料枠でも利用可 無料枠でも利用可
エッジ関数 Edge Runtime Cloudflare Workers
移行コスト — 低〜中（フレームワーク依存）

移行手順

1. Cloudflare アカウントと CLI を準備する 

npm install -g wrangler
wrangler login
Enter fullscreen mode Exit fullscreen mode

2. プロジェクトをリポジトリに接続する

Cloudflare ダッシュボード → Workers & Pages → Create → Pages → Git に接続し、対象リポジトリを選択する。

3. ビルド設定を指定する（Next.js の例） 

Framework preset : Next.js
Build command    : npx @cloudflare/next-on-pages@1
Output directory : .vercel/output/static
Node.js version  : 20.x
Enter fullscreen mode Exit fullscreen mode

@cloudflare/next-on-pages は全 API を網羅しない。next/image の最適化や ISR の完全互換は現時点で保証されないため、事前に互換チェックを実施すること。

4. 環境変数を移行する

Vercel ダッシュボードの .env をエクスポートし、Cloudflare Pages の環境変数セクションへ手動で貼り付ける。機密値は必ず「暗号化」オプションを有効にする。

# ローカルで差分確認する場合
wrangler pages dev .vercel/output/static --compatibility-date=2024-09-23
Enter fullscreen mode Exit fullscreen mode

5. カスタムドメインを切り替える 

1. Cloudflare Pages のカスタムドメインを設定（CNAME 自動生成）
2. DNS レジストラで CNAME を Cloudflare の値へ変更
3. Vercel 側の[ドメイン](https://px.a8.net/svt/ejp?a8mat=4B3XB4+4VMW8I+50+2HU3GX)を削除
4. TTL 伝播（数分〜数時間）を待って動作確認
Enter fullscreen mode Exit fullscreen mode

6. Vercel プロジェクトを削除する（確認後） 

vercel remove <project-name> --yes
Enter fullscreen mode Exit fullscreen mode

向き不向き

Cloudflare Pages が向くケース

  • 静的サイト・JAMstack 構成がメインで、動的処理が軽微なプロジェクト
  • SvelteKit・Nuxt・Astro など Next.js 以外のフレームワークを使うチーム
  • 個人開発者や少人数チームで無料枠のコスト効率を重視する場合
  • Cloudflare DNS をすでに使っており、ネットワーク管理を一元化したい場合
  • エッジでのリクエスト処理（地理判定・A/B テスト等）を Workers で細かく制御したい場合

Vercel に留まるべきケース

  • Next.js の App Router・Server Components・Streaming を本番で深く使っている
  • next/image の自動最適化や ISR をそのまま動かす必要がある
  • プレビューデプロイをチーム全員のコードレビューフローに組み込んでいる
  • Vercel Analytics や Speed Insights をモニタリングの中核に据えている

避けるべきパターン

  • 移行先の制約を検証せずに本番ドメインを即切り替える（ステージング環境で必ず先行検証する）
  • next export 相当の完全静的化ができないページを含む状態で移行を急ぐ
  • Workers のコールドスタート特性を考慮せず、レスポンスタイム SLA が厳しいサービスに適用する

Top comments (0)