Lighthouse CI は点数を上げない ― 「番人」と「改善ループ」を分けて考える

この記事で分かること

• Lighthouse CI の「番人（Gate）」と「改善ループ」の違い
• render-blocking の解消・color-contrast のブランド色を壊さない修正・守備範囲の広げ方、3つの実例
• 機械でやること・人が決めることの線引き

「Lighthouse で 90 点でました」の次に考えること

Lighthouse のスコアを出すこと自体は、ツールの使い方を覚えれば難しくはありません。問題はその後です。開発が続くにつれて、不要なライブラリが増え、色の修正が重なり、ページが追加される。気づいたら点数が下がっていた——そういうことは普通に起きます。

一度のスコアは写真、品質は動画です。

このサイト（teraone.site）では、Lighthouse のスコアを「気合い」ではなく仕組みで守るようにしました。この記事は、その仕組みを実際に組んだときの記録です。

まず誤解を解く：Lighthouse CI は点数を”上げない”

Lighthouse CI（lhci）は、測って・基準を割ったらビルドを止めるツールです。点数そのものを上げてはくれません。

// lighthouserc.json（抜粋）
"categories:accessibility": ["error", { "minScore": 0.9 }],
"categories:seo":           ["error", { "minScore": 0.9 }]

これは「90 点を下回ったら CI を赤くして、マージを止める」という守りの設定です。いわば番人（Gate）。点数を上げるのは、あくまで別の作業です。ここを混同すると「CI 入れたのにスコアが上がらない」と悩むことになります。

仕組みは、この 2 つの役割で組み立てます。

改善ループの 4 ステップ

点数は、次のサイクルで上がります。

1. 測る — CI 上の Chrome が全ページを実測する
2. 読む — レポートから「どの項目が何点引いているか」を抽出する
3. 直す — 該当箇所を修正する
4. 再測定 — もう一度測って、上がったか確認する

抽象論ではつまらないので、このサイトで実際に回した 3 つの修正を紹介します。

実例 1：使っていない JS を消すだけで、表示の足かせが消えた

レポートを読むと、render-blocking-resources に 905ms ブロックしている JavaScript がありました。中身を確認すると、カルーセル用ライブラリが読み込まれているのに、サイト内で一度も使われていないことが分かりました。

→ 読み込みを丸ごと削除。905ms の描画ブロックがゼロになりました。リスクなしで一番効いた改善でした。

教訓: パフォーマンスの敵は「重い処理」より、まず“載っているのに使っていないもの”。依存関係の棚卸しを先に。

実例 2：アクセシビリティを、ブランドの色を壊さずに直す

アクセシビリティの失点は、ほぼ全ページで color-contrast（文字色のコントラスト不足）でした。WCAG の基準は 4.5:1。ボタンや、淡い背景のカテゴリチップの文字色が、この基準を下回っていました。

安易に「色を全部濃くする」とブランドの世界観が壊れます。そこで採った方針が——背景の色味はそのまま、文字色だけを”一段濃いシェード”に差し替える。しかもベタ書きしていた色を変数化して、将来の再発も防ぎました。

修正した箇所（代表例）:

結果、アクセシビリティは全ページ 100 点に。見た目の印象はほぼ変えずに、です。

教訓: アクセシビリティとブランドは対立しない。「地の色」と「文字の色」を分けて考えると両立できます。

実例 3：「測れていない」は「守れていない」

最初、番人は全ページのうち 5 ページしか測っていませんでした。自動検出が主要ページを取りこぼしていたのです。取りこぼしていたのは、サービス・実績・お問い合わせ——一番見られるページでした。

→ 測定対象を明示リストに書き直し、各テンプレートを確実に測る 9 ページ体制に。

// lighthouserc.json — 明示リストに変更
"urls": [
  "http://localhost:4321/",
  "http://localhost:4321/service/",
  "http://localhost:4321/works/",
  "http://localhost:4321/blog/",
  "http://localhost:4321/contact/",
  // ... 全テンプレートを列挙
]

教訓: 品質ゲートは「何を測っていないか」を必ず確認する。測っていないページは、守られていない。

結果を「見える化」する

改善ループが回り続けるよう、CI に 2 つ足しました。

• レポートを成果物として保存 — ダウンロードしてあとから読み返せる
• スコア表を CI 画面に自動表示 — マージごとに全ページのスコアが一覧で見える

外部の公開ストレージには送らず、CI の中で完結させています。以後は、スコア表を眺めるだけで品質の現在地が分かります。

正直な話：機械で詰める所と、人が決める所

全部を自動化できたわけではありません。アクセシビリティを詰める最後の段階で、ブランドのカテゴリ配色をどこまで変えるかは、機械ではなく人が決めるべき判断でした。

カテゴリチップの配色は UI 上の情報コードを担っています。「コントラスト比を上げるためにブランドカラーを全部変えていいか」は、数値だけでは答えが出ません。今回は、背景色は温存して文字色のみを調整する方針を取りました。

良い品質自動化は、「全部を自動でやる」ことではなく、“機械で潰せる所”と”人が決める所”の線引きがはっきりしていること。番人とレポートが前者を引き受けるから、人は後者に集中できます。

このサイトの現在地（実測値・執筆時点）

数字は飾りではなく、仕組みで維持されているのがポイントです。

まとめ

• Lighthouse CI は点数を上げない。「番人（Gate）」と「改善ループ（Loop）」を分けるのが出発点
• 改善サイクルは 測る → 読む → 直す → 再測定 の 4 ステップ
• パフォーマンスはまず未使用リソースの除去から。効果がいちばん大きくリスクがほぼない
• アクセシビリティとブランドは「地の色」と「文字の色」を分ければ両立できる
• 品質ゲートは「測っていないページ」を疑う。守れていないページは必ずある

teraone では、こうした「速くて、人にも AI にも伝わる」サイトを、ヘッドレス構成のパッケージとして提供しています。→ サービス紹介