Tailwind CSS v4 新機能解説：パフォーマンス、設定、移行ガイド

35 ミリ秒。これは Tailwind v3 で 1 回の増分ビルドにかかる時間です。結構速いですよね？でも、v4 では同じ操作がたった 192 マイクロ秒で完了します。ミリ秒じゃなくて、マイクロ秒です。約 200 倍も速くなりました。

正直なところ、最初このデータを見たときは疑いました。マーケティングの宣伝文句だろうと。でも実際に移行を試して、HMR が 340ms から 12ms まで高速化されるのを見て、ようやく実感しました。今回は本気です。

これは Rust で書き直された Oxide エンジンによる本当の変化です。「少し速くなった気がする」という心理的なものではありません。padding を変更したら、瞬きする前にページがリフレッシュされるような体験です。Tailwind v4 は単にエンジンを変えただけではありません。設定方法（JS から CSS へ）、インストール手順（ゼロ設定）、ユーティリティクラスの構文（不透明度修飾子、Container Queries、3D Transforms…）すべてが変わりました。

この記事では、これらの変化をわかりやすく解説し、すぐに使える移行チェックリストを提供します。

Oxide エンジン——なぜ v4 はこんなに速いのか？

こんな経験はありませんか？色を変更して保存し、ブラウザで数秒待ってようやく変化が反映されるのを。大規模プロジェクトでは、Tailwind v3 の増分ビルドで少しイライラすることがあります。特に締め切りが迫っているときは。

v4 の Oxide エンジンは、この問題を解決するために登場しました。Tailwind チームは既存の JS エンジンに手を加えるのではなく、Rust でコンパイラ全体をゼロから書き直しました。これは大胆な決断ですが、確実な成果をもたらしました。

パフォーマンスは実際どれくらい向上したのか？

公式が Catalyst プロジェクトでベンチマークを公開しています。データは一目瞭然です。

テストシナリオ	v3.4	v4.0	向上倍率
フルビルド	378ms	100ms	3.78倍
増分ビルド（CSS 変更あり）	44ms	5ms	8.8倍
増分ビルド（CSS 変更なし）	35ms	192µs	182倍

この最後のデータが特に驚異的です。HTML 構造だけを変更して新しい CSS クラスを追加しない場合、v4 のビルド時間はマイクロ秒レベルに入ります。この遅延は体感できません。

本番プロジェクト（500+ コンポーネントのコードベース）からのデータもあります。

指標	v3.4	v4.0	変化
コールドスタートビルド	12.3s	1.8s	85% 高速化
開発サーバー起動	4.2s	0.8s	81% 高速化
HMR 更新	340ms	12ms	96% 高速化
本番 CSS サイズ	48KB	31KB	35% 削減
メモリ使用量	180MB	45MB	75% 削減

96%

HMR 高速化

来源: Tailwind CSS v4 公式ベンチマーク

HMR が 340ms から 12ms になったことで、開発体験への影響は劇的です。以前はスタイルを変更するたびに「明らかな待ち時間」がありましたが、今は基本的に即座に反映されます。

Oxide は何を変えたのか？

Oxide エンジンの核心は Rust + Lightning CSS です。Rust のパフォーマンス優位性は周知の事実ですが、より重要なのはアーキテクチャレベルの変化です。

統合ツールチェーン。v3 時代、Tailwind は PostCSS エコシステムに依存し、autoprefixer、cssnano などの追加設定が必要でした。v4 はこれらをすべて組み込み、Lightning CSS という 1 つのパッケージのみに依存します。中間層が減り、自然と速くなりました。

スマートコンテンツ検出。以前は tailwind.config.js で content 配列を手動設定し、Tailwind にどのファイルをスキャンするか指示する必要がありました。v4 は .gitignore とモジュールグラフを直接読み取り、スキャンが必要なファイルを自動検出します。設定が減り、より高速になりました。

ネイティブ CSS 機能。v4 は本物の @layer ルール、@property カスタムプロパティ、color-mix() 色関数などのモダン CSS 機能を使用します。これらはブラウザがネイティブにサポートしており、コンパイル時の変換が不要です。

正直なところ、これらの技術的詳細を完全に理解する必要はありません。重要なのは結果です。ビルドが速くなり、設定が減り、開発体験が良くなりました。

