CSS 条件分岐とは？使い方を徹底解説

現代のウェブサイトやウェブアプリケーションは、スマートフォン、タブレット、デスクトップPC、さらにはスマートウォッチやデジタルサイネージなど、非常に多様なデバイスで利用されています。それぞれのデバイスは画面サイズ、解像度、入力方法、ブラウザの機能サポート状況、そしてユーザーが設定した環境設定（例: ダークモード、アニメーションの好み）など、様々な特性を持っています。

このような多様な環境に対応するために、ウェブサイトはただ単に「表示される」だけでなく、「最適に表示され、快適に操作できる」必要があります。単一のCSSファイルですべての環境に完璧に対応することは極めて困難であり、多くの場合、非効率的でメンテナンス性の低いコードになってしまいます。

ここで重要になるのが、「CSS 条件分岐」の考え方と技術です。CSS 条件分岐とは、特定の条件（例えば、「画面の幅が768px以上の場合」「ブラウザがCSS Gridをサポートしている場合」「ユーザーがダークモードを希望している場合」「このコンポーネントの親要素の幅が400px以下の場合」など）が満たされた場合にのみ、特定のCSSルールを適用するための仕組みです。

この技術を習得することで、あなたはより柔軟で、レスポンシブで、アクセシブルで、そして将来の技術進化にも対応しやすいウェブサイトを構築できるようになります。この記事では、CSSにおける主要な条件分岐の手法であるメディアクエリ、機能クエリ、コンテナクエリを中心に、関連するテクニックも含めて徹底的に解説します。それぞれの使い方、具体的なコード例、メリット・デメリット、そして実践的な活用方法まで、約5000語にわたって深く掘り下げていきましょう。

1. CSS 条件分岐とは何か？その必要性

まず、CSS 条件分岐がなぜ重要なのかを改めて考えてみましょう。

CSS 条件分岐の定義:
CSS 条件分岐とは、特定の外部条件または内部状態に基づいて、適用するCSSルールセットを切り替えるためのメカニズムです。これにより、同じHTML構造に対して、様々な状況に応じた異なるスタイルを適用することが可能になります。

なぜCSS 条件分岐が必要なのか？

多様なデバイスへの対応（レスポンシブデザイン）:
これはCSS条件分岐の最も一般的で広く認識されている用途です。デスクトップでは3カラムのレイアウトが適切でも、タブレットでは2カラム、スマートフォンでは1カラムにしたい、といった要望は非常に多いです。メディアクエリを利用することで、画面の幅や高さ、デバイスの向き（縦向きか横向きか）に応じてレイアウトや要素のサイズ、表示/非表示を切り替えることができます。これにより、あらゆる画面サイズで最適なユーザー体験を提供できます。
ブラウザの機能サポート状況への対応（プログレッシブエンハンスメント/フォールバック）:
CSSには常に新しいプロパティや値、モジュールが追加されています。しかし、すべてのブラウザが最新の機能をすぐにサポートするわけではありません。特定の先進的なCSS機能（例: display: grid、特定の新しい擬似クラスなど）を使いたいが、それがサポートされていない古いブラウザや特定の環境でもサイトが崩れないようにしたい、という場合に機能クエリが役立ちます。機能クエリを使えば、特定の機能がサポートされている場合にのみその機能を使ったスタイルを適用し、そうでない場合は代替（フォールバック）スタイルを適用するといったことが可能です。
ユーザーの環境設定への適応:
多くのOSやブラウザは、ユーザーが個人の好みに合わせて設定を変更できるようになっています。代表的な例がダークモードです。ユーザーがOSレベルでダークモードを有効にしている場合、ウェブサイトもそれに合わせて配色を切り替えたいというニーズがあります。また、アクセシビリティの観点から、アニメーションを減らしたい、コントラストを強くしたいといった設定をユーザーが行っている場合もあります。これらのユーザー設定に応じてスタイルを調整する際にも、CSS条件分岐（特にメディアクエリの一種）が用いられます。
コンポーネントレベルでのスタイル調整（コンテナクエリ）:
これまでの条件分岐は主にビューポート全体やブラウザの機能といった「グローバル」な条件に基づいていました。しかし、現代のウェブ開発では、再利用可能なUIコンポーネントを構築することが一般的です。同じコンポーネント（例: 商品カード）をサイドバーのような狭い領域に配置する場合と、メインコンテンツエリアのような広い領域に配置する場合で、そのコンポーネント内のレイアウトを変えたい、という状況が生まれます。これはビューポートのサイズだけでなく、コンポーネントが配置される親要素（コンテナ）のサイズに応じてスタイルを調整したいというニーズです。コンテナクエリは、このようなコンポーネントレベルでの条件分岐を可能にする比較的新しい、強力な手法です。

これらのニーズに応えるために、CSSにはいくつかの異なるアプローチで条件分岐を実現する仕組みが提供されています。次に、これらの主要な手法を詳しく見ていきましょう。

2. 主要なCSS条件分岐手法

CSSにおける主要な条件分岐手法は、主に @media、@supports、@container の3つです。それぞれ異なる目的と適用範囲を持ちます。

2.1. メディアクエリ (`@media`)

メディアクエリは、CSS条件分岐の中で最も古くから存在し、広く利用されている技術です。主にデバイスやビューポートの特性に基づいてスタイルを適用するかどうかを決定します。レスポンシブデザインを実現する上での中核となる技術です。

基本的な構文:

css @media media-type and (media-feature) { /* 条件を満たした場合に適用されるCSSルール */ selector { property: value; /* ... */ } }

@media: メディアクエリを開始するためのアットルール。
media-type (任意): メディアの種類を指定します。省略した場合は all と見なされます。
- all: すべてのデバイスに適用。
- screen: カラー画面を持つコンピューター、タブレット、スマートフォンなどに適用。ウェブサイトの表示で最も一般的に使用されます。
- print: プリンターや印刷プレビューに適用。印刷用のスタイルシートを記述する際に使用します。
- speech: スクリーンリーダーなどの音声出力デバイスに適用。
and (任意): 複数の条件を組み合わせる際に使用する論理演算子。
(media-feature): 検査するメディアの特性を指定します。例えば (min-width: 768px) のように記述します。

よく使われるメディア特性 (Media Features):

