2026.07.18 アーキテクチャ

レスポンシブデザインの作り方｜メディアクエリとブレークポイント設計の実装手順

Q: レスポンシブデザインはHTMLとCSSだけで作れますか？

作れます。viewportメタタグ・メディアクエリ・可変レイアウトという中核はすべてHTMLとCSSの範囲です。JavaScriptが必要になるのは、ハンバーガーメニューの開閉やアコーディオンのような挙動を伴う部品に限られます。まずCSSだけで組み、挙動が要る箇所にだけ最小限のJavaScriptを足す順番が保守面でも扱いやすい構成です。

Q: メディアクエリはどこに書けばよいですか？

CSSファイル内に@media規則として書く形が基本です。link要素のmedia属性で条件別にCSSファイルを分ける書き方もありますが、条件に合わないファイルもダウンロード自体は行われるため、分割による転送量の削減は起きません。@importでの読み込みは表示開始を遅らせる要因になるので使わず、1ファイル内にモバイルファーストの順で書くことを推奨します。

Q: メディアクエリが効かないときはどこを確認すればよいですか？

確認順は4つです。(1)head内のviewportメタタグの記述漏れ、(2)記述順と詳細度（上書きしたい指定が基準スタイルより前に書かれていないか、詳細度で負けていないか）、(3)@media構文の誤り（andの前後の空白抜けや括弧の対応）、(4)ブラウザキャッシュ。経験上もっとも多いのは(1)で、この場合はどのメディアクエリも一切反応しないという症状になります。

Q: 既存のPCサイトを後からレスポンシブ対応にできますか？

可能です。ただし工数は既存HTMLの構造次第で大きく変わります。CSSで見た目を制御できる構造なら基準スタイルとメディアクエリの追加で対応できる一方、テーブルレイアウトや固定px幅が多いHTMLでは打ち消しの記述が膨らみ、作り直した方が早い場合があります。部分改修と全面リニューアルのどちらが割に合うかは、既存コードの診断を先に行ってから決める順番です。

Q: PC用とスマホ用でCSSファイルを分けるべきですか？

企業サイト規模なら1ファイルにまとめる構成を推奨します。分割してもブラウザは両方のファイルを読み込むため速度面の利点がなく、同じ部品のスタイルが2ファイルに分かれると修正漏れの温床になります。ファイルを分けるのは、ビルドツールで結合する開発環境が整っている大規模開発に限る、という線引きで問題ありません。

レスポンシブデザインの実装は、viewportメタタグの記述、メディアクエリによる画面幅ごとのスタイル切り替え、フレックスボックスやCSSグリッドによる可変レイアウトという3層の作業で構成されます。HTMLとCSSの具体的な記述を示しながら、作り方をゼロから通しで手順化するのが本記事の狙いです。Media Queries Level 4の範囲記法やコンテナクエリといった2026年時点の書き方も取り上げ、ブレークポイントをいくつ・どこに置くかという設計判断まで踏み込みます。対象は自分でコードを書く実装者と、レスポンシブ対応の見積もりを技術面から確かめたい担当者です。

1 まとめ｜レスポンシブデザインを作る4工程とメディアクエリ設計の要点
2 レスポンシブデザインの作り方の全体像とviewport設定の事前準備
- 2.1 viewportメタタグの記述と画面幅どおりに描画させる仕組みの理解
- 2.2 モバイルファーストで書くCSSの基本構造と上書きで積み上げる適用順序
3 メディアクエリの書き方とブレークポイントをコンテンツ基準で決める設計手順
- 3.1 min-widthとmax-widthの基本記法とLevel 4範囲記法の書き分け
- 3.2 端末名ではなくコンテンツが崩れる幅で決めるブレークポイントの設計手順
4 フレックスボックスとCSSグリッドで組む可変レイアウトと画像・文字の対応
5 レスポンシブ実装の失敗パターンと自作か制作会社依頼かを分ける判断基準
6 よくある質問
7 関連記事

まとめ｜レスポンシブデザインを作る4工程とメディアクエリ設計の要点

