レスポンシブデザイン実践ガイド：画面幅に合わせて読みやすさを保つ設計

2026年10月8日にweb.devのレスポンシブ基礎、MDNのコンテナクエリ・レスポンシブ画像、W3Cのリフロー・ターゲットサイズ、Googleのmobile-first indexing、MDNのvideoの必要範囲を再確認した。ブレイクポイントは端末名でなく内容が崩れる条件から選び、可変レイアウトとズーム許容を保つ。WCAG 2.2のリフローは通常の縦スクロールで幅320 CSS px相当、ターゲットは24×24 CSS pxを基本に例外があるが、これだけで全WCAG・法適合・快適さを保証しない。

レスポンシブデザイン実践ガイド：画面幅に合わせて読みやすさを保つ設計

PCで整っていた比較ページが、スマートフォンでは小さな文字と横長の表になる。そこで情報を隠すと、今度は価格の条件が伝わらない。こうした問題は、端末ごとの完成図を三枚用意するだけでは解決しません。

レスポンシブデザインは、同じ内容を、使える幅と操作方法に合わせて読める・使える形に調整する設計です。ここではHTMLとCSSを編集する制作担当者に向けて、基本の可変レイアウト、切り替える条件、公開前の確認を順に扱います。

30秒で要点

• まず狭い幅で内容と操作を成立させ、広がったときに列や余白を増やす。
• 切り替える幅は端末名から決めず、実際の見出しや部品が収まらなくなる条件から選ぶ。
• 画面全体の幅と、部品を置く場所の幅を区別する。
• 画像の表示幅、取得する画像の大きさ、トリミングは別々に設計する。
• 幅の変更だけでなく、拡大、長い文章、キーボードとタッチ操作も確認する。

先に「何を残すか」を決める

最初に、ページで読み手が行う判断を書き出します。商品比較なら価格、違い、適用条件。申込みなら必要事項と送信結果です。装飾や補助導線より、これらを優先して配置します。

「モバイルではサイドバーを非表示」と決める前に、その中身を読みます。重要な条件なら本文へ移し、関連リンクなら本文の後ろへ置けます。画面を小さくすることと、提供する情報を減らすことは別の判断です。

下図は同じ三つのカードを並べ替えず、列数だけを変える概念図です。カードにはタイトルだけでなく、実際に最も長い説明と操作ボタンを入れて判断します。

ここでいう幅は、ブラウザがレイアウトに使うCSSピクセルで考えます。製品仕様の画面解像度とは一致しないことがあり、ズームやウィンドウの分割でも変化します。「この端末なら必ず二列」とは決められません。

可変レイアウトを基本にする

ビューポートと、はみ出しにくい土台

HTMLのheadには、表示領域を端末に合わせる設定を置きます。フレームワークを使う場合は、その公式の設定方法を確認し、同じタグを重複させないようにします。

<meta name="viewport" content="width=device-width, initial-scale=1">

user-scalable=noなどでズームを止めないでください。読み手が文字を大きくする手段を残します。web.devの基本ガイドも、端末名ではなく内容を基準に切り替えることと、拡大を妨げない設定を説明しています。

次は、横書きの一般的な記事・カードページを想定した最小のCSSです。幅や余白の数値は作例であり、そのまますべてのサイトに当てはまる基準ではありません。

*, *::before, *::after {
  box-sizing: border-box;
}

.page-shell {
  width: min(100% - 2rem, 72rem);
  margin-inline: auto;
}

img, video {
  max-width: 100%;
  height: auto;
  display: block;
}

.card {
  min-width: 0;
  overflow-wrap: anywhere;
}

border-boxは、指定した幅の中に内側の余白と枠線を含めます。これがないと、幅100%に余白を足して横にはみ出すことがあります。min-width: 0は、GridやFlexの部品が長い内容を抱えたまま縮めなくなる問題への対策です。

長いURLや識別子には折り返しも必要です。ただし、すべてを一律に小さな文字へ縮めると読みづらくなります。原因となる要素を特定して直します。ページ全体にoverflow-x: hiddenを付けて切り取るだけでは、見えなくなった情報や操作は戻りません。

Gridで入るだけ並べる

次のカード一覧は、列数を三段階に固定せず、カードの最小幅と空き幅から配置を決めます。

