Tailwind CSS

Tailwind CSSとは

Tailwind CSSは、ユーティリティファーストという考え方の [[CSS]] フレームワークです。1つのクラスが1つのスタイルに対応し、クラスの組み合わせでデザインを作ります。

<div class="p-4 rounded-lg bg-teal-500 text-white font-bold">
  余白4 + 角丸 + ティール背景 + 白文字 + 太字
</div>

初学者向けポイント

• p = padding、m = margin。数字は 1 = 0.25rem(4px)。p-4 なら16px
• text-xl = 文字サイズ / font-bold = 太字 / flex grid = 並べ方
• md:flex のようにプレフィックスを付けると「画面幅md以上で適用」(レスポンシブ)
• hover:bg-blue-500 のように状態(ホバー・フォーカス)も同じ記法で書ける

メリットと注意点

v4 のポイント

• 設定ファイル(tailwind.config.js)が不要になり、CSS内の @theme { } でカスタムトークンを定義する
• [[Vite]] プラグイン(@tailwindcss/vite)で高速にビルドできる

なぜクラス名を考えなくてよいのか

素の [[CSS]] を書くとき地味に消耗するのが名前付けです。.card-header-title--active のような名前を考え、CSSファイル側にルールを書き、HTMLとCSSを行き来しながら直します。さらに厄介なのは消せなくなることです。あるクラスがどこで使われているかは全ファイルを検索しないと分からず、不要になったCSSが「消したら何か壊れるかもしれない」と残り続けます。

ユーティリティファーストはこの構造ごと避けます。p-4 の意味は常に「padding: 1rem」で、どの画面でも変わりません。スタイルは使う場所に書いてあるので、要素を消せばスタイルも一緒に消えます。詳細度の争いも起きにくく、「なぜか別のCSSに勝てない」で悩む時間が減ります。

生成されるCSSはどう決まるか

Tailwind は全ユーティリティを詰め込んだ巨大なCSSを配るわけではありません。ビルド時にソースコードを文字列として走査し、実際に登場したクラス名に対応するCSSだけを生成します。組み合わせが何万通りでも、出力は使った分だけです。

ここに初学者が必ず一度はまる落とし穴があります。

// 生成されない: "text-red-500" という文字列がソース上に存在しない
<p className={`text-${color}-500`}>危険</p>

// 生成される: クラス名が完全な文字列として書かれている
<p className={isDanger ? 'text-red-500' : 'text-slate-500'}>危険</p>

たちが悪いのは、別の画面で text-red-500 を直接書いていると偶然動いてしまう点です。後日そちらを消した瞬間に、無関係に見える場所の色が消えます。クラス名は必ず完全な文字列で書いてください。

つまずきやすいところ

• 同じ種類のクラスを重ねると勝敗が読めない — p-2 p-4 と並べても、勝つのは class 属性の順ではなく生成されたCSS側の並び順です。条件分岐ではどちらか一方だけを出力します
• 任意の値は逃げ道であって既定路線ではない — mt-[13px] のように角括弧で任意の値も書けますが、多用すると「決まった段階から選ぶ」という一貫性の利点が消えます。まず既定のスケール(mt-3 = 12px、mt-4 = 16px)で足りるか確かめます
• @apply でまとめすぎない — 複数のユーティリティを1つのクラスに束ねる @apply は便利ですが、多用すると「名前を考えて別ファイルを行き来する」元の世界に戻ります。繰り返しはCSSではなく [[React]] のコンポーネントとして切り出すのが基本です
• class 属性は長くなる — ボタン1つで10個以上並ぶこともあります。並び順の整形はフォーマッタに任せ、長さ自体は仕様として受け入れるのが現実的です

ここから先を選ぶ地図

Tailwind は「CSSを書かなくてよくする道具」ではなく、「CSSの知識をクラス名の形で使う道具」です。次は土台を埋めるか、隣の流儀と比べるか、アプリへ組み込むかです。

ユーティリティ名の元になる概念を押さえる

flex grid gap-4 md: といったクラスは、CSSの機能名がほぼそのまま名前になっています。[[CSS]] のボックスモデルとカスケード、[[FlexboxとGrid]] の主軸と交差軸、[[レスポンシブデザイン]] のブレークポイントとモバイルファーストを知らないままだと、クラスを丸暗記することになります。逆にここを押さえれば、覚えるのは「あのCSS機能はどんなクラス名か」だけになります。md:flex が「md以上で適用」という向きなのも、モバイルファーストの裏返しです。

別の流儀と比べて選ぶ

「CSSをどう書くか」に唯一の答えはありません。変数・ネスト・ミックスインでCSS自体を拡張する [[CSSプリプロセッサ(Sass)]] は、正反対に「CSSをしっかり書く」方向の解です。既存プロジェクトでは現役なので、どちらも読めると選択肢が広がります。「CSSフレームワーク」という呼び名の中身を整理したいときは [[フレームワーク]] へ。

アプリに組み込む

実務ではビルドツールとセットです。[[Vite]] に公式プラグインを入れるのが出発点で、[[React]] のようなコンポーネント指向のUIと組み合わせると、長いクラス列を部品の内側に閉じ込められます。

見た目以外の品質を落とさない

ユーティリティが面倒を見るのは見た目だけです。div にクラスを並べてボタンそっくりに作っても、キーボード操作や読み上げには届きません。要素の選び方は [[Webアクセシビリティ]] の担当範囲です。また出力CSSが使った分だけでも、画像やJavaScriptを含む表示速度は別問題です([[Webパフォーマンス最適化]])。

関連技術とのつながり

• [[CSS]] — Tailwindが生成する実体。ユーティリティの意味を理解するにはCSSの知識が必要
• [[React]] — コンポーネント単位でクラスを閉じ込められるため相性がよい
• [[Vite]] — 公式プラグインでシームレスに統合できる
• [[フレームワーク]] — 「CSSフレームワーク」と呼ばれるが、処理の流れを預ける制御の反転は伴わず、書いたクラスに対応するCSSを生成する道具に近い

Q: Tailwindが出力するCSSはどのように決まる?
- [ ] すべてのユーティリティを含む固定のCSSがそのまま配信される
- [x] ソースコードを文字列として走査し、実際に登場したクラス名の分だけ生成される
- [ ] ブラウザが表示のたびに必要なCSSを組み立てる
解説: ビルド時の走査で見つかったクラス名だけがCSSになります。そのためクラス名を変数で組み立てると走査に引っかからず生成されません。

Q: `p-4` が表す余白の大きさはどれ?
- [ ] 4px
- [x] 16px
- [ ] 40px
解説: 数字の1が0.25rem(4px)に対応するため、p-4 は 4 × 4px = 16px の padding になります。

Q: `@apply` を多用すると起きる問題として本文が挙げているのはどれ?
- [ ] ブラウザがユーティリティクラスを解釈できなくなる
- [ ] 任意の値が一切書けなくなる
- [x] 名前を考えて別ファイルを行き来する、ユーティリティ以前の状態に戻ってしまう
解説: 繰り返しはCSSのクラスに束ねるのではなく、Reactなどのコンポーネントとして切り出すのが基本です。