レスポンシブデザインの最新手法とベストプラクティス【2026年版】

Q: 古いブラウザへの対応はどうすればいいですか？

Container Queriesについては@supports not (container-type: inline-size)で従来のメディアクエリによる代替記述を用意できます。clamp()とCSS Gridのauto-fitは対応範囲が広いため、2026年時点では特別なフォールバックを用意しなくても大きな問題にはなりにくいです。

この記事の対象: レスポンシブの実装方法を現場の最新知見で更新したいフロントエンドエンジニア・デザイナー
読了時間: 約8分

レスポンシブデザインは「メディアクエリでブレイクポイントを切り替える」段階を抜けて、コンポーネント単位で自律的にレイアウトを変えるフェーズに入っています。Container Queriesが実務の選択肢として定着し、clamp()によるFluid Typographyも一般的な実装手法になりました。2026年後半時点での実装手法とチェックすべきポイントを整理します。

レスポンシブデザインの基本おさらい

レスポンシブデザインとは、画面サイズに応じてレイアウトやスタイルを動的に変更し、スマートフォンからPCまで同じHTML・CSSで快適に閲覧できるようにする設計手法です。

従来の主戦術は、ビューポート幅を基準にした@media (min-width: ○○px)でのブレイクポイント切り替えでした。この考え方自体は今も有効ですが、ページ全体を対象にしたビューポート基準の判断と、コンポーネント単位の判断を分けて使うのが今のスタンダードです。ページレイアウトの大枠はビューポート基準、カード・ウィジェットなど再利用されるパーツはコンテナ基準、という役割分担で考えると実装の見通しが良くなります。

2026年の実装手法

Container Queries（コンテナベースのレスポンシブ）

Container Queriesは主要ブラウザが対応を完了してから数年が経ち、2026年には実務で選択肢に入れるのが当たり前の技術になっています。従来のメディアクエリがビューポート幅を参照するのに対し、Container Queriesは親コンテナの幅を参照してスタイルを変更します。

/* コンテナとして宣言 */
.card-wrapper {
  container-type: inline-size;
  container-name: card;
}

/* コンテナの幅が400px以上のとき */
@container card (min-width: 400px) {
  .card {
    display: grid;
    grid-template-columns: 200px 1fr;
    gap: 16px;
  }
}

/* コンテナの幅が400px未満のとき */
@container card (max-width: 399px) {
  .card {
    display: block;
  }
  .card img {
    width: 100%;
  }
}

実装のポイント: 同じコンポーネントをサイドバーにもメインエリアにも配置でき、配置場所に応じて自動的にレイアウトが切り替わります。ビューポート基準のメディアクエリでは、同じカードでも「サイドバーに置いたときだけ崩れる」という事故が起きやすく、Container Queriesはこれをコンポーネント側の責任として解決できる点が大きな違いです。

つまずきやすい点: container-type: inline-sizeを指定したコンテナの子要素に%指定の幅を使うと、意図しないサイズになることがあります。コンテナクエリ配下では固定単位かclamp()を優先するほうが事故が少ないです。

対応ブラウザ: Chrome・Edge・Firefox・Safariの最新版で問題なく動作します。古いブラウザへのフォールバックが必要な場合は、@supports not (container-type: inline-size)で従来のメディアクエリ記述を併記します。

商品一覧カードのようなコンポーネントをContainer Queriesで組んでおくと、トップページの3カラムグリッドと、関連商品の1カラムスライダーのように配置先が異なる場面でも、メディアクエリを追加せずに両方のレイアウトを成立させられます。これは「置かれる場所ごとにスタイルを調整する」工数そのものを減らせるという、実務上のメリットです。コンポーネント単位の判断がしっかり実装されたサイト例をもっと見たい場合は、以下の記事で構成パターンをまとめています。

リニューアルガイドブランドサイト・サービスサイトの参考事例10選｜構成とデザインの決め方「参考サイトを3つ出してください」と制作会社から言われて、手が止まっていませんか。きれいなサイトはいくらでも見つかります。ただ、集めたブックマークを並べて…

