この記事の対象: スマホ向けのデザインや実装で「画面のサイズ」としてどの数字を見ればいいか決めたいWeb制作者
読了時間: 約8分
結論から書きます。Web制作で使う「スマホの画面のサイズ」は表示領域のCSSピクセルです。レイアウトは幅のCSSピクセルで決め、ファーストビューの高さは 100dvh で組みます。検索して出てくるインチ数の一覧と解像度の一覧は、どちらもレイアウトの入力値になりません。この記事は4つの数字の見分け方と、手元の端末で全部まとめて実測する手順を先に置きます。
スマホの画面のサイズは、設計で使う数字が2つだけ
端末のスペック表、ブラウザの開発者ツール、デザインツールのアートボード。同じ端末を見ていても出てくる数字は一致しません。「サイズ」という一語が4つの別の数字を指しているからです。
| 呼び方 | 単位 | 誰が使う数字か | 制作で使うか |
|---|---|---|---|
| 物理サイズ | インチ（対角） | 端末を選ぶ人・ケースを作る人 | 使わない |
| 解像度 | デバイスピクセル | 画像を書き出す人 | アセットだけ |
| 表示領域 | CSSピクセル | デザインする人・CSSを書く人 | 使う |
| 実際に見える範囲 | CSSピクセル（可変） | ファーストビューを設計する人 | 使う |
判断材料になるのは下の2つです。表組みを見て終わりにできる話ではないので、上の2つが使えない理由を先に潰しておきます。
物理インチからレイアウトは決まらない
対角のインチ数は、縦横比が分からないと幅に変換できません。同じインチ数でも縦長の比率が違えば幅は変わります。さらに、同じ物理幅でも端末側の表示倍率（文字やアイコンを大きくする設定）でCSS上の幅は動きます。インチ数は「手に持ったときの体感の大きさ」を語るための数字です。
解像度は画像の書き出し倍率のための数字
解像度（デバイスピクセル）は、1 CSSピクセルを何個の物理ピクセルで描くかという比率、つまり devicePixelRatio とセットで初めて意味を持ちます。この値が2なら、横幅390 CSSピクセルで表示する画像は780px幅で用意する、という判断に使います。レイアウトではなくアセットの判断に使う数字です。
工程ごとに見る数字が違います。1枚の一覧表で全部を済ませようとすると、必ずどこかで噛み合わなくなります。
自分の端末の画面のサイズを調べる手順
一覧表を探すより、手元の端末で実測するほうが早くて確実です。4つの数字をまとめて出します。実機のブラウザのアドレスバーに javascript: は入らないので、検証用のHTMLに置いて開くか、PCとつないだリモートデバッグのコンソールに貼ってください。
// 実機のブラウザで実行して、4つの数字を同時に見る
const vv = window.visualViewport;
console.table({
'CSSピクセルの幅': window.innerWidth,
'CSSピクセルの高さ': window.innerHeight,
'今見えている高さ': vv ? Math.round(vv.height) : '-',
'画面の幅(screen)': window.screen.width,
'ピクセル比': window.devicePixelRatio,
'物理ピクセル幅': window.screen.width * window.devicePixelRatio,
});
コンソールにつなげない場面では、画面に直接書き出すほうが確実です。
<!-- 検証用。実機でこのファイルを開くだけで数字が見える -->
<pre id="vp" style="font:14px/1.6 monospace; padding:1em"></pre>
<script>
const render = () => {
const vv = window.visualViewport;
document.getElementById('vp').textContent = [
`innerWidth : ${window.innerWidth}`,
`innerHeight : ${window.innerHeight}`,
`visualViewport.h: ${vv ? Math.round(vv.height) : '-'}`,
`screen.width : ${window.screen.width}`,
`dpr : ${window.devicePixelRatio}`,
].join('\n');
};
render();
addEventListener('resize', render);
window.visualViewport?.addEventListener('resize', render);
</script>
resize を拾っているので、スクロールしてアドレスバーが縮んだ瞬間に innerHeight が変わるところまで目で見えます。ここが実機でしか確認できない部分です。動作はモダンブラウザ全般。visualViewport はオプショナルチェーンで逃がしてあります。
PCのChromeで開発者ツールのデバイスモードを使えば近い値は取れますが、アドレスバーの縮みとアプリ内ブラウザは再現できません。
実機で見るべきもの
- ファーストビューの高さ
- SNSのアプリ内ブラウザ
- セーフエリアの効き方
- フォーム入力時の見切れ
開発者ツールで足りるもの
- 幅の崩れ
- 折り返しと禁則
- 画像の書き出し倍率
- タップ領域の寸法
高さ側の検証を開発者ツールだけで済ませたときに事故が起きます。幅と高さで手段を分けるのが要点です。
幅と高さは性質が違う｜固定できるものとできないもの
CSSピクセルで見た表示領域は、幅と高さで扱い方を分ける必要があります。幅は端末ごとにほぼ固定ですが、高さは同じ端末でも変わります。
幅は数種類の帯に収束する
Androidを含めて端末は無数にありますが、CSSピクセルの幅はいくつかの帯に集まります。おおまかには、狭い帯、標準的な帯、大きい帯、そして折りたたみを開いた状態の帯です。端末ごとの正確な値は各メーカーの一次情報と実機で確認するのが前提で、記憶や孫引きの一覧表を設計の根拠にはしません。
実務で効くのは「どの端末が何pxか」を覚えることではなく、一番狭い帯で崩れないかを基準に置くことです。狭い側で成立していれば広い側は余白が増えるだけですが、逆は破綻します。
幅をCSSの基準値としてどう置くか、ブレイクポイントを何本引くかは、数値の設計そのものが論点になります。そこは分けて書いています。
高さは「端末のサイズ」ではなく「今の状態」
高さが変わる要因は、幅と比べてずっと多いです。
- ブラウザのアドレスバーが縮むかどうか（スクロール中に高さが変わる）
- ホームインジケータやノッチなどのセーフエリア
- アプリ内ブラウザ（SNSからの遷移）で上下に出る独自のバー
- キーボードの表示（フォーム入力中）
「この端末の高さは◯px」という前提でファーストビューを作ると、SNS経由の流入だけボタンが隠れるという事故になります。高さを使うときは 100vh ではなく 100dvh を基準にして、動的な変化を取り込みます。
/* ファーストビューを「今見えている高さ」に合わせる */
.hero {
min-height: 100dvh; /* 動的ビューポート高さ */
padding-top: env(safe-area-inset-top);
padding-bottom: calc(24px + env(safe-area-inset-bottom));
box-sizing: border-box;
}
/* dvh 非対応ブラウザ向けのフォールバック */
@supports not (height: 100dvh) {
.hero { min-height: 100vh; }
}
dvh は主要なモダンブラウザで使えます。対応バージョンはブラウザの更新で動くので、実装時にMDNなど一次情報で確認してください。
つまずきやすい点が1つあります。env(safe-area-inset-*) を効かせるには、viewportのメタタグに viewport-fit=cover が必要です。
<meta name="viewport" content="width=device-width, initial-scale=1, viewport-fit=cover">
これを書き忘れると、インセットの値は常に0を返します。CSS側を何度書き直しても効きません。「セーフエリアが効かない」という症状のほとんどはここです。
画面のサイズが小さいほど、情報の優先順位が露出する
幅の狭い端末で成立させようとすると、「置く場所がない」という理由で情報の優先順位を決めざるを得なくなります。これはスマホ対応の制約ではなく、設計の弱点が可視化された状態です。PCで横に並べてごまかしていた要素は、縦に積んだ瞬間に「何番目に読ませるのか」を問われます。
幅の狭い端末で複数のサイトを開き比べると、見やすい側と読みにくい側の差は数秒で分かります。見やすい側に共通しているのは次の4点です。
- ファーストビューに置く要素が2〜3個に絞られている
- 主役のボタンが親指の届く高さにある
- 見出しの文字サイズが幅に応じて滑らかに変わる
- 画像の縦横比が端末によって崩れない
逆に読みにくいものは、PCのレイアウトをそのまま縮小しているだけで、文字が小さいかファーストビューに要素が多すぎるかのどちらかです。実際に見比べる基準を持つには、ギャラリーに並ぶ実例を手元の端末で開いて、この4点がどこで崩れているかを指でなぞって確認するのが一番早い方法です。
情報量が多いサイトは、縦に積む順番を型で決める
商品や記事が多いサイトは、幅が狭くなった瞬間に一番苦しくなります。横に並んでいたカードが全部縦一列になるので、何をどの順で見せるかを決めていないと延々スクロールするだけのページになります。レイアウトの型から入ると判断が速くなるので、分類した記事を置いておきます。
文字サイズは幅に追従させる
幅が変わる前提に立つと、文字サイズを固定値で置く意味が薄くなります。clamp() で下限・可変・上限をまとめて指定すれば、ブレイクポイントを増やさずに幅へ追従します。考え方と値の決め方はfont-size を clamp() でスマホ対応にで具体的に書いています。
狭い幅では、読み込み中の見え方まで設計に入る
幅が狭いと1画面に入る情報が少ないので、読み込みが終わるまでの数秒がそのまま「何も無いページ」に見えます。高さを dvh で詰めたファーストビューほど、この空白が目立ちます。枠だけ先に出す作り方はスケルトンスクリーンのCSS実装方法にまとめています。
スマホを前提に組み直すという選択
幅の狭さに合わせて削るのではなく、最初からスマホを主として設計すると、優先順位の決め方そのものが変わります。PC前提の設計と何が違うのかはスマホ特化デザインとはに分けて書いています。アプリやゲームのように画面を使い切る設計では、セーフエリアの扱いがより厳しくなり、判断基準も変わります（スマホゲーム画面サイズ2027）。
よくある質問
スマホの画面のサイズは何pxと考えればいいですか
Webの設計で使うのはCSSピクセルの幅で、狭い帯から広い帯までいくつかの区分に収まります。一番狭い帯で崩れないことを基準にすれば、広い側は余白が増えるだけで破綻しません。解像度の数字はレイアウトではなく画像の書き出し倍率に使います。
インチ数から画面の幅は計算できますか
できません。対角のインチ数だけでは縦横比が分からず、端末側の表示倍率の設定でもCSS上の幅は変わります。インチ数は体感の大きさを話すための数字で、設計の入力値にはなりません。
100vh でファーストビューを画面いっぱいにすると何が問題ですか
100vh はアドレスバーが縮む前の高さを指すため、実際に見えている領域より大きくなり、ボタンが画面外に隠れることがあります。100dvh に置き換えると今見えている高さに追従します。非対応ブラウザ向けに @supports not でフォールバックを添えてください。
セーフエリアの指定が効きません
env(safe-area-inset-*) は、viewportのメタタグに viewport-fit=cover が入っていないと常に0を返します。CSSではなくメタタグ側が原因であることが多いので、まずそこを確認してください。
実機がなくても検証できますか
幅の崩れ、折り返し、画像の倍率は開発者ツールのデバイスモードで足ります。アドレスバーの縮み、SNSのアプリ内ブラウザ、キーボード表示時の見切れは再現できないため、高さに関わる部分だけは実機が必要です。
まとめ
「スマホの画面のサイズ」という一語には、物理インチ・解像度・表示領域のCSSピクセル・実際に見えている範囲という4つの数字が混ざっています。設計で使うのは後ろの2つだけです。
- 幅はCSSピクセルで、一番狭い帯を下限の基準に置く
- 高さは固定値で扱わず
100dvhとセーフエリアで組む env(safe-area-inset-*)はviewport-fit=coverが無いと常に0- 高さの検証は開発者ツールで代替できず、実機が必要
- 一覧表を探すより、手元の端末で4つの数字を実測するほうが速い
幅が狭いほど、情報の優先順位を決めていない設計は崩れます。画面のサイズへの対応は寸法合わせの作業ではなく、何を最初に読ませるかという判断の問題です。