メディアクエリで利用できる特性は非常に多岐にわたりますが、ここではよく使用されるものを中心に紹介します。

幅と高さ (width, height):
- (width: value): ビューポートの幅が正確に value の場合。
- (min-width: value): ビューポートの幅が value 以上の場合。レスポンシブデザインでは、モバイルファーストのアプローチでよく使われます。
- (max-width: value): ビューポートの幅が value 以下の場合。デスクトップファーストのアプローチでよく使われます。
- (height: value), (min-height: value), (max-height: value) も同様に利用できます。
例:
“`css
/ 画面幅が768px以上の場合に適用 /
@media screen and (min-width: 768px) {
body {
margin: 0 20px;
}
.container {
display: grid;
grid-template-columns: 1fr 3fr;
}
}

/ 画面幅が600px以下の場合に適用 /
@media screen and (max-width: 600px) {
h1 {
font-size: 1.5em;
}
}
`` これらの特性に指定するvalueには、px,em,remなどの単位付きの数値を使用します。特に、レスポンシブデザインのブレークポイントにはemやremを使用することが推奨される場合があります。これは、ユーザーがブラウザのフォントサイズ設定を変更した場合でも、それに合わせてレイアウトが調整されるためです。px` を使うと、フォントサイズだけが大きくなってもレイアウトが崩れる可能性があります。
デバイスの幅と高さ (device-width, device-height):
- (device-width: value), (min-device-width: value), (max-device-width: value)
- (device-height: value), (min-device-height: value), (max-device-height: value)
  これらはビューポートではなく、デバイスの画面自体のサイズを基準とします。しかし、ズームレベルによってビューポートサイズは変わるため、多くの場合 width や height を使用する方が柔軟です。device-width は非推奨になる傾向にあります。
向き (orientation):
- (orientation: portrait): ビューポートの高さが幅以上の場合（縦向き）。
- (orientation: landscape): ビューポートの幅が高さより大きい場合（横向き）。
例:
css /* デバイスが横向きの場合に特定のスタイルを適用 */ @media screen and (orientation: landscape) { .gallery-item { max-width: 200px; } }
解像度 (resolution):
- (resolution: value): デバイスのピクセル密度を指定します。単位は dpi (dots per inch) または dpcm (dots per centimeter) が使われます。例えば、Retinaディスプレイのような高解像度ディスプレイ向けに、より高精細な画像を表示するといった用途に使えます。
- (min-resolution: value), (max-resolution: value) も利用できます。
例:
css /* 2倍以上のピクセル密度を持つデバイス向けに高解像度画像を */ @media screen and (min-resolution: 2dppx), screen and (min-resolution: 192dpi) { .logo { content: url('[email protected]'); /* 高解像度画像に切り替え */ } }
※ dppx (dots per px) はCSSピクセルに対する物理ピクセルの比率を示し、より直感的です。1dppx = 96dpi となります。
色の特性 (color, color-index, monochrome):
- (color): デバイスがカラー表示可能か。値はビット数。
- (color-index): デバイスがサポートする色の数。
- (monochrome): デバイスがモノクロ表示可能か。値はビット数。
  これらの特性は、より古いデバイスや特定の特殊なデバイス向けにスタイルを調整する際に使用されることがあります。
ポインター (pointer):
- (pointer: none): ポインターがない（例: タッチパネル非対応の古い携帯電話）。
- (pointer: coarse): ポインターの精度が低い（例: 指でのタッチ操作）。
- (pointer: fine): ポインターの精度が高い（例: マウスやスタイラス）。
  ユーザーが主にどのような入力方法を使用しているかに応じて、クリック可能な要素のサイズやホバーエフェクトなどを調整するのに役立ちます。
ホバー (hover):
- (hover: hover): 要素にホバーできるデバイス（例: マウスが使えるデバイス）。
- (hover: none): 要素にホバーできないデバイス（例: タッチ専用デバイス）。
  ホバーエフェクトを適用するかどうかを決定する際に重要です。タッチデバイスではホバー状態が存在しないか、ユーザー体験として好ましくない場合があるため、この特性で制御します。
