ハクソク

世界を動かす技術を、日本語で。

AIを使って1週間でNext.jsを再構築した方法

90日前原文(blog.cloudflare.com)

概要

  • vinext はViteベースでNext.js互換の新フレームワーク
  • Cloudflare Workers へのデプロイがワンコマンドで可能
  • ビルド速度最大4.4倍、バンドルサイズ最大57%削減
  • ISRやTraffic-aware Pre-Rendering など先進的キャッシュ戦略を搭載
  • AI活用で1週間未満 で開発、実運用事例も登場

vinext：ViteベースのNext.js互換フレームワーク誕生

  • vinext （発音：ヴィーネクスト）は、 Next.js のAPI互換を目指して Vite 上に再実装されたフロントエンドフレームワーク
  • Cloudflare Workers へのデプロイが vinext deploy コマンド1つで完結
  • App Router や Pages Router、 next.config.js、既存のディレクトリ構成がそのまま利用可能
  • Viteプラグイン として動作し、Next.jsやTurbopackのビルド出力に依存しない完全な独立実装
  • ルーティング、 SSR、 React Server Components、 サーバーアクション、 キャッシュ、 ミドルウェア などNext.js APIの主要機能を網羅

Next.jsのデプロイ課題とvinextのアプローチ

  • Next.js は人気だが、 Turbopack ベースの独自ビルドでサーバーレス環境（Cloudflare, Netlify, AWS Lambda等）への展開が困難
  • OpenNext のようなツールでビルド出力を変換する必要があり、バージョン間の非互換や保守コストが高い
  • vinext はNext.jsの出力に頼らず、 Vite を基盤に API互換 を直接実現
    • 開発サーバー もNode.jsに依存せず、Cloudflare Workers上での実行・テストが容易

ベンチマーク結果

  • ビルド速度
    • 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.9KB
    • vinext（Rollup）： 74.0KB（56%削減）
    • vinext（Rolldown）： 72.9KB（57%削減）
  • 測定条件
    • 33ルートのApp Routerアプリで比較
    • TypeScript型チェック・ESLint無効化、プリレンダリング無効化
    • コンパイル・バンドル速度のみ測定

Cloudflare Workersへのデプロイとキャッシュ

  • vinext deploy コマンドで ビルド・設定生成・デプロイ を自動化
  • Cloudflare KV を使った ISR（Incremental Static Regeneration） が標準搭載
    • setCacheHandler(new KVCacheHandler(env.MY_KV_NAMESPACE));で柔軟にキャッシュバックエンドを切替可能
    • R2 等、他のストレージも選択可能
  • Cloudflare固有API （Durable Objects, AI bindings等）も開発・本番両方で利用可能

実運用・エコシステム展開

  • Cloudflare Workers 以外にもViteベースのため他プラットフォーム対応も容易
    • Vercel へのPoCは30分で実現
  • OSS として公開、他社・他プラットフォームからのPRも歓迎
  • National Design Studio 等、実際の運用事例でビルド速度・バンドルサイズの大幅改善を確認

実装・テスト状況と注意点

  • 実験的段階、1週間未満の開発歴
  • 1,700以上のVitestテスト、380のE2Eテスト （Next.js/OpenNextテストも含む）
  • Next.js 16 APIカバレッジ94%
  • READMEで未対応・既知の制限を明示
  • 本番利用は慎重に評価推奨

プリレンダリングとTraffic-aware Pre-Rendering

  • ISR は即日サポート、初回リクエスト後にバックグラウンドで再生成
  • ビルド時プリレンダリング は未対応（今後対応予定）
    • 静的サイトはAstro等Viteベースの他フレームワークを推奨
  • Traffic-aware Pre-Rendering（TPR） を実験導入
    • Cloudflareのアクセス解析 から実際にアクセスされるページのみプリレンダリング
    • 例：10万ページ中、実際に90%のトラフィックを占める184ページのみを8.3秒でプリレンダリング
    • 残りはオンデマンドSSR＋ISRでキャッシュ
    • generateStaticParams()不要、DB接続不要

