Vercel vs Cloudflare (Workers + Pages) 比較

Next.jsの生みの親——ゼロコンフィグで最新機能を遅延なく提供

VS
Cloudflare (Workers + Pages)

グローバルなV8-isolateネットワーク——エグレス無料、そして独自のNext.jsレイヤーvinextを搭載

15 分で読了DevOps

クイック結論

状況次第で判断しよう。最新のNext.js機能を遅延なく使いたいならVercelを選ぶこと——パリティのリスクはゼロだ。帯域幅の重い、グローバルなプロジェクトで、コストの予測可能性を優先するならCloudflareが正しい賭けだ。OpenNextに加えて、まだベータだが急速に進化しているvinextもある。重要な案件はOpenNextから始め、新規プロジェクトではvinextを試してみるとよい。

VercelCloudflare (Workers + Pages)
結論をすべて読む

スコア比較

グラフを読み込み中...

詳細スコア

詳細スコア: Vercel Cloudflare (Workers + Pages) — カテゴリー別10点満点のスコア
カテゴリーVercelCloudflare (Workers + Pages)
パフォーマンス
8/10
9/10
学習のしやすさ
9/10
6/10
エコシステム
9/10
7/10
コミュニティ
9/10
8/10
求人市場
8/10
7/10
将来性
8/10
8/10

長所と短所

Vercel

長所

  • Next.jsを開発している企業であるため、新機能(PPR、Turbopack、App Router)がまずここで成熟する
  • ゼロコンフィグデプロイ——git pushだけで十分、build/ISR/エッジミドルウェアが自動設定される
  • 126 PoP/51か国のCDN + 20のcompute対応リージョンによる低遅延SSR
  • Fluid ComputeによるActive CPU課金——I/O待機中は課金が停止する
  • PreviewデプロイはすべてのPRで自動生成され、チームのワークフローに自然に統合される
  • 公式のNext.js Cache API(revalidateTag、revalidatePath)がファーストパーティでサポートされている

短所

  • Fast Data Transferは$0.15/GB(Proでは最初の1TBが含まれる)——帯域幅の重いサイトではコストがすぐに膨らむ
  • ネイティブなリレーショナル/ベクターデータベースがない;Blob Storageを除き、データは外部プロバイダー(Marketplace)に依存する
  • SAML SSOはProでは別途アドオン(月額$300);Directory Sync(SCIM)はEnterpriseプランのみ
  • エッジPoP数(126)はCloudflareのグローバルな展開規模に比べてより限定的
  • 関数ベースの料金モデルは、リクエスト数が多くCPU使用量が少ないサイトではWorkersに比べて割高になりうる

最適な用途

新しいNext.js機能(PPR、Turbopack、Cache API)を遅延なく使いたいチームゼロDevOpsで高速に反復開発を行うスタートアップやエージェンシーPreviewデプロイを基盤としたチームワークフローを求めるプロダクトチームCPU負荷は高いが中程度のトラフィックのSSRアプリケーション

Cloudflare (Workers + Pages)

長所

  • エグレス/帯域幅の料金なし——課金されるのはリクエスト(追加100万件あたり$0.30)とCPU時間(追加100万CPU-msあたり$0.02)のみ
  • ネットワークの95%がインターネット人口の50ms圏内——非常に広い地理的カバレッジ
  • V8 isolateアーキテクチャにより、コンテナベースの関数に比べて構造的にコールドスタートが軽量
  • vinextにより、Next.js 16のAPI表面の約94%が再実装された形でサポートされている
  • KV、R2、D1、Hyperdrive、Durable Objectsにより、データを同じエッジネットワーク内に保持できる
  • Access for Workers(2026年8月)により、IDポリシーが直接Workerに紐付けられ、route/プレビューURLに関わらず一貫する

