CSS の歴史から考える AI 時代：フレームワークは何を解決するのか

AI に商品カードを作ってもらう場面を想像してください。初版には画像、価格、購入ボタンがあり、デスクトップでは三列、スマートフォンでは一列に並びます。次にデザイナーから、ブランドカラーの変更と、同じカードをサイドバーにも置きたいという依頼が来ます。キーボードフォーカスと売り切れ状態は維持しなければなりません。

二度目の変更で問題が見えてきます。どの青がブランドを表し、どの青が情報を示すのでしょうか。カードは画面幅とコンテナ幅のどちらに応じて変わるべきでしょうか。AI がボタンを直すと、別のページの操作状態まで変わっていないでしょうか。

この記事では、この架空の事例を使って考えます。AI がスタイルを書くコストの一部を下げるとき、フレームワークは変更、検証、協働のどのコストを下げられるでしょうか。 CSS の歴史をたどると、ツールが担ってきた責任を整理でき、将来の予測にも確かめられる根拠を持たせられます。

CSS の出発点には、制御権の配分があった

1994 年に Håkon Wium Lie が CSS を提案し、その後 Bert Bos が加わりました。CSS1 は 1996 年に W3C Recommendation となり、CSS2 は 1998 年に続きました。中心的な設計の一つが cascade です。制作者、利用者、ブラウザの表示上の要求を、共通の規則で調整する必要がありました。W3C による歴史

この出発点は今も重要です。スタイルシートで制作者の意図は表せても、結果は利用可能な領域、フォント、利用者の設定にも左右されます。宣言として記述できることは、全ピクセルを制作者だけで決められることを意味しません。

初期のブラウザでは標準の実装も一致していませんでした。正しい CSS を書くことと、各ブラウザで許容できる表示を得ることは別の課題でした。繰り返し遭遇する差異を共通の手法にまとめることで、互換性の知識そのものがツールの価値になりました。

やがてページは、より多くの画面サイズに対応する必要が生まれます。Ethan Marcotte が 2010 年に示したレスポンシブ Web デザインは、流動的なグリッド、伸縮する画像、media queries を一つの方法論にまとめました。条件に応じたレイアウトの変化を記述する必要が生まれ、ブレークポイントや配置規則もチームで保守する資産になったのです。原文、公開日の振り返り

CSS の難しさには、ブラウザが規則をどう解釈するかと、人が規則をどう整理するかの二つがあります。前者が進歩しても、後者が自動的に解決するわけではありません。

チームの共通認識を支えるためにツールが育った

サイトが大きくなると、重複、命名、変更の影響範囲が問題になります。Sass は変数、mixin、モジュール、計算をビルド時に CSS へ処理し、ブランド設定や共通規則の集中管理を可能にします。コンパイル工程が増える一方で、ソースコードを整理する仕組みが得られます。Sass ガイド

Bootstrap は共通の決定をインターフェースの層まで広げました。Twitter 内部のスタイルガイドとして始まり、2011 年に公開され、その後の版ではレスポンシブ設計、Flexbox、カスタムプロパティなどが取り入れられました。この種のフレームワークを採用すると、コンポーネントと既定値も採用することになり、各ページでボタンやフォーム、グリッドを決め直す作業が減ります。Bootstrap の歴史

別の流れは、スタイルの帰属に注目しました。BEM は block、element、modifier の命名で構造とバリエーションを表します。CSS Modules は class 名とアニメーション名を既定でローカル化し、import で依存関係を作ります。前者は共通の規律、後者はビルドツールによって名前の衝突を抑えます。何を共有し、何をコンポーネント内部に残すかは、どちらでも判断が必要です。

コンポーネント化は CSS-in-JS も生みました。styled-components では、スタイルをコンポーネントの近くに置き、props に応じて変えられます。ただし実行モデルは一つではありません。vanilla-extract は TypeScript で記述したスタイルをビルド時に静的 CSS として出力します。記述方法、生成物、実行時点は分けて評価する必要があります。

utility-first は組み合わせる場所を markup に移します。Tailwind では小さな class、状態のバリエーション、デザイン尺度を組み合わせ、その使用箇所で選択内容を確認できます。繰り返す組み合わせの整理や、上位コンポーネントでの意味付けは依然として必要です。

時間軸に並べると、担う責任が広がってきたことがわかります。以下は流れの整理であり、同じ時期の手法を併用することもできます。

AI を考えるうえでの教訓は、入力速度がツールの価値の一部にすぎないことです。フレームワークは共通の決定を保存し、次の保守担当者が最初から推論し直す負担も減らしています。

ネイティブ CSS が担う範囲と、ツールの再定位

Flexbox は一つの次元で空間を配分し、Grid は行と列を直接表します。ブラウザが配置の仕事をより多く担うことで、独自のグリッド抽象化がどれほど必要かを見直せます。

