レスポンシブは
線から面へ
そして空間へ レスポンシブの基準は
高度なブラウザの最適化技術を背景に
画面幅の線から、面のアスペクト比、
そして空間設計へと進化

responsive_design_lines_to_space key visual by Yohiichiroh Kohtani | digivalley
Top›labo›
Responsive Design: From Lines to Space

この記事は『無限分身の忍術使いAspect-Ratio』の続きになります。先にそちらをご覧ください。

レスポンシブはブレイクポイントで切り分けから、アスペクト比、空間構成へと進化

 | 2026/05/29

変遷

レスポンシブデザインの変遷

  • スマホ登場時はデヴァイス判別が主流

    スマホ登場時は「画面幅（Viewport）」に応じたレスポンシブデザイン、つまりブレイクポイントでPC用とスマホ用で画像を切り分け、PCは大きく、スマホは小さくという設計でデザインしていた。
    そしてその切り分けの基準はブラウザの画面幅をいくつにするかが重要だった。
    iPadを含むか含まないか、含まない場合はブレイクポイントはいくつがよいかなど。
    そして現在「デバイスの解像度（ピクセル密度）」が2~3倍となり、それを考慮すると、単純な画面サイズ（物理的な横幅）だけでは最適なレスポンシブ設計は難しくなってきた。

  • ピクセル解像度に応じたデザイン

    ピクセル解像度が二倍三倍となってきた現在、画像を使用する箇所によってはスマホの方がより大きいサイズの画像を必要とするケースが発生し始めた。

    fig-01fig-2-1

  • 参考図は理想的なレスポンシブでのコンテンツ画像の目標サイズ

    あくまで理想とするレスポンシブ時の画像サイズであって、なにも、必ず3倍の画像が必要というわけではない。
    ただし、最低でも2倍の画像はスマホ向けに用意した方がいいんじゃないかな。

  • ヒーロー画面のレスポンシブでの考え方

    PCでは横長のキービジュアル、スマホではそのままのアスペクト比では帯になる。
    スマホの特徴を生かすには、スマホのアスペクト比に応じたビジュアル構成が必要。
    下の参考図をみてもスマホはスマホでビジュアルデザインを構築するべきだと理解できると思う。
    ※A案はまだましな方。PCと同じアスペクト比でスマホも流用しているサイトもまだまだ多い。

    fig-03fig-04

  • これからのレスポンシブデザインは線から面へ・・そして空間設計

    単純にブラウザの横幅をブレークポイントで判別して、デバイス別に二種類の画像を表示させるという単純な設計ではスマホの魅力を引き出すデザインとは言えない。
    今、スマホはアスペクト比率が縦長にどんどん広がっている。発売当初は3：10程度だったアスペクト比が、今は1:2を超えるまで縦長のアスペクト比になってきた。PCはPCで曲面タイプの超横長のモニターが増え始めている。
    ほかにも、物理的にも折り畳み式のスマホも登場してきた。単純にPCのキービジュアルのアスペクト比をそのままで使うのではスマホの縦長のアスペクト比の魅力を活かすことは難しい。それは先ほどの参考図でも理解できるだろう。

    また、ヒーロー画像とコンテンツ画像もそうだ。これも役割によっても求めるアスペクト比が違ってくる。
    これはもう、サイトのページ構成、ちょっとカッコよく言えば、空間設計のためのレスポンシブデザインが必要ということ。
    つまりレスポンシブデザインはこれまでの横幅（つまり線）の単純な切り分けから、デバイスのアスペクト比（つまり面）を考慮したデバイスの魅力を引き出すデザイン（空間設計）が必要になってきたということだ。

実践

