ブレイクポイント

概要と技術的な仕組み

レスポンシブデザインにおいて、PC・タブレット・スマホなど、画面サイズに合わせてレイアウトが切り替わる「画面幅の境界値」のこと。

CSS の「メディアクエリ（max-width や min-width）」という技術を使って設定する。たとえば「767px 以下はスマホレイアウト、768px 以上は PC レイアウト」のように、このピクセル数（ブレイクポイント）を境にデザインの表示ルールを切り替える。

現場のリアル：ブレイクポイントの「決め方」

業界の一般的な目安は、スマホ（〜767px）・タブレット（768px〜1024px）・PC（1025px〜）の 3 段階が主流だが、より実戦的なのは「自社の実データ」をベースに決めること。

GA4 等のアクセス解析で、自社ユーザーが多く使っている代表的な画面サイズ（解像度）を確認し、そこを境界に置くほうが実際の運用に効く。一般論だけで決めると、「自社の主要顧客が使っている特定のタブレットサイズだけ、表示が中途半端に崩れる」といった事故が起きやすい。

業者折衝における最重要ポイント（コストとの関係）

制作側と話すときの最大の論点は「いくつのブレイクポイントで組むか」である。

ブレイクポイントが多すぎると、その数だけデザイン制作・コーディング・保守の工数（＝見積もりコスト）が膨れ上がる。逆に少なすぎると、中間幅のデバイスでレイアウトが破綻する。中小企業のコーポレートサイトなら 2〜3 個で十分、EC や大規模サイトなら 4〜5 個まで増やす、というのがコストと品質の現実的な落としどころとなる。

実務でのテスト（QA）と落とし穴

スマホファーストの理解：もう一つの議論が「PC 基準で作るか、スマホ基準で作るか」。現在の Web 制作では、コードの書き順として「min-width（〇〇px 以上ならこのスタイル）」を使う「スマホファースト」が主流であることを知っておくと業者と話が通じやすい。
直前・直後のチェック：納品時のテストでは、必ずブレイクポイントの「直前・直後の幅」で意図通りにレイアウトの切り替えが起きているかを確認する。（※ Google Chrome の「検証モード」にあるデバイスツールバーを使えば、PC 上で 1px 単位で画面幅を動かしてテストできる）。
【要注意】ヘッダー崩壊の罠：現場で最もよく起きる落とし穴が「タブレット幅などの中間サイズで、PC 用の横並びメニューが画面に入りきらずに改行・重なりを起こす」という事故。スマホ用の「ハンバーガーメニュー」に切り替わるタイミングが適切か、必ずチェックすること。

言葉をよく利用する人

コーダー / フロントエンドエンジニア
デザイナー
Web 担当者(発注側)
ディレクター

会話上での使用例

レスポンシブ設計のブレイクポイントを業者と決める場面

業者ディレクター
ブレイクポイントは768pxと1024pxの2段階で組む案でいかがでしょう。
Web担当者
基本はそれでいいと思います。ただ、うちのアクセス解析を見ると横800から900pxのタブレット流入が結構あって。900px付近にもう1つ足してもらえますか。
業者ディレクター
了解です。実データがあるなら、そこに合わせた方が確実ですね。

タブレット幅で表示が崩れているのを見つけた場面

Web担当者
iPadの横画面で見ると、メニューが折り返って崩れてしまっています。
コーダー
確認します。ブレイクポイントが768pxと1280pxの間で抜けていますね。中間の1024pxにもう1つ足して、タブレット用のレイアウトを作ります。
Web担当者
よろしくお願いします。切り替わる前後の幅も実機で確認しておいてもらえると助かります。