WebページのCSS命名規則を徹底比較！OOCSS・BEM・SMACSSの特徴と選び方

CSSの命名規則とは？Webページ制作でなぜ重要なのか

Webページのコーディングを進める中で、「このボタンのクラス名、何にしよう？」「前に書いたCSSと干渉してレイアウトが崩れてしまった」といった悩みに直面したことはないでしょうか。CSSは文法自体がシンプルである反面、規模が大きくなると管理が非常に難しくなるという特性を持っています。

複数人で開発を行う場合や、長期にわたってWebページを運用・更新していく場合、場当たり的にクラス名をつけていると、どのCSSがどこに影響しているのか誰にも分からない「カオスな状態」に陥りやすくなります。これを防ぐために生み出されたのが、OOCSS、BEM、SMACSSといった「CSSの命名規則（設計手法）」です。命名規則を導入することで、コードの可読性が高まり、影響範囲が明確になるため、安全に保守・拡張できるWebページを構築することが可能になります。

主要なCSS命名規則の比較表

まずは、今回解説する3つの主要な命名規則について、それぞれの結論となる特徴を比較表で確認してみましょう。

OOCSS（オブジェクト指向CSS）の特徴と書き方

OOCSS（Object Oriented CSS）は、CSSにオブジェクト指向の考え方を取り入れた設計手法です。無駄なコードを減らし、再利用性の高いコンポーネントを作ることを目的としています。

OOCSSの2つの基本原則

OOCSSには、以下の2つの重要な原則があります。

• 構造と見た目の分離：幅や高さ、余白といった「構造（レイアウト）」の指定と、背景色や枠線といった「見た目（スキン）」の指定を別々のクラスに分けます。
• コンテナとコンテンツの分離：特定の場所（コンテナ）に依存しないようにクラスを作ります。たとえば「サイドバーの中にある見出し」ではなく「見出しの共通パーツ」として定義し、どこでも使えるようにします。

例えば、ボタンを作る場合、.btnという構造のクラスと、.btn-primaryという見た目のクラスを組み合わせてHTMLに適用します。これにより、同じ構造で色だけが違うボタンを簡単に量産できるようになります。ただし、HTML側に複数のクラス名を記述する必要があるため、HTMLの記述量がやや増える点がデメリットです。

BEM（Block Element Modifier）の特徴と書き方

BEMは、ロシアのYandex社が提唱した命名規則で、現在最も広く普及している手法の一つです。UIを「Block（独立した構成要素）」「Element（Blockを構成する子要素）」「Modifier（BlockやElementの状態・バリエーション）」の3つに分けて考えます。

BEMの命名ルールと具体例

BEMでは、クラス名をアンダースコア（_）やハイフン（-）で繋いで記述します。一般的には、Elementをアンダースコア2つ（__）で繋ぎ、Modifierをハイフン2つ（–）またはアンダースコア1つ（_）で繋ぐ「MindBEMding」という派生ルールがよく使われます。

• Block: .card（カード全体）
• Element: .card__title（カード内のタイトル）
• Modifier: .card--active（アクティブ状態のカード）

BEMの最大のメリットは、クラス名を見るだけでその要素がどのコンポーネントに属しているかが一目でわかることです。また、詳細度が均一になりやすく、スタイルの上書きによる意図しない崩れを防ぐことができます。一方で、「クラス名が非常に長くなりやすい」という点がよくデメリットとして挙げられます。

SMACSS（スマックス）の特徴と書き方

SMACSS（Scalable and Modular Architecture for CSS）は、CSSのルールを5つのカテゴリに分類して管理する設計手法です。クラスの命名規則というよりも、CSSファイル全体の構成やディレクトリ設計の指針として活用されます。

SMACSSの5つのカテゴリ

• Base：リセットCSSや、HTMLタグ自体（body, a, h1など）のデフォルトスタイルを定義します。
• Layout：ヘッダー、フッター、サイドバーなど、ページの大枠となるレイアウトを定義します。IDやプレフィックス（l-など）を用います。
• Module：ボタン、カード、ナビゲーションなど、再利用可能な独立したパーツを定義します。
• State：「非表示（is-hidden）」「アクティブ（is-active）」など、JavaScript等で切り替わる要素の状態を定義します。
• Theme：サイトのテーマ（配色や背景画像など）を定義します。案件によっては省略されることもあります。