ヒーロー画像とコンテンツ画像の設定コード見本

  • ヒーロー画像とコンテンツ画像を切り分けて設定

    前章で説明した様に現在のレスポンシブデザインではヒーロー画像とコンテンツ画像を切り分けて設定する方向へシフトしている。ヒーロー画像は、PCでは横幅でデザインし、スマホでは縦長でデザインする。
    たとえば本サイトのヒーロー画像の場合、PCとスマホではアスペクト比が大きく変わる。コンテンツ画像はアスペクト比はほぼ同じだ。
    しかしコンテンツ画像は、両デバイスでアスペクト比は同じでもピクセル解像度に差がある。
    macユーザーを考慮するとPCもDPR2に対応しないといけなくなる。
    このデバイス別の解像度に応じたレスポンシブをPHPやJSでたとえば「iPhone SEだから2倍、iPhone 15だから3倍の画像を出す」と個別に判定するコードを記述するのは物理的に困難。
    そこでpicture要素とsrcset属性の出番となる。
    アスペクト比が同じ画像の場合はsrcsetを、アスペクト比が変わる場合はpicture要素を使う。
    まずは簡単な方のコンテンツ画像の設定を次の段落から。

コンテンツ画像の設定見本

  • 今はブラウザ（srcset）に任せるのが最も効率的で正確。

    今のブラウザは非常に高性能。srcsetを下記の様に記述することで自動的にデバイスに最適な画像を判断し表示する

    <!-- 最初のlow-res.jpgは、srcsetにブラウザが対応していない場合用、下の三種類のどれかでも可 -->
<img src="low-res.jpg"
 srcset="image-small.jpg 400w,
 image-med.jpg 800w,
 image-large.jpg 1200w"
 sizes="(max-width: 440px) 100vw, 300px"
 alt="サンプル画像">
<!-- 上の400w, 800wなどは画像の実際のサイズ -->
  • size属性で対応範囲を設定

    ここで重要なのがsize属性。size属性にブラウザの範囲を指定することで、ブラウザは最適な画像を判断してくれる。
    srcsetに記述した『デバイスの画面が440px以下は100vwの画像を表示、それ以外は300pxの画像を表示せよ』との指示を受けてブラウザは次の判断をする。
    デバイス幅100vwはiPhone14だから393pxだな、だけどピクセル解像度は3倍だから1179pxまで必要、用意してある画像で一番近いのは1200wだからimage-large.jpgを表示しよう。
    ということをやってくれる。
    PCの場合だと、横幅440pxより大きいから300pxを表示すればOKだなと判断する。
    う~む、実に賢い。

  • 画像タイプをwebpとavifの二種類用意するばあい、srcsetではなくpicture要素を使用。

    今だと画像タイプはwebpオンリーでいいようだが、先行するのが好きな人は、いやいやこれからはavifだという場合もあるだろう。
    その場合はsrcsetではできないので、picture要素を使う。
    ブラウザは上から判断していくので、使いたい画像を上から順番に記述する。

    <picture>
 <!-- AVIF -->
 <source
  type="image/avif"
  srcset="
  image_156.avif 1x,
  image_312.avif 2x">

 <!-- WebP -->
  <source
  type="image/webp"
  srcset="
  image_156.webp 1x,
  image_312.webp 2x">

 <!-- 最終フォールバック -->
  <img
  src="image_156.webp"
  width="156"
  alt="">
</picture>
  • avifとwebpどっちを選ぶ？？

    これは結構難しい。実際に試してみると、同じ品質でもavifが重くなったりすることもある。また、画像の内容によっても変わる。
    また、アイコン系だとそもそも変換できないこともある（ただのベタで出力されたり）。それから一番ネックに感じるのが、PCでも使ってみるとわかるが、今はavifは重い。将来は軽快になるかもしれないが。imageMagickの変換時間も倍くらい違う。
    なので意外とwebpだけで行くっていうのもありだと思う。

ヒーロー画像の設定見本

  • ヒーロー画像はデバイスによってアスペクト比が違うことが多いのでpicture要素を使用。

    レスポンシブデザインでアスペクト比を変えるデザインをアートディレクションと呼ぶらしい。
    基本はブラウザの横幅と対応画像を上から順番に記述していく。
    下記は当サイトのコードを簡略化したもの。

    <picture>
  <source 
    media="(min-width: 441px)" 
    srcset="/assets/shv/images/keyvisual_top.avif" 
    width="1920" 
    height="1151" 
    type="image/avif">
  
  <source 
    media="(max-width: 440px)" 
    srcset="/assets/shv/images/keyvisual_top_374.avif"
    width="966" 
    height="1839"
   type="image/avif">

  <img src="/assets/shv/images/keyvisual_top.webp" 
    width="1920" 
    height="1151"
    data-aspect= "1920/1151"
    fetchpriority="high"
    alt= "top  key visual by Yohiichiroh Kohtani | digivalley"
    style="max-width: 100%; height: auto;">
