従来のレスポンシブデザインといえばメディアクエリを使ったビューポート（画面幅）ベースの実装が主流でしたが、2026年現在、CSSコンテナクエリがブラウザサポート95%を超えて実用段階に入り、コンポーネントレベルでのレスポンシブデザインという新しい概念が現場に浸透しています。これまでのような「画面幅が何px以下なら」ではなく、「コンポーネントを囲む親要素の幅が何px以下なら」という条件で、より柔軟で再利用しやすいレスポンシブ要素を作れるようになりました。
コンテナクエリが解決する根本的な問題
メディアクエリの最大の制約は、コンポーネントがどんな文脈で使われるかを知らないことでした。コンポーネントは親コンテナがどのくらいのスペースを持っているかしか知らず、ビューポートのサイズは関係ありません。コンテナクエリは、コンテナのサイズに基づいてスタイルを定義することで、コンポーネントを真に移植可能にします。
たとえば、カードコンポーネントをメインコンテンツエリアで使う場合とサイドバーで使う場合、従来は異なるCSSクラスを作るか、JavaScriptで制御する必要がありました。2026年では、同じCSSクラスのカードコンポーネントが、フルワイドヒーローレイアウトでもサイドバーの小さなサムネイルでも自動的に適応します。
ブラウザサポート状況と実装の現状
サイズコンテナクエリは、Chrome 105+、Firefox 110+、Safari 16+、Edge 105+でサポートされ、2026年時点で95%以上のグローバルカバレッジを実現しています。一方で、スタイルクエリ（@container style()）は、Chrome 111+とEdge 111+のみで、FirefoxとSafariはまだ開発中です。
カスタムプロパティを条件とするコンテナスタイルクエリについては、Firefox側の対応次第で、2026年中には実用的になる見込みが高いとされています。実用性を重視するなら、当面はサイズクエリを中心に実装を進めるのが賢明でしょう。
現場で使えるコンテナクエリの基本実装
コンテナクエリの基本構文は、まず親要素にcontainment contextを設定することから始まります：
`.card-container { container: card / inline-size; }` のようにコンテナタイプを `inline-size` に設定することで、親の横方向（英語のような左から右への言語では幅）をクエリできます。続いて子要素に対して `@container (max-width: 400px) { .card-child { grid-template-columns: 1fr; } }` のように条件付きスタイルを適用します。
2026年時点で、:has()疑似クラスも全主要ブラウザで100%サポートされ、プロダクション環境で安全に使える標準ツールとなりました。これにより、コンテナクエリと組み合わせて、より複雑な条件分岐をCSSだけで実現できます。
メディアクエリからの移行戦略
コンテナクエリは既存のメディアクエリを完全に置き換えるものではありません。ページレベルのレイアウト決定（グリッドカラム、サイドバー表示、ナビゲーションスタイル）にはメディアクエリを使い、コンポーネントレベルのレイアウト決定（カードレイアウト、ウィジェット密度、テキスト折り返し）にはコンテナクエリを使うという使い分けが重要です。
移行は段階的に進めます。複数のレイアウトコンテキストで使われるコンポーネント（カード、ウィジェット、ナビゲーション）を特定し、それらの親ラッパーに `container-type: inline-size` を追加します。各コンポーネントの @media ルールを @container ルールに変換し、ブレイクポイント値を調整します（コンテナ幅はビューポート幅より小さくなるため）。
古いブラウザへの配慮として、@supports (container-type: inline-size) を使ってメディアクエリフォールバックを提供し、@supportsでプログレッシブエンハンスメントを行うことで、古いブラウザでもメディアクエリに適切にフォールバックします。
中小企業のウェブ制作現場では、まず最もよく再利用されるコンポーネントから移行を始め、固定幅コンテキストでのみ使用されるものは後回しにするという現実的なアプローチが効果的です。2026年のモダンCSSは、クライアントサイドJavaScriptなしで、真にモジュラーで弾力性があり、高パフォーマンスなUIを構築できる段階に達しています。
