はじめに：なぜ、あなたのバンドルサイズは肥大化し続けるのか
フロントエンド開発において、Webpackのビルド結果（バンドルサイズ）の肥大化は、避けて通れない実務のボトルネックだ。CI/CDパイプラインで「Webpack Bundle Analyzer」を導入し、巨大なチャンクブロックを眺めて絶望した経験を持つエンジニアは少なくないだろう。
しかし、視覚的なツールのグラフを見るだけでは、「なぜそのコードがバンドルに含まれているのか」「どのモジュールがどのPolyfillを引きずり込んでいるのか」という根本的な依存関係の深層までは分からない。
プロのテックリードが実践するアプローチは、感覚的なダイエットではない。Webpackが内部生成する「Stats（統計）データ」を完全網羅し、データドリブンに不要なトランスパイルやPolyfillを根絶することだ。本記事では、Statsデータを活用してバンドルサイズを極限まで削り取る実践的テクニックを、実務直結のコードと設定とともに解説する。
—
1. Webpack Statsデータとは何か？内部動作とデータ構造の理解
Webpackはコンパイルを完了する際、モジュールの依存関係グラフ、生成されたアセット、タイミング情報など、ビルドプロセスに関する膨大なメタデータを生成している。これが Stats（統計）データ である。
通常、このデータはメモリ上で処理され捨てられるか、標準出力に簡易的なテキストとして流されるだけだ。しかし、`–json` オプションまたはプラグインを用いることで、このデータを完全に構造化されたJSONファイルとしてファイルシステムに書き出すことができる。
なぜStatsデータ分析が不可欠なのか？
Bundle Analyzerのような視覚化ツールは「結果（どのファイルがデカいか）」を示すが、Statsデータは「原因（誰がそれをインポートしたか）」の逆引きパス（Why it’s there）を完全に保持している。特に、Babelやcore-jsが自動注入するPolyfillは、コードの深部で隠蔽されてインポートされるため、Statsのモジュールグラフを走査しなければ特定不能なケースが多い。
—
2. Statsデータの生成と可視化のベストプラクティス
まずは、マシンリーダブルなStats JSONを生成する仕組みをビルドパイプラインに組み込む。
実用的な設定ファイル：`webpack.config.js` の最適化
手動でコマンドを叩くのではなく、本番ビルド時に自動でJSONを出力させ、かつCI上でも解析できるように設定する。
const path = require(‘path’);
const { BundleAnalyzerPlugin } = require(‘webpack-bundle-analyzer’);
module.exports = {
mode: ‘production’,
entry: ‘./src/index.js’,
output: {
filename: ‘[name].[contenthash].js’,
path: path.resolve(__dirname, ‘dist’),
clean: true,
},
// 開発効率とデバッグの精度を両立させるためのソースマップ設定
devtool: ‘source-map’,
plugins: [
// 環境変数 (ANALYZE=true) が渡された時だけBundle Analyzerを起動
process.env.ANALYZE === ‘true’ && new BundleAnalyzerPlugin({
analyzerMode: ‘static’,
reportFilename: ‘bundle-report.html’,
openAnalyzer: false, // CI環境でブラウザが勝手に立ち上がらないようにする
}),
].filter(Boolean),
stats: {
// Stats JSONに含める情報を制御し、データ量を最適化しつつ必要情報を網羅
assets: true,
colors: true,
modules: true,
reasons: true, // ⚠️極めて重要：どのモジュールから依存されているかの理由を出力させる
cachedModules: false,
chunkModules: false,
},
};
コマンドラインからのStats生成
シェルから以下のコマンドを実行し、構造化されたJSONを出力する。
–jsonフラグでファイルに出力。巨大なJSONになるためリダイレクトを使用
npx webpack –profile –json=dist/stats.json
> 💡プロの知見: `–profile` フラグを付与することで、各モジュールのコンパイルにかかったミリ秒単位の時間計測データもStatsに統合される。パフォーマンスチューニングにおいても必須のフラグである。
—
3. 犯人特定：不要なPolyfillをJSONからあぶり出す技術
生成された `stats.json` は数万行〜数十万行に及ぶため、目視での解析は不可能である。ここで、Node.jsのスクリプト、またはjqコマンドを活用して「誰がcore-jsやregenerator-runtimeを引き込んでいるか」を特定する。
依存関係の逆引きスクリプト (`analyze-polyfill.js`)
プロジェクトのルートに以下のスクリプトを配置し、実行することで、Polyfillをバンドルに持ち込んでいる張本人のモジュールパスを特定する。
const fs = require(‘fs’);
// 生成したstats.jsonを同期読み込み
const stats = JSON.parse(fs.readFileSync(‘./dist/stats.json’, ‘utf8’));
console.log(‘🔍 Polyfill依存関係の解析を開始します…\n’);
// stats.modules 配列から、core-jsやregenerator-runtimeに関連するモジュールを抽出
const polyfillModules = stats.modules.filter(mod => {
const name = mod.name || ”;
return name.includes(‘core-js’) || name.includes(‘regenerator-runtime’) || name.includes(‘polyfill’);
});
if (polyfillModules.length === 0) {
console.log(‘✨ おめでとうございます！明示的なPolyfillモジュールは検知されませんでした。’);
process.exit(0);
}
polyfillModules.forEach(mod => {
console.log(`📦 ターゲットモジュール: ${mod.name}`);
console.log(` – サイズ: ${mod.size} bytes`);
console.log(‘ – 呼び出し元 (Reasons):’);
if (mod.reasons && mod.reasons.length > 0) {
mod.reasons.forEach(reason => {
// どのファイルからインポートされているかをロジカルに表示
console.log(` ↳ [${reason.type}] ${reason.moduleName || reason.userRequest}`);
});
} else {
console.log(‘ ↳ 呼び出し元の情報がありません（エントリポイントの可能性）’);
}
console.log(‘————————————————–‘);
});
このスクリプトを `node analyze-polyfill.js` で実行すると、以下のようなログが出力される。
🔍 Polyfill依存関係の解析を開始します…
📦 ターゲットモジュール: ./node_modules/core-js/modules/es.array.flat-map.js
- サイズ: 1240 bytes
- 呼び出し元 (Reasons):
↳ [cjs require] ./node_modules/some-legacy-lib/index.js
————————————————–
これで、「どのサードパーティライブラリが、どのモダンではない機能を必要としてPolyfillをねじ込んでいるか」が完全に暴かれる。
—
4. 根本解決：モダンブラウザ向けターゲット設定とBabelの最適化
犯人が分かったら、次はビルド設定の改修だ。大半のプロジェクトでバンドルサイズが膨らむ原因は、「ターゲットブラウザの指定が古すぎる（例: `defaults` のまま）」ことにある。
ターゲットを現代のブラウザ（Chrome, Safari, Firefox, Edgeの直近2世代など）に絞ることで、BabelやWebpackが自動挿入する無駄なPolyfillを劇的に削減できる。
最適化された `.babelrc` または `babel.config.js`
Babelの `useBuiltIns: ‘usage’` を採用しつつ、ターゲットを明確に定義する。
{
“presets”: [
[
“@babel/preset-env”,
{
// ターゲットブラウザを明確に定義（Browserslist仕様）
“targets”: “> 0.5%, last 2 versions, not dead, Firefox ESR”,
// コード内で実際に使用されている機能のPolyfillだけを自動検出し、自動インポートする
“useBuiltIns”: “usage”,
// core-jsのバージョンを明示指定して予期せぬ挙動を防ぐ
“corejs”: 3,
// デバッグを有効にすると、どのファイルにどのPolyfillが注入されたかビルド時に標準出力される
“debug”: true
}
]
]
}
package.json によるブラウザターゲットのグローバル共有
Webpack、Babel、Autoprefixerなど、プロジェクト全体でターゲット環境の認識を統一するため、`package.json` に `browserslist` を定義する。
{
“name”: “high-performance-frontend”,
“version”: “1.0.0”,
“browserslist”: {
“production”: [
“>0.2%”,
“not dead”,
“not op_mini all”,
“iOS >= 13”,
“Safari >= 13”
],
“development”: [
“last 1 chrome version”,
“last 1 firefox version”,
“last 1 safari version”
]
}
}
> ⚠️実務の注意点: iOS 13未満や古いAndroid標準ブラウザのサポートを切り捨てる合意がチームおよびビジネスサイドと取れていることが前提となる。このターゲット見直しだけで、Polyfill起因のバンドルサイズが 30%〜50%削減 されるケースはざらにある。
—
5. チーム開発でこの最適状態を維持する仕組み化（CI/CD連携）
個人のローカル環境でどれだけバンドルサイズを削っても、他のメンバーがレガシーなインポートを追加したり、設定を誤ったりすれば、数週間でコードベースは元の肥大化した状態に逆戻りする。
これを防ぐため、CI/CDパイプライン（GitHub Actions等）でStatsデータを監視し、バンドルサイズや不要なPolyfillの混入を自動検知してビルドを落とす仕組みを構築する。
GitHub Actionsワークフローの設定例 (`.github/workflows/bundle-check.yml`)
name: Bundle Size & Polyfill Guard
on:
pull_request:
branches: [ main, develop ]
jobs:
analyze:
runs-on: ubuntu-latest
steps:
- name: プレフィックスチェックアウト
uses: actions/checkout@v4
- name: Node.jsのセットアップ
uses: actions/setup-node@v4
with:
node-version: ’20’
cache: ‘npm’
- name: 依存関係のインストール
run: npm ci
- name: プロダクションビルド（Stats生成）
run: npx webpack –profile –json=dist/stats.json
env:
NODE_ENV: production
- name: Polyfill監査スクリプトの実行
run: node analyze-polyfill.js
# スクリプト内で許容できないPolyfillやサイズ超過があった場合に非ゼロ終了コードで落とす設計にする
この自動化により、レビュアーが「このPR、なんかバンドルサイズ増えてない？」と人力で疑う必要がなくなり、機械的に品質が担保される。
—
おわりに：データ駆動型フロントエンドエンジニアへ
「なんとなくライブラリを入れ替え、なんとなくバンドルサイズが減った」という開発手法から脱却せよ。WebpackのStatsデータは、あなたのアプリケーションの解剖図そのものである。
どのモジュールが誰に呼ばれ、どのPolyfillがどの環境のために動いているのか。そのすべてがJSONという冷徹なデータの中に記されている。このデータを読み解き、支配するスキルこそが、シニア・テックリードと一般エンジニアを分かつ決定的な境界線となる。
今日のビルドから、あなたのプロジェクトの `stats.json` を出力し、隠れた無駄を根絶しよう。フロントエンドのパフォーマンス最適化の扉は、そこから開かれる。