<div class="cards">
  <article class="card"><h2>Aの特徴</h2><p>比較する条件と説明。</p></article>
  <article class="card"><h2>Bの特徴</h2><p>長めの説明でも内容を省略しない。</p></article>
  <article class="card"><h2>Cの特徴</h2><p>適用条件も同じ場所に示す。</p></article>
</div>

.cards {
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(min(100%, 16rem), 1fr));
  gap: 1rem;
}

この例の16remはカード一枚に確保したい幅です。さらに狭い場所では100%を上限にするため、最小幅自体が画面からはみ出すのを避けられます。実際の列数は、親の幅と余白にも左右されます。

リンクを横に並べて必要なら折り返す程度なら、Flexboxも適しています。ページ全体の格子、単純な横並び、文章の幅を同じ方法で解こうとせず、それぞれの関係に合う手段を選びます。

切り替える対象からクエリを選ぶ

クエリは「条件に合うときだけCSSを適用する仕組み」です。可変レイアウトだけでは窮屈になる部分に追加します。

表が収まらない場合は、横にスクロールできます

ページの構成はメディアクエリで変える

.article-layout {
  display: grid;
  gap: 2rem;
}

.article-layout > * {
  min-width: 0;
}

@media (min-width: 64rem) {
  .article-layout {
    grid-template-columns: minmax(0, 1fr) 18rem;
  }
}

これは、本文と補助欄をこの順にHTMLへ書き、狭い幅では縦に並べる例です。64remで本文が十分読めるかは、使う書体、文字数、ページの最大幅で確認します。画面幅を少しずつ動かし、本文が細すぎる、リンクが重なるなどの変化が出る場所を探します。

固定の768pxや1024pxに合わせること自体が間違いではありません。問題は、実際の内容を見ずに「タブレット用」「PC用」と決めてしまうことです。

部品の置き場所はコンテナクエリで扱う

同じ画面の中でも、本文と補助欄では使える幅が違います。サイズコンテナクエリなら、祖先の枠を測って子要素の配置を変えられます。

<div class="feature-slot">
  <article class="feature">
    <img src="feature.jpg" width="640" height="480" alt="機能の使用場面">
    <div><h2>機能の説明</h2><p>選ぶ前に確認する条件。</p></div>
  </article>
</div>

.feature-slot {
  container: feature / inline-size;
}

.feature {
  display: grid;
  gap: 1rem;
}

.feature > * {
  min-width: 0;
}

@container feature (min-width: 32rem) {
  .feature {
    grid-template-columns: minmax(0, 2fr) minmax(0, 3fr);
    align-items: start;
  }
}

測る枠はfeature-slot、変更するのはその内側のfeatureです。自分自身の幅を条件に、自分自身を切り替える例ではありません。画像ファイルは説明用の仮名なので、実際の素材と代替テキストに置き換えてください。

未対応環境では基本の一列が残る構成です。利用者のブラウザで対応状況を確認して導入します。種類の違いと宣言方法はMDNのコンテナクエリガイドで確認できます。

画像・動画・表は、それぞれの読み方を守る

画像は見た目の幅と配信を分ける

CSSで画像を小さく表示しても、元ファイルが小さくなるわけではありません。srcsetで候補を示し、sizesで実際の表示幅の目安を伝えます。ブラウザは画面密度なども考慮して画像を選びます。

例えば、画面幅360 CSS pxのページで左右16pxずつ余白があるなら、画像の表示幅は328 CSS pxです。ここへ「常に画面いっぱい」と指定すると、実際の配置とのずれが生まれます。これは幅を理解するための算数で、取得ファイルの確約ではありません。

横長写真を縮めると主役が小さくなりすぎる場合は、構図の異なる素材へ切り替える判断も必要です。解像度の切り替えと構図の切り替えの違いはMDNのレスポンシブ画像ガイド、配信の実装は画像最適化ガイドで扱っています。

動画の寸法属性には数値を使う

<video width="1280" height="720" controls preload="metadata">
  <source src="product-demo.mp4" type="video/mp4">
  <track kind="captions" src="product-demo-ja.vtt" srclang="ja" label="日本語" default>
</video>

