← ブログ一覧
📖 約10分

Tailwind v4で設定ファイルが消えた話

Tailwind CSS v4でtailwind.config.jsが不要に。@themeでCSSに直接書くCSS-first方式、Lightning CSSによる高速化、v3ライブラリの互換性、移行の判断フローまで実体験で解説。

CSSTailwindフロントエンドWeb開発

登場人物

  • リナ社長 … 高校生なのに会社経営するやり手ギャル。テックにも強くてAI活用が得意。
  • タクヤ … 入社3年目の男性社員。真面目で少しだけコードが書ける。

今回は、設定ファイルが消えたTailwind v4のCSS-first方式と移行の判断基準を整理する回。

「タクヤ〜、tailwind.config.js ってどこ行った？」

リナ社長がターミナルをのぞき込みながら、首をかしげた。

「あ……それ、v4から消えたんですよ。先週新規プロジェクトでセットアップしたとき、僕も最初びっくりしました」

「マジで？！じゃあ設定どこに書くの？」

「CSSファイルの中に書くんです。最初見たとき、えっ、これどういうこと？ってなりました」

「えぐくない？！それ、まじでゲームチェンジじゃん。一緒に整理してこ！」

Tailwind v4、何が変わったの？

「まずさ、v4の一番でかい変更ってなに？ひと言で言えば？」

「ひと言で言うなら……”設定をCSSに移した”、ですかね。これまで tailwind.config.js に書いていたテーマやカラーの定義を、全部CSSファイルの中に @theme ディレクティブで書くようになりました」

「CSS-firstってやつだよね！JavaScriptのコンフィグに依存しないで、CSSだけで完結する設計に変わったってこと」

Tailwind CSS v4 の最大の変更点は、CSS-firstアプローチへの転換です。これまで tailwind.config.js（または .ts）に JavaScript で記述していたデザイントークンや設定が、すべて CSS ファイルの中に移動しました。

インストール方法も変わり、これまでの PostCSS ベースから Vite プラグイン方式が推奨に変わっています。

# v4 のインストール（Viteプロジェクトの場合）
npm install tailwindcss @tailwindcss/vite

そして CSS のインポートも1行で済むようになりました。

/* v3: 3つのディレクティブが必要だった */
@tailwind base;
@tailwind components;
@tailwind utilities;

/* v4: この1行だけでOK */
@import "tailwindcss";

「ね、すっきりしてるじゃん！」

「確かに、以前の3行書く方式と比べるとシンプルですね」

@themeでCSS内にカラーパレットを定義してみる

「じゃあ実際に、ブランドカラーを追加する場合はどう書くんですか？」

「タクヤ、まず自分でやってみてよ。v3のとv4のを並べてみて」

タクヤがキーボードを叩いて書いたのがこちらです。

// v3: tailwind.config.js に書いていた書き方
module.exports = {
  theme: {
    extend: {
      colors: {
        brand: {
          500: "#6366f1",
          600: "#4f46e5",
        },
      },
    },
  },
};
/* v4: CSSファイルに @theme で書く新方式 */
@import "tailwindcss";

@theme {
  --color-brand-500: #6366f1;
  --color-brand-600: #4f46e5;
}

「いい感じじゃん！--color- プレフィックスがポイントね。これがCSS変数としてそのまま展開されるから、bg-brand-500 ってクラスが使えるようになるの」

「なるほど。命名規則が --color-{名前}-{スケール} なんですね。フォントサイズやスペーシングも同じ形式ですか？」

「そう！--font-、--spacing- って感じでプレフィックスが決まってる。覚えちゃえばシンプルだよ」

@theme 内のCSS変数はTailwindのデザイントークンと直接マッピングされます。--spacing-* なら p-* や m-* クラスに、--font-* なら font-* クラスに対応します。定義したトークンはそのまま DevTools でも確認でき、oklch などの広色域フォーマットも活用しやすくなりました。

Rust製Lightning CSSでビルドが速くなった

「ところで、ビルドがめちゃくちゃ速くなったって聞いたんですけど……」

「それよ！これがv4のもう一個のやばいポイント。Lightning CSS、知ってる？」

「名前は聞いたことあります。確かRust製のCSSパーサーですよね？」

「せいかい！v4はコアのCSS変換エンジンにLightning CSSを採用したんだよね。おかげでビルドがえぐい速さになった」

v4ではCSSのパース・変換処理にRust製の Lightning CSS（旧名：Parcel CSS）を採用しています。これにより、v3と比べてビルドが高速化されました。

比較項目Tailwind CSS v3Tailwind CSS v4
CSSエンジンPostCSS（JS製）Lightning CSS（Rust製）
ベンダープレフィックスautoprefixerが必要Lightning CSSが内蔵
設定の置き場所tailwind.config.jsCSS内の @theme

「なんでRustだと速いんですか？JSと何が違うんでしょう」

「ざっくり言うと、ガベージコレクションのオーバーヘッドがない分、ネイティブで処理できるんだよね。esbuildがJS界でビルド革命起こしたのと同じ話で、Rustで書いたCSSツールがJSのツールに勝つの、もう当たり前になってきてる」

