필사 모드: JSビルドツールのRustの波 2026 — Turbopack / Rspack / Rolldown / oxc / Biome / Vite 6 / Bun 徹底比較
日本語プロローグ — 「なぜまたビルドツールなのか」
2010年代後半にフロントエンドをやっていた人なら一度は聞いたジョークがある。**「JavaScriptビルドツールは6か月で入れ替わる」**。Grunt、Gulp、Browserify、webpack、Parcel、Rollup、Snowpack、esbuild、Vite、Turbopack…ジョークは事実だった。
ところが2024〜2026年の流れは種類が違う。**新しいツールではなく、新しい言語で書き直されたツール**が次々と登場している。ほぼ全部が**Rust**だ(esbuildはGo、BunはZigの例外)。webpackはJSで書かれたバンドラ、BabelはJSで書かれたトランスパイラ、PrettierとESLintはJSで書かれたツールだった。2026年に同じ席を狙う後継たちは**例外なくネイティブコンパイル**である。
> これは**世代交代**だ。「速いツールが新しく出た」のではなく、**ビルドチェーン全体の言語とアーキテクチャが入れ替わっている**。
この記事はその地形を整理する。どのツールが何の役割で、誰が作って、どこで使われ、2026年現在どの段階にあり、何を選ぶべきか。単なるベンチマーク集ではなく、**ビルドチェーン全体の構造図**を描く。
第1章・なぜ今Rustの波なのか
JavaScriptのツールがJavaScriptで書かれていたのは自然な選択だった。ユーザーがJS開発者、コントリビュータもJS開発者、エコシステムがJSだった。webpack、Rollup、Babel、Prettier、ESLint — 全部JSである。
問題は**スケール**だ。2010年代後半から、次の3つが同時に起きた。
1. **アプリが大きくなった**。5万モジュールのモノレポが普通になった。1回のビルドに5分、devサーバ起動に30秒。
2. **CI/CDが常態化した**。PR毎にビルド/テスト/リントが走り、シングルスレッドのJSツールがボトルネックになった。
3. **タイトなフィードバックループへの依存度が上がった**。HMRが1秒vs 100ms — 一日中開発する人にとっては認知的に別のツールである。
JSは本質的に**シングルスレッド + GC + 動的型**だ。パーサ・AST変換・バンドリングはCPUバウンドな並列処理の典型である。Rustは正反対 — マルチスレッド、GCなし、静的型、ゼロコスト抽象。トレードオフがピタリと噛み合う。
esbuildが2020年に**「Goで書けば100倍速い」**を実証したとき、業界の方向は決まった。Evan Wallaceがwebpackビルド20秒を200msに縮めた。次の問いは自然だった — **「なぜ皆そうしないのか?」**。
答えは二つに分かれた。
- **Go**: GCがあり、文法が単純で、コンパイルが速いが、ゼロコスト抽象に欠ける。esbuildはこちらを選んだ。
- **Rust**: GCなし、ownershipが厳しく、学習曲線が急だが、本物のシステムレベルの性能と安全性を同時に得る。ほぼ全ての後継ツールがこちらを選んだ。
2026年から見ると結果は明確だ。**Rustが勝った**。swc、Turbopack、Rspack、Biome、oxc、Rolldown、Farm、Lightning CSS、tsdown — 新しいツールはほぼ全てRust。Goはesbuildひとつ、ZigはBunひとつ。残り全部Rustである。
第2章・分類表 — まずは役割で理解する
ツール名が多すぎて混乱するが、**役割でまとめれば単純だ**。ビルドチェーンは次の段階に分かれる。
| 段階 | 役割 | JS時代の代表 | Rust時代の後継 |
| --- | --- | --- | --- |
| Parse | ソースをASTへ | acorn、@babel/parser | swc、oxc |
| Transform | JSX/TS → JS、ダウンレベル | Babel | swc、oxc-transformer |
| Lint | 静的解析 | ESLint | Biome、oxlint |
| Format | コード整形 | Prettier | Biome、dprint |
| Resolve | モジュールパス解決 | enhanced-resolve | oxc-resolver |
| Bundle | モジュールグラフ→チャンク | webpack、Rollup、Parcel | Turbopack、Rspack、Rolldown、Farm |
| Minify | コード圧縮 | terser、uglify-js | swc-minify、oxc-minifier、esbuild |
| Dev Server | HMR/バンドルレス | webpack-dev-server | Vite、Turbopack |
| CSS | 変換・最小化 | postcss、cssnano | Lightning CSS |
| Runtime | JS実行 | Node.js | Bun、Deno |
| Package Manager | 依存インストール | npm、yarn、pnpm | Bun、Volta |
これを頭に入れておけば、新しい名前が出ても「ああ、X段階の後継だな」と位置を把握できる。
もう一つ — 「ツール統合」の流れ
Rust時代のもう一つの特徴は**一つのツールが複数段階を兼ねる**ことだ。Biomeはlint + formatを統合。oxcはparse + transform + lint + format + minify + resolveを一つの傘の下に集めようとする。Bunはruntime + package manager + bundler + test runnerを束ねる。**垂直統合**である。
JS時代は「Unix哲学 — ひとつのことをうまくやれ」だった。Rust時代は「単一のASTを共有してパースは一度だけ」だ。両方に理がある。どちらが勝つかは未決定。ただし**現在のモメンタムは統合側**にある。
第3章・Turbopack — Next.js 15のデフォルトdev (buildはbeta)
**誰が** Vercel。当初はwebpackの作者Tobias Koppersが主導。
**言語** Rust。
**役割** Bundler + Dev server。
**状況 (2026年5月)** Next.js 15のデフォルトdev。Buildはまだbeta — Next.js 16でstable目標。
コアアイデア — 関数単位のキャッシュ
webpack/Viteとの本質的な違いは**Turbo Engine**というキャッシュ層だ。全ての変換は関数で表現され、入力が同じなら結果をキャッシュする。Turbopackはこれを**incremental computation**と呼ぶ。
// Turbo Engineは依存グラフを自動で追跡する
#[turbo_tasks::function]
async fn parse_module(path: FilePath) -> Result<AstVc> {
let source = read_file(path).await?;
Ok(swc_parse(source))
}
`parse_module`を二度呼んでも、入力が同じなら二度目はキャッシュヒットだ。ファイルが変わると、それに依存する関数だけが無効化される。結果としてHMRがほぼ即時になる。
現実 — なぜbuildはまだbetaなのか
2024〜2025年、Turbopackには「devは速いがbuildは未完成」という評が多かった。CSS Modulesのエッジケース、Sentryなどwebpackプラグインとの互換、一部のmodule federationでwebpack出力と微妙に違う。2026年現在、buildはNext.js 15でopt-in beta。**本番採用するかはチーム状況による** — Vercelホスティング + 標準的なNext.jsならどんどん安全になっているが、巨大なwebpackプラグイン資産があるならまだwebpack buildを残す現場も多い。
誰が使うべきか
- Next.js 15+の新規 → devはそのまま有効化。
- Next.js 12〜14既存 → devだけ有効化、buildはwebpackが安全。
- Next.js以外のReactアプリ → Turbopackを直接使う道はまだない。RspackかViteが答え。
第4章・Rspack — ByteDance、webpack互換を武器に
**誰が** ByteDance (TikTokの親会社)。メンテナはHan、hardfistなど。
**言語** Rust。
**役割** Bundler。
**状況 (2026年5月)** v1.x stable。ByteDance社内の数千プロジェクトで使用。
コアアイデア — webpack APIの互換
Turbopackは「ゼロから書き直そう」だった。Rspackは逆だ — **webpackのAPIとプラグインシステムをほぼそのまま互換**にする。`module.rules`、`resolve`、`plugins`、`optimization` — ほとんど同じ形だ。webpackプラグインの相当数が小修正もしくは無修正で動く。
// rspack.config.js — webpack.config.jsとほぼ同じ
module.exports = {
entry: './src/index.tsx',
resolve: {
extensions: ['.tsx', '.ts', '.js'],
},
module: {
rules: [
{ test: /\.tsx?$/, use: 'builtin:swc-loader' },
],
},
plugins: [
new HtmlRspackPlugin({ template: './public/index.html' }),
],
};
この互換戦略のおかげで、ByteDance社内の巨大なwebpackプロジェクト群が**ほぼ無修正**でRspackに移行できた。ビルド時間が5〜10倍短縮されたと報告されている。
Rsbuild — Rspackの上の親切なレイヤ
Rspackはwebpackと同じく設定が煩雑だ。そこでByteDanceは**Rsbuild**という上位ツールも作った — 内部でRspackを使うが、Viteのように合理的なデフォルトと簡潔な設定を提供する。2026年現在、Rspack採用はRsbuild経由が多い。
Rsbuildはワンコマンドで開始できる
npm create rsbuild@latest my-app
誰が使うべきか
- 大きなwebpackプロジェクトを高速にマイグレーション → Rspack。
- 新規プロジェクトでwebpackスタイルが馴染む → Rsbuild。
- Next.jsを使わないReact本番アプリでビルド速度が決定的 → Rspack/Rsbuildは最も安全な選択肢のひとつ。
第5章・esbuild — Goベースの速度の基準線
**誰が** Evan Wallace (Figma共同創業者)。
**言語** Go。
**役割** Bundler + Transformer + Minifier。
**状況 (2026年5月)** v0.24+。安定。新機能より安定性に注力。
位置づけ
esbuildはこの全ての流れの**引き金**だった。2020年にwebpackビルド20秒を200msに縮めて見せたとき、業界は**「ネイティブ言語が答えだ」**という結論に至った。
2026年時点でのesbuildの位置は興味深い。**今でも最速だが、直接使うケースは減っている**。理由は次の通り。
- **機能範囲が意図的に狭い**。Evan Wallaceはesbuildを「ライブラリ兼基準線」と見ている。コード分割(code splitting)も実験的、plugin APIも意図的に制限されている。
- **他のツールが内部でesbuildを使う**。Viteはdevの事前バンドルにesbuildを使う。tsupもesbuildラッパだ。直接ではなく**裏に隠れて**ビルドチェーンの一部になる。
それでも直接使う場面
- ライブラリビルド — 小さく速くESM/CJSデュアル出力。
- 単純なCLI/スクリプトのバンドル — webpackを持ち出す理由がないとき。
- ビルドツール自体の部品 — Vite、tsup、tsdownなどがesbuildを部品として使う。
// esbuildをライブラリとして — 5行で終わる
await build({
entryPoints: ['src/index.ts'],
bundle: true,
format: 'esm',
outfile: 'dist/index.js',
external: ['react', 'react-dom'],
});
esbuildは**消えない**。ただしユーザの直接接点は減り、「他のツールの中のエンジン」になっていく。
第6章・swc — Babelを置き換えたRustトランスパイラ
**誰が** kdy1 (DongYoon Kang)。Vercelが後援、Turbopackのトランスパイラとして採用。
**言語** Rust。
**役割** Parser + Transformer + Minifier。
**状況 (2026年5月)** stable。Next.js標準のトランスパイラ。Babel比20〜70倍の速度。
何を置き換えたか
Babelは一時代を定義したツールだった。ES6をES5にダウンレベル、JSXを変換、TypeScriptのstripping。問題は速度だ。JSで書かれたAST変換は本質的に遅い。
swcは同じ仕事をRustでやる。インタフェースは似ている (`.swcrc` vs `.babelrc`、JSX/TS対応、カスタムプラグイン可能)。速度が違う。
// .swcrc — Babel設定とほぼ一対一対応
{
"jsc": {
"parser": {
"syntax": "typescript",
"tsx": true,
"decorators": false
},
"transform": {
"react": {
"runtime": "automatic"
}
},
"target": "es2022"
}
}
どこで出会うか
- Next.jsのトランスパイル段階 (全ての.tsx/.ts/.jsx)。
- Jest用のSWCトランスフォーム (`@swc/jest`) — `babel-jest`の置き換え。
- Storybook、Turborepoなど多くのVercel系ツール。
Plugin — まだ騒がしい領域
Babelのプラグインエコシステムは巨大だった。swcもplugin APIを提供するが、**RustまたはWebAssemblyで書く必要がある**。参入障壁が高く、コミュニティプラグインはBabelほど豊富ではない。2024〜2026年にswcチームがWasmベースのplugin APIを安定化させ、`@swc/plugin-emotion`などよく使われるプラグインはswc版がある。だがロングテールは依然Babelだ。
第7章・Biome — Prettier + ESLintの置き換えを狙う
**誰が** Biomeチーム (Romeプロジェクトの後継)。フルタイム開発者複数。
**言語** Rust。
**役割** Formatter + Linter (一つのツールで両方)。
**状況 (2026年5月)** v2.x。LinterはESLintルールの相当部分をカバー、FormatterはPrettierにほぼ100%互換。
背景 — RomeからBiomeへ
2020年Romeという野心的なプロジェクトがあった。Babel作者のSebastian McKenzieが「JSツールチェーン全体を一つに統合する」というビジョンで開始。Rustに転換したが2022〜2023年に資金問題で事実上停止。**BiomeはRomeのforkかつ後継だ**。名前だけでなくガバナンスと資金モデルが変わり、本当に出荷した。
中身
- **Formatter** — Prettierほぼ互換。ワンコマンドでマイグレーション可能。
- **Linter** — ESLint推奨ルールの相当部分を移植。一部のReact/TypeScript専用ルールを含む。
- **Import organizer** — `eslint-plugin-import`の置き換え。
- **速度** — Prettier比25倍以上、ESLint比10〜20倍。
一度のインストール、一度の実行
npm i -D @biomejs/biome
npx @biomejs/biome check --apply ./src
またはマイグレーション
npx @biomejs/biome migrate eslint --write
npx @biomejs/biome migrate prettier --write
限界 — まだESLintを100%置き換えられない
ESLintコミュニティのプラグインは数千個ある。`eslint-plugin-jest`、`eslint-plugin-testing-library`、`eslint-plugin-next`などフレームワーク特化が山ほど。Biomeはコアルールは速いが、**カスタムルールを書くAPIがESLintほど成熟していない**。2026年現在、多くのチームが「PrettierはBiomeに、ESLintはそのまま」のようなハイブリッドを使う。
誰が使うべきか
- 新規プロジェクト → Prettier+ESLintの代わりにBiomeでよい。
- 既存プロジェクト → Prettierは簡単に乗り換え、ESLintは一部のみ。
- モノレポのCIでlint/formatがボトルネック → 大きな効果。
第8章・oxc — 統合パーサ/リンタ/フォーマッタ、Rolldownのバックボーン
**誰が** Boshen (シンガポール出身のメンテナ)ほか。VoidZeroに合流 (2024年)。
**言語** Rust。
**役割** Parser、Linter (oxlint)、Resolver、Minifier、Transformer、Formatter (開発中)。
**状況 (2026年5月)** ParserとResolverはproduction-ready。oxlintは高速なESLint代替。Minifierはswc-minify水準に到達。Formatterはbeta。
なぜoxcが重要か
JSツールの9割は**AST**から始まる。パースが速ければその上の全てが速い。oxc (Oxidation Compiler) の目標は**「JavaScript向け最速のASTツール群を作り、その上に全てのツールを乗せる」**だ。
+--------------------------------------------------------+
| oxc core |
| +--------+ +----------+ +----------+ +-----------+ |
| | Parser | | Resolver | | Minifier | | Formatter | |
| +---+----+ +----+-----+ +----+-----+ +-----+-----+ |
| +-----------+-----------------+----------+ |
| | |
| 共通AST + 共通traversal |
+----------------------+---------------------------------+
v
+-----------------------------------+
| Rolldown / oxlint / etc |
+-----------------------------------+
**核心アイデア**: ASTを一度だけ作り、その上でlint・minify・format・transformを全部行う。swcが各々パースするのとは違う。
oxlint — ESLintの50〜100倍速い
oxcの中のlinter。名前は`oxlint`。ベンチマークではESLint比で50〜100倍速いと報告されている。
一度のインストール、一度の実行
npx oxlint@latest
package.json
{
"scripts": {
"lint": "oxlint",
"lint:check": "oxlint --deny-warnings"
}
}
ESLintコアルールの多数、`typescript-eslint`の一部、`eslint-plugin-react`、`eslint-plugin-jsx-a11y`の一部を移植している。100%互換ではないが、**CIの第一段でoxlintを走らせ、通ったものにのみESLintを走らせるハイブリッド**がよくある。
統合企業 — VoidZeroがoxcを吸収
2024年7月、Evan You (Vue作者)が**VoidZero**を起業し、oxcメンテナのBoshenを合流させた。これによりoxc・Rolldown・Viteが一つの会社の傘下にまとまった。意味は第14章で改めて取り上げる。
第9章・Rolldown — Rollupの後継、Viteの次世代バンドラ
**誰が** Evan You + Rolldownコアチーム。VoidZeroがホスト。
**言語** Rust。
**役割** Bundler (Rollup互換API)。
**状況 (2026年5月)** Beta。Vite 7でopt-in可能、Vite 8でデフォルトバンドラ予定。
Viteの現実 — 二つのバンドラを使っていた
Viteの秘密: devとbuildで**異なるバンドラ**を使っている。
- **Dev**: 事前バンドルにesbuild、それ以外はバンドルレスESM。
- **Build**: Rollup。
これが問題になったことがある — devで動いていたものがbuildで壊れる、esbuildとRollupの動作差異が微妙なバグを生む。Viteチームは以前から**「一つのRustバンドラに統一したい」**と言ってきた。それがRolldownだ。
約束していること
// rolldown.config.js — Rollup設定とほぼ同じ
export default defineConfig({
input: 'src/main.ts',
output: {
dir: 'dist',
format: 'esm',
},
plugins: [
// Rollupプラグインは(大部分)そのまま動く
],
});
- **Rollupプラグイン互換** — Rollupエコシステムの巨大資産をそのまま使える。
- **速度** — Rollup比10〜30倍、esbuildに近づく。
- **CommonJS対応** — Rollupが弱かったCJS処理をネイティブで。
- **コード分割** — esbuildの弱点をフル機能で。
誰が使うべきか
- 2026年現在、直接使うにはまだ早い。Viteを通して間接的に出会うのが普通。
- ライブラリビルドツールとしてesbuild/tsupが息苦しい現場 → betaを試す価値あり。
第10章・Farm — 浮上中の新顔
**誰が** brightwuほか。中国コミュニティが中心。
**言語** Rust。
**役割** Bundler + Dev server。
**状況 (2026年5月)** v1.x。活発な開発、採用はまだ初期。
差別化
Farmはwebpack/Vite/Rspackの隙間を埋めようとする。
- **dev速度 — Viteより速いと主張**。Rustコア + 部分バンドリング。
- **Rollupプラグイン互換** — Vite/Rolldownと類似の約束。
- **HMRが明示的に速い** — 大きなアプリでも100ms以内。
// farm.config.ts
export default defineConfig({
compilation: {
input: { index: './src/main.tsx' },
output: { path: 'dist' },
},
server: {
port: 9000,
},
});
位置づけ
機能的にはVite/Rsbuildに近い席を狙う。差別化は「Viteより速く、Rspackよりwebpack依存が少ない」。ただし2026年現在、**選ぶ強い理由はまだ弱い** — Vite/Rspackどちらも十分速くエコシステムが大きい。Farmは要観察だが、デフォルト推奨ではまだない。
第11章・Vite 6 — Environment API、マルチ環境
**誰が** Evan You、Viteコアチーム、VoidZero。
**言語** TypeScript (コアはJS、内部でesbuild/Rolldownを使用)。
**役割** Dev server + Build orchestrator。
**状況 (2026年5月)** v6 stable。v7でRolldownオプトイン。v8でRolldownデフォルト。
6の核心 — Environment API
Vite 5まで「browser向けビルド」が1級市民だった。ところが**SSR、RSC、edge、worker**といった環境が増え、一つのプロジェクトが複数のビルド出力を持つようになった。Vite 6のEnvironment APIはこれを明示化する。
// vite.config.ts
export default defineConfig({
environments: {
client: {
build: {
outDir: 'dist/client',
},
},
ssr: {
build: {
outDir: 'dist/ssr',
ssr: true,
},
},
workerd: {
build: {
outDir: 'dist/worker',
},
resolve: {
conditions: ['workerd', 'edge'],
},
},
},
});
各environmentは自身の`resolve.conditions`、自身のプラグインフィルタ、自身のモジュールグラフを持つ。フレームワークビルダ (Nuxt、SvelteKit、SolidStart)にとっては大きな武器 — 以前は各自hackyな方法でSSR/CSRを分離していたものが、今は1級API。
Viteの位置 — 事実上の標準
Viteは2020年公開以来、React/Vue/Svelte/Soldなどほぼ全フレームワークの標準devツールになった。2026年にはnpmダウンロードでViteがwebpackを抜いた。Next.jsだけが独自ビルダ (Turbopack)路線、それ以外のほぼ全てのメタフレームワークがViteの上に乗っている。
第12章・Bun — Zigベースの統合ランタイム + バンドラ
**誰が** Jarred Sumner。Oven Inc。
**言語** Zig。
**役割** Runtime + Package manager + Bundler + Test runner。
**状況 (2026年5月)** v1.x stable。Node.js互換性が大幅向上。
別種族
Bunは他のツールと同系列ではない。Bunは**Node.js置き換え**を狙う。その中にバンドラが入っているだけだ。
package manager
bun install
script runner
bun run dev
test runner
bun test
bundler
bun build src/index.ts --outdir dist
runtime
bun src/server.ts
一つのバイナリに全部入っている。`node` + `npm` + `tsc` + `webpack` + `jest`の席を一つのツールで狙う。
2026年の現実
- **package managerは本当に速い**。`bun install`が`npm install`より5〜25倍速いという報告がよくある。一部チームは**Bunをパッケージマネージャとしてのみ**使う(ランタイムはNodeのまま)。
- **Runtime互換性**が大幅に向上した。Express、Fastify、Hono、Elysiaほぼ動く。Node.js一部のnative moduleのみ問題。
- **バンドラ**はesbuildクラス。直接選ぶより、Bunプロジェクトで自然と使うことになる。
- **テストランナー**はJest API互換を狙う。`bun test`が`jest`より速いという報告多数。
誰が使うべきか
- **新規サーバサイドTSプロジェクト** → Bunを真剣に検討。特に単純なAPIサーバ。
- **モノレポのパッケージマネージャ** → Bunが答え。pnpm比でより速く、互換も十分。
- **既存の巨大Nodeプロジェクト** → 本番移行は慎重に。Native module依存度が要。
第13章・tsdown / Lightning CSS — 小さいが重要
tsdown — TypeScriptライブラリバンドラ
**誰が** Sxzz (Vite/Vueコントリビュータ)。2024年開始。
**言語** Rust (Rolldownの上に乗せたthin wrapper)。
**役割** TypeScriptライブラリバンドラ (tsupの後継)。
tsupはesbuildラッパで、esbuildの限界をそのまま継いだ (code splitting弱い、DTS生成は別で必要)。tsdownは**Rolldownの上に乗せて**これらを解消しようとする。
package.json
{
"scripts": {
"build": "tsdown"
}
}
tsdown.config.ts
export default defineConfig({
entry: ['src/index.ts'],
format: ['esm', 'cjs'],
dts: true,
});
ライブラリ作者には小さいが重要なツール。ESM/CJSデュアル出力、自動DTS生成、Rolldownベースの高速ビルド。
Lightning CSS — CSSのRustバンドラ
**誰が** Devon Govett (Parcel作者)。
**言語** Rust。
**役割** CSS parser + transformer + minifier + bundler。
postcss + cssnano + autoprefixerの席を一つのツールで狙う。CSS Modules、CSS Nesting、@layer、color-mix()などモダンCSSをダウンレベルする。
**なぜ重要か**: Tailwind CSS 4が内部エンジンをLightning CSSに切り替えた。2026年時点でTailwind v4を使う全プロジェクトが事実上Lightning CSSを使っている。
npm i -D lightningcss
単独でも使える
npx lightningcss --minify --bundle --targets '>= 0.25%' src/style.css -o dist/style.css
その他の小さなツール
- **unbuild** — UnJS陣営のライブラリビルダ。Rollupベース。
- **tshy** — Isaac Schlueter (npm作者)のTypeScriptデュアルビルダ。
- **dprint** — Rustベースのマルチ言語フォーマッタ。Biomeと競合。
- **moonrepo / nx** — ビルドツールではないがビルドオーケストレーション (Turborepoと競合)。
第14章・VoidZero — 統合企業の意味 (2024年7月)
2024年7月、Evan Youが**VoidZero**という会社を発表した。Vueエコシステムの非営利的な活動を離れ、**「JSビルドツールチェーン全体を一つの会社の下に構築する」**という野心だ。
集まった人
- **Evan You** — Vue、Vite。
- **Boshen** — oxcメンテナ。
- **Patak (Viteコア)、bluwy (Viteコア)** ほか多数。
- **Sxzz** — tsdown、Vue/Viteコントリビュータ。
Series Aは4.6M USD (Accelリード)。小さく見えるが、OSSツール会社としては十分な規模。
何を狙うか
VoidZeroの明示的ビジョン: **「RustベースのJSツールチェーン統合」**。
- **Parser/Resolver/Minifier** — oxc。
- **Bundler** — Rolldown。
- **Dev server / Build orchestrator** — Vite 7/8。
- **Linter** — oxlint。
- **Formatter** — oxc-formatter (開発中)。
- **Test runner** — Vitest (既に広く使われている)。
各ツールは独立して使えるが、**同じASTと同じtraversalを共有する**。JS時代の「各ツールが再パース」という非効率を打破する。
なぜ意味があるか
JSビルドツールは長い間、**個別メンテナの善意**に依存してきた。Babel、webpack、Rollup、Prettier — ほぼ全てが一人か二人の個人が引っ張ってきたプロジェクトだ。そのモデルは**バーンアウトと資金不足**を繰り返した (Romeはそうやって死んだ)。
VoidZeroは**会社にモデルを変える本格的な初めての試み**である。VercelがTurbopack/swcを自社プロダクトの一部として引っ張る構造に近いが、VoidZeroは**vendor-neutral**を掲げる — 特定のフレームワーク/プラットフォームに縛られない。Next.js・Nuxt・SvelteKit・SolidStart誰でも使えるように。
2026年時点で、これがうまく回るかはまだ分からない。だが**この会社が潰れなければ、向こう5年のJSビルドチェーンはVoidZeroが定義する**。Vercel/TurbopackとVoidZero/Rolldown — 二陣営の両雄体制が形成されたのが2026年の風景だ。
第15章・State of JS Tooling 2025 (Cara / Devographics)
Cara (旧Devographics)が毎年実施するState of JS Tooling調査の2025年結果が出た。要点:
- **Viteの満足度が最高**。使用86%、満足94%。
- **TurbopackとRspackの採用率が急上昇**。TurbopackはNext.jsの採用に連動、Rspackはモノレポで強い。
- **esbuildは直接使用より依存として埋め込まれるケースが多数**。満足度は依然非常に高い。
- **Bunのパッケージマネージャ利用は急上昇**。ランタイムはまだ実験中。
- **Biome採用率はESLintを抜いていないが満足度は高い**。新規プロジェクトの選択は急速にシフト。
- **webpackはまだ最も多くインストールされているが新規スタートはほぼゼロ**。レガシーに近い位置。
このデータは「Rustツール = 未来」という一般論を**数字で裏付ける**。採用は漸進的だが、新規スタートはほぼ全てがRust陣営に流れる。
第16章・誰が何を選ぶべきか — シナリオ別推奨
シナリオ1: Next.jsアプリ (新規)
- **Dev**: Turbopack (Next 15デフォルト)。
- **Build**: Next 16からTurbopackデフォルト予定。それまではwebpack。
- **トランスパイル**: swc (自動)。
- **Lint/Format**: oxlint + Biome、またはESLint+Prettier継続。
シナリオ2: Next.js以外のReactアプリ (新規)
- **バンドラ**: Vite 6、またはRsbuild。
- **devサーバ**: Vite (事実上の標準)。
- **トランスパイル**: swcまたはoxc-transformer (Viteが内部で処理)。
- **Lint/Format**: Biomeまたはoxlint+Prettier。
シナリオ3: ライブラリ (npmパッケージ)
- **バンドラ**: tsdown (Rolldownベース)またはtsup (esbuildベース、小規模ライブラリ)。
- **型**: tscでDTSのみ生成が最も安全。
- **Format**: Biome。
- **Lint**: oxlint + 必要部分のみESLint。
シナリオ4: CLIツール / 単純スクリプト
- **バンドラ**: esbuild直接、またはBun build。
- **ランタイム代替**: Bun (単一ファイル実行が強力)。
シナリオ5: 巨大webpackモノレポ (マイグレーション)
- **段階1**: Babelをswcへ (最も安全)。
- **段階2**: webpack-dev-serverをViteへ (アプリ単位で)。
- **段階3**: webpackをRspackへ (設定互換を活用)。
- **段階4**: ESLintをoxlintへ (CI第一段のみ)。
シナリオ6: バックエンドTSサービス
- **ランタイム**: Bun (単純API)、Node.js (成熟度優先)。
- **バンドラ**: tsdownまたはesbuild。
- **パッケージマネージャ**: Bun、pnpm。
- **テスト**: Vitest、bun test。
一行決定木
- **速いdevが必要?** → Vite (大部分)、Turbopack (Next)。
- **巨大webpackをそのまま?** → Rspack。
- **ライブラリ?** → tsdown。
- **lintとformatを一つで?** → Biome、またはoxlint+dprint。
- **全てを一バイナリで?** → Bun。
第17章・おわりに — 5年後の姿
2020年にesbuildが出たとき「これが始まりだ」と感じた人は多かった。2024年にVoidZeroが発足してTurbopackがNext.js 15のデフォルトになったとき、**到達点の姿が見え始めた**。
2030年のJavaScriptビルドチェーンはおそらくこんな形だ。
- **AST共通化** — oxcかswcがほぼ全てのパースを担当。
- **二つの大きな傘** — Vercel/Turbopack/swc と VoidZero/Rolldown/oxc。
- **Viteはdev標準** — Next.js以外のほぼ全メタフレームワークの土台。
- **JSで書かれたビルドツールは博物館行き** — webpack、Rollup、Prettier、ESLintの新規採用はほぼゼロ。
- **runtime/パッケージマネージャはBunが一部市場を吸収** — Nodeを完全に置き換えるわけではない。
- **CSSはLightning CSSが標準** — Tailwind v4採用と共に。
- **Lintはoxlint + 一部ESLintハイブリッドが多数**。
この絵が当たるか外れるかは分からない。**JSビルドツール史上もっとも確実なのは「5年後の風景は常に予想と違う」**ことだ。ただし一つの流れはほぼ確実 — **JSビルドツールはもうJSで書かれない**。この方向は逆戻りしない。
良い時期だ。ツールを選ぶなら**Rust陣営から選ぼう**、そして**VoidZeroとVercelの両トラックを観察し続けよう**。5年後の標準はその二つのいずれか(あるいは両方)から出てくる。
参考 / References
- Turbopack: https://turbo.build/pack
- Next.js 15リリースノート: https://nextjs.org/blog/next-15
- Rspack: https://rspack.dev
- Rsbuild: https://rsbuild.dev
- esbuild: https://esbuild.github.io
- swc: https://swc.rs
- Biome: https://biomejs.dev
- oxc (Oxidation Compiler): https://oxc.rs
- oxlint: https://oxc.rs/docs/guide/usage/linter
- Rolldown: https://rolldown.rs
- Farm: https://www.farmfe.org
- Vite: https://vitejs.dev
- Vite 6 Environment API: https://vitejs.dev/guide/api-environment
- Bun: https://bun.sh
- tsdown: https://tsdown.dev
- Lightning CSS: https://lightningcss.dev
- VoidZero発表 (2024年7月): https://voidzero.dev/posts/announcing-voidzero-inc
- State of JS Tooling 2025 (Cara/Devographics): https://stateofjs.com
- Tobias Koppers on Turbopack: https://turbo.build/blog
현재 단락 (1/365)
2010年代後半にフロントエンドをやっていた人なら一度は聞いたジョークがある。**「JavaScriptビルドツールは6か月で入れ替わる」**。Grunt、Gulp、Browserify、webpac...