カスタムプロパティも分担を変えました。Sass 変数はコンパイル時に処理されますが、CSS カスタムプロパティは出力に残り、要素や cascade に応じて値が変わります。ブランドやテーマの切り替えでは、両方が「変数」と呼ばれることより、この違いが重要です。併用はできても、構文だけを一対一に置換できるわけではありません。Sass による違いの説明

ネイティブの nesting はセレクターの重複を減らしますが、名前の分離を作るものではありません。@layer で層の優先順位を決めても、どのスタイルをどの層へ入れるかはチームの判断です。起源、重要度、層、詳細度、記述順が関係するため、「後に書いたものが常に勝つ」とは言えません。

冒頭のカードには container size queries が役立ちます。viewport だけでなく配置先のコンテナ幅に応じて並び方を変えれば、同じデスクトップ画面の本文とサイドバーでも別々に対応できます。表現能力を提供するのはブラウザですが、どの幅で配置を切り替えるかは設計の決定です。

実際に使った経験も広がっています。State of CSS 2026 の All Features とエクスポートデータでは、:has() の設問に答えた 3,822 人中 3,198 人が使用経験ありと回答し、表示値は 83.7% です。CSS Nesting は 3,820 人中 2,695 人、表示値は 70.6% です。分母はそれぞれの機能の回答者数で、割合は公式の表示精度に従っています。Web サイト全体での普及率や、本番プロジェクトで継続使用している割合ではありません。

現代の CSS は、一式で更新される単一バージョンでもありません。モジュールは個別に進化し、仕様の状態とブラウザの普及状況は分けて見る必要があります。CSS Snapshot 2026 も仕様の安定性と実装の普及を区別しています。ネイティブの @mixin はまだ実験的な草案として読むべきものです。規則の再利用に関する別記事で扱っていますが、Sass から確実に移行できる完成済みの機能ではありません。

フレームワークもネイティブ機能を活用します。Tailwind v4 は CSS-first の設定、カスタムプロパティ、cascade layers を採用し、container queries も組み込んでいます。ブラウザの進歩は補完すべき仕事を減らしながら、ツールの組み合わせ機能を豊かにすることもできます。

調査が示す現在：ツールは併存し、AI はすべてを担ってはいない

State of CSS 2026 の CSS フレームワークに関する設問には 3,697 人が回答しました。以下は一部の選択肢の人数です。複数回答なので重複があり、市場を分割したシェアとして合計することはできません。ツール調査

これらは異なる層の選択です。shadcn/ui と Tailwind は同時に使えますし、None から「ツールを一切使わない」とは推論できません。調査の分類は回答を集めるためのものであり、構造を分析するときはスタイル生成、操作を担うコンポーネント、コード配布を区別する必要があります。

同年の CSS AI Code Generation は、自分が作成する CSS のうち AI が生成する割合を尋ねています。3,732 人の自己申告について、公式表示の中央値は約 13% です。980 人が 0% と答え、この設問の回答者の約 26.3% に当たります。これは各回答者の割合の中央値であり、世界全体の CSS 生成量を推定する値ではありません。

ここから予測の出発点を絞れます。AI は一部の人の作業に入っていますが、CSS の仕事の大部分を担っていると、この調査だけからは言えません。生成品質に関するコメントも比較実験ではなく、モデルが一般に得意か不得意かを確定する根拠にはなりません。

主催者がフレームワークを使わない選択と LLM を結び付けたコメントも、一つの解釈です。プロジェクトの種類、チームの好み、ネイティブ機能の進歩といった要因は排除されていません。AI が利用状況を変えたという因果関係を、この数字だけで証明することはできません。ここでは仮説を立て、工学的な成立条件を検討します。

二度目の変更では、規則を識別できるかが問われる

商品カードに戻りましょう。以下は枠線と余白だけを記述した架空の初版です。

.site-product-card {
  border: 1px solid #45687d;
  padding: 1.5rem;
}

「ブランドカラーを変えて」と依頼しても、このコードから枠線の役割はわかりません。AI がプロジェクト全体を検索できても、同じ色を使う別の箇所まで変えるべきかを判断する必要があります。値が同じでも、意図が同じとは限りません。

要件を「注目商品だけにブランド色の枠線を使い、ほかは中立色を維持する」と確認できたら、共通規則とバリエーションを記述できます。次は先ほどのコードを置き換える例です。カードは .site-product-slot の内側にあり、注目カードには data-featured が付き、ブランド属性は祖先要素にあるとします。

:root {
  --border-neutral: #777777;
  --accent-brand: #45687d;
  --space-card: 1.5rem;
}
 
[data-brand="forest"] {
  --accent-brand: #406b57;
}
 
.site-product-slot {
  container: product / inline-size;
}
 
.site-product-card {
  display: grid;
  gap: 1rem;
  padding: var(--space-card);
  border: 1px solid var(--border-neutral);
}
 
.site-product-card[data-featured] {
  border-color: var(--accent-brand);
}
 
@container product (width >= 30rem) {
  .site-product-card {
    grid-template-columns: minmax(0, 1fr) 2fr;
  }
}