clamp()関数によるFluid Typography

メディアクエリを使わずに、ビューポート幅に応じてフォントサイズや余白が滑らかに変化する手法です。

/* 最小16px、最大24px、ビューポート幅に応じて可変 */
h2 {
  font-size: clamp(1rem, 0.5rem + 2vw, 1.5rem);
}

/* 本文テキスト */
body {
  font-size: clamp(1rem, 0.9rem + 0.5vw, 1.125rem);
  line-height: clamp(1.6, 1.5 + 0.3vw, 1.8);
}

/* 余白にも応用可能 */
section {
  padding: clamp(24px, 4vw, 80px);
}

実装のポイント: ブレイクポイントの切り替え地点で不自然にジャンプするのではなく、シームレスにサイズが変動します。見出しの改行位置が画面幅によって急に変わる、という従来のメディアクエリ特有の違和感を避けられます。

つまずきやすい点: clamp()の第2引数（可変部分）にvwだけを使うと、ユーザーがブラウザの文字サイズ設定を変更しても反映されません。アクセシビリティを考えるとremを混ぜた式（0.9rem + 0.5vwのような形）にしておくのが安全です。

対応ブラウザ: Chrome・Edge・Firefox・Safariともに主要バージョンで問題なく動作します。

CSS Grid + auto-fit / auto-fill

カードグリッドのレスポンシブ対応をメディアクエリなしで実現する手法です。

.card-grid {
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(280px, 1fr));
  gap: 24px;
}

実装のポイント: 画面幅に応じてカラム数が自動的に増減します。ブレイクポイントの指定が不要で、コンテンツの量が変動しても柔軟に対応できます。auto-fitとauto-fillの違いは、要素数が少ないときに残りのトラックを広げるか空けたままにするかで、カード幅を揃えたい場面ではauto-fitを選ぶのが基本です。

つまずきやすい点: minmax(280px, 1fr)の最小値を大きくしすぎると、スマートフォンの画面幅でも横スクロールが発生します。最小値はいちばん小さい想定ビューポート幅から余白を引いた値で検証してください。

レスポンシブ手法の役割分担

コンポーネント単位

Container Queries
clamp()
Grid auto-fit

ページ全体

従来のメディアクエリ
ナビゲーションの出し分け
セクション順の入れ替え

ページ全体のレイアウト判断と、パーツ単位のレイアウト判断を分けて設計すると、どちらの手法を使うべきか迷わなくなります。レイアウトの型そのものをもう一段深く設計したい場合は、スプリットレイアウトの実装判断も参考になります。

デザインスプリットレイアウトの作り方｜CSSコードと判断基準【2026年版】スプリットレイアウト（画面を左右に分割するレイアウト）は、CSS Gridの数行で組めます。先に答えだけ書きます。比率は grid-template-co…

ブレイクポイントの設定（2026年の考え方）

従来のデバイス名ベース（iPhone、iPad等）ではなく、コンテンツベースでブレイクポイントを設定するのが現在のベストプラクティスです。デバイスの画面幅は年々バリエーションが増えており、特定の機種名に合わせた設計はすぐに陳腐化します。

ただし、目安として以下の値は今も広く使われています。

名称	幅	対象
sm	640px	大きめのスマートフォン
md	768px	タブレット
lg	1024px	小さめのPC
xl	1280px	標準的なPC
2xl	1536px	大画面PC

/* モダンなブレイクポイント設定 */
:root {
  --bp-sm: 640px;
  --bp-md: 768px;
  --bp-lg: 1024px;
  --bp-xl: 1280px;
}

ポイント: Container QueriesとFluid Typographyの組み合わせにより、ページ全体で管理すべきブレイクポイントの数自体を減らせるのが実装上の大きな変化です。コンポーネント側がコンテナクエリで自己完結していれば、ページ側で管理するブレイクポイントは最小限に抑えられます。

