ブレイクポイント早見表とファーストビュー設計 2026年版 迷わない基準と現場の落とし穴

ブレイクポイントって、気付くと増えます。増えた分だけCSSも増える。メディアクエリを追いかける時間が増えて、デザインの意図よりも条件分岐の都合が主役になっていく。あれ、これ誰のためのレスポンシブだっけ。そんな日が来ます。

一方でファーストビュー。ここも沼。見た目を盛るほど、読み込みは遅くなる。遅いと離脱される。でも地味だと刺さらない。悩みどころです。

この記事は、ブレイクポイントの早見表をただ置くだけじゃなく、ファーストビューを含めて「現場で迷いにくい決め方」をまとめます。僕の偏見も混ぜます。スパッと決めたい人向けです。

ブレイクポイントって何を分けているのか: 端末じゃなくレイアウトを分けたい

ブレイクポイントは、端末を分ける線ではありません。レイアウトが破綻する瞬間を分ける線です。iPhoneが何pxとか、iPadが何pxとか。もちろん目安にはなる。でもそれを基準にすると、端末が増えた瞬間に詰みます。

見出しが2行になった。カードが窮屈になった。ナビが折り返した。画像とテキストのバランスが崩れた。そういう「崩れ」を合図に線を引く。これが一番長生きします。

あなたのサイトの主要コンテンツは何ですか。ニュース一覧ですか。サービス紹介ですか。採用ですか。ECですか。そこによって崩れるポイントは全然違う。まずはレイアウトを見て決める。ここをサボると一生メディアクエリを増殖させる羽目になります。

2026年の現場感: 変わったのは端末より前提

画面は大きくなった。解像度も上がった。折りたたみも普通に入ってきた。だけど、レスポンシブの悩みの根っこは変わっていません。

変わったのは前提です。例えばこう。

• 100vhが信用できない場面が増えた(アドレスバーやツールバーの挙動)。
• ファーストビューに入れる情報が増えた(告知、追従、同意、バナー、検索)。
• 画像が重くなりがち(高解像度、WebP/AVIF、動画ヒーロー)。
• CSSで出来ることが増えた(container queries、clamp、subgridなど)。

なので、ブレイクポイントを「固定の線」として扱うより、コンテンツが勝手に伸び縮みする設計に寄せた方が安定します。メディアクエリは最後の補助輪。これが僕の好み。

ブレイクポイント早見表: よく使う目安を一気に並べる

先に早見表を出します。ここは迷った時の避難所として使ってください。万能ではありません。けれど、現場でよく当たる。

幅の目安(よくあるレンジ)

カテゴリ	目安(min-width)	よくある使い方
SP(小)	360px前後	最小構成の崩れ対策。ボタン幅、余白、見出し改行。
SP(標準)	375pxから390px	カード2列にしたくなる誘惑が出る帯域。だが大抵やらない方が良い。
SP(大)	414pxから428px	ヒーローの文字サイズを上げたくなる。行間で調整もあり。
Tablet	768px	2カラム開始の定番。ナビの見せ方が変わることが多い。
Small PC	1024px	ヘッダーのフルナビ復帰、3カラム、サイドバー復活。
PC	1280px	基本の完成形。FVの見え方、余白設計の主戦場。
Wide	1440px	コンテンツ幅固定か拡張かの分岐。背景演出も増える。
Ultra wide	1536pxから	中央寄せ固定で良いことが多い。伸ばし過ぎは事故る。

上の表は、分かりやすさを優先しています。実務で僕がよくやるのは、幅の種類を増やすより、コンテンツ幅と余白のルールを作ること。例えば、本文の最大幅を決めて、背景は伸ばす。あるいは、カードの最小幅を決めてグリッドで流す。そうするとブレイクポイントを減らせます。

ブレイクポイントのおすすめセット(少なめで戦う)

たくさん用意すると管理が破綻しやすい。なので、僕のおすすめはまずこれ。

• SP基準: 0から
• Tablet: 768px
• PC: 1024px または 1280px(案件のデザインに合わせて片方)
• Wide: 1440px(必要なら)

4本で足りることが多いです。足りないなら増やす。最初から増やさない。ここで差が出ます。

なぜ止める必要があるのか: ブレイクポイントのよくない癖

ここからが本題っぽい話。やめた方がいい癖があります。僕もやりがちです。

やめたい癖1: 端末名でブレイクポイントを決める

iPhone用、iPad用、みたいな命名。分かりやすいように見えて、未来に弱い。画面は増えるし、ブラウザのUIも変わる。レイアウトの崩れを見て決めた方が結果的に安定します。

やめたい癖2: 1px刻みで微調整する