カードの直接の子要素は画像領域と内容領域の二つ、30rem はこの事例で選んだ条件とします。参照するのは外側のコンテナで、幅が足りなければ一列を維持します。ここでは枠線、間隔、配置だけを示し、ボタンのフォーカスや売り切れ時の動作は既存コンポーネントに任せています。

上位層でコンポーネントを組み合わせるなら、さらに限定した API も提供できます。以下は既存パッケージのものではない、架空のコンポーネント API です。

<ProductCard
  product={product}
  emphasis="featured"
  availability="sold-out"
/>

これらの名前に価値があるのは、実装が emphasis をスタイルに、availability を文言と操作に正しく対応付けている場合です。型で値を制限しても、売り切れボタン、キーボード操作、表示の正しさまでは証明できません。任意の値への命名も、安定した共通の決定を表すときに初めて、次の変更の曖昧さを減らします。

ネイティブ CSS、utility class、コンポーネントライブラリのいずれも、こうした規則を持てます。AI が必要とする文脈には、構文だけでなく、既存コンポーネント、有効な組み合わせ、意図した範囲を超えていないかの確認方法も含まれます。

そのため、私はコストを分けて考えます。記述のコストは下がるかもしれませんが、既存規則の理解には文脈が必要です。変更は共有元へ波及し、検証はテーマ、サイズ、状態を含み、保守には更新と例外への対応もあります。これは分析の枠組みであり、実測した時間配分ではありません。生成が速くてもレビューが遅くなるなら、全工程を数える必要があります。

2026–2029 年に注目する三つの変化

構文を短くするだけの採用理由は弱まるかもしれない

AI がネイティブ CSS を確実に生成、変更できるなら、追加構文による入力時間の節約だけでは、学習やビルドのコストに見合わなくなる可能性があります。機能が単純で独自性の高いデザインのサイトでは、依存を減らした構成を検討する理由が増えるでしょう。

ただし utility-first には局所的な組み合わせ、デザイン尺度、チームの慣習もあります。成熟したツールは、AI が既存の例に従う助けにもなり得ます。圧力を受けると予測するのは「入力文字数が少ないから」という理由であり、Tailwind などの衰退を断定するものではありません。

同じ要件と後続の変更を、より少ない依存で、品質を維持し、人の修正も減らして達成できるかを見たいと思います。ネイティブの方法で文脈や回帰対応がより多く必要なら、この予測は狭めるべきです。None の順位上昇だけでは足りません。

設計上の制約と検証の価値が高まるかもしれない

十種類のカードを簡単に作れるなら、チームは残すべき種類を選ぶ必要があります。token、有効なバリエーション、状態ごとの例、回帰チェックは、目指す外観と正しさの基準を再利用できる形にします。

この価値は大きなフレームワークに限りません。小さなチームなら明確な CSS、少数のコンポーネント、確認手順で十分かもしれません。複数ブランドの製品では、より整ったデザインシステムが必要かもしれません。どちらも規則が実際の要求に合い、保守する人がいることが前提です。

新しい UI を追加したとき、設計からの逸脱や回帰が減り、レビュー時間が短くなるかを見ます。規則が増えるほど例外処理が難しくなったり、テスト更新のコストが利益を上回ったりするなら、重い制約は割に合わないでしょう。AI が検証を助け、軽い構成で足りる可能性もあります。

agent が見つけて使えることを、より重視するようになる

shadcn MCP はすでに registry のコンポーネントを参照、検索、インストールするインターフェースを提供し、非公開の配布元にも接続できます。文脈を取得する経路の整備を示していますが、agent が正しい部品を選び、正しく修正する保証ではありません。

私は、ツール作者がバージョンの明確な文書、取得できるソース、組み合わせの例、実行可能なチェックをさらに重視すると予測します。人にとっての使いやすさに加え、agent が正しい版と制約を把握し、既存プロジェクトへ組み込めるかも評価対象になるでしょう。

主要なエコシステムは既定の連携から利益を得る一方、検索の改善によって、小さなツールもモデルの事前知識に頼らず使えるかもしれません。接続後に API の誤用、既存部品の作り直し、人の手戻りが減るかが観察点です。汎用のコード理解で十分になれば、専用インターフェースの優位性は小さくなる可能性があります。

次の選択は、残したい責任から始める

エンジニアにとって cascade、サイズ計算、配置の理解は依然として役立ちます。生成結果が期待から外れたとき、原因を規則までたどれるからです。フレームワーク作者は、どの変更を容易にし、それをどう検証できるかを説明し直せます。

既存プロジェクトには移行コストもあります。新しい方法でコードが減るとしても、実際の変更で利益を確かめてから、安定している共通の手法を置き換えるべきです。

あのカードの二度目の変更では、ブランドカラーをどこで変え、サイドバーの配置を誰が決め、売り切れとフォーカス状態をどう確かめるかを明確にしたいと思います。これらの責任を保存し、伝え、検証する必要がある限り、ツールには役割があります。これから競う価値があるのは、一度の変更を理解しやすくし、要件を満たしたと示しやすくする力です。