ベンダープレフィックスの自動付与も Lightning CSS が内蔵しているため、これまで別途必要だった autoprefixer が不要になりました。依存パッケージが減るのも地味に効いてきます。

コンテナクエリとカスケードレイヤーが標準に

「速さ以外にも新機能はあるんですか？」

「あるある！コンテナクエリとカスケードレイヤーがプラグインなしで使えるようになったのが個人的にアツい」

「コンテナクエリって、親要素のサイズに応じてスタイルを変えられる、あれですよね」

「そゆこと。v3だとプラグイン入れないといけなかったけど、v4から標準でいける」

<!-- コンテナクエリ: v4から標準サポート -->
<div class="@container">
  <div class="@md:flex @lg:grid">
    <!-- 親コンテナの幅が md サイズ以上でflex、lg以上でgrid -->
  </div>
</div>

カスケードレイヤー（@layer）も v4 ではより自然に扱えるようになりました。Tailwindが出力するスタイルは @layer で整理されており、ユーザーが書いたスタイルとの優先順位の衝突が起きにくくなっています。

「!important を乱用しなくていい世界線、最高じゃん。CSSの詳細度バトル、もう卒業できる」

「確かに、あの !important の連鎖には毎回悩まされてました（笑）」

互換性の落とし穴：v3ライブラリがぶっ壊れた件

「あ、その顔、何かやらかしたやつだ（笑）。何があったの？」

「shadcn/ui を入れようとしたら、コンポーネントが全部スタイル崩れしてしまって。daisyUI も同じ感じで、最初はなんでか全然わからなくて……」

「あー、それ互換性問題じゃん。v3前提で作られてるやつ、v4だと動かないやつあるよね」

Tailwind CSS v4 は v3との後方互換性を捨てた大規模なリアーキテクチャです。そのため、Tailwind v3 を前提として設計されたサードパーティライブラリでは、さまざまな問題が起きます。

ライブラリ状況（2026年6月時点）
shadcn/uiv4対応版を別途セットアップする手順が必要。従来の手順では動作しない
daisyUIv4対応版がリリースされているが、設定方法が大きく変わる
Flowbite部分的に対応、一部コンポーネントで崩れが発生するケースあり

「タクヤが踏んだのは、ライブラリ側がまだ tailwind.config.js を読みに行く前提で動いてて、設定が全部すっぽ抜けてた感じ？」

「まさにそれです。ライブラリのドキュメントがv3前提のままだったので、手順通りにやっても動かなくて、しばらく原因がわからなかったです」

「地雷、ちゃんと回避策あるから安心して。使いたいライブラリのIssueとv4対応状況を先に調べるのが鉄則だよ」

移行で詰まりそうなポイントと判断フロー

「で、結局 v4 に移行した方がいいの？それともまだ待った方がいい？」

「プロジェクトの状況によるけど、判断フローで整理してあげる！まず新規ならv4でGO。既存は慎重にね」

新規プロジェクト であれば、v4を採用することを推奨します。設定がシンプルになり、CSS変数によるデザイントークン管理はメンテナンス性が高いです。ただし、使いたいUIコンポーネントライブラリがv4対応済みかを先に確認しましょう。

既存プロジェクト は、公式の移行ツールが提供されています。

# 公式の移行ツール（v3 → v4）
npx @tailwindcss/upgrade

このコマンドは tailwind.config.js の内容を @theme 形式に変換した CSS を生成しますが、複雑なカスタマイズがある場合は手動確認が必要です。一気に移行できないときは、旧JSファイルを読み込む逃げ道もあります。

/* 旧 tailwind.config.js を一時的に読み込む（@importより前に書く） */
@config "./tailwind.config.js";

@import "tailwindcss";

「@config があるなら、段階的に移行できるので安心ですね。PostCSSの設定はもう要らないんですか？」

「ViteやBunなら専用プラグインがあるから postcss.config.js は不要。ただNext.jsやAngularではまだ @tailwindcss/postcss 経由のPostCSS設定が公式推奨なんだよね。ゼロコンフィグになれるかはバンドラー次第」

「まとめると、新規はv4、既存はライブラリ依存度を棚卸ししてから、ですね」

まとめ：v4は「Tailwindの思想が変わった」

「ひと通り見てきたけど、どう？タクヤ的に」

「最初は設定ファイルがなくなって戸惑いましたけど、慣れてみるとCSSだけで完結するのはスッキリしてますね。デザイントークンをCSSで管理するのも、実は理にかなってると思いました」

「でしょ！v4って、単なるアップデートじゃなくて、“JSで設定する”から”CSSで設計する”へのシフトだよね」

「ただ、ライブラリの互換性問題はまだ現実の壁なので、そこだけは事前調査を怠らないようにしたいです」

「それが大人の判断ってやつじゃん（笑）。新しい技術に乗るタイミングを見極めるのも、エンジニアの腕の見せどころだよ」

Tailwind CSS v4 は、フロントエンドのスタイリング設計に対する考え方そのものを更新するリリースです。新規プロジェクトから積極的に採用し、CSS-firstの感覚を身につけておくと、今後のエコシステムの変化にも対応しやすくなります。

参考

コメント