デザイン

スマホの画面幅は何px?CSSで使う基準値とブレイクポイントの決め方

この記事の対象: スマホ向けのレイアウト幅やブレイクポイントを何pxで組むか決めたいWeb制作者
読了時間: 約9分

スマホの画面幅をCSSで扱うときの答えは、特定の数字を前提にしないことです。デザインの基準幅として1枚だけカンプを作るなら375pxか390px、CSSは320px〜1600pxで連続して成立させる、ブレイクポイントは2〜3本だけ置いて端末の実寸には合わせない。この3つで実務は通ります。以下では、その結論に至る理由と実際に書くコードを順に示します。「画面幅」という言葉が3つの別の数字を指していること、ブレイクポイントをレイアウト側から決める手順、Soreiine!!ギャラリー掲載サイトが実際にどう幅を扱っているかまで踏み込みます。


スマホ画面幅の結論:CSSに書く数字はこの3つだけ

先に実装の答えをまとめます。細かい理由は後ろの見出しで追いますが、迷ったときはこの表のとおりに書けば破綻しません。

用途 使う値 書き方
デザインの基準幅 375px または 390px カンプを1枚だけ作るときの幅。CSSには書かない
レイアウトの下限 320px ここで横スクロールが出なければ合格
ブレイクポイント 600px / 1024px 端末名ではなく、レイアウトが崩れる幅から決める

そして、CSSのコードに実際に書くのはこの形です。

/* コンテナ:幅は「上限」だけ決めて、あとは流す */
.container {
  width: min(100% - 2rem, 1200px);
  margin-inline: auto;
}

/* 並べ物:ブレイクポイントを書かずに済ませる */
.cards {
  display: grid;
  gap: 24px;
  grid-template-columns: repeat(auto-fit, minmax(280px, 1fr));
}

この2ブロックで、スマホ幅のレイアウトの7割は片付きます。min() と auto-fit はいずれも主要なモダンブラウザで広くサポートされており、現行のChrome・Safari・Firefox・Edgeであれば条件なしで採用できます。

以降は、なぜ「390px」をCSSに書いてはいけないのか、残りの3割(ブレイクポイントと検証)をどう決めるかを順に解きます。


「スマホの画面幅」は3つの数字が混ざっている

検索結果で数字がバラバラなのは、書き手が別の数字を指しているからです。同じスマホでも、話している層が違えば数値は390にも1170にもなります。

物理解像度・デバイス幅・ビューポート幅

呼び方 何を指すか 例(縦向き)
物理解像度 パネル上のドット数 1170px
デバイス幅(CSSピクセル) CSSが1pxと数える単位での幅 390px
ビューポート幅 コンテンツを描ける実際の幅 390px(ただし変動する)

物理解像度とCSSピクセルの比が「デバイスピクセル比(DPR)」です。1170 ÷ 390 = 3 なので、この端末のDPRは3。画像を2倍・3倍で書き出すのはこの比のためで、レイアウトの幅には一切関係しません。width: 390px と書いたとき、ブラウザが見ているのは390のほうです。

CSSで扱うのはデバイス幅とビューポート幅の2つだけ。そして実装で基準にすべきなのは、後者のビューポート幅です。

CSSが見ているのはビューポート幅だけ

メディアクエリの max-width も、100vw も、% の親要素も、すべてビューポート幅を基準に計算されます。端末のカタログスペックではなく、そのときブラウザの表示領域が何pxかだけを見ています。

ここが実装でつまずく点です。ビューポート幅は端末ごとに固定ではなく、同じ端末でも状況で変わります。

  • スマホのブラウザで横向きにすると、セーフエリアの分だけ内側が狭くなる
  • PCブラウザで検証ツールを横に開くと、その幅ぶんだけ縮む
  • デスクトップのウィンドウを手で狭めれば、スマホと同じ幅になる

つまり「390pxはスマホの幅」ではなく、「390pxという幅のビューポートはスマホでも、狭めたPCでも起きる」が正しい理解です。CSSに端末名を持ち込むと必ず破綻するのはこのためです。

3つの数字の関係と、CSSが見ている層

物理解像度(1170px など)

  • 画像の書き出し倍率を決める
  • レイアウトには使わない

デバイス幅(390px など)

  • 端末のスペック表に載る値
  • 目安として知っておく

ビューポート幅(可変)

  • メディアクエリの判定対象
  • vw・%の計算の基準
  • CSSで扱うのはこれだけ

