複雑化したCSSを整理して画面改修を速くする方法
「このボタンの色を変えたら、別のページのボタンまで変わった」「!importantを付けないと自分の書いたCSSが効かない」——数年運用しているプロダクトのCSSを触っていると、こうした事故がよく起きます。1つのスタイル変更のために、影響範囲を全ページ手動確認する羽目になっている現場も少なくありません。
この記事では、CSSが継ぎ足しで肥大化して改修が壊れやすくなる典型的な問題を整理し、いきなり全面刷新せずに安全にほどいていく進め方を、発注者向けに解説します。
なぜCSSは他のコードより厄介なのか
CSSには「グローバルスコープ」と「詳細度」という、JavaScriptにはない特有の性質があります。どこで書いたセレクタも基本的に全ページに効き、複数のルールが同じ要素に競合したときは詳細度(セレクタの強さ)とファイル内の記述順で最終的な見た目が決まります。
型もコンパイルエラーもないため、書いた瞬間は「動いているように見える」のに、半年後に別の担当者が別の画面を触った瞬間に壊れる、という遅延爆弾になりやすいのが特徴です。バグの原因が「そもそもどのCSSが効いているか分からない」ため、調査コストがJSのバグより高くつくケースも多く見ます。
よくある症状: 心当たりがあれば黄色信号
以下のうち3つ以上に当てはまれば、CSSの整理を検討すべきタイミングです。
!importantが多用されている: 既存のスタイルに勝てないため、力業で上書きしている。1箇所に付けると他の箇所も対抗して付け始め、際限なく増えていく- セレクタの詳細度が高騰している:
.header .nav ul li a.activeのような長いセレクタが乱立し、上書きするにはさらに長いセレクタを書くしかない状態 - 使われていないCSSが大量に残っている: 過去に消したHTML/コンポーネントのスタイルが残存し、ファイルサイズだけが増え続けている。誰も消せない(消して何が壊れるか分からない)ため放置される
- クラス名の命名に一貫性がない:
.btn、.button-primary、.p-button、.Buttonのように命名規則が混在し、新規メンバーがどれに合わせればいいか分からない - グローバルなタグセレクタ・IDセレクタが多い:
button { }や#content p { }のように広い範囲に効くセレクタがあり、新しく追加した要素が意図せずスタイルを継承する - CSSファイルが肥大化している: 1ファイルが数千行を超え、エディタでの検索・編集自体が重くなっている
- どのCSSファイルが読み込まれているか把握できていない: ビルド設定や読み込み順が複雑化し、「変更したのに反映されない」原因調査に毎回時間がかかる
これらは個別のバグではなく、スコープと詳細度の管理が破綻した結果としての症状です。1箇所直しても構造が同じなら別の場所で再発します。
問題の本質: 詳細度の戦争と使われないCSSの2つ
症状は多岐にわたりますが、根本原因は大きく2つに集約されます。
1. 詳細度の戦争 — 新しいスタイルを既存のスタイルより優先させたいとき、本来は「後から読み込む」か「同じ強さで書く」べきところを、セレクタを長くする・!important を付けるという力業で解決してしまう。これが積み重なると、次に触る人はさらに強い武器(もっと長いセレクタ、もっと!important)を使わざるを得なくなり、エスカレーションが止まらなくなります。
2. 使われないCSSの滞留 — HTML側で要素やクラスを削除しても、対応するCSSは「消して何か壊れたら怖い」という理由で残されがちです。CSSは静的解析だけでは「本当に使われていないか」を断定しにくい(JSで動的にクラス名を組み立てるケースがあるため)ため、消す判断自体にコストがかかり、先送りされ続けます。
この2つが組み合わさると、CSSの総量は増え続けるのに、実際に意図通り機能している行数の割合は減っていくという状態になります。改修のたびに「どこに書けば効くか」「消して大丈夫か」の調査時間が増え、画面改修のリードタイムが伸びていきます。
整理の進め方: いきなり全部やらない
Reactのリファクタリングと同様、CSSの整理でも「一度作り直したほうが早い」という判断は基本的にお勧めしません。全ページのビジュアルリグレッション(見た目が変わっていないことの確認)を人力でやり切るのは現実的でなく、途中で止めると中途半端な二重管理状態が一番長く残るリスクがあります。私たちが基本方針とするのは、段階的な整理です。
- 使用状況の可視化: まず「どのCSSがどこで効いているか」を機械的に洗い出します。ブラウザのカバレッジ機能(Chrome DevTools の Coverage タブ)で実ページ巡回時に使われたCSSルールを記録する、あるいは静的解析ツール(PurgeCSS等)でHTML/コンポーネントとの突き合わせを行う方法があります。動的にクラス名を組み立てている箇所は誤検知しやすいため、消す前に必ず目視確認を挟みます。
- 影響範囲の大きいセレクタから着手: グローバルなタグセレクタ・IDセレクタ・詳細度の高いセレクタなど、「どこに影響するか予測しづらいもの」を優先的に洗い出し、影響範囲をコンポーネント単位にスコープダウンします。
- 安全網としてのビジュアルリグレッションテスト: 整理対象の画面から、変更前後のスクリーンショット差分を機械比較できる状態を作ります(Percy・reg-suit・Playwrightのスクリーンショット比較など)。「見た目が変わっていないこと」を目視だけに頼らず確認できることが、この作業全体の心理的ハードルを下げます。
- 段階的な書き換え: 安全網を敷いた範囲から、コンポーネント単位でスコープを閉じたCSSに置き換えていきます。全ページを一気に着手せず、変更頻度が高い画面・バグが集中している画面から優先します。
- 使われないCSSの削除: 可視化の結果と目視確認をもとに、確実に未使用と判断できたものから削除します。「念のため残す」を積み重ねると結局元に戻るため、削除の判断基準(例: カバレッジ計測を2週間、対象ページを主要導線+管理画面まで含めて実施し未使用と確認)を事前に決めておくのがポイントです。
設計手法をどう選ぶか: BEM / CSS Modules / Tailwind
整理の過程で「今後どう書くか」のルールを決める必要があります。3つの代表的な選択肢と、判断の分かれ道は以下の通りです。
- BEM(命名規則によるスコープ管理):
.block__element--modifierという命名規則でスコープを疑似的に作る手法。ビルドツールの変更が不要で、既存のCSS/Sassをそのまま活かしながら段階移行しやすいのが利点です。ただし命名規則はチームの規律に依存するため、レビューで徹底しないと元の混沌に戻りやすい。既存の技術スタックを大きく変えたくない、Sassをそのまま使い続けたい場合に向く。 - CSS Modules: ビルド時にクラス名を自動的にユニーク化し、スコープ漏れを構造的に防ぐ手法。React/Vueのコンポーネント単位の構成と相性がよく、詳細度の戦争がほぼ起きなくなります。導入にはビルド設定の変更が必要で、既存のグローバルCSSと共存させる移行期間の設計が要ります。コンポーネント志向のフロントエンド(React/Next.js等)を採用しており、スコープ漏れを構造的に防ぎたい場合に向く。
- Tailwind CSS: ユーティリティクラスの組み合わせでスタイリングし、独自クラス・詳細度の概念自体をほぼ排除する手法。「CSSファイルが際限なく増える」問題そのものを解消できますが、既存のCSS資産をユーティリティクラスへ書き換える移行コストが大きく、HTMLが長くなることへのチーム内の合意も必要です。新規画面から先行導入し、既存画面は段階的に置き換える運用が現実的。
どれか1つが常に正解というわけではなく、技術スタック・チームの規模・移行コストの許容度で決めます。判断に迷う場合は、まず新規開発箇所だけに新しい設計手法を適用し、既存箇所はBEM等の低コストな整理から始めるのが、リスクを抑えた進め方です。
外注時に確認すべきこと
CSSの整理を外部に依頼する際は、以下を確認してください。
- ビジュアルリグレッションの確認方法を説明できるか: 「目視で確認します」ではなく、機械的な差分検出の仕組みを持っているか
- いきなり全ページの書き換えを提案してこないか: 段階的な進め方と優先順位の付け方を説明できるか
- 削除の判断基準を明確にできるか: 「念のため残す」を連発せず、未使用と確認できる条件を事前に合意できるか
- 今後の運用ルールまで含めて提案してくるか: 整理して終わりではなく、再び混沌に戻らないための命名規則・レビュー観点まで提示してくるか
こうした「今動いているものに後から手を入れる」観点は、CSSに限らずReactのフロントエンド全体のリファクタリングでも共通します。詳しくはReactリファクタリングを外注すべき症状と進め方で解説しています。また、そもそも既存プロダクトのどこから着手すべきかを見極める観点は既存プロダクトの改善、外部チームが最初に見る観点にまとめていますので、あわせてご覧ください。
まとめ
- CSSの改修が壊れやすい原因は「詳細度の戦争」と「使われないCSSの滞留」の2つに集約される。個別の症状に対症療法を続けても、構造が同じなら再発する
- 全面刷新はせず、使用状況の可視化とビジュアルリグレッションという安全網を先に敷いたうえで、影響範囲の大きいセレクタ・変更頻度の高い画面から段階的に整理する
- BEM/CSS Modules/Tailwindのどれを選ぶかは技術スタックとチームの移行コスト許容度次第。新規箇所から先行導入し、既存箇所は低コストな整理から始めるのが現実的
torcheees では React / Next.js を中心に、CSSの詳細度の戦争や肥大化したスタイルシートの段階的な整理を手がけています。既存プロダクトの現状を無料〜有償の診断で洗い出し、そこから継続的な改善支援へつなげることも可能です。詳しくはモダナイゼーションのサービスページ、またはお気軽にお問い合わせください。