AIによる爆速開発

  • 1人のエンジニアとAI のみで 1週間未満 で開発完了
  • 2つのルーター、33以上のモジュールshim、SSR/RSC/ミドルウェア/キャッシュ/静的エクスポート 等を実装
  • AIの進化 により、従来は数ヶ月〜年単位の開発が短期間で実現可能に

vinext は、Viteベースの新世代Next.js互換フレームワークとして、 Cloudflare Workers をはじめとしたサーバーレス時代のデプロイ体験を大幅に刷新。 AI活用による圧倒的な開発効率 と、 ビルド速度・バンドルサイズの劇的な向上 が特徴。今後も進化が期待される実験的プロジェクト。

Hackerたちの意見

振り返ってみると、モデルの進化や高品質なテストがある中で、全く予想通りの成果だけど、それでもすごく印象的だね。これが何を意味するのかは分からないけど、また一つのマイルストーンな気がする。

これ、めっちゃ興味深いし、最近考えてた複雑なAIのインセンティブも絡んでるね。自分の仕事をしっかりドキュメント化すればするほど、強い契約を定義すればするほど、他の人がその仕事をクローンしやすくなる。オープンソースの商業プロジェクトがSQLiteモデル（オープンコア、プライベートテスト）に傾くのも驚かないよ。Cloudflareがこれを実現できたのは、Nextの独自テストがあったからだと思う。フレームワークについて言うと、唯一の結論は、サーバーコンポーネントが誤解されていて、あまり活用されていないパターンだってこと。DXを簡素化しようとする人は、私にとっては勝者だね。Nextはすごく複雑で、徐々に成長してきて、ある程度後方互換性を保ってるからね。現在のAPIサーフェスから始まって成長するフレームワークは、もっと柔軟で、最初に厳しい決断を下せるかもしれない。もう.govドメインで動いてるのを見るのはクレイジーだね。[0] TTFGOVが新しい採用指標になるのかな？

└

自分の仕事をしっかりドキュメント化すればするほど、強い契約を定義すればするほど、他の人がその仕事をクローンしやすくなる。 そうだね、私も同じことを考えてる。1人または1つの組織がAPIの複数のアプローチをテストして、ベストプラクティスを確立・見直しし、エコシステムを開発するためのハードワークをする。で、ある程度安定して理解されると、別の人がそれをパクるだけ。Vercelにはあまり同情しないけど、ホスティングを使わない人にフラストレーションを与えてるのは自業自得だと思う。小規模なプロジェクト（コピーレフトのものも含む）がどうなるか心配だな。

└

Cloudflareがこれを実現するためにNextのテストなしでできたとは思えない。全然納得できない。歴史が示すように、ソースコードにアクセスせずに逆アセンブルされた非常に複雑なシステムがあった。ソースコードにアクセスできて、AIの迅速な反復がある中で、ここに本当の防壁は見えない。せいぜい少しの遅れがあるだけだと思う。

└

SQLiteモデルのポイントは過小評価されてる。実際の堀はテストスイートそのものじゃなくて、どのエッジケースが重要で、なぜそれが重要なのかを知っている人なんだ。通過するテストはクローンできるけど、それを書いた判断力はクローンできないからね。

全体で約1100ドル分のトークンがかかった。これが指摘されてるのはいいね。

これがHNのフロントページであまり高評価を得なかったのは驚き、たった34ポイント？ 1100ドルのトークンで1週間でこれを成し遂げたのは本当にすごいよね。私もそう思うし、私の仲間たちも、コードはタスクを達成するための道具に過ぎなくなってるって言ってる。コード自体が製品であるべきじゃなかったし、今もそうじゃない。これは素晴らしいニュースで、文明としてここにいるべきだと思う。これに困ってるのは、コードが神聖であるべきだと思ってるゲートキーパーたちだけ。これはコンピューティングの歪みで、間違った人たちが集まってる。VercelがNext.jsプロジェクトのホストとして1位であり続ける一方で、他の人たちはGithub統合を有効にするだけでプラットフォームに移行できると言ってるけど、実際はそうじゃない。CloudflareもNextプロジェクトをそのインフラで動かせるって言ってるけど、うまくいかなかった。Replitも同じことを言ってるけど、Nextもそこで失敗してる。いくつかの痛いハックを経て、試行錯誤しても結局無駄になる。もっと時間とフラストレーションが少なかったのは、Opus 4.6のClaude CodeにNextプロジェクト全体をReact+Viteに変換してもらったこと。あ、宣伝だけど、https://jsonquery.appを完全に稼働させることができて、ビルドはViteで超速かったし、Cloudflareページで2-3回の試行でうまくいった。SSRやNextのルーティングが必要ないなら、同じことをすることをお勧めするよ。あ、Next.jsの世界では、Turbopackには厳しいエッジケースがあって、Webpackに戻さざるを得なかった。特にWASMを扱うとき、JSON Queryはjq依存関係をWASMとして持ち込んでウェブで動かすから、これはViteには問題ない。

