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つが同時に起きた。

アプリが大きくなった。5万モジュールのモノレポが普通になった。1回のビルドに5分、devサーバ起動に30秒。
CI/CDが常態化した。PR毎にビルド/テスト/リントが走り、シングルスレッドのJSツールがボトルネックになった。
タイトなフィードバックループへの依存度が上がった。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行で終わる
import { build } from 'esbuild';
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設定とほぼ同じ
import { defineConfig } from 'rolldown';

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
import { defineConfig } from '@farmfe/core';

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
import { defineConfig } from 'vite';

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
import { defineConfig } from 'tsdown';

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