バンドラ

概要

バンドラは、開発時に小さなファイル（モジュール）へ分割して書かれた JavaScript や CSS を、import の依存関係をたどって解決し、配信に適した少数のファイルへ「束ねる（bundle）」ビルドツールです。webpack・Rollup・esbuild・Vite（内部で Rollup / esbuild を使用）などが代表で、モダンフロントエンド開発では意識せずとも必ずどこかで動いている裏方です。

役割は単に結合するだけではありません。使われていないコードの除去（ツリーシェイキング）、変数名の短縮や空白除去（ミニファイ）、ページごとにファイルを分けて必要な分だけ読み込ませる（コード分割）、画像やフォントまで含めた依存の一元管理 — 「開発しやすい形」と「配信に最適な形」のあいだの変換を一手に引き受けるのがバンドラです。多くの場合、トランスパイルもこのビルドパイプラインの中で一緒に実行されます。

なぜ生まれたか

バンドラ以前の Web 開発では、HTML に <script src="..."> タグを手で並べるのが唯一の方法でした。ファイル間の依存はタグの「並び順」でしか表現できず、順番を間違えれば未定義エラー。すべての変数はグローバル空間を共有するため、ライブラリ同士が同名の変数を上書きし合う「グローバル汚染」が日常茶飯事でした。アプリが大きくなるほど、どのスクリプトが何に依存しているのか誰にも分からなくなる — いわゆる依存地獄です。

この問題への答えが「モジュールシステム」でした。ファイルごとにスコープを閉じ、依存を import / export で明示的に宣言する。Node.js の CommonJS（2009年）がサーバ側でこれを実現し、ブラウザでも同じように書きたいという要求が高まります。しかし当時のブラウザはモジュールを解釈できず、しかも HTTP/1.1 では接続数の制限から、数百の小さなファイルを個別に取得するのは非常に低速でした。そこで「開発時はモジュールで書き、配信前に依存グラフを解決して少数のファイルへ束ねる」という変換工程が生まれ、Browserify（2011年）や webpack（2012年）がこれを担うツール、すなわちバンドラとして定着しました。

詳細

依存グラフの解決と束ね直し

バンドラの動作の核心は、エントリポイント（起点となるファイル）から import 文をたどって依存グラフを構築することです。グラフが分かれば、どのモジュールが実際に使われているかが分かり、正しい順序でひとつのファイルに連結できます。JavaScript だけでなく、CSS・画像・フォントなども「モジュールの一種」として同じグラフに組み込み、ハッシュ付きファイル名の付与（キャッシュを長期間効かせつつ、更新時は確実に新ファイルを取得させるための仕組み）まで含めて面倒をみるのが現代のバンドラです。

束ねる以上の最適化

依存グラフを持っていることは、強力な最適化の土台になります。ツリーシェイキングは、export されていても実際には import されていないコードを最終出力から落とす仕組みで、巨大なユーティリティライブラリから使う関数だけを配信できます。コード分割は逆方向の最適化で、SPA のように画面数が多いアプリで「最初のページに要らないコードは別チャンクに分け、遷移時に遅延読み込みする」ことで初回表示を速くします。動的 import() を書くだけで分割点になるのが現代の標準的な使い方です。ミニファイと合わせ、これらはすべて「ネットワークに流すバイト数と、ブラウザが解析・実行するコード量を減らす」という一点に向かっています。

webpack から Vite へ — 開発体験の世代交代

webpack は「あらゆるアセットをモジュールとして扱う」思想で長らく標準の座にありましたが、弱点は開発時の速度でした。1行直すたびにバンドルを作り直す方式は、プロジェクトが巨大化すると起動に数十秒〜数分かかることもあります。Vite（2020年）はここを発想から変えました。現代のブラウザはネイティブに ES Modules（ブラウザ標準のモジュール機構）を解釈できるため、開発時はバンドルせず、ブラウザが要求したファイルだけをその場で変換して返します。起動はほぼ一瞬で、変更の反映もファイル単位です。一方、本番ビルドでは従来どおり Rollup でバンドルします。ブラウザ間の差異の吸収や配信最適化には、依然として束ねる工程が有利だからです。「開発は無変換 ESM で速く、本番はバンドルで堅く」という二段構えが現在の主流になりました。

HTTP/2 時代に「束ねる意味」はどう変わったか

バンドラ誕生の動機のひとつは HTTP/1.1 の接続数制限でしたが、HTTP/2 では1本の接続で多数のファイルを並行取得できるため、「リクエスト数を減らすために束ねる」という理由は薄れました。それでもバンドルが消えないのは、理由が置き換わったからです。ツリーシェイキングやミニファイはファイルを横断して初めて最大の効果を発揮しますし、数千モジュールをそのまま配信すると、リクエストのオーバーヘッドや依存を順にたどる際の遅延（ウォーターフォール）が積み重なります。つまり現代のバンドルは「接続の節約」ではなく「配信するコード全体の最適化」のための工程です。何をどこまで束ね、どこで分割するか — その塩梅の設計こそが、バンドラを使いこなす実務の中心になっています。