SCSS

この用語をシェア

概要

SCSS（Sassy CSS）は、Sassの2つの記法のうちの1つで、CSS互換性を持つ構文形式です。通常のCSSコードをそのまま有効なSCSSコードとして扱えるため、既存のCSSプロジェクトにSassの機能を段階的に導入することができます。

SCSSは波括弧（{}）とセミコロン（;）を使用するCSS風の記法を採用しており、多くのWeb開発者にとって親しみやすい構文となっています。.scss拡張子のファイルで保存され、Sassコンパイラによって通常のCSSに変換されます。

Sass自体は2006年にHampton CatlinとNatalie Weizenbaumによって開発されたCSS拡張言語で、当初提供されていたのはインデントで階層を表す記法（現在の.sass記法）のみでした。2010年にリリースされたSass 3で、中括弧とセミコロンを用いるCSS互換の記法が追加され、これが「SCSS（Sassy CSS）」です。CSSとの構文互換性の高さから急速に普及し、現在ではSassを利用するプロジェクトの大半がSCSS記法を採用しています。

現在、Sassの公式実装は基本的に「Dart Sass」に一本化されています。かつて広く使われたC/C++実装のLibSass（およびそのNode.jsバインディングであるnode-sass）は2020年に開発終了（EOL）が告知されており、npmで配布されるsassパッケージ（Dart Sass）への移行が公式に推奨されています。React・Vue・Angularなど主要フレームワークのビルドツール（Vite、webpack、Angular CLIなど）も、標準またはプラグイン経由でDart Sassをサポートしています。

SCSSの仕組み（コンパイルとモジュールシステム）

SCSSはブラウザが直接解釈できる言語ではありません。開発者が記述した.scssファイルは、Sassコンパイラ（Dart Sass）によって通常のCSSファイルへと変換（コンパイル）されてから、HTMLに読み込まれます。ローカル開発ではsass input.scss output.cssのようなCLIコマンドを直接使う方法のほか、Vite・webpack（sass-loader）・Gulp（gulp-sass）といったビルドツールに組み込み、ソースの変更を検知して自動コンパイルする方法が一般的です。

ファイル名の先頭にアンダースコアを付けたファイル（例：_variables.scss、_mixins.scss）は「パーシャル」と呼ばれ、単体ではコンパイル・出力対象にならず、他のSCSSファイルから読み込まれる部品として機能します。従来はこの読み込みに@importを使うのが標準でしたが、@importは読み込んだ変数・ミックスインをすべてグローバルスコープに展開してしまうため、大規模プロジェクトでは名前の衝突が起きやすいという問題がありました。そこでSassチームは、名前空間付きで読み込める@useと、読み込んだ内容を再エクスポートする@forwardからなるモジュールシステムを導入し、現在はこちらの利用が公式に推奨されています。

// _tokens.scss（デザイントークンをまとめたパーシャル）
$spacing-unit: 8px;
$colors: (
  "primary": #1B365D,
  "danger": #d64545
);

// styles.scss（"t" という名前空間でtokensを読み込む）
@use "tokens" as t;

.alert {
  padding: t.$spacing-unit * 2;
  background: map-get(t.$colors, "danger");
}

また、コンパイル時の出力形式は可読性重視のインデント付き（expanded）と、本番向けに空白を詰めた圧縮形式（compressed）から選択でき、開発環境と本番環境で切り替えるのが一般的です。ソースマップ（.mapファイル）を併せて出力すれば、ブラウザの開発者ツール上でもコンパイル前のSCSSの行番号でデバッグできます。

主な機能

• CSS互換性：既存のCSSコードをそのまま使用可能で段階的な移行が容易
• 変数機能：$記号を使った変数定義と参照でコードの再利用性向上
• ネスト記法：HTMLの構造に合わせてCSSを階層化して記述
• ミックスイン：@mixinと@includeでスタイルブロックの再利用
• 継承機能：@extendによる他のセレクタスタイルの継承
• 演算機能：数値計算、色操作、文字列操作をサポート
• 制御構文：@if、@for、@while、@eachによる条件分岐とループ
• モジュールシステム：@useと@forwardによる名前空間付きの安全な分割管理
• 組み込みモジュール関数：sass:math、sass:color、sass:listなど用途別の関数群

具体例・ユースケース

SCSSは「素のCSSでは冗長になりがちな繰り返しやトークン管理をコード側で解決したい」場面で特に効果を発揮します。実務でよく使われる3つのユースケースを見てみます。

1. コンポーネント単位のスタイリング（ネスト＋ミックスイン）