短所

  • vinextはベータ版——採用前に`npx vinext check`を実行することが推奨されている;GitHubリポジトリも、まだすべてのプロダクションワークロードの完全な代替にはなっていないと述べている
  • OpenNextアダプターのISR+PPR用R2キャッシュバックエンドは、約24時間後に古くなるリスクを抱えている(Issue #662;アダプターのv1.0.2で報告され、いまだ未解決)
  • next/imageの最適化は部分的にしかサポートされていない——一部のシナリオでは追加設定が必要
  • Next.jsの生みの親ではないため、新しいフレームワーク機能はVercelに比べて遅れて到着する
  • 月額$5のベース料金+リクエスト/CPU時間モデルは、低トラフィックだがCPU負荷の高いアプリケーションでは予測可能性を下げる
  • OpenNext/vinextレイヤーは、アダプターの更新やキャッシュバックエンドの選択といった追加の運用負荷をもたらす

最適な用途

帯域幅の重い(画像/動画/API負荷の高い)サイト——エグレスが無料なためコストが予測しやすいグローバルで多地域にわたるユーザーベースを持つアプリケーションKV/D1/R2/Hyperdriveのような単一エコシステムのデータ層を好むチーム集中管理されたID/アクセスポリシー(Access)を必要とする、多ルートの社内アプリケーション

コード比較

Vercel
// Vercel — Next.js 16 App Router、Cache Components(PPRがデフォルト)+ オンデマンドパージ
// next.config.ts
import type { NextConfig } from "next";

const nextConfig: NextConfig = {
  cacheComponents: true,
};

export default nextConfig;

// app/blog/[slug]/page.tsx — 'use cache' + cacheTagでキャッシュされるデータ
import { cacheTag } from "next/cache";

async function getPost(slug: string) {
  "use cache";
  cacheTag(`post-${slug}`);
  const res = await fetch(`https://api.example.com/posts/${slug}`);
  return res.json();
}

export default async function BlogPost({
  params,
}: {
  params: Promise<{ slug: string }>;
}) {
  const { slug } = await params;
  const post = await getPost(slug);

  return (
    <article>
      <h1>{post.title}</h1>
      <div dangerouslySetInnerHTML={{ __html: post.html }} />
    </article>
  );
}

// app/api/revalidate/route.ts — オンデマンドパージ(Vercel Data Cache)
// "max" = stale-while-revalidate;Webhookで即座に無効化するには { expire: 0 }
import { revalidateTag } from "next/cache";
import { NextRequest, NextResponse } from "next/server";

export async function POST(req: NextRequest) {
  const { slug } = await req.json();
  revalidateTag(`post-${slug}`, "max");
  return NextResponse.json({ revalidated: true });
}

// vercel.json — リージョン設定と関数のタイムアウト
{
  "regions": ["fra1"],
  "functions": {
    "app/api/revalidate/route.ts": { "maxDuration": 10 }
  }
}

// デプロイ
// $ vercel --prod
Cloudflare (Workers + Pages)
// Cloudflare — Next.js 16をWorkersにデプロイ(vinext、公式デフォルトの方法)
// 1) まず互換性を測定し、その後プロジェクトに追加(Vite設定はvinext initが生成)
// $ npx vinext check
// $ npx vinext init

// vite.config.ts — ルートレベルのISRにはWorkers Cache、データキャッシュにはKV
import { cloudflare } from "@cloudflare/vite-plugin";
import { cdnAdapter } from "@vinext/cloudflare/cache/cdn-adapter";
import { kvDataAdapter } from "@vinext/cloudflare/cache/kv-data-adapter";
import { defineConfig } from "vite";
import vinext from "vinext";

export default defineConfig({
  plugins: [
    vinext({
      // cdnAdapter yalnız wrangler.jsonc'de "cache": { "enabled": true } iken çalışır
      cache: { cdn: cdnAdapter(), data: kvDataAdapter() },
    }),
    cloudflare({
      viteEnvironment: { name: "rsc", childEnvironments: ["ssr"] },
    }),
  ],
});

// デプロイ — Worker設定は自動生成される
// $ npx @vinext/cloudflare deploy

// 代替案: OpenNextアダプター — open-next.config.ts
import { defineCloudflareConfig } from "@opennextjs/cloudflare";
import r2IncrementalCache from "@opennextjs/cloudflare/overrides/incremental-cache/r2-incremental-cache";

export default defineCloudflareConfig({ incrementalCache: r2IncrementalCache });
// $ opennextjs-cloudflare build && opennextjs-cloudflare deploy

// Access for Workers — WorkerをAccessアプリケーションに紐付け
// POST /accounts/{account_id}/access/apps
// "destinations": [{ "type": "worker", "worker_id": "<worker-id>" }]

結論

状況次第で判断しよう。最新のNext.js機能を遅延なく使いたいならVercelを選ぶこと——パリティのリスクはゼロだ。帯域幅の重い、グローバルなプロジェクトで、コストの予測可能性を優先するならCloudflareが正しい賭けだ。OpenNextに加えて、まだベータだが急速に進化しているvinextもある。重要な案件はOpenNextから始め、新規プロジェクトではvinextを試してみるとよい。

無料相談を受ける
FAQ

よくある質問

完全ではないが、近いところまで来ている:CloudflareのvinextレイヤーはNext.js 16のAPI表面の約94%(App Router、Server Actions、ISR、ミドルウェア)をサポートしており、公式のデフォルトルートとなっている——ただしまだベータ版だ。ドキュメントでは、既存のプロダクションアプリケーションで採用する前に`npx vinext check`を実行するよう案内している。より成熟した`@opennextjs/cloudflare`アダプターの方は、ISR+Partial PrerenderingのR2キャッシュバックエンドに古くなる問題(未解決のGitHub issue)を抱えている。

関連ブログ記事

すべての記事を見る
すべての比較