トップ > AI > 【2025年版】BEMに疲れた全人類へ。AI時代のWebシステム開発におけるCSS選定で意識したいこと

【2025年版】BEMに疲れた全人類へ。AI時代のWebシステム開発におけるCSS選定で意識したいこと

AI CSS BEM TailwindCSS
記事タイトルとURLをコピーする

"BEM is Dead ?"

「BEM、辛くないですか」

長年Web開発を続けてきたエンジニアやデザイナーであれば、一度はこの感情を抱いたことがあるはず。というか、今まさにツライと現在進行系で思っているのが原動力となって、このブログを書いているサービス開発部の佐々木です。

生成AIが当たり前にコーディングのパートナーとなった今、BEMの運用コストは「辛い」を超えて「開発のボトルネック」になりつつあるのでは。それはつまり、AIファースト開発においては「BEM is Dead」なのでは？と私は考えています。

刺激的なタイトルにしてしまいましたが、「なぜAI時代の新規開発においては、BEM is Dead なのか」を、現場の痛みと開発体験（DevEx）の観点から、魂の叫びと共にまとめてみたので、最後までお付き合いいただけますと幸いです。

BEMのツラみ with Figma（デザイナ編）

自分は普段、Figmaを使ってUI設計をしているのですが、FigmaとBEMの相性は最悪だと常々思っています。

その根本的な原因は、「Figmaは『コンポーネント（部品）』単位でUIを設計していくのに対し、BEMは『コンテキスト』単位で命名を強制される」という違いにあります。

1. Auto Layoutで作った構造と、BEMの構造が一致しない

Figmaでは、Auto Layoutで「余白」や「配置」を管理します。ネスト（入れ子）はあくまでレイアウトのためであり、そこには "情報のまとまり" の意味を持たないケースも多いです。

しかし実装時には、BEMのルールを守るために、レイアウト調整用の div にも .block__inner や .block__wrapper といった名前を付けなければなりません。

デザインのためだけの、いわば「名もなき透明な箱」に、無理やり意味のある名前（Element名）を考えなければならいという苦行を強いられます。

2.「親」が変わるたびに命名変更を強制される（再利用性の欠如）

Figma上では「ユーザーアイコンのコンポーネントを、ヘッダーにもサイドバーにもカードの中にも置きたい」となったら、基本的にはコンポーネントをコピペして完了です。

ですが、BEMによる実装では「ヘッダーに置くなら .header__user-icon となり、カードの中なら .card__user-icon」など、場合によってリネームする必要が出てきます。

部品として独立しているはずなのに、「どこに置くか」によって、名前とCSSの責務が変わってしまい、Figmaのような気軽な再利用が許されません。

3. レイヤー名を綺麗にしても、それがクラス名にはならない

そもそも、Figmaのレイヤー名は実装を意識した名前にしているわけではなく、「デザインチームが管理しやすい名前」にしているものです。

ですので、例えばレイヤー名を Image, Title, Description といったシンプルな名前で管理している場合、BEMではクラス名はユニーク（一意）にする必要があるので、最終的にImage は .article-card__image に、Title は .article-card__title などに変更しなくてはいけません。

先ほどの「再利用性の欠如」でも書いたように、Figma上は同じコンポーネントなのに、配置される場所によってBEMのクラス名は異なる可能性があるため、Figmaのレイヤー名と実装のクラス名を「1対1」にするのは極めてコストが高いのです。

そしてこれが、AI時代の開発でBEMが向いていない理由に繋がってくる部分でもあるのですが、詳細は後半で説明したいと思います。

4. SCSSファイルの肥大化が不可避

Figmaでは「バリアント」機能で、Type=Primary, State=Hover, Size=Large のように、プロパティを掛け合わせたUI定義が可能です。

これをBEMに適合させる場合、.btn などの修飾子に対して、複数のModifier（色、サイズ、状態）を組み合わせることになります。.btn--primary-large, .btn--primary-small といった具合に、プロパティの掛け合わせの数だけ、複合クラス名を定義する必要が出てきます。

つまり、Figma上で整理された「状態のマトリクス」は、実際の実装では「それぞれ別のクラス名」として定義するしかなく、SCSSファイルの肥大化は避けられません。

開発でもBEM超ツライ（エンジニア編）

エンジニアにとっても、BEMは設計手法というより、高度な「命名パズル」になりがちで大変ツライです。

脳のリソースを「命名」で使い切る

UIロジックを書く前に、「これは block なのか element なのか？ wrapper なのか container なのか？」という問いに時間を奪われていませんか。私は盛大に奪われています。