CSS-first 設定——tailwind.config.js に別れを

これは v4 で最も大きな変化であり、移行コストも最も高い部分です。

以前は tailwind.config.js で設定を書いていましたが、v4 では CSS ファイルで @theme ディレクティブを使います。正直、最初はかなり違和感がありました。数年間 JS 設定を書いてきたので、突然 CSS 変数を書くのは少し戸惑いました。でも、しばらく使ってみると、この方が CSS の考え方に合っていると感じるようになりました。

設定の移行：変更前と変更後

まず最もシンプルな例を見てみましょう。プライマリカラーをカスタマイズする場合です。

// v3: tailwind.config.js
module.exports = {
  theme: {
    extend: {
      colors: {
        primary: '#3b82f6',
      },
    },
  },
}

v4 では、これらはすべて CSS に移動します。

/* v4: app.css */
@import "tailwindcss";

@theme {
  --color-primary: #3b82f6;
}

お気づきかもしれませんが、変数名が primary から --color-primary に変わりました。これは v4 に厳格な命名プレフィックスルールがあるためです。

変数命名規則の対応表

v3 設定項目	v4 CSS 変数プレフィックス	例
colors	—color-*	—color-primary: #3b82f6
spacing	—spacing-*	—spacing-128: 32rem
fontSize	—text-*	—text-xs: 0.75rem
fontFamily	—font-*	—font-sans: “Inter”
borderRadius	—radius-*	—radius-lg: 0.5rem
screens	—breakpoint-*	—breakpoint-md: 768px
boxShadow	—shadow-*	—shadow-card: 0 4px 12px rgba(0,0,0,0.1)
animation	—animate-*	—animate-spin: spin 1s linear infinite

このプレフィックスシステムは最初は煩雑に感じるかもしれませんが、利点があります。変数名を推測する必要がありません。フォントサイズの変数はどう書けばいいか？必ず --text- で始まります。

より複雑な設定例

少し複雑な例を見てみましょう。v3 の設定が以下のような場合です。

// v3: tailwind.config.js
module.exports = {
  theme: {
    extend: {
      colors: {
        brand: {
          light: '#f0f9ff',
          DEFAULT: '#0ea5e9',
          dark: '#0369a1',
        },
      },
      fontFamily: {
        display: ['Cal Sans', 'sans-serif'],
      },
      animation: {
        'fade-in': 'fadeIn 0.5s ease-out',
      },
    },
  },
  plugins: [
    require('@tailwindcss/typography'),
  ],
}

v4 に移行すると以下のようになります。

/* v4: app.css */
@import "tailwindcss";

@theme {
  /* カラー */
  --color-brand-light: #f0f9ff;
  --color-brand: #0ea5e9;
  --color-brand-dark: #0369a1;

  /* フォント */
  --font-display: "Cal Sans", sans-serif;

  /* アニメーション */
  --animate-fade-in: fadeIn 0.5s ease-out;
}

/* プラグイン */
@plugin "@tailwindcss/typography";

いくつかの変化に注目してください。

カラー階層のフラット化。v3 はネストされたオブジェクト brand.light をサポートしていましたが、v4 では --color-brand-light と書く必要があります。
プラグインは @plugin で導入。JS で require する必要はありません。
DEFAULT サフィックスの消失。brand のデフォルトカラーは直接 --color-brand と書きます。

ダークモードの設定

v3 のダークモード設定は以下のようでした。

// v3
module.exports = {
  darkMode: 'class', // または 'media'
}

v4 はデフォルトで media 戦略（システムに追従）を使用します。class に変更したい場合、CSS に 1 行追加します。

/* v4 */
@import "tailwindcss";
@variant dark (&:where(.dark, .dark *));

この行は、要素またはその親に .dark クラスがある場合、ダークモードスタイルを適用することを意味します。

コンテンツ検出の設定

以前は、スキャンするファイルを手動で指定する必要がありました。

// v3
module.exports = {
  content: [
    './src/**/*.{js,ts,jsx,tsx}',
    './public/index.html',
  ],
}

v4 は自動的に .gitignore を読み取り、除外したファイルを無視し、プロジェクト内のすべての関連ファイルをスキャンします。プロジェクト構造が特殊な場合、@source で手動追加できます。

