CSSフレームワークを使わない選択は本当に最適解？メリット・デメリットとモダンCSSで作る独自UIの秘訣

Web制作の現場でBootstrapやTailwind CSSのようなCSSフレームワークは、もはや当たり前の存在になりましたよね。手軽に開発を始められ、それなりに見た目も整うから便利だと感じる方も多いでしょう。でも、こんな風に感じたことはありませんか？

「なんだかHTMLがクラス名だらけで読みにくいな…」

「使わないCSSまで含まれて、ファイルが重くなっている気がする」

「もっとオリジナリティのあるデザインにしたいのに、フレームワークの制約が邪魔だな」

「結局、カスタマイズに時間がかかって、かえって非効率になっているかも？」

「CSSの基礎力がこのままでいいのか、少し不安だ…」

もし一つでも心当たりがあるなら、あなたは正しい道をたどっています。実は今、多くのプロのWeb開発者が「本当にCSSフレームワークは必要なのか？」という問いを立て、あえて使わないという選択に注目しているんです。フレームワークがもたらす手軽さの裏側には、コードの冗長化やパフォーマンスの低下、デザインの画一化といった悩みが潜んでいることも少なくありません。

しかし、フレームワークを使わないとなると、「どうやって効率的にCSSを書けばいいの？」「もっと複雑になるんじゃないの？」といった新たな疑問が湧いてくるかもしれませんね。ご安心ください。現代のCSSは、フレームワークに頼らずとも、驚くほど効率的で高品質なWebサイトを構築できる力を持っています。

このリード文を読んでいるあなたは、きっと現状の課題を解決し、ご自身のスキルをさらに高めたいと願っているはずです。この記事では、そんなあなたの疑問や悩みを解消し、次のステップへと進むための具体的な道筋を示します。

本編で、具体的な解決策と実践的なヒントを詳しくご紹介します。

CSSフレームワーク「使わない」選択肢：本当に必要？

なぜ今、CSSフレームワークを使わないのか？

近年、Tailwind CSSに代表されるユーティリティファーストなCSSフレームワークが人気を博していますが、それと同時に「CSSフレームワークを使わない」という選択肢が注目され始めています。なぜ今、多くの開発者がフレームワークに疑問を持ち、あるいは脱却を検討しているのでしょうか？主な理由として、以下の点が挙げられます。

tailwindcssの使い方をさくっと説明 - ざっくり入門したい人向け

tailwindcssはcssフレームワークです。他のCSSフレームワークとの違いはtailwindcssはユーティリティークラスの集まりだということです。CSSフレームワークの代表的な存在の「Twitter Bootstrap」はユーティリティークラスの他にデザインされたコンポーネントを使用することができます。Twi...

watashi.xyz

2022.11.04

tailwindcssをWordPressにマッチさせる方法 - テーマ開発における相性の悪さをカバーしよう

tailwindcssというCSSフレームワークが人気です。非常に便利なのでWordPressテーマ開発に導入して見たところ相性について思うことがありましたのでお伝えします。tailwindcssとはユーティリティーベースのCSSフレームワークです。似たようなものにTwitterBootstrap等があります。Twit...

watashi.xyz

2022.10.05

1. HTMLの冗長性と可読性の低下

最も一般的な不満の一つが、HTMLに大量のクラス名が記述されることによる可読性の低下です。特にTailwind CSSのようなユーティリティファーストのフレームワークは、細かなスタイルをクラスとして直接HTMLに記述するため、見た目とHTML構造が密結合になります。

例: Tailwind CSS使用時

<!-- Tailwind CSS使用時のHTML -->
<div class="flex items-center justify-between p-4 bg-white shadow-md rounded-lg">
  <h2 class="text-xl font-bold text-gray-800">タイトル</h2>
  <button class="bg-blue-500 hover:bg-blue-700 text-white font-bold py-2 px-4 rounded">
    詳細を見る
  </button>
</div>

このHTMLは、一見して要素の役割や構造を把握しにくく、CSSの変更がHTMLにまで波及するため、メンテナンス性が低下する可能性があります。

2. 不要なCSSの肥大化とパフォーマンスへの懸念

多くのCSSフレームワークは、豊富なコンポーネントやユーティリティクラスを提供しています。しかし、そのすべてがプロジェクトで使われるわけではありません。結果として、必要のないCSSも含まれるため、CSSファイルのサイズが肥大化し、ページの読み込み速度に悪影響を与えることがあります。

例えば、Bootstrapは多機能であるゆえに、使わないスタイルも多く含まれがちです。Tailwind CSSはJITコンパイラやPurgeCSS（Tailwind CSS v3.0以降はJITに統合され、CSSをパージする機能が標準で組み込まれていますが、ビルドプロセスは必要です）によって未使用のCSSを削減できますが、それでもビルドプロセスは必須であり、完璧にゼロにするのは難しいケースもあります。

3. デザインの画一化とオリジナリティの欠如

手軽に利用できる反面、フレームワークが提供する標準的なスタイルに縛られ、Webサイトのデザインが画一的になりがちです。独自のブランドイメージや、ピクセルパーフェクトなデザインを実現しようとすると、フレームワークのデフォルトスタイルを上書きしたり、複雑なカスタマイズが必要になったりすることがあります。これは、フレームワークを導入したメリットを相殺し、かえって手間を増やすことにもつながります。

