Next.jsの書き方そのままで、ビルド4倍速・バンドル57%減。Vinextの仕組みを全部調べた

Next.js は素晴らしいフレームワークだ。みんな使ってるし、自分も使っている。

ただ、2つだけ「これはもうしょうがないよね」とみんなが諦めている問題がある。Vercel 以外でまともに動かないことと、ビルドが遅いことだ。

2026年2月24日、Cloudflare が Vinext を発表した。Vite 上に Next.js の API をゼロから再実装したフレームワークだ。既存の app/、pages/、next.config.js がそのまま動いて、ビルドは4倍速、バンドルサイズは57%減。

この記事では Vinext が何をやっているのか、なぜ速いのか、そして本当に使えるのかを全部調べた。

なぜ「しょうがない」だったのか

この2つの問題の根っこは同じだ。Next.js のビルドツールが完全に独自ということ。

覚えている人もいると思うが、かつて React の入門といえば create-react-app（CRA）だった。CRA は内部で Webpack を使っていたが、2023年に非推奨になり、React 公式は Vite を推奨するようになった。

その Vite は今やフロントエンドのデファクトスタンダードになりつつある。

フレームワーク	ビルドツール
TanStack Start	Vite
Remix / React Router	Vite
Nuxt（Vue）	Vite
SvelteKit	Vite
Astro	Vite
Next.js	Turbopack（独自）

主要フレームワークがほぼ全て Vite に集まる中、Next.js だけが独自路線を走っている。

Next.js は Webpack の後継として Turbopack を開発中だ。皮肉なことに、Turbopack を作っているのは Webpack の作者本人（Tobias Koppers）で、Vercel が彼を雇っている。Turbopack は確かに速い。だが Vercel のエコシステムに最適化されていて、他のプラットフォームでは使えない。

ビルドが遅いのも、Vercel 以外でまともに動かないのも、この「独自ビルドツール」に縛られていることが原因だ。

これまでも OpenNext というプロジェクトが、Next.js を AWS Lambda や Cloudflare Workers にデプロイできるようにしてきた。だがこれは Next.js のビルド出力をラップする方式で、Next.js の内部実装が変わるたびに追従しなければならない。根本的な解決ではなかった。

Vinext はまったく違うアプローチを取った。ラップするのではなく、Next.js の公開 API を Vite 上にゼロから再実装した。世の中の流れに合流させた、とも言える。

# OpenNext のアプローチ
Next.js でビルド → 出力を変換 → 他のプラットフォームにデプロイ

# Vinext のアプローチ
Next.js の API を Vite で再実装 → 最初から Vite としてビルド

