👌

『何かでかい』を防ぐ、Webデザインのサイズ設計── 見落としがちなポイント整理

2025/09/24に公開

Webデザインを作成してOKを貰ったのに、コーディング後、「何かでかい･･･」と言われたこと、思ったことはありませんか？
きちんとサイズを調べて作成しているWebデザイナーでも、一部見落としが原因で「何かでかい」が発生することがあります。
この記事は、そうした見落としがちなポイントを整理、把握することで、レビューする側（ユーザー環境）の状況を理解し、「何かでかい」を防ぐ手助けになればという思いで書きました。
!※ 対象はデスクトップの話のみ、データは2025年9月時点のものです。

※ 考え方自体は今後も活かせると思います。

 見落としの罠は各段階に存在デザインからレビューの各段階に、見落としがちなポイントがあります。
アートボードサイズを設定し、デザイン
特に「高さ」がレビュー側で見切れていないか
ファーストビューだけでなく「1画面に収めたいコンテンツ」がちゃんと収まっているか
「固定UI」（ヘッダーやツールバーなど）を差し引いてデザインできているか

プレビュー確認
「デバイス側で自動リサイズされた状態」で確認して（確認されて）いないか

コーディング
デザインの意図がコーダーに正しく伝わっているか

完成後のレビュー
レビュー側のOSにより、相対的に、物理的に大きくなっている可能性をイメージできているか


 「高さの見切れ」で「何かでかい」が発生している可能性アートボードの幅や高さについて検索すると、以下のような説明が出てきます。
アートボード幅： 1280px〜1920px。

コンテンツ幅： 800px〜1300px。アートボード幅よりも狭く設定し、両端に余白を設けることで見やすさを確保します。

ポイント： 最大幅を1920pxに設定し、最も多くのユーザーが利用する1440pxや1280pxを基準にデザインすると効率的です。
ファーストビューの高さの目安： ユーザーがスクロールせずに見られる領域の高さは、およそ600〜900pxが目安となります。

例： 幅1920px、高さ1080pxのディスプレイを想定する場合、OSのタスクバーやブラウザのタブ・ツールバーを除いた表示領域は、約800〜900pxになります。


他にも、検索すると「高さ550〜650pxは古い」「700〜720pxがベスト」など、さまざまな情報が見つかります。
問題は、これら情報を元にそのままレビューする人の環境より大きい表示領域でデザインしてしまうと、確実に「何かでかい」が発生してしまうことです。

 レビュー側の「表示領域」を想像してみるでは、レビューする人はどんな環境で確認しているのでしょうか。最近の状況から推測してみます。
※データは2024年8〜9月時点
国内出荷実績では、ノートPCが約86% [jeita.or.jp]
デスクトップOSシェアはWindowsが約65% [gs.statcounter.com]
解像度（CSS px）では1920×1080が約25% [※1][gs.statcounter.com]
また、Windowsでは「1920×1080解像度のままだと文字が小さい」ため、OSのスケーリング機能（125%や150%表示）が標準で有効になっていることが多いです。



そのため、上記の解像度（CSS px）※1の分布は、おおよそ以下の環境に対応していると考えられます。

1920×1080 / 2560×1440 → 外部モニター
1536×864 → WindowsノートPC（125%スケーリング）
1366×768 → WindowsノートPC（100%、過去に広く普及）
1280×720 → WindowsノートPC（150%スケーリング）
1440×900 / 1280×800 → MacBook Air / Pro（Retinaスケーリング）
これらを踏まえると、Webサイトの見られ方としては、ユーザーは1920×1080の外部モニターで見ることが多く、たまにWindowsノートPCでも確認する という状況が一般的と考えられます。

 「画面全幅、全高さを使える」想定でデザインしていないか次の表は、利用率の高い環境順に並べて、実際の表示領域を概算したものです。

ブラウザ実測値（高さ）は、検索バーを模して、「全高さから40pxを引いた値」を記入しています。


物理解像度
OS
スケーリング
CSS px 理論値
ブラウザ実測値
（高さ）
想定環境
利用率
（概算）


1920 × 1080
（FHD）
100%
1920 × 1080
〜968 px
外部モニター / 一部ノート
約25%

1920 × 1080
（FHD）
125%
1536 × 864
〜816 px
15.6インチノート
 (Windows)
約9.8%

1366 × 768
（HD）
100%
1366 × 768
〜728 px
古めのノートPC (Windows)
約6.1%