/* v4 */
@import "tailwindcss";
@source "../node_modules/my-ui-lib";

CSS-first 設定の最大のメリットは、スタイル関連の設定がすべて 1 つの CSS ファイルに集約されることです。JS と CSS の間を行き来する必要がありません。デメリットは、特に JS 設定に慣れている開発者にとって、適応期間が必要なことです。

インストールと統合——ゼロ設定の新体験

Tailwind v3 をインストールしたことがある人なら、その手順をご存じでしょう。3 つのパッケージをインストールし、設定ファイルを作成し、PostCSS を設定し、content 配列を書く…。複雑ではありませんが、新しいプロジェクトごとに毎回実行する必要があります。

v4 はこのプロセスを極限まで簡素化しました。

最もシンプルなインストール

Vite を使用している場合、2 つのステップだけです。

# 1. インストール
npm install tailwindcss @tailwindcss/vite

# 2. vite.config.js に 1 行追加
import tailwindcss from '@tailwindcss/vite'

export default {
  plugins: [tailwindcss()],
}

そして CSS ファイルに 1 行追加します。

/* app.css または index.css */
@import "tailwindcss";

これだけです。tailwind.config.js も postcss.config.js も content 配列もありません。すぐに使えます。

3 つの統合方法

Vite 統合（推奨）：

npm install tailwindcss @tailwindcss/vite

// vite.config.js
import tailwindcss from '@tailwindcss/vite'

export default {
  plugins: [tailwindcss()],
}

PostCSS 統合：

npm install tailwindcss @tailwindcss/postcss

// postcss.config.js
export default {
  plugins: {
    '@tailwindcss/postcss': {},
  },
}

CLI 使用：

npx tailwindcss -i input.css -o output.css --watch

最近のプロジェクトのほとんどは Vite 統合で十分です。PostCSS 方式は古いプロジェクトの移行に適し、CLI はビルドプロセスがないシナリオに適しています。

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

v4 では content 配列の設定が不要です。スキャンが必要なファイルを自動検出します。どうやって？

.gitignore ファイルを読み取り、スキャン不要なディレクトリ（node_modules、dist など）を除外し、残りのファイルで Tailwind クラス名を検索します。

このメカニズムには前提があります。プロジェクトが標準的な Node.js プロジェクト構造であること。テンプレートファイルを非常に特殊な場所（プロジェクトルートの外のフォルダなど）に置いている場合、手動で指定する必要があります。

@import "tailwindcss";
@source "../templates";  /* 手動でスキャンパスを追加 */

