2026.10.05 開発

Vinextとは？Next.jsをViteで動かす1.0の使い方とOpenNextとの違い・移行手順

Q: VinextはCloudflare以外にもデプロイできますか？

可能です。ネイティブな展開先はCloudflare Workersですが、 vinext init --platform=node でNode.jsサーバー向けに初期化でき、Vercel、Netlify、AWS Amplify、Deno DeployなどへはNitroのプリセットを指定してビルドします。 cloudflare:workers のバインディングを使ったコードだけはWorkers専用になる点に注意してください。

Q: 移行に失敗したら元のNext.jsに戻せますか？

戻せます。 vinext init は既存の dev や build スクリプトとソースを残したまま、 dev:vinext や build:vinext を追加する非破壊の作りです。評価の結果見送る場合は、追加されたスクリプトと依存パッケージ、Viteの設定ファイルを外せば元の構成に戻ります。ただしWorkers専用のバインディングを書き足したコードは、戻す際に書き換えが要ります。

Vinextとは？Next.jsをViteで動かす1.0の使い方とOpenNextとの違い・移行手順

Vinext（ヴィーネクスト）は、CloudflareがMITライセンスで公開している、Next.jsのAPIをVite上に作り直したフレームワークです。2026年9月28日に1.0.0が出て「実験」の扱いを外れ、10月1日には1.0.1が続きました。既存のNext.jsアプリのapp/やpages/をほぼそのまま使いながら、ビルドはVite 8が受け持ち、Cloudflare WorkersやNode.jsなどVercel以外の基盤へ載せられます。この記事では実装者向けに、Vinextの仕組みとOpenNextとの違い、vinext checkから始める移行手順、Workersへのデプロイ、Next.jsとの差分で詰まりやすい箇所、そして採用の判断基準を、1.0.1時点の公式ドキュメントをもとに整理します。

まとめ｜Vinext 1.0の正体と既存Next.jsアプリを移す判断の要点

Vinextは、Next.jsのビルド結果を変換するのではなく、ルーティングやReact Server Components、Server Actions、ミドルウェアといったNext.jsの「API面」をViteのプラグインとして書き直したものです。1.0の発表では、主要機能のテスト互換性が99%超（Cache Componentsを除く）とされました。移行はvinext checkで非対応箇所を洗い出し、vinext initで既存のNext.jsスクリプトを残したまま並走させる、非破壊の手順が公式の推奨です。

判断を先に言うと、Vercel以外へ載せ替えたいApp RouterやPages Routerのアプリで、'use cache'やPartial Prerenderingに依存していなければ採用候補になります。逆に、Cache Componentsを前提に設計したアプリや、Next.jsとの挙動差を検証する工数を割けない本番サービスは、現時点では見送るのが妥当です。

Vinextとは｜Next.jsのAPIをVite 8上に再実装した構造と経緯

Vinextの中身は、Viteのプラグイン群です。next devやnext buildの代わりにvite devとvite buildを使い、next/linkやnext/headersといったimportはVinext側の実装に解決されます。Vite 8でRolldownへ移った経緯はViteとは？Reactの環境構築手順とVite 8の変更点で整理しています。

1.0で何が変わったか｜2026年2月の実験版から9月28日の1.0.0まで

Vinextの初出は2026年2月24日のCloudflareブログHow we rebuilt Next.js with AI in one weekで、1人のエンジニアがAIモデルと約1週間で作り、Claudeのトークン代は約1,100ドルだったと公表されています。当時は「実験的」と明記され、本番トラフィックでの検証不足も認めていました。

7か月後のVinext 1.0の発表記事では、ビルド時プリレンダリング、静的エクスポート、ページ単位のISRまでページのライフサイクル全体を扱えるようになり、Cloudflareのネットワーク上でプリレンダリングを済ませる「キャッシュウォーミング」が加わりました。保守体制も変わっています。毎朝エージェントがNext.js本体の変更を確認して追跡Issueを起こし、毎晩Next.jsのテストスイートを回して互換性表を作り直す仕組みです。版の推移はGitHubのReleasesで追えます。

OpenNextとの違い｜ビルド出力の変換か、API面の再実装か

Next.jsをVercel以外で動かす手段として、先行していたのがOpenNextのCloudflareアダプタ（@opennextjs/cloudflare）です。こちらは本物のNext.jsでビルドし、その出力をWorkersで動く形へ変換します。Cloudflareは初出記事で、出力の変換はNext.jsの版が上がるたびに想定外の差分が出て保守が重くなると説明し、Vinextを別の解として位置づけました。

