技術 約7分で読めます

CloudflareがAIで1週間でNext.jsをVite上に再実装、vinextが本番稼働

Next.js Vite Cloudflare Workers AI JavaScript

先週、Cloudflareのエンジニアが1人でNext.jsをゼロから再実装した。AIとのペアプログラミングによるもので、かかったトークンコストは約$1,100。その成果物 vinext（ヴィネクスト）がオープンソースで公開され、すでに本番稼働している実例がある。

なぜNext.jsを再実装するのか

Next.jsはReactの事実上の標準フレームワークだが、Cloudflare・Netlify・AWS Lambdaへのデプロイは長年の課題だった。Next.jsはTurbopackという固有ビルドチェーンに深く依存しており、ビルド出力を各プラットフォーム向けに変換する必要がある。

その問題を解くために生まれたのがOpenNextだ。だが「Next.jsのビルド出力をリバースエンジニアリングする」という構造上、Next.jsのバージョンアップのたびに予測不能な変更に追いつくいたちごっこが続いてきた。

Next.jsは公式のアダプターAPIを開発中だが、それでもTurbopackのビルドチェーンに縛られる。開発環境（next dev）はNode.js限定で動き、Durable ObjectsやKV、AI bindingsといったCloudflare固有のAPIを開発中にテストするにはワークアラウンドが必要だった。

Cloudflareが辿り着いた結論は「適合するより再実装する」だった。

vinextとは

vinextはNext.jsの APIサーフェスを Viteプラグインとして再実装したもの。Next.jsのラッパーではなく、同じAPIで動く別の実装だ。Viteはこれ以外のほぼすべての主要フロントエンドフレームワーク（Astro・SvelteKit・Nuxt・Remix）が採用しているビルドツールで、出力はVite Environment APIのおかげで任意のプラットフォームで動く。

npm install vinext

既存プロジェクトへの導入は package.json の next を vinext に書き換えるだけ。app/、pages/、next.config.js はそのまま使える。

vinext dev          # HMR付き開発サーバー
vinext build        # 本番ビルド
vinext deploy       # Cloudflare Workersへビルド＋デプロイ

ルーティング・サーバーサイドレンダリング・React Server Components・サーバーアクション・キャッシュ・ミドルウェアを実装しており、Next.js 16 APIの94%をカバーしている。

数値

33ルートのApp Routerアプリケーションを使って計測した。TypeScript型チェックとESLintはNext.jsビルドで無効化し、bundlerと compilationの速度のみを比較している。

本番ビルド時間:

フレームワーク平均時間比較
Next.js 16.1.6（Turbopack）7.38秒baseline
vinext（Vite 7 / Rollup）4.64秒1.6倍速
vinext（Vite 8 / Rolldown）1.67秒4.4倍速

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

フレームワークサイズ比較
Next.js 16.1.6168.9 KBbaseline
vinext（Rollup）74.0 KB56%削減
vinext（Rolldown）72.9 KB57%削減

Vite 8で導入されるRustベースのバンドラーRolldownが速度差の主な要因だ。ベンチマークはGitHub CIで毎マージごとに実行されており、結果と方法論は公開されている。

Cloudflare Workers展開

vinext deploy

このコマンド1つでビルドからWorker設定の自動生成、デプロイまで完結する。開発環境も含めアプリ全体がworkerd上で動くため、Durable Objects・AI bindingsといったCloudflare固有のAPIをワークアラウンドなしで使える点が従来のOpenNextと根本的に違う。

ISR（段階的静的再生成）はCloudflare KVをキャッシュバックエンドとして利用する。

import { KVCacheHandler } from "vinext/cloudflare";
import { setCacheHandler } from "next/cache";

setCacheHandler(new KVCacheHandler(env.MY_KV_NAMESPACE));

キャッシュレイヤーはプラグイン式で、R2など他のバックエンドへも差し替えられる。

Traffic-aware Pre-Rendering

vinextには実験的な機能「Traffic-aware Pre-Rendering（TPR）」がある。

従来のNext.jsは generateStaticParams() で列挙した全ページをビルド時に事前レンダリングするため、10万ページのECサイトでは30分超のビルドになる。ビルド時間がページ数に比例してスケールするのが構造的な問題だ。

TPRはCloudflareのゾーン解析データ（実トラフィック）を参照し、実際にアクセスされているページだけを事前レンダリングする。

vinext deploy --experimental-tpr

  TPR: 12,847 unique paths — 184 pages cover 90% of traffic
  TPR: Pre-rendered 184 pages in 8.3s → KV cache

べき乗則に従えば100万ページのサイトでも90%のトラフィックは通常50〜200ページに集中する。それだけをレンダリングし、残りはISRに任せる仕組みだ。 generateStaticParams() は不要で、本番データベースとビルドを結合する必要もない。デプロイのたびにトラフィックデータをもとにプリレンダリング対象が更新される。

1週間で作れた理由