HTMLの構造に沿ってセレクタをネストし、繰り返し使うスタイルはミックスインとして切り出す、という書き方はSCSSの最も基本的な使い方です。

$primary-color: #007bff;
$border-radius: 0.375rem;

.card {
  background: white;
  border-radius: $border-radius;
  box-shadow: 0 2px 4px rgba(0, 0, 0, 0.1);

  .card-header h3 {
    margin: 0;
    color: $primary-color;
  }
}

@mixin flex-center {
  display: flex;
  align-items: center;
  justify-content: center;
}

.button {
  @include flex-center;
  background-color: $primary-color;
  border-radius: $border-radius;

  &:hover {
    background-color: darken($primary-color, 10%);
  }
}

2. @eachループによるユーティリティクラスの自動生成

Sassのマップと@eachループを組み合わせると、Tailwind CSSのような小さなユーティリティクラス群を自前で一括生成できます。手書きでは数十行になる定義を数行に圧縮できるのが利点です。

$spacers: (0: 0, 1: 0.25rem, 2: 0.5rem, 3: 1rem, 4: 1.5rem);

@each $key, $value in $spacers {
  .m-#{$key} { margin: $value; }
  .p-#{$key} { padding: $value; }
}
// => .m-0, .m-1, .m-2 ... .p-0, .p-1, .p-2 ... が一括生成される

3. デザイントークンとダークモード切り替え

色や余白をSassのマップで一元管理しつつ、実際の出力はCSSカスタムプロパティ（CSS変数）にすることで、コンパイル後もJavaScript側からdata-theme属性を切り替えるだけでダーク／ライトテーマを動的に変更できます。SCSSの静的な計算能力と、CSS変数の実行時可変性を組み合わせるのが実務でよく使われるパターンです。

:root {
  @each $name, $value in (bg: #ffffff, text: #1a1a1a) {
    --color-#{$name}: #{$value};
  }
}
[data-theme="dark"] {
  --color-bg: #1a1a1a;
  --color-text: #f5f5f5;
}
body { background: var(--color-bg); color: var(--color-text); }

このほか、Bootstrap 5やFoundationのようなCSSフレームワークは、内部の色やブレークポイントをSCSS変数として公開しており、アプリ側でその変数を上書きしてから再ビルドする、というカスタマイズ手法も広く使われています。

メリットとデメリット

メリット

• 学習コストが低い：CSS知識があれば容易に習得可能
• 既存プロジェクトとの親和性：CSSファイルをそのまま.scssに変更可能
• チーム開発に適している：CSS経験者なら誰でも理解しやすい構文
• 豊富なツールサポート：多くのエディタやビルドツールで対応済み
• 保守性向上：変数やミックスインにより一貫性のあるスタイル管理
• 開発効率向上：繰り返しコードの削減と構造化されたコード
• 大規模開発対応：ファイル分割と@use/@forwardによるモジュール化

デメリット・注意点

• ビルドステップが必須：SCSSはブラウザが直接解釈できないため、必ずコンパイル環境（Node.jsとsassパッケージ、あるいはビルドツール連携）が必要になる。純粋な静的HTML＋CSSだけで完結させたいプロジェクトでは、この前処理自体がオーバーヘッドになる場合がある。
• 過剰なネストによる可読性低下：セレクタを何段階もネストしすぎると、出力されるCSSの詳細度（specificity）が意図せず高くなり、後からの上書きが困難になりやすい。一般に3〜4階層程度に留めることが推奨される。
• デバッグ時の対応関係の把握：ソースマップを出力しない設定だと、ブラウザ上で見えるのはコンパイル後のCSSの行番号になり、元のSCSSのどの行に対応するか分かりにくい。
• ネイティブCSSとの機能重複：CSSカスタムプロパティ（変数）やCSSネスト構文が主要ブラウザで利用可能になったことで、SCSSを導入する動機の一部（変数管理・ネスト）は素のCSSだけでもある程度代替できるようになってきている。
• 実行時の値の受け渡しができない：SCSSの変数はコンパイル時に固定値へ展開されるため、ユーザー操作やJavaScriptに応じてリアルタイムに値を変えるような用途には、CSSカスタムプロパティを併用する必要がある。

混同されやすい用語・類似技術との違い

SCSSは名称や機能が似た技術と混同されやすい用語です。それぞれの位置づけを整理します。

実務ポイント：エコシステムと採用の判断基準

SCSSは単体で使われることは少なく、以下のようなツール・フレームワークと組み合わせて使われることが多いです。

