CSSファイルが1000行を超えたあたりから、「この色コード、何箇所に書いたんだっけ」という状態になります。修正のたびに全体を検索して置換する。この不毛な作業から解放してくれるのがSassです。
ただし、いま学び始める方には気をつけてほしい点があります。Sassの@importは非推奨となっており、将来のバージョンで削除される予定です。ネット上の解説記事の多くはまだ@importで書かれているため、そのまま覚えると学び直しが発生します。
この記事では、Sassの基本的な書き方を初心者向けに整理したうえで、現在の推奨である@useと@forwardの使い方まで解説します。最初から新しい書き方で覚えれば、無駄な回り道を避けられます。
Sassとは何をするものか
CSSを書きやすくする拡張言語
Sassは、CSSに変数・入れ子・関数といった機能を追加した言語です。書いたSassのファイルはコンパイルされて通常のCSSに変換され、ブラウザはそのCSSを読み込みます。ブラウザがSassを直接理解しているわけではないという点を、まず押さえておいてください。
Sassで解決できること
| CSSでの困りごと | Sassでの解決 |
|---|---|
| 同じ色コードを何箇所にも書いている | 変数にまとめて1箇所で管理する |
| セレクタが長くなって読みにくい | 入れ子で階層構造を表現する |
| 同じスタイルの塊を何度も書いている | ミックスインで使い回す |
| 1ファイルが巨大になっている | 役割ごとにファイルを分割する |
| 数値の計算を手作業でやっている | 四則演算をそのまま書ける |
SCSS記法とSASS記法
Sassには2つの書き方があります。現在ほぼすべての現場で使われているのはSCSS記法（.scss）です。波かっことセミコロンを使う、CSSとほぼ同じ見た目の書き方なので、既存のCSSをそのまま貼り付けても動きます。
もう一方のSASS記法（.sass）はインデントで階層を表現しますが、採用例は多くありません。これから学ぶ方はSCSS記法を選んでください。
書き方を順を追って確認したい方は、Sassの入門書を1冊用意して、公式ドキュメントと照らし合わせながら進めると理解しやすくなります。
導入方法
実装はDart Sassを使う
Sassにはいくつかの実装がありましたが、公式が推奨しているのはDart Sassです。かつて広く使われていたnode-sass（LibSass）はすでに開発が終了しており、新規で選ぶ理由はありません。
・npmでsassパッケージを導入する（実務での標準）
・ViteなどのビルドツールにSassを組み込む
・エディタの拡張機能で自動コンパイルする（学習用に手軽）
学習の段階では、エディタの拡張機能で保存時に自動コンパイルさせる方法がいちばん手軽です。実務ではnpm経由で導入し、ビルドツールと組み合わせる構成が一般的になります。詳しい仕様はSass公式ドキュメントで確認できます。
基本の書き方その1：変数
ドル記号で始まる名前に値を入れておき、あとから何度でも呼び出せます。ブランドカラー、フォントサイズ、余白の基準値などをまとめておくのが定番の使い方です。
色を変更したいとき、変数の定義を1行書き換えるだけで全体に反映されます。「メインカラーを少し明るくしたい」というよくある修正依頼が、数秒で終わります。
Sassの変数はコンパイル時に確定するため、ブラウザ上で動的に切り替えることはできません。ダークモードの切り替えのように実行時に値を変えたい場合は、CSSカスタムプロパティ（CSS変数）を使ってください。
基本の書き方その2：入れ子（ネスト）
親要素の中に子要素のスタイルを書き込める機能です。HTMLの構造とCSSの記述が対応するため、どこに何が書かれているかを追いやすくなります。
また、アンパサンド（&）を使うと親のセレクタを参照できます。ホバー時のスタイルや、BEMのような命名規則での要素名の連結に便利です。
入れ子は深くしすぎない
便利な機能ですが、深く入れ子にするとコンパイル後のCSSで詳細度が高くなりすぎます。後から上書きできない頑固なスタイルが生まれる原因になるため、3階層程度までにとどめるのが実務での目安です。
基本の書き方その3：ミックスイン
@mixinでスタイルの塊に名前をつけ、@includeで呼び出す機能です。引数を渡せるため、同じ形で値だけ違うスタイルを効率よく量産できます。
| よくある用途 | 内容 |
|---|---|
| メディアクエリ | ブレークポイントを名前で呼び出せるようにする |
| ボタンの共通スタイル | 色だけ引数で変えて使い回す |
| テキストの省略表示 | 行数を引数にして三点リーダーを出す |
| 中央寄せ | Flexboxの定型的な組み合わせをまとめる |
とくにメディアクエリのミックスインは効果が大きいです。ブレークポイントの数値を1箇所で管理でき、記述量も減ります。
基本の書き方その4：ファイル分割
ファイル名の先頭にアンダースコアをつけたファイルは「パーシャル」と呼ばれ、単体ではCSSに出力されません。変数用、ミックスイン用、ヘッダー用、フッター用といった具合に役割ごとに分けて、メインのファイルから読み込みます。
この分割ができるようになると、1000行のCSSファイルを開いて目的の場所を探す作業から解放されます。ここがSassを導入する最大の理由だと言う人も少なくありません。
ファイルの分け方や命名のルールは、CSS設計を扱った本で考え方を押さえておくと、自分のプロジェクトに当てはめやすくなります。
@importは使わない：@useと@forwardへ
なぜ@importが廃止されるのか
従来の@importには、読み込んだファイルの変数やミックスインがすべてグローバルに展開されるという問題がありました。ファイル数が増えるほど、どこで定義された変数なのかが追えなくなり、名前の衝突も起きやすくなります。
この問題を解決するために導入されたのが@useと@forwardです。@importは非推奨となっており、Dart Sassのバージョン3.0.0で削除される予定とアナウンスされています。
@useの基本
・読み込んだファイルの変数には「名前空間.変数名」でアクセスする
・同じファイルを複数回読み込んでも、出力は1回だけになる
・asキーワードで名前空間を短縮したり、省略したりできる
・グローバルを汚さないので、どこ由来の値かが一目で分かる
最初は「いちいち名前空間を書くのが面倒」と感じるかもしれません。ただ、ファイル数が増えたときにその値がどのファイルで定義されたのかが即座に分かるという利点は、規模が大きくなるほど効いてきます。
@forwardの役割
@forwardは、複数のパーシャルをまとめて外部に公開するための仕組みです。変数・ミックスイン・関数を集約した「窓口ファイル」を1つ作っておき、各ファイルからはその窓口だけを@useする構成がよく使われます。
この構成にしておくと、ファイルの追加や整理をしても、読み込み側の記述を変えずに済みます。
既存プロジェクトの移行
すでに@importで書かれたプロジェクトがある場合、公式が提供している移行ツール（sass-migrator）を使うと機械的に置き換えられます。ただし、自動変換後は手作業での確認が必要です。名前空間の付け方や、変数の参照先が意図どおりかを目視でチェックしてください。
そのほかに知っておきたい変更点
割り算の書き方も変わっています。従来はスラッシュで割り算を表現していましたが、この記法は非推奨となり、math.div関数を使う形に置き換わりました。古い記事のコードをそのまま貼ると警告が出るので、覚えておいてください。
また、色を扱う関数群も整理が進んでいます。Sassは仕様の更新が続いているため、詰まったら公式ドキュメントを見る習慣をつけておくと安全です。ブラウザ側のCSS仕様についても、MDN Web Docsを併用すると理解が深まります。
Sassを使わないという選択肢
近年はCSS自体が進化しており、変数（カスタムプロパティ）や入れ子がCSSの標準機能として使えるようになっています。小規模なサイトであれば、Sassを導入せず素のCSSで完結させる判断も現実的です。
・ページ数が多く、CSSが数千行規模になる → Sassの価値が高い
・複数人で分担して書く → ファイル分割の恩恵が大きい
・LP1枚だけ、数百行で収まる → 素のCSSで十分なことも多い
それでも、既存案件の保守でSassが使われているケースは非常に多いです。読めるようにしておくこと自体に、実務上の価値があります。
学習環境の話
Sassの学習は、Sassファイル・コンパイル後のCSS・ブラウザの3つを見比べる作業になります。「書いたコードがどんなCSSに変換されたか」を確認しながら進めると、理解の速度がまったく違います。
この確認作業には画面の広さが効きます。24〜27インチの外付けモニターを1枚足して、左にSass、右に出力されたCSSとブラウザを並べられると、変換の対応関係が直感的につかめます。設置場所に困る場合はクランプ式のモニターアームで机の奥行きを確保してください。
知識面では、CSS設計を扱った書籍を1冊持っておくと、ファイル分割や命名の考え方が整理できます。SassはCSS設計の道具なので、設計の考え方を知らないまま使うと、ただ複雑になっただけの状態になりがちです。手を動かしながら、A5サイズのノートに自分なりのディレクトリ構成を書き出してみるのもおすすめです。
よくある質問
Q. CSSを覚えていなくてもSassから始められますか
おすすめしません。SassはCSSを書きやすくする道具であって、CSSの代わりではないからです。出力されるのは通常のCSSなので、ボックスモデルやFlexboxを理解していないと、結局どこを直せばいいのか分かりません。
Q. node-sassを使っている記事を見かけますが
node-sassは開発が終了しています。新規で導入する理由はありません。Dart Sass（npmのsassパッケージ）を使ってください。既存プロジェクトで使われている場合は、移行を検討する時期に来ています。
Q. @importで書かれた既存のコードは動かなくなりますか
現時点では動作しますが、警告が表示されます。将来のバージョンで削除される予定のため、新しく書くコードは@useを使い、既存分は計画的に移行しておくのが安全です。
Q. .scssと.sassのどちらを選べばいいですか
.scssを選んでください。実務での採用がほとんどこちらであり、CSSに近い書き方なので学習コストも低くなります。既存のCSSをそのまま貼り付けても動くという利点もあります。
Q. コンパイルしたCSSはGitで管理すべきですか
プロジェクトの方針によります。ビルド環境が整っている場合は出力先を除外し、Sassのソースだけを管理する構成が一般的です。ただし、サーバーに直接アップロードする運用では、出力後のCSSも管理対象にすることがあります。
Q. WordPressのテーマ制作でも使えますか
使えます。テーマ内でSassを管理し、コンパイルしたCSSを読み込ませる構成が一般的です。既存テーマをカスタマイズする場合は、元のCSSとの読み込み順に注意してください。
Q. どのくらいで使えるようになりますか
変数・入れ子・ミックスイン・ファイル分割の4つに絞れば、数日で使い始められます。@useと@forwardの設計を含めて実務レベルにするには、実際のプロジェクトで1〜2本組んでみるのが早道です。
まとめ
Sassは、変数・入れ子・ミックスイン・ファイル分割によって、CSSの管理を大きく楽にしてくれる道具です。CSSが数千行規模になる案件では、導入する価値が明確にあります。
学習で最も注意したいのは、@importではなく@useと@forwardで覚えることです。ネット上の記事は古い書き方のものが多く残っているため、公式ドキュメントを軸にしてください。
まずは小さなプロジェクトで、変数ファイルとミックスインファイルを分けて@useで読み込む構成を試してみましょう。この形が身につけば、規模が大きくなっても迷わなくなります。