└

それとも、Next.jsや他のJSのSSRをスキップして、ElixirとPhoenix LiveViewに移行するのもありだね。ClaudeとCodexは今、Elixirにすごく強いからね。https://elixirisallyouneed.dev

└

これがHNのフロントページで高評価を得なかったのは驚きだね、たった34ポイント？Cloudflareが何かを作ったとき、前回はTODOが山ほどある栄光のプロトタイプだったから。

└

これがHNのフロントページで高評価を得なかったのは驚きだね、たった34ポイント？HNがついにCloudflareの投票リングを打ち破ったみたいだ。

└

Cloudflareワーカーでnextjsを使おうとしたとき、すごく問題が多かった。

└

コードは決して製品そのものではなかったし、そうあるべきでもなかった。 でも、コードは実際の製品を完全に、正確に定義しているよね。悪いコード => 悪い製品。 > コードは神聖で、尊重されるべきだ。手と頭の産物として、コードは尊重されるべきだよね。作った人間やグループの印として。 > 間違った人たちのグループ。周りの世界を深く気にかけている人たちのグループ。

誰かがNext.JSの機能を再現するために1000ドル以上使ったのか。1ドルでも多すぎる気がするな。私がちょっと過剰に報復的になってるのかも。

└

それは生産アプリを最大4倍速く作り、クライアントバンドルを最大57%小さくするんだって。確かに、君が過剰に報復的なのはその通りかもね。

Next.jsは、Reactのサーバーサイド実装のせいでリモートコード実行の脆弱性があった。しばらく待たないとAI版には手を出さないつもり。

└

ありがとう。これが一番驚いた部分だよ。私はこの理由でずっとNext.jsに警戒してたんだ（実際、RCEの前は個人プロジェクトで使うのを拒否してたくらい）。サーバーサイドのデータをクライアントに漏らすミスをするのが怖かったから。こういうバグは簡単に起こるし、AIで何千行もコードを生成してると、見逃しやすいんだよね。

いや、Nextも好きなんだけど、Viteも好きなんだよね。でもNextチームは嫌い。彼らは0.1%のユーザーのために派手な新機能に集中してて、残りの99.9%のNextコミュニティは完全に無視されてるから。だから、俺みたいな人には全てが揃ってる。Nextコミュニティは何年もパフォーマンス向上を求めてきたのに、Nextチームは無視してたけど、Cloudflareチームは違った。ViteはNextの人たちが使ってるゴミよりも優れたコアレイヤーだけど、フルのNext機能も使える。Cloudflareのこのフォークが成功することを願ってる。会社で使えるようになればいいな！

└

NextのどこがVercelに結びついてなくて、他では手に入らないのが好きなの？俺もNextが好きだけど、その価値はVercelに密接に結びついてると思う。Vercelの派手な機能のためにNextを選ばないなら、使うことを想像できないな。

└

うちの職場では、7年以上前のNext.jsアプリがあって、新機能は追加されないけど、ちゃんと動いてるんだよね。でも、理由もなくランダムに変更されることがあって、もう何回も大きなNext.jsのバージョンアップのためにリファクタリングに時間を無駄にしてる。

└

そもそもバックエンドにJavaScriptを使いたくないでしょ… それなら、Viteと好きなバックエンドを使うだけでいいんじゃない？

└

Nextは、Railsの次に使った中で最悪のフレームワークだよ。ほとんどのアプリにとっては純粋にオーバーヘッドだね。