any-pointer, any-hover:
これらは、デバイスがサポートする任意のポインター/ホバー機能に関する特性です。例えば、タブレットがタッチ（coarse）とBluetoothマウス（fine）の両方をサポートしている場合、(any-pointer: fine) は true になります。
ユーザー設定に関する特性:
これらはユーザーのアクセシビリティや好みの設定に応じてスタイルを調整するために非常に重要です。
- (prefers-color-scheme: light) または (prefers-color-scheme: dark): ユーザーがシステムレベルでライトモードまたはダークモードを希望しているか。ダークモード対応は現代のウェブサイトではほぼ必須となりつつあります。
  例:
  css /* ユーザーがダークモードを希望している場合 */ @media (prefers-color-scheme: dark) { body { background-color: #1e1e1e; color: #f5f5f5; } a { color: #bb86fc; /* ダークモードで見やすいリンク色 */ } }
- (prefers-reduced-motion: no-preference) または (prefers-reduced-motion: reduce): ユーザーがアニメーションやトランジションの量を減らすことを希望しているか。これは、特定のユーザーにとってアニメーションがめまいや不快感を引き起こす可能性があるため、アクセシビリティの観点から非常に重要です。
  例:
  “`css
  / ユーザーがアニメーション削減を希望していない場合のみアニメーションを適用 /
  @media (prefers-reduced-motion: no-preference) {
  .animated-element {
  transition: transform 0.3s ease-in-out;
  }
  .modal {
  animation: fadeIn 0.5s ease-out;
  }
  }
  
  / ユーザーがアニメーション削減を希望している場合、アニメーションやトランジションを無効化または最小限に /
  @media (prefers-reduced-motion: reduce) {
  * {
  animation-duration: 0.01ms !important; / アニメーション時間をほぼゼロに /
  transition-duration: 0.01ms !important; / トランジション時間をほぼゼロに /
  scroll-behavior: auto !important; / スムーズスクロールを無効に /
  }
  / または、特定の要素のスタイルを直接調整 /
  / .animated-element { transition: none; } /
  }
  ``!important` を使うのは最終手段ですが、ライブラリのアニメーションなども強制的に無効化したい場合に有効です。個別のスタイルで対応できる場合はそちらの方が望ましいでしょう。
- (prefers-contrast: no-preference | more | less | custom): ユーザーがコントラストの増加または減少を希望しているか。
- (prefers-reduced-transparency: no-preference | reduce): ユーザーが透過性の減少を希望しているか（macOSなど）。
- (forced-colors: active | none): 強制カラーモードが有効か。Windowsのハイコントラストモードなど。
表示モード (display-mode):
- (display-mode: fullscreen | standalone | minimal-ui | browser): プログレッシブウェブアプリ (PWA) がどの表示モードで実行されているか。例えば、standalone モード（ネイティブアプリのようにブラウザのUIなしで表示）の場合に、特定のヘッダーを非表示にするといった用途に使えます。

論理演算子 (Logical Operators):

メディアクエリでは、複数の条件を組み合わせてより複雑な条件を指定できます。

and: 複数の特性を同時に満たす場合。
css /* 画面幅が768px以上かつ横向きの場合 */ @media screen and (min-width: 768px) and (orientation: landscape) { /* ... */ }
, (カンマ): 複数のメディアクエリをOR条件で組み合わせる場合。いずれかの条件を満たせば適用されます。
css /* 画面幅が768px以上の場合、または印刷時の場合 */ @media screen and (min-width: 768px), print { /* ... */ }
not: 条件を否定する場合。指定したメディアクエリが真にならない場合に適用されます。メディアタイプに対して使用すると、そのタイプのデバイス以外に適用されます。
“`css
/ 画面（screen）ではなく、かつ縦向きでもない場合 (=印刷または音声出力で、かつ横向き) /
/ または、画面であって縦向きでない場合 (screen and orientation: landscape) 以外 /
@media not screen and (orientation: landscape) {
/ … /
}

/ 画面（screen）ではない場合 /
@media not screen {
/ 印刷や音声出力などに適用 /
}
``not演算子はクエリ全体を否定するため、括弧を使って否定する対象を明確にすることが推奨されます。例えば(not (orientation: landscape))` のように書く方が意図が明確になります。

ブレークポイントの設計:

レスポンシブデザインにおけるブレークポイント（特定のスタイルが切り替わる画面幅）の設定は重要です。

デバイス基準: スマートフォン、タブレット、デスクトップといった代表的なデバイスの画面サイズを基準に設定する方法。例: 600px以下（SP）、601px〜1024px（Tab）、1025px以上（PC）。
コンテンツ基準: コンテンツが特定の幅で崩れ始める、または最適に見えなくなるポイントを基準に設定する方法。こちらの方がより柔軟で、将来的なデバイスサイズの変化にも対応しやすいとされます。デザインやコンテンツに合わせてブレークポイントを決定します。

いずれの方法でも、min-width を使用したモバイルファーストのアプローチでCSSを記述するのが現代的なベストプラクティスとされています。まず最小画面（モバイル）のスタイルをデフォルトとして定義し、min-width を使って画面が広がるにつれてスタイルを上書きしていきます。

“`css
/ ベーススタイル（モバイルファースト） /
.container {
width: 100%;
padding: 10px;
}

/ タブレット以上 /
@media screen and (min-width: 768px) {
.container {
width: 960px;
margin: 0 auto;
}
}

/ デスクトップ以上 /
@media screen and (min-width: 1200px) {
.container {
width: 1140px;
display: flex;
}
.sidebar {
width: 300px;
margin-right: 20px;
}
.main-content {
flex-grow: 1;
}
}
“`

<link> タグでのメディアクエリ:

CSSファイルをHTMLで読み込む際に、<link> タグの media 属性を使ってメディアクエリを指定することも可能です。これにより、特定の条件を満たす場合にのみそのCSSファイルが読み込まれ（または適用され）、不要なCSSのダウンロードや解析を防ぐことができます。

“`html

`` ただし、多くのモダンなレスポンシブデザインでは、単一のCSSファイル内に@media` ルールを記述する方が管理が容易な場合が多いです。ファイルの分割は、スタイルシートが非常に大きい場合や、特定のメディア（例: print）向けに全く異なる大量のスタイルが必要な場合に検討すると良いでしょう。

@import でのメディアクエリ:

@import ルールでもメディアクエリを指定できます。
css @import url("print-styles.css") print; @import url("mobile-styles.css") screen and (max-width: 600px);
しかし、@import ルールはCSSファイルの読み込みを直列化させ、パフォーマンス上の問題を引き起こす可能性があるため、非推奨とされています。代わりに <link> タグを使用するか、CSSビルドツール（Webpack, Parcelなど）やCSSプリプロセッサー（Sass, Lessなど）を利用して複数のCSSファイルを結合することが推奨されます。

メディアクエリの注意点:

記述順序: 同じセレクターに対して複数のメディアクエリで異なるスタイルを定義した場合、後のメディアクエリに記述されたルールが優先されます（カスケードの原則）。したがって、モバイルファーストで min-width を使う場合は、より大きな画面幅のクエリを後に書く必要があります。デスクトップファーストで max-width を使う場合は、より小さな画面幅のクエリを後に書きます。
パフォーマンス: 過剰に多くのメディアクエリを使用したり、複雑なセレクターと組み合わせたりすると、ブラウザのスタイル計算に負荷がかかる可能性があります。必要なブレークポイントに絞り、効率的なCSSを記述することを心がけましょう。

メディアクエリはウェブサイトのレスポンシブ対応において依然として非常に重要な技術です。ビューポートサイズやデバイスの基本的な特性に基づいてスタイルを切り替えたい場合に、まず検討すべき手法と言えます。

2.2. 機能クエリ (`@supports`)

機能クエリ (@supports) は、現在のブラウザが特定のCSSプロパティと値のペアをサポートしているかどうかに基づいてスタイルを適用するかどうかを決定するアットルールです。これにより、新しいCSS機能を積極的に導入しつつ、それらをサポートしていない環境向けのフォールバック（代替）スタイルを提供することができます。

基本的な構文:

“`css
@supports (property: value) {
/ 条件（指定した機能がサポートされている）を満たした場合に適用 /
selector {
property: value;
}
}

@supports not (property: value) {
/ 条件（指定した機能がサポートされていない）を満たした場合に適用 /
selector {
alternative-property: alternative-value;
}
}
“`

@supports: 機能クエリを開始するためのアットルール。
(property: value): 検査したいCSS機能（プロパティと値のペア）を指定します。例えば (display: grid) は、ブラウザが display プロパティに grid という値をサポートしているかをチェックします。プロパティ単体ではなく、有効なプロパティと値のペアである必要があります（例: (grid-template-columns) は無効、(grid-template-columns: 1fr) は有効）。
not: 条件を否定する場合に使用します。

論理演算子 (Logical Operators):

メディアクエリと同様に、複数の条件を組み合わせることができます。

and: 複数の機能を同時にサポートしている場合。
css /* display: grid と gap プロパティの両方をサポートしている場合 */ @supports (display: grid) and (gap: 1em) { .container { display: grid; gap: 1em; } }
or: 複数の機能のいずれかをサポートしている場合。
css /* display: flex または display: grid のいずれかをサポートしている場合 */ @supports (display: flex) or (display: grid) { .container { display: flex; /* または display: grid */ } }
not: 指定した機能をサポートしていない場合。
css /* display: grid をサポートしていない場合 */ @supports not (display: grid) { .container { display: flex; /* Flexboxで代替レイアウト */ } }
複数の条件を組み合わせる際は、括弧 () を使ってグループ化し、意図を明確にすることが重要です。
css /* display: grid をサポートしていない、かつ (display: flex または display: box) をサポートしている場合 */ @supports not (display: grid) and ((display: flex) or (display: box)) { /* ... */ }

機能クエリの応用例:

プログレッシブエンハンスメント (Progressive Enhancement):
これは機能クエリの主な用途です。まず、古いブラウザでも表示できる基本的な（フォールバック）スタイルを定義します。次に、@supports を使って特定のモダンなCSS機能が利用可能かチェックし、サポートされている場合にのみ、その機能を使った拡張されたスタイルを適用します。

例: CSS Grid を使ったレイアウト

“`css
/ フォールバック: Flexboxを使ったレイアウト (古いブラウザでも表示できる) /
.container {
display: flex;
flex-wrap: wrap;
justify-content: space-around;
}

.item {
width: 30%; / Flexアイテムの基本的な幅 /
margin: 10px;
}

/ プログレッシブエンハンスメント: CSS Gridを使ったレイアウト (対応ブラウザのみ) /
@supports (display: grid) {
.container {
display: grid;
grid-template-columns: repeat(auto-fit, minmax(250px, 1fr)); / 自動調整グリッド /
gap: 20px; / グリッド間隔 /
/ Flexbox関連のスタイルは上書きされるか、Gridと共存しないように注意 /
justify-content: unset; / Flexboxのプロパティをリセットまたは上書き /
}

.item {
width: auto; / Gridアイテムはコンテナが幅を制御するため不要 /
margin: 0; / gapプロパティで間隔を管理 /
}
}
“`
この例では、CSS Grid をサポートしていないブラウザでは Flexbox で基本的なレスポンシブレイアウトが実現され、CSS Grid をサポートしているモダンブラウザではより強力なグリッドレイアウトが適用されます。
特定のプロパティや値のサポートチェック:
新しいCSSプロパティや、既存のプロパティに追加された新しい値（例: display: flex の gap プロパティは比較的新しい）のサポートをチェックできます。
css /* display: flex はサポートしているが、gapプロパティをサポートしていない場合の調整 */ @supports (display: flex) and (not (gap: 1px)) { .flex-container > *:not(:last-child) { margin-right: 10px; /* gap の代わりに margin で要素間隔を作る */ } }
アットルール全体のサポートチェック:
@supports ルールは、アットルール（@font-face, @keyframes など）のサポートもチェックできます。
css /* @keyframes ルールがサポートされている場合のみアニメーションを定義 */ @supports (@keyframes slide-in) { @keyframes slide-in { from { transform: translateX(-100%); } to { transform: translateX(0); } } .element-to-animate { animation: slide-in 0.5s ease; } }
ただし、特定のセレクターや構文（例: :has() 擬似クラス）のサポートを直接チェックする機能は @supports には現在のところありません。

機能クエリの注意点:

@supports 自体のブラウザサポート: @supports ルール自体が比較的新しい機能であるため、非常に古いブラウザではサポートされていません。しかし、IE11以外の主要なモダンブラウザでは広くサポートされているため、実用上の問題は少なくなってきています。@supports がサポートされていないブラウザでは、@supports ブロック内のCSSはすべて無視されます。この性質を利用して、@supports ブロックの外にフォールバックを記述する、前述のプログレッシブエンハンスメントのアプローチが有効です。
プロパティと値のペア: チェックできるのは基本的に有効なプロパティと値のペアです。無効な値（例: (display: invalid-value)) や、存在しないプロパティをチェックしても常に偽となります。
構文レベルのチェックの限界: 特定のセレクター（例: :has()）や複雑なCSS関数のサポートを直接チェックすることはできません。

機能クエリは、新しいCSS機能を段階的に導入し、様々なブラウザ環境で安定した表示を保つための重要なツールです。特にプログレッシブエンハンスメントのアプローチを採用する際に力を発揮します。

2.3. コンテナクエリ (`@container`)

コンテナクエリ (@container) は、メディアクエリがビューポートを基準とするのに対し、特定の親要素（コンテナ）のサイズに基づいて子要素のスタイルを適用するかどうかを決定する、比較的新しい強力なアットルールです。これにより、コンポーネント単体のレスポンシブ対応が劇的に容易になります。

なぜコンテナクエリが必要か？（メディアクエリとの違い）

メディアクエリは、ビューポートのサイズ全体に基づいてページ全体のレイアウトや、その中の主要なセクションのレイアウトを調整するのに適しています。しかし、個々のUIコンポーネント（例: カード、ウィジェット、メディアオブジェクト）を考えた場合、そのコンポーネントがどのように表示されるべきかは、ビューポートのサイズよりも、そのコンポーネントがページ上のどこに配置され、どれくらいのスペースを与えられているかに依存することがよくあります。

例えば、同じ「商品カード」コンポーネントを考えてみましょう。
* メインの商品一覧ページでは、カードは幅広のコンテナに配置され、画像、タイトル、価格、ボタンなどが横並びで表示される。
* サイドバーの「おすすめ商品」エリアでは、カードは狭いコンテナに配置され、画像が上、タイトル、価格、ボタンが縦並びで表示される。

このとき、メディアクエリを使って「ビューポート幅が狭い場合は縦並び、広い場合は横並び」とすると、サイドバーに配置されたカードは常に縦並びになってしまい、メインエリアに配置されたカードはビューポート幅が狭い場合に縦並びになってしまいます。理想は、サイドバーに配置されたカードはビューポートが広くても狭くても縦並び、メインエリアのカードはメインエリア自体の幅に応じて縦並びか横並びかを切り替えることです。

これを実現するのがコンテナクエリです。コンポーネント自身が、親コンテナから与えられたスペースを「知って」、それに応じて自身の内部レイアウトを調整できるようになります。

基本的な構文:

“`css
/ 1. コンテナとなる要素を指定 /
.sidebar, .main-content {
container-type: inline-size; / 子孫要素がインライン方向（横幅）でクエリできるようにする /
/ container-name: my-container; / / 名前を付けることも可能（任意） /
}

/ 2. コンテナ内の要素に対してコンテナクエリを記述 /
@container (min-width: 400px) { / コンテナの幅が400px以上の場合 /
.card {
display: flex; / 横並びにする /
}
}

@container (max-width: 399px) { / コンテナの幅が399px以下の場合 /
.card {
display: block; / 縦並び（デフォルト） /
}
}

/ 名前付きコンテナの場合 /
@container my-container (min-width: 400px) {
.card-in-sidebar {
display: flex;
}
}
“`

container-type: コンテナとなる要素に指定する必要があるプロパティです。子孫要素がどの次元でクエリを実行できるかを定義します。
- size: インライン方向とブロック方向の両方でクエリ可能（width と height など）。
- inline-size: インライン方向（横幅）でクエリ可能（width, inline-size など）。最も一般的です。
- normal: デフォルト値。コンテナクエリの対象になりません。
container-name (任意): コンテナに名前を付けます。同じCSSファイル内に複数のコンテナがある場合に、特定のコンテナの子孫要素だけがそのコンテナを対象にクエリを実行できるようにするために使用します。名前を省略した場合、最も近い祖先の無名コンテナが対象となります。
container (ショートハンド): container-type と container-name を同時に設定できます。例: container: my-container / inline-size;
@container [container-name] (query-feature): コンテナクエリ本体。
- [container-name] (任意): 対象とするコンテナの名前。省略すると最も近い無名コンテナが対象。
- (query-feature): 検査するコンテナの特性を指定します。構文はメディアクエリに似ています。

コンテナ特性 (Container Query Features):

メディア特性と同様の概念ですが、ビューポートではなくコンテナ要素の特性を検査します。

width, min-width, max-width
height, min-height, max-height
inline-size, min-inline-size, max-inline-size: コンテナの書き込みモード（writing-mode）におけるインライン方向のサイズ。横書きの場合は width と同じ。
block-size, min-block-size, max-block-size: コンテナの書き込みモードにおけるブロック方向のサイズ。横書きの場合は height と同じ。
他にも orientation, aspect-ratio など一部のメディア特性が利用可能です。

コンテナクエリ単位 (Container Query Units):

コンテナクエリとともに導入された新しい単位です。クエリを実行しているコンテナのサイズに対する相対的なサイズを示します。メディアクエリのビューポート単位（vw, vh）に似ていますが、基準となるのがビューポートではなくコンテナである点が異なります。

cqw: コンテナのインライン方向サイズ (width) の 1%。
cqh: コンテナのブロック方向サイズ (height) の 1%。
cqi: コンテナのインライン方向サイズ (inline-size) の 1%。横書きの場合は cqw と同じ。
cqb: コンテナのブロック方向サイズ (block-size) の 1%。横書きの場合は cqh と同じ。
cqs: コンテナのスクロール軸方向サイズ (scroll-axis size) の 1%。横書きの場合は cqi と同じ。
cql: コンテナの非スクロール軸方向サイズ (non-scroll-axis size) の 1%。横書きの場合は cqb と同じ。
cqq: コンテナの最小軸サイズ (min(inline-size, block-size)) の 1%。
cqmax: コンテナの最大軸サイズ (max(inline-size, block-size)) の 1%。

これらの単位を使うと、コンポーネントのサイズをコンテナのサイズに応じて動的に調整できます。例えば、カード内の見出しのフォントサイズをコンテナ幅の3%にする、といったことが可能です。

例:
“`css
.card {
/ … /
}

@container (min-width: 400px) {
.card .title {
font-size: 3cqi; / コンテナのinline-size (幅) の 3% /
}
}
“`

コンテナクエリのメリット:

コンポーネントの再利用性向上: コンポーネント自身が自身のコンテナサイズに応じてレスポンシブに対応できるため、様々な場所に配置しても期待通りに表示されます。
カプセル化 (Encapsulation): コンポーネントのスタイルがビューポート全体に依存しないため、コンポーネントのCSSが外部環境に影響されにくくなります。
開発効率の向上: コンポーネント単位でレスポンシブ対応を考えられるため、大規模なレイアウト変更を伴うメディアクエリの記述量を減らせる可能性があります。
シンプルな記述: 多くの場合、特定のプロパティに対して @container (min-width: Xpx) のように記述するだけで済みます。

コンテナクエリのデメリットと注意点:

ブラウザサポート: コンテナクエリは比較的新しい機能であり、古いブラウザではサポートされていません。ただし、主要なモダンブラウザ（Chrome, Firefox, Safari, Edge）の新しいバージョンでは既にサポートされています。対象ブラウザの要件を確認し、必要であればポリフィル（非対応ブラウザで機能をエミュレートするスクリプト）を検討する必要があります（ただし、CSSの新機能のポリフィルは限界がある場合が多いです）。
コンテナの確立が必要: クエリの対象となる要素に container-type または container プロパティを設定して、明示的にコンテナとして確立する必要があります。これを忘れるとコンテナクエリは機能しません。
包含の考慮: コンテナクエリは、子要素が包含ブロックとなっている祖先コンテナに対してのみクエリを実行できます。通常、ブロックレベルの要素は包含ブロックを確立しますが、特定のCSSプロパティ（例: position: absolute の包含ブロックは最も近い位置指定された祖先要素になる）や、display: flex, display: grid のアイテムは異なる振る舞いをすることがあります。この包含関係を理解しておく必要があります。
名前の競合: 複数の名前付きコンテナがある場合、名前が重複しないように注意が必要です。

コンテナクエリは、コンポーネント指向のウェブ開発において非常に強力なパラダイムシフトをもたらす可能性を秘めています。メディアクエリと組み合わせて使用することで、ページ全体のレイアウトと個々のコンポーネントのレイアウトの両方を効率的に管理できるようになります。

2.4. その他の条件分岐的なテクニック

厳密には「条件分岐」というアットルールを使用するわけではありませんが、結果として特定の条件に応じてスタイルが切り替わるようなテクニックがCSSには他にも存在します。

セレクターの特異性 (Specificity):
同じ要素に対して複数のCSSルールが適用される場合、ブラウザはセレクターの「特異性」を計算して、どのルールを優先するかを決定します。IDセレクター、クラスセレクター、要素セレクターなどで特異性のスコアが異なり、スコアが高いルールが優先されます。また、ソースコード中で後に記述されたルールは、特異性が同じまたは低い前のルールを上書きします。

例:
“`css
/ 特異性: 0,0,1 /
p {
color: black;
}

/ 特異性: 0,1,0 /
.text {
color: blue; / こちらが優先 /
}

/ 特異性: 1,0,0 /

intro-text {

color: red; / こちらが最も優先 /
}
“`
これは直接的な条件分岐ではありませんが、「特定のセレクターにマッチするという条件」に基づいてスタイルが適用されるという意味で、結果として条件に応じたスタイル適用と言えます。しかし、特異性に頼りすぎるとCSSが複雑でメンテナンスしにくくなるため、注意が必要です。
カスケードと継承 (Cascade and Inheritance):
カスケードは、異なるソース（ブラウザのデフォルトスタイル、ユーザーのスタイル、開発者のスタイル）や異なる場所（セレクターの特異性、記述順序、!important の有無）で定義されたCSSルールの優先順位を決定する仕組みです。継承は、親要素に適用されたプロパティの値が子要素に引き継がれる仕組みです（例: color, font-family）。これらの仕組みにより、要素に適用される最終的なスタイルが決定されます。これも直接の条件分岐ではありませんが、「どのルールが優先されるか」「親から子へ何が引き継がれるか」という「条件」に基づいてスタイルが決まります。
CSS変数 (--*) と JavaScript の連携:
CSS変数（カスタムプロパティ）は値を格納し、CSS全体で再利用できるようにする機能です。これらのCSS変数の値はJavaScriptから動的に変更することができます。この仕組みを利用すると、JavaScript側で何らかの条件（例: ユーザーのクリック、スクロール位置、要素のロード状態など）を判定し、それに合わせてCSS変数の値を変更することで、CSS側で定義されたスタイルが条件に応じて変化するように見せることができます。

例: ダークモード切り替え

“`css
/ デフォルトのライトモード /
:root {
–bg-color: #fff;
–text-color: #333;
}

body {
background-color: var(–bg-color);
color: var(–text-color);
}

/ JavaScriptで切り替え /
/ const root = document.documentElement; /
/ root.style.setProperty(‘–bg-color’, ‘#333’); /
/ root.style.setProperty(‘–text-color’, ‘#fff’); /
`` この例では、JavaScriptで–bg-colorや–text-color` の値を変更することで、サイト全体の背景色や文字色を切り替えることができます。これはJavaScriptという「条件判定ロジック」とCSS変数を組み合わせた条件分岐と言えます。
HTML属性やクラスと連携したCSS:
最も一般的で単純な条件分岐的なテクニックの一つです。HTML要素に特定のクラス名（例: .is-active, .is-hidden）やデータ属性（例: data-state="open", data-theme="dark") をJavaScriptやサーバーサイドのコードで追加・削除し、CSS側ではそれらのセレクターにマッチした場合のスタイルを定義します。

