序文：ブラウザを「手」で動かす時代の終焉
デベロッパーツール（DevTools）を開き、「Lighthouse」タブをクリックし、深呼吸をしながら「Analyze page load」を押す。結果が出るまで数十秒待ち、スコアに一喜一憂する——。
もしあなたが今もこのルーチンを繰り返しているなら、それはアーキテクトとして「技術的負債」を積み上げているのと同じです。手動の測定は、実行環境の差異（拡張機能の干渉、CPUの個体差、ネットワークの揺らぎ）を排除できず、再現性のない数値にチームが振り回される結果を招きます。
真のプロフェッショナルが目指すべきは、「パフォーマンスの非機能要件化」です。コードがマージされる前に、CIパイプラインの中でLighthouseが自動的に走り、閾値を下回ればビルドを落とす。この「ガードレール」を構築することこそが、ウェブアプリケーションの品質を永続的に担保する唯一の道です。
今回は、DevToolsのエンジンをCI/CDに組み込み、開発プロセスを劇的に進化させる「Lighthouse CI (LHCI)」の実践的な極意を伝授します。
—
1. なぜ「Lighthouse CI」なのか：内部メカニズムの視点
Lighthouse CIは、単にLighthouseをCLIで動かすツールではありません。背後ではChrome DevTools Protocol (CDP) を介してheadless Chromeを制御し、ネットワークスロットリングやCPUスロットリングをシミュレートしながら、統計的に有意なデータを抽出します。
手動測定との決定的な違いは、「複数回試行による中央値の採用」と「パフォーマンス予算（Performance Budgets）による自動判定」にあります。
—
2. 実戦配備：`lighthouserc.js` のベストプラクティス構成
設定はJSONよりもJavaScript形式（`.js`）を推奨します。環境変数や動的なURLリストを扱える柔軟性が、大規模プロジェクトでは不可欠だからです。
// lighthouserc.js
module.exports = {
ci: {
collect: {
// 開発サーバの起動コマンド（CI環境で自動実行）
startServerCommand: ‘npm run start’,
// アプリケーションが立ち上がるのを待機するURL
url: [‘http://localhost:3000/’],
// 測定の精度を高めるため、3回実行して中央値を採用する
numberOfRuns: 3,
settings: {
// デスクトップ版の計測設定（モバイルがデフォルトのため明示が必要な場合）
chromeFlags: ‘–no-sandbox –headless –disable-gpu’,
},
},
assert: {
// プリセットの「おすすめ設定」をベースにする
assertions: {
// カテゴリー別の最低スコア設定（0.9 = 90点）
‘categories:performance’: [‘error’, { minScore: 0.9 }],
‘categories:accessibility’: [‘warn’, { minScore: 0.9 }],
// 特定のメトリクスに「予算」を設定
// First Contentful Paintが2秒を超えたらビルドエラー
‘first-contentful-paint’: [‘error’, { maxNumericValue: 2000 }],
// 特定のDOM要素数を制限し、DOMツリーの肥大化を防ぐ
‘dom-size’: [‘error’, { maxNumericValue: 3000 }],
// 未使用のJavaScriptを削減できているか（Byte単位での制限）
‘unused-javascript’: [‘warn’, { maxLength: 100000 }],
},
},
upload: {
// 測定結果の保存先。’temporary-public-storage’ は手軽だが、
// 秘匿性の高いプロジェクトでは自前の LHCI Server 構築を推奨
target: ‘temporary-public-storage’,
},
},
};
—
3. GitHub ActionsによるCI/CD連携の完全自動化
プルリクエスト（PR）が作成されるたびにLighthouseを実行し、結果をPRのコメントとしてフィードバックするワークフローを構築します。これにより、レビュワーは「コード」だけでなく「パフォーマンスへの影響」を即座に判断できるようになります。
.github/workflows/lighthouse.yml
name: Lighthouse CI
on: [pull_request]
jobs:
lighthouse:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Use Node.js
uses: actions/setup-node@v3
with:
node-version: ’18’
cache: ‘npm’
- name: Install dependencies
run: npm ci
- name: Build project
run: npm run build
- name: Run Lighthouse CI
run: |
# LHCIのインストール（グローバルではなく、プロジェクトごとに固定するのが定石）
npm install -g @lhci/cli@0.12.x
# 実行。GITHUB_TOKENを渡すことで、PRにリッチなレポートリンクを自動投稿できる
lhci autorun
env:
LHCI_GITHUB_APP_TOKEN: ${{ secrets.GITHUB_TOKEN }}
—
4. 現場で震えるほど役立つ「DevTools」隠れTips
CI/CDを構築する一方で、ローカルでのデバッグ効率も極限まで高める必要があります。多くのエンジニアが見落としている、DevToolsの「深層機能」を紹介します。
① Command Menu (Ctrl+Shift+P / Cmd+Shift+P) の魔術
DevTools内でこのショートカットを叩き、以下のコマンドを入力してください。
- “Show Sensors”: 位置情報、加速度、そして何より「タッチイベント」のシミュレーションを即座に起動。
- “Show Request Blocking”: 特定のドメインやJSファイルをブロックした状態での挙動を確認。サードパーティ広告が重い場合の検証に最適。
- “Capture full size screenshot”: スクロールが必要な長いページも、一瞬で一枚の画像として保存。
② プロトコルレベルでの制御：Chrome DevTools Protocol (CDP)
Lighthouse CIの裏側を知るには、DevToolsの「Protocol Monitor」を有効にしてください。
- 設定（歯車アイコン）> Experiments > Protocol Monitor をオン。
- ブラウザとDevToolsがどのようなJSONメッセージ（`Network.enable`, `Page.navigate`等）をやり取りしているかが見えます。これを理解すると、PuppeteerやPlaywrightを使ったより高度な自動テストのデバッグが容易になります。
—
5. チーム開発での設定共有と品質管理
ツールを導入しても、メンバーごとに設定がバラバラでは意味がありません。
- `.vscode/extensions.json` の活用:
プロジェクトを開いた際、`Lighthouse` 拡張機能や、`ESLint` の推奨設定を自動で提案するようにします。
- Performance Budgetの合意:
「なぜPerformanceスコアが90点必要なのか」をビジネス指標（コンバージョン率や離脱率）と紐付けてドキュメント化し、`lighthouserc.js` の閾値に対するチームの納得感を作ります。
—
結論：自動化がもたらす「創造的自由」
Lighthouseの自動化は、単なる「作業の効率化」ではありません。それは、人間が「機械的なチェックから解放され、より本質的なUX設計やアーキテクチャの検討に時間を割けるようになる」ことを意味します。
CIパイプラインでLighthouseが静かに、しかし厳格にコードを監視しているという安心感。これこそが、高速で変化し続ける現代のフロントエンド開発において、チームが自信を持ってデプロイボタンを押すための「勇気」の源泉となります。
今すぐ、あなたのリポジトリに `lighthouserc.js` を追加してください。そこから、真のプロフェッショナルとしての開発体験が始まります。