レスポンシブブレイクポイントの書き方｜決め方・実装ガイド

レスポンシブ ブレイクポイントは「768px」「1024px」に設定すればいいと思っていませんか？実は、すべてのWebサイトに当てはまる正解の数値はありません。ブレイクポイントは端末の種類ではなく、ナビゲーションやカード、コンテンツ幅などが窮屈になり、レイアウトを切り替える必要が生じる位置を基準に決めることが大切です。

実務では768pxや1024pxを出発点として使う方法もありますが、サイトの構成によっては600pxや900pxなど、別の数値が適している場合もあります。また、CSS GridやFlexbox、Container Queriesを活用すれば、メディアクエリを増やさずに柔軟なレイアウトを実現できるケースもあります。

この記事では、レスポンシブのブレイクポイントの決め方から、CSS・SCSSでの実装、Figmaを使ったレスポンシブ設計、SEOを意識した注意点まで、実際のWeb制作で役立つ考え方を整理します。

レスポンシブのブレイクポイントはいくつ？推奨サイズ一覧

レスポンシブWebデザインのブレイクポイントに、すべてのサイトで使える「正解のpx」はありません。基本は、コンテンツが窮屈になったりレイアウトが崩れたりする画面幅を確認し、その境界にブレイクポイントを設定します。

実務で迷った場合は、768pxや1024pxなど、よく使われる値を出発点として検討する方法もあります。ただし、サイトのレイアウトやコンテンツによって適切な位置は変わります。

例えば、次のような構成が考えられます。

これはあくまで構成例です。例えば、768pxではまだナビゲーションが収まらない場合は800pxにしたり、600px程度でもレイアウトを切り替える必要がある場合は600pxを設定したりします。

ブレイクポイントは「端末」ではなく「コンテンツ」で決める

ブレイクポイントを決めるときにありがちなのが、「iPhoneだから390px」「タブレットだから768px」のように、特定の端末サイズをそのまま基準にする方法です。

しかし、レスポンシブWebデザインでは、特定の端末に合わせてブレイクポイントを決めるのではなく、コンテンツが適切に表示できるかを基準にすることが重要です。

例えば、PC向けのナビゲーションが900pxでは窮屈になってしまうなら、1024pxまで待つ必要はありません。

@media (min-width: 900px) {
  .site-nav {
    display: flex;
  }
}

このように、実際のレイアウトに合わせて900pxを境界にすることもできます。

反対に、768pxになったからといって必ずタブレット向けレイアウトへ切り替える必要もありません。

つまり、ブレイクポイントは次のように考えると分かりやすくなります。

• ブレイクポイント：CSSのレイアウトを切り替える境界
• ビューポート幅：ブラウザで実際に利用できるCSS上の表示幅
• 検証サイズ：レイアウトが正しく表示されるか確認するための画面幅

この3つは同じものではありません。

よく使われる768px・1024pxは「目安」として利用する

ブレイクポイントを一から決めるのが難しい場合は、768pxや1024pxを最初の候補として利用できます。

例えば、次のような3段階の構成です。

〜767px       モバイル
768px〜1023px タブレット
1024px〜      PC

この構成は、モバイル・タブレット・PCで大きくレイアウトを切り替えたい場合に分かりやすい方法です。

ただし、768pxと1024pxに技術的な必然性があるわけではありません。

例えば、カードを3列で表示するには900pxあれば十分なら、1024pxまで待つ必要はありません。

〜599px       1列
600px〜       2列
900px〜       3列

という設計でも問題ありません。

また、GridやFlexboxなどのCSS機能を活用すれば、細かな幅の変化をすべてメディアクエリで分岐させる必要もありません。

ブレイクポイントを増やしすぎないことも重要

ブレイクポイントは多ければ多いほど柔軟になるわけではありません。

例えば、

576px
768px
992px
1200px
1400px

のように細かく設定すると、画面幅ごとの調整はしやすくなる一方で、CSSの管理が複雑になりやすくなります。

