JavaScript開発の待機時間は、長年「トランスパイル」「バンドル」「Lint」の分断で最適化されてきた。だが2025年12月のVite 8 Betaと、2026年1月のRolldown 1.0 RC公開は、この前提を根本から更新した。開発サーバと本番ビルドの基盤をRolldownへ統一し、Oxc系ツールを標準経路に組み込み、Rust実装の処理系を中心にフロントエンドのツールチェーン全体が再編されている。

本稿は、2026年3月時点の一次情報を基に、Rolldown・Oxc・Biomeが「体感10倍級」の開発体験をどう作るかを分解する。結論を先に述べると、Oxc parser単体が常に10倍という意味ではない。各工程の高速化が積み重なった結果として、フロントエンド開発のボトルネックが連鎖的に縮小する構造である。

1. VoidZeroの戦略: なぜ「統一ツールチェーン」なのか

Viteの生みの親であるEvan Youが設立したVoidZeroは、Vite・Vitest・Rolldown・Oxcを一つの組織の下に統合し、「エンドツーエンドのツールチェーン」を目指している。

従来の問題は、各工程が別プロジェクトで開発されていたことにある。バンドルはwebpack/Rollup、トランスパイルはBabel/SWC、Lint/FormatはESLint/Prettier──各ツールが独自のAST表現と設定体系を持ち、同じコードを複数回パースする構造的非効率が常態化していた。

VoidZeroの統一ツールチェーンは、この冗長性を排除する。Oxcが生成した単一のASTをRolldownがバンドルに使い、同じASTをOxlintがLintに使い、Oxfmtがフォーマットに使う。「パースは1回だけ」という設計原則が、理論的なスループット上限を引き上げる。

2. Vite 8の設計転換: esbuild+Rollup分離からRolldown統一へ

Vite 8 Betaの発表（2025-12-03）で明確になったのは、従来の「esbuild + Rollup」中心設計から、Rolldown中心設計への移行である。公式Migration Guide（v7→v8）でも、デフォルトバンドラにRolldownを採用し、parser/minifierをOxcベースへ切り替える方針が示されている。

技術的に重要なのは、開発時と本番ビルドの「二重構造」の解消である。Vite 7以前は、開発時はesbuild、本番はRollupという二層構造で「開発では動くが本番で壊れる」差異が構造的に発生していた。Rolldown統一でこの差異が原理的に縮小する。

さらに、VoidZeroは「Vite+」のパブリックプレビューを2026年前半に予定している。Vite・Rolldown・Oxcを統合した「設定ゼロ」のツールチェーンで、ツール選定・設定に費やす時間の削減を目指す。

3. Rolldownの実測値: 本番環境での定量的成果

Rolldown公式ベンチマーク（React + MUI + Icons、約19,112 modules）では、Cold Startが1.339秒（Vite + Rolldown）対22.817秒（Vite + Rollup）、HMRが404ms対1,126ms。Cold Startは約17倍、HMRは約2.8倍の高速化である。

2026年1月21日のRolldown 1.0 RCでは、本番環境での定量データも蓄積されている。

企業/プロジェクトビルド時間削減具体的数値
Linear87%削減46秒 → 6秒
Beehiiv64%削減大規模コードベース
Mercedes-Benz.io38%削減エンタープライズ規模
SPA検証事例5倍高速化3.8秒 → 0.8秒

削減率はプロジェクト規模で異なるが、CI/CDが1日数十〜数百回実行されるエンタープライズ環境では、38%の短縮でも年間数百時間の開発者時間に換算される。

筆者自身、150人月規模の基幹システム開発で技術リードを務めた経験から、大規模プロジェクトではビルド待機時間がチームのモラルに直結する。20秒の待機が1日50回で約17分の損失、コンテキストスイッチの再集中コストを含めれば実質数倍になる。Cold Startが1〜2秒台なら、HMR以上に生産性が改善する。

4. OxcとBiome: 各工程の高速化が生む「複利効果」

4-1. Oxc: パーサーからフォーマッターまでの全工程カバー

Oxc（The JavaScript Oxidation Compiler）は、VoidZero傘下のプロジェクトとして全工程をRust実装でカバーする。2026年3月時点のコンポーネントは以下の通り。

  • Oxc Parser: SWC比約3倍、Biome parser比約5倍の速度
  • Oxlint: ESLint比50〜100倍高速、695の組み込みルール。TypeScript 7のGoネイティブコンパイラ（tsgo）との統合で完全なTypeScript互換を実現
  • Oxfmt: Prettierの100%コンフォーマンステスト（JS/TS）に合格しつつ最大36倍高速
  • Oxc Transformer: Babel比40倍超のケースが公開ベンチマークで確認
  • Oxc Resolver: モジュール解決のボトルネック解消、Rolldownで本番利用中

一次情報上「常に10倍高速」と断定するのは正確ではないが、各工程を合計した体感改善は10倍級に達しうる。これがTypeScript 7のGoネイティブコンパイラによる10倍高速化と組み合わさると、トランスパイル→型チェック→バンドル→Lint→フォーマットの全パイプラインでRust/Go実装が支配的になる。JavaScript自身が「書かれる言語」ではなく「処理される言語」になりつつある逆転現象が起きている。

4-2. Biome: Lint/Formatの統合と2026年の進化