例: メニューの表示/非表示

html <nav id="main-nav" class="menu">  </nav>
“`css
.menu {
display: none; / デフォルトで非表示 /
}

.menu.is-open {
display: block; / .is-open クラスがある場合に表示 /
}
`` JavaScriptでメニューボタンのクリックイベントを処理し、メニュー要素に.is-openクラスを追加・削除することで、メニューの表示/非表示を切り替えることができます。これは「.is-open` クラスが付与されているか」という条件でスタイルが切り替わる非常に一般的なパターンです。

データ属性を使った例:
html <button data-modal-target="#my-modal" data-modal-state="closed">開く</button> <div id="my-modal" data-modal-state="closed">  </div>
“`css
[data-modal-state=”closed”] {
display: none;
}

[data-modal-state=”open”] {
display: block;
}
`` これもJavaScriptでdata-modal-state` 属性の値を変更することで、モーダルの表示/非表示を制御する例です。

これらのテクニックは、JavaScriptやサーバーサイドのロジックと密接に連携して、より動的な条件分岐を実現します。CSS単体のアットルールによる条件分岐とは性質が異なりますが、特定の状態や条件に応じたスタイル変更という目的は共通しています。

3. 各手法の比較と使い分け

ここまで見てきた主要なCSS条件分岐の手法や関連テクニックは、それぞれ得意な領域が異なります。適切に使い分けることで、より効率的でメンテナンスしやすいCSSコードを記述できます。

