PCでスマートフォン向けWebサイトを確認する最短手順は、Google Chromeで対象ページを開き、DevToolsのDevice Toolbarを有効にすることです。Windows／Linuxでは通常Ctrl+Shift+IでDevToolsを開き、Ctrl+Shift+Mでデバイス表示を切り替えます。macOSでは対応するCommandキーのショートカットを使います。ただしDevice Modeはスマホ体験の近似であり、実際のiPhoneやAndroid端末を動かしているわけではありません。公開前は実機と実ブラウザーで確認してください。
Device Toolbarを開く
- Chromeで確認したいURLを開き、ログイン状態と環境が本番・検証のどちらか確認する。
- ページ上で右クリックして「検証」を選ぶか、キーボードショートカットでDevToolsを開く。
- DevTools上部のスマートフォンとタブレット形の「Toggle device toolbar」を選ぶ。
- DimensionsからResponsiveまたは代表端末を選び、ページを再読み込みする。
- 幅、高さ、DPR、向き、タッチ、通信速度を用途に応じて変えて確認する。
DevToolsの配置やボタン名はChrome版と画面幅で変わります。ショートカットが別機能に割り当てられている場合は、メニューからMore toolsやDevice Toolbarを探します。ブラウザー拡張が表示へ影響することがあるため、再現テストでは管理されたクリーンプロファイルも使います。シークレットモードでも拡張、キャッシュ、企業ポリシーが完全に消えるとは限りません。
Responsiveで境界を探す
最初から特定の端末プリセットだけを見るより、Responsiveモードで幅を連続的に変え、レイアウトが崩れる境界を探します。320、375、390、412、768 CSSピクセルなど代表幅だけでなく、その間もドラッグします。カードが1列から2列へ変わる直前、ナビゲーションが折りたたまれる直前、長い見出しが改行する幅を重点的に見ます。端末名プリセットは製品の完全な実装ではなく、viewportやUser-Agentなど一部設定の組み合わせです。
- 横スクロールが本文に発生しないか。意図した表やコードブロックだけが個別にスクロールするか。
- ヘッダー、メニュー、モーダル、Cookie通知が画面を覆い、閉じられなくならないか。
- 見出し、ボタン、価格、日付、長いURL、多言語テキストがはみ出さないか。
- タップ対象が近すぎず、フォーカス表示が見え、キーボードだけでも操作できるか。
- 画像と動画が親幅を超えず、縦横比が崩れず、レイアウト移動を起こさないか。
- 固定フッターやチャットが入力欄、送信ボタン、ブラウザーUIと重ならないか。
CSSピクセルとDPR
Device Toolbarの幅・高さは基本的にCSSピクセルです。DPR（Device Pixel Ratio）は1 CSSピクセルを何個の物理画面ピクセルで描くかという比率で、高密度画面の画像選択や描画へ影響します。幅390、DPR3だから画像のCSS表示幅が1170になるわけではありません。レスポンシブ画像のsrcset、CSSのimage-set、canvasなどを確認するときにDPRを変え、Networkパネルで実際に取得した画像URLと転送量を見ます。
縦向きと横向き
回転ボタンでportraitとlandscapeを切り替えます。横向きでは高さが急に減り、固定ヘッダーやモーダルが本文を覆う問題が出やすくなります。画面方向のCSSメディアクエリだけでコンテンツを非表示にせず、幅と高さ、入力方式、実際の利用目的を考えます。折りたたみ端末や分割画面は単純な縦横だけでは表せないため、実機または対応エミュレーターも使います。
touchとhoverを確認する
Device Modeではタッチイベントと丸いポインターを近似できます。hoverしたときだけサブメニューや説明が出る設計は、タッチ端末で到達できない可能性があります。タップ、長押し、スクロール、ピンチの一部を試せますが、OSの戻るジェスチャー、ソフトウェアキーボード、触覚、複数指、実際の誤タップまでは再現できません。実機で片手操作とキーボード表示時のレイアウトを確認します。
User-Agent変更だけをスマホ対応と考えない
端末プリセットはUser-AgentやClient Hintsを近似する場合がありますが、レスポンシブデザインの中心はviewportとCSSです。サーバー側がUser-Agentだけで別HTMLを返すと、キャッシュ、タブレット、検索エンジン、折りたたみ端末、新しいUA形式で誤判定しやすくなります。機能検出、レスポンシブCSS、同一URL・同一主要コンテンツを基本にし、サーバー分岐が必要ならキャッシュキーとテストケースを明示します。
Networkで遅い回線を近似する
高速な開発PCでは、モバイル回線での読み込み遅延を見落とします。NetworkパネルまたはDevice ModeのThrottlingでFast 3G、Slow 3Gなどを選び、キャッシュを無効にした初回表示と、キャッシュが効いた再訪を分けて測ります。スロットリングはPC上の相対的な近似で、実際の電波揺らぎ、パケット損失、基地局遅延、データ節約モードを完全には再現しません。
- HTML、CSS、JavaScript、フォント、画像、広告、解析タグのリクエスト数と転送量。
- 404、500、CORS、mixed content、証明書、リダイレクトループ。
- 最初の表示に不要な大画像、未使用JavaScript、第三者スクリプトの待ち時間。
- キャッシュヘッダー、圧縮、CDN、Cookieによるキャッシュ分岐。
- 遅い応答時にもローディング状態が分かり、操作を二重送信しないか。
CPUスロットリングとPerformance
Device ModeやPerformanceパネルでCPU低速化を選ぶと、JavaScript実行、レイアウト、描画が遅い端末に近い状況を作れます。ただし開発PCのCPUを倍率で遅くするだけで、ARMアーキテクチャ、GPU、熱制限、メモリ圧迫を再現するものではありません。操作を記録し、長いタスク、レイアウトシフト、スクロールのカクつき、入力応答を確認した後、代表的な低価格実機で再検証します。
Consoleのエラーを確認する
見た目が合っていても、ConsoleにJavaScript例外、非推奨API、CSP違反、アクセシビリティ警告が出る場合があります。ページ読み込み前にConsoleを開き、再読み込みして最初から確認します。第三者拡張が出したエラーとサイト自身のエラーをInitiatorやファイルURLで分けます。Consoleへ本番のトークンや個人情報を貼らず、コピーするログはマスキングします。
media queryの境界をたどる
Device ModeのMore optionsからmedia queries表示を有効にできる版では、min-widthとmax-widthの境界を可視化し、該当CSSへ移動できます。ブレークポイントを有名端末の幅だけで決めるのではなく、コンテンツが崩れる地点に置きます。CSSの読み込み順、詳細度、コンテナクエリ、theme.json、プラグインの追加CSSも影響するため、Computedパネルで最終的に採用された値を確認します。
スクリーンショットの用途と限界
Device Toolbarからviewportまたはfull size screenshotを取得できます。レビュー証跡にはURL、日時、Chrome版、viewport、DPR、認証状態、コミットや公開版を添えます。スクリーンショットは見た目の一瞬しか示さず、キーボード操作、読み上げ順、アニメーション、タップ、通信失敗は証明しません。個人情報、管理バー、未公開コンテンツ、Cookieを含む画像を公開チケットへ添付しないでください。
キャッシュとService Worker
修正したのに古いCSSが見える場合は、NetworkのDisable cache、通常再読み込み、ハード再読み込み、Service Worker、CDN、WordPressキャッシュ、ブラウザーキャッシュを順に切り分けます。すべてを一度に削除すると原因が分からなくなるため、一層ずつ確認します。本番キャッシュの全消去は利用者全体へ負荷を与える可能性があり、承認されたパージ範囲を使います。
ログイン状態と公開表示を分ける
WordPressなどでは管理者ログイン中だけ管理バー、未圧縮資産、プレビューCookie、A/Bテスト除外が適用されることがあります。管理者表示で直ったから公開利用者も直ったとは限りません。公開用の新しいブラウザープロファイルまたは権限のないテストアカウントで確認し、会員、管理者、未ログイン、Cookie同意前後を分けます。実ユーザーのセッションCookieを共有しません。
実機リモートデバッグ
Android版Chromeは、開発者向けオプションとUSBデバッグを有効にし、PCのDevToolsから実機ページをリモート検査できます。USBデバッグは接続PCへ強い権限を与えるため、所有者が管理する検証端末と信頼できるPCだけで使い、接続時のRSA確認を読み、作業後は許可を取り消します。私物端末や本番アカウントの通知・写真・パスワードを画面共有しません。組織のMDMと情報セキュリティポリシーを優先します。
iPhone/iPadのSafariやiOS内WebViewはChrome Device Modeでは再現できません。macOSのSafari Web Inspector、クラウド実機サービス、手元実機など、対象ブラウザーに合う方法を使います。iOS上のChromeも基盤エンジンやOS制約がデスクトップChromeと異なるため、Chromeプリセットだけで合格にしません。
実機で確認する項目
- アドレスバーや下部バーが出入りするときのviewport高さと固定要素。
- ノッチ、安全領域、丸角、ホームインジケーター、折りたたみ・分割画面。
- ソフトウェアキーボード表示、入力種類、オートフィル、パスワードマネージャー。
- 実際のタッチ、スクロール慣性、戻るジェスチャー、画面回転、ズーム。
- 省電力、低メモリ、低速回線、オフライン復帰、バックグラウンドからの再開。
- VoiceOver、TalkBack、外付けキーボード、文字拡大、ダークモード、コントラスト。
確認マトリクスを残す
端末名を大量に並べるより、レイアウト幅、DPR、入力方式、ブラウザーエンジン、OS版、性能階層、認証状態を組み合わせた代表ケースを決めます。バグ票には再現URL、手順、期待結果、実際の結果、viewport、DPR、Chrome／OS版、Console・Networkの根拠を添えます。公開前には最低でも小型スマホ、標準スマホ、タブレット、デスクトップ、iOS Safari、Android Chromeを実機または信頼できる実機環境で確認します。
PCのDevice Modeは、レスポンシブ崩れを素早く探す第一段階として非常に有効です。幅を連続的に動かし、DPR、回転、touch、低速回線、CPUを変え、ConsoleとNetworkを確認します。その結果を実機へ引き継ぎ、OS UI、キーボード、Safari/WebView、支援技術まで検証して完成です。
コメント