Tailwind CSS v4 とは何が変わったか？Oxide エンジン・CSS first 設定・自動コンテンツ検出を整理

Q: Q. 「tailwind.config.js」 は完全に消えますか？

A. 消える方向ですが、必要なら残せます。「JS で動的に色を生成したい」 などの特殊ケースのために、「tailwind.config.ts」 を引き続き使う道は残っています。多くの案件では 「@theme」 だけで足ります。

Q: Q. v3 から v4 に上げると何か壊れますか？

A. 大半は 「@tailwindcss/upgrade」 で対応されますが、「 色の解釈の細部」 「transition の挙動」 「カスタムプラグイン」 で差分が出る ことがあります。E2E / Visual Regression テストで確認するのが安全です。

Q: Q. Tailwind と shadcn/ui は v4 でも使えますか？

A. shadcn/ui は v4 対応版が公式に提供されている ため、新規導入は v4 ベースの shadcn で問題ありません。既存プロジェクトの 「v3 ベース shadcn → v4 ベース shadcn」 への移行は、コンポーネントのテンプレ差分を見ながら手動で寄せていくのが現実的です。

Q: Q. PostCSS / Vite / Next.js のどれを使うべきですか？

A. 新規 Vite プロジェクトなら 「@tailwindcss/vite」 が圧倒的に楽です。Next.js は公式ガイドに従えば PostCSS 経由でも特に問題なく動きます。「PostCSS のプラグインチェーンを意識せずに済む」 のが Vite プラグインの利点です。

Q: Q. レガシーブラウザ対応はどうしたらいいですか？

A. v4 はモダンブラウザを前提にしています。「どうしても古い環境をサポートする必要がある」 案件では、v3 を使い続ける のが現実的な選択です。「既存 v3 でも長く使える」 ことは Tailwind チームから明言されています。

Q: Q. デザイントークンを Figma などと同期したいです。

A. 「@theme」 が 「CSS 変数の集合」 なので、Figma Variables から CSS 変数を生成 → @theme に貼る という流れが組みやすくなりました。「デザインツール → コードの一方向同期」 を仕組み化しやすい設計です。

Q: Q. Tailwind v4 を学ぶ最短ルートは？

A. ① 新規 Vite プロジェクトを 「@tailwindcss/vite」 で立てる、② 「@theme」 でテーマ変数を1つ追加してみる、③ 「container queries」 のような新機能を1つだけ触ってみる、の3ステップが速いです。「設定の薄さ」 を体感するのが、v4 の良さを掴む一番の近道です。

先に要点

Tailwind CSS v4 は、「Rust 製の新エンジン Oxide」と CSS first 設定方式を中心とした大刷新メジャー。「tailwind.config.js を捨てて CSS にまとめる」という方向に振り切ったのが最大の変化。
設定は「@import "tailwindcss";」 + 「@theme { ... }」のように CSS ファイルの中で完結する。「JS / TS で色やフォントを定義する」古い書き方から、「CSS 変数で表現する」形に統一された。
ビルドが速い(数十倍速くなったケースもある)、自動でコンテンツを検出する(「content」設定を書かないでもよくなる)、Vite プラグインが公式に用意されたなど、「使い始める手間が大きく減った」のが体感できる変化。
移行は `アップデートツール(「npx @tailwindcss/upgrade」)」でかなり自動化できる。「 v3 のままで困っていないなら急がない」もアリ、「新規は v4 から」が現実的な選び方。

Tailwind v4 ってよく見るけど、結局 v3 と何が違うの？ tailwind.config.js が消えるって本当？ `「@theme」ってどう書くの？」 ── Tailwind の v4 は、「これまでの設定の感覚が割と変わる」メジャーアップデートでした。

ざっくり言うと、Tailwind v4 は 設定を CSS の中に寄せ、Rust 製の新エンジンに乗せ替えた アップデートです。これまでの「tailwind.config.js を書いて、PostCSS を整える」という JS/TS 中心の世界から、CSS ファイルだけで完結させる 方向へ大きく舵が切られています。

この記事では、2026年5月時点の Tailwind CSS v4 の状況をベースに、何が変わったか・どう書くか・移行のコツ・採用判断軸 を、「v3 までは触っているけど v4 はまだ」レベルから順に整理します。仕様は安定しつつも細部が更新されることがあるので、最終確認は公式ドキュメントを見るのが安全です。

v4 で何が変わったか — 5つの核

「大きな変更点はどこ？」を5つにまとめます。

①Rust 製エンジン Oxide

ビルドエンジンを Rust に書き直した「Oxide」を採用。「初回ビルドも更新ビルドも数倍〜数十倍速い」という体感の差。大規模プロジェクトほど効く。

② CSS first の設定方式

「 tailwind.config.js」を必須としない。「@import "tailwindcss";」 + 「@theme { ... }」で CSS ファイルだけで設定が完結する。JS で色を定義する代わりに CSS 変数で書く。

③ 自動コンテンツ検出

