スタイリング

CSSのスコープ管理はフロントエンド開発における長年の課題である。グローバルなCSSはカスケーディングと詳細度（Specificity）の問題から、プロジェクトが大きくなるにつれてスタイルの意図しない干渉が起きやすくなる。この問題に対して様々なアプローチが生まれており、CSS Modules・CSS-in-JS・ユーティリティファーストCSS（Tailwind CSS）が現在の主要な選択肢となっている。

CSS Modulesはファイル単位でCSSをスコープ化し、クラス名をビルド時にハッシュ付きのユニークな名前に変換することでグローバル汚染を防ぐ。コロケーション（コンポーネントファイルの隣にCSSファイルを置く）により、コンポーネントとスタイルの対応関係が明確になる。styled-componentsやEmotionに代表されるCSS-in-JSはJavaScriptの変数やPropsをスタイルに利用できるが、ランタイムコストとキャッシュ効率の課題から、静的CSSを生成するZero Runtime CSS-in-JS（Linaria・vanilla-extract等）への移行が進んでいる。

Tailwind CSSはユーティリティクラス（flex・text-sm・p-4等）を直接HTMLに適用するアプローチで、カスタムCSSを書く必要をほぼなくし、デザインのシステム化と高い開発速度を両立する。一方でクラス名が長くなり可読性が下がる点や、複雑なアニメーションや動的スタイルへの適用が難しい点が課題となる。

コードレビューで着目するポイント

グローバルなCSSにコンポーネント固有のスタイルが混入していないか（スコープ分離が適切か）
詳細度の競合（Specificity War）が起きていないか（!importantの多用は設計上の問題を示す）
CSS Custom Properties（--color-primary等）でテーマ値が管理されており、マジックナンバーが散在していないか
CSS-in-JSを使用している場合、ランタイムのパフォーマンスコストが許容できるか（Server Componentsと組み合わせる場合は特に注意）
Tailwind CSSを使用している場合、cn()等のユーティリティで条件付きクラスが管理されているか
メディアクエリやブレイクポイントがデザインシステムの値と一致しているか
アニメーションが transform・opacity を使用しており、レイアウトを引き起こすプロパティ（width・margin等）を避けているか

典型的なアンチパターン

!important の多用: 詳細度の競合を !important で解決しようとすると、さらに高い詳細度を要求するスタイルが生まれ続け、CSSが修正不可能な状態に陥る。根本的にはセレクターの詳細度を低く保つ設計（BEMやCSS Modules等）で解決すべきである。

CSS-in-JSとServer Componentsの組み合わせ: React Server Componentsでランタイム依存のCSS-in-JS（styled-components等）を使うと、サーバー側でスタイルを計算できずクライアントで二重レンダリングが必要になる。Zero Runtime CSS-in-JSや Tailwind CSS への移行が推奨される。

グローバルスタイルでのコンポーネントスタイル定義: globals.css にコンポーネント固有のスタイルを書くと、そのスタイルがアプリ全体に影響する。コンポーネントのスタイルは必ずコンポーネントにコロケーションし、グローバルには本当にグローバルな設定（リセットCSS・フォント等）のみを置く。

参考リソース

ツール: Tailwind CSS - ユーティリティファーストCSSフレームワークの公式ドキュメントと設計思想
ツール: vanilla-extract - Zero Runtime CSS-in-JSの代表的ライブラリ（TypeScript対応）
標準: CSS Custom Properties - テーマ切り替えに使えるCSS変数の仕様
書籍: 「CSS Architecture」（Harry Roberts, ITCSS） - 大規模CSSの設計手法としてのITCSS（Inverted Triangle CSS）
ツール: PurgeCSS - 未使用CSSを除去してバンドルサイズを最小化するツール