2560 × 1440
（WQHD）
100%
2560 × 1440
〜1400 px
外部モニター
約5.7%

1920 × 1080
（FHD）
150%
1280 × 720
〜680 px
13〜14インチノート
 (Windows)
約5.0%

2880 × 1800
（Retina）
200%
1440 × 900
〜860 px
MacBook Pro 15" (Mac)
約2.6%

1920 × 1200
（WUXGA）
150%
1280 × 800
〜760 px
15.6インチノート
 (Windows)
約1.2%

2560 × 1600
（QHD+）
200%
1280 × 800
〜760 px
MacBook Air 13" (Mac)
約1.9%

ここからさらに、ブックマークバーや固定ヘッダー、フッター固定CTAなどのUIを引いた値が、実際の表示領域になります。

 「見切れ」が発生する具体例Macで1440×900の作業環境でデザインし、高さは最大800pxを想定して作成したが、レビュー側では見切れが発生した。
ファーストビューの情報は1200×700に収まるよう作成したが、下部コンテンツで、見出し＋文章＋ボタンなど「1画面に収めたい情報」が入り切っておらず、レビューで「見えづらい」と指摘された。
1280×720に収まるようデザインしていたが、スクロール後に固定ヘッダーが重なって実際の表示領域が狭まり、見えづらい状況が発生した。
他にも、レビュー側が「1280×650程度」の表示領域だったために見切れが発生するケースもあり、結果として、「修正してください」という依頼につながることがあります。

 対策例多数のユーザーをカバーできる「表示領域」を基準に作成する
固定UIも差し引いてデザインする（左右に持たせたい余白も考慮）
ファーストビューだけでなく、1画面に収めたいコンテンツも見切れないよう配慮する

出来ればレビューする側（クライアント）の確認環境を事前に把握する
レビュー者へ「制作側が対応を想定しているサイズ」をあらかじめ共有しておく

 プレビュー確認で「何かでかい」を拾えない理由デフォルトのプレビュー機能やPDF・画像で確認した場合、実際のブラウザ表示サイズ（CSS px）ではなく、デバイスに合わせて自動的に拡大縮小された状態で表示されていることがあります。
そのため、プレビュー時には画面に収まっているように見えても、実際のブラウザ表示では「見切れ」が発生することがあります。
画面全体に表示した例：

実際のサイズ（100%）：


 ディスプレイの解像度とCSS px（ブラウザ表示）は別物例えば、Webサイト上で「200pxの円」を作ったとして、それをキャプチャしてデザインツールに貼り付けると、200pxではなく400pxとして貼り付けられることがあります（OSや環境によって異なります）。
これは、キャプチャが 物理解像度（デバイスピクセル）を基準にしている一方で、ブラウザはCSS px（OSスケーリングを考慮した値） で描画しているために起こります。
そのため、クライアントがPDFや画像を確認するときも、実際とは違う倍率で拡大縮小されていて、レビュー段階では「大きすぎる」「見切れている」といった問題に気づけないことがあります。

結果として、デザインレビューではOKが出たのに、コーディング後に「何かでかい」が発生し、指摘されるケースに繋がります。

 対策例
実際のサイズ（CSS px） で確認してもらう

100%表示で確認する機会 を設ける

 デザインの意図がマークアップ時に伝わっているか例えば「画面100%表示で実装してほしい」と考えデザインする場合、コンテンツ全体をアートボード幅に合わせて16:10や16:9比率で設計し、必要な情報は表示領域が狭いPCでも収まるように作成しておけば、どのOSでも比較的実装しやすくなります。
しかし、コーダーがその意図を把握していないと、デザインデータの高さがそのまま固定で実装されたり、横幅も「レスポンシブさせて常に左右余白を持たせたい」つもりが、固定幅で実装されてしまうことがあります。
こうしたすれ違いはコミュニケーション不足で発生するため、他の人にコーディングしてもらう場合は、デザインメモを残す等で意図を伝えることが、手戻りを防ぐ重要な手段になります。

 対策例デザインデータ内にメモを残す（ここにメモがありますと強調する）
口頭でも補足する
幅や高さによってレイアウトが異なる部分は、複数アートボードを用意する

 相対的に大きく見えるここまでのコンテンツサイズをクリアしていれば大きな問題はありませんが、見え方の差について、もう少し考えてみたいと思います。
例えば、自分のノートPCがMacで表示領域1470px、ユーザーのPCが1280pxだったとします。