観点	Vinext	OpenNext（Cloudflare）
方式	API面をViteで再実装	Next.jsのビルド出力を変換
ビルドツール	Vite 8	Next.js本体（Turbopack等）
Next.jsとの一致度	テスト互換99%超	本体ビルドのため高い
Cache Components	限定的	PPRを含め対応と記載
主な展開先	Workers、Nitro経由で他基盤	Cloudflare Workers

実務上の違いは「本物のNext.jsを動かすか」に尽きます。

動作要件の確認とvinext checkによる既存Next.jsアプリの互換性診断

前提を外れたままvinext initを走らせると、依存解決で止まります。

Node.js 22以上・Vite 8・React 19.2.6という前提条件の確認

npm registryに登録されたvinext 1.0.1のメタデータを確認すると、enginesはnode >=22、peer依存はvite ^8.0.0、reactとreact-domが^19.2.6です。GitHubのREADMEも同じくReact 19.2.6以上とVite 8.0.0以上を要件に挙げています。手元の状態は次のコマンドで確かめられます。

node -v                      # v22以上か
npm view vinext engines peerDependencies
npm ls react react-dom next  # 既存アプリの版を確認

Reactが19.2.6より古いなら、先にReactの更新を済ませます。

vinext checkで非対応の設定とimportを洗い出す手順

公式の移行ガイドは、最初にvinext checkを走らせるよう求めています。既知の非対応設定、import、プロジェクト構成のパターンを報告するコマンドです。

pnpm dlx vinext check
# npmの場合
npx vinext check

報告で特に見るべきは、next.config.jsのwebpack関数やTurbopack設定、@vercel/ogの利用です。READMEはこれらを非対応に分類しています。checkの結果に加えて、機能ごとの対応状況を毎晩更新する互換性ダッシュボードも確認し、自分のアプリが使う機能が赤や黄になっていないかを見てから次へ進みます。

vinext initで既存アプリを非破壊のまま並走させる移行手順

Vinextの移行は、既存のdevやbuildスクリプトとソースを残し、*:vinext系のスクリプトを横に足して比べる作りです。評価だけして見送る判断も取りやすくなります。

init –platformでCloudflareかNodeかを選ぶ初期化コマンド

vinext initは必要なパッケージを入れ、ESMとViteの設定を足し、選んだ展開先向けのデプロイ設定を作ります。対話で選ぶこともできますが、CIや手順書に残すなら--platformを明示する書き方が再現性に優れます。

pnpm dlx vinext init --platform=cloudflare
# Node.jsサーバーで動かす場合
pnpm dlx vinext init --platform=node

新規アプリの雛形は別コマンドのpnpm create vinext-app@latest my-appで作ります。

vite.config.tsの最小構成とCSS Modulesを手で直す場面

initが生成する設定の中心は、Viteのプラグイン配列にvinext()を足すだけの短いファイルです。手動で組む場合も、READMEの最小構成は次の形になります。

import { defineConfig } from "vite";
import vinext from "vinext";

export default defineConfig({
  plugins: [vinext()],
});

手で直す必要が出やすいのはCSS Modulesです。既存のvite.configが関数で動的に組まれているなど、initが自動で書き換えられない場合、移行ガイドはvite-css-modulesのpatchCssModules({ exportMode: "default" })をvinext()より前に置き、クラス名の生成規則をcss.modules.generateScopedNameで指定する設定を示しています。プラグインの順序を逆にするとスタイルが当たらないため、順番は崩さないようにします。

dev:vinextとdevを並べて認証・ミドルウェアの挙動を突き合わせる

init後は、同じソースを2つのツールチェーンで起動して比べます。

pnpm dev:vinext     # Vinext(Vite)で起動
pnpm build:vinext   # Vinextで本番ビルド
pnpm dev            # 従来のNext.jsで起動

移行ガイドが比較対象に挙げているのは、認証、ミドルウェア、データ更新（ミューテーション）、キャッシュ、デプロイ先のバインディングです。見るべきは画面の表示可否ではなく、ログイン後のリダイレクトやServer Actions実行後の再描画が両者で一致するかです。

Cloudflare Workersへのデプロイとバインディング・キャッシュの扱い