そのため、まずは大きなレイアウト変更だけをメディアクエリで制御し、カード一覧などの細かなレイアウトはCSS GridやFlexboxで柔軟に対応する方法がおすすめです。

例えば、次のようなCSS Gridなら、固定したブレイクポイントを設定しなくても、コンテナの幅に応じてカードの列数を自動的に調整できます。

.card-grid {
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(280px, 1fr));
  gap: 24px;
}

このように、「メディアクエリで切り替える部分」と「CSSの標準機能で自動調整する部分」を分けることで、ブレイクポイントの増加を抑えられます。

実務では「壊れる幅」を確認して決める

実際にブレイクポイントを決めるときは、まずデザインや実装を確認しながら、どの幅でレイアウトに問題が発生するかを確認します。

例えば、

1. モバイル幅でレイアウトを作成する
2. ブラウザ幅を少しずつ広げる
3. ナビゲーションやカードが窮屈になる位置を確認する
4. 必要な箇所にブレイクポイントを設定する
5. ブレイクポイントの前後で表示を確認する

という流れです。

重要なのは、「768pxだから切り替える」のではなく、「この幅ではレイアウトが窮屈になるから切り替える」という考え方です。

最初の候補として768pxや1024pxを利用し、実際のコンテンツに合わせて調整すると、必要以上にブレイクポイントを増やさずにレスポンシブ対応を進められます。

CSS・SCSSでのブレイクポイント（メディアクエリ）の書き方

レスポンシブ対応では、CSSの@mediaルールを使って、画面幅に応じてレイアウトや文字サイズ、余白などを切り替えます。

基本的な書き方は次のとおりです。

/* 768px未満を基本スタイルにする */
.card {
  padding: 16px;
}

/* 画面幅が768px以上になったら変更 */
@media (min-width: 768px) {
  .card {
    padding: 24px;
  }
}

/* 画面幅が1024px以上になったらさらに変更 */
@media (min-width: 1024px) {
  .card {
    padding: 32px;
  }
}

このように、基本となるスタイルを用意したうえで、必要な幅だけ@mediaで上書きすると、ブレイクポイントを整理しやすくなります。

CSS @media アットルール - CSS | MDN

@media は CSS のアットルールで、1 つまたは複数のメディアクエリーの結果に基づいて、スタイルシートの一部を適用するために使用することができます。これによってメディアクエリーを指定し、そのメディアクエリーがコンテンツの使用される端末に一致する場合にのみ、文書に CSS のブロックを適用することができます。

developer.mozilla.org

Mobile Firstならmin-widthを基本にする

レスポンシブCSSでは、Mobile Firstの考え方としてmin-widthを使う書き方がよく採用されています。

/* モバイル */
.container {
  padding: 16px;
}

/* 768px以上 */
@media (min-width: 768px) {
  .container {
    padding: 24px;
  }
}

/* 1024px以上 */
@media (min-width: 1024px) {
  .container {
    padding: 32px;
  }
}

この方法では「小さい画面を基本にして、画面が広くなったらスタイルを追加する」という構造になります。

一方で、max-widthを使って大きな画面向けのスタイルから小さな画面向けに調整する方法もあります。どちらが正解というわけではありませんが、プロジェクト内で記述方法を統一しておくことが重要です。

ブレイクポイントは必要な箇所だけ設定する

ブレイクポイントを増やせば、細かな画面幅まで調整できます。しかし、画面幅ごとに大量のメディアクエリを追加すると、CSSの管理が複雑になります。

たとえば、

@media (min-width: 600px) {
  /* ... */
}

@media (min-width: 768px) {
  /* ... */
}

@media (min-width: 900px) {
  /* ... */
}

@media (min-width: 1024px) {
  /* ... */
}

@media (min-width: 1200px) {
  /* ... */
}

のように、明確なレイアウト上の理由がないままブレイクポイントを増やすのは避けたほうが管理しやすくなります。

