実行時の「死」を可視化せよ：Chrome DevTools CoverageをCI/CDの刃に変える極致
大規模Webアプリケーションにおける「肥大化」は、技術的負債の最も静かで致命的な形態だ。数MBに及ぶJSバンドルは、単に転送時間を食い潰すだけでなく、ブラウザのメインスレッドを占有し、V8エンジンのJITコンパイルコストを増大させ、初期表示（LCP）を崩壊させる。
多くのエンジニアがLighthouseのスコアに一喜一憂する中、真のアーキテクトは「実際に実行されたコードと、ロードされたコードの乖離」に目を向ける。DevToolsの「Coverage」パネルは、単なるデバッグツールではない。それは、君のアプリケーションの生存圏を特定するスキャナーだ。
今日は、このCoverageの出力を自動化し、CI/CDパイプラインに組み込んで「デッドコードの混入を許さない」強固な品質ゲートを構築する方法を伝授する。
—
1. Coverageパネルの本質：V8の実行トレースをどう解釈するか
Coverageパネルが示す「Red Bar（未使用領域）」は、単に「ロードされたが実行されなかった」という事実だけを語るのではない。それは、「ブラウザがパースし、メモリに展開し、実行コンテキストを準備したにもかかわらず、一度も触れられなかったリソース」の墓標だ。
大規模アプリでこれが起きる根本原因は、「静的な依存関係解決」と「動的な実行経路」のミスマッチにある。webpackやViteのツリーシェイキングが及ばない、動的インポートの管理不全や、条件分岐の奥底に眠る巨大なライブラリが、この「死んだコード」の主犯だ。
—
2. 自動化の核心：Puppeteerによる「実行時カバレッジ」の抽出
UI上の手動操作でCoverageを計測するのは、趣味の領域だ。我々が求めるのは、特定のユーザーフローにおける真のコード使用率を、CI環境で正確に抽出する自動化スクリプトだ。
以下のコードは、Puppeteerを使い、指定したURLにアクセスしてカバレッジデータをJSONとして吐き出すアーキテクチャの雛形である。
// coverage-collector.js
const puppeteer = require(‘puppeteer’);
const fs = require(‘fs’);
(async () => {
const browser = await puppeteer.launch({ headless: “new” }); // 新しいヘッドレスモードでリソース消費を抑制
const page = await browser.newPage();
// JavaScriptとCSSの両方のカバレッジ収集を有効化
await Promise.all([
page.coverage.startJSCoverage(),
page.coverage.startCSSCoverage()
]);
// アプリのクリティカルパスをナビゲート（この操作がカバレッジ精度の肝となる）
await page.goto(‘https://your-app.example.com’, { waitUntil: ‘networkidle0’ });
await page.click(‘#login-button’); // ユーザー体験をエミュレート
const [jsCoverage, cssCoverage] = await Promise.all([
page.coverage.stopJSCoverage(),
page.coverage.stopCSSCoverage()
]);
// データを統合し、各ファイルの未使用バイト数を計算
const report = […jsCoverage, …cssCoverage].map(entry => {
const unusedBytes = entry.ranges.reduce((acc, range) => acc + (range.end – range.start), 0);
return { url: entry.url, unusedBytes, totalBytes: entry.text.length };
});
fs.writeFileSync(‘coverage-report.json’, JSON.stringify(report, null, 2));
await browser.close();
})();
—
3. CI/CDパイプラインへの統合：品質ゲートの構築
収集したデータをただ眺めるのは無意味だ。CI上で「未使用率が一定の閾値を超えたらビルドを落とす」という品質ゲート（Quality Gate）を設けることで、初めてコードの腐敗を食い止められる。
GitHub Actionsでの構築例
.github/workflows/perf-gate.yml
jobs:
coverage-check:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Run Coverage Collector
run: node coverage-collector.js
- name: Assert Coverage Threshold
run: |
# 未使用バイト数の合計が500KBを超えたらアラートを出す簡易バリデータ
python3 -c “import json; data = json.load(open(‘coverage-report.json’));
total_unused = sum(d[‘unusedBytes’] for d in data);
print(f’Total Unused: {total_unused}’);
exit(1 if total_unused > 500000 else 0)”
—
4. 現場のアーキテクトが教える「さらなる最適化ハック」
このプロセスを導入すると、必ず「なぜこのライブラリがロードされているのか？」という疑問に突き当たる。その時、以下の視点で深掘りせよ。
1. Code Splittingの粒度検証:
特定の巨大なコンポーネントが、初期ロード時に含まれていないか？ Coverageデータを見て、未使用率が100%に近いJSファイルがあれば、それは`React.lazy`や`dynamic import()`による遅延読み込みの候補だ。
2. サードパーティスクリプトの断罪:
トラッキングツールや広告SDKが、実はほとんど実行されていないのに、メインスレッドの貴重なリソースを奪っていないか？ カバレッジ結果は、マーケティング担当者に対して「このツールはコストに見合わない」とデータで突きつけるための最強の武器になる。
3. ソースマップとのマッピング:
収集したカバレッジデータとソースマップを突合させれば、どの「関数」や「クラス」が未使用なのかを、コードレベルで特定できる。これはリファクタリングの優先順位を決定する際、感情ではなくデータに基づいた意思決定を可能にする。
結びに：真のパフォーマンスとは
パフォーマンスチューニングとは、速いコードを書くことではない。「必要のないコードをいかにして生存させないか」という引き算の芸術だ。
ブラウザの内部挙動を理解し、CI/CDでその実行を監視する。このサイクルを確立した君のアプリケーションは、もはや「肥大化」という病に蝕まれることはないだろう。今日から、君のパイプラインに「静かなる監視者」を組み込み、その効果を数字で証明して見せよ。