Vinextのネイティブな展開先はCloudflare Workersです。Vercel、Netlify、AWS Amplify、Deno Deploy、Node.jsサーバーなど他の基盤へは、Nitroのプリセット（例：NITRO_PRESET=vercel npx vite build）経由で出力します。Workersそのものの料金や無料枠はCloudflare Workersとは？対応言語・無料枠・使い方・料金で確認できます。

@vinext/cloudflare deployと–envでステージングを分ける手順

Cloudflare向けのデプロイ手順では、認証してからデプロイ用パッケージを実行します。環境を分けるときは--envを付けます。

pnpm exec cf auth login
pnpm dlx @vinext/cloudflare deploy
pnpm dlx @vinext/cloudflare deploy --env staging

アカウントIDは環境変数CLOUDFLARE_ACCOUNT_IDか、initが作るcloudflare.config.tsのaccountIdで指定します。CIから流す場合はCLOUDFLARE_API_TOKENを使い、個人の対話ログインに頼らない構成にしておきます。

Server ComponentからD1などのバインディングを直接読む書き方

Workersで動かす利点の1つが、D1やKV、R2といったバインディングをServer Componentから直接読める点です。公式ドキュメントの例を簡略化すると次の形になります。

import { env } from "cloudflare:workers";

export default async function Page() {
  const posts = await env.DB.prepare("SELECT id, title FROM posts").all();
  return <ul>{posts.results.map((p) => <li key={p.id}>{p.title}</li>)}</ul>;
}

DBへの中継APIを省ける反面、cloudflare:workersをimportしたコードはWorkers専用になります。Node.jsへ戻す可能性がある部分は、リポジトリ層に閉じ込めておくと安全です。

ISRとキャッシュウォーミング｜–warm-cacheでデプロイ前に温める

1.0で加わったキャッシュウォーミングは、プリレンダリングをビルド機からCloudflareのネットワーク側へ移す機能です。デプロイ前にバックグラウンドでページを生成し、本番へ切り替えた時点でキャッシュが埋まっている状態を作ります。

npx @vinext/cloudflare deploy --warm-cache

1.0.0のリリースノートでは、App Routerのページをキャッシュするのは Next.js が静的またはSSGと判定する場合に限り、既定をrevalidate = falseとする変更も入りました。キャッシュの保存先はKV、メモリ、Workers Response Storeから選べます。

Next.jsとの差分で移行が詰まりやすい箇所と1.0.1時点の非対応機能

互換性が99%超でも、残りの差分が自分のアプリの中心にあれば移行は止まります。公式の差分ページとREADMEから、影響が大きい順に並べます。

use cacheとPartial Prerenderingが未完成という最大の制約

最も重い差分は、Cache Components（'use cache'ディレクティブ）とPartial Prerenderingが「部分対応」にとどまる点です。Next.js 16系はこの2つを中心にキャッシュ設計を組み立てる方向へ進んでおり、16.3ではInstant NavigationsもcacheComponentsを前提にしています。その流れはNext.js 16.3とは？Turbopack永続キャッシュとInstant Navigationsなど新機能で解説しました。

もう1つ、静的生成の判定も違います。Vinextは動的レンダリングかどうかをリクエスト時に決めるため、動的セグメントの末尾にgenerateStaticParamsを置かない限り、ページはリクエストごとにレンダリングされます。Next.jsでは静的に配られていたページが、移行後にサーバー描画へ変わっていないかを確かめてください。

next/imageとnext/fontの処理がビルド時でなく実行時になる差

next/imageは、リモート画像を@unpic/react経由で、ローカル画像を<img>とsrcSetで扱います。Workers上ではリクエスト時のCloudflare画像変換に対応する一方、ビルド時の変換パイプラインは未完成です。next/font/googleとnext/font/localも、ビルド時に埋め込むのではなく実行時にCDNから読み込みます。表示速度の指標を厳しく追っているサイトでは、移行前後でLCPやCLSを測り直す必要があります。

runtimeとpreferredRegionが効かずデプロイ先で決まる仕様

Next.jsのルート設定であるruntimeやpreferredRegionは、Vinextでは実行場所を決めません。実行場所を決めるのは、選んだデプロイアダプタ（WorkersかNitroのプリセット）です。ルートごとにEdgeとNode.jsを使い分けていたアプリは、その前提が崩れます。また、App Routerの開発時にはsharpやresvg、satoriといったネイティブモジュールが失敗する場合があるとREADMEに記載されています。OG画像生成をこれらで組んでいるなら、移行検証の最初に潰す項目です。

