AI 時代の CSS は「素の CSS」に戻るべきか？Tailwind・StyleX と適材適所の選び方

最近のXなどでは、「AI にコードを書かせるなら、Tailwind より素の CSS のほうが適している」という意見が見られます。HTML がユーティリティクラスで埋まらない点や、モダン CSS の機能拡充によってブラウザ標準だけでレイアウトを組める点、そして AI が実装を担うなら人間にとっての書きやすさを優先する理由が薄い点などが根拠として挙げられています。

こうした主張の技術的背景には頷ける部分があります。しかし、パーティーハード株式会社で日常的に Claude Code などのコーディングエージェントを活用した開発を進めていると、出力の安定性や保守性の面で別の課題に直面します。素の CSS の利点を前提としつつ、コードの再現性とトークン消費量の両面からスタイリング手法の得失を比較します。

素の CSS 派の主張

素の CSS を評価する意見には、具体的な技術的背景があります。

• モダン CSS の機能拡充：:has() 擬似クラス、コンテナクエリ、カスケードレイヤー（@layer）やスコープ（@scope）の普及により、かつて Sass やユーティリティクラスで補っていた設計課題の多くがブラウザ標準仕様だけで実装できます
• ツール依存の排除：ビルドツールやサードパーティ製ライブラリの更新に伴う破壊的変更を受けません。実際、Tailwind v4 への移行時に設定仕様が刷新された際、古い知識を参照したコーディングエージェントが、廃止された tailwind.config.js を前提にした手順を出力してセットアップに失敗する事例が見られました
• マークアップの視読性：class="flex items-center justify-between gap-4 px-6 py-3 ..." のように長いクラスが連続する HTML に比べ、class="site-header" のような記述のほうが構造の意図を把握しやすくなります

いずれの論点も実情に即した指摘です。とくに標準仕様の進展によって、外部ツールに頼らずとも高度なレイアウトを実現できる環境が整った点は、数年前と大きく状況が異なります。

再現性のために Tailwind を使うという考え方

しかし、セッションをまたいでコーディングエージェントに変更を依頼し続ける現場では、素の CSS の自由度の高さが出力のばらつきにつながります。

素の CSS をエージェントに生成させると、単体としては整ったコードが出力されます。問題は、その体裁がセッションごとに少しずつ分散することです。余白の指定が 16px、1rem、1.125rem と揺れ、同系統のグレーを指定する際も #666 と #6b7280 が混在します。セレクタの命名も .card-header、.cardHeader、.c-card__head のように、入力されたプロンプトや直前の文脈によって変化します。

人間が単独で開発する場合は、個人の記憶や文脈の保持によって統一感を維持できます。しかし、コーディングエージェントはセッションごとに前提文脈が初期化されるうえ、複数のエージェントやチームメンバーが同一のリポジトリに変更を加えます。素の CSS は表現の選択肢が無制限であるため、指定値や命名の揺れがコードベースに蓄積します。

Tailwind を採用すると、設計上の自由度をあらかじめ制限することでこの問題を抑えられます。

• デザイントークンによって指定可能な値の選択肢が制約されている（p-4 や text-gray-500 など）
• 独自のクラス名を考案・命名する必要がない
• スタイル定義が要素の属性として直接記述されるため、スタイルの実態を確認するために別ファイルを探索する必要がない

コーディングエージェントにとっては、選択できる表現の幅が狭いほど出力のばらつきが抑えられます。Tailwind は公開リポジトリなどの学習データにも大量に含まれているため、構文的な揺れも少なくなります。記述の簡潔さとは異なる、AI による自動生成を前提とした環境ならではの特性です。

CSS 探索に伴うトークン消費の比較

素の CSS を支持する立場からは、トークン消費量への懸念も挙げられます。長いクラス文字列がコンテキストウィンドウを圧迫するという指摘です。

確かに、単一の HTML ファイルの記述量だけを比較すれば、素の CSS を採用したマークアップのほうが短く収まります。たとえばボタン要素 1 つをとっても、Tailwind では次のような記述になります。

<button class="inline-flex items-center gap-2 rounded-md bg-blue-600 px-4 py-2 text-sm font-medium text-white hover:bg-blue-700">
  保存
</button>

素の CSS であれば、HTML 側は <button class="btn-primary">保存</button> という短い記述で済みます。

しかし、コーディングエージェントが既存のコードを変更する場面を考慮すると、コンテキストの消費量は単純な文字数だけでは決まりません。たとえばボタンの見た目を変更する作業では、素の CSS を採用しているとエージェントが次の手順をたどります。

1. HTML を読み込んで btn-primary というクラス名を特定する
2. そのクラスが定義されている CSS ファイルを検索する
3. 該当する CSS ファイルを読み込む（通常はファイル全体がコンテキストに読み込まれる）
4. 同じクラスが他の要素で使われていないか、変更の影響範囲を確認する

これに対して Tailwind では、コンポーネント定義を読み込んだ時点でスタイルの情報がすべて揃っています。コンテキストに読み込む必要があるのは、対象コンポーネントのファイル単体にとどまります。