4. 学習コストと将来的な依存リスク

フレームワークにはそれぞれ独自の記法やルールがあり、それを習得するための学習コストが発生します。プロジェクトごとに異なるフレームワークが使われている場合、開発者は複数のフレームワークの知識を維持する必要が出てきます。また、特定のフレームワークに過度に依存してしまうと、そのフレームワークのアップデートやサポート終了が、将来的にプロジェクトの維持管理に大きな影響を与えるリスクも考えられます。

これらの問題意識から、「本当にこのプロジェクトにCSSフレームワークは必要なのか？」「フレームワークなしで、もっとシンプルかつ効率的にCSSを書く方法はないのか？」という問いが開発者の間で広がり、脱フレームワークへの関心が高まっているのです。

Tailwind CSS、Bootstrapを使わない本当のメリット・デメリット

CSSフレームワークを使わないという選択は、一見すると手間が増えるように思えるかもしれません。しかし、そこには多くのメリットが存在します。もちろん、デメリットも理解しておく必要があります。

メリット：

パフォーマンスの最大化とCSSファイルの軽量化

• 本当に必要なCSSだけを記述: フレームワークが提供する「使わないCSS」が含まれないため、CSSファイルのサイズを最小限に抑えられます。これにより、ページのレンダリング速度が向上し、特にモバイル環境でのユーザー体験が改善されます。
• HTTPリクエストの削減: CSSファイルの軽量化は、ネットワークリソースの節約にも繋がります。

デザインの自由度と高いオリジナリティ

• ピクセルパーフェクトなデザイン: フレームワークの制約を受けず、デザイナーの意図した通りにピクセル単位で正確なデザインを実装できます。ブランドイメージを忠実に反映した、独自のUI/UXを追求することが可能です。
• 細部の調整が容易: わずかなスペースや微妙なフォントサイズ調整など、フレームワークでは上書きが難しいような細部の調整も、ダイレクトにCSSで記述できるため容易です。

HTMLのセマンティック化と可読性の向上

• クラス名の簡素化: スタイルのための冗長なクラス名が減り、HTML要素本来の役割や構造を示すクラス名（例: class="main-header", class="product-card"）に集中できます。これにより、HTMLコードの可読性が大幅に向上し、HTMLを見ただけでページの構造を理解しやすくなります。
• スタイルと構造の分離: CSSが独立したファイルで管理されるため、HTMLはコンテンツと構造に、CSSはスタイルに専念するという、Web標準に則った理想的な分離が実現できます。

CSSの基礎力向上と真のスキル習得

• 「なぜそうなるか」の理解: フレームワークの魔法に頼らず、自身でCSSプロパティを記述することで、「なぜこのスタイルが適用されるのか」「どうすればこのレイアウトになるのか」というCSSの基本原則やレンダリングの仕組みを深く理解できます。
• 汎用性の高いスキル: フレームワークに依存しない純粋なCSSスキルは、どんなプロジェクトや新しい技術が登場しても通用する、普遍的なフロントエンド開発の基盤となります。

長期的な保守性と安定性

• フレームワーク依存からの脱却: 特定のフレームワークのバージョンアップや非推奨化、あるいはコミュニティの衰退といった外部要因に左右されるリスクがなくなります。
• 予測可能なメンテナンス: 自分で書いたCSSは、すべてを自分でコントロールできるため、未来のメンテナンスや拡張が容易になります。

デメリット：

初期開発コストの増加

• ゼロからの構築: コンポーネントやユーティリティクラスをゼロから設計・実装する必要があるため、フレームワークを導入する場合と比較して、特にプロジェクト初期の開発速度は遅くなる可能性があります。
• 共通スタイルの再発明: ボタンやフォーム要素、グリッドシステムなど、多くのプロジェクトで共通して使われるスタイルを、毎回自分で書く手間が発生する可能性があります。

チーム開発におけるルール統一の難しさ

• コーディング規約の徹底: フレームワークが提供する規約がないため、チーム内で厳格なコーディング規約を定め、それを徹底させるための仕組み（Stylelintなど）や合意形成がより重要になります。
• スキルレベルのばらつき: チームメンバーのCSSスキルにばらつきがある場合、コード品質に差が出やすく、コードレビューの負担が増える可能性があります。

複雑なUIコンポーネントの実装負荷

• JavaScriptとの連携: ドロップダウンメニュー、モーダル、タブUIなど、JavaScriptとの連携が必要な複雑なUIコンポーネントは、フレームワークが提供するものを利用する方が手軽です。これらをゼロから実装するには、CSSだけでなくJavaScriptの知識も必要となり、工数が増えます。

レスポンシブデザインの実装手間

• ブレークポイントの管理: フレームワークはレスポンシブデザインのためのユーティリティクラスやグリッドシステムを豊富に提供していますが、これらを自作CSSで管理する場合、メディアクエリの記述やブレークポイントの設計を手動で行う手間が増えます。

これらのメリットとデメリットを総合的に判断し、プロジェクトの性質やチームのスキルセット、目指す品質に応じて、CSSフレームワークを使うべきか否かを検討することが重要です。

あなたのプロジェクトにCSSフレームワークは「不要」なケースとは？

CSSフレームワークを使わないという選択が特に適しているプロジェクトや状況は確かに存在します。以下に具体的なケースを挙げます。

独自のブランドイメージが強く求められるWebサイト

