自社サイトがスマートフォンで使いやすいか確かめたいときは、まず実際の端末で一つの用件を最後まで試します。画面幅を変えるツールや速度の測定は、そこで見つけた問題を再現し、原因を探すために使います。
以前よく紹介されたGoogleの「モバイルフレンドリーテスト」は2023年12月に終了しました（Google Search Centralの告知）。現在の点検では、終了したツールの合格表示を探すのではなく、文字が読めるか、操作できるか、必要なページにたどり着けるかを記録します。改善の考え方はスマートフォン向けページの見直し方でも説明しています。ここでは点検の実施順に絞ります。
最初に、点検するページと用件を決める
全ページを一度に調べようとすると、問題を見つけても修正の順番を決めにくくなります。まずトップページ、よく見られるサービスページ、問い合わせページなど、利用者が通る主な経路を選びます。「サービス内容を読み、相談先まで進む」のように一つの用件を決め、開始URLと到着したいページをメモします。
同じページでも、メニューから入る場合と検索結果から直接入る場合では見える順番が違います。代表的な入口を一つずつ試し、端末、ブラウザ、画面の向き、日時を残しておくと再現しやすくなります。問い合わせフォームを実際に送る検査は、受信先とテストデータの扱いを決めてから行い、フォームの送信・受信確認手順に沿って別に記録します。
使う道具は、実機・画面幅・速度で役割を分ける
Googleは2023年12月にモバイルフレンドリーテストとSearch Consoleの「モバイルユーザビリティ」レポートを終了しました。古い記事や画面例にある入力先は、現在の点検手順として案内できません。
代わりに、実機では指での操作やキーボードの出方を確認し、Chrome DevToolsのデバイスモードでは幅を変えて崩れ方を再現します。PageSpeed Insightsでは読み込みの状況を調べます。それぞれ答えられる質問が異なるので、一つのスコアだけで「スマホ対応済み」と判断しません。
実機では「読む・探す・操作する」を通して見る
手元のスマートフォンで対象ページを開き、拡大せずに見出しと本文が読めるか、横へ画面全体がはみ出さないかを見ます。続けてメニューを開き、サービスや料金など目的の情報を探し、電話・問い合わせなどの案内まで進みます。リンクを押し間違えたり、固定表示のボタンが本文を隠したりしないかも確かめます。
表や地図のように二方向の操作が必要な部分は、ページ全体を横に動かさなくても扱えるかを確認します。W3Cのリフロー基準では、原則として320 CSSピクセル相当の幅で情報を失わずに読めることが重視されますが、二次元の配置が意味上必要な部分には例外があります。また、操作対象の大きさと間隔も確認します。数値だけを見て合格を断定せず、実際に押せるかも確かめます。
| 確認場所 | 実際にすること | 問題の例 | 記録すること |
|---|---|---|---|
| 最初の画面 | 会社名、提供内容、次の案内を読む | 重要な文が隠れる | URL、画面幅、隠れた場所 |
| 本文・画像 | 拡大せずに読み、画像の意味を確かめる | 文字が小さい、図の文字が読めない | 該当見出しと画像 |
| メニュー・リンク | 指で開閉し、目的のページへ進む | 押し間違い、閉じられない | 操作順と止まった地点 |
| 問い合わせ | 入力欄と送信前の案内を確認する | キーボードが欄を隠す | 端末・ブラウザと入力欄 |
| 読み込み | 回線条件を変えて主要内容の表示を見る | 画像や文字が長く空白になる | 回線条件と対象URL |
一つの端末で問題が見えなくても、すべての端末で同じとは限りません。利用者から不具合の連絡があった機種やブラウザは優先して追加し、画面の向きも変えて確認します。
画面幅の再現と速度測定で原因を絞る
Chrome DevToolsのデバイスモードでは、例えば320px、390px、タブレット相当の幅へ変え、どこで見出し、表、メニューが崩れるかを調べられます。ただしこれは机上の近似です。実機のCPU、ブラウザ、キーボードやタッチの挙動を完全には再現しないため、最後は実際の端末で再確認します。
PageSpeed Insightsは、モバイルとデスクトップの読み込みについて、利用可能な実ユーザーデータと、Lighthouseによる検査用データを分けて表示します。実ユーザーデータは対象URLに十分なデータがなければ表示されないことがあり、検査用データは一つの模擬環境の結果です。点数だけで操作性や検索順位を判断せず、指摘された画像、表示のずれ、読み込み順を対象ページで確かめます。画像が重い場合の具体的な見直しは画像圧縮と表示速度の点検を参照してください。
問題は再現できる形で残し、直した後に同じ手順で確かめる
「スマホで見づらい」だけでは、修正担当が同じ現象を見つけにくくなります。URL、端末とブラウザ、画面幅、操作順、期待した結果、実際の結果を一組で残します。スクリーンショットには個人情報や社内情報が写っていないか確認してから共有します。
修正の順番は、相談や購入など主要な用件が止まる問題を先にします。次に、読めない本文や押せないリンク、最後に細かな見た目を確認します。一度に複数箇所を変えると原因が分かりにくくなるため、変更内容を記録し、同じ端末・同じ操作で再テストします。可能なら別の画面幅でも崩れがないか見ます。
モバイル対応の点検は、一度の「合格」表示で終わりません。ページやフォームを変更した後、利用者の連絡があったとき、定期的な見直しのときに、同じ用件を実機でたどってください。
参考資料
- Google Search Central「ページ体験と終了したモバイル検査ツール」（2026年9月25日確認）
- Chrome DevTools「デバイスモードとその限界」（2026年9月25日確認）
- PageSpeed Insights「実ユーザーデータと検査用データ」（2026年9月25日確認）
- W3C WAI「リフローの基準」（2026年9月25日確認）
- W3C WAI「操作対象の大きさ」（2026年9月25日確認）
