Source: Dev.to

結論（おすすめ1つ）

静的サイト・JAMstack 中心で帯域コストを抑えたいなら Cloudflare Pages への移行を勧める。理由は3つ。Cloudflare はビルド成果物の配信帯域に課金しない設計で大量アクセス時のコスト見通しが立てやすいこと、Workers と統合してエッジ実行を同一プラットフォームで完結できること、独自ドメイン配下の DNS・CDN・WAF を一元管理できることだ。逆に Next.js の ISR や Image Optimization、Server Actions を全面的に使い込んでいるなら Vercel 残留が無難で、無理な移行はコスト増になる。

項目 Vercel Cloudflare Pages

料金体系 帯域・実行回数・ビルド時間に従量課金（公式の料金ページで要確認） 静的配信は帯域無課金、Functions 実行はリクエスト課金（公式の料金ページで要確認）

無料枠 Hobby プランあり、商用利用に制限（公式の料金ページで要確認） Free プランあり、ビルド回数に上限（公式の料金ページで要確認）

移行コスト — 静的サイトは低／Next.js 機能依存が深いと中〜高

対応言語/FW Next.js を筆頭に Astro・SvelteKit・Vite 等 同様の主要 FW に対応、SSR は Workers/next-on-pages 経由

金額は変動するため、必ず両社公式の料金ページで最新値を確認してほしい。 Cloudflare Wrangler を使った最小手順を示す。まず CLI を導入しログインする。 npm install -g wrangler wrangler login

静的サイト（Astro / Vite / 純粋な静的出力）なら、ビルド出力ディレクトリを指定してデプロイするだけで動く。

例: ビルド出力が ./dist の場合

npm run build wrangler pages deploy ./dist —project-name=my-site

Next.js を移行する場合は専用アダプタを使う。 npm install —save-dev @cloudflare/next-on-pages npx @cloudflare/next-on-pages wrangler pages deploy .vercel/output/static —project-name=my-next-app

環境変数は Vercel の vercel env pull で控えを取り、Cloudflare 側に移す。

Vercel 側の env を .env に書き出して内容を確認

vercel env pull .env.production

Cloudflare へ反映（Secret は —secret で）

wrangler pages secret put API_KEY —project-name=my-next-app

最後にダッシュボードまたは DNS でカスタムドメインを Pages プロジェクトへ向け替え、本番切替前にプレビュー URL で動作確認する。next-on-pages 利用時は Edge Runtime 非対応 API（Node.js 固有モジュール等）でビルドが落ちることがあるため、移行前にログを確認しておく。 Cloudflare Pages が向くケース 静的サイト中心で配信帯域のコストを読みやすくしたいチーム 既に Cloudflare の DNS / CDN / WAF を使っており管理を一元化したい場合 エッジ実行（Workers）を主軸に据えたい中〜大規模トラフィックのサービス Vercel 残留が無難なケース Next.js の ISR・Image Optimization・Server Actions を深く使っている プレビューデプロイや Analytics など Vercel 統合機能の運用が定着している 移行検証に割ける工数が乏しい少人数チーム 避けるべきケース Node.js ランタイム固有 API への依存が多く、Edge Runtime 化の見積もりが立っていない 料金差の根拠を確認せず「安そうだから」だけで移行を決めること（必ず実トラフィックで試算する）