「iPadだから768px」「PCだから1024px」と決めるのではなく、実際のレイアウトを確認し、コンテンツが窮屈になる幅でブレイクポイントを設定するのが基本です。

また、GridやFlexboxを活用すれば、メディアクエリを追加しなくても幅に応じてレイアウトを変化させられる場合があります。

たとえば、CSS Gridなら次のように書けます。

.card-list {
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(280px, 1fr));
  gap: 24px;
}

この場合、カードの最小幅を280px程度に保ちながら、利用できる幅に応じて列数を変化させられます。

そのため、すべてのレイアウト変更をメディアクエリで指定するのではなく、CSSのレイアウト機能で対応できる部分と、メディアクエリが必要な部分を分けることがポイントです。

メディアクエリの範囲を明確にする

特定の幅だけにスタイルを適用したい場合は、min-widthとmax-widthを組み合わせることもできます。

/* 768px以上、1023px以下 */
@media (min-width: 768px) and (max-width: 1023px) {
  .navigation {
    /* タブレット向け */
  }
}

ただし、ブレイクポイントを増やしていくと範囲指定も複雑になりやすいため、基本的にはmin-widthを使って段階的にスタイルを追加する方法が管理しやすいケースが多くあります。

また、現行ブラウザではメディアクエリの範囲構文を使って、次のように書くこともできます。

@media (768px <= width < 1024px) {
  .navigation {
    /* 768px以上、1024px未満 */
  }
}

プロジェクトで採用する場合は、対象ブラウザやチームのコーディングルールに合わせて記法を選択するとよいでしょう。

SCSSでブレイクポイントを管理する

SCSSを使う場合は、ブレイクポイントを変数やMapにまとめておくと、複数のコンポーネントで同じ値を使いやすくなります。

たとえば、Dart Sassでは@useを使ってSassのMap APIを読み込み、次のように管理できます。

@use "sass:map";

$breakpoints: (
  tablet: 768px,
  desktop: 1024px,
);

@media (min-width: map.get($breakpoints, tablet)) {
  .container {
    padding: 24px;
  }
}

@media (min-width: map.get($breakpoints, desktop)) {
  .container {
    padding: 32px;
  }
}

さらに、Mixinにまとめると記述を簡略化できます。

@use "sass:map";

$breakpoints: (
  tablet: 768px,
  desktop: 1024px,
);

@mixin mq($breakpoint) {
  @media (min-width: map.get($breakpoints, $breakpoint)) {
    @content;
  }
}

.container {
  padding: 16px;

  @include mq(tablet) {
    padding: 24px;
  }

  @include mq(desktop) {
    padding: 32px;
  }
}

この方法なら、ブレイクポイントの値を変更するときもMapの定義を変更するだけで済みます。

ただし、SCSSを使うからといって、必ずMixinやMapを導入する必要はありません。小規模なサイトでは通常のCSSと同じように@mediaを直接記述したほうが分かりやすい場合もあります。

ブレイクポイントを共通化する必要があるかどうかは、プロジェクトの規模やCSSの構成に合わせて判断することが大切です。

ブレイクポイントは実機・ブラウザ幅で確認する

ブレイクポイントを決めたら、設定した数値だけを確認するのではなく、その前後の幅でもレイアウトを確認します。

たとえば768pxをブレイクポイントにした場合は、

• 767px
• 768px
• 769px

だけでなく、スマートフォンの実際の表示幅やタブレット、PCなどでも確認します。

特に確認したいのは、次のようなレイアウトの崩れです。

• 見出しが不自然に折り返されていないか
• ボタンやナビゲーションが窮屈になっていないか
• カードの横幅が狭くなりすぎていないか
• 画像がコンテンツからはみ出していないか
• 横スクロールが発生していないか
• 余白が広すぎたり狭すぎたりしないか

この確認を行うことで、「端末の種類に合わせてブレイクポイントを決める」のではなく、実際のレイアウトに必要な位置でブレイクポイントを設定することができます。

効率的なレスポンシブ設計とFigma連携の実践フロー