作り方の結論を先に示します。工程は4つです。(1) HTMLのhead内にviewportメタタグを記述する、(2) スマートフォン向けの1カラムレイアウトを基準CSSとして書く、(3) min-width系のメディアクエリで広い画面向けの上書きを重ねる、(4) 表示が崩れた箇所にだけブレークポイントを追加する。この順で書くモバイルファースト構成にすると、上書きの記述量が減り、保守しやすいCSSになります。

ブレークポイントは端末名からではなく、コンテンツが崩れる幅に置きます。実務では768pxの1本から始めて2〜3本で収まる構成が扱いやすく、中間幅はフレックスボックスやグリッドの可変指定で吸収する形です。カード一覧のような繰り返し要素であれば、CSSグリッドのauto-fit指定を使うとメディアクエリなしで列数を可変にできます。以降の章で、各工程のコードと判断条件を順に確認していきます。

レスポンシブデザインの作り方の全体像とviewport設定の事前準備

コードを書き始める前に、モバイルブラウザがページをどう描画するかと、CSSをどの順で書くかという2つの前提を押さえます。レスポンシブデザインの定義や、別URL・動的配信との方式比較といった検討段階の内容は、兄弟記事のレスポンシブデザインの仕組みとスマホ対応方式の選び方の解説に整理してあるため、方式選定から迷っている場合はそちらが先です。

viewportメタタグの記述と画面幅どおりに描画させる仕組みの理解

レスポンシブ実装の起点は、HTMLの<head>内に置く<meta name="viewport" content="width=device-width, initial-scale=1">の1行です。width=device-widthが描画幅を端末の画面幅に合わせる指定、initial-scale=1が初期表示倍率の指定にあたります。

この記述がないと、多くのモバイルブラウザは980px前後の仮想幅でページを描画し、全体を縮小して表示します。メディアクエリを正しく書いても、ブラウザが自分の幅を980pxと認識しているため、スマートフォン向けの指定が発動しません。「メディアクエリが効かない」というトラブルの多くはこの記述漏れが原因です。パラメータの種類ごとの意味はviewportの書き方とパラメータ一覧の解説で詳しく扱っています。

モバイルファーストで書くCSSの基本構造と上書きで積み上げる適用順序

CSSは同じ詳細度なら後に書いた指定が優先されます。この性質を前提に、メディアクエリの外へスマートフォン向けの1カラムスタイルを基準として書き、広い画面向けの差分だけをmin-widthのメディアクエリで後から上書きするのがモバイルファーストの構造です。スマホ用のスタイルが最も単純になるため、差分として書く量が最少で済みます。

逆に、PC向けを基準にmax-widthで縮小方向へ上書きするデスクトップファーストも動作はします。ただし複雑なPCレイアウトを打ち消す記述が膨らみやすく、新規実装で選ぶ理由は薄い方式です。Googleが2023年10月末に移行完了を公表したモバイルファーストインデックスでも評価対象はモバイル版ページであり、スマートフォン表示を基準に書く方が設計と検索評価の向きが揃います。

メディアクエリの書き方とブレークポイントをコンテンツ基準で決める設計手順

メディアクエリはCSSファイル内に@media規則として書くのが基本形です。記法そのものは少数で覚えられるため、実装の中心はブレークポイントをどこに置くかという設計に移ります。

min-widthとmax-widthの基本記法とLevel 4範囲記法の書き分け

広い画面向けの上書きは@media (min-width: 768px) { … }、狭い画面に限定した指定は@media (max-width: 767px) { … }と書きます。モバイルファーストで組む場合、基準スタイルとmin-widthの積み上げだけでほぼ完結し、max-widthの出番は例外的な打ち消しに限られます。