v3 では「content: ['./src/**/*.{html,tsx}']」を設定していたが、v4 はファイルを自動で見て使われているクラスを検出する。「設定し忘れて空のCSSになる」事故が激減。

④ 公式 Vite プラグイン

「@tailwindcss/vite」が用意され、「PostCSS 設定なしで Vite に統合」できる。Next.js / Vercel も含めて、フレームワーク側のプラグインが整備された。

⑤ モダン CSS 機能の活用

「 color-mix()」「@property」「container queries」など、現代の CSS 機能をデフォルトで使う設計。「変数を引数で渡せる」ような JS 寄りの工夫を CSS 標準だけで実現する。

要するに JS と PostCSS の世界から、CSS ファースト + Rust エンジンの世界へ 進化したのが v4 です。この方向性は Tailwind 自身の哲学「CSS で書くことに重さを感じないこと」をさらに推し進めた、と捉えると分かりやすいです。

CSS first 設定の書き方

「v3 では JS で書いていた設定」が、「v4 ではどう書くか」を具体例で比較します。

v3 の書き方(従来)

// tailwind.config.js
module.exports = {
  content: ['./src/**/*.{html,tsx}'],
  theme: {
    extend: {
      colors: {
        brand: { 500: '#2f5c55' },
      },
      fontFamily: {
        display: ['"Yu Mincho"', 'serif'],
      },
    },
  },
};

/* src/index.css */
@tailwind base;
@tailwind components;
@tailwind utilities;

v4 の書き方(CSS first)

/* src/index.css */
@import "tailwindcss";

@theme {
  --color-brand-500: #2f5c55;
  --font-display: "Yu Mincho", serif;
}

「@import "tailwindcss";」

v3 の「@tailwind base; @tailwind components; @tailwind utilities;」を1行に統合。

「@theme { ... }」

カラー・フォント・スペーシング・ブレークポイントなど、テーマ全体を CSS 変数で定義 する。「--color-brand-500」のように書くと「bg-brand-500」「text-brand-500」等のクラスが自動で生成される。

「content」が不要

自動コンテンツ検出のおかげで、「使われている所からクラスを拾ってくる」のがデフォルト。新しいフォルダを追加しても設定変更が要らない。

JS 設定との併用

必要なら「tailwind.config.ts」を使い続けることもできる。「JS の中で動的に何かを生成したい」ケースのために残された逃げ道。

「デザインシステム = CSS 変数の集合」という設計に一段近づいた、というのが v4 の核心です。

自動コンテンツ検出の仕組み

「どうやって使われているクラスを見つけるの？」を整理します。

プロジェクト全体をスキャン

「.gitignore」と「node_modules / build / dist」などを除いて、リポジトリ内のテキストファイルから「Tailwind クラスっぽいトークン」を抽出。

パフォーマンスの工夫

Rust エンジン + 並列処理で、初回スキャンも実用範囲。「大量のファイルを毎回読む」のではなく、「変更があったところだけ再評価」のキャッシュ機構を持つ。

追加で指定したいとき

「@source」ディレクティブを CSS に書くと、「このフォルダもスキャン対象に追加」を明示できる。デフォルトの自動検出から外れる外部パッケージなどに使える。

逆に除外したいとき

「@source not」 / 「.gitignore」 / 明示的なフラグで「見ない場所」を指定できる。「使われていないクラスがビルドに混ざる」ケースを避けられる。

「使われているクラスが自動的に最終 CSS に含まれる」という基本動作はそのままで、設定の手間だけ減った、というのが体感です。

モダン CSS 機能の活用

v4 は「モダンブラウザ前提」を強く打ち出していて、以前は JS で頑張っていた部分を CSS だけで書けるようになりました。

color-mix() を内部で活用

「bg-blue-500/50」のような不透明度付き表現を、「color-mix(in oklab, var(--color-blue-500), transparent 50%)」のように生成。「動的な色変換」が CSS 側で柔軟に書ける。

container queries 標準対応