• 企業のブランドサイトやキャンペーンページ: デザイナーが細部にまでこだわった、オリジナリティの高いデザインを忠実に再現したい場合、フレームワークのデフォルトスタイルを上書きするよりも、ゼロからCSSを記述する方が柔軟に対応できます。フレームワークによる「画一的な見た目」を避けたい場合に最適です。

パフォーマンスが最重要視されるプロジェクト

• LP（ランディングページ）や非常に軽量なWebサイト: ページの読み込み速度が直接コンバージョンに影響するLPや、シンプルさが求められる静的なWebサイトでは、わずかなCSSファイルの肥大化も避けたいところです。不要なCSSを一切含まない自作CSSが、最高のパフォーマンスを実現します。
• Core Web Vitalsの最適化: LCP（Largest Contentful Paint）やCLS（Cumulative Layout Shift）といったCore Web Vitalsの指標改善を目指す上で、CSSの最適化は不可欠です。フレームワークのオーバーヘッドを排除することで、より制御しやすい環境が得られます。

小規模なWebサイトやプロトタイプ開発

• シンプルなコーポレートサイトや個人ブログ: 複雑なUIコンポーネントが不要で、かつ短期間で開発する必要がない場合、フレームワークの導入・学習コストをかけるよりも、素のCSSで手早く実装する方が効率的なことがあります。
• PoC（概念実証）や技術検証: 特定のCSS機能の検証や、新しいレイアウトのプロトタイプ作成など、小規模で使い捨ての可能性もあるプロジェクトでは、フレームワークの依存関係を持たない方が身軽に開発を進められます。

既存システムとの密な統合が必要な場合

• レガシーシステムへの部分的なUI改修: 既存のCSSやJS資産が大量にあるプロジェクトに、安易に新しいCSSフレームワークを導入すると、スタイル衝突や予期せぬ動作を引き起こす可能性があります。既存のCSS設計に合わせた形で、必要な部分だけを素のCSSで記述する方が、リスクを抑えられます。
• コンポーネントライブラリやUIキットの自作: 複数プロジェクトで共通して利用するカスタムUIコンポーネントを構築する場合、特定のフレームワークに依存させないことで、汎用性と再利用性を高めることができます。

CSSの基礎力を高めたい個人開発者・学習者

• スキルアップを目的としたプロジェクト: フレームワークを使わず、自身のCSSスキルのみで一からUIを構築する経験は、CSSの深い理解と問題解決能力を養う上で非常に有効です。今後のキャリアにおいて、どんなフレームワークを使おうとも、その土台となるCSSの基礎力が盤石になります。

特定のモダンなCSS機能（CSS Grid、Custom Propertiesなど）をフル活用したい場合

• フレームワークが提供するグリッドシステムやカラースキームに頼らず、CSS GridやFlexbox、CSS Custom Propertiesなどのネイティブな機能で柔軟なデザインシステムを構築したい場合に、フレームワークの制約が邪魔になることがあります。

これらのケースに当てはまるのであれば、CSSフレームワークを使わないという選択は、開発効率、パフォーマンス、デザインの自由度、そして自身のスキルアップにおいて、非常に有効な戦略となり得ます。

フレームワークなしで効率的にCSSを書くための設計手法と実践例

CSSフレームワークを使わないことは、闇雲にCSSを書くことを意味しません。むしろ、より計画的で堅牢なCSS設計が求められます。ここでは、効率的かつ保守性の高いCSSを書くための設計手法と、最新のCSS機能を活用した実践例を紹介します。

BEM＋ITCSSで階層化――可読性を保つ命名＆フォルダ構成

CSSのメンテナンス性を高める上で最も重要なのは、一貫した命名規則とファイル構造です。ここでは、広く採用されている「BEM」と「ITCSS」を組み合わせたハイブリッドなアプローチを提案します。

BEM（Block Element Modifier）の導入と命名規則

BEMは、UIを「Block」「Element」「Modifier」の3つの要素に分解し、それぞれの役割に基づいてクラス名を命名する手法です。これにより、CSSのスコープが明確になり、スタイル衝突を防ぎ、再利用性を高めます。

• Block（ブロック）: 再利用可能な独立したコンポーネントのルート要素。（例: .card, .button, .header）
• Element（要素）: ブロックの一部であり、単独では意味を持たない要素。（例: .card__title, .button__icon, .header__logo）
  • ブロック名と要素名は __ で連結します。
• Modifier（修飾子）: ブロックや要素の状態、バリエーションを表す。（例: .button--primary, .card--active, .button--disabled）
  • ブロック/要素名と修飾子名は - で連結します。

BEM命名規則の例

/* Block */
.user-profile {
  /* スタイル */
}

/* Element */
.user-profile__avatar {
  /* スタイル */
}

.user-profile__name {
  /* スタイル */
}

/* Modifier */
.user-profile--active {
  /* アクティブ状態のプロフィールに対するスタイル */
}

.user-profile__avatar--small {
  /* 小さいアバターに対するスタイル */
}

BEMを徹底することで、HTMLクラス名を見ただけで、その要素がどのコンポーネントのどの部分であり、どのような状態であるかが一目瞭然となり、可読性が飛躍的に向上します。

ITCSS（Inverted Triangle CSS）によるCSSファイル構造の階層化