Vinextを採用する条件と見送るべき場面｜受託開発の判断基準

Vinextは「Next.jsの上位互換」ではなく、「Next.jsのAPIでVercel以外を選ぶための選択肢」です。この前提で条件を切ります。

Vercel以外へ載せ替えたい中規模App Routerアプリなら採用候補

採用候補になるのは、次の条件がそろう場合です。vinext checkで致命的な指摘が出ない。'use cache'とPartial Prerenderingを使っていない。ホスティング費用やリージョン要件でVercelから離れたい理由がある。Vercelの料金構造はVercel料金｜Hobby無料枠とPro($20)の中身・超過単価で整理しています。初出記事の33ルートのApp Routerアプリでの計測では、Next.js 16.1.6のビルド7.38秒に対しVite 8（Rolldown）版は1.67秒、クライアントバンドルはgzip後168.9KBから72.9KBでした。2月時点の数字なので、自分のアプリで測り直す前提で扱ってください。

Cache Components依存とFreeプランCPU10ミリ秒は見送り

見送るべき場面ははっきりしています。第一に、Cache Componentsを前提に設計したアプリです。Vinextで最も未完成な領域であり、移行するとキャッシュ設計を組み直すことになります。第二に、Cloudflare WorkersのFreeプランで本番を回す計画です。Workersの制限ページでは、FreeプランのCPU時間はHTTPリクエストあたり10ミリ秒で、サーバーサイドレンダリングは一般に10〜20ミリ秒を使うとされています。SSR主体のアプリならPaidプラン（既定30秒）を前提に見積もるべきです。

第三に、Next.jsとの挙動差を検証する工数を割けない案件です。互換性99%超は「残り1%が自分の業務フローに当たらない」ことを保証しません。既存のNext.jsアプリを別基盤へ移すなら、並走期間の検証項目と切り戻し手順まで含めて計画するのが筋です。現行システムの移行計画づくりから相談したい場合は、一創のシステムマイグレーション・リプレイスで、互換性の診断から段階移行の設計まで対応します。

Vinextの使い方とNext.jsからの移行に関するよくある質問

Vinextを検討する実装者から出やすい疑問に、1.0.1時点の公式情報で答えます。

VinextはNext.jsのフォークですか？

フォークではありません。Next.jsのソースを分岐させたものではなく、Next.jsのAPI（ルーティング、React Server Components、Server Actions、ミドルウェア、next/linkなどのimport）をViteのプラグインとして別に実装したものです。そのため既存のapp/やpages/、next.config.jsを読める一方、Next.js本体のwebpackやTurbopackの設定は引き継がれません。

VinextはCloudflare以外にもデプロイできますか？

可能です。ネイティブな展開先はCloudflare Workersですが、vinext init --platform=nodeでNode.jsサーバー向けに初期化でき、Vercel、Netlify、AWS Amplify、Deno DeployなどへはNitroのプリセットを指定してビルドします。cloudflare:workersのバインディングを使ったコードだけはWorkers専用になる点に注意してください。

VinextとOpenNextはどちらを選ぶべきですか？

Next.jsとの挙動の一致を最優先するならOpenNextです。本物のNext.jsでビルドした出力を変換するため、Partial Prerenderingも本体どおりに扱えます。ビルド速度やViteのプラグイン資産を取りたい場合はVinextが候補です。'use cache'への依存の有無が分かれ目になります。

移行に失敗したら元のNext.jsに戻せますか？

戻せます。vinext initは既存のdevやbuildスクリプトとソースを残したまま、dev:vinextやbuild:vinextを追加する非破壊の作りです。評価の結果見送る場合は、追加されたスクリプトと依存パッケージ、Viteの設定ファイルを外せば元の構成に戻ります。ただしWorkers専用のバインディングを書き足したコードは、戻す際に書き換えが要ります。

Vinextを本番で使っても大丈夫ですか？

1.0で実験の扱いは外れ、Cloudflareは高トラフィックの本番でも使えると説明しています。ただしREADMEは「すべての本番ワークロードの完全互換は保証しない」とし、採用前のvinext checkを推奨しています。本番投入は、互換性ダッシュボードで使用機能を確認し、主要な業務フローを並走比較してからにするのが安全です。