提案書や仕様書に、たまにこういう一文が入っていることがある。
「ブレイクポイントは◯◯◯pxでお願いします」
そのたびに私は、この記述を消してもらうよう依頼することが多い。
理由は単純で、実装フェーズに入っていない段階で適切なブレイクポイントは決められないからである。
もちろん、デザイナーの頭の中にある前提が完全に正しく、提示されたブレイクポイントでも破綻しないレスポンシブが組めるのであれば問題はない。しかし、現実はだいたいこう。
- SP／PCのデザインカンプが2種類だけ渡される
- 「768px以上はPC、それ以下はSP」みたいに線引きが提示される
- そして実装してみると、どこかが広すぎたり、もしくは窮屈になったりして破綻する
よほどシンプルなデザインでない限り、これはほぼ確実に起きる。
なぜなら、“768px”という数字は、デザインの理想状態を保てる保証を何も持っていないからである。
ブレイクポイントをデザインの段階で決められない理由
そもそもデザインの段階で決められるブレイクポイントに根拠がない
典型的な流れはこう。
- デザインの段階で、ブレイクポイントを2〜5個選ぶ。多くの場合はトレンドのデバイスサイズや、古典的フレームワーク（Bootstrap / Tailwind 等）の値を参照する。例えば 1200px / 992px / 768px / 480px あたり。
- 実装でそれらをメディアクエリに埋め込み、レイアウトを切り替える
- その結果「レスポンシブになったことにする」
このやり方は、モバイル端末の種類が少なく解像度の幅も狭かった時代には機能していた。でも令和8年の現在は違う。
新規Webサイト案件で、ブレイクポイントは何にしますか？ なぜそのブレイクポイントを提示しましたか？
最初の問い（何にすべきか）には、適当な答えを返せるかもしれない。でも後半の「なぜ？」には、確実に答えられないだろう。
正確に答えようがないのは、どのブレイクポイントを選ぶべきかに「筋道」が存在しないからだ。
現代のWebは最適化対象が「数種類の代表デバイス」ではない。Set Studio が48時間かけて計測した調査「The ideal viewport doesn’t exist」では、約12万件のデータからユニークなビューポートのサイズが2,300通り以上見つかっている。さらに全員が全員画面いっぱいで表示しているわけではない。毎年「2026のブレイクポイント決定版はこれだ！」みたいな記事が出回るが、読まなくていい。
この辺りは昨年フロントエンドカンファレンス関西で話した「俺流レスポンシブコーディング 2025」のスライドを見てほしい。
コンポーネント指向では「置かれ方」が変わり続ける
今のWeb制作はアプリケーション開発と同様に、コンポーネントを前提にしている。
コンポーネントは「そのページのその場所」だけに置かれるとは限らない。
- 同じボタンがサイドバー、セクション内のカラム、フッターなどあらゆる箇所に入る
- 同じフォームが、本文、モーダル、ドロワーなどあらゆる箇所に入る
- 同じナビが、ヘッダー、オフキャンバスなどあらゆる箇所に入る
各コンポーネントは常に「自分以外のことは何も知らない」状態を目指す必要があり、置かれた先の利用可能スペースに適応する必要がある。
この前提に立つと、画面幅（ビューポート）だけを見て分岐するメディアクエリは、どうしても苦しくなる。
令和8年の現在において、メディアクエリはもう主役ではないということを意識した方が良い。
私はIE時代に「俺流レスポンシブコーディング」という記事を書いたことがあるが、当時はメディアクエリが主役だった。
デバイス幅を狙い撃ちし、レイアウトを微調整し、画面サイズに応じてデザインを操作するのがIE時代で最も適したアプローチだったから。
ただ、IEが滅び、CSSが絶え間なく進化した現在は状況が変化している。
- コンテナクエリが昨年 Baseline の Widely available になり、広く使用できるようになった
- コンポーネントごとにブレイクポイントを決められるようになった
- 「コンポーネント自身は外のことを何も知らない」という原則に対して、ビューポートに密結合する（＝外部に依存する）矛盾を減らせるようになった
要するに、レスポンシブの基準が「画面幅」から「利用可能スペース」へ移ったことで、全体ブレイクポイントを先に決めるという設計が古くなったということである。
誤解しないでほしいが、メディアクエリはオワコンになったわけではない。float が flex や grid の代替手段から「回り込みレイアウト」という正しい使い方に戻ったように、画面を基準にブレイクポイントを決める手段へと、使いどころが変わっただけである。
メディアクエリとコンテナクエリの解説は登壇のスライドを参照してほしいが、概ね以下の通りである。
- メディアクエリ：「画面はどれくらい大きい？」
- コンテナクエリ：「いまここに、どれくらいのスペースがある？」
この違いは些細な言い換えではなく、コンポーネント再利用を前提にした現代Webでは致命的に大きい。
フルリキッド化は悪手である
デザインの段階でブレイクポイントが固定されると、実装者が取りがちな行動がある。それは「全てをリキッドレイアウト化する」という方法。
デザインカンプは言わば「理想の表示」であり、その理想をあらゆる画面幅に強制できるリキッドはデザインを尊重するのであればアリのように思える。フルリキッドじゃないとデザインの価値観が通せない、というのであれば選択肢に入るかもしれない。
しかし、私はブレイクポイントが固定されたことへの解決策としてフルリキッド化を行うのは避けたいと思っている。理由はこう。
読みやすさは画面幅の縮小・拡大に負ける
例えば、1440pxのデザインカンプで本文が16pxだったとする。
1440pxでは読みやすいだろう。でも、それをそのまま縮小していくと、画面幅が狭いほど文字は読みにくくなる。
特に「768px以上はPCデザインをリキッドで流す」とすると、iPadでは文字が小さくなりすぎて最悪ピンチアウトしないと満足に読めないみたいな体験が普通に起こり得る。
もちろん、大型のスマートフォンでは逆に文字が大きすぎて読みにくいみたいなパターンもあるだろう。
vw はズームとの相性が悪い
フルリキッドでよく使われる vw は、ブラウザによってズーム挙動と噛み合わない。特にGoogle Chromeでは、vw だけで指定した文字はズームしても一切大きくならないため、アクセシビリティを阻害するリスキーな単位である。
もちろん、リキッドが全て悪いというわけではない。ヒーローヘッダーのような「局所的に気持ちよさを出す」箇所なら、リキッドは有効だと考えている。問題は、全体をリキッドにしてしまうことである。
リキッドレイアウトを組む場合は極力コンテナクエリ＋cqi のように、コンテナ基準で組むようにすれば、コンテナの幅に上限がある範囲では先述したズーム問題は起こらない。vw と cqi(cqw) の使い分けはメディアクエリとコンテナクエリの対比と同じである。つまり、コンポーネントにvwを持たせるのは極力避けたほうがいい。（※ただし、サイト全体の調和を優先するなら font-size には vw をベースとするのも選択肢ではある）
ただし、コンテナの幅が画面幅に連動している範囲では、cqi も vw と同じくズームしても大きくならない。文字サイズをリキッドにするときは、clamp() で rem の下限と上限を付け、ズームしたときに少なくとも rem の値までは文字が大きくなるようにしておく。具体的な組み方は「当ブログのレスポンシブコーディングについて」の「font-sizeはclamp()関数で指定する」で紹介している。
ブレイクポイントは実装段階でデザイナーと一緒に決めるべき
何を維持し、どこから崩れとみなすか
ブレイクポイントの決定の落とし所はこう。
- 何が維持されるべきか（優先順位）
- 文字の可読性？情報密度？画像比率？CTAの視認性？
- どこからが崩れなのか（許容範囲）
- 2カラムが1カラムになるタイミングの意図
- 余白を削ってよい順番
これらは実際に実装のフェーズを経ないと分からない。だから、実装段階でデザイナーと実装者が「ブレイクの是非」を密に擦り合わせることがベターな方法だと考える。
数値の代わりに書いてほしいこと
とはいえ、デザインの段階で何も決めなくていいわけではない。提案書や仕様書には、ブレイクポイントの数値の代わりに次のことを書いてほしい。
- 想定する最小幅と最大幅（コンテンツの幅の上限を含む）
- デザインカンプとデザインカンプの間の幅で守りたい状態（「ここは2カラムを保ちたい」など）
例えば、こう書いてもらえると実装者は迷わない。
「ブレイクポイントは実装段階で決める。コンテンツの幅は1200pxを上限とし、375pxまで崩れずに表示する。カード一覧は、カードの幅が280pxを下回らない範囲で列を増やす。」
まず分岐しない組み方を考える
ブレイクポイントを決める前に、そもそも分岐が要らないかを考えたい。グリッドの auto-fit と minmax()、フレックスボックスの flex-wrap を使えば、利用可能スペースに応じて列の数や折り返しが変わるので、ブレイクポイントを書かずに済むことが多い。
/* カードの幅が 280px を下回らない範囲で列を増やす */
.card-list {
display: block grid;
grid-template-columns: repeat(auto-fit, minmax(min(100%, 280px), 1fr));
gap: 1.5rem;
}
/* 入りきらなければ折り返す */
.tag-list {
display: block flex;
flex-wrap: wrap;
gap: 0.5rem;
}先ほどの文例の「カードの幅が280pxを下回らない範囲で列を増やす」は、この1行で組める。
分岐の方法も見直す
分岐が必要な場合は、その方法も現代的に見直す。
- 原則：コンポーネント、BEMにおけるBlockはコンテナクエリ
- 「置き場で変わる」ものは viewport 基準にしない
- 例外：ビューポートに密着しているもの、ページ全体のレイアウトはメディアクエリ
- モーダル、固定配置などの position: fixed な要素
- ページ全体のレイアウトはデザインカンプ≒ビューポートに依存するのでメディアクエリを使う
デザインの段階で「◯◯◯pxでお願いします」と書いてしまうのは、レスポンシブの前提を根拠のない数字で固定してしまう行為。だからデザインの段階でブレイクポイントを決定するのはやめてほしい。