最初のコミットは2月13日。同日夜にはPages RouterとApp RouterのSSRが動作し、ミドルウェア・サーバーアクション・ストリーミングが実装された。翌日午後にはApp Router Playgroundのルート11本のうち10本がレンダリング成功。3日目に vinext deploy でWorkersへのデプロイが動いた。

「数ヶ月かかると思っていた」というのが正直な評価だ。実際に取り組んだのは1人のエンジニアリングマネージャーがAIを指示する形で、ゼロから書いたのではなく、AIがコードを生成しエンジニアが判断・設計を担うスタイルだった。テスト面では1,700以上のVitestテストと380のPlaywright E2Eテスト（Next.jsのテストスイートとOpenNextのCloudflare適合スイートから移植したものを含む）が書かれている。

公開初週の実績として、National Design Studioが運営するCIO.govがvinextを本番稼働させており、ビルド時間とバンドルサイズの改善を確認している。

Next.jsの脆弱性とvinextの立ち位置

vinextの公開とは別の文脈だが、Next.jsはこの1年半でセキュリティ面の問題を複数抱えている。vinextが「再実装」である以上、これらの脆弱性との関係を確認しておく。

Next.js固有の実装バグ:

  • CVE-2025-29927（CVSS 9.1）: x-middleware-subrequest ヘッダーを外部リクエストから信頼していたため、ミドルウェアの実行が完全にスキップされる認証バイパス。ヘッダーにミドルウェア名を複数回繰り返すだけで悪用できた。セルフホスト環境のみ影響
  • CVE-2024-34351（CVSS 7.5）: Server Actionsの相対パスリダイレクト時にHostヘッダーを信頼していたためSSRFが可能
  • CVE-2024-46982（CVSS 8.7）: Pages Routerの非動的SSRルートでキャッシュポイズニングが可能
  • CVE-2024-51479: ルートディレクトリ直下の制限ページへの認証バイパス
  • CVE-2024-56332: Server Actionsへの特殊リクエストでサーバーがハングするDoS

vinextはNext.jsの内部コードを一切使わず完全に再実装しているため、これらのバグがそのまま存在する可能性は低い。特にCVE-2025-29927のような「内部ヘッダーを外部から信頼する」設計ミスは、実装をゼロから書き直す過程で排除される類のものだ。

Reactコアの脆弱性（vinextにも影響しうる）:

  • CVE-2025-55182 / CVE-2025-66478（CVSS 10.0）: React Server Componentsの「React2Shell」。RSCのFlightプロトコルにおけるデシリアライゼーション脆弱性で、認証不要でRCEが可能。2025年12月にCISAがKEVに追加し、実際の攻撃が確認された
  • CVE-2026-23864（CVSS 7.5）: RSCのDoS。React2Shell修正後も3回の不完全修正を経て2026年1月に4度目のパッチ

React2Shell以降の一連のRSC脆弱性はReactライブラリ自体に起因する。vinextもRSCを使う以上、同様に影響を受ける可能性がある。Cloudflareからの公式見解は現時点では出ていない。

このブログではReact2Shellの対応メモやReact2Shellがきっかけで別サイトをAstroに移行した話を書いた。Mintlify脆弱性との区別も整理している。Next.jsのセキュリティ問題は構造的なテーマになりつつある。

構造的な問題のパターン:

Next.jsの脆弱性を並べると見えてくるのは、ミドルウェアの信頼モデル・内部ヘッダーの扱い・Server Actionsの攻撃面拡大という繰り返しのテーマだ。フロントエンドフレームワークにサーバーサイド機能を追加するほど攻撃面は広がる。多くの脆弱性で「Vercelホストなら影響なし、セルフホストは影響あり」という非対称性があるのも特徴的だ。

vinextがこの構造的な問題をどこまで解決できるかはまだわからない。ただ、Next.js内部のビルド出力に依存しない再実装というアプローチは、少なくとも「Next.jsの実装バグをそのまま継承する」リスクからは解放される。

Cloudflareの本気度

Steve Faulkner（Cloudflare Workers Director、80人以上の組織を統括）がGitHub Issue #21で「これは実験だが、リソースを直接配分できるディレクターが関わっている」と明言している。Tanner Linsley（TanStack創設者）は「OpenNext以来、初めての実行可能なNext.jsフォーク」と評価した。

一方で「vibe codedなコピー」「TanStack Startなど既存フレームワークのサポートを優先すべき」という声もある。Vercelからの公式声明は出ていないが、vinextがVercel上で動作する概念実証（vinext-on-vercel.vercel.app）は存在する。

現状と限界

vinextはまだ実験的プロジェクトだ。ビルド時の静的事前レンダリング（generateStaticParams()）は未実装で、完全に静的なサイトへの恩恵は今のところ薄い。READMEには非対応事項と既知の制限が率直に列挙されている。

現在のデプロイターゲットはCloudflare Workersだが、実装の約95%はCloudflare非依存の純粋なViteコードだという。Vercelへの概念実証は30分未満で動作させられたとのことで、他プラットフォームのデプロイターゲット追加のPRを受け付けている。