SMACSSを取り入れることで、どこに何が書かれているかが明確になります。プレフィックス（接頭辞）をつけるルール（例：レイアウトには .l-header、モジュールには .m-card、状態には .is-active）を採用することで、他の命名規則（BEMなど）と組み合わせて使用されることも多いです。

プロジェクト別！最適なCSS命名規則の選び方

3つの手法を解説しましたが、どれか一つだけが絶対の正解というわけではありません。プロジェクトの規模やチームのスキルに合わせて選択、あるいは組み合わせて使用することが重要です。

• 小規模サイトやLP制作：OOCSSの考え方を取り入れつつ、柔軟にコーディングするのがスピーディです。ガチガチのルール縛りはかえって開発スピードを落とします。
• 中〜大規模なWebサービス・複数人開発：BEMの厳格なルールが威力を発揮します。誰が書いても同じようなクラス名になり、CSSの干渉によるバグを未然に防ぐことができます。
• ディレクトリやファイル構造から見直したい場合：SMACSSの5つの分類を採用し、モジュールの命名にはBEMを使う（FLOCSSのようなハイブリッド手法）のが現代の主流なアプローチの一つです。

CSS命名規則における失敗例と落とし穴

命名規則を導入する際によくある失敗例を紹介します。事前に把握しておくことで、プロジェクトの頓挫を防ぐことができます。

• 【落とし穴1】BEMでDOMツリーをそのままクラス名にしてしまう：.header__nav__list__item__linkのように、親要素からすべてを繋げてしまうとクラス名が肥大化し管理できなくなります。BEMのElementは階層構造ではなく、あくまでBlockに対する所属を表すものです。.header__linkのようにフラットに命名するのが正解です。
• 【落とし穴2】OOCSSでクラスを細分化しすぎる：再利用性を意識しすぎるあまり、.mt-10（上余白10px）や .font-bold のようなユーティリティクラスばかりを作ってしまうケースです。これではHTML側に装飾の指定が散乱してしまい、OOCSS本来のコンポーネント設計から外れてしまいます（ユーティリティ主導のTailwind CSS等を使う場合は別ですが、自作する場合は注意が必要です）。
• 【落とし穴3】チーム内でルールが共有されていない：どんなに優れた設計手法を導入しても、メンバーが理解していなければすぐに破綻します。ドキュメント化やコードレビューの徹底が不可欠です。

【実用】CSS命名規則の導入チェックリスト

実際のプロジェクトで命名規則を策定・導入する際に活用できるチェックリストです。プロジェクト開始前にチーム全体ですり合わせを行いましょう。

• プロジェクトの規模と寿命（保守期間）を把握し、適切な厳密さの手法を選んでいるか？
• BEMのセパレーター（繋ぎ文字）のルールは統一されているか？
• SMACSSの状態を表すクラス（is-*）を他のモジュールと混同していないか？
• CSSの入れ子（ネスト）の深さの上限を定めているか？（推奨は3階層まで）
• コンポーネントの命名に関する辞書（単語リスト）を作成し、表記揺れを防いでいるか？

よくある質問（FAQ）

Q1: 複数の命名規則を混ぜて使っても良いのでしょうか？

A1: はい、全く問題ありません。むしろ現代のWeb開発では、SMACSSのファイル分類の考え方をベースにしつつ、各モジュールのクラス名にはBEMのルールを採用するといった「いいとこ取り」の手法（FLOCSSなど）が主流となっています。チームでルールが統一されていれば大丈夫です。

Q2: BEMのクラス名が長すぎてHTMLが見づらくなるのですが、対策はありますか？

A2: 確かにBEMはクラス名が長くなりがちです。対策としては、Blockの単位を適切に小さく分割することが挙げられます。1つの巨大なBlockにすべてを詰め込むのではなく、独立できる部分は新しいBlockとして切り出すことで、Element名が過剰に長くなるのを防ぐことができます。

Q3: 個人開発の小さなWebページでも命名規則は必要ですか？

A3: 個人開発であれば、厳密すぎるルールは不要かもしれません。しかし、「構造と見た目を分ける（OOCSS）」「状態にはis-をつける（SMACSS）」といったエッセンスを少し取り入れるだけでも、後からコードを見返したときの理解しやすさが劇的に向上するため、基本的な概念を知っておくことは非常に有益です。