レスポンシブサイトを効率よく制作するには、CSSを書き始めてからブレイクポイントを決めるのではなく、デザイン段階から画面幅による変化を整理しておくことが重要です。

Figmaでは、Auto LayoutやVariablesなどを活用しながら、どの要素が幅に応じて変化するのかを整理できます。

ただし、Figmaの設定だけでレスポンシブCSSが自動的に完成するわけではありません。

Figmaでレスポンシブな設計意図を整理し、実装時にCSSのGrid・Flexbox・メディアクエリなどへ落とし込むという考え方が基本です。

まずデザイン上の変化を整理する

レスポンシブ対応では、最初に「画面幅が変わったときに何が変化するのか」を整理します。

たとえば、次のような変更が考えられます。

ここで重要なのは、すべての要素にブレイクポイントを設定することではありません。

たとえばカード一覧なら、CSS Gridのauto-fitやminmax()を利用することで、画面幅に応じて列数を自然に変化させられる場合があります。

.card-list {
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(280px, 1fr));
  gap: 24px;
}

一方、モバイルではナビゲーションをハンバーガーメニューに切り替えるなど、明確にレイアウトやUIが変わる部分にはメディアクエリを使います。

つまり、「すべてをブレイクポイントで切り替える」のではなく、CSSのレイアウト機能で吸収できる部分を先に整理することがポイントです。

FigmaのAuto Layoutで可変部分を設計する

Figmaでは、Auto Layoutを使って要素間の余白や配置ルールを設定できます。

たとえばボタンでは、固定幅を設定するのではなく、テキスト量に応じて幅が変化するように設計できます。

このように、コンテンツ量に応じて自然にサイズが変わる設計にしておくと、異なる画面幅への展開を考えやすくなります。

カードやナビゲーションなどでも、固定値を増やすのではなく、Auto Layoutによる余白・配置・サイズ変更のルールを整理しておくと、実装時に必要なCSSを判断しやすくなります。

ただし、FigmaのAuto LayoutとブラウザのCSSレイアウトは同じ仕組みではありません。

Figma上で正しく配置できたからといって、そのままCSSの挙動になるわけではないため、実装時にはFlexboxやGridなど、Webのレイアウトモデルに置き換えて考える必要があります。

VariablesとModesはデザイン値の切り替えに活用する

Figma Variablesでは、色・余白・フォントサイズなどのデザイン値を変数として管理できます。

さらにModesを利用すると、同じVariableに対して異なる値を設定できます。

たとえば、レスポンシブデザインで画面幅によって余白を変える場合、次のような設計が考えられます。

spacing-section

Mobile   → 32px
Desktop  → 64px

このように、デザイン上の値をまとめて管理しておくと、画面サイズごとのデザインルールを整理しやすくなります。

ただし、ModesはDesktop用のレイアウトとMobile用のレイアウト全体を自動的に切り替えるための機能ではありません。

ModesはVariablesの値をコンテキストに応じて切り替えるために利用し、実際のレスポンシブな構造や配置については、Auto Layoutやコンポーネントなどと組み合わせて設計します。

そのため、

• Variables → 色・余白・サイズなどの値を管理
• Modes → Variableの値をコンテキストごとに切り替える
• Auto Layout → 要素の配置やサイズ変化を設計
• Components → UIパーツを再利用・管理

というように、それぞれの役割を分けて考えると整理しやすくなります。

FigmaのデザインをCSSへ落とし込む

デザインが完成したら、Figmaの情報をそのままCSSへコピーするのではなく、デザインルールをCSSのレイアウトルールへ変換することを意識します。

たとえば、Figmaで次のようなカードレイアウトを設計したとします。

Desktop
┌──────┐ ┌──────┐ ┌──────┐
│ Card │ │ Card │ │ Card │
└──────┘ └──────┘ └──────┘

Mobile
┌──────────────┐
│     Card     │
└──────────────┘
┌──────────────┐
│     Card     │
└──────────────┘