自動検出のもう 1 つのメリットは、新しいファイルを作成しても設定を変更する必要がないことです。以前はコンポーネントファイルを作成するたびに tailwind.config.js の content 配列を更新する必要がありました（ワイルドカード **/* を使用していれば不要ですが、一部のプロジェクト構造ではサポートされません）。今は完全に気にする必要がなく、新しいファイルを作成すればすぐに使えます。

破壊的変更と移行チェックリスト

ここが移行の核心です。でも心配しないでください。ほとんどの変更にはパターンがあり、公式が自動移行ツールを提供しています。

不透明度修飾子の変化

これが最も影響の大きい変更です。v3 では背景の不透明度を設定するには以下のようにしていました。

<!-- v3 -->
<div class="bg-blue-500 bg-opacity-50">...</div>

v4 では不透明度が色値に統合されました。

<!-- v4 -->
<div class="bg-blue-500/50">...</div>

背景色だけでなく、色に関連するすべてのプロパティがこの構文をサポートします。

<!-- 文字色の不透明度 -->
<p class="text-gray-900/75">...</p>

<!-- ボーダー色の不透明度 -->
<div class="border-red-500/30">...</div>

bg-opacity-* などのクラス名はどうなるのか？単に削除してください。v4 ではサポートされなくなりました。

リネームされたユーティリティクラス

v4 ではいくつかのユーティリティクラスがリネームされました。主に簡略化と意味調整のためです。

v3 クラス名	v4 クラス名	説明
`flex-grow`	`grow`	命名の簡略化
`flex-grow-*`	`grow-*`	命名の簡略化
`flex-shrink`	`shrink`	命名の簡略化
`flex-shrink-*`	`shrink-*`	命名の簡略化
`overflow-ellipsis`	`text-ellipsis`	分類の調整
`decoration-slice`	`box-decoration-slice`	分類の調整
`shadow-sm`	`shadow-xs`	サイズのリネーム
`shadow`	`shadow-sm`	サイズのリネーム
`rounded-sm`	`rounded-xs`	サイズのリネーム
`rounded`	`rounded-sm`	サイズのリネーム
`outline-none`	`outline-hidden`	意味の変更

shadow と rounded の変化に注意してください。以前の shadow は shadow-sm になり、以前の shadow-sm は shadow-xs になりました。これはサイズ命名の一貫性を高めるための意味調整です。

デフォルト値の変化

いくつかのデフォルト値が変更され、スタイルの不一致が発生する可能性があります。

border デフォルトカラー：v3 では gray-200 でしたが、v4 では currentColor に変更されました。つまり、ボーダー色が文字色に追従するようになります。

<!-- v3: ボーダーは灰色 -->
<div class="border text-blue-500">ボーダーは gray-200</div>

<!-- v4: ボーダーは文字色に追従 -->
<div class="border text-blue-500">ボーダーは blue-500</div>

ring デフォルト値：v3 では幅 3px、色 blue-500 がデフォルト。v4 では幅 1px、色 currentColor がデフォルト。

<!-- v3: ring は青色 3px -->
<button class="ring">...</button>

<!-- v4: ring は currentColor 1px -->
<button class="ring">...</button>

<!-- v3 の効果が必要な場合 -->
<button class="ring-3 ring-blue-500">...</button>

完全な移行チェックリスト

順番に実行してください。

依存関係をアップグレード

npm install tailwindcss@latest @tailwindcss/vite@latest

自動移行ツールを実行
```
npx @tailwindcss/upgrade
```
このツールは、@tailwind ディレクティブ、不透明度クラス名、リネームされたユーティリティクラスなど、大部分の構文を自動変換します。

CSS エントリーファイルを変換

/* v3 */
@tailwind base;
@tailwind components;
@tailwind utilities;

/* v4 */
@import "tailwindcss";

設定ファイルを移行：tailwind.config.js の設定を CSS の @theme ブロックに移動。
プラグインを更新：JS プラグインを @plugin 構文に変更。
```
@plugin "@tailwindcss/typography";
```
不透明度クラス名を確認：bg-opacity、text-opacity、border-opacity をグローバル検索し、新しい構文に置換。
リネームされたクラス名を確認：shadow-*、rounded-*、flex-grow-*、flex-shrink-* を重点的にチェック。
デフォルト値の変化を確認：特に border カラーと ring スタイルに注目。
視覚的回帰テスト：テストを実行し、見落とした変化がないことを確認。

自動移行ツールは 80% の作業を処理できますが、残りの 20% は手動チェックが必要です。特にデフォルト値の変化は、ツールでは期待値を変更できないため、自分で調整する必要があります。

新機能——Container Queries、3D Transforms などのハイライト

パフォーマンスと設定の改善に加え、v4 にはいくつかの実用的な新機能が追加されました。

Container Queries の組み込みサポート

以前は Container Queries を使用するのにプラグインが必要でしたが、今はネイティブサポートされました。

<!-- コンテナを定義 -->
<div class="@container">
  <!-- コンテナ幅に応じてレスポンシブ -->
  <div class="@md:grid-cols-2 @lg:grid-cols-3">
    ...
  </div>
</div>

@container は container-type: inline-size と同等で、@md: はコンテナクエリのブレークポイントです。構文はレスポンシブブレークポイントの md: に似ていますが、前に @ が付きます。

これはコンポーネントライブラリで特に便利です。コンポーネントのスタイルが画面幅ではなく、親コンテナの幅に応じてアダプティブになります。

3D Transform ユーティリティ

v4 には一連の 3D 変換ユーティリティが追加されました。

<!-- 3D パースペクティブ -->
<div class="perspective-distant">
  <!-- X 軸回転 -->
  <div class="rotate-x-45">...</div>
</div>

<!-- Y 軸回転 -->
<div class="rotate-y-12">...</div>