• Dart Sass（sassパッケージ）：現在唯一の公式実装。npmのsassパッケージとして配布され、CLIからもビルドツール経由でも利用できる。
• Vite / webpack（sass-loader）：.scssファイルをimportするだけで自動コンパイルされるよう標準または準標準でサポートしている。
• PostCSS / Autoprefixer：SCSSコンパイル後のCSSにベンダープレフィックスを自動付与するなど、後処理として組み合わせる。
• Bootstrap / Foundation：SCSSで書かれたCSSフレームワーク。変数を上書きしてビルドし直すことで配色やブレークポイントを一括カスタマイズできる。
• stylelint（stylelint-scss）：SCSS特有の構文（ネスト、@ifなど）を含めてコーディング規約を静的にチェックするデファクトのlinter。

大規模プロジェクトでは、7-1パターン（base、components、layout、pages、themes、abstracts、vendorsの7ディレクトリ＋1つの集約ファイルに分割する構成）のような設計原則に沿ってパーシャルを整理し、@forwardで1つのエントリポイントにまとめる構成がよく採用されます。

採用可否は次のような観点で検討するのが実務的です。

• 既存のCSS資産が大きく、段階的に整理・再利用性を高めたい場合はSCSSが適している（既存CSSがそのまま有効なSCSSとして動くため移行コストが低い）。
• React・VueなどのコンポーネントベースのUIで、コンポーネントごとにスタイルを閉じ込めたいだけであれば、CSS ModulesやCSS-in-JS、あるいはフレームワークが標準提供するscoped styleで十分なケースも多い。
• デザインシステムをユーティリティクラスとして高速に組み立てたいチームは、Tailwind CSSとの比較検討が必要になる。SCSSとTailwindは排他的ではなく、Tailwindの設定を拡張する際にSCSS的な考え方（変数・関数）を応用する併用例もある。
• すでにCSSカスタムプロパティやネイティブCSSネストで足りる小規模サイトであれば、ビルドステップを増やすコストに見合わないこともある。

2025〜2026年の最新動向

SCSS・Sassをめぐる直近の動向として、次のような点が挙げられます。

• Dart Sassへの一本化がほぼ完了：LibSassおよびそのラッパーであるnode-sassは2020年に開発終了が告知されて以降、実質的にDart Sassが唯一のアクティブな実装となっている。Node.jsからの呼び出しを高速化する「embedded Sass（Embedded Dart Sass）」ホストの提供も進んでいる。
• @importの段階的な非推奨化：Sassチームは@importを将来的に廃止し、@use／@forwardへ完全移行させる方針を明言しており、Dart Sassでは@import使用時に非推奨警告が表示されるようになってきている。正式な削除時期は明言されていないが、新規プロジェクトでは@use／@forwardを前提に設計するのが事実上の標準になりつつある。
• グローバル色関数の非推奨化：darken()やlighten()のようなグローバル関数から、名前空間付きのsass:colorモジュール（color.adjust()、color.scale()など）への置き換えが公式ドキュメントで案内されている。
• ネイティブCSSの機能拡充との関係：CSSのネスト構文やCSSカスタムプロパティ、@propertyなどが主要ブラウザで実用段階になったことで、「SCSSでなければ実現できない」領域は狭まりつつある。ただし、マップ演算・制御構文（@each／@for／@if）・パーシャル分割によるモジュール管理など、コンパイル時に完結する機能は依然として素のCSSだけでは代替しにくく、大規模なデザインシステムでの採用は引き続き多い。
• 主要フレームワークの継続採用：Bootstrap、Foundationなど主要なCSSフレームワークが最新バージョンでも一貫してSCSSをソースとして提供し続けている点も、実務での需要が継続している裏付けといえる。

関連用語

• Sass - SCSSの親となるプリプロセッサ言語（.sass記法）
• CSS - SCSSがコンパイルされる出力先の言語
• Tailwind CSS - ユーティリティファーストのCSSフレームワーク
• Bootstrap - SCSSで実装された代表的なCSSフレームワーク
• webpack - sass-loader経由でSCSSをビルドする代表的なバンドラ
• Vite - 標準でSCSSファイルのビルドに対応する高速なビルドツール

外部リンク

• Sass/SCSS公式サイト
• Sass公式ドキュメント
• Sass公式ドキュメント：@use ルール
• Dart Sass（GitHubリポジトリ）

この用語についてもっと詳しく

SCSSに関するご質問や、システム導入のご相談など、お気軽にお問い合わせください。