結論(おすすめ1つ)
Cloudflare Pages への移行を推奨する。
無料枠のリクエスト数・帯域制限が実用上ほぼ無制限であり、個人プロジェクトから中規模サービスまでコスト圧力なしに運用できる。Vercel の強みである Next.js との密結合が不要なら、ロックイン解消と CDN 性能の向上を同時に得られる。移行コストは静的サイト・Vite/SvelteKit 系では半日以内に収まるケースが多い。
比較表(料金/無料枠/移行コスト/対応言語)
| 項目 | Vercel | Cloudflare Pages |
|---|---|---|
| 無料枠 帯域 | 制限あり(公式の料金ページで要確認) | 商用利用含め実質無制限 |
| 無料枠 ビルド数 | 月間上限あり(公式要確認) | 月間500ビルド(要確認) |
| Serverless Functions | Edge Functions / Serverless Functions | Pages Functions(Workers ベース) |
| Next.js SSR 対応 | ネイティブ・最高水準 | @cloudflare/next-on-pages 経由(制約あり) |
| SvelteKit / Astro / Remix | アダプター要 | アダプター要(公式サポート済み) |
| カスタムドメイン | 無料 | 無料 |
| プレビューデプロイ | あり | あり |
| 移行コスト(静的/SPA) | 低(設定ファイル数行) | 低(設定ファイル数行) |
| 移行コスト(SSR/Edge) | — | 中〜高(Workers API 差異あり) |
| ランタイム互換性 | Node.js / Edge Runtime | Workers Runtime(Node.js API 部分互換) |
移行手順
1. Wrangler CLI のインストール
npm install -g wrangler
wrangler login
2. Cloudflare Pages プロジェクトの作成
# Git 連携なしで直接デプロイする場合
wrangler pages project create my-app
# ビルド済み成果物をデプロイ
npm run build
wrangler pages deploy ./dist --project-name=my-app
Git 連携する場合は Cloudflare ダッシュボードの「Workers & Pages」→「Create」から GitHub リポジトリを接続する。
3. ビルド設定の更新
wrangler.toml(またはダッシュボード上の設定)に以下を記述する。
name = "my-app"
pages_build_output_dir = "dist"
compatibility_date = "2024-09-23"
フレームワーク別ビルドコマンドの例:
# Vite
npm run build # → dist/
# Astro
npx astro build # → dist/
# SvelteKit(CF Pages アダプター使用)
npm run build # → .svelte-kit/cloudflare/
4. 環境変数の移行
Vercel ダッシュボードの「Settings → Environment Variables」から値を控え、Cloudflare ダッシュボードまたは CLI で設定する。
wrangler pages secret put API_KEY --project-name=my-app
# プロンプトに値を入力
.env ファイルから一括設定したい場合:
# 各行を読み込んで投入するシェルスクリプト例
while IFS='=' read -r key value; do
[[ "$key" =~ ^#.*$ || -z "$key" ]] && continue
echo "$value" | wrangler pages secret put "$key" --project-name=my-app
done < .env.production
5. カスタムドメインの切り替え
- Cloudflare ダッシュボードでプロジェクトに「Custom domain」を追加
- DNS が Cloudflare 管理下であれば CNAME が自動設定される
- 外部 DNS の場合は CNAME レコードを
<project>.pages.devに向ける - Vercel 側のドメイン割り当てを解除し、TTL 切れを待って完全切り替え
6. Pages Functions(サーバーサイド処理)の移行
Vercel の API Routes (/api/*.ts) を移行する場合、functions/ ディレクトリに配置する。
// functions/api/hello.ts
export const onRequest: PagesFunction = async (context) => {
return new Response(JSON.stringify({ message: "hello" }), {
headers: { "Content-Type": "application/json" },
});
};
next/headers や next/server 等 Next.js 固有の API を使っている場合は個別に代替実装が必要。
向き不向き
Cloudflare Pages が向くケース
- 静的サイト・SPA・Astro・SvelteKit を運用しており、Next.js 依存がない
- 帯域コストを抑えたい個人開発者・スタートアップ初期
- Cloudflare の CDN・WAF・R2・KV を組み合わせたインフラに統一したい
- Workers Runtime の制約(Node.js API の部分非互換) を許容できるチーム
Vercel を維持すべきケース
- App Router / Server Actions 等 Next.js の最新機能 をフル活用している
- ISR(Incremental Static Regeneration)に強く依存している
- チームが Vercel の DX(プレビュー URL、コメント機能等)に慣れており移行コストが見合わない
- Node.js ネイティブモジュール(
sharp、canvas等)を Functions 内で使用している
避けるべきパターン
- Next.js の Edge Runtime 以外の SSR を多用しているのに、工数見積もりなしで移行を始める
- 本番ドメインのカット先を DNS TTL を確認せず即日切り替える
- Vercel の
rewrites/headers設定を_redirectsファイルへ機械的にコピーし動作確認を省略する
Top comments (0)