「このお知らせカード、トップのメインエリアでは画像を横に並べて、サイドバーに置くときは縦に積みたい」——受託の制作現場で、同じ見た目の部品を場所ごとに少しずつ変えたい、という要望は日常的に出ます。ところが、長年レスポンシブの分岐に使ってきたメディアクエリ（@media）は、画面（ビューポート）の幅でしか分岐できません。カード自体が「いま狭い場所に置かれているか、広い場所に置かれているか」は判断できない。結果、メインカラム用のカードとサイドバー用のカードを別々に作り、同じようなコードが二重三重に増えていく。受託で一度作った部品が「その場所専用」になって使い回せず、案件のたびに似たものを作り直す——これが、メディアクエリだけで組んだサイトに溜まりやすい負債です。
これを解くのがコンテナクエリ（Container Queries）です。web.dev が 2026 年に整理した Interop 2026（web.dev） でも、ブラウザ間で安定して使える基盤として継続的に磨かれている機能で、いまや実務で前提にできる段階に入りました。コンテナクエリを使うと、部品が「自分の置かれた領域の幅」を見て、自分でレイアウトを切り替えられるようになります。本記事では、受託で「どこに置いても崩れない、使い回せる UI」を作る道具として、コンテナクエリをどう使うかを整理します。
なぜメディアクエリだけだと部品が使い回せないのか
メディアクエリでレスポンシブを組む発想は、「画面が広いか狭いか」を基準にレイアウトを決めるものです。これはページ全体の骨格を決めるには向いていますが、部品の単位では合わなくなります。
理由は、同じ画面幅でも、部品の置き場所によって使える横幅が違うからです。デスクトップ（画面幅 1200px）でも、メインカラムに置かれたカードは 800px 使える一方、サイドバーに置かれた同じカードは 280px しか使えません。メディアクエリは画面幅しか見ないので、「画面が広いから横並びにする」と書くと、サイドバーの狭いカードまで横並びになって窮屈に潰れます。
この不一致を回避するために、現場は「メインカラム用カード」「サイドバー用カード」「フッター用カード」と、置き場所ごとにバリエーションを作りがちです。見た目はほぼ同じなのに、HTML のクラスも CSS も別々に持つ。すると、カードのデザインを少し直すだけで、全バリエーションを横断して直す必要が出てきます。受託では、この「同じものの作り分け」が、制作工数と保守工数の両方を静かに押し上げます。
コンテナクエリは、この基準そのものを変えます。判断の軸を「画面の幅」から「親要素（コンテナ）の幅」に移すことで、部品は自分が実際に使える横幅を見てレイアウトを決められる。同じカードを、メインカラムに置けば横並び、サイドバーに置けば縦並びに、一つのコードのまま自動で切り替えられます。
コンテナクエリの基本 — 「測る親」と「見る子」を決める
コンテナクエリは二段階で考えます。まず、基準にしたい親要素を「コンテナ」として宣言し（測る親）、次にその中の子要素が、親の幅に応じてスタイルを切り替えます（見る子）。
/* 1. 測る親：このエリアを幅の基準（コンテナ）にする */
.card-area {
container-type: inline-size; /* 横幅を測れるようにする */
container-name: card-area; /* 名前を付けておくと指定しやすい */
}
/* 2. 見る子：親(card-area)が400px以上のときだけ横並びにする */
@container card-area (min-width: 400px) {
.card {
display: grid;
grid-template-columns: 160px 1fr; /* 画像とテキストを横並びに */
}
}ポイントは、@container の条件が「画面の幅」ではなく「コンテナの幅」を見ていることです。.card 自体は同じコードのまま、.card-area が広ければ横並び、狭ければ（条件を満たさず）縦並びになる。この .card を、800px のメインカラムに置けば横並びで、280px のサイドバーに置けば縦並びで表示される——置き場所を変えるだけで、部品が自分で適応します。
クラスで「場所ごとの専用品」を作る発想から、要素が自分のサイズを基準に振る舞う発想への移行は、CSSアンカーポジショニングの記事で扱った「位置や振る舞いを要素自身に持たせる」考え方と同じ流れにあります。
受託で効く「コンポーネント駆動」の組み方
コンテナクエリの本当の価値は、単体の便利さより、設計の方針を変えられることにあります。部品が置き場所に依存しなくなると、サイトを「ページ単位」ではなく「部品単位」で組み立てられるようになります。
| 観点 | メディアクエリ中心 | コンテナクエリ併用 |
|---|---|---|
| 分岐の基準 | 画面の幅 | 部品が置かれた領域の幅 |
| 同じ見た目の部品 | 置き場所ごとに作り分け | 一つを使い回す |
| デザイン修正 | 全バリエーションを横断修正 | 一か所を直せば全箇所に反映 |
| 別案件への流用 | 場所前提が固定で流用しづらい | 部品として持ち出しやすい |
この「一つの部品を使い回す」設計は、受託で複数のサイトを手がけるほど効いてきます。一度きちんと作ったカードやリストの部品が、置き場所を選ばない「資産」になるからです。次の案件で似た部品が必要になったとき、ゼロから作らず持ち出せる。部品をパターンとして整理し、命名や責務を揃えていく考え方は、CSSカスタム関数で値を共通化する記事で扱ったデザインシステム的な整理と組み合わせると、より強固になります。
なお、コンテナクエリには「幅」だけでなく、コンテナに設定した CSS 変数の値を見て分岐するスタイルクエリもあります。たとえば「このコンテナはダークなトーンだ」という状態を変数で持たせ、その値に応じて中の部品の色を切り替える、といった使い方ができます。レイアウトはサイズで、装飾の質感は状態で——と分岐の軸を分けられるのが、最近のコンテナクエリの強みです。
受託で導入するときの落とし穴
弊社が改修を引き継いだあるメディアサイト（社名は伏せます）では、記事カードが「トップ用」「カテゴリ一覧用」「関連記事用」「サイドバー用」の四種類に分裂していました。見た目はほぼ同じなのに、HTML も CSS も別々で、カードのデザインを少し変える依頼が来るたびに、四か所を漏れなく直す必要がありました。実際、過去に一か所だけ直し忘れ、関連記事のカードだけ古いデザインのまま残る、という事故も起きていました。
私たちはこの四種類を、コンテナクエリを使った一つのカード部品に統合しました。カードを置く各エリア（メインカラム・サイドバーなど）を container-type: inline-size のコンテナにし、カード側は「親が広ければ横並び、狭ければ縦並び」という一つのルールだけを持つ形に。四つあった HTML・CSS は一つになり、デザイン修正は一か所で全箇所に反映されるようになりました。やったのは、置き場所ごとに分裂していた部品を、自分のサイズを見て適応する一つの部品に畳んだだけです。
この案件で一番効いた学びは、コンテナを設定すると、その内側でのサイズ基準が切り替わる点に注意することでした。container-type: inline-size を指定した要素は、内部のレイアウト計算の基準になるため、まれに想定外の高さの詰まり方をすることがあります。コンテナにするのは「部品を並べる領域」に限り、ページ全体を無闇にコンテナ化しない、という線引きをしておくと安全です。
もう一つの落とし穴は、コンテナクエリ用のフォールバックを過剰に作り込まないことです。コンテナクエリは広く実装済みですが、ごく古い環境を考慮する場合でも、メディアクエリで作った既存のレイアウトを土台にし、コンテナクエリは「より賢く適応させる上乗せ」として段階的に入れると、移行のリスクを小さく保てます。一度に全部品を作り替えず、影響範囲を区切って進めるのが、受託での安全な進め方です。
どこから着手するか
「画面幅でしか分岐できない」という前提を外すと、部品の作り方が変わります。同じ見た目の部品を場所ごとに作り分けているなら、それはコンテナクエリで一つに畳める可能性が高い。畳めれば、デザイン修正が一か所で済み、次の案件への流用もしやすくなります。
最初の一歩としては、いま「置き場所ごとに作り分けている部品」を一つ選び、置く領域をコンテナにして、部品側を「親の幅で分岐する一つのルール」に統合してみることをお勧めします。そのうえで、各置き場所で意図どおりにレイアウトが切り替わるかを確認すれば、本番に出せる品質になります。
似た部品の作り分けで制作工数が膨らんでいる、デザイン修正のたびに複数箇所を直していて漏れが怖い、一度作った部品を資産として使い回したい——そうしたお悩みがあれば、グリームハブのお問い合わせからご相談ください。現行サイトのコンポーネント構成を拝見し、置き場所に依存しない再利用できる部品へ段階的に寄せる設計をご一緒に組みます。
