第2章 Tailwind CSS 誕生の背景

第1章では、CSS が抱えてきた課題を歴史としてたどりました。この章では、その課題に対して 1 人の開発者がどう向き合い、Tailwind CSS が生まれたのかを、本人の発信という一次情報を中心に見ていきます。

2.1 Adam Wathan とは何者か

Tailwind CSS の作者は Adam Wathan（アダム・ウェイサン） です。彼はフルスタックの開発者であり、技術書や有料講座、ポッドキャストなどを通じて知識を発信してきた人物でもあります。

彼の経歴で重要なのは、Tailwind 以前から デザインと CSS の設計に強い関心を持っていたことです。彼はデザイナーの Steve Schoger とともに、デザインの実践書 『Refactoring UI』 を執筆しています。「きれいな UI をどう設計するか」を体系的に考えてきた人物が、その実装手段として CSS の書き方を突き詰めた結果が Tailwind だ、という背景を押さえておくと、Tailwind が単なる CSS フレームワークではなく「デザインシステムを作るための道具」である理由が腑に落ちます。

なお、Tailwind CSS は現在 Tailwind Labs という会社によって開発・運営されています。Adam Wathan を中心とした小さなチームが、OSS としての Tailwind CSS と、後述する有料製品の両方を手がけています。

2.2 きっかけとなったブログ記事「Separation of Concerns」再読

Tailwind の思想を理解するうえで最も重要な一次情報が、2017 年 8 月に Adam Wathan が公開したブログ記事 「CSS Utility Classes and "Separation of Concerns"」 です。これは Tailwind CSS が公に登場する直前に書かれた、いわば思想の宣言文です。

この記事で彼が投げかけたのは、第1章でも触れた問いです。「関心の分離は、本当に HTML と CSS を分けることなのか？」

彼はこう論じます。HTML と CSS が別ファイルにあっても、たとえば .hero-title のようなクラスでは、CSS が HTML の構造に依存しています。「ヒーローのタイトル」という HTML 側の都合に合わせて CSS のクラスを作っているからです。これは見方を変えれば、HTML と CSS が双方向に依存している状態です。

そこで彼は、依存の「向き」に注目します。選択肢は 2 つあると言います。

CSS が HTML に依存する（.hero-title のように、HTML の構造に合わせて CSS を書く）→ HTML は変えやすいが、CSS は再利用しにくく、増え続ける。
HTML が CSS に依存する（text-white text-2xl font-bold のように、あらかじめ用意された汎用クラスを HTML 側で組み合わせる）→ CSS は完全に再利用可能で増えない。その代わり HTML はクラスでにぎやかになる。

彼の結論は、多くのプロジェクトでは後者、すなわち 「再利用可能な CSS」を選ぶ方が利益が大きい、というものでした。この「依存の向きを反転させる」という発想こそが、Utility First の核心です（第3章で深掘りします）。

2.3 自作 CSS から生まれた最初の Tailwind

重要なのは、Tailwind が「理論を先に立てて作られた」のではなく、実際のプロジェクトの中から生まれたという点です。

Adam Wathan は自分のプロジェクトで、繰り返し使う小さなユーティリティクラス（.p-4 のような）を自前で書きためていました。最初はちょっとした便利クラスの集まりでした。やがてそれを体系化し、設定で色や余白のスケールを生成できるようにしていったものが、フレームワークとしての Tailwind CSS になりました。最初のバージョンが公開されたのは 2017 年です。

この「実務での痛みから生まれた」という出自は、Tailwind が机上の理想論ではなく、現場で使える実用性を重視している理由を説明します。

2.4 「ユーティリティの自作」から「フレームワーク化」への転換点

個人の便利クラス集が、世界中で使われるフレームワークになるには、いくつかの転換が必要でした。

