LabHub

ブログ

JSビルドツールのRustの波 2026 — Turbopack / Rspack / Rolldown / oxc / Biome / Vite 6 / Bun 徹底比較

2026-05-15 · 32 分で読めます · #javascript#build-tools#turbopack#rspack#esbuild#swc#biome#oxc#rolldown#farm#vite#bun#rust#deep-dive#japanese

한국어English日本語

プロローグ — 「なぜまたビルドツールなのか」

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に縮めた。次の問いは自然だった — 「なぜ皆そうしないのか?」。

答えは二つに分かれた。

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/parserswc、oxc
TransformJSX/TS → JS、ダウンレベルBabelswc、oxc-transformer
Lint静的解析ESLintBiome、oxlint
Formatコード整形PrettierBiome、dprint
Resolveモジュールパス解決enhanced-resolveoxc-resolver
Bundleモジュールグラフ→チャンクwebpack、Rollup、ParcelTurbopack、Rspack、Rolldown、Farm
Minifyコード圧縮terser、uglify-jsswc-minify、oxc-minifier、esbuild
Dev ServerHMR/バンドルレスwebpack-dev-serverVite、Turbopack
CSS変換・最小化postcss、cssnanoLightning CSS
RuntimeJS実行Node.jsBun、Deno
Package Manager依存インストールnpm、yarn、pnpmBun、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を残す現場も多い。

誰が使うべきか

第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

誰が使うべきか

第5章・esbuild — Goベースの速度の基準線

誰が Evan Wallace (Figma共同創業者)。 言語 Go。 役割 Bundler + Transformer + Minifier。 状況 (2026年5月) v0.24+。安定。新機能より安定性に注力。

位置づけ

esbuildはこの全ての流れの引き金だった。2020年にwebpackビルド20秒を200msに縮めて見せたとき、業界は「ネイティブ言語が答えだ」という結論に至った。

2026年時点での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"
  }
}

どこで出会うか

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かつ後継だ。名前だけでなくガバナンスと資金モデルが変わり、本当に出荷した。

中身

# 一度のインストール、一度の実行
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はそのまま」のようなハイブリッドを使う。

誰が使うべきか

第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で動いていたものが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プラグインは(大部分)そのまま動く
  ],
});

誰が使うべきか

第10章・Farm — 浮上中の新顔

誰が brightwuほか。中国コミュニティが中心。 言語 Rust。 役割 Bundler + Dev server。 状況 (2026年5月) v1.x。活発な開発、採用はまだ初期。

差別化

Farmはwebpack/Vite/Rspackの隙間を埋めようとする。

// 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年の現実

誰が使うべきか

第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

その他の小さなツール

第14章・VoidZero — 統合企業の意味 (2024年7月)

2024年7月、Evan YouがVoidZeroという会社を発表した。Vueエコシステムの非営利的な活動を離れ、「JSビルドツールチェーン全体を一つの会社の下に構築する」という野心だ。

集まった人

Series Aは4.6M USD (Accelリード)。小さく見えるが、OSSツール会社としては十分な規模。

何を狙うか

VoidZeroの明示的ビジョン: 「RustベースのJSツールチェーン統合」。

各ツールは独立して使えるが、同じ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年結果が出た。要点:

このデータは「Rustツール = 未来」という一般論を数字で裏付ける。採用は漸進的だが、新規スタートはほぼ全てがRust陣営に流れる。

第16章・誰が何を選ぶべきか — シナリオ別推奨

シナリオ1: Next.jsアプリ (新規)

シナリオ2: Next.js以外のReactアプリ (新規)

シナリオ3: ライブラリ (npmパッケージ)

シナリオ4: CLIツール / 単純スクリプト

シナリオ5: 巨大webpackモノレポ (マイグレーション)

シナリオ6: バックエンドTSサービス

一行決定木

第17章・おわりに — 5年後の姿

2020年にesbuildが出たとき「これが始まりだ」と感じた人は多かった。2024年にVoidZeroが発足してTurbopackがNext.js 15のデフォルトになったとき、到達点の姿が見え始めた。

2030年のJavaScriptビルドチェーンはおそらくこんな形だ。

この絵が当たるか外れるかは分からない。JSビルドツール史上もっとも確実なのは「5年後の風景は常に予想と違う」ことだ。ただし一つの流れはほぼ確実 — JSビルドツールはもうJSで書かれない。この方向は逆戻りしない。

良い時期だ。ツールを選ぶならRust陣営から選ぼう、そしてVoidZeroとVercelの両トラックを観察し続けよう。5年後の標準はその二つのいずれか(あるいは両方)から出てくる。

参考 / References

コメント

まだコメントはありません。

ログインするとコメントできます