ITCSSは、CSSの特定のルールが他のルールに影響を与える「詳細度（Specificity）」の問題を解決し、大規模なCSSを管理しやすくするためのアーキテクチャです。詳細度の低いものから高いものへと順番にファイルを読み込むことで、スタイルが予期せず上書きされるのを防ぎます。

ITCSSでは、CSSファイルを以下のレイヤーに分割します。

1. Settings: グローバルな変数、フォント定義など（Sassの_variables.scssなど）
2. Tools: MixinやFunctionなど（Sassの_mixins.scss, _functions.scssなど）
3. Generic: リセットCSS、Normalize.css、box-sizingなどの一般的なスタイル
4. Elements: HTML要素に対するデフォルトスタイル（h1, a, pなど）
5. Objects: OOCSSの考え方に基づく抽象的なレイアウトパターンやオブジェクト（.wrapper, .media-objectなど）
6. Components: UIを構成する具体的なコンポーネントのスタイル（.button, .card, .navigationなど、BEMのBlockに対応）
7. Trumps: 強制的にスタイルを上書きするユーティリティクラス（!importantを使うことが多いが、最小限に）

ITCSSフォルダ構成例

src/
└── styles/
    ├── main.scss               // エントリーファイル
    ├── _settings.scss          // 1. グローバル変数、マップなど
    ├── _tools.scss             // 2. Mixin, Functionなど
    ├── _generic.scss           // 3. リセット、Normalize.css
    ├── _elements.scss          // 4. HTML要素の基本スタイル
    ├── _objects.scss           // 5. レイアウトオブジェクト
    └── components/             // 6. UIコンポーネント（BEMのBlock）
        ├── _button.scss
        ├── _card.scss
        ├── _header.scss
        └── ...
    └── _trumps.scss            // 7. 強制ユーティリティ（最小限）

main.scssから上記の順序で各ファイルをインポートすることで、詳細度が低いスタイルから詳細度が高いスタイルへとCSSが適用され、予期せぬスタイルの上書きを防ぎ、CSS全体の予測可能性を高めます。

https://x.com/csswizardry

x.com

BEMとITCSSの組み合わせによるメリット

• 明確なスコープ: BEMで各コンポーネントのスタイルがカプセル化され、スタイル衝突のリスクを低減。
• 一貫性のある命名: チーム全体で同じルールでCSSを記述できるため、可読性と保守性が向上。
• 論理的なファイル構造: ITCSSにより、CSSの役割が明確になり、どこにどのスタイルを記述すべきかが分かりやすくなる。
• 拡張性の確保: 新しいコンポーネントや機能を追加する際に、既存のCSSに影響を与えにくい構造。

この組み合わせは、大規模なプロジェクトでも破綻しにくい、非常に堅牢なCSS設計を実現します。

Grid／Flexbox／Custom Propertiesを組み合わせた軽量レイアウト

CSSフレームワークを使わなくても、最新のCSS機能（Grid、Flexbox、Custom Properties）を駆使すれば、柔軟かつ軽量なレイアウトを効率的に構築できます。これらは現代のレスポンシブデザインの基盤であり、その活用は必須です。

CSS Gridによる複雑なレイアウト構築

CSS Gridは、2次元（行と列）のレイアウトを定義するための強力なモジュールです。特に、ページ全体のレイアウトや、複雑なコンポーネント内部の配置に適しています。

例: 3カラムレイアウト

<!-- HTML -->
<div class="grid-container">
  <header class="grid-header"></header>
  <nav class="grid-sidebar"></nav>
  <main class="grid-main"></main>
  <footer class="grid-footer"></footer>
</div>

/* CSS */
.grid-container {
  display: grid;
  /* 3列のレイアウトを定義 */
  grid-template-columns: 200px 1fr 250px; /* サイドバー, メインコンテンツ, 追加情報 */
  /* 行のレイアウトを定義 */
  grid-template-rows: auto 1fr auto; /* ヘッダー, メインコンテンツ, フッター */
  /* 各エリアの名前を定義（grid-template-areasと組み合わせて） */
  grid-template-areas:
    "header header header"
    "sidebar main aside"
    "footer footer footer";
  gap: 20px; /* グリッドアイテム間の隙間 */
  min-height: 100vh; /* 最小高さをビューポートの高さに */
}

/* 各エリアの配置 */
.grid-header { grid-area: header; }
.grid-sidebar { grid-area: sidebar; }
.grid-main { grid-area: main; }
.grid-footer { grid-area: footer; }

/* レスポンシブ対応 (例: モバイルでは1カラム) */
@media (max-width: 768px) {
  .grid-container {
    grid-template-columns: 1fr;
    grid-template-rows: auto auto 1fr auto auto; /* 要素の並び順も考慮 */
    grid-template-areas:
      "header"
      "sidebar"
      "main"
      "aside"
      "footer";
  }
}

Gridを使用することで、HTML構造を変更することなくCSSだけでレイアウトを大幅に変更できる柔軟性が得られます。

Flexboxによる柔軟な要素配置

Flexboxは、1次元（行または列）のレイアウトを定義するのに最適です。ナビゲーション、カードの並び、フォーム要素の配置など、要素の並び順や均等配置、中央寄せなどに威力を発揮します。

例: アイテムを均等に並べたナビゲーション