</picture>

アット
ルール

空間設計を考慮したレスポンシブデザインに必要なcontainer queriesと、media queriesのaspect-ratio

  • 折りたたみスマホ時代を考慮する「ハイブリッド」構成

    最初のほうでも軽く触れたように、折り畳み式スマホは2018年頃に登場し、7〜8年が経過した2026年現在でも日本でのマーケットシェアはまだ1%未満。世界的には0.6％となっている。
    しかし、今後、appleが参入するとかなり市場占有率も変わると思われる。その対策として早めにやっておくのもいいと思う。

    まさにそれにぴったりの仕様がmedia queriesにある。アスペクト比を設定できるaspect-ratioメディアフィーチャー。
    CSSのaspect-ratioと同じ名称だが違う。こちらは@media の条件分岐の中でビューポート（画面）の縦横比を指定する役割を持つ。

メディアクエリー（media queries）のaspect-ratio

  • メディアクエリーといえば、一昔前の技術のようだが

    今、CSSではmin()やclamp()が進み、メディアクエリは古臭いというイメージもあるが実は進化している。

    @media (min-aspect-ratio: 1/1)
    min-aspect-ratio: 1/1はアスペクト比が最低1、つまり1以上（1を含む）という意味。つまり正方形と横長のデバイスを指す。逆にmax-aspect-ratio: 1/1は縦長を意味する。
    不等号・不等値演算子も使える。aspect-ratio <= 1/1みたいに。
    用途はデバイスが「開いたか・閉じたか」という大きな状態を検知するのが一般的な使い方。

    運用の仕方だが、不等号・不等値演算子が使えるので正方形を含む横長とそれ以外という記述をする。
    これまでのmax-widthなんかの使い方と同じだ。
    逆を言えば、注意する点はmin-aspect-ratio: 1/1とmax-aspect-ratio: 1/1を併記すると正方形のデバイスをどっちも含んでしまうってこと。まあ、あとの記述が上書きするので問題ないといえばないが、なんか気持ち悪いよね。
    なので次のように不等号・不等値演算子を使って設定するのがスマートだ。

    /* 2026年仕様 */
@media (aspect-ratio <= 1/1) {
}

@media (aspect-ratio > 1/1) {
}


/*もちろん、横幅の範囲とも併用できる。*/
@media (width < 441px) and (aspect-ratio < 1/1){
}
  • 古いデバイスにも対応させたい

    不等号・不等値演算子に対応していないブラウザも対応する場合はデフォルトのスタイルを後からmedia queriesのaspect-ratioで上書きするように記述すればよい。

    /* デフォルト（正方形を含まない横長） */
.box{
	background: blue;
}

/* 正方形以下だけ上書き */
@media (max-aspect-ratio: 1/1) {
	.box{
		background: red;
	}
}

まさに『レスポンシブは線から面へ』を体現する メディアクエリ aspect-ratioのデモ

