本記事について
当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「フロントエンドアーキテクチャ」カテゴリ第5弾として、CSS設計について解説する記事です。
CSSは書くのは簡単だが大規模化で必ず崩壊する言語です。本記事ではCSS記述方式（Tailwind／CSS Modules／CSS-in-JS）の比較、デザインシステムとDesign Token、アクセシビリティ、AI時代の「Tailwind+shadcn/ui+Design Token」三点セットまで解説します。
本記事のテーマについてさらに詳しく知りたい方は『データ視覚化のデザイン』も参考にしてみてください。
この記事の結論
- CSSはTailwindに寄せる
- Design Tokenを最初から入れる（カラーコード直書きは未来への借金）
- CSS-in-JS（styled-components）の新規採用は避ける
- アクセシビリティはaxe-core+LighthouseでCI強制する
この記事を読む前に
本記事はブラウザ側（画面側）の仕組みの話が中心です。IT用語にあまり馴染みがない方は、基礎編の「Webサービスが動く仕組み」と「プログラムとAPIの基本」を先に読んでおくと格段に分かりやすくなると思います。また、読んでいて分からない用語が出てきたときは用語集で調べながら読み進められます。
そもそもCSS設計とは何か
CSS設計とは、ざっくり言えば「Webページの見た目を定義するCSSを、チームで安全に管理し続けるためのルールを決めること」です。
洋服の収納を想像してください。1人暮らしなら引き出しに適当に入れても困りません。しかし家族が増えると、誰かがTシャツの引き出しにコートを詰め込み、別の誰かが自分の服が見つからず新しく買ってしまう──CSS設計もこれと同じで、小規模なら問題ないグローバルなスタイル定義が、大規模化すると名前の衝突・意図しない上書き・不要スタイルの山積みという崩壊を起こします。
なぜCSS設計が重要なのか
もしCSS設計なしで大規模開発したらどうなるか。名前衝突と !important の詳細度バトルが積み重なり、「修正が怖くて触れないコード」になります。スタイル変更の影響範囲を限定し、デザイナーと開発者の共通言語を作るのがCSS設計の目的です。「機能しているか」だけでなく「将来も安全に修正できるか」が品質の決め手で、規約と自動化で秩序を保つ必要があります。
主なCSS記述方式
| 方式 | 例 | 向くケース |
|---|---|---|
| グローバルCSS | 素のCSSファイル | 小規模・個人ブログ |
| CSS Modules | styles.module.css | 既存アプリへの段階導入 |
| CSS-in-JS | styled-components / Emotion | 動的スタイル多用の既存SPA |
| ユーティリティCSS | Tailwind CSS | 新規SPA・チーム開発全般 |
| ゼロランタイムCSS-in-JS | Vanilla Extract / Panda CSS | RSC環境・型安全重視の大規模 |
Tailwind ― 現代の最大潮流
px-4 py-2 rounded bg-indigo-600 のようにユーティリティクラスをHTMLに並べる方式です。「HTMLが汚い」と言われがちですが、デザインシステムの値（色・間隔・フォントサイズ）が強制されるため、大規模チームで視覚的一貫性を自然に保てるのが最大の利点です。ファイルの行き来が不要で、ビルド時に未使用CSSが削除され軽量。新規プロジェクトの第一候補です。
CSS Modules ― 素のCSSに近い安全策
ファイルごとにクラス名を自動ローカライズする仕組みで、ビルド時にハッシュ化されてグローバル衝突が起きません。シンプル・学習コスト低・ランタイム負荷ゼロで、「素のCSSに近い書き心地を保ちながら衝突を防ぎたい」時や既存アプリへの段階導入の鉄板です。
CSS-in-JS ― 衰退傾向、新規採用は避ける
styled-components / EmotionのようにJSの中にCSSを書く方式は、propsで動的にスタイルを切り替えられる強みで一世を風靡しましたが、ランタイムオーバーヘッドとRSC非対応という課題があり、2024年3月にstyled-componentsがメンテナンスモード入りを公式発表しました。動的スタイルの需要はビルド時にCSSを抽出するゼロランタイムCSS-in-JS（Vanilla Extract・Panda CSS）が引き継いでおり、型安全重視の大規模デザインシステムではこちらが選択肢になります。
デザインシステムとDesign Token
デザインシステムは「再利用可能なUI部品とそれを使うルールの集合」で、その土台になるのがDesign Token──色やサイズを「意味のある名前で変数化」する仕組みです。
❌ color: #4F46E5 ← どの色がどこで使われているか不明
✅ color: var(--color-primary) ← 意図が明確#4F46E5 ではなく color.primary と呼ぶことで、ブランド変更・ダークモード対応・テーマ切替が一括で可能になります。ダークモードはCSS変数を [data-theme="dark"] で切り替えるだけで実現でき、Tailwindの dark: variantや prefers-color-scheme（OS連動）も同じ基盤に乗ります。Figmaで定義したトークンをStyle Dictionary等でコードに取り込み、「Figma⇔コードでトークンを完全同期」する流れが現代の主流です。
コンポーネントはゼロから作らず既製ライブラリを使うのが標準です。制約少なく自分色にしたいならshadcn/ui+Radix UI（コピペ式でコードが自分のものになる・アクセシビリティ特化）、即戦力の管理画面ならMUI / Ant Designが定番です。
どう選べばいいのか ― ケース別の推奨構成
新規SPA・中規模SaaSならTailwind+shadcn/ui+Design Tokenが現代の鉄板構成です。ブログ・コンテンツサイトは素のCSS / CSS Modules（Astroのscoped styleで十分）。大規模デザインシステム構築はVanilla Extract / Panda CSS+自社Design Token。既存アプリへの段階導入はCSS Modules、社内管理画面はMUI / Ant Designで部品を借りて素早く作ります。
CSS品質・アクセシビリティの数値Gate
※ 2026年4月時点の業界相場値です。
CSS設計の質は「なんとなく綺麗」ではなく数値で追います。特にアクセシビリティ（WCAG 2.2 AA）は法的義務になる国が増えています。
| 項目 | 基準値 |
|---|---|
| 色のコントラスト比（本文） | 4.5:1以上 |
| タッチ対象の最小サイズ | 44×44px |
| Lighthouse Accessibilityスコア | 90点以上 |
| axe-coreエラー数 | 0件（CIでブロック） |
| CSSバンドルサイズ | < 50KB（gzip後） |
米国・EUではアクセシビリティ訴訟が年々増加しており、2019年のDomino’s Pizza訴訟（視覚障害者が音声読み上げで注文できず、最高裁まで行き原告勝訴）以降、Webアクセシビリティは「気配り」ではなく「法的リスク領域」に入りました。日本の障害者差別解消法改正（2024年4月施行）も同方向です。目視ではなくaxe-core+LighthouseをCIに組み込んで機械的にチェックします。
3つのシナリオで考える
個人開発・スタートアップの場合
Tailwindとshadcn/uiのコピペベースで最速に組んでしまいましょう。ブログやコンテンツサイトであれば、Astroのscoped styleで素のCSSを書くのでも十分です。独自のデザインシステムを作る余裕はこの段階にはありませんので、必要な箇所だけカスタムするという割り切りが大事だと思います。
中小SaaSの場合
Tailwindとshadcn/uiにDesign Tokenを加えた構成が鉄板です。色・余白・タイポグラフィをTokenで変数化しておくと、リブランド対応が1行の変更で済んでしまいます。この段階からはaxe-coreとLighthouseをCIに組み込んで、アクセシビリティを機械的に担保する運用もお勧めします。
大企業の場合
大規模なデザインシステムを構築するならVanilla ExtractやPanda CSSに自社Design Tokenを組み合わせ、社内管理画面はMUIやAnt Designで部品を借りて素早く作る、というように用途で使い分けます。WCAG 2.2 AA準拠はもはや法的リスク領域となっていますので、監査要件として最初から設計に含めておくべきでしょう。
AI判断軸 ― TailwindはAIが完璧に生成できる
TailwindがAI生成で圧倒的に有利な理由
TailwindのユーティリティクラスはHTMLに直接書かれるため、AIはJSX内で見た目の意図を一目で把握できます。className="flex items-center gap-4 p-6 rounded-lg" は、AIにとって「中央揃え・余白・角丸」という意味が即座に読み取れます。CSS Modulesやstyled-componentsではスタイル定義が別ファイルにあり、AIがJSXとスタイルの対応を取るためのコンテキストが増えます。この差がAI生成速度と精度に直結します。
shadcn/uiのコピペ方式がAI編集を容易にする
shadcn/uiは node_modules にコンポーネントを隠すのではなく、プロジェクトの components/ui/ にコピーして使う方式です。AIにとってはプロジェクト内のファイルとして中身が見えるため、「Buttonコンポーネントにローディングスピナーを追加して」のような指示に対しファイルを直接編集できます。なおAIはセマンティックHTMLを軽視して <div onclick> を書くことがあるため、ARIA・セマンティクスのチェックは自動化しておくのが安全です。
やってはいけないこと
スコープ崩壊・詳細度バトル・カスケード地獄につながる典型を、特に危険な6つに絞ります。
| 禁じ手 | なぜダメか → どうするか |
|---|---|
| グローバルCSSで命名規約なし | 名前衝突で触れないコードになる → Tailwind / CSS Modulesでスコープを切る |
!important を多用 | 詳細度バトルが解けなくなる → 設計で詳細度を管理する |
| カラーコードをハードコード | リブランド・ダークモードで全置換不能になる → Design Tokenで変数化する |
| CSS-in-JSをRSC環境で新規採用 | styled-componentsはメンテ入り → Tailwind / Vanilla Extractにする |
セマンティックHTMLを無視（<div onclick>） | スクリーンリーダーで読めない → <button> 等を正しく使う |
| コントラスト比を目視だけで確認 | 4.5:1を満たさない色が大量発生する → axe-coreで機械チェックする |
筆者メモ ― 「リブランドで滲み続けた旧色」
あるサービスで、リブランド対応のために #4F46E5 を全ファイル置換で対応した、という話があります。コードの大半は変わりましたが、インラインスタイル・Figmaから直接コピペされたグラデーション・メール用HTMLに古い色が残り、リリース後1週間は前ブランドカラーが画面のどこかに滲み出続けたそうです。
Design Tokenが最初から定義されていれば、var(--color-primary) の値を1行書き換えるだけで終わった作業でした。「変数化していない色はgrepで拾いきれない」#4F46E5 と書いた瞬間、未来の自分への借金が発生しています。
決めるべきこと — 自分のプロジェクトでの答えは？
以下の項目について、自分のプロジェクトの答えを1〜2文で言語化してみてください。曖昧なまま着手すると、必ず後から「なぜそう決めたんだっけ」が問われます。
- CSS記述方式（Tailwind / CSS Modules / ゼロランタイム）
- UIコンポーネントライブラリ（shadcn/ui / MUI等）
- Design Token管理方法（tokens.json / Style Dictionary）
- アクセシビリティ基準（WCAG AA等）とCIチェック
- ダークモード対応（OS連動 / トグル）
この記事に関連する記事
まとめ
本記事はCSS設計について、Tailwind/CSS Modules/CSS-in-JS・Design Token・アクセシビリティまで含めて解説しました。如何だったでしょうか。
CSSはTailwindに寄せ、Design Tokenを最初から入れる。他方式は明確な理由がある時だけ、というのが2026年の現実解です。
次回はBFFについて解説します。
シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方
本記事で扱った内容の詳細は Tailwind CSS も合わせて参考にしてください。
それでは次の記事も閲覧いただけると幸いです。
📚 シリーズ：生成AI時代のアーキテクチャ超入門（41/95）