これをCSSで実装する場合、単純に「768pxになったら3列から1列へ変更する」という方法だけでなく、Gridのminmax()などを利用して、利用可能な幅に応じて列数を変化させる方法も検討できます。

.card-list {
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(280px, 1fr));
  gap: 24px;
}

一方、デザイン上「この幅を境にナビゲーションを切り替える」と明確に決まっている場合は、メディアクエリを利用します。

.navigation {
  display: none;
}

@media (min-width: 768px) {
  .navigation {
    display: flex;
  }
}

このように、Figmaで確認したデザイン上の変化を、そのまま固定的なブレイクポイントに置き換えるのではなく、CSSで最も適切な実装方法を選ぶことが大切です。

Dev Modeで実装に必要な情報を確認する

FigmaのDev Modeでは、デザイン上のサイズや間隔、カラー、Variablesなど、実装時に必要となる情報を確認できます。

たとえば、次のような情報を確認できます。

• 要素のサイズ
• 要素間の間隔
• カラー
• タイポグラフィ
• Variables
• レイアウトに関する情報
• コードに関する情報

ただし、Dev Modeから取得した値をそのままCSSに貼り付ければ完成するわけではありません。

たとえば、Figma上で24pxの余白が設定されていても、それがすべての画面幅で固定なのか、モバイルでは16pxに変更するのかを判断する必要があります。

また、Figmaで定義したVariableの名前や構造が、そのまま最終的なCSSの変数名やコードとして出力されるとは限りません。

実装者はデザインの値だけでなく、その値がどのようなルールで変化するのかまで確認することが重要です。

レスポンシブ設計から実装までの流れ

実際の制作では、次のような流れにするとブレイクポイントを必要以上に増やしにくくなります。

1. Figmaで画面幅ごとの変化を整理する

まず、モバイル・タブレット・PCなどで、どのUIが変化するのかを確認します。

2. Auto LayoutやVariablesでデザインルールを整理する

固定値を増やすのではなく、余白・サイズ・配置などのルールを整理します。

3. CSS Grid・Flexboxで可変部分を実装する

メディアクエリを追加する前に、CSSのレイアウト機能だけで対応できないか確認します。

4. レイアウトが破綻する幅を確認する

実際のブラウザで画面幅を変化させ、テキストの折り返しやカード幅、ナビゲーションなどを確認します。

5. 必要な箇所だけブレイクポイントを追加する

レイアウトの切り替えが必要になった場所に@mediaを追加します。

6. Figmaとブラウザの表示を比較する

最後に、主要な画面幅でデザインと実装を比較し、余白・文字サイズ・配置・UIの切り替えなどを確認します。

この流れなら、最初から「768px・1024px・1200px」とブレイクポイントを固定するのではなく、デザインと実装の両方を確認しながら必要なブレイクポイントを決めることができます。

SEOに強いレスポンシブ設計｜ブレイクポイントの決め方と注意点

レスポンシブ対応でSEOを意識する場合、「Googleが推奨するブレイクポイントは何pxなのか」と考えるかもしれません。

しかし、Googleが「768px」「1024px」といった特定の数値をSEO上の推奨ブレイクポイントとして示しているわけではありません。

重要なのは、どのブレイクポイントを採用するかという数値そのものではなく、スマートフォンを含むさまざまな画面幅でコンテンツを適切に表示できることです。

Googleはページエクスペリエンスの確認項目として、モバイルデバイス上でコンテンツが適切に表示されることや、Core Web Vitalsが良好であることなどを挙げています。

そのため、SEOを意識したレスポンシブ設計では、次のポイントを確認しましょう。

• モバイルでも主要なコンテンツを問題なく閲覧できる
• PCとモバイルで重要なコンテンツに大きな差を作らない
• 横スクロールやレイアウト崩れを発生させない
• 画像やレイアウトによる不要なレイアウトシフトを抑える
• ページの読み込みや操作性を妨げない
• 画面幅に応じて適切なレイアウトへ切り替える