下の層ほどCSSに近く、上の層はレイアウトに直接関与しません。

図の下段だけがCSSの仕事の範囲です。上2つは「知っておく値」で、コードに書き込む値ではありません。

端末ごとの実寸と、よく使われるデバイス幅の一覧は別記事にまとめています。手元で数字を確認したいときはこちらを参照してください。

スマホサイズの基準はどれ?2026年に見るべき実寸と画面幅


画面幅を前提にせず組むCSSの書き方

幅の数字を書く場所はできるだけ減らす、が方針です。減らせば、端末が増えても直す場所がありません。

まず viewport のmetaを正す

幅の話はここから始まります。これが無いと、モバイルブラウザは980px前後の仮想ビューポートを勝手に作り、ページ全体を縮小表示します。

<meta name="viewport" content="width=device-width, initial-scale=1">

これだけで十分です。maximum-scale=1 や user-scalable=no を足す書き方が今も残っていますが、拡大操作を奪うのでアクセシビリティ上避けます。モダンブラウザの多くはこの指定を無視する傾向にあるため、入れても効かないうえに他の環境だけが不便になります。

対応ブラウザは全モダンブラウザ(Chrome / Safari / Firefox / Edge の現行版)で問題ありません。

幅は「上限」だけ決めて、あとは流す

スマホ幅のレイアウトは、幅を指定するのではなく「最大幅」と「左右の余白」だけを決めて、中身を流し込む形が壊れません。

.container {
  width: 100%;
  max-width: 1200px;      /* PCでの上限 */
  margin-inline: auto;
  padding-inline: clamp(16px, 5vw, 40px);
  box-sizing: border-box;
}

なぜこう書くのか。width: 100% と max-width の組み合わせは、ビューポートが何pxでも必ず収まります。左右の余白を clamp() にしているのは、狭い画面では16pxまで詰め、広い画面では40pxまで開いてほしいからです。固定値で padding: 0 20px と書くと、375px幅の端末で中身が窮屈になり、1440pxでは余白が足りません。

さらに短く書くなら、冒頭で挙げた min() の1行で済みます。

.container {
  width: min(100% - 2rem, 1200px);
  margin-inline: auto;
}

min() の中で「画面幅から左右1remずつ引いた値」と「1200px」を比べ、小さいほうを採用します。paddingを使わないので box-sizing の指定も不要です。

つまずきやすい点:100vw は横スクロールを生む

全幅のセクションを作るときに width: 100vw を使うと、縦スクロールバーが出ている環境で横スクロールが発生します。100vw はスクロールバーの幅を含むビューポート幅を返すためで、Windows版のChromeやFirefoxで特に目立ちます。

/* 避ける */
.fullwidth { width: 100vw; margin-left: calc(50% - 50vw); }

/* 置き換える */
.fullwidth { width: 100%; }                      /* 親がbody幅なら不要 */
.fullwidth { margin-inline: calc(50% - 50cqw); } /* コンテナ基準で逃がす */

モバイルだけ見ていると気づきません。スマホで 100vw が問題なく見えるのは、モバイルブラウザのスクロールバーが領域を占有しないからにすぎないので、PCのウィンドウでも必ず確認します。

文字サイズを幅に合わせて伸縮させる方法は、別記事で手順を追っています。


ブレイクポイントを何pxに置くか

ここが「スマホ 画面幅」でもっとも実務に効く論点です。端末の実寸を調べても、ブレイクポイントの答えは出てきません。

端末の幅に合わせないという判断

よくある失敗は、流通している端末のデバイス幅(375 / 390 / 414 / 430 など)をそのままブレイクポイントにすることです。この設計には2つの問題があります。

  1. 端末は毎年増えるので、合わせ続けると境界が増え続ける
  2. 境界と境界のあいだの幅が狭く、レイアウトの切り替わりが1端末ごとになる

代わりに見るのは「このレイアウトは何pxから崩れるか」です。カードを3列で並べたとき、1枚の最小幅が280pxで隙間が24pxなら、3列が成立する下限は 280×3 + 24×2 = 888px。この888が境界の候補になります。端末ではなく、自分のコンポーネントが答えを持っています。

ブレイクポイントの決め方の2つの立場

コンテンツから決める(推奨)

  • 崩れる幅を実測して境界にする
  • 境界は2〜3本で足りる
  • 新端末が出ても直さなくてよい
  • デザイン側と数字の根拠を共有できる

