[Chrome] 実機なしでモバイル表示を確認する ― DevTools デバイスモードの使い方

このブログもアクセスの半分以上がスマホからで、レイアウトを直すたびに「実機で見たらどうなんだ」と確認したくなります。とはいえ毎回スマホを取り出すのは面倒。Chrome のデバイスモードでほとんど済むので、使い方と、逆に「これは実機で見ないとダメ」という線引きをまとめておきます。

開き方

まず DevTools を開いて、デバイスツールバーを出します。

操作	Windows / Linux	macOS
DevTools を開く	`F12` または `Ctrl + Shift + I`	`Cmd + Option + I`
要素を選択して開く	`Ctrl + Shift + C`	`Cmd + Shift + C`
デバイスツールバーの切替	`Ctrl + Shift + M`	`Cmd + Shift + M`

覚えるのは実質 Ctrl + Shift + M だけ。DevTools を開いた状態でこれを押すと、ページ表示がスマホサイズに切り替わります。もう一度押せば戻ります。

ℹ️ ショートカットが体に入っていないうちは、コマンドメニューが便利です。Ctrl + Shift + P（macOS は Cmd + Shift + P）を押して「device」と打つと、切替コマンドが出てきます。

画面サイズを決める

デバイスツールバーの上部で、表示する画面を決めます。やり方は2通り。

プリセット端末を選ぶ … iPhone や Pixel など、代表的な端末の寸法が用意されています
レスポンシブを選ぶ … 幅・高さを自由に指定。端のハンドルをドラッグして、ぐりぐり伸縮させながら崩れを探せます

実務でよく使うのは後者です。特定の端末に合わせるより、幅を連続的に変えて崩れる地点を探すほうが、レスポンシブの不具合は早く見つかります。

ブレークポイントを一覧で見る

ツールバー右の⋮メニューからメディアクエリを表示を有効にすると、画面上部にCSSのブレークポイントがバーで並びます。バーをクリックするとその幅にジャンプできるので、自分が定義した区切りを順に確認するのが一瞬で終わります。

CSS を書いた本人でも、どこにブレークポイントを置いたか忘れます。これは地味に効きます。

DPR（デバイスピクセル比）

同じ「幅390px」でも、実機は画面の密度が違います。ツールバーの DPR を 2 や 3 にすると高密度ディスプレイ相当になり、画像がぼやけないかの確認ができます。

srcset や @2x 画像を用意しているなら、ここを切り替えて実際にどのファイルが読まれるか、Networkパネルで見るのが確実です。

回転・デバイスフレーム

回転：ツールバーの回転ボタンで縦横を切り替え。横向きでヘッダーが破綻していないかは見落としがちなので、ひと通り確認しておきたいところ
デバイスフレーム：⋮メニューから有効にすると、端末の外枠付きで表示されます。スクリーンショットを資料に貼るときに便利
ルーラー：ピクセル定規を表示。余白の実測に使えます

通信速度とCPUを絞る

見た目だけでなく、モバイルらしい遅さも再現できます。ここがデバイスモードの本領。

ネットワークのスロットリング … Slow 4G などを選ぶと、回線が遅い状態を再現。画像の読み込み順やレイアウトのガタつきが見えてきます
CPU のスロットリング … 4倍・6倍といった倍率で処理を遅くします。ミドルレンジのスマホは思っている以上に遅いので、アニメーションやJSの重さはここで初めて露見します

⚠️ 開発マシンは速すぎます。手元で快適 ≠ 実機で快適。特にCPUスロットリングは、かけた瞬間に「うわ」となることが多いので、リリース前に一度は通しておくのがおすすめです。

ユーザーエージェントを変える

デバイスモードにすると UA も自動でモバイルのものに切り替わります。サーバー側でUAを見て出し分けている場合も、これで確認できます。

任意の文字列にしたいときは、DevTools 下部のドロワーから ネットワーク条件を開いて、UAのオーバーライドを設定します。特定端末やクローラーのふりをして確認したいときに。

位置情報・端末の向きを偽装する

ドロワーのセンサーでは、こんな偽装ができます。

位置情報 … 主要都市のプリセット、または緯度経度を直接指定。「東京にいる想定」でGeolocation APIを叩けます
端末の向き … 傾きセンサーの値を指定
位置情報エラー … 「位置情報が取れなかった場合」の分岐テストにも使えます