__inner / __wrapper / __container が量産されてカオスになっていませんか。私はなっています。とてもシンドいです。

hover, active, error, loading ... 1つのコンポーネントファイルに、あらゆる状態のスタイルが詰め込まれ、可読性が低下していませんか。私は（以下略）

共通化のジレンマ

「似ているけど少し違うUI」が出てきた時。これも本当に厄介です。

  • 命名が微妙に違って共通化できないので、共通化するためにリファクタリングをした結果、別の画面を壊してしまった
  • 共通化によりCSSの責務がずれて、「どこにスタイルの定義を書けばいいか分からない」状態になってしまう
  • 共通化のリファクタをするより、「新規クラス」にしたほうが楽だし安全だと判断されがちで、負債が積み上がっていく

などなど。「あるある〜！」と頷きすぎて首がもげそうです。これはBEM経験者の誰もが、一度は通ってきた道じゃないでしょうか？

なぜ「AI」を使うとBEMはさらに辛くなるのか？

はい、お待たせいたしました。ここからが本題です。

「AIにコードを書かせれば楽になる」はずが、BEMを採用していると逆に負担が大きくなる現象というか悲劇が起きています。 その理由はシンプルで、AIは「文脈（コンテキスト）に依存する命名」が苦手だからです。

AIによる「命名の揺らぎ」

AIは厳格なルールセット（BEMの設計思想）を与えない限り、その場の雰囲気で名前を付けてきます。AIがUIを書く時にやることは「規約遵守」ではなく「完成」なので、BEMのような統治が必要な設計に対して事故りやすいのです。

例えばこのような会員の名前を表示するだけのシンプルなUIがあったとします。これをAIに出力させるとどうなるか。

AIによる1回目の出力内容：（アイコンやメールアドレス部分は割愛）

<div class="member-account">
  <div class="member-account__name">鈴木</div>
</div>

別ページで同じUIパーツを元に生成：

<div class="member-card">
  <div class="member-card__title">鈴木</div>
</div>

同じUIなのに member-account と member-card が混在しています。element名も __name と __title で揺れてしまっています。これが起きると共通化できません。

事故例

  • AIが毎回違うblock名を提案する
    • → member-card / member-account / user-card
  • AIがelement名を安定させない
    • → __title / __name / __header-title
  • AIが見た目を再現させるために、勝手にルールにないmodifierを増殖させる
    • → --active --selected --highlight --blue ...
  • promptの表現次第で命名が変わってしまう

例えば、現場でよくある「デザイン修正（ボタンを赤く、少し大きくしたい）」が発生した時、まず「赤い状態」をどう呼ぶかでAIは悩みます。--red？ --danger？ --alert？ （人間でも迷いそうではありますが）

赤くするだけの軽微な修正でも、そこに厳格な命名ルールが無ければ、クラス名を安定させることはできません。これらの理由により結局「人間が修正したほうが早いわ〜😩」となってしまいます。

それならば、デザイン側（つまりFigmaなど）にクラス名の責務を持たせたらどうか？と考えるかもしれませんが、Figmaのレイヤー名をBEMのクラス名に対応させるのが難しいことは、「レイヤー名を綺麗にしても、それがクラス名にはならない」の章で書いたとおりです。つまりBEMは、FigmaだけでなくAIとも相性が悪いのです。

AI時代においては "Tailwind" が有力である理由

ここまでの内容を踏まえると、新規開発におけるCSSフレームワークの選定は、明確に「開発効率を決定づける戦略」になります。AI時代の開発においては、BEMが向いていないことは分かりましたが、それでは何を選んだらいいのでしょうか。

結論から先に書くと、「新規に爆速でAIを使って開発するなら、Tailwind CSS が最有力候補」だと私は考えています。ここで注意していただきたいのは、「新規・爆速・AI」の文脈ならば、という条件付きの話であることです。

Tailwindが解決することは何か

Tailwindは、BEMの一番のツラみである「命名」を不要にするフレームワークです。スタイルを当てるためのクラス名を考えなくても良い。これが、AIとの圧倒的な親和性を生み出します。

見た目をそのままclassに落とすので、AIに「このUIをTailwindで作って」と指示すれば、flex items-center p-4 bg-white... といった標準的なユーティリティクラスが出力されます。これらはAIが学習済みの「事実上の標準（デファクトスタンダード）」であるため、比較的一貫した出力になりやすいのです。（慣れるまで違和感は大きいですが💦）

