設計思想
「CSS アーキテクチャを覚える」から「ツールが検証する」へ。
SpiraCSS は 「親が子のレイアウトを決め、子は内部だけを書く」 という原則に基づき、構造判断を Stylelint で検証可能にします。
既存の CSS 設計手法が抱える課題
BEM / SMACSS / OOCSS / RSCSS / ITCSS / CUBE CSS など、数多くの設計手法が「CSS をどう構造化し、保守可能にするか」という課題に取り組んできました。
しかし、これらに共通する課題があります：
「コンポーネントの境界や命名の判断が、人の感覚や解釈に依存する」
- どこまでを 1 つのコンポーネントとするか？
- この要素は親の一部か、独立したコンポーネントか？
- 親と子のレイアウト責務をどちらが持つか？
- どんな命名規則に従うべきか？
これらの判断は「ガイドライン」として示されるものの、ルールを覚える負担があり、最終的には実装者の経験や感覚に委ねられてきました。その結果：
- プロジェクトごとに分割の粒度や命名がバラつく
- コードレビューでコンポーネント境界の議論に時間を費やす
- AI に指示しても一貫性が保てないことがある
また RSCSS は One component per file を明記しており、BEM もブロック実装を技術ごとの別ファイルに分ける方針です。しかしファイル分割に伴う行き来の煩雑さを補う運用支援が十分でなく、命名規則だけが取り入れられ実務では定着しにくい状態が続いていました。
SpiraCSS のアプローチ
クラス名で構造を表現し、Block 単位でファイルを分割します。
その上で、構造判断を「解釈」ではなく「不変条件」に落とし込みます。Block ごとにファイルを分け、各 Block が自分の責務だけを持ち、子は内部を自己完結させ、親が子に対して行うのはレイアウトのみです。この考え方は、プログラミングにおけるオブジェクト指向（責務の分離やカプセル化）に通じるものがあるかもしれません。
コンポーネント境界の曖昧さを解消する
既存の CSS 設計ではコンポーネントの境界判断に人の解釈が入り、その判断次第で命名や配置も変わります。SpiraCSS は「Block > 子（Block または Element）」の繰り返しだけで構造を表現し、Stylelint でその構造を強制するため破綻しません。
クラス名の衝突を物理的に防ぐ
コンポーネントごとに SCSS フォルダを作り、1 Block = 1 ファイル、かつファイル名 = Block 名というルールを適用します。同じフォルダ内に同名のファイルは作れないため、Block 名の衝突は物理的にありえません。ルールで禁止するのではなく、構造として不可能にしています。
Modifier を Variant と State に分離する
従来の BEM Modifier は「見た目のバリエーション」と「インタラクション状態」を同じ仕組みで扱っていたため、両者の区別が曖昧でした。SpiraCSS では静的な差分（Variant）と動的な状態（State）を分離し、デフォルトでは data-variant / data-state 属性で明示します。HTML レベルで両者の区別が明確になり、SCSS 内の書く場所も Stylelint が検証するため、コード全体で統一されます。
レイアウトとプロパティの責務を明確にする
CSS のレイアウトは本質的に「親が子を並べる」仕組みです（親に display: flex、子に align-self）。子の margin も親のレイアウトに影響するため、子自身ではなく親から指定します。この性質に基づき、SpiraCSS はどのプロパティを誰が持つべきか明確に規定します。親子間で責務を分離するという点で、オブジェクト指向の考え方をイメージするとわかりやすいかもしれません。
ファイル内の構造も明確にする
既存の CSS 設計手法は「どのファイルに何を書くか」は規定しても、「1 つのファイル内でどう構成するか」は言及していませんでした。SpiraCSS では —interaction・—shared などのセクション構成を規定し、ファイル内の構造も明確にしています。
ファイル間の移動を容易にする
1 Block = 1 ファイルの運用では、1 ファイル内を検索するのではなく関連ファイルへ移動する形になります。手動でディレクトリからファイルを探すのは手間がかかるため、@rel コメントでリンクを張り、VS Code 拡張（SpiraCSS Comment Links）でクリック遷移することで親子 Block 間を高速に行き来しながら編集します。
ルールは暗記ではなくツールが検証する
人間でも判断がブレるルールを、AI に指示しても安定しません。機械的に検証できるルールだけを採用し、ツールに任せることで、人間も AI も同じ基準で正しいコードを書けます。
エラーメッセージで自律修正させる
AI に複雑なルールを指示書で理解させるのは非現実的です。TypeScript の型エラーのように「何が間違っているか」「どう直すべきか」をエラーメッセージに含めれば、AI は自律的に修正できます。人間も同じメッセージで学べるため、新人教育にも有効です。
SPIRA の意味
SpiraCSS = Simplified Practical Integrated Relational Architecture
| 原則 | 意味 |
|---|---|
| Simplified | 「親が子のレイアウトを決め、子は内部だけを書く」を原則 |
| Practical | 実務で曖昧になりがちなプロパティの責務やセクション構成を規定 |
| Integrated | HTML 構造・SCSS・ツールが同じルールで連動、Stylelint で検証 |
| Relational | @rel コメントでファイル間の依存関係を明示 |
| Architecture | CSS レイヤー 3 層と 1 Block = 1 ファイルで全体を設計 |