既存の共通コンポーネントに対して、呼び出し元ごとに見た目を変えたい場合は、まず variant、size、tone などの明示的なプロパティとしてコンポーネント API に取り込めないかを検討する。外部から任意の class を渡して基底スタイルを上書きする方式は一見手軽だが、CSS 詳細度や読み込み順に依存し、画面遷移や chunk 分割の条件で見た目が不安定になることがある。

判断基準

• 差分が「そのコンポーネントの正規のバリエーション」として再利用されそうなら、呼び出し元の個別 CSS ではなくコンポーネント側の API にする。
• 外部 class を許す場合でも、基底の border、radius、layout、state 表現などを丸ごと上書きさせる用途には慎重になる。これはスタイルの責務境界が崩れている兆候。
• variant 化するときは、既存の default を壊さず、差分名を用途ではなく形や意味で命名する。特定画面名ではなく、他でも使える抽象度にする。
• 一回限りの局所装飾や配置調整まで API 化するとコンポーネントが膨らむため、正規バリエーションか単なるレイアウト都合かを分ける。

なぜ

共通コンポーネントは、見た目・状態・アクセシビリティの責務を内側で保つほど安定する。呼び出し元の class 上書きに任せると、利用側は短期的に楽だが、CSS 読み込み順、詳細度、hover/disabled などの状態差分を個別に抱えることになる。API 化すると差分が型で見え、Story やテストにも載せやすく、再発防止にもなる。

検証

既存コンポーネントに外部 class を渡したくなったら、その class が何を上書きしているかを見る。基底コンポーネントの形・色・状態表現を変えているなら API 化候補。配置だけなら親側 layout の責務として残す。