1023pxだけ崩れる。だから1023pxだけ当てる。これをやると地獄が始まります。崩れの原因は本当に1pxですか。文字量、余白、最小幅、どれかの設計が怪しいことが多い。根っこを直した方が早い。

やめたい癖3: ブレイクポイントで全部を切り替える

SPはこの見た目、PCはこの見た目。二重実装に近くなると、修正が2倍になります。コンポーネントはできるだけ同じまま、流れだけ変える。幅のルールだけ変える。そういう寄せ方が強い。

やめたい癖4: 固定値だらけの設計

フォントも余白も幅も全部px固定。すると中間幅で不自然になります。clampやminmax、flexやgridの自動調整に任せられる部分は任せる。メディアクエリは最終手段に回す。僕はこっち派です。

やり方: ブレイクポイントを決める現場の手順

理想論だけでは動かないので、手順にします。忙しい人向けに短くいきます。

手順1: まず文章量が多いページで崩れを見る

トップよりも、一覧よりも、詳細ページ。ここが一番崩れます。採用詳細、ニュース詳細、コラム。文字が長いページをDevToolsで幅を動かして、崩れる幅をメモる。ここで一気に見えてきます。

手順2: カードやボタンに最小幅ルールを付ける

崩れの原因は「要素が潰れる」ことが多い。なら最小幅を決める。例えばカードならmin-width、ボタンならmin-inline-size、画像ならaspect-ratio。こういう土台があると、ブレイクポイントを増やさずに済む。

手順3: 行長を先に決める

本文が長いサイトなら、行長は武器です。日本語の本文が1行に詰まり過ぎると読めない。広過ぎると視線が迷う。max-widthを持たせる。ここを決めると、ワイド対応も落ち着きます。

手順4: 本当に必要な所だけメディアクエリで切り替える

ナビの折りたたみ。2カラム化。固定ヘッダーの高さ。FVの見せ方。ここだけで十分なことが多い。全部切り替えない。ここが大事。

min-width派かmax-width派か

僕はmin-widthのモバイルファースト寄りです。後から積み上げる方が直感的。CSSも増えにくい。max-widthはデザインがPC起点で固まっている現場だと楽な時もあります。どっちでもいい。統一だけはしてください。混ざると死にます。

CSS例: 破綻しにくいブレイクポイントの書き方

まずは定番。よくあるけど、これが一番強い。

:root {
  --content-max: 1120px;
  --gutter: 16px;
}

.container {
  max-width: var(--content-max);
  margin-inline: auto;
  padding-inline: var(--gutter);
}

@media (min-width: 768px) {
  :root { --gutter: 24px; }
}

@media (min-width: 1024px) {
  :root { --gutter: 32px; }
}

余白だけを変える。これだけでも体感はかなり整います。コンテンツを無理に広げない。背景や飾りだけ伸ばす。僕はこの設計が好きです。見た目が安定しやすい。

clampでフォントサイズと余白を自然に変える

ブレイクポイントでガクッと変えるのが嫌なら、clamp。これ、使いどころが多い。特にファーストビューの見出しに効きます。

.hero__title {
  font-size: clamp(24px, 4vw, 44px);
  line-height: 1.15;
}

.section {
  padding-block: clamp(40px, 6vw, 96px);
}

ここで質問。見出しを1段大きくしたいだけなのに、メディアクエリを足していませんか。clampで済むなら、その方が読みやすいです。

ファーストビューとは何か: 上から見える範囲だけじゃない

ファーストビューって言うと、ヒーロー画像とキャッチコピー。そこだけを想像しがちです。けれど、ユーザーが最初に見るのは「ページの空気」です。読み込みの速さ、文字の出方、ガタつきの有無、押せそうなボタンの存在。ここも含めてファーストビュー。

つまり、FVはデザインだけの問題じゃない。実装の問題です。むしろ実装で差が出る。ここが面白い所。

ファーストビューで起きがちな事故

• 画像が遅くて何も見えない時間が長い
• フォント読み込みで文字がガタッと動く
• 追従バナーが出てレイアウトがずれる
• ヘッダーが高過ぎて本文が見えない
• 100vhにしてアドレスバーで崩れる

これらは、ブレイクポイント設計とも絡みます。SPでヘッダーが2段になる。FVが消える。よくある。だからこそ、ブレイクポイントとFVはセットで考えた方が良い。

ファーストビュー設計のやり方: まず3秒の中身を決める

3秒。体感でいいです。最初の数秒で何を伝えるかを決める。そこから逆算する。キャッチか、価値か、導線か。全部載せたくなる。分かります。でも全部載せると重い。

FVに入れるものの優先順位

• 何のサイトか分かる要素(ロゴ、サービス名、1行説明)
• 次に押してほしい導線(CTA、検索、カテゴリ)
• 信用の材料(実績、受賞、導入社数、レビュー)
• 世界観(写真、動画、背景演出)