Googleが特定のブレイクポイントを推奨しているわけではない

「SEOなら768pxと1024pxに設定すればよい」という考え方には注意が必要です。

768pxや1024pxはレスポンシブサイトでよく利用される数値ですが、Google検索で評価されるために、この数値を採用する必要があるわけではありません。

たとえば、次のようなサイトであれば、

スマートフォン
      ↓
    600px
      ↓
タブレット・小型PC
      ↓
    1000px
      ↓
デスクトップ

600pxや1000pxをブレイクポイントとして採用しても問題ありません。

重要なのは、サイトのコンテンツに合わせてレイアウトが適切に変化することです。

特に、ナビゲーションの項目数やカードの横幅、見出しの折り返しなどによってレイアウトが窮屈になる位置は、サイトごとに異なります。

そのため、「端末の種類」ではなく「コンテンツが崩れる位置」を基準にブレイクポイントを決めるのが基本です。

モバイルで主要コンテンツを適切に表示する

Google検索ではモバイル環境からアクセスするユーザーも多いため、スマートフォンでの表示を軽視できません。

レスポンシブ対応では、画面幅が狭くなったときに単純にコンテンツを小さくするのではなく、情報を読みやすく配置する必要があります。

たとえばPCでは、

┌──────────────┬────────┐
│              │        │
│ メインコンテンツ │ サイドバー │
│              │        │
└──────────────┴────────┘

としていたレイアウトを、モバイルでは、

┌────────────────┐
│ メインコンテンツ │
├────────────────┤
│ サイドコンテンツ │
└────────────────┘

のように変更します。

このようなレイアウト変更には、CSS GridやFlexbox、必要に応じてメディアクエリを利用します。

重要なのは、モバイル用に重要なコンテンツを削除してしまうことではありません。

PCとモバイルでコンテンツの構成を変更する場合は、検索ユーザーが必要とする情報が適切に利用できるかを確認しましょう。

Core Web Vitalsを意識した実装にする

レスポンシブ設計では、レイアウトの見た目だけでなく、ページの表示や操作性にも注意が必要です。

GoogleのCore Web Vitalsには、現在次の3つの指標があります。

GoogleはCore Web Vitalsをランキングシステムで使用していますが、良好なスコアを取っただけで検索順位が保証されるわけではありません。ページエクスペリエンス全体を改善することが重要です。

特にレスポンシブ実装では、画像や広告、動的に挿入されるコンテンツなどによってレイアウトが変化しないように注意します。

たとえば画像には、表示領域を確保しやすくするためにwidthやheight、またはaspect-ratioを設定できます。

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

ただし、ブレイクポイントそのものがCLSやLCPを悪化させるわけではありません。

問題になるのは、レスポンシブ実装に伴って不要なレイアウト変更や大きな画像の読み込み、複雑なCSS・JavaScriptなどが発生するケースです。

レスポンシブ画像も適切に使う

画面幅に応じて画像サイズを変える場合は、srcsetやpictureなどのレスポンシブ画像の仕組みも利用できます。

<img
  src="image-800.jpg"
  srcset="
    image-400.jpg 400w,
    image-800.jpg 800w,
    image-1200.jpg 1200w
  "
  sizes="(max-width: 767px) 100vw, 800px"
  alt="レスポンシブデザインのイメージ"
>

srcsetやsizesを使うことで、ブラウザが表示領域などを考慮して適切な画像リソースを選択しやすくなります。

アートディレクションが必要な場合は、picture要素を利用して画面幅に応じて画像そのものを切り替える方法もあります。

<picture>
  <source
    media="(max-width: 767px)"
    srcset="image-mobile.jpg"
  >
  <img
    src="image-desktop.jpg"
    alt="サービス紹介"
  >
</picture>

このように、レスポンシブ対応ではCSSだけでなく、画像の配信方法も画面幅に合わせて設計できます。

display: noneによるコンテンツの扱いに注意する