具体的には、33以上のシムモジュールが next/* のインポートをインターセプトする。next/link、next/router、next/navigation、next/server、next/headers—— これらを全部、Vinext 独自の実装に差し替える。

// コードは変わらない
import Link from 'next/link';
import { useRouter } from 'next/navigation';

// ↑ Vite の resolveId フックが next/* をインターセプトして
// Vinext のシム実装にリダイレクトする

既存の app/、pages/、next.config.js がそのまま動く。移行コマンドも用意されている。

npm install vinext
# package.json の scripts を書き換えるだけ
# "dev": "vinext dev"
# "build": "vinext build"

対応している機能（API の94%）

• ファイルシステムルーティング（App Router / Pages Router 両対応）
• SSR、ストリーミング、React Server Components
• Server Actions（"use server"）
• getStaticProps、getServerSideProps、ISR
• Middleware、Rewrites、Redirects
• Metadata API
• "use cache" ディレクティブ
• 環境変数（.env*、NEXT_PUBLIC_*）

対応していないもの

• Vercel 固有機能（Analytics、KV/Blob/Postgres バインディング）
• 画像の最適化（next/image は動くが、ビルド時の最適化は Unpic CDN に委譲）
• フォントのサブセット化（CDN ベースのロードのみ）
• Webpack / Turbopack の設定（代わりに Vite プラグインを使う）

100%の互換性は意図的にゴールにしていない。Cloudflare のエンジニア自身が「動作は完全に同じではない」と明言している。

なぜ速いのか

ベンチマーク結果から見てみよう。テスト条件は33ルートの共通アプリケーション。

ビルド時間

実装	ビルド時間	倍率
Next.js 16.1.6（Turbopack）	7.38秒	ベースライン
Vinext + Vite 7 / Rollup	4.64秒	1.6倍高速
Vinext + Vite 8 / Rolldown	1.67秒	4.4倍高速

クライアントバンドルサイズ（gzip後）

実装	サイズ	削減率
Next.js 16.1.6	168.9 KB	ベースライン
Vinext（Rollup）	74.0 KB	56%削減
Vinext（Rolldown）	72.9 KB	57%削減

※ Cloudflare 公式ブログは「方向性を示すものであり、決定的なものではない」と注記している。

なぜこの差が出るのか

ポイントは Vite のアーキテクチャにある。

開発時（dev server）

Next.js（Webpack ベース）は、開発サーバー起動時にアプリケーション全体をバンドルする。ファイルが増えるほど起動が遅くなる。Turbopack はこれを改善しているが、アーキテクチャの根本は変わらない。

Vite は違う。ESM（ES Modules）をネイティブに活用して、ブラウザが必要とするモジュールだけをオンデマンドで変換する。アプリが100ページあっても、開いたページに必要なモジュールしか処理しない。

# Webpack 系のアプローチ
全ファイル → バンドル → ブラウザ
（起動時に全部処理する）

# Vite のアプローチ
ブラウザがリクエスト → そのファイルだけ変換 → 返す
（必要になるまで何もしない）

本番ビルド時

Vinext は Vite 8 から搭載される Rolldown（Rust 製バンドラー）を活用できる。Rolldown は Rollup の API 互換を保ちながら、Rust のパフォーマンスで動く。これがビルド4.4倍速の主因だ。

バンドルサイズの差

57%の削減は大きい。これは Vite / Rollup のツリーシェイキングが Next.js の内部実装より効率的に不要コードを除去できるためだ。Next.js は内部でフレームワーク固有のランタイムコードを含むが、Vinext は Vite のエコシステムをそのまま使うため、余計なランタイムが少ない。

AI で1週間で作れた理由

800以上のセッションで Claude を使い、ほぼ全てのコードを AI が書いた。コストは$1,100。これが可能だった理由を、開発者の Steve Faulkner（Cloudflare Workers org のディレクター）自身が公式ブログで分析している。

1. テストスイートが「機械読み取り可能な仕様書」になった

Next.js のリポジトリには2,000のユニットテストと400のE2Eテストがある。Vinext チームはこれをそのまま移植して、「テストが通るまで AI に書かせる」アプローチを取った。

Hacker News のコメントで的確に表現されていた。

「AI は人間の意図を理解する必要がなかった。アサーションを通過させる必要があっただけ」

テストがあることで、AI の出力を客観的に検証できる。「なんとなく動いてそう」ではなく「2,400のテストケースが通っている」と言える。これはAI開発との相性が極めていい。

2. Vite という堅牢な基盤

Hacker News で「Vinext の95%は純粋な Vite だ」という指摘があった。AI がゼロからバンドラーを書いたわけではない。Vite のプラグインシステム、HMR、モジュール解決といった基盤の上に、Next.js 固有のロジック（ルーティング、RSC、ISR など）を載せた形だ。

3. モデルの進化

公式ブログでの Faulkner 自身の言葉：

「以前のモデルではこのサイズのコードベースで一貫性を維持できなかっただろう」

AI がフレームワーク全体のアーキテクチャをコンテキストに保持し、モジュール間の相互作用を推論し、十分な頻度で正しいコードを生成できるようになった——というのが彼の見解だ。

テスト駆動 × AI という新パラダイム

この事例が示唆するのは、テストスイートがあれば AI は大規模ソフトウェアを再実装できるということだ。

逆に言えば、テストスイートが公開されているプロジェクトは、同じ手法で再実装されるリスクがある。実際に Hacker News では、SQLite がまさにこのシナリオを防ぐためにテストスイートを非公開にしていることが指摘されていた。

コミュニティの反応

海外のエンジニア向けニュース掲示板 Hacker News では激しい議論が起きている。両方の意見を紹介する。

肯定的な声

「本番アプリを4倍高速にビルドし、クライアントバンドルを57%小さくする。これは無視できない」

「Next.js チームがユーザーの 0.1% のためのファンシーな機能に集中し、残り 99.9% のパフォーマンスを犠牲にしてきた。これはその問題に答える」

TanStack の作者 Tanner Linsley もプロジェクトを公式に支持している。

批判的な声

「基本的な hello world の例が動かないのに、何かを『再実装した』と言えるのか」

「コードベースはほぼ全てAI生成で、人間のレビューが追いついていない」

「Cloudflare がやることはすべて半焼けだ」

実際、GitHub では hello world が動かない Issue が報告されている。出たばかりのプロジェクトであることは間違いない。

「このプロジェクトは本気か？」

GitHub の Issue #21 で直接この質問がされた。Faulkner は「我々は間違いなくこれに投資する」と回答し、既存顧客による本番利用を根拠に挙げた。実際に CIO.gov（米国政府サイト）がベータ版で Vinext を本番稼働させている。

まとめ

	Next.js	Vinext
ビルドツール	Turbopack（独自）	Vite / Rolldown
ビルド速度	7.38秒	1.67秒（4.4倍）
バンドルサイズ	168.9 KB	72.9 KB（57%減）
デプロイ先	Vercel 最適化	Cloudflare Workers（現状）
API カバレッジ	100%	94%
成熟度	安定	実験的

Vinext は「Next.js を殺す」ものではない。Next.js の書き方はそのまま、ビルドとデプロイの自由度を取り戻すプロジェクトだ。

技術的には、Vite のアーキテクチャが Next.js の独自バンドラーより効率的にビルド・バンドルできることを数値で証明した。AI 開発の観点では、テストスイートが「機械読み取り可能な仕様書」として機能するという発見が、今後のソフトウェア開発に大きな示唆を与えている。

ただし、出て1週間のプロジェクトだ。hello world が動かない Issue がある現実を考えると、今すぐ本番に持ち込むものではない。まずは動向を追いつつ、Vite 8 / Rolldown のエコシステムの成熟を見守るのが現実的だろう。

個人的に一番刺さったのは、**「テストがあれば AI はフレームワークを再実装できる」**という事実だ。Next.js を使っている身としては、フレームワーク選択の基準が「エコシステムの囲い込み」から「API の良さ」に移っていく未来を感じた。