制作会社に作ってもらったNext.jsのコーポレートサイトやWebアプリがVercelで動いている。ほかのサイトやDNSはCloudflareにまとめているので、ホスティングもそちらへ寄せられないか。そう考えたときの候補に、Cloudflareが開発する「vinext」が加わりました。npmの記録では、1.0.0が2026年9月28日、1.0.1が10月1日に公開されています。
一方で、vinextのREADMEは冒頭で「まだすべてのアプリケーションや本番ワークロードの置き換えにはならない」と書き、より成熟した選択肢としてOpenNextを挙げています。1.0という番号だけで乗り換えを決めず、READMEと変更履歴、Next.js 16の検証用アプリで動かした結果から、判断の材料を整理します。
vinextは「Next.jsのAPIをViteで作り直したもの」
READMEによると、vinextは next build の出力を使わず、Next.jsのAPI（ルーティング、サーバーレンダリング、next/* のモジュールなど）をビルドツールのVite上で実装し直したものです。App RouterとPages Router、React Server Components、Server Actions、ミドルウェア、ルートハンドラー、ISR、静的書き出しに対応するとしています。対象はNext.js 16.xで、古い版で非推奨になったAPIは扱いません。
主な配置先はCloudflare Workersで、それ以外（Vercel、Netlify、AWS Amplify、Deno Deploy、Node.jsサーバーなど）にはNitroというViteプラグインを足して配置します。Next.jsのフォークではありません。
npmの公開記録では、2026年7月4日のbeta.0から14のベータ版を経て1.0.0になりました。1.0.0の変更履歴には、Next.jsが静的と扱うページだけをキャッシュする、vinext check が無視・反映する next.config の項目を報告する、Cloudflare向けの初期設定を新しいCLI「cf」に切り替える、といった変更が並びます。
READMEが挙げる「まだ足りない部分」
READMEの「Known gaps」には、取り組み中の項目として次が書かれています。
- Cache ComponentsとPartial Prerendering：
"use cache"は部分的な実装で、cacheComponentsの挙動はNext.jsと一致しない場合がある - ビルド時の画像・フォント最適化：Cloudflareではリクエスト時に画像を最適化できるが、Next.jsのビルド時の画像処理は再現していない
- App Routerの開発時のネイティブモジュール：
sharp・resvg・satoriなどが開発サーバーで失敗することがある - 配置先に関わる設定：
preferredRegionは無視され、runtimeは実行場所を選ばない
これとは別に、Vercel固有の機能（edge runtimeの @vercel/og、Vercel Analytics、Vercel KV/Blob/Postgres）は今後も対応しないと明記されています。本番利用については「Can I use this in production?」に「You can, with caution.」（使えるが慎重に）と答えています。
Vercel外へ出す4つの道
選択肢の説明は、vinextのREADMEの記述によります。OpenNextとNext.jsの公式ドキュメントは本記事では開いていないため、それぞれの詳細は各公式資料で確かめてください。
| 選択肢 | 仕組み | vinextのREADMEでの位置づけ |
|---|---|---|
| Vercelを続ける | 現状のまま | 記述なし（本記事では比較の基準として置く） |
| Next.jsのセルフホスト | Node.jsサーバー、Docker、静的書き出し | 「Next.jsのまま別の場所で動かしたいなら最も簡単」 |
| OpenNext | next build の出力を各基盤向けに変換 | 「より成熟し、より多くのAPIを扱う」「安全で実績のある選択肢」 |
| vinext | Next.jsのAPIをVite上で再実装 | ビルドが速く成果物が小さい一方、Next.jsの機能の端までは扱わない |
編集部の整理では、vinextを選ぶ意味があるのは、Viteのツール群へ寄せたい、Cloudflare Workersのバインディングを直接使いたいなど、ツールチェーンそのものを変える理由がある場合です。Viteを土台にした開発環境の動きはVite+の記事でも整理しました。
Next.js 16の検証用アプリで動かした
2026年10月2日、編集部の検証環境（Linux、Node v22.22.0、npm 10.9.4）で、create-next-app が作るApp Routerのひな形（Next.js 16.3.8、next/image と next/font/google を使用）に、JSONを返すルートハンドラーを1つ足して試しました。vinextは1.0.1です。
checkは何も書き換えない
npx vinext@1.0.1 check は約13秒で終わり、ファイルの変更はありませんでした（gitの差分なし）。結果は「100% compatible (6 supported, 0 partial, 0 issues)」です。
そこで、READMEが足りない部分に挙げる2つを足して再実行しました。next.config.ts に cacheComponents: true、新しいページに preferredRegion = "hnd1" と "use cache" です。結果は「94% compatible」に下がり、cacheComponents — experimental support; behavior is incomplete が表示されました。一方、preferredRegion については何も表示されませんでした。checkの合格は、READMEのKnown gapsを読む代わりにはなりません。
initはReactの版で止まった
続く vinext init --platform=node は、依存関係の追加で止まりました。npmのエラーは ERESOLVE could not resolve で、追加しようとした react-server-dom-webpack@19.3.0 がReact 19.3.0以上を求める一方、ひな形のReactは19.2.8でした。止まった時点で、package.json へのスクリプトと "type": "module" の追加、vite.config.ts の作成、.gitignore の追記はすでに済んでいました。途中で止まっても変更は残るため、gitのブランチ上で試します。
ReactとReact DOMを19.3.0へ上げてやり直すと、initは完了しました。
READMEの説明どおり、next.config.ts・tsconfig.json・app/ 配下は変わらず、npm run dev などの既存のNext.jsのスクリプトもそのまま残りました。追加されたのは dev:vinext・build:vinext・start:vinext の3つです。CSS Modulesを検出して vite-css-modules も入りました。
ビルドと起動
npm run build:vinext（Vite 8.3.2）は完了し、npm run start:vinext で起動したサーバーは、ページとルートハンドラーにどちらもHTTP 200を返しました。ただし、ビルドの最後のルート一覧では / が「? Unknown」と表示され、「headers()やcookies()などの動的APIの使用はビルド時に検出できない」という注記が出ました。同じアプリを next build すると / は「○ (Static)」です。READMEのベンチマークの節も、Next.jsはビルド時にページを静的に作り、vinextは既定でリクエストごとにサーバーで描画すると説明しています。
Cloudflare向けはキャッシュの方式を先に決める
--platform=cloudflare を付けたinitは、キャッシュと画像最適化の選択を求めて止まりました。CDNキャッシュ（response-store、workers-cache、static-assets、data-cache）、データキャッシュ（kvかなし）、画像最適化（cloudflare-imagesかなし）を指定してから再実行するよう表示されます。static-assets・データキャッシュなし・画像最適化なしで再実行すると、cloudflare.config.ts が作られ、/ はビルド時に事前描画されて「○ Static」になりました。ローカルのプレビューでもページとルートハンドラーは200を返しました。
追加された依存には、cf@1.0.0-beta.10 と @cloudflare/vite-plugin の2.0.0のベータ版が含まれていました。vinext本体は1.0でも、Cloudflareへの配置に使う道具はベータ段階です。cfの扱いはCloudflareのcfベータとWranglerの記事にまとめています。Cloudflareへの実際のデプロイは試していません。
乗り換えを決める前に確かめること（編集部の提案）
- Next.jsの版：vinextの対象は16.xです。15以前のサイトは、まずNext.js側の更新が必要かを確かめます
- 使っている機能とKnown gapsの照合：
"use cache"、next/imageのビルド時最適化、sharpやsatoriを使ったOG画像の生成、Vercel固有のサービスを使っていないか。OG画像の生成はNext.jsの9月の脆弱性の記事でも触れた箇所です - ブランチで
vinext checkとvinext initを通す：差分をgitで見て、何が増えたかを制作会社と共有します - ページが静的か動的か：ビルドのルート一覧で、静的に配りたいページが「Static」になっているかを見ます。Cloudflare向けではキャッシュの方式の選択がこれを左右します
- 保守の担い手：vinextはNext.jsとは別の実装です。不具合が出たとき、制作会社が調査と回避まで受けられるかを確認します
どれを選ぶか
ここまでの資料と検証をもとにした、編集部の整理です。
| 状況 | 編集部の提案 |
|---|---|
| Vercelの費用や運用に大きな不満がない | 続ける。Vercel外へ出ること自体を目的にしない |
| Next.jsのまま自社管理のサーバーで動かしたい | Next.jsのセルフホストを先に検討する |
| Cloudflareへ寄せたい。機能を落としたくない | OpenNextを先に検討する |
| Cloudflare Workersの機能やViteを積極的に使いたい。Next.js 16で、Known gapsに当たらない | ブランチでvinextを試し、静的ページの扱いと依存の版を確認してから判断する |
落とし穴
- checkの「100%」を合格証として扱う。
preferredRegionのように、READMEで無視すると書かれている設定でも表示されませんでした - 静的だったページが、配置後に毎回サーバー描画になる。 表示速度や実行回数に関わります
- 1.0を「Next.jsと同じ挙動」と読む。 READMEは、Next.jsの文書にない挙動までは再現しないとしています
2026年10月2日に、cloudflare/vinextのREADMEとpackages/vinextのCHANGELOG（mainブランチ）、npmレジストリのvinextの公開記録を直接開いて確認しました。check・init・build・起動は、編集部の検証環境（Linux、Node v22.22.0、npm 10.9.4）で、create-next-appのひな形（Next.js 16.3.8）にルートハンドラーを1つ足した検証用アプリに対して1回ずつ実行した結果です。実際の業務サイトの移行、Cloudflareへのデプロイ、OpenNextとNext.jsのセルフホストの動作、表示速度や費用の比較は確認していません。
Next.jsで作ったサイトのホスティングの見直しや、リニューアルに合わせた構成の検討は、グリームハブへご相談ください。
