Loading
  • LIGHT

  • DARK

ROUTE

ルートゼロの
アクティビティ

CSS命名規則を徹底比較!BEM・FLOCSS・Atomic CSSの選び方とは?

2

CSS命名規則を比較!BEM・FLOCSS・Atomicどれが最強か?徹底解説

CSSのクラス名、なんとなく自己流で決めていませんか?「動けばいい」と思ってその場で名付けていたら、後で「このクラス名って何?」「これ、将来保守できるのか?」と不安になったことがある――。

そんな経験、エンジニアの方なら一度はあるはずです。特に現場が変わるたびに命名規則や設計思想がバラバラで、レビューでは「ルール守って」と言われ、プロジェクトごとに学習コストを感じてしまう。

この記事では、現場エンジニアのリアルな悩みに共感しながら、「CSS命名規則」の本質と代表的な3つの手法――BEM、FLOCSS、Atomic CSS――を徹底比較。

「自己流の限界」「各規則の選び方」「失敗・成功事例」まで、“感覚”ではなく“ロジックと現場経験”で納得できる情報をまとめています。

この記事を読み終えれば、「どの命名規則がなぜ推奨されるのか」「自分に最適な選択」が明確になり、新規案件でも迷わない“設計力”が手に入ります。

用語解説:CSS命名規則
CSSのクラス名やID名の付け方に関するルール。保守性や可読性、チーム開発の効率を高めるために重要です。

用語解説:クラス名
HTML要素にスタイルを適用するための名前。命名規則に従うことで役割や状態が分かりやすくなります。


CSS命名規則とは?現場エンジニア視点の基礎と目的

なぜ命名規則が必要か?自己流のリスクと破綻事例

CSSの命名規則は「プロジェクトの資産価値」を守るための必須ルールです。自己流のまま進めると、次のようなリスクが顕在化します。

  • 属人化・スパゲッティ化:開発者ごとに命名がバラバラになり、誰もコードを追えなくなる

  • レビュー・保守コストの増加:クラス名の意味や用途が不明確で、修正のたびに現場が混乱

  • プロジェクトごとの混乱:現場が変わるたびに命名思想も変わるため、学習コストが増大

命名規則は「一時的な時短」ではなく、「継続的な価値」を生む“エンジニアの必須リテラシー”です。


「BEM」「FLOCSS」「Atomic CSS」など主な手法の定義

BEM(Block Element Modifier)

  • BEM公式ガイド

  • 「Block」「Element」「Modifier」の3要素で構成。

  • 例:.button, .button__icon, .button--primary

  • クラス名で「役割・構造・状態」を明確に表現

FLOCSS(フロックス)

  • FLOCSS公式ドキュメント

  • ファイル・クラスを「機能別」「構造別」に分けて、BEMと組み合わせて運用

  • 例:l-header, c-button, p-card

  • プロジェクト規模・チーム開発に強み

Atomic CSS(アトミックCSS)

  • Tailwind CSSなどで代表される「ユーティリティファースト」な設計思想

  • 1つのクラス名が「1つのプロパティ」を担当

  • 例:.text-center, .mt-2, .bg-blue-500

  • ルールよりも“再利用性・機動性”を重視

用語解説:BEM(Block Element Modifier)
「Block(部品)」「Element(要素)」「Modifier(状態)」の3つで構成される命名規則。クラス名で役割や状態を明確に表現します。

用語解説:FLOCSS
ファイルやクラスを機能・構造ごとに分けて管理する設計手法。BEMと組み合わせて使われることが多いです。

用語解説:Atomic CSS
1つのクラス名が1つのCSSプロパティを担当する設計思想。Tailwind CSSなどが代表例です。

(CSSのレスポンシブ設計については『初心者向けCSSレスポンシブ解説|2025年対応・サンプル付きでスマホ対応をマスター』をご参照ください)


主要CSS命名規則の比較表と選び方

用語解説:保守性
コードを長期間・複数人で管理しやすくする性質。命名規則が統一されていると保守性が高まります。

用語解説:可読性
コードを見たときに役割や状態がすぐ分かること。クラス名や命名規則が分かりやすいと可読性が向上します。

各方式のメリット・デメリット

規則 メリット デメリット 向いている現場
BEM ・構造・役割・状態が一目で分かる
・運用が徹底しやすい
・大規模PJでの実績多
・クラス名が長くなりやすい
・ルール理解に初学コスト
サービス運用型、増員前提PJ
FLOCSS ・役割・粒度の整理がしやすい
・BEMを柔軟に拡張できる
・チームでスケール
・設計思想が複雑化しやすい
・小規模PJではオーバー設計
複数チーム・中〜大規模
Atomic CSS ・スピード開発・変更に強い
・コード量削減
・デザイン自由度が高い
・HTML肥大化
・“設計”を感じづらい
・チーム文化で賛否
小〜中規模・短期開発

