Web制作2026年10月13日

CSSの命名規則FLOCSSとは

クラス名が案件ごとに違う。ボタンが .btn と .c-button と .p-mv__btn で三つある。検索して上書きし、詳細度が伸びる。その時間は、よくあります。命名を揃えれば破綻しない、という保証はありません。先に「どの層のクラスか」が見えると、後から入った人が触る場所を選びやすい、です。

結論です。FLOCSS は、Hiroki Tani 氏（hiloki）が公開した CSSの構成案 です。公式READMEでは、OOCSS、SMACSS、BEM、SuitCSS の考え方を取り入れ、MCSS の層構成からも影響を受けたとあります。フレームワークのインストール名ではありません。フォルダと接頭辞の約束です。2014年公開、という説明は本人のスライドにあります。現在の利用率の数字は、この原稿では出しません。

この記事では、フリーランスのWebディレクター兼エンジニアとして、公式の層と命名、現場で崩れやすい点を整理します。FLOCSSを入れれば保守が終わる、とは書きません。

層は3つ。Object の中が3つ

公式の基本原則です。

Foundation — Reset / Normalize、下地の背景、基本のタイポグラフィ
Layout — ヘッダー、メイン、サイドバー、フッターなど、ページ共通の大きな枠
Object

読み込み順を前後させない、が公式の注意です。後ろの層ほど具体的で、勝たせる、という考え方です。順番を入れ替えると、詳細度の見通しが落ちます。必ず破綻する、ではありません。後から入った人が「どこが勝っているか」を追いづらくなります。

グリッドの mixin を Foundation に置くか、クラス化したグリッドを Component に置くかは、公式にも「運用で変わる余地がある」と注記があります。チームで一文決めておく対象です。

命名：MindBEMding と接頭辞

Object のクラスは、BEM そのものではなく MindBEMding を基本にする、と公式にあります。ブロック、要素、修飾子です。

公式が推奨する接頭辞です。

Component: .c-*
Project: .p-*
Utility: .u-*
Layout: l-* を使うか、ID / 属性セレクタ（詳細度に注意）

状態は、SMACSS の State を借りて .is-active のようにできる、とあります。ただし .is-active 単体にスタイルを持たせない。他モジュールの状態を汚染しないためです。

<button class="c-button is-active" type="button">保存</button>

.c-button {
  display: inline-block;
  padding: 0.5em 1em;
}

.c-button.is-active {
  outline: 2px solid currentColor;
}

キャメルケースとの組み合わせは、公式も「プロジェクトの規則に従ってもよい。一貫性が先」としています。接頭辞を案件で変えること自体は否定しません。.c- と .cmp- が混在するほうが、後工程の検索を増やします。

悪い分け方と、公式に近い分け方

悪い分け方

見た目が似ているから、全部 .c- に入れる。MV 専用のヒーローを .c-hero にしたまま、他ページで色だけ上書きする。余白の例外も Modifier で増やし続ける。公式が Utility に分けた理由（Object を無尽蔵に増やさない）と逆です。

公式に近い分け方

層	置くもの	置きにくいもの
Foundation	リセット、`:root` のトークン、本文の基本	特定ページの飾り
Layout	ページを分ける枠。幅や段の骨格	ロゴ画像の影など、部品の見た目
Component	色や幅を持ちすぎない、使い回す部品	そのキャンペーンだけの塊
Project	記事カード一覧、価格表など、案件固有	全案件共通のボタン
Utility	隣接との間隔、表示の切り替え	部品の「本体」の見た目

Component は「固有の幅や色を持ちすぎないほうがよい」、と公式にあります。ブランド色を全部 Component に固めると、案件をまたいだ再利用が落ちます。必ず無彩色にせよ、ではありません。最低限の機能、が公式の言葉です。

カスケードで、公式が禁じていること

同一層のモジュール同士を、親セレクタで混ぜない。.c-dialog .c-button のような依存は、公式は好ましくない、としています。モジュールが独立して使えないためです。

例外として、Project が Component を変えることは許容、とあります。それでも、可能なら Project の Element か、Component の Modifier で済ませるほうが、詳細度は伸びにくい、という説明です。他モジュールを親に持つのは1つまで、適用範囲は限定する、が例外時の条件です。

プリプロセッサの @extend は、モジュール内で完結する以外は原則禁止、と公式にあります。層をまたぐ継承は、構成が追いづらくなります。

実務での3つの使い方

1. フォルダを公式どおり切る

Sass なら、公式のディレクトリ例がそのまま使えます。app.scss からの @import 順を、Foundation → Layout → Object に固定する。ファイル名より、層の順が先です。

2. レビューで接頭辞だけ見る

プルリクエストで「このクラスは .c- か .p- か」を一文聞く。見た目の正しさより先に、層がずれていないかを見る。時間は短い。後の上書きより安いことが多い。必ず安い、ではありません。

3. AI にCSSを書かせるとき

プロンプトに「FLOCSSの層と .c- .p- .u- を守る」と書く。それだけでは、公式に無いクラスが混ざります。生成後に、接頭辞とファイルの置き場を人が見る。Markdownで層を指示するのは、整理の手段です。モデルの判断が良くなる、という意味ではありません。

現場でハマりやすい点

Layout と、機能を持ったヘッダーを同一クラスにする: 本人スライドでも、枠としての Header と、機能モジュールとしての Header を分ける話があります。
Utility をデザインシステム化する: 余白の全パターンを .u- に出すと、ファイルは太ります。公式例は .u-mbs のような、必要な調整です。
IDを Layout で多用する: 公式は可能としつつ、詳細度を懸念するなら l-* か属性セレクタ、としています。
「FLOCSS導入済み」だけで中身が無い: フォルダ名だけ公式で、クラスが .btn のまま、はよくあります。

一次情報は hiloki/flocss です。解説記事は多くあります。層の定義が食い違うときは、README を正とします。

まとめ：名前の規則より、層の約束

FLOCSS は、クラスの見た目を美しくする技法ではありません。Foundation / Layout / Object の順と、.c- .p- .u- の役割を先に決める構成案です。守れば壊れない、とは言いません。後から入った人が、触ってよいファイルを選びやすくなります。

CSSの層と命名の揃え方、既存クラスからの移行の相談は、相談・お問い合わせからどうぞ。