<!-- Z 軸スケール -->
<div class="scale-z-150">...</div>

利用可能なクラスには、rotate-x-*、rotate-y-*、rotate-z-*、scale-z-*、perspective-*、translate-z-* などがあります。カードのフリップ効果や 3D メニューなどのインタラクションがずっと簡単になりました。

@starting-style バリアント

これは CSS ネイティブの @starting-style 機能と組み合わせて、要素が最初にレンダリングされるときのスタイルを指定します。

<!-- 要素出現時に透明から不透明へフェード -->
<div class="starting:opacity-0 opacity-100 transition-opacity">
  ...
</div>

JavaScript なしでエントリーアニメーションを実現できます。以前は animate-fade-in などのカスタムアニメーションが必要でしたが、今は 1 つのクラス名で完了します。

not-* バリアント

CSS :not() 疑似クラスをサポートします。

<!-- 最後以外のすべての子要素 -->
<li class="not-last:mb-4">...</li>

<!-- disabled 状態がないすべてのボタン -->
<button class="not-disabled:opacity-100">...</button>

以前は last:mb-0 のような逆の書き方が必要でしたが、今は not-* でより直感的に書けます。

拡張された Gradient API

v4 のグラデーションがより強力になりました。

<!-- Conic グラデーション -->
<div class="bg-conic/from-red-500 via-yellow-500 to-blue-500">...</div>

<!-- 放射グラデーション -->
<div class="bg-radial from-white to-transparent">...</div>

<!-- グラデーション補間モード -->
<div class="bg-linear-to-r from-blue-500 to-purple-500 via-oklch">...</div>

via-oklch は新しい補間モードで、グラデーションの遷移をより自然にします（特に色空間変換時）。

結論

これだけ説明しましたが、アップグレードすべきでしょうか？

プロジェクトがまだ活発に開発されているなら、私の提案は：アップグレードしてください。HMR が数百ミリ秒から十数ミリ秒になることで、毎日かなりの待ち時間を節約できます。CSS サイズの削減、メモリ使用量の削減も含め、大規模プロジェクトで特にメリットがあります。

移行コストは主に設定変換とクラス名変更にあります。幸い、自動移行ツール npx @tailwindcss/upgrade があり、大部分の反復作業を処理できます。試してみましたが、中型プロジェクト（200+ コンポーネント）の移行はテストを含めて半日で完了しました。

新規プロジェクトなら、直接 v4 を使ってください。ゼロ設定インストール、自動コンテンツ検出、CSS-first 設定——これらの変更により、Tailwind がさらに使いやすくなりました。使わない理由がありません。

あと、ブラウザ互換性に注意してください：v4 は Safari 16.4+、Chrome 111+、Firefox 128+ が必要です。古いブラウザをサポートする必要があるプロジェクトは、少し待った方がいいかもしれません。

アクションの提案：

新規プロジェクトは直接 v4 を使用
既存プロジェクトは npx @tailwindcss/upgrade で自動移行
border デフォルトカラーと ring デフォルト値の変化を重点的にチェック
問題があれば公式アップグレードドキュメントを参照

Tailwind CSS v4 移行ガイド

Tailwind v3 から v4 へのアップグレード手順

⏱️ 目安時間: 30 分

1
ステップ1: 依存パッケージをアップグレード
npm インストールコマンドを実行して最新版にアップグレードします：

```bash
npm install tailwindcss@latest @tailwindcss/vite@latest
```

PostCSS 統合を使用している場合は以下をインストール：
```bash
npm install tailwindcss@latest @tailwindcss/postcss@latest
```
2
ステップ2: 自動移行ツールを実行
Tailwind 公式がワンクリック移行ツールを提供しています：

```bash
npx @tailwindcss/upgrade
```

このツールは自動的に処理します：
• @tailwind ディレクティブを @import "tailwindcss" に変換
• 不透明度クラス名を bg-opacity-* から /50 構文に変換
• リネームされたユーティリティクラス（shadow-sm → shadow-xs など）
• 設定ファイルを CSS @theme 形式に変換
3
ステップ3: CSS エントリーファイルを変換
元の 3 つの @tailwind ディレクティブを 1 つの @import に置換：

