ブレークポイントは崩れから決める
ブレークポイントは、端末カテゴリの暗記ではなく、コンテンツが読みにくくなる瞬間を境に設定します。文章が詰まる、カードが細すぎる、ボタンが押しにくい、こうした変化点が設計の根拠です。
- 端末名を出発点にしない
- 「iPhone向け」「タブレット向け」ではなく、崩れた幅を観察して決めます
- 読みにくさを基準にする
- 行長、余白、タップ領域、画像の比率を確認して閾値を置きます
- 少ない本数で運用する
- 境界を増やしすぎると管理コストが上がるため、意味のある幅に絞ります
- コンポーネント単位でも考える
- ページ全体だけでなく、ナビ・カード・フォーム単位でも崩れを確認します
幅を縮めながら読みにくい瞬間を見つける
崩れた前後を3〜5px刻みでメモする
実機でも確認し、変化点前後を比較する
数値と根拠をCSSコメントに残して確定
一般的な参考値を目安にする
「崩れから決める」が原則ですが、観察の出発点として業界で広く実績のある幅の目安があります。これは暗記するための正解値ではなく、「この付近から観察を始める」という手がかりです。
この範囲は観察開始の目安です。実際の境界値はコンテンツの崩れ方を実測して最終決定します。
実測で閾値を決める手順
ここでは、カード一覧を例に「どの幅で2列にするか」を観察で決めます。開発者ツールで幅を少しずつ縮め、読みにくくなる境目を記録する流れです。
<section class="feature-grid">
<article class="feature-card">料金プランの比較</article>
<article class="feature-card">学習進捗の可視化</article>
<article class="feature-card">質問テンプレート集</article>
<article class="feature-card">作品ポートフォリオ</article>
</section> .feature-grid {
display: grid;
grid-template-columns: repeat(2, 1fr);
gap: 16px;
}
.feature-card {
padding: 16px;
border-radius: 12px;
background: #f0f9ff;
}
@media (max-width: 680px) {
.feature-grid {
grid-template-columns: 1fr;
}
} この例では、2列のまま幅を狭めるとカード内テキストが詰まり、読みづらい幅が出ます。その直前を境界として 680px 前後を候補にし、実機でタップしやすさも確認して最終決定します。
※プレビューの右下にあるアイコンをドラッグして、実際の画面幅を動かして切り替えを確認できます。
管理しやすいブレークポイントの書き方
実務では、数値が散らばると調整のたびに迷います。プロジェクトで意味を持った名前を使い、参照先を揃えると運用しやすくなります。
.page {
padding: 16px;
}
.card-grid {
display: grid;
grid-template-columns: 1fr;
gap: 12px;
}
/* 768px: 2カラム化できる幅 */
@media (min-width: 768px) {
.page {
padding: 24px;
}
.card-grid {
grid-template-columns: repeat(2, 1fr);
gap: 16px;
}
}
/* 1080px: 3カラム化できる幅 */
@media (min-width: 1080px) {
.page {
padding: 32px;
}
.card-grid {
grid-template-columns: repeat(3, 1fr);
gap: 20px;
}
} CSSの var() は media query 条件では使えないため、条件式の数値は明示で書くのが安全です。代わりにコメントで「なぜその幅か」を残し、設計ドキュメントにも対応表を持たせるとチームで迷いにくくなります。
- 幅の根拠を一緒に記録する
- 例として「680px: 2列カードの本文が詰まる境界」のように目的を残します
- コンポーネントごとの例外を明示する
- 全体基準と別に、特定UIだけ閾値が違う場合はコメントで理由を記録します
- 本数を増やしすぎない
- 主要な変化点に絞ると、修正時の比較テストが軽くなります
- レビュー時に崩れ観点を固定する
- 行長、余白、ボタンサイズの3点を毎回確認すると品質が安定します
一般的なUI例で考えるブレークポイント
ここでは、よく使うUIを3つに分けて考えます。カード一覧、ヘッダー導線、フォーム入力です。どれも「端末名」ではなく「崩れた瞬間」を境界にするのが共通ルールです。
- カード一覧
- 本文が窮屈になって読みにくくなる幅を境界にします
- ヘッダー導線
- ナビが折り返して迷いやすくなる幅を境界にします
- フォーム入力
- 入力欄が狭くなり、タップしにくくなる幅を境界にします
<form class="booking-form">
<label>
氏名
<input type="text" placeholder="山田 花子">
</label>
<label>
電話番号
<input type="tel" placeholder="090-1234-5678">
</label>
<label>
日付
<input type="date">
</label>
<label>
人数
<select>
<option>1名</option>
<option>2名</option>
<option>3名</option>
</select>
</label>
</form> .booking-form {
display: grid;
grid-template-columns: 1fr 1fr;
gap: 12px;
}
.booking-form input,
.booking-form select {
width: 100%;
padding: 10px;
} .booking-form {
display: grid;
grid-template-columns: 1fr;
gap: 16px;
padding: 16px;
border: 1px solid #dbe4ee;
border-radius: 16px;
background: linear-gradient(180deg, #ffffff 0%, #f8fbff 100%);
box-shadow: 0 10px 30px rgba(15, 23, 42, 0.06);
}
.booking-form label {
display: grid;
gap: 8px;
color: #0f172a;
font-size: 0.95rem;
font-weight: 700;
}
.booking-form input,
.booking-form select {
width: 100%;
min-height: 48px;
padding: 0 14px;
box-sizing: border-box;
border: 1px solid #cbd5e1;
border-radius: 12px;
background: #ffffff;
color: #334155;
font: inherit;
}
.booking-form input:focus,
.booking-form select:focus {
outline: none;
border-color: #14b8a6;
box-shadow: 0 0 0 4px rgba(20, 184, 166, 0.15);
}
@media (min-width: 760px) {
.booking-form {
grid-template-columns: repeat(2, minmax(0, 1fr));
gap: 16px;
}
} ※プレビューの右下にあるアイコンをドラッグして、実際の画面幅を動かして切り替えを確認できます。
設計判断の理由
- モバイル起点を採用する理由
- 狭い幅の制約を先に解くと、広い幅への拡張で崩れが再発しにくくなります
- 760pxを使う理由
- 実測で入力欄の詰まりが解消し、2列でもタップしやすい境界として安定したためです
- 1回で大きく変えない理由
- 余白と列数を段階的に変えるほうが、切り替え前後の違和感が小さくなります
よくある誤用パターン
- 端末名で境界を固定する
- 実際の崩れ幅と合わないため、観察結果を基準に再設定する
- 切り替え前後の差が大きすぎる
- 余白や文字サイズの変更量を抑えて段差を小さくする
- フォーム部品ごとの確認を省略する
inputとselectの高さ・タップ領域を別々に検証する
- 幅360pxで横スクロールなく入力できる
- 幅760pxで2カラムへ切り替わる
- 境界値の根拠をCSSコメントで確認できる
@media (min-width: 760px) で2列へ切り替え
運用で壊れにくくする観点
- 命名を責務で統一する
- 例として bp-card、bp-form のように用途で分類します
- 変更前の観察ログを残す
- どの幅で何が崩れたかを短文で必ず記録します
- 回帰テスト観点を固定する
- 行長、余白、タップ領域の3点を毎回確認します
- 例外値を増やしすぎない
- 一時的な値は期限付きで管理し、解消予定を明示します
理解度チェッククイズ
ブレークポイント戦略 ミニクイズ
まとめ
- 崩れを基準に閾値を決める
- 端末名ではなく、可読性と操作性が落ちる幅を境界にします
- 本数は必要最小限にする
- 意味のある変化点だけを選ぶとメンテナンス性が上がります
- 根拠を記録して共有する
- 数値の背景を残すことで、将来の修正判断が速くなります
- コンポーネント単位で検証する
- ページ全体だけでなく、フォームやカード単位でも崩れを確認します