すると、同じWebサイトを見たとしても、相手には 約1.15倍（15%大きく） 見えている可能性があります。
計算式： 1470 ÷ 1280 = 1.15倍
Macの例（表示領域1470px、コンテンツ幅1200px）：

Windowsの例（表示領域1280px、コンテンツ幅1200px、OSスケーリング150%）：

表示領域が狭いほど余白が削られ、相対的に「大きく見える」ことがあります。

 物理的に大きく見えるぱっと見でもわかりやすい例ですが、モニターのサイズが大きければ、同じCSS指定のフォントでも物理的に大きく感じられます。
例：作業環境が幅1470px、相手のモニターが1920px、見出しフォントを48pxで作成した場合
1920 ÷ 1470 ✕ 48 ≒ 63px に相当します。
本文（14〜16px程度）では違和感は少ないですが、見出しのように大きな文字ほど「でかく」 見えやすくなります。

※ 実際にはOSのスケーリング（125%、150%）やDPRの影響も加わるため、数値はあくまで目安です。

 対策例コンテンツサイズやフォントのジャンプ率は、Webサイトの内容により、表現としてサイズ調整されると思います。しかし、それでも「何かでかい」とならず、さまざまなデバイスに対応できるフォントサイズの上限は40px程度が目安だと考えます。
また、Webデザインのジャンプ率は、DTPデザインに比べると低めに抑えられる傾向があります。

 まとめ
 デザイン設計でできることアートボード幅は 1920px以下で作成

（クライアントへの見せ方や実装のしやすさを考慮して調整）
1画面で見せたいコンテンツは、最大1200 × 約650〜700px程度を基準に、固定UIを差し引いたサイズで幅・高さを設計（縮小時の目安値）
フォントサイズの上限は40px程度を目安にする

（WebデザインはDTPよりジャンプ率を抑える傾向）
小さいデバイス（幅1280px前後）だけでなく、大きいデバイス（幅1920px前後）での見え方も考慮（背景で吸収、縦スクロールを増やす、一部レスポンシブ対応などで工夫）
画面100%で見せたいといった要望は、別アートボードやコメントで明示し、マークアップ時に意図を共有

 実装時にできることフォントサイズは clamp() で上限値を設定し、デバイス幅に追従させる
max-width を適切に設定し、幅が広すぎる環境でも可読性を保つ（「何かでかい」を防止）
min-height、height:auto で最小限の高さを確保し、他はコンテンツ追従（見切れを防止）
デザインで決めたサイズは、実装側で後から調整することも可能です。

しかし、リサイズ対応やレスポンシブ調整には時間がかかり、コンテンツ単位で個別に対応すると工数が膨らんでいきます。
だからこそ、最初にデザイン段階で基準を揃えておくことが、工数削減にも品質向上にも直結すると考えます。
「何かでかい」を未然に防ぐことは、ユーザーにとって見やすく、チームにとって手戻りが少なく、そしてデザイナー自身にとってもスキルアップにつながります。

そんな良い循環を生み出せる一助となれば幸いです。

 おまけ以下のスクリプトをコンソールに貼り付けると、Webサイトの「表示領域」を確認できます。

外部モニターとノートPCをお持ちの方は、このスクリプトを実行してブラウザを行き来させてみたり、異なるOS環境の人と一緒に試してみると、より実感しやすいと思います。
!ブラウザズームは100%で確認してください。
スクリプトの内容：

