ここまでの回で、Tailwindの書き方はひととおり手に入りました。最後は使う・使わないの判断です。
Tailwindは万能ではありません。向いている場面ではとても強く、向いていない場面では素のCSSより手間が増えます。この見分けができるようになれば、道具として使いこなせている状態です。
判断の軸はひとつ
いろいろな比較ができますが、いちばん効く問いはこれです。
つまり判断はこうなります。
- 長く育てる・人が入れかわる・部品を使い回す → Tailwindが効く
- 1回作って終わり・自分ひとり・ページが数枚 → 素のCSSで十分
場面別の判断
| 作るもの | おすすめ | 理由 |
|---|---|---|
| CSSを学習中の練習ページ | 素のCSS | プロパティを自分で書くことが練習になる |
| ポートフォリオ・1枚もののLP | 素のCSS | ビルドを増やす価値が薄い |
| 数ページの小さなサイト | どちらでも | 好みで決めていい規模 |
| 何十ページある企業サイト | Tailwind | 余白や色がそろう。CSSが太らない |
| 長く運用するサービス | Tailwind | 「消せる」が効いてくる |
| ReactやVueで部品を作る | Tailwind | 部品とスタイルが同じ場所にある |
| チームで開発する | Tailwind | 命名で悩まない。刻みが共通言語になる |
| デザインが1枚1枚違う作品サイト | 素のCSS | 使い回しがないので利点が出ない |
| WordPressの既存テーマを直す | 素のCSS | 既存のCSSに合わせるほうが安全 |
クラスが長すぎるときの対処
Tailwindの最大の不満は「HTMLが長くなる」ことです。対処には順番があります。上から試してください。
①並べる順番を決める（まずこれ）
<!-- 接頭辞なし → md: → lg: の順にそろえる -->
<div class="grid grid-cols-1 gap-4 p-4 md:grid-cols-2 md:gap-6 lg:grid-cols-3">これだけで体感の読みやすさが大きく変わります。 何も導入せずにできる対処なので、まずここから。
②部品（コンポーネント）として切り出す
同じクラスの並びを3回以上書いているなら、それは部品にすべきサインです。ReactやVue、あるいはWordPressのテンプレートパーツでもいいので、繰り返しているHTMLごとまとめます。
// クラス列は1か所だけ。使う側は短い
function Button({ children }) {
return (
<button className="px-6 py-3 bg-orange-500 text-white font-bold rounded-full hover:bg-orange-600 transition">
{children}
</button>
);
}Tailwindが本領を発揮するのはこの形です。 「クラスが長い」問題は、部品化で解けるように設計されています。
③@applyでまとめる（最後の手段）
CSSの中で@applyを使うと、ユーティリティをまとめて1つのクラスにできます。
.btn {
@apply px-6 py-3 bg-orange-500 text-white font-bold rounded-full;
}短くなって嬉しく見えますが、これをやるとTailwindの利点がほぼ消えます。
.btnがどこで使われているか分からなくなる（＝消せなくなる）- HTMLを見ても見た目が分からなくなる（CSSを開きに行くことになる）
- 結果として、素のCSSに戻ってビルドの手間だけが残る
使うとしても、本当に何十か所で使うボタン1種類のような場面に限ってください。「クラスが長いから@applyで全部まとめる」を始めると、Tailwindを使う理由がなくなります。
素のCSSと混ぜるときの線引き
混ぜて構いません。実際、多くのプロジェクトが混ぜています。大事なのはどちらで書くかの線引きを決めることです。
おすすめの分け方はこうです。
| 内容 | どちらで書くか |
|---|---|
| 配置・余白・幅（レイアウト） | Tailwind |
| 色・文字サイズ・角丸 | Tailwind |
| ホバーやフォーカスの変化 | Tailwind |
複雑な@keyframesアニメーション | 素のCSS |
::before／::afterを凝った装飾 | 素のCSS |
| サイト全体の文字・リンクの既定スタイル | 素のCSS |
| 印刷用のスタイル | 素のCSS |
ユーティリティで素直に書けるものはTailwind、書きにくいものは素のCSSというだけの話です。無理にTailwindで表現しようとして[&>*:nth-child(3)]:mt-[13px]のような読めないクラスになるくらいなら、素のCSSで数行書くほうが親切です。
Tailwindを学んで、素のCSSに返ってくるもの
このコースをここまで進めた人には、素のCSSに戻っても残る収穫があります。
- 余白を刻みで考えるクセ——
13pxではなく16pxか24px。これは素のCSSでも変数にすれば同じことができます - モバイルファーストの型——
min-widthだけで書く癖がつきます - 「消せるか」という視点——素のCSSを書くときも、消せる構造を意識するようになります
つまりTailwindを使わない選択をしたとしても、学んだことは無駄になりません。道具の思想だけ持ち帰って、素のCSSで実践するのも立派な使い方です。
べんりワザSassは今も必要？同じ「使う・使わない」の判断は、Sassについてもまとめていますこのレッスンのまとめ
- 判断の軸は「そのCSS、半年後に誰かが消せるか」
- 長く育てる・部品を使い回す・チームで開発ならTailwindが効く
- 1枚もの・学習中・既存サイトの改修なら素のCSSが素直
- クラスが長いときは「順番をそろえる → 部品化する」の順。
@applyは最後の手段 @applyを多用すると、Tailwindの利点が消えて素のCSSに戻る- 混ぜてよいが、同じプロパティを両方から指定しない
- 刻みで考える・モバイルファースト・消せる構造——素のCSSに戻っても残る収穫
道具は、選べる状態になったときにはじめて道具になります。使う理由と使わない理由の両方を言えるようになったなら、このコースの目的は達成です。