コンテナクエリー：Container Queries

  • コンテナークエリーは、パーツ単位のレスポンシブ

    コンテナクエリは親要素とその子孫との関係で成立する。
    デバイスの横幅が375pxだろうが1920pxだろうが関係なく親の状態で子孫のスタイルを自動調整できる。
    つまり、左右のサイドバーを考慮する必要なしにコンテンツのレスポンシブ設定や、特定のコンテナだけをデザインすることが可能になる。
    これまでcalc(49vw - min(72vw, 980px)/2 - 108px)などと計算していたことが不要になるわけだ。

    ※コンテナクエリを使う親要素は、「自分のサイズが中身（子要素）の影響を受けない」 状態にする必要がある。
    そのため、基本的には inline-size（横幅のみ）を使い、高さはなりゆき（auto）にするのが安全な設計となる。
    が、高さが必要なケースもある。意外と便利なので、そのうち紹介する。

  • メディアクエリとの決定的な違い：スクロールバーの扱い

    @media: スクロールバーの幅を含んだ「窓のサイズ」で判定。
    @container: body に設定した場合、スクロールバーの幅を差し引いた「実際に表示可能な内側の幅」で判定。
    これにより、スクロールバーの有無でレイアウトがガタつく微細な計算ミスを防ぎやすくなる。

  • 専用の単位

    MDNによると下記の専用の単位がある。
    cqw: クエリーコンテナーの幅の 1%
    cqh: クエリーコンテナーの高さの 1%
    cqi: クエリーコンテナーのインラインサイズの 1%
    cqb: クエリーコンテナーのブロックサイズの 1%
    cqmin: cqi または cqb の小さい方
    cqmax: cqi または cqb の大きい方
    詳しくはMDNで調べて欲しい。下の方に記載してある。
    MDNによるコンテナクエリの専用単位の説明：https://developer.mozilla.org/ja/docs/Web/CSS/Guides/Containment/Container_queries

コンテナクエリーのサンプル

  • コンテナークエリーが活きてくる特殊なコンテンツ

    コンテナクエリは左右にサイドバーがある場合などは便利だというのは、特に説明はいらないと思う。
    なので、それ以外の特殊なコンテンツの時にこんなに便利だよ！というのを次に紹介する。

  • 「どこにでも置ける」マルチプレイス・コンテナ

    マルチプレイス＝どこにでも置ける、まさにそのままだね。爆！
    ECサイトの「商品カード」や、ニュースの「記事スニペット」のように、「サイト内のあらゆる場所（メイン、サイドバー、モーダル内、フッターなど）に置けて使い回し可能なコンテナ、ウィジェットともいうかな。

    何が特殊か 配置される場所によって、横幅やスタイルが自在に可変する（300px〜1200px）。
    コンテナクエリだから可能
    「サイドバー用のカード」「メイン用のカード」と作り分ける必要がなくなる。カード自身をコンテナにしておけば、サイドバー（狭い）に置かれたら自動で縦並び、メイン（広い）に置かれたら自動で横並びのレイアウトに変身。コンポーネントの完全な独立（カプセル化）が達成できる仕様。次がそのデモ。
    最もコンテナクエリっぽいデモ：https://labo.studio-happyvalley.com/container-query/card/

  • 「どこにでも置ける」マルチプレイス・コンテナのコードの解説

    前の段落で紹介したデモページを開発ツールでソースを調べながら、以下の解説を読むと理解しやすいと思う。

    primaryとsecondaryに全く同じCSSを設定したウィジェット(.card-container)を設置。
    自分(.ccard-container)が格納されている空間を把握し、狭ければ縦長に、余裕があれば横長にレイアウトを展開する

    /* さらに.card-containerの中にはテキストの他、画像を格納する.card-imageなどが配置されている */
.card-image {
  background: #ffffff;
  color: rgb(90, 90, 90);
  font-size: 40px;
  text-align: center;
  padding: 0;
	aspect-ratio: 10/5;
}
.card-body {
  padding: 15px;
}

img{
	width: 100%;
	height: auto;
	baseline-shift: center;
	aspect-ratio: 10/5;
  object-fit: cover;
	object-position: top
}
  • コンテナ―テキストの宣言

    primaryとsecondaryの幅に応じて直下の.card-containerの幅も変わる。
    その.card-containerにコンテナテキストを設定しコンテナの宣言をする。

    .card-container {
  container-type: inline-size; /* 横幅を監視対象にする、という宣言 */
  width: 100%;
}
  • コンテナクエリを設定する前準備

    この.card-containerの幅に応じて.cardのflexの方向を縦横へ変更する。
    まずデフォルトのスタイルを設定し、その後、コンテナクエリで上書きするようにする。

  • デフォルトの設定

    次にコンテナクエリで上書きする前提の共通のスタイルを設定する。
    サンプルは.cardだけを記載しているが、他の内包するオブジェクトも同じくスタイルを設定する。

    /* 2. 基本スタイル（コンテナの横幅が「狭い」ときの見た目：縦並び） */