ウィンドウの「表示領域」や「拡大率（OSスケーリング）」をリアルタイムで確認できます。
使い方：
以下のコード全体をコピー
開発者ツールのコンソール（F12）に貼り付けてEnter
コンソールを閉じる
(() => {
  const box = document.createElement('div');
  Object.assign(box.style, {
    position: 'fixed',
    zIndex: 2147483647,
    top: '10px',
    left: '10px',
    background: 'rgba(0,0,0,.82)',
    color: '#fff',
    padding: '10px 12px 8px',
    borderRadius: '8px',
    font: '12px/1.5 sans-serif',
    boxShadow: '0 4px 20px rgba(0,0,0,.3)',
    whiteSpace: 'nowrap',
    userSelect: 'text',
    cursor: 'default',
  });
  box.setAttribute('role', 'status');
  box.setAttribute('aria-live', 'polite');

  const close = document.createElement('button');
  close.textContent = '×';
  Object.assign(close.style, {
    position: 'absolute',
    top: '4px',
    right: '6px',
    border: 'none',
    background: 'transparent',
    color: '#fff',
    fontSize: '14px',
    lineHeight: '1',
    cursor: 'pointer',
    padding: 0,
  });
  close.title = '閉じる';
  close.addEventListener('click', cleanup);
  box.appendChild(close);

  const head = document.createElement('div');
  head.style.marginBottom = '6px';
  head.innerHTML =
    '<b>今の表示サイズをリアルタイムで確認</b><br>閉じる: Esc / × / リロード';
  box.appendChild(head);

  const content = document.createElement('div');
  box.appendChild(content);

  const r2 = (n) => Math.round(n * 100) / 100;
  const update = () => {
    const dpr = r2(window.devicePixelRatio || 1);
    const winW = Math.floor(window.innerWidth);
    const winH = Math.floor(window.innerHeight);
    const scrW = Math.floor(screen.width);
    const scrH = Math.floor(screen.height);
    // レンダリング解像度（近似） = CSS基準の画面サイズ × DPR
    const renderW = Math.round(scrW * dpr);
    const renderH = Math.round(scrH * dpr);

    content.innerHTML =
      `ブラウザ内の表示領域: <b>${winW} × ${winH}</b> px<br>` +
      `全体の表示サイズ（CSS基準）: ${scrW} × ${scrH} px<br>` +
      `拡大率（OSスケーリング＋ブラウザズーム） : <b>${dpr}×（約${Math.round(
        dpr * 100,
      )}%）</b><br>` +
      `<span style="font-size:11px;opacity:0.8">
      ※ブラウザズームは100%で実行してください。<br>
      ※Macの場合、物理解像度 ÷ 表示サイズ（CSS基準）で拡大率が計算できます。</span><br>` +
      `レンダリング解像度（近似）: <b>${renderW} × ${renderH}</b> px<br>` +
      `<span style="font-size:11px;opacity:0.8">
      ※Macの場合、描画手順の都合で物理解像度と一致しない場合があります。</span>`;
  };

  let raf = 0;
  const onResize = () => {
    if (!raf) raf = requestAnimationFrame(() => ((raf = 0), update()));
  };
  const onKey = (e) => e.key === 'Escape' && cleanup();

  function cleanup() {
    box.remove();
    removeEventListener('keydown', onKey);
    removeEventListener('resize', onResize);
    removeEventListener('orientationchange', onResize);
    raf && cancelAnimationFrame(raf);
  }

  addEventListener('resize', onResize, { passive: true });
  addEventListener('orientationchange', onResize, { passive: true });
  addEventListener('keydown', onKey);

  document.body.appendChild(box);
  update();
})();

 
最後まで読んでいただき、ありがとうございました！

物理解像度	OS スケーリング	CSS px 理論値	ブラウザ実測値（高さ）	想定環境	利用率（概算）
1920 × 1080 （FHD）	100%	1920 × 1080	〜968 px	外部モニター / 一部ノート	約25%
1920 × 1080 （FHD）	125%	1536 × 864	〜816 px	15.6インチノート (Windows)	約9.8%
1366 × 768 （HD）	100%	1366 × 768	〜728 px	古めのノートPC (Windows)	約6.1%
2560 × 1440 （WQHD）	100%	2560 × 1440	〜1400 px	外部モニター	約5.7%
1920 × 1080 （FHD）	150%	1280 × 720	〜680 px	13〜14インチノート (Windows)	約5.0%
2880 × 1800 （Retina）	200%	1440 × 900	〜860 px	MacBook Pro 15" (Mac)	約2.6%
1920 × 1200 （WUXGA）	150%	1280 × 800	〜760 px	15.6インチノート (Windows)	約1.2%
2560 × 1600 （QHD+）	200%	1280 × 800	〜760 px	MacBook Air 13" (Mac)	約1.9%

見落としの罠は各段階に存在

「高さの見切れ」で「何かでかい」が発生している可能性

レビュー側の「表示領域」を想像してみる

「画面全幅、全高さを使える」想定でデザインしていないか

「見切れ」が発生する具体例

対策例

プレビュー確認で「何かでかい」を拾えない理由

ディスプレイの解像度とCSS px（ブラウザ表示）は別物

対策例

デザインの意図がマークアップ時に伝わっているか

対策例

相対的に大きく見える

物理的に大きく見える

対策例

まとめ

デザイン設計でできること

実装時にできること

おまけ

Discussion