CUBE CSS — Composition Utility Block Exception

CUBE CSS は Andy Bell が 2019 年頃に提唱した CSS 方法論で、Composition（合成）/ Utility（ユーティリティ）/ Block（ブロック）/ Exception（例外）の 4 つのレイヤーで CSS を整理する。BEM のような厳格な命名規約や Tailwind のような全面的ユーティリティ化に頼らず、cascade と継承を積極的に活かす低 specificity 設計が特徴で、design token を前提とするモダンなフロントエンド開発と相性がよい。

CUBE CSS とは何か

CUBE CSS は CSS フレームワークではなく、CSS をどう構造化するかという考え方の集合体である。著者は英国のフロントエンド開発者・教育者である Andy Bell で、自身のスタジオ Set Studio や教育サイト Piccalilli を通じて広めた。公式ドキュメントは cube.fyi に集約されている。

中心思想は「cascade を敵視せず利用する」点にある。多くの先行手法は specificity 戦争を避けるため class を局所化する方向に進化したが、CUBE CSS は逆に、グローバルな defaults（base styles）と composition primitives を最大限利用し、Block での個別記述を可能な限り減らす。CSS 本来の継承・cascade を「機能」として扱う発想であり、design token と HTML の意味構造が先にある現代の web 開発と整合する。

methodology であってライブラリではないため pinning するバージョンは存在せず、HTML/CSS が書ける環境であれば framework に依存せず適用できる。Eleventy や Astro などの content 駆動型フレームワークと組み合わせて採用されることが多い。

4 つのレイヤー: C-U-B-E

C — Composition（合成）: 要素の配置と流れを司る高レベルなレイアウト primitives。stack（縦方向の間隔）、cluster（折り返す横並び）、grid（自動列数の grid）など、Every Layout の概念に近い汎用的なレイアウト構造を担う。Composition は中身の見た目を決めず、空間配置のみを定義する。

.stack > * + * {
  margin-block-start: var(--space-m, 1rem);
}

U — Utility（ユーティリティ）: 単一の役割を持つ class で、design token（色・余白・タイポグラフィのスケール）から直接派生させる。Tailwind のように全 CSS プロパティを utility 化するのではなく、token に紐づく粒度に絞るのが CUBE 流の運用である。

.bg-primary { background: var(--color-primary); }
.color-on-primary { color: var(--color-on-primary); }
.font-base { font-family: var(--font-base); }

B — Block（ブロック）: UI を構成する component 単位のスタイル。BEM の Block に似るが、composition と utility が大半を担うため、Block の責務は固有の見た目のみに絞られる。CSS ファイルが薄くなりやすい。

.card {
  border-radius: 0.5rem;
  padding: var(--space-m);
  background: var(--color-surface);
}

E — Exception（例外）: Block の通常状態から逸脱する variation を、modifier class ではなく data-* 属性で表現する。状態（state）と見た目の二系統を切り分け、JS 側との接続点も明確になる。

.card[data-state="reversed"] {
  display: flex;
  flex-direction: column-reverse;
}

クラスのグルーピング規約

CUBE CSS は、HTML 上で複数 class を書く際に角括弧（[ ]）でレイヤーを視覚的に分割する記法を推奨する。括弧自体は class 名の一部ではなく、空白として扱われる人間向けの区切り記号である。

<article
  class="[ card ] [ section box ] [ bg-primary color-on-primary ]"
  data-state="reversed"
>
  ...
</article>

この例では、最初のグループが Block、次が Composition primitives、最後が Utility である。Exception は data-state 属性として独立する。レビュー時に「どの class がどのレイヤー責務か」を一目で識別でき、Block への追記が増えすぎていないかも把握しやすい。括弧記法は任意であり、チームの好みでパイプ | などに置き換える例もある。

他の CSS 手法との比較

CUBE CSS の位置づけは、他の代表的な CSS 方法論と並べると理解しやすい。

実務上特に重要なのは Tailwind との関係である。Tailwind が「CSS を書かない」方向の最適化であるのに対し、CUBE は「CSS を整理して書く」方向の最適化なので、両者は排他ではない。Tailwind の token 設定を Utility 層として流用しつつ、Composition と Block は手書きで運用する組み合わせも成立する。一方 BEM 中心のチームが CUBE へ移行する場合は、modifier class を data-* 属性へ機械的に置換する作業が中心になる。

いつ使うか / いつ使わないか

採用に適しているのは次のような条件下である。

• design token（色・spacing・typography のスケール）が既に定義されているか、これから定義する余地があるプロジェクト。
• cascade と継承を否定せず、低 specificity な CSS を志向するチーム。
• Eleventy・Astro・Hugo など、HTML/CSS をフルコントロールする content 駆動型 framework を使う場合。
• BEM などの重い命名規約から脱したいが、Tailwind ほど全面的なシフトはしたくない場合。
• グリーンフィールドのデザインシステム構築。

逆に採用が推奨されないのは以下のような状況である。

• すでに Tailwind を全社的に運用していて、methodology の切り替えコストが利点を上回るチーム。
• 多数のチームが横断的に CSS を編集し、厳格な class 命名契約が運用上の利益を生んでいる現場（BEM の冗長性は資産になる）。
• 数ページ規模の小型プロジェクトで、いかなる方法論も過剰設計になる場合。
• design token を持たず、ad-hoc な色・余白指定が許容されているレガシー環境。

参考資料

• CUBE CSS 公式ドキュメント (cube.fyi) — Andy Bell による一次情報。各レイヤーの定義と運用例が簡潔に整理されている。
• Piccalilli — Andy Bell の教育サイト。CUBE CSS を実例で解説するチュートリアルと有料コースを公開。
• Every Layout — Heydon Pickering と Andy Bell による Composition primitives のカタログ。stack / cluster / grid などの実装パターンを学べる。