<!-- HTML -->
<nav class="flex-nav">
  <ul class="flex-nav__list">
    <li class="flex-nav__item"><a href="#">Home</a></li>
    <li class="flex-nav__item"><a href="#">About</a></li>
    <li class="flex-nav__item"><a href="#">Services</a></li>
    <li class="flex-nav__item"><a href="#">Contact</a></li>
  </ul>
</nav>

/* CSS */
.flex-nav__list {
  display: flex;
  justify-content: space-around; /* アイテムを均等に配置 */
  align-items: center; /* 垂直方向の中央寄せ */
  list-style: none; /* リストのスタイルをリセット */
  padding: 0;
  margin: 0;
}

.flex-nav__item {
  padding: 10px 15px;
  /* レスポンシブで要素を折り返す */
  flex-wrap: wrap;
}

Flexboxは、要素の配置に関するCSSの記述量を大幅に減らし、シンプルで理解しやすいコードを実現します。

CSS Custom Properties（CSS変数）によるデザインシステムの構築

CSS Custom Properties（通称CSS変数）は、値をカスタムプロパティとして定義し、CSS内で再利用できる強力な機能です。これにより、デザインシステムを効率的に構築し、一貫性を保ちながら、変更に強いCSSを実現できます。

【保存版】CSS var()の使い方徹底解説！カスタムプロパティで色・サイズ・レイアウトを一括管理するテクニック＆実践例

CSS変数でCSS設計を効率化！カスタムプロパティの基本（定義、var()、スコープ）はもちろん、カラーテーマ、レスポンシブ、ダークモードといった現場で即役立つ活用例、JavaScript連携などの応用テクニックまで、具体的なコードとともに詳しく解説します。CSS変数でよりメンテナンス性の高いコードを目指しましょう。

watashi.xyz

2025.05.02

例: カラーパレットとスペーシングの定義

:root {
  /* カラーパレット */
  --color-primary: #3498db;
  --color-secondary: #2ecc71;
  --color-text: #333;
  --color-background: #f8f8f8;

  /* スペーシング */
  --spacing-xs: 4px;
  --spacing-sm: 8px;
  --spacing-md: 16px;
  --spacing-lg: 24px;
  --spacing-xl: 32px;

  /* フォントサイズ */
  --font-size-base: 16px;
  --font-size-h1: 2.5rem;
  --font-size-h2: 2rem;
}

.button {
  background-color: var(--color-primary);
  color: #fff;
  padding: var(--spacing-md) var(--spacing-lg);
  border-radius: var(--spacing-sm);
  font-size: var(--font-size-base);
}

.card {
  background-color: var(--color-background);
  padding: var(--spacing-xl);
  margin-bottom: var(--spacing-lg);
  box-shadow: 0 var(--spacing-xs) var(--spacing-sm) rgba(0, 0, 0, 0.1);
}

/* calc()とclamp()の活用例 */
.responsive-text {
  font-size: calc(1rem + 0.5vw); /* ビューポート幅に応じて調整 */
}

.flexible-width {
  width: clamp(300px, 80vw, 900px); /* 最小300px, 最大900px, 80vwで調整 */
}

CSS変数を活用することで、Tailwind CSSのようなユーティリティファーストの思想を、フレームワークなしで実現することも可能です。例えば、var(--spacing-md)を直接クラス名として使うのではなく、BEMと組み合わせてコンポーネント内で使用することで、よりセマンティックなマークアップを維持しつつ、デザインの一貫性を保てます。

これらの最新CSS機能を組み合わせることで、フレームワークに匹敵する、あるいはそれ以上の柔軟性と軽量性を持つレイアウトを構築できます。

Sass・PostCSS・CSS ModulesなどモダンCSSツールの活用法

CSSフレームワークを使わないからといって、CSSの記述が非効率になるわけではありません。Sass、PostCSS、CSS ModulesといったモダンなCSSツールを適切に活用することで、開発効率を飛躍的に向上させ、CSSフレームワークが提供する機能の多くを自作CSS環境でも享受できます。

Sass (Syntactically Awesome Style Sheets)

Sassは、CSSをより効率的に記述するためのプリプロセッサです。変数、ネスト、Mixin、Function、Partialなどの機能を提供し、CSSの冗長性を排除し、保守性を高めます。

主な機能と活用例:

• 変数: 色、フォントサイズ、ブレークポイントなどの値を一元管理。
• ネスト: セレクタの階層をHTML構造に合わせてネスト。記述量を削減し、可読性を向上。
• Mixin: 繰り返し使うCSSの塊を関数のように定義し、呼び出す。ベンダープレフィックスの管理などにも便利。
• Partial (パーシャル): CSSファイルを小さな単位に分割し、@importで結合。ITCSSのファイル構造を実現するのに不可欠。

Sassは、フレームワークが提供する多くの便利機能を、自作CSSの文脈で再現するための強力な基盤となります。

PostCSS

PostCSSは、CSSの変換ツールです。豊富なプラグインエコシステムを持ち、CSSの最適化、ベンダープレフィックスの自動付与、将来のCSS構文（CSSNextなど）の利用などを可能にします。

主なPostCSSプラグインと活用例:

• Autoprefixer: ベンダープレフィックス（webkit-, moz-など）を自動で付与。これにより、手動での記述が不要になり、CSSコードがクリーンになります。
• CSS Nano: CSSファイルを圧縮・最適化。コメント削除、空白削減、重複ルールのマージなどを行い、ファイルサイズをさらに削減します。
• PostCSS Custom Properties: 古いブラウザ向けにCSS変数を変換。フォールバックを提供し、互換性を確保します。
• postcss-preset-env: 最新のCSS機能を多くのブラウザで利用できるように変換。