「@container」系のユーティリティ(「@sm:」「@md:」)が正式採用。`コンポーネント単位で「小さい時はこう表示」を書ける」のは v3 時代より遥かに自然。

3D 変換

「rotate-x-12」「rotate-y-12」「perspective-distant」等の 3D 変換ユーティリティを正式サポート。「3D を CSS だけで」が標準ツールキット入り。

@property による型付き変数

CSS 変数を「@property」で宣言することで、「アニメーション可能な型付き変数」を Tailwind 側が裏で活用。「カスタムプロパティ間の補間アニメーション」が無理なく書ける。

「モダン CSS をフル活用したフレームワーク」という方向に振り切ったので、「古いブラウザ対応が必要な案件」では一度確認が必要、というのも併せて覚えておくと安全です。

v3 からの移行

「既存プロジェクトをどう v4 に上げるか」の現実的な手順を整理します。

読み込み中...

「config を完全に CSS first にしないと使えない」わけではなく、段階的に CSS first に寄せていける ように設計されているのが移行のしやすさに繋がっています。

いつ v4 にすべきか

採用判断の目安を整理します。

新規プロジェクト

素直に v4。「tailwind.config.js を書かなくていい」だけで初期設定の時間が大きく減る。Next.js / Vite いずれも公式サポートがある。

v3 で動いている小〜中規模アプリ

「急ぐ必要は薄い」。アップグレードツールで動けばラッキーくらいの気持ちで、「時間が取れた週末」にやるのが楽。

v3 で動いている大規模アプリ

計画的に。「config が肥大化している」場合は CSS first にする利益が大きいが、「E2E / Visual Regression / デザインシステム連携」をどこまで影響範囲として捉えるかが分かれ目。

古いブラウザ対応が必要

v4 はモダンブラウザ前提が強い。「IE / 古い Safari / 古い Android」をどこまでサポートするか要件で要確認。「業務要件として古い環境がない」場合は問題なし。

「v4 がリリースされた = 全員今すぐ移行すべき」ではない、というのは Tailwind チームも公式に言っているスタンスです。ただし 新規プロジェクトをこれから始めるなら v4 が現実的な選択 というのは間違いなく、「これから1年使う設定」を書くなら v4 を選んでおくのが将来的に楽です。

AI 時代の Tailwind v4

AI 連携の文脈で v4 が嬉しい場面もあります。

v0 / AI コード生成との親和性

[v0 が生成するコード](/articles/what-is-v0-vercel-ai-ui-generator-usage) は Tailwind 前提。「設定が CSS だけで完結」する v4 は、「AI が出力した CSS をそのまま貼って動く」確率が上がる。

プロンプトに含めやすい

「 @theme で色とフォントを定義し、bg-brand-500 などのユーティリティで使う」のような形は、LLM への説明が短くて済む。「設定の説明」にトークンを消費しなくて済む。

高速ビルド × 試行回数

AI で UI を「試して直す」反復を、Oxide エンジンの速さがそのまま支える。「数秒の保存リロード」が積み重なる時代に、「1秒で反映される」のは体感価値が大きい。

デザインシステムの構造化

「 CSS 変数として色 / フォントを公開」することで、AI 側に「使えるトークン一覧」を渡しやすい。「そのテーマで作って」と頼める世界。

「AI が UI を書く時代」の足回りとして、CSS first の Tailwind v4 はかなり良い相性を持っています。

Tailwind CSS v4 に関するよくある質問

Q. 「tailwind.config.js」は完全に消えますか？

A. 消える方向ですが、必要なら残せます。「JS で動的に色を生成したい」などの特殊ケースのために、「tailwind.config.ts」を引き続き使う道は残っています。多くの案件では「@theme」だけで足ります。

Q. v3 から v4 に上げると何か壊れますか？

A. 大半は「@tailwindcss/upgrade」で対応されますが、「色の解釈の細部」「transition の挙動」「カスタムプラグイン」で差分が出ることがあります。E2E / Visual Regression テストで確認するのが安全です。

Q. Tailwind と shadcn/ui は v4 でも使えますか？

A. shadcn/ui は v4 対応版が公式に提供されている ため、新規導入は v4 ベースの shadcn で問題ありません。既存プロジェクトの「v3 ベース shadcn → v4 ベース shadcn」への移行は、コンポーネントのテンプレ差分を見ながら手動で寄せていくのが現実的です。

Q. PostCSS / Vite / Next.js のどれを使うべきですか？

A. 新規 Vite プロジェクトなら「@tailwindcss/vite」が圧倒的に楽です。Next.js は公式ガイドに従えば PostCSS 経由でも特に問題なく動きます。「PostCSS のプラグインチェーンを意識せずに済む」のが Vite プラグインの利点です。

Q. レガシーブラウザ対応はどうしたらいいですか？

A. v4 はモダンブラウザを前提にしています。「どうしても古い環境をサポートする必要がある」案件では、v3 を使い続けるのが現実的な選択です。「既存 v3 でも長く使える」ことは Tailwind チームから明言されています。

Q. デザイントークンを Figma などと同期したいです。

A. 「@theme」が「CSS 変数の集合」なので、Figma Variables から CSS 変数を生成 → @theme に貼る という流れが組みやすくなりました。「デザインツール → コードの一方向同期」を仕組み化しやすい設計です。

Q. Tailwind v4 を学ぶ最短ルートは？

A. ① 新規 Vite プロジェクトを「@tailwindcss/vite」で立てる、② 「@theme」でテーマ変数を1つ追加してみる、③ 「container queries」のような新機能を1つだけ触ってみる、の3ステップが速いです。「設定の薄さ」を体感するのが、v4 の良さを掴む一番の近道です。

参考リンク

Tailwind CSS: 公式サイト
Tailwind CSS v4: Upgrade Guide
Tailwind CSS: @theme reference
Tailwind CSS: Vite plugin
shadcn/ui: 公式
MDN: container queries