この記事の対象: スマホゲームのUI・公式サイト・LPを設計するデザイナーと実装担当者
読了時間: 約10分
スマホゲームの画面サイズは、縦持ちなら幅390px×高さ844px、横持ちなら844×390を基準キャンバスに置き、幅は固定・縦(横持ちなら横)だけを可変にする。安全領域は固定paddingをやめて env(safe-area-inset-*) で端末に決めさせ、高さは 100dvh で取る。2027年に向けた設計基準はこの3つで足ります。以下では、その数値の根拠、確認すべき3つの幅、そのままコピーして使えるCSS、公式サイト側で判断が変わる点を順に見ていきます。
スマホゲームの画面サイズ2027|まず押さえる基準値
この3工程の順番を崩すと、端末ごとの分岐が後から増えていきます。
先に結論を置いたので、以降は「なぜその値なのか」と「どこで破綻するのか」を具体的に見ていきます。設計時に確認しておく論理幅(CSSピクセル)は次の5区分です。実機の値は端末とOSの版で変わるため、最終確認は実機かブラウザのデバイスエミュレーションで行ってください。
| 区分 | 論理幅の目安 | 設計上の意味 |
|---|---|---|
| 小さめのiPhone | 375px前後 | 下限。情報密度の限界を決める基準 |
| 標準的なiPhone | 390〜393px前後 | 実質的な最多層。ここで美しく見せる |
| 大画面iPhone | 430px前後 | 余白が増える側。要素を太らせない |
| Android 標準 | 360〜412px前後 | 360pxは下限候補。文字詰まりが出やすい |
| 折りたたみ(開いた状態) | 650px以上 | タブレット扱いに切り替える分岐点 |
確認する幅は375px・390px・430pxの3点に絞れます。375pxで文字の折り返しと詰まりを見て、390pxで完成形を作り、430pxで間延びしていないかを見る。この3点を通れば、間にある幅はほぼ成立します。
崩れる原因は横幅ではなく縦横比
レイアウトが壊れる原因は、横幅の違いよりも縦横比の違いです。横幅は360〜430pxという狭い範囲に収まっているのに対し、縦横比は16:9に近いものから20:9を超えるものまで散らばります。横持ちゲームなら左右が伸び、縦持ちゲームなら上下が伸びる。ここを「全体の拡大縮小」で吸収しようとすると、端末によってUIが画面外へはみ出したり、中央が間延びしたりします。
2027年に効いてくる3つの変化
- ブラウザUIの伸縮:アドレスバーの出入りで表示高さが変わる。
100vh固定は上下が切れる原因になります - 折りたたみ端末:開閉で縦横比が別物になる。
resizeではなくmatchMediaで状態として扱う前提が要ります - カメラ部分の切り欠き:ノッチ・パンチホール・丸角の形は端末ごとに違う。座標で逃げるのではなく、OSが教えてくれる値を使う発想へ
基準キャンバスの決め方|縦持ちと横持ちで分ける
縦持ちゲームの基準
縦持ちは横幅を固定、縦を可変として設計します。基準キャンバスは幅390px・高さ844px前後を置き、縦の伸び縮みを「中央のコンテンツ領域」だけが吸収する構造にします。
上部固定帯
- 所持通貨・スタミナ
- 高さは固定
中央コンテンツ
- 縦の余りを全部ここで吸う
- スクロール可
下部ナビ
- 親指が届く範囲に置く
- 安全領域ぶんを足す
伸びるのは中央の1層だけ。上下の帯は高さを動かさない。
この3層に割っておくと、縦長の端末でも短い端末でも、ボタンの位置関係が変わりません。逆に上下の帯まで比率で伸ばすと、背の高い端末でヘッダーだけが分厚くなって締まりが消えます。
横持ちゲームの基準
横持ちは高さを固定、横を可変です。基準は390×844を倒した844×390前後で起こし、横に余った領域は背景の延長として扱います。ここで重要なのは、UIを画面の四隅に貼らないことです。横に長い端末では四隅が遠すぎて指が届かず、16:9寄りの端末では切り欠きと干渉します。
- ゲーム進行に必要な操作は、画面中央から高さの40%以内に収める
- 背景美術は左右に20%ずつ「捨て代」を持たせ、どこで切れても成立する絵にする
- ロゴ・バナーは左右中央寄せ。隅基準の絶対配置にしない
安全領域(セーフエリア)は座標で逃げず端末に決めさせる
切り欠きや丸角を避ける方法として、固定のpadding値を入れる作りはいまだによく見かけますが、端末が増えるほど合わなくなります。OSが渡してくる env(safe-area-inset-*) を使い、値は端末に決めさせるのが2027年基準です。
env()で端末に決めさせる
- 新端末が出ても修正不要
- 折りたたみの開閉に追従
- 横持ち時の左右も自動で入る
固定paddingで逃げる
- 端末ごとに分岐が増える
- 切り欠きなし端末で余白が無駄
- OS更新で合わなくなる
env() を使う側は、端末が増えてもコードが増えません。固定値で書いた分岐は、そのまま将来の修正コストになります。
実装のポイント|viewport-fit=cover を忘れない
env() を効かせるには、HTMLのviewport指定に viewport-fit=cover が必要です。これを忘れると値が常に0になり、「書いたのに効かない」というつまずき方をします。
<meta name="viewport"
content="width=device-width, initial-scale=1, viewport-fit=cover">
:root {
/* 端末が値を返さない場合の保険として max() で下限を作る */
--safe-top: max(env(safe-area-inset-top), 12px);
--safe-bottom: max(env(safe-area-inset-bottom), 12px);
--safe-left: max(env(safe-area-inset-left), 0px);
--safe-right: max(env(safe-area-inset-right), 0px);
}
.game-ui {
position: fixed;
inset: 0;
/* 古い環境向けに 100vh を先に置き、dvh で上書きする */
height: 100vh;
height: 100dvh;
padding-top: var(--safe-top);
padding-bottom: var(--safe-bottom);
padding-left: var(--safe-left);
padding-right: var(--safe-right);
box-sizing: border-box;
}
/* 下部ナビは安全領域ぶんだけ背景を伸ばし、中身は押し上げる */
.game-nav {
padding-bottom: var(--safe-bottom);
background: #14121a;
}
max() で下限を入れているのは、切り欠きのない端末で env() が0pxを返し、UIが画面の端に貼り付いてしまうのを防ぐためです。見た目の最低余白はこちらで保証します。
対応ブラウザ:env(safe-area-inset-*) と dvh は、主要なモバイルブラウザ(iOS Safari・Android Chrome)の近年のバージョンでは標準的に使えます。対象端末のOS・ブラウザの版は案件ごとに幅があるため、実装前にCan I Useなどで最新の対応状況を1回確認してから採用してください。
ダークなゲームUIで安全領域ぶんの帯を足すと、背景色と文字色のコントラストが設計時と変わって見える場合があります。帯の色を決めるときの基準値は別記事にまとめています。
可変に耐えるレイアウトの型とつまずきやすい点
画面全体を1枚の比率として扱う
ゲームの盤面やカード演出など「比率が崩れると成立しないもの」は、画面に合わせて引き伸ばすのではなく、比率を保ったまま収めます。
.board-area {
/* 盤面の比率を固定し、余りは外側の余白にする */
aspect-ratio: 3 / 4;
max-width: 100%;
max-height: 100%;
margin-inline: auto;
}
/* 横持ち時は高さ基準に切り替える */
@media (orientation: landscape) {
.board-area {
aspect-ratio: 16 / 9;
height: 100%;
width: auto;
}
}
aspect-ratio で比率を固定し、max-width と max-height の両方を100%にしておくと、縦長でも横長でも盤面が画面の内側に収まります。はみ出しを overflow: hidden で隠す作りは、端末によって盤面の端が切れるので避けてください。
折りたたみ・タブレットの分岐
幅650pxを境に「スマホの拡大版」から「2カラム」へ切り替えるのが扱いやすい基準です。開閉を状態として拾うなら matchMedia を使います。
const wide = window.matchMedia('(min-width: 650px)');
function applyLayout(e) {
document.documentElement.dataset.layout = e.matches ? 'wide' : 'narrow';
}
applyLayout(wide);
wide.addEventListener('change', applyLayout);
resize イベントで毎回判定すると発火回数が多く、折りたたみの開閉では途中の中間状態まで拾ってしまいます。matchMedia なら境界を越えた瞬間だけ1回走ります。
つまずきやすい点4つ
100vhのまま出す:Android Chromeでアドレスバーが出入りすると、下部ボタンが隠れます。dvhへposition: fixedとソフトキーボード:入力欄があるゲームは、キーボード表示時に固定要素が浮きます。入力画面だけfixedを外す設計に- デザインデータの倍率違い:@2xで作ったデータを等倍としてCSSに書き写すと全部2倍になります。基準は論理px(390など)で統一
- 画像の解像度不足:430px幅端末でも実ピクセルは3倍になる場合があります。書き出しは@3xまで用意
文字サイズを幅に応じて動かす場合は、ブレイクポイントで段階的に切り替えるより clamp() で1行にまとめたほうが、375pxと430pxの間で不自然な飛びが出ません。書き方はfont-size を clamp() でスマホ対応にで解説しています。
公式サイト・LP側の画面サイズ設計はゲーム内と別物
ゲーム本体のUIと、公式サイトやリリース前のLPは別の設計です。LPは縦スクロールが前提なので、ゲーム内と同じ比率固定の発想を持ち込むと、情報が入らなくなります。
- FVはdvhで組む:
height: 100dvhにして、キービジュアルの主題を中央から上寄せに置く。下部はスクロールを促す余地として空ける - 横持ち対応は切らない:ゲームサイトは横持ちで見られる割合が相対的に高くなる傾向があります。横持ちでFVが成立するかを必ず確認
- 縦1本で畳む:情報量が多くないタイトルなら、1カラム構成のほうが端末差に強くなります
キャラクター一覧やニュース一覧のように数が増える領域は、グリッドの列数をブレイクポイントで変えるのが素直です。列数の決め方はグリッドレイアウトのWebデザイン実例9選にまとめています。更新が続くお知らせ部分の設計はポータルサイト・メディア参考事例5選が近い構造の参考になります。
可変前提の設計はガジェット系サイトが先に通っている
縦横比のばらつきに対して先に答えを出しているのは、実はゲームサイトより家電・PC・モバイル系のサイトです。扱う商品そのものが「画面」なので、端末の幅で見え方が変わることを前提に組まれています。
Soreiine!!のギャラリーで家電・PC・モバイルに分類している掲載サイトを見ると、共通して次の作りになっていました。
- キービジュアルを比率で固定し、周囲を背景色で埋める:どの幅で切れても製品の主題が欠けない。ゲームの盤面を
aspect-ratioで守るのと同じ考え方です - 下部の操作要素を画面端に貼らない:丸角と切り欠きのある端末で指が触れない位置を避けている
- スペック表を幅で縦積みに畳む:横スクロールで逃げず、375px幅でも読める形に組み替えている
とくに参考になるのは3つ目です。ゲーム公式サイトのキャラクターステータスや装備一覧も同じ構造なので、375px幅で表が読めるかどうかは、この分類の掲載サイトを並べて比べると判断が早くなります。分類と各サイトの詳細は下の記事にまとめています。
背景を画像で敷くと、可変の幅に合わせた複数書き出しが必要になります。CSSだけで背景を作れば、どの縦横比でも破綻せず画像の読み込みもゼロになるので、ゲーム公式サイトのFV背景にはCSSメッシュグラデーションが噛み合います。
よくある質問
スマホゲームの基準となる画面サイズは何pxで作ればいいですか
縦持ちなら幅390px・高さ844px前後、横持ちならそれを倒した844×390前後を基準キャンバスにします。幅は固定して縦(横持ちなら横)を可変として扱い、余った分はコンテンツ領域1か所だけで吸収させてください。実機確認は375pxと430pxの両端で行うと、詰まりと間延びの両方を同時に潰せます。
2027年も375px幅での確認は必要ですか
必要です。375px前後の端末は長く使われ続けており、ここで文字が折り返して崩れる設計は下限で破綻します。下限の確認は375px、標準は390px前後、上限は430px前後の3点で足ります。
safe-area-inset を書いたのに効きません
viewportのmetaタグに viewport-fit=cover が入っていないケースがほとんどです。これが無いと env(safe-area-inset-*) は常に0pxを返します。加えて、切り欠きのない端末では正しく0pxが返るため、max() で最低余白を併記しておくと見た目が安定します。
100vh と 100dvh はどちらを使うべきですか
ゲームUIやFVのように画面いっぱいで固定したい領域は 100dvh です。100vh はアドレスバーが隠れた状態の高さを基準にするため、バーが出ている間は下端が画面外へ出ます。古い環境向けに 100vh を先に書き、後ろに 100dvh を置いて上書きする形が実務的です。
折りたたみ端末は専用のレイアウトを作るべきですか
専用には作らず、幅650px以上でタブレット側のレイアウトに切り替える形で足ります。開閉の検出は resize ではなく matchMedia('(min-width: 650px)') を使い、境界を越えた瞬間だけ処理が走るようにしてください。
まとめ
2027年のスマホゲーム画面サイズ設計は、固定キャンバスを1枚決める作業から、伸びる場所と伸びない場所を仕分ける作業に変わっています。基準は縦持ち390×844・横持ち844×390。縦持ちは横固定・縦可変、横持ちは高さ固定・横可変で、余りは1か所だけに吸わせる。安全領域は座標で逃げず env() で端末に決めさせ、高さは dvh で取る。確認は375px・390px・430pxの3点。
公式サイト側はゲーム内UIとは別の設計が必要で、縦1本に畳むか、グリッドで情報を並べるかはタイトルの情報量で決まります。可変を前提にした組み方は家電・PC・モバイル系のサイトが先に通っているので、近い縦横比の実装をギャラリーで見比べてから着手すると、判断の精度が上がります。