設定からの生成: 色・余白・フォントサイズなどを設定ファイルで定義すると、そこから整合性のとれたユーティリティクラス群が自動生成される仕組み。これにより「制約のあるデザインシステム」が手に入りました。
レスポンシブやホバーへの対応: md: や hover: といったプレフィックス（バリアント）で、メディアクエリや擬似クラスをユーティリティのまま扱えるようにしたこと。これがインラインスタイルとの決定的な違いになりました（第3章・第6章）。

これらにより、Tailwind は「ただの便利クラス集」から「デザインシステムを構築するための基盤」へと進化しました。

2.5 JIT エンジン以前の課題（巨大な生成 CSS と PurgeCSS）

ただし、初期の Tailwind には大きな弱点がありました。生成される CSS が巨大だったのです。

Tailwind は、ありとあらゆる色・余白・サイズの組み合わせをクラスとして用意します。しかも md: や hover: などのバリアントまで掛け合わせると、組み合わせは爆発的に増えます。初期の方式では、これらをあらかじめ全部生成していたため、開発時の CSS は数 MB に達することもありました。

そのままでは本番環境に出せないので、当時は PurgeCSS というツールを併用するのが定番でした。これは「実際に HTML で使われているクラスだけを残し、使っていないクラスを削除する」ツールです。これで本番の CSS は小さくなりますが、設定が必要で、「開発時は巨大、ビルド時に削る」という二段構えは、開発体験としても仕組みとしてもスマートとは言えませんでした。

2.6 v1 → v2 → v3（JIT 標準化）→ v4（新エンジン）の流れ

Tailwind はこの弱点を、エンジンの進化によって根本的に解決していきます。バージョンの流れは、そのまま「巨大な CSS 問題をどう克服したか」の歴史です。

v1.0（2019 年）: 最初のメジャーバージョン。フレームワークとしての土台が固まる。
v2.0（2020 年 11 月）: ダークモード対応などを追加。
JIT エンジン（2021 年 3 月にプレビュー公開）: ここが大きな転換点です。「あらかじめ全部生成して後で削る」のをやめ、実際にコードで使われているクラスだけを、その場で（Just-in-Time に）生成する方式に変えました。これにより PurgeCSS が不要になり、開発時から CSS が小さくなり、ビルドも劇的に速くなりました。さらに top-[-113px] のような任意の値を角かっこで書けるようにもなりました。JIT は v2.1 で本体に統合され、v3.0（2021 年 12 月）で既定の動作になりました。
v4.0（2025 年 1 月 22 日）: エンジンを Rust で書き直した新エンジン（コードネーム Oxide）を搭載し、さらに高速化。設定方法も tailwind.config.js 中心から CSS ファースト（@theme を CSS に書く）へと大きく変わりました。本書はこの v4 を前提にしています（詳細は第29章）。

「巨大な CSS をどうするか」という初期の課題が、JIT という仕組みの発明によって解決され、それが Tailwind を実務で本当に使えるものにした——この流れは、第4章「Tailwind CSS はどう動くのか」の伏線になります。

2.7 ビジネスとしての Tailwind（OSS と収益の両立）

Tailwind を語るうえで見逃せないのが、OSS でありながら継続的に開発される仕組みを作った点です。

Tailwind CSS 本体は無料のオープンソースです。では Tailwind Labs はどうやって収益を得て、専任で開発を続けているのでしょうか。答えは、Tailwind を使った有料製品です。

Tailwind UI（現在は Tailwind Plus に名称変更）: Tailwind で作られた高品質な UI コンポーネント・テンプレート集。これを販売しています。
Headless UI（スタイルを持たないアクセシブルな UI 部品）や Heroicons（アイコン集）など、本体を補完する OSS も提供しています。

「無料の OSS でユーザーを増やし、その上に乗る有料の完成品で収益を得る」というモデルにより、Tailwind は特定企業のスポンサー頼みにならず、自走できる開発体制を築きました。これは、多くの OSS が資金難で停滞するなかで、Tailwind が継続的に大きな進化を続けられている理由の 1 つです。

FBC Press: Tailwind CSS