モバイルとPCで表示するUIが異なる場合、同じ内容をHTMLに2つ用意して、一方をdisplay: noneで隠す方法もあります。

ただし、この方法を多用するとDOMが複雑になり、CSSやJavaScript、アクセシビリティの管理が難しくなる可能性があります。

たとえばナビゲーションをPC用とモバイル用で別々に用意すると、

<nav class="navigation-desktop">
  ...
</nav>

<nav class="navigation-mobile">
  ...
</nav>

というように、同じ目的のUIを複数管理することになります。

そのため、可能であれば1つのHTML構造をCSSでレイアウト変更する方法を検討しましょう。

ただし、PCとモバイルで操作方法そのものが大きく異なるUIでは、別の構造が必要になるケースもあります。

重要なのは、SEO対策として無理に1つのHTML構造にすることではなく、コンテンツの重複やアクセシビリティ、保守性を考慮して実装方法を選ぶことです。

タップしやすいサイズと文字サイズを意識する

スマートフォン向けのレスポンシブ設計では、ボタンやリンクを指で操作しやすいサイズにすることも重要です。

たとえば、次のようにボタンの余白を確保します。

.button {
  display: inline-flex;
  align-items: center;
  justify-content: center;
  min-height: 48px;
  padding: 12px 20px;
}

48pxは実務で使いやすいタップ領域の目安として利用できます。

ただし、これは「Google SEOのために48pxが必要」という意味ではありません。アクセシビリティの基準には別の要件があり、WCAG 2.2のAAでは、Target Size (Minimum)として24×24 CSSピクセル以上などの基準が定められています。

また、本文の文字サイズを決める際も「16pxならSEOに有利」という考え方ではなく、読みやすさやユーザーの環境を考慮して決めることが大切です。

SEOを意識するなら「数値」より「表示品質」を確認する

レスポンシブ対応でSEOを考えるとき、最も避けたいのは「Google対策として768pxと1024pxを設定したから大丈夫」と考えてしまうことです。

ブレイクポイントの数値自体よりも、次のような状態になっていないかを確認しましょう。

• スマートフォンで横スクロールが発生していない
• 見出しや本文が読みやすい
• ナビゲーションを問題なく操作できる
• ボタンやリンクをタップしやすい
• 重要なコンテンツが画面外にはみ出していない
• 画像によるレイアウトシフトが発生していない
• モバイルでもページの主要な情報を確認できる
• PC・モバイルのどちらでも快適に閲覧できる

Googleもページエクスペリエンスについて、Core Web Vitalsだけに限定せず、モバイルでの表示、HTTPS、広告やインタースティシャルなどを含めて総合的に確認することを案内しています。

つまり、SEOに強いレスポンシブ設計とは、特定のブレイクポイントを採用することではなく、検索ユーザーがどの画面幅からアクセスしてもコンテンツを適切に利用できる状態を作ることです。

よくある質問（FAQ）

まとめ

レスポンシブのブレイクポイントには、すべてのWebサイトに当てはまる正解の数値があるわけではありません。

768pxや1024pxは実装を始める際の目安として使いやすい数値ですが、GoogleがSEOのために推奨している値ではありません。重要なのは、端末の種類や一般的なサイズだけで決めるのではなく、コンテンツやレイアウトが窮屈になったり崩れたりする位置を基準に設定することです。

最初から「768px」「1024px」とブレイクポイントを固定するのではなく、Figmaでデザインの変化を整理し、CSS GridやFlexboxなどで対応できる部分を見極めたうえで、必要な箇所だけメディアクエリを追加すると管理しやすくなります。

レスポンシブ設計で大切なのは、決められた数値に合わせることではなく、どの画面幅でもコンテンツを読みやすく、操作しやすい状態に保つことです。

あわせて読みたい

スマホのファーストビューサイズは何px？基準の幅・高さと設計

スマホのファーストビュー最適サイズを解説！375px・390pxの使い分けや高さ750pxの根拠など、失敗しないWeb制作の基準が分かります。

watashi.xyz

2025.08.06