したがって、単一ファイルあたりの文字数では素の CSS がコンパクトに見えるとしても、変更タスク 1 回で参照すべきファイル数と総読み込み量では、Tailwind のほうがトークン消費を抑えられる場面が珍しくありません。規模の大きな CSS ファイルを抱えたプロジェクトでは、クラス定義を探索してファイル全体を読み込むコストのほうが、クラス文字列の長さによる消費を上回ることがあります。

一方で、同一のスタイルを持つ要素が多数並ぶ画面で、Tailwind のクラスをコンポーネント化せずに直書きしていると、同一のクラス文字列が反復してトークンを浪費します。Tailwind の利点を活かすには、要素をコンポーネント単位で適切に分割・共通化している運用が前提となります。

StyleX という選択肢

素の CSS と Tailwind の中間的なアプローチとして、Meta 社が開発する StyleX という選択肢もあります。Facebook や Instagram の大規模な Web アプリケーションで運用実績を持つスタイリングライブラリです。

import * as stylex from '@stylexjs/stylex';

const styles = stylex.create({
  button: {
    display: 'inline-flex',
    paddingInline: 16,
    backgroundColor: {
      default: 'blue',
      ':hover': 'darkblue',
    },
  },
});

<button {...stylex.props(styles.button)}>保存</button>

構文は CSS-in-JS の形式をとりますが、ビルド時に静的なアトミック CSS へ変換されるため、実行時のパフォーマンス低下が起きません。生成される CSS は Tailwind に類似し、記述感は「TypeScript の型が付いた素の CSS」に近い特性を備えています。

コーディングエージェントによるコード生成を前提とすると、StyleX には次のような利点があります。

• TypeScript の型定義と連動するため、エージェントが存在しないプロパティや無効な値を生成した場合、ビルド時や静的解析の段階で機械的に検出できる
• stylex.defineVars によってデザイントークンを厳格に定義し、許可されていない任意の値の使用を制限できる
• スタイル定義がコンポーネントファイル内に閉じるため、Tailwind と同様にエージェントが外部の CSS ファイルを探索する必要がない
• プロパティ名に標準の CSS 仕様を踏襲しているため、Tailwind 独自の名前空間やユーティリティ構文を学習・指定する必要がない

直近でも View Transitions やアンカーポジショニングに対応する API が拡充されるなど、機能の更新が進められています。

一方で、公開リポジトリに含まれる学習データの量は Tailwind と比較して限られており、エージェントの生成精度はリポジトリ内に既存の参照実装（手本となるコード）が存在するかどうかに依存します。Next.js や Vue などのコンポーネント指向フレームワークを採用した Web アプリケーションには適合しやすい反面、PHP（Symfony や Laravel など）のテンプレートエンジンで静的な HTML を生成するサーバー主導の構成では導入の恩恵を得にくい制約があります。

型システムによる静的検査を出力の再現性担保に活用できるため、複数人で運用する中規模以上のプロダクトや、デザインシステムを厳格に管理したいチームにとって有力な選択肢となります。

適材適所で選ぶ

AI を活用した開発では、単一のスタイリング手法がすべての要件に当てはまるわけではありません。コード生成をエージェントに任せるからこそ、プロジェクトの要件や体制に応じて、スタイルの揺れをどの仕組みで防ぐかを判断する必要があります。

パーティーハード株式会社では、現時点で次のような判断基準を目安にしています。

• ランディングページや小規模なコーポレートサイト：素の CSS が適しています。ページ数が少なく全体のスタイル規模も小さいため、エージェントがファイル構造を把握しやすくなります。モダン CSS の標準機能を活用でき、ビルドツールの依存も増えません
• 複数人の開発者や複数のエージェントが継続的に改修する Web アプリケーション：Tailwind の採用が適しています。デザイントークンによって指定値の選択肢が限定され、マークアップとスタイルが密結合しているため、執筆者やセッションが異なっても出力の乖離を防ぎやすくなります
• デザインシステムを厳格に管理する中規模以上のプロダクト：StyleX が有力な候補となります。TypeScript の型検査とトークン定義により、指定可能なプロパティや値を機械的に制約できる利点があります

いずれの手法を採用する場合でも、カラーパレットや余白のルールといったデザイントークンをあらかじめ定義し、エージェントが任意の値を書き込めない制約を用意する必要があります。素の CSS であればカスタムプロパティ（CSS 変数）で、Tailwind であれば @theme ディレクティブで、StyleX であれば defineVars で定義します。実装手段は異なっても、エージェントの出力を規定のトークン内に制限する機構を設けることが、長期的な保守性と再現性を支えます。

おわりに

「どちらが優れているか」という二項対立ではなく、プロジェクトの規模、開発メンバーの人数、コーディングエージェントをどの作業範囲に適用するかによって選ぶべき道具は変わります。エージェントがコードの記述を肩代わりするからこそ、開発者はどのレイヤーで制約を課し、再現性を担保するかという設計判断に注力することが求められます。

パーティーハード株式会社では、AI エージェントを前提にした受託開発や技術選定のご相談も受け付けています。お気軽にお問い合わせください。