BiomeはRome（旧Facebook/Meta）のフォークとして独立し、v2.xに到達。Prettier比20〜35倍高速なformatter、ESLint比15倍以上のlinter（450以上のルール）、GritQLベースのカスタムルールが特徴。対応言語はJS/TS/JSX/JSON/CSS/GraphQLに加え、Vue/Svelte/Astroの実験的サポートも進む。

BiomeとOxc（Oxlint/Oxfmt）は機能が重複する領域がある。VoidZeroのツールチェーンではOxlint/Oxfmtが推奨されつつあるが、Biomeはネスト設定やGritQLなど独自の強みを持ち、要件に応じた選択が求められる。

5. 移行の実務: 段階的導入プロトコル

Rust製ツールチェーンへの移行は、理論上の高速化と実務上の移行コストのバランスで判断すべきである。

Phase 1: 計測（1〜2日）

Cold Start（開発サーバ起動）、HMR（ファイル変更反映）、Lint（全ファイル実行）、CI Build（本番ビルド）の4指標を現行値で固定する。

Phase 2: Lint/Format置換（1〜2週間）

最もリスクが低い工程から着手する。ESLint→Oxlint、Prettier→Biome formatter（またはOxfmt）への置換は、コード動作に影響しないため安全に実施できる。既存ルールの互換性確認、フォーマット差分の検出と合意、CI/CDパイプラインの置換を順に行う。

Phase 3: Vite 8 + Rolldown移行（2〜4週間）

バンドラ置換は影響範囲が広い。Rollupプラグインの互換性確認、開発環境の動作検証、本番ビルド出力の差分比較、E2Eテスト通過を順に確認する。AI生成コードの技術的負債が指摘されるなか、AI支援で高速に生成されたコードほど暗黙の依存関係が埋もれやすく、バンドラ変更で顕在化するリスクがある。

6. Rust製ツールチェーン統一がもたらす構造的変化

第一に、開発フロー設計が変わる。2024年以前の最適化は「重いチェックをCIに逃がす」が中心だったが、2026年時点では「ローカル常時実行しても回る」方向に移りつつある。Oxlintが全ファイルを数十ミリ秒でLintできるなら、ファイル保存のたびにLintを走らせても体験を損なわない。Claude Code hooksによるコード品質ゲートと組み合わせれば、AIコーディングの品質保証もリアルタイムで実現できる。

第二に、モノレポ運用の前提が変わる。Rust基盤でウォッチ再計算が短くなると、パッケージ分割を「速度のために過剰化」する必要が薄れる。RolldownのCold Startが1〜2秒なら、分割の動機自体が弱くなる。アーキテクチャ判断を、ビルド都合ではなくドメイン境界で行いやすくなる。

第三に、ツール選定の評価軸が「機能数」から「レイテンシ予算」へ寄る。フロントエンドの競争力は、UIの品質だけでなく1日の反復回数で決まる時代に入っている。React 19 Server ActionsがAPI仕様書レス開発を推進するのと同様に、ツールチェーン高速化は開発プロセスそのものを再設計する契機になる。

7. 競合ツールとの比較

ツール言語互換性採用先ステータス
RolldownRustRollup API互換Vite 81.0 RC
RspackRustwebpack API互換ByteDance安定版
TurbopackRustNext.js専用Next.js開発中
esbuildGo独自API広範安定版

選択の基準は「どのエコシステムに接続するか」である。Viteユーザーにはrolldown、webpackからの移行にはRspackが最も摩擦が少ない。TurbopackはNext.js専用、esbuildは更新頻度が低下している。

FAQ

Vite 8 + Rolldownは本番利用できるのか？

Rolldownは1.0 RC段階でAPIの破壊的変更は原則ない。Linear、Beehiiv、Mercedes-Benz.ioが本番採用済み。Rollupプラグインの互換性確認は移行前に必要。

Oxcは本当に10倍速いのか？

parserベンチはSWC比約3倍、Biome parser比約5倍である。一方、transformer（Babel比40倍超）やlinter（ESLint比50〜100倍）は桁違いの高速化を示す。10倍級という表現は、開発全体の待機時間で捉えるのが妥当である。

Biomeに置き換えるとESLint/Prettier運用は不要になるのか？

BiomeはLint/Format統合の利点が大きいが、既存ESLintプラグイン資産が多い組織では段階移行が現実的である。Biome 2.0のGritQLプラグインでカスタムルール作成が可能だが、ESLintの全ルールカバーには至っていない。

OxlintとBiome Linterはどちらを選ぶべきか？

VoidZeroのVite+エコシステムに乗る場合はOxlintが自然な選択。Biomeはネスト設定、GritQLプラグイン、CSS/GraphQL対応など独自の強みを持つ。性能差よりも設定体系やプラグインエコシステムの要件で判断すべきである。

webpackからの移行はRolldownとRspackどちらが適切か？

webpackのプラグイン資産を活かすならRspack（webpack API互換）。新規やVite移行前提ならRolldown（Rollup API互換）が将来性で優る。

Rustツールチェーン統一の最初の一手は？

最初は計測。Cold Start、HMR、Lint、CIビルドの4指標を現行値で固定し、導入後の差分を比較すると投資対効果を定量化しやすい。計測なき最適化は改善ではなく趣味である。

Rust製ツールはJavaScript開発者にとってブラックボックスにならないか？

内部実装への参加はハードルが上がるが、APIとCLIはJS開発者に馴染み深い設計。RolldownプラグインはRollup互換、Biome設定は直感的なJSON/TOML。使い方にRustの知識は不要である。

参考文献