このコンテンツは自動機械翻訳サービスによる翻訳版であり、皆さまの便宜のために提供しています。原本の英語版と異なる誤り、省略、解釈の微妙な違いが含まれる場合があります。ご不明な点がある場合は、英語版原本をご確認ください。
*この投稿は、ビルド時間ベンチマークの誤字を修正するために、午後 12:35（太平洋時間）に更新されました。
先週、あるエンジニアとAIモデルは、最も人気のあるフロントエンドフレームワークをゼロから再構築しました。その結果、vinext（「ヴィーネクスト」と発音します）は、Next.jsのドロップイン代替品であり、単一コマンドでCloudflare Workersにデプロイできる、Vite上に構築されたプラットフォームです。初期のベンチマークでは、本番アプリを最大4倍速く構築し、最大57%縮小したクライアントバンドルを生成しています。すでに本番環境で実行しているお客様もいます。
トークンの費用はおよそ1100ドルです。
Next.jsは、最も人気のあるReactフレームワークです。数百万人の開発者が利用しています。プロダクションWebの巨大な部分を支えているのには、もっともな理由があります。開発者体験は最高のものです。
しかし、Next.jsをより広範なサーバーレスエコシステムで使用すると、展開上の問題があります。ツールは完全にオーダーメイドです。Next.jsはTurbopackに多額の投資をしていますが、Cloudflare、Netlify、またはAWS Lambdaにデプロイしたい場合は、そのビルドのアウトプットを取り、ターゲットのプラットフォームが実際に実行できるものに再形成する必要があります。
「OpenNextがやっているのではないか？」という意見をお持ちなら、あなたは正しいです。
それこそがまさに、OpenNextが解決するために作られた問題です。OpenNextには、Cloudflareを含む複数のプロバイダーから、大量のエンジニアリングの労力が注がれています。動作はするものの、すぐに制限に遭遇し、もぐらたたきゲームのようになります。
Next.jsのアウトプットを基盤として構築するのは、困難で脆弱なアプローチであることが証明されています。OpenNextはNext.jsのビルド出力をリバースエンジニアリングする必要があるため、その結果、バージョン間で予測不可能な変更が発生し、修正に多くの作業が必要になります。
Next.jsは、ファーストクラスのアダプターAPIに取り組んでおり、当社は彼らと協力してきました。まだ初期段階ですが、アダプターを使用しても、オーダーメイドのTurbopackツールチェーン上で構築することができます。また、アダプターは構築と展開のみをカバーしています。開発中、次の開発者はNode.jsのみで実行されます。別のランタイムをプラグインする方法はありません。アプリがDurable Objects、KV、AIバインディングなどのプラットフォーム固有のAPIsを使用している場合、回避策を講じずに開発環境でそのコードをテストすることはできません。
もしNext.jsの出力を適応させるのではなく、Next.js APIサーフェスをVite上で直接再実装したらどうでしょうか。Viteは、Next.js以外のフロントエンドエコシステムの大部分で使用されているビルドツールで、Astro、SvelteKit、Nuxt、Remixなどのフレームワークを動作させます。単なるラッパーやアダプターではなく、クリーンな再実装です。正直、効果があると思っていませんでした。しかし、2026年、ソフトウェア構築のコストは完全に変化しました。
当初の予想をはるかに超えるものになりました。
npm install vinext
スクリプトでnextをvinextに置き換えれば、他はすべて同じです。既存のapp/、pages/、およびnext.config.jsは、そのまま機能します。
vinext dev # Development server with HMR
vinext build # Production build
vinext deploy # Build and deploy to Cloudflare Workers
これはNext.jsとTurbopackの出力のラッパーではありません。これは、ルーティング、サーバーレンダリング、React Server Components、サーバーアクション、キャッシング、ミドルウェアなど、APIサーフェスの代替実装です。そのすべてがVite上にプラグインとして構築されています。最も重要なのは、Vite Environment APIのおかげで、Vite出力があらゆるプラットフォームで実行されることです。
初期のベンチマークは有望な数字でした。共有33ルートのApp Routerアプリケーションを使って、vinextとNext.js 16を比較しました。
どちらのフレームワークも、サーバーレンダリングされたルートのコンパイル、バンドル、準備という同じ作業を行っています。Next.jsのビルドでは、TypeScriptのタイプチェックとESLintを無効にし（Viteはビルド時にこれらを実行しません）、force-dynamicを使用することで、Next.jsが静的ルーティングのプリレンダリングに余分な時間を費やさず、不当に遅くなる可能性があります。数字を見ることになります。目的は、バンドルとコンパイル速度のみを測定することであり、それ以外には何も測定しませんでした。ベンチマークは、mainへのマージのたびにGitHub CIで実行されます。
本番環境のビルド時間：
| フレームワーク |
平均 |
vs. Next.js |
| 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圧縮）：
| フレームワーク |
Gzip圧縮 |
vs. Next.js |
| Next.js 16.1.6 |
168.9KB |
ベースライン |
| vinext（ロールアップ） |
74.0KB |
56%縮小 |
| vinext（ロールダウン） |
72.9 KB |
57%縮小 |
これらのベンチマークは、コンパイルとバンドルの速度を測定するもので、本番環境のパフォーマンスではありません。テストフィクスは、単一の33ルートアプリであり、すべての本番アプリケーションの代表的サンプルではありません。これらの数値は、3つのプロジェクトが継続するにつれて進化することが予定されています。すべての方法論と過去の結果が公開されています。決定的なものではなく、方向性として捉えてください。
それでも、この方向性は力強いものです。Viteのアーキテクチャ、特にRolldown（Vite 8で登場するRustベースのバンドラー）には、ビルドパフォーマンスの構造的な利点があり、それが明確に表れています。
vinextは、Cloudflare Workersを最初のデプロイメントターゲットとして構築されています。単一のコマンドで、ソースコードから実行中のWorkerへアクセスできます。
vinext deploy
アプリケーションの構築、Worker設定の自動生成、デプロイなど、すべてを行うことができるのです。App ルーターとPages ルーターは両方ともWorkersで動作し、完全なクライアントサイドのハイドレーション、インタラクティブコンポーネント、クライアントサイドナビゲーション、Reactステートを備えています。
本番環境のキャッシングのために、VinextにはCloudflare KVキャッシュハンドラーが含まれており、すぐにISR（Incremental Static Regeneration）を提供します。
import { KVCacheHandler } from "vinext/cloudflare";
import { setCacheHandler } from "next/cache";
setCacheHandler(new KVCacheHandler(env.MY_KV_NAMESPACE));
KVは、ほとんどのアプリケーションにとって良いデフォルトですが、キャッシュレイヤーはプラグ可能なように設計されています。このsetCacheHandlerの呼び出しは、意味のあるバックエンドであればスワップできることを意味します。R2は、大きなキャッシュペイロードを持つアプリや、異なるアクセスパターンを持つアプリに適しているかもしれません。また、より少ない設定で強力なキャッシングレイヤーを提供できるように、Cache APIの改善にも取り組んでいます。目指すべきは柔軟性であり、アプリに合ったキャッシング戦略を選択できるのです。
現在実行中のライブ例：
また、Next.jsアプリでCloudflare Agentsが実行されているライブ例もあります。開発フェーズとデプロイフェーズの両方でアプリ全体がworkerdで実行されるため、getPlatformProxyのような回避策は必要ありません。つまり、Durable Objects、AIバインディング、その他のCloudflare固有のサービスを妥協することなく使用できるということです。こちらをご覧ください。
現在のデプロイ対象はCloudflare Workersですが、これは全体像のごく一部に過ぎません。vinextの95%のように、純粋なViteです。ルーティング、モジュールシム、SSRパイプライン、RSC統合：いずれもCloudflare固有のものではありません。
Cloudflareは、他のホスティングプロバイダーのお客様のために、このツールチェーンの採用を検討しています（導入の負担は最小限です。当社はVercelで30分以内に概念実証を動作させることができました！）。これはオープンソースプロジェクトであり、長期的な成功のためには、エコシステム全体のパートナーと協力して継続的な投資を確実にすることが重要だと考えています。他のプラットフォームからのPRも歓迎します。デプロイメントターゲットの追加にご興味のある方は、問題を報告するか、ご連絡ください。
明確にしたいのは、vinextは実験的なものです。これはまだ1週間前であり、有意義な大規模トラフィックによる実地テストもまだ行われていません。本番アプリケーションとして評価する場合は、慎重に進めてください。
とはいえ、テストスイートは広範なものです。1,700以上のVitestテストと380 Playwright E2Eテストがあり、Next.jsテストスイートやOpenNextのCloudflare準拠スイートから直接移植されたテストも含まれています。当社では、Next.js App Router Playgroundに照らして検証しました。カバレッジはNext.js 16 API攻撃対象領域の94%に対応しています。
実際の顧客からの初期の結果は、心強いものでした。当社は、あらゆる政府のインターフェースを最新化することを目指すNational Design Studioと、彼らのベータサイトの1つであるCIO.govで協力してきました。すでに本番環境で実行されており、ビルド時間とバンドルサイズの大幅な改善が見られます。
READMEには、サポートされないもの、今後もサポートされないもの、および既知の制限について正直に記載されています。私たちは、過剰な約束ではなく、先手を打つことを目指しています。
vinextは、すぐに増分静的再生（ISR）をサポートしています。ページへの最初のリクエストの後、Next.jsと同様にバックグラウンドでキャッシュされ、再検証されます。その実装は現在も有効です。
vinextは、ビルド時の静的プリレンダリングをまだサポートしていません。Next.jsでは、動的データのないページは次のビルド時にレンダリングされ、静的HTMLとして提供されます。動的ルートがある場合は、generateStaticParams() を使用して、どのページを事前に構築するかを列挙します。vinextは、まだありません。
これはローンチに向けた意図的な設計上の決定でした。ロードマップには組み込まれていますが、貴社のサイトが静的コンテンツを含む100%ビルド済みのHTMLの場合、現在vinextのメリットはあまり見られないでしょう。とはいえ、あるエンジニアがトークンに$1,100を費やしてNext.jsを再構築できるのであれば、おそらく10ドルを費やして、Astro（Cloudflare Workersにもデプロイされます）のような静的コンテンツ専用に設計されたViteベースのフレームワークに移行できます。
ですが、純粋に静的ではないサイトの場合は、ビルド時にすべてをプリレンダリングするよりももっと良い方法があると考えています。
Next.jsは、ビルド中にgenerateStaticParams()で一覧化されたすべてのページをプリレンダリングします。10,000の製品ページがあるサイトは、構築時に10,000のレンダリングが行われることを意味しますが、そのうちの99%はリクエストを受信しない可能性もあります。ビルドは、ページ数に応じて直線的に拡張します。これが、大規模なNext.jsサイトのビルドが30分で終わる理由です。
そこで当社は、トラフィックを意識したプリレンダリング（TPR）を開発しました。現在は実験的なものですが、もっと現実的なテストが実施されたら、デフォルトにする予定です。
答えはシンプルです。Cloudflareはすでにサイトのリバースプロキシになっています。トラフィックデータがありますどのページが実際にアクセスされるのかも把握できます。そのため、すべてをプリレンダリングしたり、何もプリレンダリングしたりするのではなく、vinextはCloudflareのデプロイ時にCloudflareのゾーン分析を照会し、重要なページだけをプリレンダリングします。
vinext deploy --experimental-tpr
Building...
Build complete (4.2s)
TPR (experimental): Analyzing traffic for my-store.com (last 24h)
TPR: 12,847 unique paths — 184 pages cover 90% of traffic
TPR: Pre-rendering 184 pages...
TPR: Pre-rendered 184 pages in 8.3s → KV cache
Deploying to Cloudflare Workers...
10万ページのあるサイトでは、電力法はトラフィックの90％が通常50～200ページに向けられることを意味します。これらは数秒でプリレンダリングされます。それ以外はすべてオンデマンドSSRに戻り、最初のリクエスト後にISR経由でキャッシュされます。新たにデプロイするたびに、現在のトラフィックパターンに基づいてセットが更新されます。拡散したページは自動的に取り上げられます。これはすべて、generateStaticParams() なしで、ビルドを本番データベースに結びつけることなく動作します。
このようなプロジェクトには、通常、エンジニアチームが数年とは言わないまでも、数ヶ月が必要です。さまざまな企業の複数のチームが試みており、その範囲は膨大です。過去にCloudflareで試してみました！ 2台のルーター、33個以上のモジュールシム、サーバーレンダリングパイプライン、RSCストリーミング、ファイルシステムルーティング、ミドルウェア、キャッシング、静的エクスポート。これには、理由があります。
今回は1週間以内で完了しました。1人のエンジニア（技術エンジニアリングマネージャー）がAIを直接運用するために、
最初のコミットは2月13日に到達しました。その同日の夕方までに、Pagesルーターとアプリルーターの両方が、ミドルウェア、サーバーアクション、ストリーミングとともに、基本的なSSRが動作するようになりました。次の午後までに、App Router Playgroundは11のルートのうち10をレンダリングしています。3日目までに、vinext deployは完全なクライアントハイドレーションとともにCloudflare Workersにアプリを出荷しました。この週の残りの期間は強化に向けられました。エッジケースの修正、テストスイートの拡大、APIカバレッジの94%拡大などでした。
前回の試みから何が変わったのでしょうか？AIはより優れた。それがもっと優れています。
すべてのプロジェクトがこうなるわけではありませんが、これは、いくつかのことが良いタイミングに合わせてできたため、実行しました。
Next.jsは明確に指定されています。広範なドキュメント、膨大なユーザーベース、長年にわたるスタックオーバーフローの回答とチュートリアルがあります。APIサーフェスは、トレーニングデータ全体をカバーします。ClaudeにgetServerSidePropsを実装したり、useRouterの仕組みを説明したりするように依頼しても、ハルシネーションはありません。次の仕組みを知っているのです。
Next.jsには、精巧なテストスイートがあります。Next.jsリポジトリには、あらゆる機能とエッジケースをカバーする数千のE2Eテストが含まれています。スイートから直接テストを移植しました（コードには帰属表示があります）。これにより、機械的に検証できる仕様ができました。
Viteは優れた基盤です。Viteは、高速HMR、ネイティブESM、クリーンなプラグインAPI、本番バンドルなど、フロントエンドツールの難しい部分を担います。バンドラーを構築する必要はありませんでした。Next.jsを話すようにする必要がありました。@vitejs/plugin-rscはまだ初期段階ですが、RSC実装を一から構築する必要なく、React Server Componentsをサポートしてくれました。
モデルは追いついていました。わずか数か月前では、不可能だったでしょう。以前のモデルでは、このサイズのコードベース全体で一貫性を保つことはできませんでした。新しいモデルは、アーキテクチャ全体を文脈から保持し、モジュールの相互作用について合理化し、しばしば正しいコードを生成することで、勢いを維持することができます。時には、Next、Vite、Reactの内部に侵入してバグを見つけることもありました。最先端のモデルは素晴らしいもので、ますます改善され続けているように見えます。
これらすべてが、同時に実現しなければなりませんでした。ターゲットAPI、包括的なテストスイート、基盤となるビルドツール、そして複雑さに対処できるモデル。どれを選んでも、うまく機能しません。
ほぼすべてのコードがAIによって書かれています。しかし、ここで重要なことは、すべての行が人間が書いたコードに期待するのと同じ品質のゲートを通過することです。このプロジェクトには、1,700以上のVitestテスト、380のPlaywright E2Eテスト、tsgoによるTypeScriptの完全タイプチェック、oxlintによるリンティングがあります。継続的インテグレーションにより、すべてのプルリクエストでそれが実行されます。AIのコードベースで生産性を高めるには、一連の優れたガードレールを確立することが重要です。
このプロセスは、計画から始まりました。OpenCodeでClaudeと何度もやり取りを重ね、何を構築するか、どのような順序で、どの抽象化を使用するかといったアーキテクチャを定義するのに数時間を費やしました。この計画は結果的に重要目標の達成に寄与しました。そこから、ワークフローはスムーズになりました。
タスクを定義します（「usePathname, useSearchParams, useRouter」で、次のナビゲーションシムを実装する）。
AIに実装とテストを書いてもらいましょう。
テストスイートを実行します。
テストに合格したら、合併します。そうでない場合は、AIにエラー出力を与え、反復させます。
繰り返し、
AIエージェントにコードレビューを依頼しました。PRを開くと、エージェントがレビューを行いました。レビューコメントが返されると、別のエージェントが対応しました。フィードバックループはほぼ自動化されています。
毎回、完璧に機能するわけではありませんでした。PRが間違っていたのです。AIは、正しいように見えるものの、実際のNext.jsの動作と一致しないものを自信を持って実装するでしょう。定期的にコース修正をしなければなりませんでした。アーキテクチャに関する決定、優先順位付け、AIがいつ行き詰ったかを知るなど、それは私にとって全容でした。AIに適切な指示、コンテキスト、ガードレールを与えると、生産性を大幅に高めることができます。しかし、それでも人間は舵取りをしなければなりません。
ブラウザレベルのテストでは、agent-browser を使用して、実際のレンダリング出力、クライアントサイドのナビゲーション、ハイドレーションの動作を検証しました。ユニットテストでは、多くの微妙なブラウザ問題を見逃します。それが彼らを捕獲したのです。
プロジェクトの全過程で、OpenCodeで800以上のセッションを実施しました。合計費用：Claude APIトークンでおよそ1,100ドル。
なぜこれほど多くのレイヤーがあるのでしょうか？このプロジェクトで、私はこの問いについて深く考えざるを得なくなりました。そして、AIがその答えにどのように影響するかを考慮することです。
ソフトウェアの抽象化が存在するのは、人間が支援を必要としているからです。システム全体を把握できなかったので、複雑さを管理するためのレイヤーを構築しました。各層は次の人の仕事を容易にしていました。こうして、フレームワークの上にフレームワーク、ラッパーライブラリ、何千行ものグルーコードが存在することになります。
AIにも同じ限界があります。システム全体をコンテキストに保持し、コードを記述するだけで、中間フレームワークが必要ないため、整理するのに役立ちます。つまり、仕様と構築のための基盤が必要なのです。
どの抽象化が真に基礎的なもので、どの抽象化が人間の認識を妨げるだけであったのかはまだ明確ではありません。この境界線は、今後数年で大きく変化するでしょう。しかし、vinextはデータポイントです。API契約、ビルドツール、AIモデルを持ち、AIはその間のすべてを書いてくれました。中間フレームワークは必要ありません。今後、多くのソフトウェアで繰り返されると思います。長年にわたって構築してきたレイヤーがすべて実現するわけではありません。
Viteチームのおかげです。Viteは、この全体の基盤となっています。@vitejs/plugin-rscはまだ初期段階ですが、ゼロから構築する必要なくRSCサポートを提供してくれました。これは、そうでなければプロジェクトを断念する要因となっていたでしょう。Viteの保守担当者は、以前テストされていない領域にプラグインをプッシュした際、対応が速くて協力してくれました。
また、Next.jsチームにも感謝の意を表したいと思います。彼らは、React開発の水準を引き上げるフレームワークを構築するために、何年も投資してきました。同社のAPIサーフェスは十分に文書化されており、テストスイートは非常に包括的であるという事実が、このプロジェクトを可能にした大きな理由となっています。vinextは、彼らが設定した基準なしには存在しません。
vinextには、移行を処理するエージェントスキルが含まれています。Claude Code、OpenCode、Cursor、Codeex、その他数十のAIコーディングツールと連携します。インストールし、Next.jsプロジェクトを開き、AIに移行するよう指示してください。
npx skills add cloudflare/vinext
そして、サポートされているツールでNext.jsプロジェクトを開いて、まさに以下を押してください。
migrate this project to vinext
このスキルでは、互換性のチェック、依存関係のインストール、設定の生成、開発サーバーの起動も行えます。Vinextが何をサポートしているかを知っており、手作業による注意が必要なものすべてにフラグを立てます。
手動で行いたい場合は：
npx vinext init # Migrate an existing Next.js project
npx vinext dev # Start the dev server
npx vinext deploy # Ship to Cloudflare Workers
ソースはgithub.com/cloudflare/vinextにあります。問題、PR、フィードバックをお待ちしています。