Media Queries Level 4では@media (width >= 768px)のように比較演算子で書く範囲記法が定義され、Chrome 104以降・Firefox 102以降・Safari 16.4以降が対応しています（2026年7月時点）。従来記法でmin-widthとmax-widthを併用したときに意識が要った767px／768pxの境界の書き分けを、@media (480px <= width < 768px)のように不等号1行で表せるのが利点です。閲覧環境を現行ブラウザに限定できる案件なら範囲記法へ寄せて構いません。更新の止まった社内ブラウザが残る環境では、従来のmin-width／max-width記法が無難です。

端末名ではなくコンテンツが崩れる幅で決めるブレークポイントの設計手順

「iPhoneの画面幅が390pxだから」と端末名を基準にブレークポイントを決めると、新端末が出るたびに前提が崩れます。決め方はコンテンツ基準です。開発者ツールでウィンドウ幅を連続的に変えながら、レイアウトが崩れる幅・行長が読みにくくなる幅を探し、そこに境界を置きます。とはいえ出発点は必要なので、初期値には次の構成が使えます。

構成	境界値	想定レイアウト
1本	768px	767px以下1カラム／768px以上2カラム
2本	768px・1024px	スマホ・タブレット・PCの3段階
3本	480px・768px・1024px	小型スマホ向け調整を追加

境界の本数を増やすほど検証すべき表示パターンが増え、保守のたびに全パターンの確認が発生します。まず768pxの1本で組み、崩れた箇所にだけ追加する運用が費用に効きます。中間幅の細かな調整は、次章の可変レイアウトで境界を増やさずに吸収するのが先です。

フレックスボックスとCSSグリッドで組む可変レイアウトと画像・文字の対応

メディアクエリは切り替えの仕組みにすぎず、各画面幅での実際のレイアウトはフレックスボックスとCSSグリッドで組みます。どちらも主要ブラウザで長く安定しており、フロート時代のような回り込み解除のハックは不要になりました。

フレックスボックスで横並びを縦積みへ切り替えるカラム実装の手順

2カラム構成の切り替えは、基準CSSで親要素にdisplay: flexとflex-direction: columnを指定して縦積みにし、メディアクエリ内でflex-direction: rowへ上書きする2段構えで実装します。本文とサイドバーのような主従カラムなら、本文側にflex: 1、サイドバー側に固定幅を与えると、画面幅の変化を本文側だけが吸収します。

個数が変わる一覧の横並びにはflex-wrap: wrapとgapを組み合わせます。子要素へflex: 1 1 240pxのように基底幅を持たせると、確保できる幅に応じて自動で折り返され、境界を書かずに1行あたりの個数が変わる動きです。要素間の余白をmarginで打ち消し合わせる旧来の書き方より、gapの方が端の余白処理を含めて記述が短く済みます。

CSSグリッドのauto-fitとminmaxで列数を自動可変にする実装

カード一覧のように同型の要素を敷き詰める箇所は、grid-template-columns: repeat(auto-fit, minmax(240px, 1fr))の1行で列数の可変が完結します。コンテナ幅に240px以上の列が入る数だけ列が作られ、余った幅は1frの指定で各列へ均等に配分される動きです。

この書き方の効果は、ブレークポイント間の中間幅で余白だけが間延びする現象を防げる点にあります。メディアクエリで4列→2列と不連続に切り替える構成と違い、列数が幅に応じて連続的に変わるため、設計者が管理する値はカードの最小幅240pxの1つだけになります。検証パターンが減る分、ブレークポイント自体を減らせるのがグリッドを使う実利です。

画像のsrcset指定とclamp()関数による文字サイズの可変対応

画像は基準CSSにimg { max-width: 100%; height: auto; }を置き、親要素からはみ出さない状態をまず作ります。そのうえで転送量を減らすには、img要素のsrcset属性とsizes属性で幅別の画像候補を渡し、どれを読み込むかをブラウザに選ばせます。スマホとPCで構図ごと差し替えたい場合に限り、picture要素での出し分けを使うという役割分担です。

文字サイズはfont-size: clamp(1rem, 0.9rem + 0.5vw, 1.25rem)のように最小値・推奨値・最大値の3引数で指定すると、境界での急な切り替えなしに画面幅へ追従します。効果が出やすいのは見出しのような大きめの文字で、本文はremの固定値のままでも読みにくくなりにくいというのが実装上の目安です。remを基準単位にしておくと、ブラウザの文字サイズ設定を変えている読者の環境も壊しません。

