Sass

// 変数の定義
$primary-color: #3498db;
$secondary-color: #2ecc71;
$font-stack: 'Helvetica, Arial, sans-serif';
$border-radius: 8px;

// ミックスインの定義
@mixin button-style($bg-color, $text-color: white) {
  background-color: $bg-color;
  color: $text-color;
  padding: 12px 24px;
  border: none;
  border-radius: $border-radius;
  cursor: pointer;
  transition: all 0.3s ease;
  
  &:hover {
    background-color: darken($bg-color, 10%);
    transform: translateY(-2px);
  }
}

// ネストと親セレクタ参照
.navbar {
  background-color: $primary-color;
  padding: 1rem 0;
  
  .container {
    max-width: 1200px;
    margin: 0 auto;
    
    .nav-links {
      display: flex;
      list-style: none;
      
      li {
        margin-right: 2rem;
        
        a {
          color: white;
          text-decoration: none;
          font-family: $font-stack;
          
          &:hover {
            text-decoration: underline;
          }
        }
      }
    }
  }
}

// ミックスインの使用
.btn-primary {
  @include button-style($primary-color);
}

.btn-secondary {
  @include button-style($secondary-color, #333);
}

具体例・ユースケース

Sassが実務でどのように使われるかを、代表的な3つの場面で見てみます。

1. レスポンシブ対応をミックスインで共通化する

ブレークポイントの記述をコンポーネントごとにベタ書きすると、値のズレや修正漏れが起きやすくなります。ミックスインに閉じ込めておけば、ブレークポイントの変更が1箇所で完結します。

$breakpoints: (sm: 576px, md: 768px, lg: 1024px);

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

.card {
  padding: 1rem;
  @include mq(md) {
    padding: 2rem;
    display: flex;
  }
}

2. デザインシステムのトークンをファイル分割して管理する

色・余白・タイポグラフィなどのデザイントークンを_variables.scss等の部分ファイル（パーシャル、ファイル名の先頭に_を付ける）にまとめ、@useで必要なファイルから読み込むのが定石です。これにより、数百ファイル規模のCSSでも「どこで何を定義しているか」が追いやすくなります。

// _tokens.scss
$color-brand: #1B365D;
$space-unit: 8px;

// button.scss
@use 'tokens';

.btn {
  background: tokens.$color-brand;
  padding: tokens.$space-unit * 2;
}

3. ループで大量のユーティリティクラスを生成する

余白やグリッド幅など機械的に増えるクラスは@eachや@forで生成すると、記述量とヒューマンエラーの両方を減らせます。Bootstrapの.mt-1〜.mt-5のようなクラス群も、内部的にはこの手法で生成されています。

@each $size, $value in (1: 4px, 2: 8px, 3: 16px) {
  .mt-#{$size} { margin-top: $value; }
  .mb-#{$size} { margin-bottom: $value; }
}

このように、Sassは「単発のスタイル調整」よりも「規則性のあるスタイルを大量に、一貫したルールで作る」場面で真価を発揮します。逆に、数ページ程度の小規模サイトでは、ビルド環境を用意するコストに見合わないこともあります。

メリット・デメリット

メリット

• 開発効率向上：変数やミックスインにより重複コードを削減
• 保守性向上：変数を使うことで一括変更が容易になる
• コードの整理：ネスト機能により構造化されたコードが書ける
• 再利用性：ミックスインや関数で共通スタイルを効率的に管理
• 数学的操作：計算機能により動的なサイズ調整が可能
• 豊富な関数：色操作、文字列操作などの組み込み関数が充実
• 大規模プロジェクト対応：ファイル分割とインポート機能でスケーラブル

デメリット・注意点

• ビルド環境が必須：コンパイル工程が増えるため、静的HTMLのみの小規模サイトでは構成がやや重くなる
• 過度なネストの罠：ネストを深くしすぎると出力されるCSSのセレクタ詳細度（Specificity）が上がり、後から上書きしづらいCSSになりがち
• デバッグの間接性：ブラウザの開発者ツールに表示されるのはコンパイル後のCSSであり、元のSassの行番号とはズレることがある（ソースマップの併用で軽減可能）
• ネイティブCSSとの機能重複：CSS変数（Custom Properties）やCSSネイティブネストの普及により、Sassでしか実現できない機能の範囲は年々狭まっている
• チーム内の設計ルールが必要：ミックスインや変数を無秩序に増やすと、逆に「どこで何が定義されているか分からない」状態に陥りやすい

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

CSSプリプロセッサ／後処理ツールの分野は名称が似ているものが多く、混同されがちです。代表的な技術との違いを整理します。

特に「Sass変数」と「CSSカスタムプロパティ」の違いは実務で誤解されやすいポイントです。Sassの$colorはコンパイル時に文字列置換される静的な値であるのに対し、CSSの--colorはDOM上でカスケード（継承・上書き）され、メディアクエリの内側やJavaScriptから動的に変更できます。テーマ切り替え（ライト／ダークモード）のような実行時の値変更が必要な場面ではCSSカスタムプロパティを使い、ビルド時に確定する共通値の管理にはSass変数を使う、という使い分けが現実的です。

実務での採用ポイント・エコシステム

Sassは以下の技術と組み合わせて使用されます：

• CSS：Sassコンパイル後の出力対象となるスタイルシート言語
• SCSS：CSS互換の記法を持つSassの拡張構文
• Dart Sass：現在の公式リファレンス実装。npmではsassパッケージとして配布
• PostCSS / Autoprefixer：Sassでコンパイルした後にベンダープレフィックスを自動付与する後処理ツール
• Vite / webpack（sass-loader）：モジュールバンドラーとしてSassのコンパイルをビルドパイプラインに統合
• Bootstrap：ソースコードがSassで書かれているCSSフレームワーク。カスタマイズ時は変数の上書きでテーマ調整が可能
• Compass、Bourbon、Susy：Sass向けのミックスインライブラリ・グリッドシステム。近年はCSS Gridの普及や機能内蔵化により利用は縮小傾向

大規模なSassコードベースでは、ファイル構成の指針として「7-1パターン」（base/・components/・layout/・pages/・themes/・abstracts/・vendors/の7フォルダ＋1つの集約ファイルという構成）が広く参考にされています。厳密に7フォルダすべてを使う必要はありませんが、「変数・関数などの抽象定義」「個別コンポーネント」「レイアウト」を分離するという考え方自体は、中規模以上のプロジェクトで採用する価値があります。

採用を検討すべき場面としては、(1) デザインシステムやコンポーネントライブラリを複数チームで共有し変数管理を一元化したい、(2) Bootstrapなど既存のSassベースフレームワークをカスタマイズして使う、(3) 色や余白の計算ロジック（明度調整、比率計算など）をCSSの記述の中で完結させたい、といったケースが挙げられます。逆に、静的なランディングページ1枚を作るだけの案件や、React／VueなどでCSS-in-JSやCSS Modulesを既に採用しているプロジェクトに後から導入するメリットは薄いことが多いです。

2025〜2026年の最新動向

実装面の一本化が完了。かつて存在したRuby Sass、C/C++実装のLibSass（node-sass経由で広く使われていた）は既に開発が終了しており、現在はDart SassがSassの唯一の公式実装となっています。新規プロジェクトでnode-sassを選ぶ理由は実質的になく、npmパッケージもsass（Dart Sassをコンパイルしたもの）を使うのが標準です。

@importの非推奨化が進行中。Sass公式は従来のファイル分割手段であった@importルールを非推奨とし、@use／@forwardによるモジュールシステムへの移行を進めています。既存の大規模プロジェクトでは@importがまだ多く残っていますが、新規コードでは@useを使うことが事実上の標準的な作法になっています。

CSSネイティブ機能との機能重複が進む。CSSカスタムプロパティ（変数）はモダンブラウザで広く利用可能になり、さらにCSSネイティブのネスト構文も主要ブラウザでのサポートが進んでいます。これにより「変数とネストだけが目的ならSassでなくても書ける」場面が増え、Sass導入の主な動機は、ミックスイン・関数・条件分岐・モジュール分割といった「CSSネイティブにはまだ存在しない機能」に絞られつつあります。

フロントエンドのスタイリング手法が多様化。React／Vueエコシステムでは、CSS Modules、Tailwind CSS、CSS-in-JSなど代替のスタイリング手法が広く定着しており、新規に立ち上げるSPAプロジェクトでSassを第一候補に選ぶ比率は以前より下がっている、というのが実務上の肌感です。一方で、Bootstrapを使う案件、レガシーな大規模CSS資産を持つ企業サイト、デザインシステムのトークン管理など「CSS中心の大規模プロジェクト」では引き続き現役の選択肢です。

総じて、Sassは「新技術に置き換えられつつある過去の技術」というより、「適用範囲がCSSネイティブ機能でカバーしにくい高度な用途に収束しつつある成熟した技術」と捉えるのが実態に近い評価と言えます。

よくある質問（FAQ）