第28章 Tailwind CSS への批判と評価
Tailwind は広く使われていますが、同時に強い批判も浴び続けてきました。この章では、Tailwind を擁護するのではなく、主要な批判をできるだけ強い形で提示し、それに対する反論を並べ、最後に公平な評価を下します。読者が「自分のプロジェクトでどうすべきか」を自分で判断できるようにするのが目的です。
28.1 批判①「HTML が汚い」
批判の主張: Tailwind の最大の批判はこれです。class="inline-flex items-center rounded-md bg-blue-600 px-4 py-2 ..." のようにクラスが大量に並んだ HTML は、読みにくく、醜く、保守しづらい。要素の構造がクラスの洪水に埋もれて見えなくなる、というものです。これは見た目の好みの問題に留まらず、「ぱっと見て構造を把握できない」という実害を伴います。
反論: 第3章で見たとおり、これはトレードオフだという立場です。HTML が「にぎやか」になる代わりに、CSS ファイルの肥大化・命名・詳細度の戦いから解放される。そして、繰り返し現れる長いクラス列はコンポーネント化すれば、それが見えるのは定義の 1 か所だけになる（第6部）。
評価: この批判には、正当な部分があります。コンポーネント化の仕組みがない環境（生の HTML を手で量産するなど）では、「醜い HTML」は実害のある負債になります。一方、React や Rails の ViewComponent のように抽出手段が整った環境では、痛みは大きく緩和されます。つまりこの批判の妥当性は、プロジェクトの構成に依存する、というのが公平な見方です。「コンポーネント化できる環境かどうか」が分かれ目です。
28.2 批判②「インラインスタイルと同じでは」
批判の主張: クラスで見た目を直接指定するなら、style 属性に書くインラインスタイルと本質的に同じで、CSS の進歩を巻き戻しているだけだ、というものです。
反論: 第3章で詳しく見たとおり、これは事実として誤りです。Tailwind のユーティリティは、インラインスタイルにはできない 3 つのことができます——制約（スケールによる一貫性）、状態（hover: など）、レスポンシブ（md: など）。公式ドキュメントもこの 3 点を明確に挙げています。インラインスタイルでは :hover も @media も書けません。
評価: この点については、反論に分があります。「見た目を要素に直接当てる」表層は似ていても、Tailwind が提供する一貫性・状態・レスポンシブは、インラインスタイルには原理的にない価値です。ただし「魔法の数字（magic number）を散らかしうる」という危うさは、任意の値の乱用（第27章）として現実に存在するため、批判が全く的外れというわけでもありません。
28.3 批判③「関心の分離に反する」
批判の主張: HTML（構造）と CSS（見た目）は分離すべきであり、見た目を HTML に書き込む Tailwind は、長年確立されてきた「関心の分離」の原則に反する、というものです。これは最も思想的で根深い論争です。
反論: Adam Wathan の主張（第2章）は、「分けるべきは HTML と CSS ではなく、再利用できるものとできないものだ」という関心の分離の再定義でした。.hero-title のようなクラスは、ファイルが分かれていても HTML の構造に CSS が依存しており、本当の意味では分離していない、と。
評価: ここはどちらが正しいと断定できない、価値観の対立です。「構造と表現の分離」を重んじる立場からは Tailwind は退歩に見え、「再利用性と変更容易性」を重んじる立場からは前進に見えます。重要なのは、これが技術的な優劣ではなく、何を重視するかの選択だと理解することです。本書は Tailwind を解説する本ですが、セマンティックな CSS（BEM など）の思想にも合理性があることは、公平に認めるべきです。
28.4 批判④「学習コスト」
批判の主張: 既存の CSS 知識があっても、Tailwind 独自のクラス名（flex はともかく shrink-0・inset-0・tracking-tight など）を新たに覚える必要があり、学習コストが高い。CSS を知っていれば素の CSS の方が早い、というものです。
反論: クラス名の多くは CSS プロパティの短縮形であり（第15章・第16章の対応表）、エディタの補完（第9章）があれば暗記は不要。一度慣れれば、命名やファイル往復が消える分むしろ速い、という反論です。
評価: 短期的には批判が正しく、長期的には反論が正しい、というのが実態に近いでしょう。導入直後は確かに遅くなります。CSS に習熟した人ほど「自分の知識が使えない」もどかしさを感じます。しかし数週間で慣れ、その後は生産性が上がるという声が多い。「最初は遅い」というコストは実在するので、チーム導入時はこの立ち上がり期間を見込む必要があります。
28.5 批判⑤「ロックインと移植性」
批判の主張: HTML が Tailwind のクラスで埋め尽くされると、後から Tailwind をやめるのが極めて困難になる。特定のツールにロックインされ、移植性が下がる、というものです。
反論: ユーティリティは結局ただの CSS クラスであり、最終的な生成物は標準的な CSS と HTML です。また、これは Tailwind 固有の問題ではなく、CSS-in-JS でも独自の命名規則でも、何らかの方式を採用すれば程度の差こそあれ移行コストは生じる、という反論です。
評価: この批判には現実的な重みがあります。Tailwind をやめる場合、HTML に散らばったクラスを別の方式へ移すのは大仕事です。ただし「移行が大変」なのはどんな CSS 方針でも同じで、Tailwind だけが特別に悪いわけではありません。公平に言えば、「採用は容易だが撤退は重い」という性質を理解したうえで選ぶべき、ということになります。導入前に「このプロジェクトで Tailwind を長く使い続ける見込みがあるか」を考えるのが賢明です。
28.6 計測できる効果の実態
主観的な論争だけでなく、計測しやすい効果も見ておきましょう。
- CSS サイズ: 第3章・第4章で見たとおり、CSS は使うユーティリティの種類数で頭打ちになり、プロジェクトが大きくなっても線形には増えません。大規模・長期のプロジェクトほど、この効果は明確です。
- 変更容易性: 「この CSS を消すと何が壊れるか分からない」という恐怖（第1章）が小さくなります。ユーティリティは局所的で、他へ波及しないからです。
- 開発速度: 立ち上がり後は、命名とファイル往復が消える分、速くなるという報告が多い。ただしこれは定量化が難しく、チームや個人差が大きい点は留意が必要です。
これらは「Tailwind の宣伝文句」ではなく、仕組みから説明できる性質です。とはいえ、どの効果も「プロジェクトの規模・寿命・チーム」に強く依存します。小さく短命なサイトでは、これらの利点はほとんど効きません。
28.7 結論: 向くプロジェクト・向かないプロジェクト
公平な評価を踏まえた結論です。
向いている:
- 中〜大規模で、長く保守されるアプリケーション。
- React / Vue や Rails の ViewComponent など、コンポーネント化の手段がある環境。
- デザインの一貫性をチームで仕組みとして担保したい場合。
慎重になるべき:
- ごく小さく短命な静的ページ（利点が効かず、学習コストだけ残る）。
- コンポーネント化の仕組みがなく、長いクラス列を手でコピーし続ける環境。
- チームが強くセマンティック CSS の思想を支持しており、その合意がある場合（無理に変える必要はない）。
Tailwind は「あらゆる場面で最善」ではありません。強みと弱みを理解し、プロジェクトの性質と照らして選ぶべき道具です。具体的な採用判断のチェックリストは、次の第8部・第31章にまとめます。