商品ページのように要素数が多く、コンポーネントの入れ替わりが頻繁に起きる画面では、この役割分担の効果が特に出やすいです。構成の置き順まで含めて考えたい場合は以下を参照してください。

デザイン Shopify商品ページの構成と作り方｜要素を置く順番の設計 Shopifyのテーマには、最初から商品ページが用意されています。写真があって、価格があって、カートに入れるボタンがあって、その下に説明文が続く。これで一応…

テスト環境の構築

レスポンシブ確認の流れ

DevToolsで確認複数幅をシミュレーションし崩れを洗う

複数幅を同時表示スクロール連動で一括チェック

実機で最終確認タッチ操作とフォントレンダリングを見る

Chrome DevTools

デバイスモードで様々な画面幅をシミュレーションできます。Container Queriesのデバッグにも対応しており、コンテナの境界線をオーバーレイ表示できるので、どのコンテナがどの幅でクエリを発火させているか目視できます。

複数幅を同時表示するツール

複数の画面サイズを同時に表示してレスポンシブの挙動を確認できるツール群です。一度のスクロールが全サイズに反映されるため、確認作業のスピードが大きく変わります。Container Queriesを多用する実装では、ページ全体のビューポート幅だけでなく、各コンポーネントがどの幅で切り替わるかも併せて見ておく必要があります。

実機テスト

DevToolsでは再現できないタッチ操作、SafariのUI挙動、フォントレンダリングの違いを確認するため、iPhoneとAndroidの実機テストは欠かせません。特にclamp()で可変にしたフォントサイズは、実機のデフォルト設定（文字サイズを大きくしている利用者など）でどう見えるかまで確認しておくと安心です。

よくある質問

Container Queriesとメディアクエリはどちらを使うべきですか？

役割で分けるのが基本です。ページ全体のレイアウト（ナビゲーションの出し分け、セクションの表示順など）はメディアクエリ、再利用するコンポーネント（カード、ウィジェットなど）はContainer Queriesという分担にすると、実装の見通しが良くなります。どちらか一方に統一する必要はありません。

clamp()を使うとブレイクポイントは完全に不要になりますか？

完全には不要になりません。ページ全体の構成（カラム数やナビゲーションの形式）を変える判断は依然としてブレイクポイントが必要です。clamp()が置き換えられるのは、フォントサイズや余白のような「段階的に変える必要のない」数値だけです。

古いブラウザへの対応はどうすればいいですか？

Container Queriesについては@supports not (container-type: inline-size)で従来のメディアクエリによる代替記述を用意できます。clamp()とCSS Gridのauto-fitは対応範囲が広いため、2026年時点では特別なフォールバックを用意しなくても大きな問題にはなりにくいです。

Shopifyのテーマでもこれらの手法は使えますか？

使えます。Liquidテンプレート自体はHTML出力の仕組みなので、セクションのCSSにContainer QueriesやGrid auto-fitを組み込むことに制約はありません。ただしテーマエディタでの編集可能性を考えると、コンテナの命名規則だけは早い段階で決めておくと後からの改修が楽になります。

AIにレスポンシブのコードを書かせても大丈夫ですか？

下書きとしては有効ですが、コンテナの入れ子関係やブレイクポイントの役割分担まではAI側が把握できないことが多く、そのまま採用すると崩れの原因になりやすいです。生成されたコードをどこまで信頼して使えるかは以下で整理しています。

コラム AIでデザインは生成できるか｜実務で使えるかの現在地「AIでデザインが作れる時代になった」という話を、この1年で何度聞いたでしょうか。制作会社の中にいると、この言葉が指しているものが、話す人によってまったく違…

レスポンシブ対応の工数や費用はどれくらいかかりますか？

ページ数・コンポーネントの再利用範囲・既存CSSの状態によって大きく変わるため、一概な金額は出せません。既存サイトをContainer Queriesベースに書き換える場合は、まずコンポーネント単位の洗い出しと優先順位付けから始め、影響範囲の大きいカード・グリッド系のパーツから着手すると、工数の見通しを立てやすくなります。