SCSS を運用していると、だんだん迷いやすくなるのが c- と p- の境界 です。

ブロックを切り出すかどうかを考えるとき、再利用可能性はたしかに重要です。ただ実際には、「今後ほかでも使うか」は作成時点では判断しにくいことが少なくありません。

最近は AI でリネームや関連箇所の追従修正をしやすくなったので、いったんは「単一なら p-、複数なら c-」のような運用も考えやすくなりました。
ただ、作業コストが下がっても、変更するかどうかを判断するコスト は残ります。再利用回数を基準にするとその判断頻度が増えやすいので、今は ブロックを切り出す理由 と 部品の大きさ を分けて考える方が整理しやすいと感じています。

この記事では、SCSS のプレフィックスを、ブロックを切り出す理由 と 部品の大きさ の観点でどう整理すると扱いやすいかをまとめます。

global / base / layouts / components / utility の 読み込み順 や u-* の役割 は、SCSS の分割と読み込み順、u- と c- の役割 に分けて書いています。

まず結論

今のところ、自分は次のように整理しています。

• ブロックを切り出すのは、再利用可能性がある場合 または 独立して管理したい場合
• c-* は 見た目を持つ小さな部品
• p-* は ページやセクション単位の大きな部品

さらに配置先もそろえると、探しやすくなります。

src/assets/sass/
├── base/
├── components/
├── global/
├── layouts/
├── projects/
├── utility/
└── style.scss

• c-* は components/
• p-* は projects/

ブロックを切り出す理由と、c- / p- の分け方

まず、ブロックを切り出す理由と、c- / p- の分け方は分けて考える方が整理しやすいです。

ブロックを切り出すのは、たとえば次のような場合です。

• ほかの場所でも使う可能性がある
• 1 箇所でしか使わなくても、独立して管理したい

たとえばハンバーガーボタンは、サイト内で 1 箇所にしか置かないことが多い部品です。
それでも、ドロワー開閉に応じて見た目が変わり、記述も増えやすいなら、p-header__menu-button として p-header に抱え込むより、c-menu-button として分けた方が管理しやすいことがあります。

一方で、c- と p- を 「複数箇所で使うなら c-、1 箇所なら p-」 と決めると、作成時に迷いやすくなります。
AI により後からの変更作業はしやすくなりましたが、それでも「変更すべきか」を判断する頻度が増えると、そちらの方がコストになりがちです。

そのため、c- / p- は次のように 部品の大きさ で決める方が安定します。

• c-*: ボタン、見出し、ラベル、装飾テキストなど、小さく自己完結した部品
• p-*: ヘッダー、ヒーロー、一覧セクション、カード群など、ページやセクションを構成する大きなまとまり

つまり、再利用可能性は ブロックを切り出すかどうか の判断材料にはなりますが、c- / p- の主な判断基準にはしない、という整理です。

まとめ

SCSS の c- と p- を安定して運用したいなら、次のように整理すると扱いやすくなります。

• ブロックを切り出すのは、再利用可能性がある場合、または独立して管理したい場合
• c-* は見た目を持つ小さな部品
• p-* はページやセクション単位の大きな部品
• c-* / p-* は再利用回数ではなく、部品の大きさで分ける
• AI で変更作業のコストは下がっても、変更判断コストは残るので、再利用回数ベースの運用は採用しない

c-menu-button のように、1 箇所でしか使わなくても独立して管理したい小さな UI 部品を c-* として切り出せるようにしておくと、SCSS の読みやすさと運用の安定感はかなり変わります。