これは実動画と字幕ファイルを別に用意する例です。先ほどのmax-width: 100%; height: auto;をCSSで適用します。HTML属性にwidth="100%"やheight="auto"を入れる方法とは分けてください。MDNのvideo要素リファレンスは、寸法属性に数値を使うことを説明しています。

動画は枠だけでなく、再生・停止の操作、字幕、音声なしでも内容が伝わるかも確認します。

表は比較する軸を消さない

横長の表は、列を隠すと比較条件が欠けることがあります。表の領域だけを横にスクロールできるようにするか、用途に合わせた別の表示を用意します。どちらでも、列見出しと値の関係を維持します。

「横にスクロールできます」という案内だけでは不十分です。キーボードで領域へ移動できるか、隠れた列に到達できるか、フォーカスの位置が見えるかまで確認します。表をカード表示へ変える場合も、各数値が何の値か伝わる必要があります。

小さな画面以外でも使えるか確かめる

拡大したときに情報が欠けないか

W3CのWCAG 2.2では、通常の縦スクロール内容について、幅320 CSS px相当で情報や機能を失わず、縦横両方のスクロールを要求しないことがリフローの基準です。二次元の配置が意味を持つ表や図などには例外がありますが、表の個々のセル内の文章まで無条件に除外されるわけではありません。W3Cのリフロー解説

PCのブラウザを拡大しても、固定ヘッダーが本文を覆わないか、ボタンが画面外へ出ないか、フォームのエラーを読めるかを見ます。単に「スマートフォン幅で崩れなかった」とは別の確認です。

触れることと、押せることを分ける

小さなアイコンが見えていても、隣を誤って押してしまうなら操作しづらい設計です。WCAG 2.2のターゲット最小サイズは24×24 CSS pxを基本とし、間隔、文中リンク、同等の操作手段などに例外があります。基準の最小値だけを狙うのではなく、重要な操作は余裕を持った領域で試します。W3Cのターゲットサイズ解説

狭い幅でメニューを折りたたむ場合は、ボタンに開閉状態を伝え、キーボードでも開いてリンクへ進めるようにします。JavaScriptが必要な実装では、処理が動く前からリンクをすべて隠してしまわないよう、動かないときの導線も考えます。

画面幅だけでマウスかタッチかは判定できません。ホバーしないと説明や操作が現れない作りは、タッチやキーボードで同等の手段があるかを確かめます。なお、ここで挙げた項目だけでアクセシビリティ全体の適合を判定できるわけではありません。

検索への対応は、内容が同じかから確認する

Googleはモバイル版の内容をインデックスとランキングに使用しています。レスポンシブ方式を実装・保守のしやすさから推奨していますが、それ自体が順位上昇の保証ではありません。Googleのモバイルファーストインデックスの案内

主要な説明、見出し、画像の代替テキスト、重要なリンクが小さい画面でも利用できるかを確認します。折りたたんで見せることと、クリックするまで本文自体を取得しないことも区別します。検索に読ませたい主要内容を、操作後の取得だけに依存させない設計が必要です。

一つの代表ページで、崩れる条件を探す

サイト全体を直す前に、長い見出し、画像、表、フォームを含む代表ページを選びます。短い仮テキストだけで確認すると、本番の文章を入れた後に崩れを見逃します。

1. 内容を入れる：最も長いタイトル、空の状態、エラー、長いURLも用意する。
2. 幅を連続的に動かす：最小・中間・最大に加え、各切り替え幅の直前と直後を見る。
3. 拡大する：本文の折り返し、固定要素との重なり、操作の欠落を見る。
4. 手段を変えて操作する：キーボードだけ、タッチ、画面回転、入力中のキーボード表示を試す。
5. 取得する素材を見る：小さく表示しただけで巨大な画像を配信していないかを確認する。
6. 修正を記録する：発生した幅、文章、操作、期待する結果をセットで残す。

表が収まらない場合は、横にスクロールできます

ブラウザの端末表示モードは幅の確認を助けますが、実機操作を置き換えません。問題が見つかった幅だけを直すのではなく、その両側でも情報と操作が保たれるかを確かめます。

次に進むときは、サイト全体の優先順位をWeb制作完全ガイド、読み込みの評価をWebパフォーマンス改善の入門と合わせて整理できます。最初の成果は対応端末数ではなく、「どの条件でも読み手が必要な判断を終えられるか」で見てください。