メディアクエリ (@media):
- 得意なこと:
  - ビューポートサイズに基づいたページ全体や主要セクションのレイアウト調整（レスポンシブウェブデザイン）。
  - デバイスの基本的な特性（画面サイズ、向き、解像度、印刷）に応じたスタイル。
  - ユーザーのシステム設定（ダークモード、アニメーション設定など）に応じたスタイル。
- 使いどころ:
  - ブレークポイントを設定してカラム数や全体の配置を切り替える。
  - 画面サイズが小さいときに特定の要素を非表示にする/表示する。
  - 印刷用の特別なスタイルを適用する。
  - ダークモードの配色を適用する。
- 苦手なこと:
  - コンポーネントが配置される親要素のサイズに応じたコンポーネント内部のレイアウト調整。
  - 特定のCSS機能のサポート状況によるスタイル切り替え。
  - ユーザーインタラクションやアプリケーションの状態に応じた動的なスタイル変更。
機能クエリ (@supports):
- 得意なこと:
  - 特定のCSSプロパティや値のブラウザサポート状況を検出する。
  - モダンCSS機能の導入時に、非対応ブラウザ向けのフォールバックを提供したり、対応ブラウザ向けに拡張スタイルを適用したりする（プログレッシブエンハンスメント）。
- 使いどころ:
  - CSS Grid をサポートしているブラウザと Flexbox などで代替するブラウザでレイアウトを切り替える。
  - 新しいCSS構文（例: 特定の関数や単位）が使える場合にのみそれを使ったスタイルを適用する。