地図や店舗検索を作っているときは、わざわざ外に出なくてもテストできるのが助かります。

表示モードのエミュレーション

ドロワーのレンダリングからは、CSSの表示条件を切り替えられます。

prefers-color-scheme … ダークモードの見え方をその場で確認。このブログもダークモード対応なので、毎回ここで見ています
prefers-reduced-motion … アニメーションを減らす設定の確認
forced-colors … ハイコントラストモード相当の表示

ダークモード対応は「OSの設定を切り替えて確認」だと面倒すぎるので、ここを使うのが正解です。

スクリーンショットを撮る

デバイスツールバーの⋮メニューから、表示中のサイズでキャプチャできます。Ctrl + Shift + P から「screenshot」と打てば、ページ全体を1枚に収めたフルサイズのキャプチャも撮れます。スクロールしながら繋ぐ作業が要らないので、モバイル表示の共有にはこれが一番早い。

よく使う端末を登録する

プリセットに無い解像度を毎回入力しているなら、カスタムデバイスとして登録できます。DevTools の設定からデバイスを追加して、幅・高さ・DPR・UAを保存しておけば、次回からプリセットのリストに出てきます。

社内の検証端末の実寸を入れておくと、チームで基準が揃って便利です。

ここは実機で見るべき、という話

便利なのですが、デバイスモードはあくまでエミュレーションです。次のあたりは実機と食い違います。

項目	実機との違い
レンダリングエンジン	iPhone の実機は Safari（WebKit）。Chrome のデバイスモードでiPhoneを選んでも、中身は Chrome のまま。WebKit固有の崩れは見つかりません
アドレスバーの伸縮	スクロールでブラウザUIが伸び縮みする挙動は再現されません。`100vh` がずれる問題はここが原因になりがち
タッチ操作の質感	慣性スクロール、長押し、ピンチなどの細かい挙動は実機と別物
フォント	端末に入っているフォントが違うので、字形や行送りがずれることがあります
実際の速度・発熱	スロットリングは近似。実機の重さ・電池・発熱までは再現できません

ざっくりした指針としては、レイアウトの当たりを取るのはデバイスモード、最終確認は実機。特に iOS 向けは、Safari で見ないと意味がない場面がそれなりにあります。

実機で見るには

Android … USBで繋いで、Chrome のアドレスバーに chrome://inspect/#devices と入力。端末側で開発者向けオプションのUSBデバッグを有効にしておけば、実機の画面をPCのDevToolsからデバッグできます
iPhone … Mac の Safari の Web インスペクタを使います。iPhone側で「Web インスペクタ」を有効にして、Macと繋ぎます

「デバイスモードでは再現しないバグ」に当たったら、この2つに切り替える、と覚えておけば十分です。

よくある質問

iPhone を選べば iOS の確認になりますか？

なりません。画面サイズとUAが変わるだけで、描画は Chrome のままです。iOS特有の不具合は Safari の実機・シミュレータでしか見つかりません。

タッチイベントは動きますか？

デバイスモードではマウス操作がタッチイベントとして送られるので、基本的な動作確認はできます。ただしマルチタッチや慣性の質感までは再現しません。

実機と表示がずれるのはなぜ？

フォント、ブラウザUIの高さ、スクロールバーの有無、そしてエンジンの違いが主な理由です。1pxのズレを追うなら実機へ。

レスポンシブ確認は何幅で見ればいい？

決め打ちより、幅をドラッグで動かしながら崩れる地点を探すのが早いです。そのうえで、自分のCSSのブレークポイント前後を重点的に。

まとめ

起動は Ctrl + Shift + M（macOS は Cmd + Shift + M）。まずこれだけ覚える
幅をドラッグして崩れを探すのがレスポンシブ確認の基本。メディアクエリ表示でブレークポイントに飛べる
ネットワークとCPUのスロットリングをかけると、モバイルの体感に近づく
ダークモード確認はレンダリングの prefers-color-scheme が最短
ただし iPhone の確認にはならない。最終確認は実機、iOSは Safari で

見た目の当たりを取る段階なら、デバイスモードでほぼ完結します。そのうえで「ここは実機」という線を持っておくと、無駄な確認作業がかなり減ります。