.card {
  display: flex;
  flex-direction: column; /* 上下に並べる */
  background: #f5f5f5;
  border-radius: 8px;
  overflow: hidden;
  border: 1px solid #ddd;
}
/* .card-imageやimgも一緒に指定する */
  • コンテナクエリの設定

    いよいよ、コンテナクエリを設定する。

    /* 3. コンテナの横幅が「441px以上」になったときのスタイル：横並び */
@container (min-width: 441px) {
  .card {
    flex-direction: row; /* 横並びに変更！ */
  }

 /* .card-imageやimgも一緒に指定する */
}
  • まだまだ面白いサンプルはあるが

    と以上がコンテナクエリの基礎の解説。
    他にもいろいろ面白い設定があるが、それはまた別の機会に。

まとめ
と次回

これからのレスポンシブデザインは空間設計まで考える

  • 考慮すべきことが多い中で重要なのは、1.アスペクト比 2.ブラウザに任せる の二つ

    これまで解説してきたように、現在のレスポンシブデザインでは考慮すべきことが非常に多いと感じる。
    しかしシンプルに考えれば、その根底にあるのは1.アスペクト比であり、難しいことは2.ブラウザに任せる。この二つ。

    たとえば、折り畳みスマホを含むデバイス判別はアスペクト比で判別し、ヒーロー画像、コンテンツ画像はアスペクト比を同じにするか個別に最適化するか、DPR2～3とWEBPやAVIFへの物理的な技術対応は、ブラウザ任せにする。
    このようにシンプルに考えればかなり負担も減る。

  • 新しいレスポンシブデザインの考え方

    アスペクト比を考慮し、難しいことはブラウザに任せる、レスポンシブデザインは、もうこれで完成。のように見える。でもちょっと待って。

    考えて欲しい、現代のWebサイトはパーツ（コンポーネント）の組み合わせでできている。
    同じ「お知らせ情報」というパーツでも、メインの広い場所に置かれることもあれば、狭いサイドバーに置かれることもある。これは前の章で紹介したね。
    こういうことをコンテナクエリが登場するまでは、デバイスの画面幅だけを基準にデザインしようとしていたわけだ。
    コンテナクエリを触った後では、凄く無謀なことに思えるよね。

    コンテナクエリだと、デバイスの画面幅がどうであれ、そのパーツが置かれた「内側の部屋（コンテナ）」の広さに合わせて、狭ければ縦積みに、広ければ横並びに勝手に変身させることが可能だからね。
    これはコンテナクエリを使うことで空間まで把握したレスポンシブデザインが可能になるってことなんだよね。

    つまり、これからのレスポンシブデザインは、デバイスの幅（つまり線）という境界を乗り越え、アスペクト比（面ね）を踏まえて、さらにその先。デバイスによって空間がどう変化するかをパーツ自身に読み取らせ、それに合わせて自身の形状をどう変身させるか。そこまでを設計する方向へ向かっているってことなんだ。まさに、レスポンシブは線から面へ、そして空間へだね。しかも進行形。革命中だね。

  • Container Queriesの残りは？次のCSS革命の内容は？

    前章でもちょっと話したけど、container queriesについては特殊なコンテンツ用のコードや、横幅ではなく、高さを考慮する方法などちょっと特殊だけど革新的で面白い内容が多い。これらも近いうちにまとめて解説したいと思う。
    次？次こそはhas()疑似クラスを解説しようかと思う。爆！！

『レスポンシブは線から面へそして空間へ』関連のお薦め

このサイトで紹介しているコード、プログラムなどは個人の学習目的で作成されたものであり、いかなる保証も行いません。
利用はすべて自己責任でお願いします。
ただし、このページで紹介しているプログラムやビジュアルなどはご依頼いただければ実装を賜ります。
お問い合わせはこちら