- 苦手なこと:
  - ビューポートサイズやコンテナサイズによるレイアウト変更。
  - デバイスの特性やユーザー設定によるスタイル調整。
  - JavaScriptと連携した動的なスタイル変更。
コンテナクエリ (@container):
- 得意なこと:
  - 特定の親要素（コンテナ）のサイズに基づいたコンポーネント内部のレイアウト調整。
  - コンポーネントの再利用性を高める。
- 使いどころ:
  - カードコンポーネントを、配置された場所の幅に応じて縦並び・横並びを切り替える。
  - ウィジェット内の要素サイズやフォントサイズを、ウィジェット自身のサイズに応じて調整する。
  - レイアウトコンポーネント（例: サイドバー、メインコンテンツエリア）の幅に応じて、その中の要素の配置や表示を調整する。
- 苦手なこと:
  - ビューポート全体に基づいたページ全体のレイアウト変更。
  - ブラウザの機能サポート状況によるスタイル切り替え。
  - デバイスの特性やユーザー設定によるスタイル調整（ただし、コンテナクエリの仕様拡張で将来的に可能になる可能性も）。
CSS変数 + JavaScript / HTML属性・クラス + JavaScript:
- 得意なこと:
  - ユーザーのインタラクション（クリック、ホバー、入力など）に応じた動的なスタイル変更。
  - アプリケーションの状態（例: ログイン状態、エラー表示、フォームの入力検証結果）に基づいたスタイル変更。
  - スクロール位置や他の複雑なJavaScriptロジックによるスタイル変更。
