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の進化により、小規模・短期案件ではCSSオンリーが合理的な選択肢になりました。一方、中〜大規模・継続運用案件では以下のように判断するのが現実的です。
- すでにビルド環境がある場合
→ Sassの採用コストは低く、設計・保守面でのメリットが上回る - ビルド環境がない場合
→ 案件規模と運用期間を天秤にかけて判断する
プロジェクトの性質に応じて判断し、CSS の進化を取り入れつつ Sass の強みを活かすのが、現時点での現実的な選択と言えます。
補足：CSSの将来
CSSでは @function や @mixin のネイティブサポートの仕様策定が進んでおり、一部ブラウザでは実装も始まっています。ただし、すべての主要ブラウザで安心して使える状況になるまでには、まだ時間がかかる見込みです。現時点での実務判断には影響しません。