端末の実寸から決める

  • 390・414・430と境界が増える
  • 端末が出るたび見直しが必要
  • 端末名でしか説明できない
  • PCの狭いウィンドウで想定外になる

左側の立場に立つと、ブレイクポイントは「この案件のこのレイアウトにとっての数字」になります。他案件から数字をコピーする理由がなくなるのが利点です。

実務で置く本数は2〜3本

それでも初期の設計指針は必要なので、迷ったときの出発点を置きます。

境界 想定する環境 切り替える内容
〜599px スマホ縦 1カラム・ハンバーガー・縦積みのカード
600〜1023px スマホ横・タブレット 2カラム・余白を広げる
1024px〜 PC 3カラム以上・グローバルナビを展開
/* 基準はスマホ。追加で広い画面に足していく */
.cards { display: grid; gap: 24px; grid-template-columns: 1fr; }

@media (min-width: 600px) {
  .cards { grid-template-columns: repeat(2, 1fr); }
}
@media (min-width: 1024px) {
  .cards { grid-template-columns: repeat(3, 1fr); }
}

min-width で書き足していくのは、スマホのCSSを土台に置くためです。max-width で上から削る書き方と見た目は同じ結果になりますが、打ち消しのための記述が増え、スマホで読み込むCSSが重くなります。

境界を1本も書かずに済ませる手もある

カードを並べるだけのセクションなら、冒頭で挙げた auto-fit の形で済みます。カード1枚の最小幅を280pxと決めれば、入る枚数はブラウザが計算します。390pxのスマホでは1列、900pxでは3列。ブレイクポイントを書かないので、将来の端末幅にも勝手に追従します。

ただし auto-fit は列数を制御できないことが弱点です。「PCでは必ず3列」という指定がデザイン側から来ている場合は使えません。その判断を先にデザイナーと揃えておくと、実装がやり直しになりません。

PC前提の設計とスマホ前提の設計で何が変わるかは、別記事で整理しています。


ギャラリー掲載サイトの幅設計から読み取れること

Soreiine!!のギャラリーには業種ごとにサイトを分類して掲載しています。スマホでの表示を並べて見ると、幅の扱いに共通した判断が見えてきます。数字の正解ではなく、判断の型として参考になる部分を挙げます。

余白を削らず、要素を減らしている

スマホ幅で読みやすいサイトは、PCのレイアウトを縮小していません。左右の余白は16〜24px程度を保ったまま、その幅に収まらない要素を落としているのが共通点です。

差が出やすいのがホテル・旅館のサイトです。PCでは写真を画面いっぱいに敷き、文字を上に重ねる構成が多いのですが、スマホ幅では写真と文字を上下に分けている例が目立ちます。狭い幅で写真の上に文字を重ねると、写真の明度が場所によって変わって文字が読めなくなるためです。幅が足りないときに重ね構造をやめるのは、CSSの技術ではなくデザインの判断です。

文字の大きさを幅で落としていない

掲載サイトを横断して見えるもうひとつの傾向です。スマホ幅で本文の文字を小さくしているサイトはほとんどありません。16px前後を維持し、代わりに1行の文字数を減らしています。

幅が狭い → 文字を小さくして1行に入れる、という発想は読みづらさに直結します。狭い幅でやるべきは、文字サイズを守って行数を増やすことです。コーポレートサイトの掲載例でも、見出しだけは大きく動かし、本文は動かさない組み方が多数派でした。

情報密度の高いブロックは幅で畳んでいる

家電・PC・モバイルのカテゴリに掲載しているサイトは、この点が特に丁寧です。スペック表のように列数の多い要素を、スマホ幅でそのまま横に残しているサイトはありませんでした。見出し列と値を縦に積み直す、あるいは表全体を横スクロールの箱に入れるかのどちらかで、表の都合でページ全体の幅を押し広げている例が無いのが共通点です。

表を縦に積み直す場合は、セルに見出しを持たせる書き方が使えます。

@media (max-width: 599px) {
  .spec-table thead { display: none; }
  .spec-table tr { display: block; margin-bottom: 16px; }
  .spec-table td { display: flex; justify-content: space-between; gap: 16px; }
  .spec-table td::before { content: attr(data-label); font-weight: 700; }
}

td に data-label="重量" のように見出しを持たせておけば、縦積みにしても何の値かが分かります。横スクロールで逃がすより手間はかかりますが、スペックを読ませたいページではこちらが読みやすくなります。