- 使いどころ:
  - モーダルの表示/非表示。
  - タブの切り替えやアコーディオンメニューの開閉。
  - フォームの入力エラー表示。
  - スクロールに応じてヘッダーのスタイルを変更する。
  - ユーザーが明示的に選択したテーマ（ライト/ダークなど）の適用。
- 苦手なこと:
  - ビューポートサイズやデバイス特性に純粋に基づいた静的なレスポンシブ対応（これはCSS単体で行うべき）。
  - ブラウザの機能サポート状況によるフォールバック（これは@supportsで行うべき）。

組み合わせ方:

これらの手法は相互に排他的なものではなく、組み合わせて使用することでより強力なデザインを実現できます。

メディアクエリでページ全体の主要なブレークポイントを設定し、異なるビューポートサイズでの全体レイアウトを調整する。
その中に配置される個々のコンポーネントは、コンテナクエリを使って自身のコンテナサイズに応じて内部レイアウトを調整する。
特定の高度なCSS機能を使いたい部分は、@supports を使ってフォールバックを用意する。
ユーザーのアクションやアプリケーションの状態に応じて動的に変化するスタイルは、JavaScriptとCSS変数やクラス名の切り替えで実現する。

このように、それぞれの技術の強みを理解し、目的に応じて適切な手法を選択・組み合わせることが、効率的で保守しやすいCSS設計につながります。

4. 実践的なテクニックとベストプラクティス

CSS 条件分岐を効果的に活用するための実践的なテクニックや、推奨されるコーディングスタイルについて解説します。

モバイルファーストのアプローチを基本とする:
ほとんどの場合、モバイルファーストのアプローチを採用するのが最善です。まず、狭い画面（モバイル）でのレイアウトとスタイルを記述します。次に、@media screen and (min-width: Xpx) のように min-width を使ったメディアクエリで、画面幅が広がるにつれてスタイルを上書きしていきます。
このアプローチは、CSSの記述量が少なく済む傾向があり、パフォーマンス的にも有利なことが多いです（小さなデバイスで不要な大きな画面向けのスタイルを読み込む必要がない）。また、将来的にさらに小さな新しいデバイスが登場した場合でも対応しやすくなります。
ブレークポイントの設計:
前述の通り、固定的なデバイスサイズだけでなく、コンテンツが自然にフィットしなくなるポイントをブレークポイントとして設定することが重要です。デザインやコンテンツの種類によって最適なブレークポイントは異なります。開発初期段階でデザインチームと密に連携し、主要なブレークポイントを決定しましょう。
ブレークポイントの単位は em または rem を検討する:
メディアクエリのブレークポイントに px を使うのが一般的ですが、ユーザーがブラウザのデフォルトフォントサイズを変更した場合でもレイアウトが崩れにくいように、em や rem を使用することも検討できます。1em や 1rem はルート要素のフォントサイズ（デフォルトでは通常16px）に基づきます。例えば、@media (min-width: 48em) は、ルートフォントサイズが16pxの場合、@media (min-width: 768px) と同じ意味になります。ユーザーがルートフォントサイズを大きく設定すると、ブレークポイントも「大きく」なり、より早い段階で大きな画面向けのスタイルが適用されるようになります。
メディアクエリの整理方法:
CSSコードが増えてくると、メディアクエリが scattered（分散）してしまうと管理が難しくなります。いくつかの整理方法があります。
- 要素/コンポーネントごとにまとめる: 各セレクターの定義の中に、そのセレクターに関連するメディアクエリも一緒に記述する方法。Sassなどのプリプロセッサーを使うと、ネストして記述できるため管理が容易です。
  “`scss
  .my-component {
  / デフォルトスタイル (SP) /
  width: 100%;
  
  @media (min-width: 768px) {
  / Tablet+ /
  width: 50%;
  }
  
  @media (min-width: 1200px) {
  / PC+ /
  width: 30%;
  }
  }
  * **ブレークポイントごとにまとめる:** CSSファイルの最後に、ブレークポイントごとにまとめてメディアクエリを記述する方法。css
  / 共通スタイル /
  .my-component { width: 100%; }
  .another-element { color: red; }
  
  / === Tablet+ (min-width: 768px) === /
  @media (min-width: 768px) {
  .my-component { width: 50%; }
  .another-element { color: blue; }
  / … Tablet+ 向けのスタイル /
  }
  
  / === PC+ (min-width: 1200px) === /
  @media (min-width: 1200px) {
  .my-component { width: 30%; }
  / … PC+ 向けのスタイル /
  }
  “`
  どちらの方法にもメリット・デメリットがありますが、現代のコンポーネント指向開発では、要素/コンポーネントごとにまとめる方が関連するスタイルが一箇所に集まり、コードの見通しが良くなるため推奨される傾向があります。
