結論（おすすめ1つ）
Cloudflare Pages への移行を推奨する。
Cloudflare Pages は無料枠が広く、グローバルエッジの応答速度でも Vercel に劣らない。ただし Next.js の ISR や一部の App Router 機能は互換アダプタ経由となるため、純粋な静的サイト・SPA・Workers で完結する API 構成であれば移行コストはほぼゼロに等しい。Vercel に依存した高度な Next.js 機能を多用しているなら、移行前に動作確認を必ず行うこと。
比較表（料金/無料枠/移行コスト/対応言語）
| 項目 | Vercel | Cloudflare Pages |
|---|---|---|
| 無料枠のビルド数 | 公式の料金ページで要確認 | 公式の料金ページで要確認 |
| 無料枠の帯域 | 公式の料金ページで要確認 | 無制限（公式発表に基づく） |
| チームメンバー数（無料） | 1名（Hobby プラン） | 無制限 |
| サーバーレス実行環境 | Vercel Functions / Edge Functions | Cloudflare Workers / Functions |
| Next.js サポート | ネイティブ（同一チーム開発） |
@cloudflare/next-on-pages アダプタ経由 |
| ISR サポート | ネイティブ | 限定的・要検証 |
| カスタムドメイン | 無料プランで利用可 | 無料プランで利用可 |
| 対応フレームワーク | Next.js, Nuxt, SvelteKit, Astro 等 | 同左（フレームワーク検出自動） |
| ビルドランタイム | Node.js | Node.js（Wrangler 経由） |
| 移行コスト目安 | — | 静的/SPA: 低、Next.js 高度機能: 中〜高 |
| エッジロケーション数 | 公式の料金ページで要確認 | 300 超（Cloudflare 公式発表に基づく） |
移行手順
1. Wrangler CLI のインストール
npm install -g wrangler
wrangler login
2. 既存プロジェクトの確認とアダプタ導入（Next.js の場合）
# Next.js プロジェクトの場合のみ
npm install --save-dev @cloudflare/next-on-pages
npx @cloudflare/next-on-pages
静的サイトや SPA（Vite/Astro/SvelteKit 等）はアダプタ不要。
3. wrangler.toml の作成
name = "my-app"
compatibility_date = "2024-09-23"
pages_build_output_dir = ".vercel/output/static" # Next.js の場合
# 静的サイトの場合は dist や out など出力ディレクトリに合わせる
4. 環境変数の移行
Vercel ダッシュボードの「Environment Variables」から値を書き出し、Cloudflare Pages のダッシュボード（Settings → Environment variables）へ手動で転記する。シークレット系は必ず「Encrypted」設定を使うこと。
# ローカル確認用（.dev.vars ファイルに記述）
echo "API_KEY=your_key_here" >> .dev.vars
5. Cloudflare Pages へのデプロイ
# Git 連携（推奨）
# Cloudflare ダッシュボード → Pages → Create a project → Connect to Git
# または CLI から直接デプロイ
wrangler pages deploy ./dist --project-name=my-app
6. カスタムドメインの切り替え
Cloudflare ダッシュボード → Pages → my-app → Custom domains → Set up a custom domain
DNS を Cloudflare 管理下に置いている場合は CNAME レコードが自動設定される。外部 DNS の場合は CNAME レコードを手動で <project>.pages.dev に向ける。
7. Vercel の API ルートを Workers Functions へ変換
// Vercel: pages/api/hello.ts
export default function handler(req, res) {
res.json({ message: "hello" });
}
// Cloudflare Pages Functions: functions/api/hello.js
export async function onRequest(context) {
return Response.json({ message: "hello" });
}
向き不向き
Cloudflare Pages が向くケース
- 静的サイト・SPA 中心のチーム: ビルド成果物をそのまま置くだけで動く
- 個人開発・小規模チーム: 無料枠のチームメンバー制限がなく、コスト上限を気にせず複数人で使える
- グローバル配信が重要なプロダクト: Cloudflare のエッジネットワークがそのまま使える
- Cloudflare DNS・WAF をすでに使っているチーム: ダッシュボードが統合されており運用が楽
- Remix, Astro, SvelteKit ユーザー: これらは Cloudflare Workers ネイティブアダプタが成熟している
Vercel を維持すべきケース
- Next.js の ISR・PPR・Server Actions をフル活用している: Cloudflare 上の互換アダプタでは再現できない挙動がある
- Vercel Analytics や Speed Insights を業務指標にしている: 移行後は同等ツールを別途用意する必要がある
- ゼロコンフィグのプレビューデプロイを重視するエンタープライズチーム: Vercel の PR プレビュー体験は現時点でも優秀
- Next.js Edge Middleware を複雑に組んでいる: Workers との API 差異で書き直しが必要になるケースがある
避けるべき移行パターン
- 動作確認なしに本番を一括切り替えする（必ずステージング環境で検証する）
-
next/imageの最適化を多用している場合に検証をスキップする（Cloudflare 側の Image Resizing 設定が別途必要） - Vercel の cron jobs を使っている場合に対応を後回しにする（Cloudflare Workers Cron Triggers への書き換えが必要）
Top comments (0)