<div class="flex items-center gap-3 px-4 py-3 rounded-md border border-slate-200 bg-white hover:border-blue-500 hover:bg-blue-50">
  ...
</div>

Tailwind と shadcn/ui の組み合わせが最強説

ただし Tailwind 導入時の懸念点として、デザイナ的には「UIパーツをゼロから作るのは大変」というのがあります。ここで登場するのが shadcn/ui です。

shadcn/ui とは？
Tailwind CSS と Radix UI（アクセシビリティ対応済みのヘッドレスUI）を組み合わせた、「コピペして使うコンポーネント集」です。

npmパッケージのような依存ライブラリとしてインストールするのではなく、コードをプロジェクトにコピーして使うため、デザインに合わせて自由にカスタマイズができ、完全にプロダクトの資産として管理が可能です。

Next.jsの開発元であるVercelの「v0」が選んだのもこのスタックでした。

v0はプロンプトからUIを生成する際、標準で Tailwind CSS + shadcn/ui のコードを出力します。世界のフロントエンドトレンドを牽引するVercelが、「AIにUIを書かせるならこの構成が最適」と判断したこと。これは、2025年のCSS選定における強力な後押しにもなっています。

UI構築は3パターンで考える

ここまでTailwind を推す内容を書いてきましたが、もちろん全てのプロジェクトでTailwindが正解なわけではないです。 CSSの選定は、チームが「UIの『正解』をどこに置いているか」によって決まります。

大きく分けて、UI構築には3つのパターンがあるかなと思っています。

1. デザインファースト（ブランド重視）の場合

デザイン統治を効かせたいようなプロダクト・プロジェクトの場合です。デザイナーがFigmaで完璧な定義を行い、エンジニアはそれを再現する必要があるケースです。グロースしたサービスなど、基本的に成熟期のプロダクトはこちらになります。

Figma上の変数（Variables）と実装コードの「トークン」を厳密に同期させる必要があるため、構造化されたCSS設計が求められます。ここではTailwindの柔軟さが逆に「勝手な値を使ってしまうノイズ」になることがあるため、向いていません。

Tokens + CSS Modules の構成などは 、Figma上の変数（Variables）と実装コードの値を厳密に同期させる運用に向いています。

2. コードファースト（動く画面重視）の場合

Figmaはあくまでラフ案として使い、細かい挙動や余白は実装しながら決めるスタイルのプロジェクトです。

実際の触り心地やインタラクションは、エンジニア（またはデザインエンジニア）がコード上で調整して確定させるため、その場でスタイルを変更できるTailwindが圧倒的なパフォーマンスを発揮します。Storybook との相性もとても良いです。

3. AIファースト（プロンプトでの対話重視）の場合

基本的に、ゼロからコードを書くことはほぼ無く「作らせて修正する」の繰り返しとなるようなケースです。

前述の通り、AIにとって最も理解しやすく、かつ人間が修正指示を出しやすいのはTailwindです。

UI構築の3パターン比較

私の独断でまとめると、こんな感じです。

観点 BEM + Sass Tailwind CSS CSS Modules + Tokens
初速（UI完成まで） ❌️（設計と命名に時間がかかる） ✅️（爆速） 🤔（設計次第）
命名コスト ❌️（破綻しやすい） ✅️（ほぼ不要） 🤔（統治が必要）
AI生成との相性 ❌️（命名が揺れる・修正コスト増） ✅️（安定・修正容易） 🤔（ルールがあれば可）
デザインの一貫性 🤔（ルール遵守が前提） ❌️（自由すぎるため制約が必要） ✅️（トークンによる統治）
推奨シーン レガシー改修・長期運用 新規開発・MVP・管理画面 大規模・ブランド重視

まとめ

従来の受託開発や大規模なプロダクトでは ①デザインファースト が主流でした。しかし、現代のWebサービス開発は、スピード重視の ②コードファースト、そしてこれからは ③AIファースト へとシフトしています。

Tailwindを選定するということは、単にCSSの書き方を変えるだけではなく、「CSSクラスの命名」という、AIが苦手とする（そして人間も疲れ果てている）作業を捨て、「UIの構造と体験」の設計に集中するという方針転換でもあります。

もちろん、厳格なブランド統治が必要な場合は、Tokens中心の設計（CSS Modulesなど）が適していますが、もし今、「新規でWebシステムを立ち上げたい」「AIを活用して爆速で開発したい」と考えているなら、

Tailwind CSS + shadcn/ui + Storybook

これが、今後最も開発体験が良い選択肢になりえる。と言えるのではないでしょうか。