Astroを買ったのが面白いと思う（https://blog.cloudflare.com/astro-joins-cloudflare/）。俺はフロントエンドの人間じゃないけど、Nextと似たような問題に取り組んでるように見える。1ヶ月前の話だけど。もし彼らが推奨するものを作るのがそんなに安いなら（プロトタイプじゃなくて）、なぜAstroを買ったんだろう（このクローンのトークンコストより高かったはずだし）。一つの結論は、組織レベルでフレームワークの「ビジョン」を持っている人を雇う方が、単にクローンを作るよりも意味があるってことかも。あるいは、もしかしたらAIがこの1ヶ月でそんなに進化したのかもね！

└

彼らはユーザーや開発者をCF製品に誘導したいだけなんじゃないかな？二つのプラットフォームを見るのは面白いね。俺はSvelteに移行したけど、フロントエンドの人間じゃなかったのに、実際楽しんでるよ。

└

Astroは全然違うパラダイムだね。Astroを手に入れることで、Cloudflareは非常に価値のあるウェブサイトのクラスに影響を与えることができる。これは、VercelがNext.jsを所有していることで別のクラスに影響を持つのと同じ感じ。AstroはCloudflareにとってはずっと合ってると思う。Next.jsは人気だけど、Vercel以外で動かすのは本当にひどい。CloudflareはNext.jsをより良くするわけじゃなくて、ただ自分たちの顧客がVercelからCloudflareにNext.jsのサイトを移行できるようにしようとしてるだけだよ。現実的に考えると、Next.jsのサイトをCloudflareに移す人は、最終的にはAstroに移行することになると思う。

└

「私のフロントエンドの専門家じゃない視点から見ると、Nextと似たような問題に取り組んでいるように見える。」 そうじゃないよ。Astroは動的なウェブアプリじゃなくて、静的サイト向けなんだ。

└

Astroとは違って、これは競合をバカにしながら低コストの実験をしてるように見える。真剣なプロダクション用のプロジェクトとは思えない。もしかしたら間違ってるかもしれないけど、数年後にどうなるか見てみよう。

└

その懸念を買って人を雇うんだよ。スタックはもう無料なんだから。

└

Astroには「サーバーアイランド」があって、どこかでバックエンドサーバーが動いてるんだ。ページの90%が静的だけど、残りの10%にインタラクティブ性が必要なら、Astroはいい選択だよ。他の純粋な静的サイトジェネレーターとは違うところだね。Next.jsとは違って、Reactに縛られないし、フレームワークに依存しないからね。とにかく、Cloudflareにとってはいいフィットなんだ。バックエンドはどこかで動かす必要があるし、Astroはその背後にあるユーザーベースが大きいから、Cloudflareがサービスを宣伝できるんだ。実際の取得というよりは、ターゲット広告みたいな感じだね。彼らはその技術にすごく興味があるから。もしそうなら、取得する代わりにフォークすればよかったんじゃないかな。Astroの視点から見ると、彼らは完全にオープンソースのツールでゼロのペイウォールで働いていた時よりも、（おそらく）もっとお金を得ているから、Cloudflareが今誰も使ってない彼らの vibe-coded プロジェクトから得られないウィンウィンな状況だね。

ソフトウェアのほとんどの抽象化は、人間が助けを必要とするから存在する。私たちは全体のシステムを頭に入れておけないから、複雑さを管理するためのレイヤーを作ったんだ。ちょっと雑な表現だけど、抽象化やレイヤリングがソフトウェアに存在するのは、人間が理解するために助けが必要だからだと言うのは正確じゃないと思う。抽象化はしばしば、現実世界のある側面の本質を捉えたり、ソフトウェアの再利用を可能にするために存在する。AIはソフトウェアの再利用が役立つと思う？それに、「抽象化」を「レイヤー」と同じものとして結びつけてるけど、実際には違うよね。レイヤーは関心の分離に関するものだから。レイヤリングは一種の抽象化だと言えるかもしれないけど。

これは今まで見た中で一番面白いAI実験かも。コードベースを見てると、どこにコードがあるのか疑問に思っちゃう。誰かがnext.jsのコードベースを見たことがあるかは分からないけど、これの再実装よりも少なくとも2桁多いコードがあると思う。だから、実際にエッジケースを処理してるのか、それともテストを通過するだけなのか気になるな。どちらにしても、かなり印象的だね。