世界観を最優先にしがちですが、僕は導線派です。最初に迷わせない方が強い。特にコーポレート系は。

FVの高さはどう決めるか

SPで100vhを使うと、ブラウザUIの挙動でズレる場面があります。そこで最近は、dvhやsvh/lvhを使う選択肢も出てきました。とはいえ、万能ではない。なので僕の偏見としては、FVを画面にピッタリ合わせる執着を捨てるのが一番安定します。

例えば、上部にヘッダーがあり、FVは「見出し+サブ+CTA+画像」が収まるだけでいい。ピッタリ100vhにしない。余白で呼吸を作る。これで崩れが激減します。

ブレイクポイントとファーストビューが衝突する瞬間

よくあるのが、768px付近。タブレットで2カラムにした途端、FVの中身が詰まる。あるいは、ヘッダーがPCナビになった途端、タイトルが2行になって煩い。そんな時は、ブレイクポイントを変えるより、FVの設計を変えた方が早いことが多い。

衝突を避ける小技

• FVだけはclampで段階的に変える(メディアクエリの数を減らす)
• 画像は固定アスペクト比にして高さの暴れを止める
• ヘッダーの高さが増える幅では、FVの上下余白を減らす
• CTAは1つに絞り、2つ目は下に逃がす

もう一つ質問。PCで見た時に格好良いからといって、SPでも同じ情報量を詰め込んでいませんか。SPはスクロールが得意です。詰め込むより、分けた方が読みやすい。

メリット: きちんと設計すると何が得か

ブレイクポイントを減らすメリット

• CSSが読みやすくなる
• 修正の影響範囲が減る
• テストする幅が減る
• デザイン変更に強くなる

ファーストビューを整えるメリット

• 離脱が減りやすい
• CTAが押されやすい
• サイトの印象が上がる
• 社内で評価されやすい(これも現実)

特に最後。数字が出る前に評価されるのはFVです。ここは割り切って投資していい。僕はそう思っています。

デメリット: やり過ぎると起きる副作用

ブレイクポイントを少なくし過ぎるデメリット

• 中間幅で微妙な見え方が残ることがある
• デザインが端末別に厳密な案件だと揉めやすい
• コンポーネント設計が甘いと耐えられない

ファーストビューを盛り過ぎるデメリット

• 表示が遅くなり、逆に離脱が増える
• CLS(ガタつき)が起きてストレスになる
• 動画背景はスマホ回線で嫌われることがある

盛るなら、盛る代わりに削る。これがセットです。削らずに盛るのは、ほぼ破綻します。

実務のチェックリスト: ブレイクポイントとFVの見直し

忙しい人向けに、チェックだけ置きます。全部やらなくていい。気になる所からでOK。

ブレイクポイント側

• メディアクエリの数が増殖していないか
• 同じコンポーネントが幅ごとに別物になっていないか
• 余白と幅のルールが変数化されているか
• 中間幅(900px前後)で破綻していないか

ファーストビュー側

• 最初の表示でサイトの目的が分かるか
• 押すべき導線が迷わず見えるか
• 画像の読み込みで何もない時間が長くないか
• 読み込みでガタつきが出ていないか
• SPでヘッダーが邪魔していないか

読者に有益な追加ネタ: ブレイクポイントを減らす道具箱

最後に、ブレイクポイントに頼り過ぎないための武器をまとめます。これを使うと、CSSが落ち着きます。

1. Gridのminmaxで自動的に段組みさせる

.cards {
  display: grid;
  gap: 16px;
  grid-template-columns: repeat(auto-fit, minmax(240px, 1fr));
}

カードの最小幅を決めるだけ。後は自動。メディアクエリが減ります。気持ちいい。

2. 画像はaspect-ratioで高さの暴れを止める

.thumb {
  aspect-ratio: 16 / 9;
  width: 100%;
  object-fit: cover;
}

FVでも一覧でも効きます。読み込み中に高さが確保されるので、ガタつきが減る。地味に強い。

3. コンテナクエリでコンポーネント単位に切り替える

ページ全体の幅ではなく、親コンテナの幅で切り替える考え方。これがハマると、ブレイクポイントをページから切り離せます。管理画面や複雑なレイアウトで特に効く。対応状況や設計方針は案件次第ですが、選択肢として覚えておくと武器になります。

4. FVは軽量化もセットにする

画像の形式(AVIF/WebP)、遅延読み込み、preload、フォントの読み込み。ここは別記事級ですが、FVをやるなら避けて通れない。見た目と速度はトレードオフになりやすいので、最初からセットで設計する方が楽です。

ブレイクポイントは、増やすのは簡単です。減らすのが難しい。ファーストビューは、盛るのは簡単です。整えるのが難しい。だから面白い。