開発環境 2025.12.17

Sass / SCSS を使わずに CSS だけで開発するのはアリなのか？

Sass / SCSS は本当に必要なのか？実務開発における判断基準

時々、Sass や SCSS を使わずに、CSS のみで開発しているケースに遭遇することがあります。一方で近年は「CSS が進化したから Sass は不要」という意見も見かけるようになりました。

本記事では、実務開発の視点から「CSSオンリー開発は本当に問題ないのか」を整理します。

結論：案件の性質で判断が変わる

先に結論を述べます。

小規模・短期案件では、CSSだけで問題なく成立するケースが増えています。しかし、中〜大規模サイトや継続運用を前提とした案件では、Sassを使うメリットは依然として大きいと言えます。

これは思想や好みの話ではなく、設計・保守・運用コストの観点から実務的に判断すべき問題です。

CSSの進化で何が変わったのか

ここ数年で CSS は大きく進化しました。主な変更点を見ていきます。

CSS変数（Custom Properties）

:root {
  --color-primary: #0055cc;
  --space-md: 16px;
}

変数管理がネイティブで可能になり、JavaScript からも参照できるようになりました。ただし、Sass変数との違いも理解しておく必要があります。

CSS変数：ブラウザ側で実行時評価、メディアクエリ内で再定義可能
Sass変数：コンパイル時評価、計算や文字列操作が可能

単純な色・余白管理であれば、CSS変数で十分実用的です。

ネイティブネスト

.card {
  & .title {
    font-weight: bold;
  }
}

Sass に近い記法が使えるようになりました。ただし、Sass と完全に同じ挙動ではない点には注意が必要です。

& なしの直接ネストも仕様上は可能
ただし、実務では & を明示的に使う方が推奨される（可読性・保守性の観点）
複雑なセレクタ結合では、Sass と挙動が異なる場合がある

レスポンシブ対応の数式表現

font-size: clamp(14px, 2vw, 18px);

clamp() / min() / max() / calc() により、レスポンシブ対応の数式表現がCSSのみで書きやすくなりました。

レイヤー管理

@layer base, components, utilities;

CSS設計のレイヤー概念を @layer でネイティブに表現できます。

CSSだけで開発しても問題ないケース

以下の条件が揃う場合、CSSオンリーは合理的な選択です。

小規模サイト・LP
デザインバリエーションが少ない
再利用コンポーネントがほぼない
短期・単発案件
ビルド環境を極力持ち込みたくない

「速く作って、役目を終える」タイプの案件では有効な選択肢と言えます。

Sassが実務で有効な理由

ミックスインによる共通化

@mixin mq($breakpoint) {
  @media (min-width: map-get($breakpoints, $breakpoint)) {
    @content;
  }
}

ミックスインを使うことで、以下が実現できます。

ブレイクポイント管理の一元化
記述ルールの統一
修正コストの低減

CSSでも Custom Properties や命名規則による共通化は可能ですが、処理やルールを仕組みとして強制する点では、Sass の方が優れています。

設計を構造として維持できる

Sass では以下の設計をコード構造として維持できます。

partial 分割
変数・関数・mixin の管理
ファイル依存関係の明確化

これにより、プロジェクト全体の見通しが良くなります。

引き継ぎ・保守対応に強い

中長期で運用されるサイトや複数人が関わる案件では、以下のような状況が発生します。

他の制作者が触る
数ヶ月後に自分が保守対応する

こうしたケースでも、構造化された Sass は把握しやすく、修正リスクを下げられます。

また、変数・mixin・構造が整理されていることで、新規実装やデザイン調整の際も「考える量」が減り、日々の開発自体が楽になるという側面もあります。

Sassを使う際のデメリット

Sass を採用する場合、以下のデメリットが存在します。

ビルド環境（Node.js など）が必要になる
ローカルに開発環境を構築できない人にとっては、修正のハードルが上がる
「CSS ファイルを直接編集する」運用ができなくなる

つまり、誰でも即座に修正できる状態ではなくなるという点は、明確なデメリットです。

フロントエンド開発環境の現状

近年のフロントエンド開発では、CSS に限らず JavaScript も含めてビルド前提の構成が一般的です。

JavaScript はライブラリやフレームワークを利用することが増えた
TypeScript の採用によりトランスパイル工程が必要
バンドラ（Webpack / Vite など）による最適化が前提になっている

このような状況では、すでにビルド環境が存在する場合、CSSでもSassを使う追加コストは小さいと言えます。

また、Sassを使わない場合でも、ベンダープレフィックス対応のために PostCSS + Autoprefixer を導入するケースが多く、結果としてビルドステップが必要になることも少なくありません。

重要なのは「JavaScriptでビルドが必要だから、CSSもビルドすべき」という論理ではなく、プロジェクト全体の構成と、CSS単体で得られるメリットを天秤にかけた判断です。

実務的な使い分け

CSS と Sass は対立関係ではありません。それぞれの強みを活かした使い分けが現実的です。

CSSとSassの使い分け例

計算系は clamp() を積極的に使用
色は CSS変数 + Sass変数を併用
レイヤー管理は @layer を Sass 内で活用
ネストは Sass を基本とする

コンポーネント指向開発での選択肢

React/Vue等のコンポーネント指向開発では、CSS Modules や Scoped CSS といった選択肢も検討に値します。これらは「CSSオンリー vs Sass」という二項対立を超えた、現代的なスタイル管理の手法です。

まとめ

CSSの進化により、小規模・短期案件ではCSSオンリーが合理的選択になりました。

しかし、中〜大規模・継続運用案件では以下のように判断すべきです。

すでにビルド環境がある場合
→ Sassの採用コストは低く、設計・保守面でのメリットが上回る
ビルド環境がない場合
→ 案件規模と運用期間を天秤にかけて判断

重要なのは「Sass vs CSS」という対立ではなく、プロジェクトの性質に応じた適切な判断です。CSS の進化を取り入れつつ、Sassの強みを活かす。それが現時点での最も現実的な選択と言えるでしょう。

補足：CSSの将来

W3Cでは @function や @mixin のネイティブサポートが提案されていますが、仕様確定・ブラウザ実装までには数年単位の時間を要する見込みです。現時点での実務判断には影響しません。

Sass / SCSS は本当に必要なのか？ 実務開発における判断基準