ホームページのスマホ表示を公開前に確認する方法｜7つの実機チェック
テストサイトをパソコンで縮小し、「スマホ幅でも崩れていない」と確認しただけでは、公開前のチェックは終わりません。実際のスマートフォンでは、指での操作、画面下のホームインジケーター、ブラウザのアドレスバー、文字入力時のキーボード、通信回線などが表示に影響します。パソコン上では整って見えたページでも、実機ではボタンが押しにくい、入力欄がキーボードに隠れる、固定メニューが本文を覆うといった問題が起こります。
公開前に必要なのは、すべての端末を完璧に再現することではありません。確認する端末とページを先に決め、同じ順番で操作し、見つけた不具合を再現できる形で残すことです。最低限、異なるOS・ブラウザの実機を組み合わせ、ファーストビュー、文字、ボタン、フォーム、画像や動画、横スクロール、表示速度まで一続きで確認します。
この記事は、制作会社からテスト用URLを受け取った発注者や社内担当者が、専門的な検証ツールを使わなくても公開判断を進められるようにまとめています。スマホ対応の仕組みやレスポンシブデザインの基本から確認したい場合は、先に「スマホ対応って何？中小企業向けの基本解説」を読むと、今回の実機チェックとの役割を分けやすくなります。
確認を始める前に、端末と対象ページを絞る
スマホ表示の確認で最初につまずきやすいのは、「どの端末で、どこまで見ればよいか」が決まっていないことです。機種、OS、ブラウザ、画面幅の組み合わせは数が多いため、思いつくまま確認すると、同じページばかり見たり、問い合わせ完了画面のような重要箇所を見落としたりします。
まず、実際の利用者に近い組み合わせを優先します。アクセス解析で端末やブラウザの傾向が分かるなら、その上位を基準にします。データがまだない新規サイトでは、次のような組み合わせから始めると現実的です。
- iPhoneでSafariを使う
- Android端末でChromeを使う
- 可能なら、画面が小さめの端末か少し前の端末を一台含める
- 縦向きを基本にし、画像、表、地図など幅の影響が大きい箇所は横向きでも見る
- Wi-Fiだけでなく、モバイル回線でも一度開く
社内に片方のOSしかない場合は、パソコンのデバイス表示で幅を広く確認したうえで、手元の実機を最後の操作確認に使います。別のOSを持つ社員に、主要ページだけ同じ手順で見てもらう方法でも構いません。大切なのは、パソコン上の疑似表示を「実機の代わり」にするのではなく、確認範囲を広げる補助として使うことです。
対象ページも先に決めます。全ページを同じ深さで見るより、利用者の行動に関わるページから順に確認した方が、公開を止めるべき不具合を早く見つけられます。
- トップページ
- 主力サービスや商品のページ
- 料金、プラン、よくある質問など比較に使うページ
- 問い合わせ、予約、購入などの入力ページと完了ページ
- 会社概要、アクセス、地図、電話番号があるページ
- 表、動画、スライダー、カレンダー、PDFなど特殊な表示を含むページ
テスト用URLにパスワードがある場合は、スマートフォンから開けることも事前に確かめます。社内ネットワークやVPNの中だけで見られる環境なら、制作会社と確認方法を合わせておかないと、表示確認以前にページへ入れません。フォームの送信先や自動返信も、テスト時に実在の顧客へ届かない設定かを確認しておくと安全です。
公開前のスマホ実機チェックは7項目で進める
見た目だけを眺めるのではなく、利用者がページを開き、内容を読み、操作し、必要な行動を完了する順番で確認します。次の7項目を同じ端末・同じページで通すと、抜け漏れを減らせます。
公開前のスマホ実機確認は、表示、操作、入力、通信、不具合記録までを一つの流れとして扱います。
1．実機とブラウザの組み合わせを固定する
最初に、どの端末とブラウザで確認したかを記録します。「自分のスマホ」だけでは、修正後に同じ条件を再現できません。端末名、OS、ブラウザが分かる範囲で十分です。たとえば「iPhone 15／iOS／Safari」「Android端末／Chrome」のように残します。OSやブラウザの細かなバージョンまで確認できる場合は追記しますが、非技術者が最初から完全な情報をそろえる必要はありません。
同じテスト用URLを各端末で開き、まず縦向きでトップページから主要導線をたどります。その後、画像や表の崩れが気になるページだけ横向きでも確認します。ブラウザの上部や下部にある操作部分は、スクロールすると高さが変わることがあります。ページを少し下へ動かし、上へ戻したときに、固定ヘッダーや画面下のボタンが急に重なったり、位置が跳ねたりしないかも見ます。
パソコンのChromeなどにあるデバイス表示は、画面幅を連続的に変えて崩れを探すのに便利です。ただし、パソコン上でスマートフォンの状態を近似しているだけで、実際の端末上で動いているわけではありません。タッチ操作、端末固有の文字描画、キーボード、処理性能まで同じにはならないため、最終確認は実機で行います。
ここでの合格条件は、端末ごとに完全に同じ見た目になることではありません。必要な情報が欠けず、操作不能な箇所がなく、画面幅に応じた違いが意図したものになっていることです。端末ごとの差をすべて不具合扱いにすると、本当に直すべき問題が埋もれてしまいます。
2．ファーストビューと文字の折り返しを見る
ページを開いた直後に見える範囲では、「何のページか」「誰に向けた内容か」「次に何を見ればよいか」が理解できるかを確認します。スマホは表示できる面積が小さいため、パソコンでは同時に見えていた見出し、写真、説明、ボタンが縦に分かれます。見出しだけが大きく表示され、肝心の説明や次の行動が何画面も下へ送られていないかを見ます。
固定ヘッダー、キャンペーン帯、Cookieの案内、チャットボタンなどがある場合は、それらがファーストビューを覆っていないかも重要です。特に画面の上と下に固定要素が同時にあると、本文を読める範囲が極端に狭くなります。閉じるボタンが小さすぎる、閉じても再表示される、スクロールしても大部分を占有するといった状態は、実機で触らないと気づきにくい問題です。
文字は「読めるか」だけでなく、折り返しによって意味が分断されていないかを確認します。会社名、商品名、サービス名、金額、日付、電話番号、メールアドレスなど、長くなりやすい文字列を重点的に見ます。見出しの最後の一文字だけが次の行へ落ちる、句読点が行頭に残る、単語の途中で不自然に切れる、行間が詰まって上下の文字が重なる場合は修正対象です。
本文では、画面いっぱいに長い一文が続いていないか、段落間の余白が狭すぎないか、リンク文字が通常文と見分けられるかを見ます。アコーディオンやタブで情報を整理しているページでは、開いた後の文章まで確認してください。パソコン側にある重要な説明が、スマホでは省略されたり、開けない要素の中へ隠れたりしていないことも確かめます。
3．ボタンの大きさと位置を指で確認する
ボタンは見た目の大きさではなく、実際に指で押して確認します。メニュー、電話番号、地図、ページ内リンク、アコーディオン、タブ、スライダー、問い合わせボタンなど、押せる場所を一通り操作します。文字の周囲まで反応するのか、文字そのものしか押せないのかによって、使いやすさは大きく変わります。
隣り合うボタンやリンクが近すぎると、意図しない方を押しやすくなります。指を置いたときに別のリンクへ移動しないか、タップ後に押したことが分かる反応があるか、移動先が正しいかを見ます。戻る操作をしたときに、元の位置へ戻れるかも確認すると、ページ内リンクやタブの不具合を見つけやすくなります。
画面下へ固定された問い合わせボタンや購入ボタンは、スマホでは便利な一方、本文末、フォームの同意欄、送信ボタン、動画の操作部分を覆うことがあります。画面の一番下までスクロールし、最後の文字やボタンを隠していないかを確認します。ホームインジケーターがある端末では、画面最下部の操作と重なって押しにくくないかも見ます。
ボタンサイズを測る専門的な基準もありますが、発注側の実機確認では、数字だけで合否を決めるより「片手で迷わず押せるか」「隣の操作へ誤って触れないか」「押した結果が分かるか」を確かめる方が実用的です。小さなアイコンだけで意味を伝えている場合は、初めて見る人にも役割が分かるかを確認します。
4．フォーム入力とキーボード表示を最後まで試す
問い合わせフォームは、入力欄が並んでいるだけでは完成とは判断できません。実機で最初の項目から入力し、確認画面、送信、完了画面、自動返信まで一連の流れを試します。テスト送信には、氏名や本文へ「公開前テスト」と分かる情報を入れ、送信先を制作会社と共有しておくと、本番の問い合わせと混ざりません。
各入力欄をタップしたとき、目的に合うキーボードが表示されるかを見ます。電話番号なら数字を入力しやすい配列、メールアドレスなら「@」を使いやすい配列が表示されると入力が楽になります。次の項目へ進むキーが働くか、入力中の欄がキーボードの後ろへ隠れないか、画面が不自然に拡大されたまま戻らない状態にならないかも確認します。
必須項目を空欄にした場合、形式の違うメールアドレスを入れた場合、文字数を超えた場合など、エラーが出る条件も試します。エラーメッセージが画面外に表示されて気づけない、赤色だけで場所を示している、入力内容がすべて消える、エラー箇所へ戻れないといった問題は、離脱につながります。
選択肢、日付、プルダウン、ファイル添付、写真撮影、個人情報保護方針への同意欄がある場合は、それぞれ操作します。キーボードを開いた状態で固定ボタンが重なることもあるため、最後の送信ボタンまで無理なく到達できるかを確認してください。送信後は、完了画面が表示されること、二重送信が起きないこと、自動返信の件名や本文が読めること、問い合わせ先に内容が届くことまでが確認範囲です。
5．画像・動画・埋め込みと横スクロールを確認する
画像は画面内に収まっていても、重要な部分が切れていれば問題です。人物の顔、商品の形、施工箇所、図表の注釈など、内容を理解するために必要な部分が残っているかを見ます。縦長と横長の写真が混在するページでは、同じ枠へ無理に合わせた結果、写真ごとに切れ方が大きく変わることがあります。画像がぼやける、読み込み後に高さが変わって本文が動く、端末を横向きにすると極端に拡大される場合も記録します。
動画は再生ボタンが押せるか、音声の有無が分かるか、全画面表示から戻れるかを確認します。自動再生する動画は、通信量や操作の妨げにならない設定かを見ます。地図、SNS投稿、予約カレンダー、外部フォームなどの埋め込みは、枠の中だけが細くなったり、操作時にページ全体のスクロールが止まったりしやすいため、実際に触って確かめます。
ページの余白部分に指を置き、左右へ軽く動かして、ページ全体が横にずれないかも確認します。画像、表、長いURL、埋め込み要素のどれかが画面幅を超えると、本文全体が横に揺れることがあります。意図した横スクロールと、不具合による横スクロールは分けて判断します。料金表や比較表を枠内だけ横へ動かす設計はあり得ますが、その場合は表の外側まで一緒に動かず、横へ見られることが利用者に伝わる状態が必要です。
カルーセルやスライダーは、左右の操作だけでなく、縦スクロールを邪魔しないかも見ます。スライダー上で指を動かしたときにページを上下へ進められない、勝手に次の画像へ移って内容を読めない場合は、見た目が整っていても操作上の問題があります。
6．Wi-Fi以外でも初回表示を確認する
社内や自宅の速いWi-Fiだけで見ると、実際の利用環境で起きる遅さを見落とします。一度Wi-Fiを切り、モバイル回線で主要ページを開きます。すでに何度も見たページは画像やファイルが端末内に残り、速く見えることがあるため、プライベートブラウズやシークレットモードを使うか、まだ開いていないページで初回表示を確認します。
見るべきなのは、単純な秒数だけではありません。最初に白い画面が長く続かないか、見出しより大きな画像が先に場所を占めないか、文字が表示された後に書体が変わってレイアウトが動かないか、メニューやボタンが見えているのに押せない時間がないかを確認します。重い動画や地図がある場合でも、ページの主な説明や問い合わせへの導線まで一緒に待たされないことが重要です。
PageSpeed Insightsなどの計測ツールは、原因を絞り込む補助になります。ただし、計測値は端末、回線、サーバーの状態、キャッシュの有無などで変わります。点数だけを公開条件にせず、実機での初回表示、スクロール、タップ、フォーム入力に支障がないかと組み合わせて判断します。
遅さを報告するときは「遅い」とだけ書かず、どの回線で、どのページを初めて開き、どの要素がどの順番で表示されたかを残します。画面録画があると、途中の白画面、画像の遅延、レイアウトの移動を制作側が確認しやすくなります。通信状況が不安定な場所で一度だけ起きた場合は、同じ条件で再現するかも確かめます。
7．不具合をURL・端末・画面で記録する
実機確認の価値は、不具合を見つけることだけでなく、修正できる情報へ変えることにあります。「スマホで崩れています」「ボタンがおかしいです」だけでは、制作側が同じ状態を再現できず、確認の往復が増えます。一件の不具合につき、次の情報をまとめます。
- 問題が起きたページのURL
- 端末名、OS、ブラウザ
- どこまでスクロールし、何を操作したか
- 実際に起きた状態と、本来期待する状態
- 問題箇所が分かるスクリーンショットまたは画面録画
- 毎回起きるか、ときどき起きるか
スクリーンショットには、問題箇所を丸で囲むなど最低限の印を付けると伝わりやすくなります。ただし、一枚の画像へ複数の修正指示を詰め込みすぎると、どの内容がどのURLに対応するのか分かりにくくなります。ページや症状が違うものは分けて記録します。
優先度も簡単に分けておくと、公開判断がしやすくなります。問い合わせや購入を完了できない、重要な説明が見えない、別ページへ進むリンクが誤っている、本文を読めないほど横へはみ出す問題は、公開前に止めて直す対象です。文字の重なり、重要画像の切れ、誤タップしやすい操作は、主要ページであれば公開前の修正を優先します。余白や改行位置の微調整は、利用を妨げない範囲なら公開後の改善へ分けられます。
修正後は、問題があった端末とページだけでなく、その前後の導線も再確認します。固定ボタンの高さを直した結果、別の画面幅で本文が隠れるなど、一箇所の修正が他の端末へ影響することがあるためです。修正前と同じ条件を記録しておけば、再確認の基準がぶれません。
確認は「主要導線、全体表示、例外」の順で進める
限られた時間で確認する場合は、ページを上から順に眺めるより、利用者が目的を達成する流れから通します。最初にトップページから主力サービスへ進み、問い合わせや予約を入力して完了画面まで到達します。この一本の導線をiPhoneとAndroidで確認すれば、ヘッダー、本文、ボタン、フォーム、通知メールなど、公開を止める問題を早い段階で見つけられます。
次に、料金、会社概要、アクセス、よくある質問、ブログなど、主要なテンプレートを確認します。最後に、横向き、モバイル回線、長い文章、長い商品名、エラー表示、ファイル添付といった例外条件を見ます。この順番なら、細かな余白の調整に時間を使い切る前に、事業上重要な導線の合否を判断できます。
公開判定では、「すべての端末で一画素も違わないこと」ではなく、次の三点を基準にします。
- 利用者がページの目的を理解できる
- 読む、移動する、入力する、送信する操作を完了できる
- 端末や回線が変わっても、重要情報が欠けたり操作不能になったりしない
修正依頼を出した後は、公開直前にもう一度同じ順番で確認します。確認中にも本文、画像、タグ、フォーム設定が更新されるため、最初に合格した箇所が最後まで同じとは限りません。公開日を決める際は、修正日だけでなく、再確認と承認に使う時間も確保しておくと、急いで見落とす状況を避けられます。
PCの縮小プレビューと実機は役割を分ける
パソコンのデバイス表示は不要ではありません。複数の画面幅を短時間で切り替え、特定の幅だけで起きる重なりや横はみ出しを探すには効率的です。制作側が原因を調べる際にも役立ちます。一方、実機は、指の届き方、キーボード、ブラウザの表示領域、端末の処理性能、モバイル回線を含めた利用体験を確認するために使います。
端末を一台しか用意できない場合は、パソコン上で幅を細かく動かして表示崩れを探し、その後に実機で主要導線とフォームを通します。別OSの確認は、社内の協力者へURLと確認項目を渡す、制作会社に画面録画を依頼するなど、条件を明記して補います。端末数を増やすこと自体が目的ではなく、異なる条件で同じ不具合が起きないかを確かめることが目的です。
まとめ｜公開前は「見える」ではなく「使える」まで確認する
ホームページのスマホ表示は、パソコン上の縮小プレビューで形を整え、実機で利用者の行動を通して確認します。端末と対象ページを先に決め、ファーストビュー、文字、ボタン、フォーム、画像や動画、横スクロール、表示速度を同じ順番で見れば、非技術者でも公開を止めるべき問題を見分けやすくなります。
テスト用URLが届いたら、まずトップページから問い合わせ完了までを二つの端末・ブラウザで通し、問題があればURL、端末、操作、期待する状態、画面を一件ずつ記録します。修正後も同じ条件で再確認し、重要な情報が読めることと、必要な操作を最後まで完了できることを確認してから公開へ進みます。