コンテナクエリとメディアクエリの組み合わせ:
ページ全体のレスポンシブレイアウト（例: ヘッダー、サイドバー、メインコンテンツの配置）はメディアクエリで制御し、サイドバーやメインコンテンツ内に配置されるカードやウィジェットなどの個々のコンポーネントの内部レイアウトはコンテナクエリで制御する、という使い分けが非常に有効です。これにより、各技術の得意な範囲で役割を分担でき、CSS構造が整理されます。
機能クエリを活用したプログレッシブエンハンスメント:
新しいCSS機能を試す際に、すぐに全てのブラウザでサポートされていなくても臆病になる必要はありません。@supports を使って、その機能を使わない場合の基本的なスタイル（フォールバック）と、機能が使える場合の洗練されたスタイルを記述することで、ユーザーは可能な限り最高の体験を得られます。これはウェブサイトを持続可能にし、将来の技術進化に対応しやすくする重要なプラクティスです。
アクセシビリティ特性への配慮:
prefers-reduced-motion, prefers-color-scheme, prefers-contrast といったユーザー設定に関するメディア特性は、アクセシビリティやユーザー体験に大きく影響します。これらの設定を尊重し、適切なスタイルを提供するように努めましょう。特にアニメーションを多用する場合は、prefers-reduced-motion: reduce が指定されているユーザーにはアニメーションを無効化または簡略化することが強く推奨されます。
パフォーマンスへの影響と最適化:
- 不要なメディアクエリや機能クエリは削除する。
- 可能であれば、<link media="..."> を使用して、特定のメディアや特性のCSSファイルを条件に応じてのみ読み込む（ただし、HTTP/2 以降では単一のCSSファイルにまとめる方が効率的な場合もあるため、サイトの規模や構成に応じて検討）。
- CSSの記述順序を意識し、カスケードを効率的に利用する。
- 複雑すぎるセレクターは避ける。
- 画像のアスペクト比を維持しつつサイズをレスポンシブにする (object-fit, padding-top ハックなど) 技術も、メディアクエリと組み合わせて重要になります。
テストとデバッグ:
ブラウザの開発者ツール（特に要素の検証機能とレスポンシブデザインモード）は、CSS条件分岐のテストとデバッグに不可欠です。様々な画面サイズをシミュレートしたり、要素に適用されているスタイルとそのソース（どのファイル、どの行、どのメディアクエリ/コンテナクエリ）を確認したりできます。可能であれば、実際の多様なデバイスでテストを行うことも重要です。
CSSプリプロセッサーの活用:
Sass, Less, StylusなどのCSSプリプロセッサーは、変数、Mixin、ネストなどの機能を提供し、メディアクエリやコンテナクエリを含むCSSコードをより効率的に記述・管理するのに役立ちます。例えば、ブレークポイントの値を変数として定義したり、共通のメディアクエリやコンテナクエリのルールをMixinとして再利用したりできます。
設計思想の共有:
チームで開発を行う場合、ブレークポイントの値、モバイルファースト/デスクトップファーストのどちらを採用するか、コンテナクエリを使う範囲など、CSS条件分岐に関する設計思想やルールをチーム内で共有し、一貫性を持たせることが重要です。

5. 将来展望

CSSは常に進化を続けており、条件分岐に関する機能も今後さらに強化される可能性があります。例えば、現在提案されているCSSの仕様には、より複雑な条件分岐を記述するための @when, @else のような構造や、要素の状態（例: スクロール位置、要素の表示・非表示）に基づいた条件分岐機能などが検討されているものもあります。

コンテナクエリも比較的新しい技術ですが、将来的には要素のスタイル情報（例: 親要素のフォントサイズ）に基づいたクエリなど、さらに多様な条件でスタイルを切り替えられるように拡張される可能性も考えられます。

これらの新しい機能が標準化され、広くブラウザでサポートされるようになれば、CSSだけで実現できる表現の幅はさらに広がり、より柔軟でパワフルなスタイル制御が可能になるでしょう。最新のCSS仕様やブラウザの動向に注目し続けることは、ウェブ開発者として常にスキルをアップデートしていく上で重要です。

6. まとめ

この記事では、CSS 条件分岐とは何か、そしてその主要な手法であるメディアクエリ (@media)、機能クエリ (@supports)、コンテナクエリ (@container) について、それぞれの使い方、具体的なコード例、メリット・デメリット、そして実践的な活用方法を詳細に解説しました。さらに、セレクターの特異性、カスケード、CSS変数とJavaScript連携、HTML属性やクラスとの連携といった、条件分岐的な結果をもたらす関連テクニックについても触れました。

現代の多様なデバイスとユーザー環境に対応するためには、CSS 条件分岐はもはや単なるテクニックではなく、ウェブデザイン・開発における必須の考え方、そしてスキルセットです。

メディアクエリは、主にビューポートサイズやデバイス特性に基づくレスポンシブデザインの基礎を築きます。
機能クエリは、ブラウザの機能サポート状況に応じたフォールバックやプログレッシブエンハンスメントを可能にし、新しいCSS機能を安心して導入することを助けます。
コンテナクエリは、コンポーネント単位でのレスポンシブ対応を容易にし、再利用性の高いUIパーツ構築を強力に後押しします。
JavaScriptと連携するテクニックは、より動的な、アプリケーションの状態に基づいたスタイル変更を実現します。

これらの技術を適切に理解し、目的に応じて組み合わせて使用することで、あなたは様々な画面サイズや環境で最適に表示され、アクセシビリティに配慮され、そして将来の技術進化にも対応しやすい、堅牢で保守性の高いウェブサイトやウェブアプリケーションを構築することができるようになります。

CSS 条件分岐は、単に見た目を整えるだけでなく、ユーザー体験そのものを向上させるための重要なツールです。この記事が、あなたのCSSコーディングの理解を深め、より高度なウェブサイト開発への一歩となることを願っています。継続的に学習し、実践を通じてこれらの技術を磨いていきましょう。