【テクニカル・上級編】【比較】Vite vs esbuild vs Rollup：ビルドツールそれぞれの「得意分野」を見極める – ビルド・パッケージ管理ツール生産性向上バイブル

ビルドの深淵：Vite, esbuild, Rollup を「解体」し、CI/CDパイプラインを最適化する

フロントエンド開発の現場において、「とりあえずViteを使えば速い」という認識は、もはやエンジニアとしての思考停止を意味する。真のアーキテクトは、ビルドツールが内部でどのような抽象化レイヤーを構築し、どの瞬間にCPUとメモリを消費しているかを完全に把握している。

本稿では、Vite/esbuild/Rollupの「得意分野」の裏側にあるアーキテクチャを紐解き、CI/CD環境においてビルド時間を極限まで削り出すための戦略を解説する。

—

1. 内部構造の再定義：なぜ「役割」を分離するのか

多くの開発者はこれらを単なる「ビルドツール」と一括りにするが、その実体は全く異なる。

esbuild (The Engine): Go言語で記述された、圧倒的速度を誇るトランスパイラ/バンドラ。AST（抽象構文樹）の走査を並列化し、メモリレイアウトを最適化することで、他ツールが数秒かかるタスクをミリ秒で終える。しかし、プラグインエコシステムや複雑なコード分割（Code Splitting）の制御においてRollupほどの柔軟性はない。
Rollup (The Architect): ES Modulesの強みを最大限に活かすモジュールバンドラ。ツリーシェイキング（不要なコードの削除）のアルゴリズムは現在でも最高峰であり、ライブラリ開発やプロダクションビルドにおける「最終的な配布物の品質」を決定づける。
Vite (The Orchestrator): 開発時にはesbuildの超高速なESM変換を使い、本番ビルドにはRollupの緻密な最適化を使う、という「いいとこ取り」を自動化するメタフレームワーク。

アーキテクトの視点:
開発環境では「即時フィードバック」が正義であり、プロダクションでは「実行時のロード時間とバンドルサイズ」が正義である。この二律背反を、Viteは「開発環境用サーバー」と「ビルドエンジン」を切り替えることで解決している。

—

2. CI/CDパイプラインにおける最適化ハック

Dockerコンテナ上でビルドを実行する際、多くのエンジニアが「ビルドキャッシュの使い捨て」という初歩的なミスで時間を浪費している。

Dockerマルチステージビルドの最適化

単に `npm install` を走らせるのではなく、`esbuild` の特性を活かしたキャッシュ戦略を組むべきだ。

ステージ1: 依存関係の解決とビルド
FROM node:20-alpine AS builder

corepackを有効化し、pnpmのバージョンを固定（一貫性の担保）
RUN corepack enable && corepack prepare pnpm@latest –activate

WORKDIR /app
COPY package.json pnpm-lock.yaml ./
RUN pnpm install –frozen-lockfile

ソースコードをコピーし、ビルド実行
COPY . .
esbuildのキャッシュをNode_modules内に持たせ、Dockerレイヤーで保持する
RUN pnpm build

ステージ2: 軽量な配信サーバー（Nginx等）
FROM nginx:alpine
COPY –from=builder /app/dist /usr/share/nginx/html

知見: CI環境で `pnpm` を使う最大の利点は、シンボリックリンクによる `node_modules` の共有にある。これにより、ビルド間のIOオーバーヘッドを極限まで削減できる。

—

3. esbuildプラグインでビルドプロセスをハックする

デフォルトのビルドプロセスで満足してはならない。例えば、CI/CDパイプラインにおいて「特定の環境変数による動的なコード注入」や「アセットの自動最適化」をビルド時に埋め込む必要がある場合、RollupのプラグインAPIを叩くのが定石だ。

以下は、ビルドの最終段階で「Gitのハッシュとビルドタイム」をメタデータとして注入するカスタムプラグインの例である。

// vite.config.ts
import { defineConfig } from ‘vite’;
import { execSync } from ‘child_process’;

export default defineConfig({
plugins: [{
name: ‘inject-build-info’,
buildStart() {
// ビルド開始時にGitのHEADハッシュを取得し、プロセス環境に埋め込む
const hash = execSync(‘git rev-parse –short HEAD’).toString().trim();
process.env.VITE_BUILD_HASH = hash;
}
}],
build: {
// プロダクションではesbuildのminifyに加え、Rollupのterserで徹底的に圧縮する
minify: ‘terser’,
terserOptions: {
compress: { drop_console: true } // 本番環境でのコンソール出力を強制排除
}
}
});

—

4. なぜ「大規模アプリケーション」でビルドが破綻するのか

プロジェクトが巨大化すると、Vite/Rollupが単一のメインスレッドでメモリを枯渇させる現象（OOM: Out of Memory）が発生する。これを解決するには、ツールの限界を理解した「分割戦略」が不可欠だ。

1. Dependency Pre-bundlingの制御:
Viteは初回起動時に `node_modules` を `esbuild` で事前バンドルする。数千のライブラリがある場合、`optimizeDeps.include` で事前に明示することで、再起動時のオーバーヘッドをゼロにできる。
2. Workersの活用:
重たい変換処理（CSS-in-JSのパース等）は、メインのビルドパイプラインから分離し、`worker_threads` を活用する独自スクリプトをCI側に用意する。

アーキテクトからの提言

「何でもかんでも一つのビルド設定で完結させようとしないこと」。
マイクロフロントエンドアーキテクチャを採用し、ビルドプロセスを並列化する。モノレポ環境であれば、`Turborepo` や `Nx` を用いて「変更があった箇所だけを、最適なツール（esbuildかRollupか）でビルドする」のが、現在到達しうる最高効率のビルドパイプラインである。

—

結論

Viteは魔法の杖ではない。それは、esbuildの「速さ」とRollupの「精密さ」を統合するための「指揮官」だ。

あなたがDevOpsエンジニアとして次にやるべきことは、「ビルド時間の計測（`vite-plugin-inspect`等を使用）」から始め、ボトルネックが「ネットワークIOにあるのか」「ASTの変換にあるのか」「メモリの圧迫にあるのか」を特定することだ。

ツールに振り回されるな。ツールの設計思想を理解し、その上を歩け。そうすれば、ビルド時間は単なる待ち時間ではなく、最適化という名のエンジニアリングの舞台へと変わる。