Next.jsをVercel以外へそのままデプロイできる「Vinext 1.0」が公開

Next.jsアプリをCloudflare Workersに出そうとして、OpenNextを挟んだことはないだろうか。バージョンを一つ上げた途端にビルドが通らなくなり、差分を追いかけ直した経験がある人もいるはずだ。Cloudflareは2026年9月28日、この構図そのものを変える「Vinext 1.0」を公開した(Cloudflare公式ブログ)。Next.jsのコードを書き換えずに、Viteベースの実装へ乗せ替えるだけで、Cloudflare Workers・Netlify・AWS Lambdaへデプロイできるようになる。

なぜ今までのツールでは追従が壊れ続け、Vinextではそれが起きにくいのか。1.0になって、具体的にどこまで任せられるようになったのか。

OpenNextが抱えていた問題

Next.jsを使ったことがある人なら、公式のビルドツールTurbopackがVercelに最適化されていることは知っているだろう。Cloudflare・Netlify・AWS Lambdaなど別の基盤に出すには、ひと手間かかる。Turbopackが吐いたビルド出力を、各プラットフォームが実行できる形へ作り変える必要があるからだ。この変換を担ってきたのがOpenNextだ。

Cloudflareも開発に加わってきたが、公式ブログは率直にこう認めている。「OpenNextはNext.jsのビルド出力をリバースエンジニアリングする必要があるため、バージョン間で予期しない変更が起き、その修正に多くの手間がかかる」(Cloudflare公式ブログ)。土台が人の作った出力物であり、Next.js開発チームの内部実装に依存している。だから相手が仕様を変えるたびに、変換ツールの側が追いかけ続けることになる。

Vinextは、この変換という発想そのものをやめた。「Next.jsの出力を変換するのではなく、Next.jsのAPIをViteの上に直接作り直した。単なるラッパーやアダプターではない、素のままの再実装だ」(Cloudflare公式ブログ)。Next.js互換のフレームワークを、Next.jsの出力物からではなく、Viteという別の土台の上に一から建て直した。

なぜどこでも動くようになったのか

ここで引っかかるのは、「変換」をやめて「作り直す」ことが、なぜVercel以外への移植を楽にするのかだ。これを可能にしているのは、乗せ替えた先の土台の性質だ。「Vite出力はVite Environment APIのおかげで、あらゆるプラットフォームで実行できる」(Cloudflare公式ブログ)。

Vite自体は、Next.js以外のフロントエンド開発でAstroやSvelteKit、Nuxt、Remixが使っている汎用のビルドツールで、もともと特定のホスティング事業者に結びついていない。Next.jsの機能をそのViteのプラグインとして実装し直せば、出力もVite標準の形になり、Vercel向けの変換作業自体が要らなくなる。

自分は最初、「AIに1週間書かせた実験的プロジェクト」と聞いて、動けば御の字の実験止まりだろうと身構えていた。Vinextが生まれたのは2026年2月、1人のエンジニアがAIに指示を出し、1週間で作ったプロジェクトだったからだ(Cloudflare公式ブログ)。だが1.0の発表文を読んで、その見立ては外れていたと分かった。

7か月でどこまで来たのか

2月の時点では、Next.js 16のAPI表面のカバレッジが94%、テストはVitestが1,700件以上とPlaywrightのE2Eテストが380件という規模だった(Cloudflare公式ブログ)。測り方は異なるが、7か月後の1.0では「主要な顧客から要望のあった機能について、テスト互換性が99%を超えた(キャッシュコンポーネントを除く)」という水準まで進んでいる(Cloudflare公式ブログ)。

対応範囲も広がった。App RouterだけでなくPages Routerも対応する。React Server Components・Server Actions・APIルート・ミドルウェアも、両方のルーティング方式で使える(Cloudflare公式ブログ)。Cloudflareは「Pages Routerは、大規模で移行が難しいアプリケーションを持つ顧客に今も重要だと分かった」と、対応を広げた理由を説明している(同)。

既存の計測の仕組みも引き継げる。公式ブログが対応を挙げているのは次の点だ(同)。

• next/*のAPI全般
• 認証・画像最適化・フォント・メタデータといった定番の使い方
• OpenTelemetry・Sentryによる既存の計測

移行のたびに監視の設定まで作り直す必要はない。

既存プロジェクトの移行も難しくない。app/やpages/、next.config.jsはそのまま使う。コマンドはnpx vinext check && npx vinext initの2つで済む(同)。

ただし、すべてが揃ったわけではない。Next.js 16が推す新機能「Cache Components」を支える"use cache"ディレクティブへの対応は、今のところ限定的だ(同)。Cloudflareは「話を聞いた多くのチームはCache Componentsを使っておらず、移行の前提条件とは考えていなかった」として、ここより他の互換性を優先したと説明している(同)。"use cache"を使い始めている場合は、移行前にこの制限が当てはまるか確認したほうがいい。

機能の対応範囲が分かったところで、残る疑問は速さだ。対応が広がっても、大規模なサイトのビルド時間が変わらなければ、開発者の待ち時間は減らない。

ビルド時間を配信網側で使う理由

Next.jsには、ページをビルド時にあらかじめレンダリングしておく仕組みがある。これ自体は公開後に速くアクセスできて便利だが、Cloudflareは公式ブログでこう指摘する。「数万から数十万のURLを持つサイトでは、ほとんどアクセスされないページまでレンダリングするのに、深刻なほど長い時間がかかることがある。ビルドの工程は、ほとんどのサイトが実際に抱えているロングテールのアクセス状況を考慮できない」(Cloudflare公式ブログ)。1万件の商品ページがあれば、ビルド時には1万回分のレンダリングが走る。だがそのうち大半は、公開後もほとんど誰も見に来ない。

Vinext 1.0が持つ「cache warming」は、このレンダリングをビルドの工程から追い出す。デプロイのたびに、次の順番で動く(同)。

1. 新しいバージョンのWorkerを、本番環境のトラフィックの0%の状態でまず立ち上げる
2. そのバージョンに対して、実際にページをリクエストしてキャッシュを作らせる
3. キャッシュが十分にできあがったところで、そのバージョンを本番トラフィックへ昇格させる

つまり、ページを前もって作り置きする場所を、手元のビルドマシンから、本番と同じ配信網の中へ移した。ビルドが終わった時点ではなく、実際にユーザーがアクセスする直前の状態で、必要なページのキャッシュだけが整っている。

ここまで分かると、残る疑問は「今日から何を試せるか」になる。

まとめ

Vinext 1.0により、Next.jsアプリはコードを書き換えずに、Viteベースの実装へ乗せ替えるだけでCloudflare Workers・Netlify・AWS Lambdaへデプロイできるようになった。変換ではなく再実装という設計のおかげで、Vite出力がそのままどのプラットフォームでも動く。App RouterとPages Routerの両方で、主要な機能のテスト互換性は99%を超えている。ビルド時に全ページを事前レンダリングする代わりに、デプロイ直後に本番トラフィックの0%の状態でキャッシュを温めてから昇格させる「cache warming」も備わった。

新規ならnpm create vinext-app@latest、既存プロジェクトならnpx vinext check && npx vinext initで試せる。ただしNext.js 16の「Cache Components」("use cache")を使っているプロジェクトは、対応が限定的な現状を踏まえてから移行を判断したほうがいい。