PostCSSは、ビルドプロセスに組み込むことで、CSSの品質向上と最適化を自動化し、開発者が本来のCSS記述に集中できる環境を提供します。

CSS Modules

CSS Modulesは、コンポーネント指向開発（React, Vueなど）において、CSSのスコープをローカルに限定するための仕組みです。これにより、クラス名の衝突を防ぎ、コンポーネントの再利用性を高めます。

特徴と活用例:

• クラス名の自動生成: クラス名が自動的にユニークなハッシュ値を含む名前に変換されます（例: buttonが_button_abc123のように）。
• スタイル衝突の回避: どのコンポーネントのCSSも、他のコンポーネントに影響を与えません。
• 再利用性の向上: コンポーネントを移動したり再利用したりする際に、CSSの依存関係を気にすることなく利用できます。

例: ReactでのCSS Modules使用

// Button.module.css
.button {
  background-color: blue;
  color: white;
  padding: 10px 20px;
}

.primary {
  background-color: darkblue;
}
```jsx
// Button.js (React Component)
import React from 'react';
import styles from './Button.module.css'; // CSSファイルをモジュールとしてインポート

function Button({ children, type }) {
  const buttonClass = type === 'primary' ? styles.primary : styles.button;
  return (
    <button className={buttonClass}>
      {children}
    </button>
  );
}

export default Button;

CSS Modulesは、フレームワークのコンポーネントシステムに代わる、堅牢なスタイリングアプローチを提供します。これにより、コンポーネントごとに独立したスタイルを管理し、大規模アプリケーションでもCSSの破綻を防ぐことができます。

これらのツールを組み合わせることで、CSSフレームワークの「便利さ」と「効率性」を享受しつつ、自作CSSの「自由度」と「最適化」を最大限に引き出すことが可能になります。

既存プロジェクトからの脱フレームワーク実践ガイド

もしあなたの既存プロジェクトがCSSフレームワークに強く依存している場合でも、段階的に「脱フレームワーク」を進めることは可能です。ここでは、影響を最小限に抑えながら、安全に移行するための具体的なステップとツールを紹介します。

既存プロジェクトを脱フレームワーク化する具体的なステップ

大規模なプロジェクトでフレームワークから脱却するには、一気にすべてを入れ替えるのではなく、計画的かつ段階的に進めることが重要です。

1.現状分析と影響範囲の特定

• フレームワーク使用状況の棚卸し: プロジェクト内でどのUIコンポーネントが、どのフレームワークのどのクラスに依存しているかを洗い出します。使われているフレームワークのバージョンも確認しましょう。
• 依存度マップの作成: CSSフレームワークのクラスがHTML、JavaScriptのどこで使われているかをマッピングし、変更がどこまで波及するかを把握します。自動化ツール（例: Webpack Bundle AnalyzerでCSSバンドルサイズを確認する）や、手動でのコードリーディングを組み合わせます。
• リグレッションテスト計画: 変更後に既存機能が壊れないよう、テスト計画を立てます。E2Eテストツール（Cypress, Playwright）の導入も検討しましょう。

2.ミニマムスタート：影響の小さいコンポーネントから独自CSSに切り替え

• まずは、プロジェクト内で最もシンプルで依存関係の少ないコンポーネント（例: ボタン、タグ、アイコンなど）を選び、その部分だけフレームワークのクラスを削除し、対応する独自CSSを記述します。
• この際、新しいCSSはBEMなどの命名規則に従い、ITCSSなどの設計原則に則って作成します。
• 小規模な成功体験を積み重ねることで、チームの自信とモチベーションを高めます。

3.CSS変数によるフレームワーク変数の置き換え

• 既存のCSSフレームワークが提供する色、フォントサイズ、スペーシングなどのカスタムプロパティ（CSS変数）やSass変数があれば、それを自作のCSS変数に置き換えます。
• これにより、フレームワークのスタイルシートに依存せず、独自のデザインシステムを構築する基盤を築きます。

/* Before (Bootstrap変数を直接参照) */
.my-button {
  background-color: var(--bs-primary); /* BootstrapのCSS変数 */
  padding: var(--bs-btn-padding-y) var(--bs-btn-padding-x);
}

/* After (独自のCSS変数に置き換え) */
:root {
  --color-primary: #0d6efd; /* Bootstrapのprimaryカラーに合わせて定義 */
  --spacing-button-y: 0.375rem;
  --spacing-button-x: 0.75rem;
}
.my-button {
  background-color: var(--color-primary);
  padding: var(--spacing-button-y) var(--spacing-button-x);
}

4.ユーティリティクラスの段階的自作と置き換え

• Tailwind CSSのようなユーティリティクラスを多用している場合、プロジェクトで頻繁に利用されているユーティリティクラスのみを、独自にSassのMixinやCSSのカスタムプロパティを使って自作します。
• 新しいユーティリティクラスを作成したら、既存のHTMLからフレームワークのクラスを一つずつ置き換えていきます。
• 例: Tailwind CSSのtext-centerを自作のユーティリティに置き換え

<!-- Before -->
<p class="text-center">テキスト</p>

<!-- After -->
<p class="u-text-center">テキスト</p>

/* utilities/_text.scss (Sassのユーティリティファイル) */
.u-text-center {
  text-align: center !important; /* 必要に応じて!important */
}

• このプロセスは影響を最小化するためのツールを活用して行います。

5.段階的なCSSファイルの整理と削除

• フレームワークのクラスを置き換えるたびに、不要になったフレームワークのCSSファイルを（もし直接インポートしている場合）徐々に削除していきます。
• 最終的には、フレームワークに依存しない、自作のCSSファイルのみで構成されたプロジェクトを目指します。

このプロセスは時間と労力を要しますが、最終的にはよりクリーンで、保守性の高く、パフォーマンスに優れたCSSコードベースへと導きます。

影響を最小化するTailwindクラス置換ツール＆スクリプト例

特にTailwind CSSからの脱却は、大量のユーティリティクラスの置き換えが課題となります。手動での置き換えは非現実的なため、ツールやスクリプトを最大限に活用し、影響を最小限に抑えながら効率的に作業を進めます。

1. エディタの強力な検索・置換機能（VS Codeなど）

VS Codeのようなモダンなエディタは、プロジェクト全体での強力な検索・置換機能を提供します。正規表現を駆使することで、特定のTailwindクラスパターンを自作のCSSクラスやコンポーネントに置き換えることができます。

例: flexとitems-centerをコンポーネントクラスに置き換え

• 検索: class="flex items-center"
• 置換: class="u-flex-center" （BEMやユーティリティプレフィックスを考慮した自作クラス）

複雑なパターンには正規表現が有効です。

2. シンプルなJavaScript/Node.jsスクリプト

プロジェクトの規模や置き換えルールの複雑さに応じて、簡単なスクリプトを作成することで、自動化の幅が広がります。

例: HTMLファイル内の特定のTailwindクラスを別のクラスに置換するNode.jsスクリプト

// replace-tailwind-classes.js
const fs = require('fs');
const path = require('path');

const replaceRules = {
  'flex items-center': 'u-flex-center',
  'p-4 bg-white shadow-md rounded-lg': 'card-base',
  // 必要に応じて他の置換ルールを追加
};

const processFile = (filePath) => {
  let content = fs.readFileSync(filePath, 'utf8');
  let changed = false;

  for (const [tailwindClasses, customClass] of Object.entries(replaceRules)) {
    // スペース区切りでクラスが並んでいることを考慮し、正規表現で厳密にマッチさせる
    // 例えば 'flex items-center' が 'flex items-center justify-between' の一部である場合も考慮
    const regex = new RegExp(`class="([^"]*?)\\\\b${tailwindClasses.replace(/\\s/g, '\\\\s+')}\\\\b([^"]*?)"`, 'g');

    if (content.match(regex)) {
      console.log(`Replacing in ${filePath}: Found "${tailwindClasses}"`);
      // マッチしたクラス全体をカスタムクラスに置き換え
      content = content.replace(regex, (match, before, after) => {
        // 元のクラスリストからtailwindClasses部分を除去し、customClassを追加
        const existingClasses = (before + ' ' + after).trim().split(/\\s+/).filter(cls => cls !== '');
        const newClasses = existingClasses.filter(cls => !tailwindClasses.split(/\\s+/).includes(cls));
        newClasses.push(customClass);
        const finalClassList = Array.from(new Set(newClasses)).join(' ').trim(); // 重複除去
        return `class="${finalClassList}"`;
      });
      changed = true;
    }
  }

  if (changed) {
    fs.writeFileSync(filePath, content, 'utf8');
    console.log(`Updated: ${filePath}`);
  }
};

const traverseDir = (dir) => {
  fs.readdirSync(dir).forEach(file => {
    const fullPath = path.join(dir, file);
    if (fs.lstatSync(fullPath).isDirectory()) {
      traverseDir(fullPath); // ディレクトリを再帰的に探索
    } else if (file.endsWith('.html') || file.endsWith('.jsx') || file.endsWith('.tsx')) {
      // HTML, JSX, TSXファイルなどを対象
      processFile(fullPath);
    }
  });
};

const targetDirectory = './src'; // 置換対象のディレクトリ
traverseDir(targetDirectory);
console.log('Class replacement process completed.');

使用方法:

1. このスクリプトをreplace-tailwind-classes.jsとして保存。
2. replaceRulesオブジェクトに、置き換えたいTailwindクラスとその対応する自作クラスを定義。
3. targetDirectoryをプロジェクトのHTML/JSX/TSXファイルがあるディレクトリに設定。
4. node replace-tailwind-classes.jsを実行。

注意点:

• このスクリプトはあくまで概念的な例であり、実際のプロジェクトの複雑さに応じて調整が必要です。
• 必ずバージョン管理システム（Gitなど）で変更を追跡し、事前にバックアップを取ってから実行してください。
• Tailwindのクラスは非常に多岐にわたるため、手動での調整が最終的には必要になります。

このようなスクリプトを活用することで、大量のクラス置換作業の大部分を自動化し、ヒューマンエラーのリスクを減らしながら移行を進めることができます。

チーム開発でルールを統一するCSS Stylelint＆ドキュメント雛形

CSSフレームワークを使わないチーム開発では、メンバー間のコーディング規約の統一が特に重要になります。Stylelintのようなリンターと、明確な設計ドキュメントを用意することで、コード品質と一貫性を維持できます。

Stylelintの導入と設定

Stylelintは、CSSのリンターです。コードのスタイルや潜在的なエラーを自動的にチェックし、一貫性のあるコーディング規約を強制します。

1.インストール:

npm install stylelint stylelint-config-standard --save-dev

2.設定ファイル（.stylelintrc.json）の作成:

// .stylelintrc.json
{
  "extends": "stylelint-config-standard",
  "rules": {
    // カスタムルールを追加/上書き
    "indentation": [2, {
      "baseIndentLevel": 0
    }],
    "selector-class-pattern": "^([a-z][a-z0-9]*)(-[a-z0-9]+)*(__([a-z0-9]+)(-[a-z0-9]+)*)?(--([a-z0-9]+)(-[a-z0-9]+)*)?$",
    // 上記はBEM命名規則に合わせた正規表現の例
    "max-empty-lines": 1,
    "string-quotes": "single",
    "color-hex-case": "lower",
    "declaration-block-single-line-max-declarations": 1,
    "declaration-empty-line-before": [ "always", {
      "ignore": ["after-declaration"]
    }],
    "at-rule-no-unknown": [ true, {
      "ignoreAtRules": ["include", "mixin", "extend", "each", "if", "else", "for", "function", "return"]
    }] // Sassの@ルールを無視
  }
}

• extends: stylelint-config-standardは一般的な推奨ルールセットです。
• rules: ここでカスタムルールを追加したり、既存ルールを上書きしたりします。特にselector-class-patternでBEMなどの命名規則を強制できます。

3.package.jsonにスクリプトを追加:

"scripts": {
  "lint:css": "stylelint \"**/*.{css,scss}\"",
  "lint:css:fix": "stylelint \"**/*.{css,scss}\" --fix"
}

4.Prettierとの連携:

• Prettierはコードフォーマッターであり、Stylelintはリンターです。両者を連携させることで、コードの整形と品質チェックを同時に行えます。
• npm install stylelint-prettier stylelint-config-prettier --save-devをインストールし、.stylelintrc.jsonに"extends": ["prettier"]を追加します。

Stylelintを導入することで、PRレビューの負担を軽減し、自動的にコード品質と統一性を保つことができます。

CSS設計ガイドラインの作成と共有

Stylelintが構文レベルのチェックを行うのに対し、CSS設計ガイドラインは、より高レベルな設計思想やルールを明文化し、チーム全体で共有するためのドキュメントです。

このガイドラインは、GitHub WikiやConfluence、あるいはプロジェクト内のMarkdownファイルとして管理し、チームメンバーがいつでも参照できるようにします。定期的なレビューと更新も重要です。

Stylelintと設計ガイドラインを組み合わせることで、CSSフレームワークを使わないからこそ重要となる「共通認識」と「自動化された品質担保」を実現し、チーム開発におけるCSSのメンテナンス性と拡張性を高めることができます。

Stylelintを利用してコードを自動整形する方法

cssを分析して間違いを指摘してくれるツールStylelint。これを使えば複数人でコードを共有していても自動的に同じ作法で書かれたコードを作ることができます。一度その仕組みを組んでしまえばあとは楽で便利ですが、導入部分が少し複雑なのでnpm-scriptsでStylelintを稼働して作法がバラバラなCSSファイルを...

watashi.xyz

2022.06.28

よくある質問（FAQ)

まとめ

CSSフレームワークはWeb開発を効率化する強力なツールですが、すべてのプロジェクトにとって常に最適解とは限りません。本記事では、「CSSフレームワークを使わない」という選択肢が持つ真のメリットとデメリットを深く掘り下げ、特に以下のようなケースでその選択が有効であることを解説しました。

• パフォーマンスを最大限に引き出したいプロジェクト
• 独自のブランドイメージを忠実に再現したいプロジェクト
• HTMLのセマンティック性を重視し、クリーンなコードを維持したいプロジェクト
• 自身のCSS基礎スキルを向上させ、普遍的な知識を身につけたい開発者

そして、フレームワークなしで効率的かつ高品質なCSSを記述するために、以下の具体的な手法とツールを紹介しました。

• BEMとITCSSを組み合わせた、堅牢で拡張性の高いCSS設計手法
• CSS Grid、Flexbox、Custom PropertiesといったモダンCSS機能をフル活用した軽量レイアウト構築術
• Sass、PostCSS、CSS Modulesなど、開発効率と品質を高めるためのモダンCSSツールの活用法
• 既存プロジェクトから段階的に脱フレームワークを進めるための具体的なステップや、Stylelintによるコード品質の担保

「CSSフレームワークを使わない」という選択は、決して「原始的な方法に戻る」ことを意味するものではありません。むしろ、現代のWeb開発において、より洗練され、最適化されたCSSアプローチを追求する、戦略的な判断となり得ます。

あなたのプロジェクトの特性やチームのスキルセット、目指す品質を総合的に考慮し、CSSフレームワークに依存しない開発を試してみてはいかがでしょうか。最初は学習コストや手間を感じるかもしれませんが、得られる自由度、パフォーマンス、そして何よりも自身のCSSスキル向上というリターンは、計り知れない価値があるはずです。

ぜひ、本記事で紹介した設計手法やツールを参考に、あなたの手で、より高品質でメンテナンス性の高いWebサイトを構築してください。