レスポンシブ実装の失敗パターンと自作か制作会社依頼かを分ける判断基準

ここからは判断の章です。避けるべき実装と、コンテナクエリのような新しめの仕組みを使う場面、そして内製と外注の切り替え条件を、それぞれ条件付きで言い切ります。

user-scalable=no指定と表のはみ出しに代表される実装の失敗例

viewportへuser-scalable=noやmaximum-scale=1を足してピンチズームを禁止する実装は避けます。文字を拡大できない状態はアクセシビリティを直接損ない、iOSのSafariはバージョン10以降この指定を無視する挙動です。効くブラウザでは害になり、効かないブラウザでは無意味という、入れる理由のない指定になっています。

PC向け要素をdisplay: noneで隠すだけのスマホ対応も要警戒です。非表示でもHTMLや画像の読み込み自体は発生するため転送量が減らず、モバイル表示の速度だけが落ちます。読み込ませない対応（srcsetでの出し分けや要素自体の削減）へ寄せるのが筋です。列の多い表は、列を削るよりoverflow-x: autoを指定した親要素で横スクロールに逃がすと、データを保ったまま収まります。タップ要素はLighthouseの監査基準で48×48CSSピクセル相当の領域が目安とされており（2026年7月時点）、リンクを縦に詰めて並べるフッターなどで不足しがちです。

コンテナクエリを導入する条件と従来のメディアクエリで足りる場面の線引き

@container規則で書くコンテナクエリは、ビューポート幅ではなく親要素の幅を基準にスタイルを切り替える仕組みで、Chrome 105以降・Safari 16以降・Firefox 110以降が対応しています（2026年7月時点）。導入してよい条件は1つで、同じコンポーネントを幅の異なる複数の親（本文カラムとサイドバーなど）で使い回す設計になっている場合です。この場合はビューポート基準のメディアクエリでは配置先ごとの見え方を制御しきれず、コンテナクエリが構造的に正しい道具になります。コンポーネント単位の設計例はCSS Container Queriesで実現するコンポーネント単位のレスポンシブ設計で扱っています。

ページ全体のレイアウト切り替えが目的なら、従来のメディアクエリで足ります。コンテナクエリはcontainer-typeの事前指定など準備の記述が増えるため、コンポーネントの使い回しがない数ページのサイトへ持ち込むのは過剰です。ここは言い切ります。デザインシステムやUI部品のライブラリ化を前提にした案件以外では、2026年時点でもメディアクエリ＋可変グリッドを既定の構成にすべきです。

自作で進めてよい条件と制作会社への依頼に切り替える条件の見極め

自作で進めてよいのは、(1)対象が静的な数ページで、(2)HTMLとCSSを編集できる担当者が社内におり、(3)デザインカンプの厳密な再現までは求めない場合です。この3条件が揃うなら、本記事の4工程で公開まで到達できます。WordPressなどCMSの既製テーマを使っているなら、テーマ側がレスポンシブ対応済みかを先に確かめてください。対応済みであれば、そもそも実装作業が発生しません。

切り替えの基準も明確です。(1)既存PCサイトへの後付け対応で、テーブルレイアウトや固定px指定が多く構造の改修が絡む、(2)ECや会員機能を持ち、表示崩れが売上・業務に直結する、(3)実機での検証端末や検証工数を社内で確保できない——このいずれかに該当したら外部へ出す方が総コストは下がります。後付けのレスポンシブ化は新規制作より制約が多い作業のため、スマートフォンサイト制作の受託サービスのように、既存HTMLの構造診断から入って進め方ごと設計する窓口へ相談する形が手戻りを防ぎます。

よくある質問

レスポンシブデザインの実装に着手する前に挙がりやすい疑問へ簡潔に答えます。

レスポンシブデザインはHTMLとCSSだけで作れますか？