BEMは保守性・可読性に優れますが、クラス名が長くなりがちです。Atomic CSSは開発スピードに寄与しますが、設計思想がチームに馴染まないと混乱を招く可能性があります。


プロジェクト規模・現場環境ごとの最適な選択指針(比較チャートつき)

  • プロジェクトの規模/期間/チーム体制/運用フローを指標に選択するのが現実的です。

現場の特徴 オススメ命名規則 理由・ポイント
長期運用・メンバー流動 BEM / FLOCSS 「役割×状態」で迷わず、保守性・可読性が高い
複数チーム・増員PJ FLOCSS 拡張・分担しやすい、ドキュメント管理も容易
スピード重視・少人数 Atomic CSS 機動性・再利用性重視。Tailwind等と相性
モダンJS/React系 BEM + CSS Modules スコープ管理×命名規則。TypeScriptとも親和性高い
  • “現場の現実”に合った選択が、プロジェクトを成功に導きます。

用語解説:CSS Modules
JavaScriptフレームワークで使われるCSSの管理方法。クラス名が自動でユニーク化され、BEMなどの命名規則と組み合わせやすいです。

用語解説:Tailwind CSS
Atomic CSSの代表的なフレームワーク。ユーティリティクラスを使って素早くスタイルを適用できます。


実体験で学ぶ!失敗しない命名規則導入と現場Tips

よくある失敗例とプロジェクト体験談

  • 命名ルールが現場ごとにバラバラ

  • 例:「.btn」「.button」「.btn-main」「.mainButton」…統一ルール不在

  • 転属や新メンバー追加時、「クラス名の意図が分からない」→バグ発生/改修ミス

(CSSの命名規則や保守性の観点については『SCSSとは?CSSとの違い・導入方法・書き方を徹底解説』をご参照ください)

成功する導入・チーム運用ノウハウ(ルール策定・CI導入・事例紹介)

  • ルールの“見える化”が肝心

  • ・プロジェクト開始時に「命名規則ガイドライン」を必ず作成

  • ・NotionやGitHub Wikiで共有し、都度アップデート

  • 自動チェックの仕組みも導入

  • ・Stylelint等で命名パターンを機械的に統一(CI/CD組み込みで運用負荷ゼロ)

(AIによるコード補完や自動化については『GitHub CopilotでAIコード補完!導入手順と効率化メリット徹底解説』をご参照ください)

  • 新人からベテランまで迷わず開発できる仕組みが現場力を底上げします。

用語解説:CI/CD
継続的インテグレーション/継続的デリバリーの略。コードの変更を自動でテスト・デプロイする仕組みです。

用語解説:Stylelint
CSSの書き方や命名規則を自動でチェックするツール。CI/CDと組み合わせて運用負荷を減らせます。


まとめ・迷った時のチェックリスト

【CSS命名規則 選定&運用のチェックリスト】

  • [ ] プロジェクト開始時に命名規則を決めているか?

  • [ ] 命名ルールのガイドラインが社内Wiki等で共有されているか?

  • [ ] StylelintやCIで自動チェック仕組みがあるか?

  • [ ] レビューで「命名について」の指摘が減っているか?

CSS命名規則は“現場の保守性・生産性”を大きく左右します。自己流に頼らず、BEM・FLOCSS・Atomic CSSなど「現場と自分に合う最適解」を論理的に選び、今後のエンジニア人生をより豊かにしましょう。

用語解説:ガイドライン
プロジェクトやチームで守るべきルールや方針をまとめた文書。命名規則のガイドラインがあると、誰でも迷わず開発できます。


FAQ

  1. CSS命名規則の“正解”はありますか?
    → プロジェクトの規模・文化・目的によって“最適解”は異なります。BEMやFLOCSSが多くの現場で推奨されていますが、Atomic CSSも適材適所です。

  2. BEM・FLOCSS・Atomic CSSは何が違う?
    → BEMは構造重視、FLOCSSは役割・粒度重視、Atomic CSSは機動性・スピード重視。現場や開発方針で最適解が異なります。

  3. そもそも自己流のままでも問題ないの?
    → 一時的には進められますが、保守・運用・レビュー時にコストやトラブルが大きくなりやすいです。

  4. チームやプロジェクトで命名規則がバラバラな場合どうする?
    → まずは共通ルールを作り、ドキュメント化と自動チェック(Stylelint等)導入がおすすめです。

  5. 命名規則を現場で統一するコツは?
    → ガイドラインを作成し、継続的な共有とレビュー、自動ツール導入が効果的です。

  6. CSS ModulesやTailwindなど新しい技術との相性は?
    → CSS ModulesはBEMやFLOCSSと相性が良いです。TailwindはAtomic CSS系ですが、設計思想の理解とプロジェクト要件に合わせて選択を。

もっとルートゼロを知りたいなら

DISCOVER MORE