はじめに
業務システムの画面設計をしていて、「ノートPCでもスクロールなしで1画面に収まるようにしたい」と考えました。
要件定義書には「画面解像度 1366×768 以上」と書いてあります。使うノートPCの設定を見たら 1920×1080。「なんだ、余裕じゃん」と思って進めようとしたのですが、念のため実機のブラウザで測ってみたら、使えるのは 1280×720 でした。さらに、ページを実際に描ける高さは 約600 しかありませんでした。
同じ1台のPCから 1920×1080 / 1280×720 / 約600 と3種類の数字が出てきて完全に混乱したので、整理して残しておきます。
環境
- Windows 11
- Chrome / Edge（最新版）
- ノートPC：パネル 1920×1080、表示の拡大率 150%
- デスクトップPC：パネル 1920×1080、表示の拡大率 100%
結論（3つの数字は全部別のものだった）
| # | 呼び方 | ノートPCでの値 | 何を表しているか | 調べ方 |
|---|---|---|---|---|
| ① | 物理解像度 | 1920×1080 | パネルに並んでいる点の数 |
Win + I →「システム」→「ディスプレイ」 |
| ② | 画面サイズ（CSSピクセル） | 1280×720 | ブラウザから見た画面の広さ | ブラウザで F12 →「Console」タブに screen.width と入力 |
| ③ | ビューポート | 約1280×600 | 実際にページを描ける範囲 | 同じConsoleで innerWidth / innerHeight（※開発ツールを開くと値がずれる。後述） |
②③は、ブラウザに最初から入っている「開発ツール（DevTools）」の Console というタブで確認します。何かをインストールする必要はありません。F12 で開いて命令を打つと、その場で答えが返ってきます。
画面設計で使うのは③だけです。 ①を見て判断すると、私のように1.5倍も広く見積もってしまいます。
備考：「CSSピクセル」とは
CSS（Cascading Style Sheets）はWebページの見た目を指定する言語で、その CSSが「1px」と数えるときの単位が CSSピクセルです。画面に並んでいる点そのもの（＝物理ピクセル）とは別物で、関係はCSSピクセル = 物理の点の数 ÷ 拡大率の式だけです。②の 1280×720 もこれに当てはめた結果で、詳しくは「つまずき②」で説明します。
以下、順番に何が起きているかを書きます。
つまずき①：px は長さの単位ではない
まずここを勘違いしていました。「1920って cm？」と思ったのですが、違います。
px（ピクセル）は画素、つまり「点の個数」です。 画面は小さく光る点がびっしり並んでできていて、1920×1080 は「横に1920個、縦に1080個の点が並んでいる」という意味です（合計およそ207万個）。
長さではないので、cm には直せません。同じ 1920×1080 でも物理的な大きさはバラバラです。
| 画面 | 点の数 | 実際の横幅 |
|---|---|---|
| 13インチのノートPC | 1920×1080 | 約29cm |
| 27インチのモニター | 1920×1080 | 約60cm |
点の数は同じでも、点そのものの大きさが違うので、実際の幅は2倍以上違います。13インチは点が細かく詰まっていて、27インチは点が大きく粗い、ということです。
Webページを作るときに知りたいのは「どれだけ情報が入るか」なので、cm ではなく点の個数で数えます。
つまずき②：拡大率が、使える広さを目減りさせる
ここが最大の落とし穴でした。
Windowsの「表示の拡大率（スケーリング）」とは、ページの1pxを、画面の点いくつ分で描くかの設定です。
拡大率100% ページの1px → 点1個で描く
→ 1920個の点に、1920px 分の情報が入る
拡大率150% ページの1px → 点1.5個分で描く
→ 1920個の点に、1280px 分の情報しか入らない（1920 ÷ 1.5）
式にするとこれだけです。
CSSピクセル = 物理ピクセル ÷ 拡大率
横： 1920 ÷ 1.5 = 1280
縦： 1080 ÷ 1.5 = 720
文字やボタンは1.5倍大きく描かれて読みやすくなりますが、その代わり入る情報は3分の2に減ります。
拡大率を変えたときの一覧がこちらです。物理パネルはどの行も同じ1920×1080で、点の数は一切変わっていません。
| 拡大率 | 1CSSピクセルが使う点 | 物理パネル | CSSピクセルでの画面サイズ | 文字の見た目 |
|---|---|---|---|---|
| 100% | 1個 | 1920×1080 | 1920×1080 | 小さい |
| 125% | 1.25個 | 1920×1080 | 1536×864 | やや大きい |
| 150% | 1.5個 | 1920×1080 | 1280×720 | 大きい |
| 200% | 2個 | 1920×1080 | 960×540 | かなり大きい |
同じPCでも、設定を変えるだけでCSSピクセルの数は増えたり減ったりします。
そして拡大率100%のときだけ、物理ピクセルとCSSピクセルが同じ数になります。デスクトップPCは100%なので一致していて、だから「解像度1920×1080」と言えばそれで話が通じていました。ノートPCが150%だったせいで、初めて2つを区別する必要が出てきたわけです。
備考：拡大率は自分で設定した覚えがなくても100%ではないことが普通です。
Windowsは、画面の物理サイズと解像度から適切な拡大率を判断して、購入時から125%や150%を「推奨」として設定します。小さい画面に高い解像度が載っているノートPCほど、拡大率が高く設定されています。「設定を触っていないから100%のはず」という前提は成り立ちません。
つまずき③：ブラウザのUIが高さを食う
②で 1280×720 になることは分かりましたが、実測した高さは 600 でした。残りの120はどこへ行ったのか、という話です。
ブラウザ自身のタブ・アドレスバー・ブックマークバーが、画面の上部を占めているためです。
画面の高さ（CSSピクセル） 720
− タブ・アドレスバー等 約120
──────────────────────────────
ページに使える高さ 約600
この「約120」はブラウザやブックマークバーの表示有無で変わるので、実機で測るしかありません。
幅のほうは、縦スクロールバーが 15〜17px ほど占めます。
自分のPCを測るスニペット
開発ツールのConsoleに貼るだけで、上の①〜③が全部出ます。
備考：スニペット（snippet）＝「切れ端」。
コピーして貼るだけで動く、短いコードのことです。ファイルに保存したりインストールしたりせず、その場で1回だけ実行して結果を見る、という使い方をします。実行してもPCの設定は何も変わらず、ページを再読み込み（F5）すれば消えます。
// 使い方：ブラウザで F12 を押して「Console」タブを開き、これを貼って Enter
//（③を正しく測るには、次の項のとおり開発ツールを別ウィンドウにしてから実行してください）
console.table({
'① パネルの画素数（推定）': {
// screen.width は拡大率で割られた値なので、拡大率を掛けて物理の点の数に戻す
値: `${screen.width * devicePixelRatio} x ${screen.height * devicePixelRatio}`
},
'② 画面サイズ（CSSピクセル）': {
// ブラウザから見た画面の広さ。Windowsの設定画面の数字とは一致しないことがある
値: `${screen.width} x ${screen.height}`
},
'③ ビューポート（ページに使える範囲）': {
// ブラウザのUIを除いた、実際にページを描ける範囲。設計に使うのはこれ
値: `${innerWidth} x ${innerHeight}`
},
'④ スクロールバーを除いた幅': {
// innerWidth はスクロールバーの幅を含んでいるので、それを除いた値
値: `${document.documentElement.clientWidth} x ${document.documentElement.clientHeight}`
},
'⑤ 拡大率': {
// 1 なら100%、1.5 なら150%
値: `${devicePixelRatio * 100}%`
}
});
備考：
F11（全画面表示）の状態で測らないこと。
全画面にするとブラウザのUIが消えるのでinnerHeightが大きく出ます。普段の使い方に合わせて、通常の状態で測ります。
落とし穴：開発ツール自体がビューポートを削っている
ここは自分でやってみて気づいた点です。開発ツールを画面の右や下に表示すると、その分ページの表示領域が削られます。
開発ツールを閉じている ページに使える範囲 1280 × 600 ← 本当に知りたい値
開発ツールを下に開く ページに使える範囲 1280 × 300 ← 開発ツールの高さ分だけ減る
つまり開発ツールを開いたまま測った③の値は、本当の値より小さく出ます。測るために開いた道具が、測りたいものを変えてしまっているわけです。
| 番号 | 開発ツールの影響 | 理由 |
|---|---|---|
| ① 物理解像度 | 受けない | 画面（パネル）の話なので、ブラウザの状態と無関係 |
| ② 画面サイズ | 受けない | 同じく画面の話。screen は画面全体を指す |
| ③ ビューポート | 受ける | ページの表示領域そのものなので、削られた分だけ小さくなる |
対処法は、開発ツールを別ウィンドウに切り離すことです。独立したウィンドウにすれば、測りたいページの大きさは変わりません。手順はこちらです。
- 開発ツール右上の
⋮（縦三点）をクリック -
Dock side（ドッキングの位置） の行に並ぶ4つのアイコンのうち、一番左（別ウィンドウ） を選ぶ
キーボードで済ませたい場合は、コマンドメニューから実行できます。
-
Ctrl+Shift+Pを押す -
undockと入力 -
Undock into separate windowを選ぶ
注意：
Ctrl+Shift+Dでは切り離せません。
このショートカットは「直前に使っていたドッキング位置と入れ替える」ものなので、右と下を往復するだけです。下に出ている状態でも高さは削られたままなので、値は正しくなりません（右なら幅が削られます）。私はこれを勘違いしていました。
切り離せたかどうかは、innerHeight をもう一度実行すれば分かります。数値が増えていれば成功、変わらないならまだページの中に居座っています。
おまけ：「1366×768」はどこから来た数字なのか
要件定義書によく出てくるこの値、気になって調べました。
WXGA と呼ばれる規格で、2010年代のノートPCの標準的な解像度です。長年、世界のブラウザ統計で最も多い解像度でした。
数字の出どころは、その前の世代の規格 XGA（1024×768） です。画面が4:3から16:9の横長に置き換わるとき、メーカーは高さ768をそのまま残して横だけ広げたのです。
768 × 16 ÷ 9 = 1365.33… → 切り上げて 1366
この式は「16:9 の比率を、実際の数に直す計算」です。16:9 とは「横が16のとき、縦が9」という比率なので、2段階に分けるとこうなります。
① 768 ÷ 9 = 85.33 比率の「1目盛り」がいくつかを求める
② 85.33 × 16 = 1365.33 それを16目盛り分にして、横幅を出す
÷9 で1目盛りの大きさを求め、×16 でそれを横幅に直している、というだけです。きれいに割り切れる例で確かめると分かりやすいです。
| 解像度 | 計算 | 結果 |
|---|---|---|
| 1920×1080（16:9） | 1080 ÷ 9 = 120 → ×16 | 1920 ぴったり |
| 1024×768（4:3） | 768 ÷ 3 = 256 → ×4 | 1024 ぴったり |
| ?×768（16:9） | 768 ÷ 9 = 85.33 → ×16 | 1365.33 割り切れない |
768 が 9 で割り切れないため端数が出て、それを切り上げたのが1366です。1366 という中途半端な値なのはこのためで、8でも割り切れないので、実際には 1360×768 のパネルも存在しました。
そして皮肉なことに、この数字は今でも通用します。
| 使える広さ | |
|---|---|
| 2010年代のノートPC（1366×768、拡大率100%） | 1366×768 |
| 今のノートPC（1920×1080、拡大率150%） | 1280×720 |
パネルの画素数は増えたのに、拡大率のせいで実際に使える広さはむしろ狭くなっています。「新しいPCだから広いはず」は成り立たない、ということです。
設計にどう落としたか
手順はこれだけです。
- 利用者が実際に使うPCを、上のスニペットで測る
- その中でページに使える範囲がいちばん狭いものを基準にする
- そこから余白とスクロールバーを引いた値を、設計上の枠にする
実際に測ったのは、自分に貸与されているノートPCとデスクトップPCの2台だけです。 社内を見たところ、おおむねこの2機種が配られているようだったので、まずはこの2台で決めました。
| 測ったPC | ページに使える範囲 |
|---|---|
| デスクトップPC（拡大率100%） | 約 1920×950 |
| ノートPC（拡大率150%） | 約 1280×600 ← こちらを基準に |
狭いほうのノートPCに合わせ、ページに使える範囲 1280×600 に対して、設計枠を 1120×600 にしました。幅は160px分を余白とスクロールバーに残し、高さは600をそのまま使っています。
備考：2台しか測っていないので、これは「暫定の下限」です。
ただし表示拡大率の初期値はWindowsが画面サイズと解像度から自動で決めるため、同じ機種なら同じ値になります。逆に違う機種を使っている人がいれば下限は変わるので（15.6インチのフルHDなら推奨125%＝幅1536）、配布PCの機種が確定した時点で見直す前提にしています。
全台を測るのが理想ですが、まず1台でも実測して「物理解像度で判断してはいけない」と分かったことのほうが、この件では大きかったです。
もう一つ決めたのは、全画面を1画面に収めようとしないことです。高さ600から、今度は作るシステム自身が置くもの（画面上部のヘッダー帯、画面タイトル、パンくずなど）を引くと、内容に使えるのは450〜500程度しかありません。
720 ブラウザから見た画面の高さ
−120 ブラウザが持っている部分（タブ・アドレスバー） ← ここまではブラウザの都合
─────
600 ページに使える範囲（＝設計枠の高さ）
−100 自分が作るシステムのヘッダー帯・画面タイトル ← ここからは自分の設計の話
─────
500 1画面の中で本文に使える範囲
同じ「ヘッダー」でも、ブラウザが持っているものと、自分が作るものは別です。二重に引いているわけではありません。
一覧画面や登録画面を無理にここへ詰めると、タブや折りたたみが増えて、かえって操作の手数が増えます。
なので画面を3つに分けました。
| 分類 | 方針 | 対象の例 |
|---|---|---|
| A | スクロールさせない | ログイン画面、トップ画面 |
| B | 主要情報をファーストビューに収める（以降はスクロール可） | 一覧画面 |
| C | スクロール許容。操作ボタンは画面下部に固定 | 詳細画面、登録・編集画面 |
要件定義書にどう書くべきだったか
「画面解像度 1366×768 以上」という書き方は、①②③のどの数字なのかが分かりません。拡大率にも触れていないので、読んだ人によって解釈が変わり、結果として検証もできません。
書くならこうすべきでした。
- 対象ブラウザ：Chrome / Edge 最新版（Windows 11）
- 想定する表示の拡大率：100%〜150%
- 設計基準ビューポート：1280×600
（拡大率150%のノートPCで実測した、ページに使える範囲）
- 上記の範囲で横スクロールを発生させないこと
ポイントは、測定条件が書かれていて、あとから同じ手順で検証できることだと思います。
おわりに
同じ1台のPCから3種類の数字が出てくることを知らないと、「1920×1080だから余裕」と判断してしまいます。私は実際にそう判断しかけました。
拡大率とブラウザUIの2段階で目減りする、と覚えておくと見通しが良くなります。そして結局、実機で測るのが一番早いです。