操作要素の幅と高さを確保している

スマホ幅で最後に効くのが、押せるものの大きさです。掲載サイトのスマホ表示では、ボタンやメニュー項目に44px以上の高さを取っている例が大半でした。狭い幅でボタンを2つ横に並べると、1つあたりが指の幅を下回ります。

実装としては、ボタンを横並びにする条件を幅で切るのが素直です。

.actions { display: flex; flex-direction: column; gap: 12px; }
.actions > a { min-height: 48px; display: grid; place-items: center; }

@media (min-width: 480px) {
  .actions { flex-direction: row; }
}

480pxという数字は端末由来ではなく、「ボタン2つ + 隙間が窮屈にならない下限」から出した値です。ボタンの文字数が多い案件なら、この数字は上がります。


検証するときの手順

幅まわりを確認する段取りです。端末を並べて確認する必要はなく、ブラウザの幅を連続的に動かすほうが確実です。

幅の検証を4ステップで通す
最小幅で見る320pxまで縮めて横スクロールが出ないか確認
連続して広げる320→1600pxをゆっくり引き伸ばし崩れる幅を記録
実機で触るスクロールバー・セーフエリア・固定要素を確認
境界を調整記録した崩れる幅をブレイクポイントに反映

2番目の「連続して広げる」が要点です。特定の端末幅だけを確認すると、境界と境界のあいだで崩れている状態を見逃します。

最小幅に320pxを置くのは、現行で流通している端末のうち最も狭い層に相当するからです。ここで横スクロールが出なければ、それより広い幅はほぼ通ります。確認のポイントは次の3つに絞れます。

  • 長い英単語やURLがはみ出していないか(overflow-wrap: anywhere で対処)
  • テーブルが幅を押し広げていないか(親に overflow-x: auto を付ける)
  • 固定幅の画像が残っていないか(img { max-width: 100%; height: auto; } を基本に)

読み込み中の見せ方まで含めて幅を詰めたいときは、スケルトンの実装も合わせて確認してください。


よくある質問

スマホの画面幅は結局何pxで考えればいいですか

デザインのカンプを1枚だけ作る場合の基準幅は375pxか390pxが扱いやすく、この幅で成立するレイアウトは他の端末幅でも破綻しにくくなります。ただしCSSを書くときは特定の数字を前提にせず、320pxから1600pxまで連続して成立するように組むのが正解です。基準幅はデザインの話、CSSの幅は可変の話として分けて扱います。

ブレイクポイントは何本必要ですか

多くの案件では2〜3本で足ります。スマホ縦(〜599px)・タブレット(600〜1023px)・PC(1024px〜)の3段に分けるのが出発点で、そこから案件のレイアウトが実際に崩れる幅を実測して調整します。端末の実寸ごとに境界を増やすと、端末が増えるたびに修正が必要になるので避けます。

100vw と 100% はどう使い分けますか

レイアウトの幅には 100% を使い、100vw は使わないのが安全です。100vw は縦スクロールバーの幅を含むため、PCブラウザで横スクロールが発生します。どうしてもビューポート基準が必要な場合は、コンテナクエリ単位の cqw に置き換えます。

user-scalable=no を入れてはいけないのですか

入れないほうがよいです。ユーザーの拡大操作を奪うためアクセシビリティ上の問題があり、現行のモダンブラウザの多くはこの指定を無視する傾向にあります。viewportのmetaタグは width=device-width, initial-scale=1 だけで十分です。

デバイスピクセル比はレイアウトに影響しますか

レイアウトには影響しません。デバイスピクセル比が関係するのは画像とCanvasの解像度だけで、CSSのpx指定やメディアクエリの判定には関与しません。2倍・3倍の画像を用意するのはこのためですが、幅の設計とは別の話として扱います。


まとめ

「スマホの画面幅」という問いは、CSSの立場からは「ビューポート幅をどう扱うか」に置き換わります。要点は3つです。

  • 物理解像度・デバイス幅・ビューポート幅を区別し、CSSではビューポート幅だけを見る
  • 幅の数字を書く場所を減らす。min() clamp() auto-fit で幅を流す
  • ブレイクポイントは端末の実寸ではなく、自分のレイアウトが崩れる幅から決める

端末は毎年増えますが、この3つを守った実装は更新が要りません。数字を追いかける設計から、幅に依存しない設計へ切り替えるのが、いちばん手戻りの少ない道です。