新規のコーポレートサイトを請けるたびに、着手の最初の一手で迷う人は多いはずです。「とりあえず Tailwind を入れておくべきか、それとも素の CSS で書くか」。社内の標準が決まっていればいいのですが、受託の現場は案件ごとに規模もチームも違うので、毎回ゼロから判断し直すことになる。さらにやっかいなのは、過去案件の引き継ぎです。前任者が組んだ Tailwind の設定ファイルが肥大化し、独自のユーティリティが大量に生えていて、いまや誰も全体像を把握していない——そんなプロジェクトを引き継いだ経験のある人なら、「フレームワークを入れる」という判断の重みが分かると思います。
2026 年のいま、この迷いに新しい変数が加わりました。標準 CSS が、ここ数年で目に見えて強くなったのです。「標準 CSS は美しくなった、もはや Tailwind は不要だ」という論調まで出てきています。本記事では、受託 Web 制作の立場から、どんな案件なら Tailwind を入れる価値があり、どんな案件なら標準 CSS の最小設計で十分なのかを、保守性と引き継ぎを軸に整理します。
標準CSSは、Tailwindの売りだった領域に追いついた
まず事実関係を押さえます。かつて「素の CSS では面倒、だから Tailwind」と言われていた領域の多くが、いまは標準仕様で書けるようになりました。
代表的なのが、コンポーネントを親要素の幅に応じて切り替える container queries、親要素を子の状態で選べる :has()、CSS 単体で入れ子が書ける ネスト記法、スタイルの優先順位を意図どおりに管理する cascade layers（@layer）、それに subgrid、color-mix() や相対カラー構文、@property といった機能群です。これらはもう実験段階ではなく、主要ブラウザで使える前提で設計してよい段階に来ています。
たとえば「カードのレイアウトを、置かれた場所の幅で切り替えたい」という、Tailwind なら @container 系のユーティリティで書いていた処理は、標準 CSS でこう書けます。
.card-list {
container-type: inline-size;
}
@container (min-width: 480px) {
.card {
display: grid;
grid-template-columns: 120px 1fr;
}
}ビューポート幅ではなく「親の幅」で分岐できるので、同じカードを狭いサイドバーにも広いメインカラムにも置ける。この再利用性こそ、これまでフレームワーク側で補っていた部分です。標準 CSS のこのあたりの進化は container queriesで再利用可能なコンポーネントを作る記事 でも具体的に扱っています。つまり「標準 CSS では手が届かないから Tailwind」という前提自体が、2026 年には半分くらい崩れています。
では Tailwind の利点は消えたのか
ところが、「標準が追いついたから Tailwind は不要」という結論にはなりません。標準 CSS が再現したのは Tailwind の機能であって、Tailwind が提供している運用上の価値ではないからです。
Tailwind の本質的な売りは、個別の機能ではなく「設計判断を減らせること」にあります。クラス名を考えなくていい。余白や色やフォントサイズが、最初から決められた段階値（p-4、text-lg、bg-slate-100）に揃うので、複数人が触っても見た目がばらつかない。HTML を見ればスタイルが分かるので、別ファイルを行き来しなくていい。そしてビルド時に使っていないクラスがパージされ、最終的な CSS が小さく収まる。これらは、チームでスピード感を持ってコンポーネントを量産する局面で、いまも確かに効きます。
先ほどの container query の例を、Tailwind v4 で書くとこうなります。
<div class="@container">
<div class="@min-[480px]:grid @min-[480px]:grid-cols-[120px_1fr]">
<!-- カードの中身 -->
</div>
</div>CSS ファイルを開かず、HTML の中だけで分岐の意図が完結している。これが「速い」と言われる所以です。加えて 2026 年に無視できないのが、AI コーディング支援との相性の良さです。ユーティリティクラスは構造が決まっていて予測可能なので、AI が生成するコードとして安定しやすい。Vercel や Linear のようなプロダクトが Tailwind を使い続けているのは、この運用面の優位が大きいからです。
問題は、この利点がすべての案件で効くわけではないことです。チームでコンポーネントを量産しないサイトでは、「設計判断を減らす」効果がそもそも発動しません。むしろ HTML がクラスで埋まって読みにくくなる、設定ファイルを覚えるコストがかかる、というデメリットだけが残る。ここが受託案件で判断を誤りやすいポイントです。
案件タイプで分ける判断軸
抽象論だけでは選べないので、受託で実際に効く判断軸を表にします。
| 判断軸 | Tailwind 寄りが向く | 標準CSS（最小設計）が向く |
|---|---|---|
| サイト規模・ページ構成 | コンポーネントを多数使い回す中〜大規模 | 数ページのコーポレートサイト・LP |
| 採用フレームワーク | React / Astro などコンポーネント前提 | 静的HTML中心、または薄いテンプレート |
| 体制 | 複数人が並行して触る | 一人〜少人数、属人的でも回る |
| 更新頻度 | 継続的に画面を足し続ける | 公開後はほぼ更新しない |
| 引き継ぎ先 | 自社にTailwind経験者がいる | 制作会社や非エンジニアが保守 |
軸を眺めると、分かれ目は「規模」そのものより、コンポーネントを継続的に量産する体制があるかと引き継ぎ先が誰かにあると分かります。React や Astro でコンポーネント駆動の開発をし、複数人が並行で画面を足していくなら、一貫性を機械的に担保してくれる Tailwind の価値が素直に出ます。Astro での構成判断は Next.jsとAstroを比較した記事 も合わせて参考になります。
逆に、数ページのコーポレートサイトを納品して、その後の更新は先方の Web 担当者や別の制作会社が引き継ぐ——という典型的な受託案件では、話が変わります。Tailwind の設定一式とユーティリティの流儀を引き継ぎ先に背負わせると、「触れる人がいない」状態を新たに作り込むことになる。標準 CSS で素直に書いておけば、CSS の基礎知識さえあれば誰でも保守できます。引き継ぎ先のスキルセットは、技術選定の立派な一要素です。
弊社の事例: リニューアルでTailwindをやめて標準CSSに寄せた判断
具体例を挙げます。ある地方の専門サービス系の中小企業（社名は伏せます）から、コーポレートサイトのリニューアル相談を受けました。既存サイトは数年前に別の制作会社が Tailwind で構築したもので、ページ数は会社案内・サービス・採用・お知らせを合わせて 20 ページほど。問題は、社内に Tailwind を扱える人が一人もいなくなっていたことでした。当初の担当者が退職し、「お知らせの色を少し変えたい」という程度の修正すら外注しないと動かせない。設定ファイルには独自ユーティリティが大量に追加されていて、引き継ぎ資料もない状態でした。
私たちはまず、このサイトに Tailwind が本当に必要かを問い直しました。更新の実態は月に数回のお知らせ追加と、年に数回の文言修正が中心。コンポーネントを量産する開発はもう発生していない。であれば、Tailwind が提供していた「量産時の一貫性」は宝の持ち腐れで、残っているのは「触れる人がいない」というコストだけでした。そこでリニューアルでは Tailwind を外し、cascade layers でスタイルの優先順位を整理し、デザイントークンを CSS カスタムプロパティ（--color-primary のような変数）に集約した、素直な標準 CSS の構成に組み直しました。クラス設計も、先方の Web 担当者が読んで意味が分かる命名に統一しました。
結果として、リニューアル後は「お知らせの追加」や「色の微調整」を先方の担当者が自分で行えるようになり、軽微な修正のたびに発生していた外注が止まりました。CSS の総量も、未使用クラスを抱え込んでいた以前より小さくなった。この案件で効いたのは新機能ではなく、引き継ぎ先のスキルに技術選定を合わせたことです。なお、ここで判断の軸になった「過剰な作りを外して素直な構成に戻す」考え方は、HTMLファーストで作り直した記事 の発想とも地続きです。逆に言えば、もしこの会社が継続的に機能を足し続けるサービスを運営していたなら、私たちは Tailwind を残す判断をしていたはずです。優劣ではなく、案件への適合の問題なのです。
迷ったときに確かめたいこと
新規案件で Tailwind か標準 CSS かを決めかねたら、機能の比較表をにらむ前に、二つだけ確かめると判断を誤りません。
一つは、このサイトは公開後もコンポーネントを量産し続けるのか。React や Astro でチーム開発し、画面を足し続けるなら Tailwind の一貫性が効きます。数ページを納めて以後はほぼ更新しないなら、標準 CSS の最小設計で十分です。もう一つは、公開後に誰が CSS を触るのか。自社にフロントエンドの体制があるか、先方の非エンジニアが保守するか、別の制作会社に渡るか。引き継ぎ先のスキルに合わない技術を入れると、納品の瞬間から「触れない仕組み」を作り込むことになります。
新規サイトで Tailwind を入れるべきか毎回迷っている、前任者の Tailwind 設定が膨らんで保守できなくなっている、リニューアルで技術構成ごと見直したい——そうしたお悩みがあれば、グリームハブのお問い合わせからご相談ください。サイトの規模・体制・引き継ぎ先を伺ったうえで、Tailwind を入れるべき案件なのか、標準 CSS の最小設計で軽く保つべき案件なのかを率直にお見立てし、公開後も無理なく保守できる形へご一緒に組み上げます。