```css
/* これらを削除 */
@tailwind base;
@tailwind components;
@tailwind utilities;

/* 以下に置換 */
@import "tailwindcss";
```
4
ステップ4: カスタム設定を CSS に移行
tailwind.config.js のテーマ設定を CSS ファイルに移動：

```css
@import "tailwindcss";

@theme {
/* カラー設定 */
--color-brand: #0ea5e9;

/* フォント設定 */
--font-display: "Cal Sans", sans-serif;

/* アニメーション設定 */
--animate-fade-in: fadeIn 0.5s ease-out;
}
```

変数命名規則に注意：colors → --color-*、fontSize → --text-*
5
ステップ5: プラグインの読み込み方法を更新
JS プラグインは @plugin ディレクティブで読み込みます：

```css
/* 旧方法：tailwind.config.js で */
// plugins: [require('@tailwindcss/typography')]

/* 新方法：CSS ファイルで */
@plugin "@tailwindcss/typography";
```
6
ステップ6: デフォルト値の変化を確認
2 つのデフォルト値の変化に注目：

• **border カラー**：gray-200 から currentColor に変更
- 元のグレーボーダーが必要な場合、明示的に border-gray-200 を追加

• **ring デフォルト値**：3px blue-500 から 1px currentColor に変更
- 元の青色 3px ring が必要な場合、ring-3 ring-blue-500 を使用
7
ステップ7: テストとスタイルの修正
開発サーバーを実行して視覚的な変化を確認：

```bash
npm run dev
```

重点的にチェック：
• 不透明度関連のスタイルが正常か
• shadow と rounded のサイズが期待通りか
• ボーダー色がデザイン通りか
• プロジェクトの視覚回帰テストを実行（ある場合）

FAQ

Tailwind CSS v4 と v3 の最大の違いは何ですか？

核心的な違いは 3 つあります。1 つ目は Oxide エンジンが Rust で書き直され、HMR 速度が 96% 向上しました。2 つ目は設定が JS から CSS に移行し、@theme ディレクティブを使用します。3 つ目はインストールが簡素化され、Vite プロジェクトは 2 ステップの設定だけです。

Tailwind v4 への移行にはどれくらい時間がかかりますか？

中型プロジェクト（200+ コンポーネント）は約半日で移行が完了します。自動移行ツールが作業の 80% を処理し、残りの 20% はデフォルト値の変化と特殊設定の手動チェックが必要です。

v4 のブラウザ互換性要件は何ですか？

v4 は Safari 16.4+、Chrome 111+、Firefox 128+ が必要です。これは @layer、@property、color-mix() などのネイティブ CSS 機能を使用しているためです。古いブラウザをサポートする必要があるプロジェクトは、アップグレードを延期することをお勧めします。

自動移行ツールは何を処理できますか？

@tailwind ディレクティブの変換、不透明度クラス名の構文更新（bg-opacity-50 → /50）、リネームされたユーティリティクラス（shadow-sm → shadow-xs）、JS 設定から CSS @theme への変換を自動処理します。デフォルト値の変化によるスタイルの違いは処理できません。

v4 では content 配列の設定はまだ必要ですか？

必要ありません。v4 は .gitignore ファイルを読み取って無関係なディレクトリを除外し、プロジェクト内の Tailwind クラス名を自動的にスキャンします。特殊なケースでは @source ディレクティブでスキャンパスを手動追加できます。

v3 からアップグレード後、スタイルが一致しません。どうすればいいですか？

3 つのデフォルト値の変化を重点的にチェック：border デフォルトカラーが gray-200 から currentColor に変更、ring デフォルトが 3px blue-500 から 1px currentColor に変更、shadow と rounded のサイズ命名が調整。該当する要素に明示的にクラス名を追加すれば元に戻ります。

v4 で注目すべき新機能は何ですか？

Container Queries の組み込みサポート（@container 構文）、3D Transform ユーティリティ（rotate-x/y/z、perspective-*）、@starting-style バリアントによるエントリーアニメーション、not-* バリアント、拡張された Gradient API（conic、radial、oklch 補間）が追加されました。

8 min read · 公開日: 2026年3月25日 · 更新日: 2026年3月25日

Easton

技術開発