スマホで表示が崩れているという連絡を受け、原因のメディアクエリを直そうとして CSS を開く。すると @media (max-width: 768px) が、ファイルのあちこちに数十か所も散らばっている。一か所直しても他が古い値のままで崩れが残り、結局「768px」を全ファイルから検索置換して、念のため 767px や 769px の表記ゆれも探す——。受託で他社が作ったサイトの改修を引き継ぐと、この光景に高い頻度で出くわします。ブレークポイントの値が CSS 全体に直書きで散らばっていると、レスポンシブの修正が毎回「全置換ギャンブル」になり、一つ直すたびに別の場所が壊れるリスクを抱えます。
この散在を根本から解くのが、メディアクエリの条件に名前を付けて一元管理する @custom-media です。CSS-Tricks が 2026 年 6 月にまとめた @custom-media（CSS-Tricks Almanac） のとおり、長く PostCSS などのビルドツール頼みだったこの機能が、ブラウザのネイティブ実装へと進みつつあります。本記事では、受託で「壊れにくいレスポンシブ」を作る道具として @custom-media をどう使い、既存サイトへどう移行するかを整理します。
なぜブレークポイントの直書きが破綻するのか
@media (max-width: 768px) のような条件を CSS のあちこちに直接書く方式は、最初は何の問題もありません。破綻するのは、サイトが育って次の三つが重なったときです。
第一に、値の散在。同じ「タブレット境界」を意味する 768px が、コンポーネントごと・ファイルごとに別々に書かれます。デザインの都合で境界を 820px に変えたくなったとき、変更箇所を一つでも見落とすと、その場所だけ古い挙動のまま残ります。
第二に、意図の喪失。max-width: 768px という数字を見ても、「これはスマホ向けなのか、タブレット縦向きなのか、それとも特定コンポーネントの都合なのか」が読み取れません。次の担当者は、その数字が何を意図しているか分からないまま触ることになります。
第三に、表記ゆれ。768px と 767.98px、max-width と min-width が混在し、境界の前後でスタイルが二重に当たったり、逆に隙間ができたりします。検索置換では拾いきれず、デバッグが長引きます。
@custom-media は、この三つを「名前」で解きます。境界の値を一か所で定義し、各所ではその名前を参照する。値を変えたいときは定義を一行直すだけで全体に効き、コードを読む側は数字ではなく意図のある名前を見られます。
@custom-media の基本 — 条件に名前を付ける
使い方は、メディアクエリの条件にカスタムプロパティのような名前を割り当てるだけです。まず定義をプロジェクトの先頭（または専用ファイル）にまとめます。
/* ブレークポイントの定義を一か所に集約 */
@custom-media --sp (max-width: 600px); /* スマホ */
@custom-media --tablet (max-width: 900px); /* タブレット以下 */
@custom-media --pc (min-width: 901px); /* PC */
@custom-media --reduce-motion (prefers-reduced-motion: reduce);そして各コンポーネントでは、数字ではなく名前を参照します。
.card-grid {
display: grid;
grid-template-columns: repeat(3, 1fr);
}
/* 「タブレット以下なら2列」が一読で分かる */
@media (--tablet) {
.card-grid { grid-template-columns: repeat(2, 1fr); }
}
@media (--sp) {
.card-grid { grid-template-columns: 1fr; }
}ポイントは二つあります。ひとつは、@media (--tablet) を読めば「タブレット以下向けの調整だ」と意図がそのまま伝わること。もうひとつは、後でタブレット境界を 900px から 820px に変えたくなっても、直すのは定義の一行だけで、参照している全箇所に一斉に反映されることです。検索置換も表記ゆれの心配もなくなります。
メディアクエリだけでなく、prefers-reduced-motion のような機能クエリにも名前を付けられるので、アクセシビリティ対応の条件も一元化できます。「動きを減らす設定のユーザー向け」という意図を --reduce-motion という名前で何度も使い回せるわけです。
デザイントークンの一部として設計する
@custom-media の真価は、単独で使うより、デザインシステムのトークンの一部として束ねたときに出ます。色・余白・タイポグラフィをカスタムプロパティで管理しているなら、ブレークポイントもその仲間として一か所に集める。そうすると、レスポンシブの基準点が「デザイン上の決めごと」として明文化され、誰が触っても同じ境界を使うようになります。
ただし注意点があり、@custom-media は @media の条件部分にしか使えず、var() のように任意の値として埋め込めるわけではありません。一方、CSS のカスタムプロパティ（--color-primary など）はメディアクエリの条件には使えません。この二つは役割が分かれているので、混同しないことが大切です。デザイントークンを CSS の関数として再利用する設計については、CSS @function の記事で扱った「値の生成ロジックを名前に閉じ込める」考え方と合わせて設計すると、トークン全体の見通しが良くなります。
| 仕組み | 何に名前を付けるか | 使える場所 |
|---|---|---|
| @custom-media | メディアクエリの条件（境界・機能） | @media (...) の中 |
| カスタムプロパティ（—x） | 値（色・余白・サイズ） | プロパティの値（var()） |
「色や余白はトークン化したのに、ブレークポイントだけ各所に直書き」という状態は、デザインシステムの片手落ちです。色を --color-primary で管理するのと同じ粒度で、境界も --tablet のように管理する。色の一貫性を保つ発想は、contrast-color() で自己修正するカラーシステムの記事で扱った「値を直書きせず仕組みに任せる」方針と地続きです。
受託で既存サイトに導入するときの進め方
弊社が改修を引き継いだあるリフォーム会社のコーポレートサイト（社名は伏せます）では、まさに「768px の全置換」が改修のたびに発生していました。CSS を調べると、768px 767px 769px 48em が混在し、同じタブレット境界のつもりで四種類の値が使われていた。境界の前後でスタイルが二重に当たり、特定の画面幅でレイアウトが一瞬崩れる症状も出ていました。
私たちは作り直しではなく、段階的な集約を選びました。まず現状の CSS から、使われている全ブレークポイント値を洗い出し、意図ごとに --sp --tablet --pc の三つへ寄せる方針を決めました。次に、表記ゆれを正規の値へ統一しながら、@media (max-width: 768px) を @media (--tablet) へ機械的に置き換えていきました。ブラウザのネイティブ対応がまだ不安な範囲は、ビルド時に従来の @media 記法へ展開するプラグインを噛ませ、出力 CSS は既存ブラウザでも動く形を保ちました。派手な基盤入れ替えはしていません。やったのは、散らばっていた境界に名前を付けて一か所に集めただけです。結果、その後のレスポンシブ修正は定義の一行を直すだけで済むようになり、境界前後の二重適用も解消しました。
この案件で一番効いた学びは、移行を「全部いっぺんに」やろうとしないことでした。既存の @media 記法と @custom-media は共存できるので、新規・改修するコンポーネントから順に名前参照へ寄せ、古い直書きは触るタイミングで置き換える。一括変換を狙うと差分が巨大になり、レビューも回帰確認も破綻します。なお、どの記法をネイティブのまま本番投入し、どこをビルドで補うかの線引きは、モダンCSSネイティブ機能の記事で触れた Baseline の読み方で判断すると安全です。
どこから着手するか
レスポンシブの修正が毎回「全置換ギャンブル」になっているなら、まずプロジェクトで使われているブレークポイント値を全部書き出してみることをお勧めします。同じ意味の境界がいくつの表記で散らばっているかが見えれば、それがそのまま統合すべき対象です。
次の一歩は、--sp --tablet --pc のような数個の名前を定義し、新しく触るコンポーネントから名前参照に切り替えること。古い直書きは無理に一括変換せず、改修のついでに少しずつ寄せていけば、差分も確認も小さく保てます。
レスポンシブの崩れが直しても直しても再発する、CSS が肥大して触るのが怖い——そうしたお悩みがあれば、グリームハブのお問い合わせからご相談ください。現行サイトの CSS を拝見し、ブレークポイントとデザイントークンを一元化して、保守しやすい構造に整理します。
