スマホで見やすいホームページの作り方｜モバイルUIチェックリスト

スマートフォン対応は、画面幅に収まっているだけでは不十分です。訪問者が最初の要点を読み、メニューや電話・問い合わせボタンを選び、フォームを送信できるところまでを実機で確認する必要があります。本記事では、文字、タップ、固定要素、フォーム、表示速度を利用者の行動順に点検し、改善の優先順位を決める方法を解説します。

この記事で分かること

レスポンシブ対応とモバイルで使いやすい状態の違い
文字・画像・タップ領域・固定要素を確認する基準
問い合わせフォームをスマートフォンで完了しやすくする方法
実機テストとCore Web Vitalsを組み合わせる改善手順

モバイル改善のゴールは「目的の操作を完了できること」

デスクトップを縮小して横スクロールが出ない状態は、出発点にすぎません。電話する、所在地を確認する、資料を読む、商品を選ぶ、問い合わせを送るなど、ページごとの主要行動を片手でも完了できることをゴールにします。

Googleは同じURL・同じHTMLを画面サイズに応じて表示するレスポンシブデザインを、実装・保守しやすい構成として推奨しています。また、モバイル版の内容をインデックスとランキングに利用するため、重要な本文、見出し、画像の代替テキスト、構造化データ、メタデータをデスクトップ版と同等に保つ必要があります。狭い画面ではアコーディオン等に移しても、重要情報そのものを削らないようにします。

BtoBサイトの問い合わせ導線がページ間の移動とCTAを扱うのに対し、本記事は各画面をスマートフォンで読み、操作し、送信できるかを点検します。

先にテスト条件を決め、同じ手順で比較する

担当者の最新端末一台だけでは、画面幅、OS、ブラウザ、文字サイズ、通信条件の違いを見落とします。アクセス解析で利用の多い環境を優先しつつ、次の条件を最低限の確認表にします。

条件	最低限の確認	発見しやすい問題
画面幅	狭い端末、利用の多い端末、横向き	横スクロール、表・見出し・CTAの欠け
OS・ブラウザ	主要なiOS/SafariとAndroid/Chrome	入力欄、固定表示、スクロールの差
文字・ズーム	ブラウザの200%拡大、端末の文字サイズ変更	文字切れ、重なり、操作不能
通信・性能	モバイル回線、低速条件、性能の低い端末	画像待ち、操作遅延、レイアウト移動
入力経路	タッチ、キーボード、音声入力、入力補完	焦点の見失い、誤タップ、入力し直し

開発者ツールの端末表示は一次確認に便利ですが、アドレスバー、ソフトウェアキーボード、指での操作、通信、端末性能は実機と同じになりません。主要な導線は必ず実機で最後まで完了させます。

文字・画像・表を「拡大せず読めるか」で確認する

本文、注記、ボタン文言が背景との組み合わせで読める
見出しが途中で切れず、長い日本語や英数字も折り返す
画像内だけに重要な説明を置かず、本文にも同じ情報がある
画像に表示寸法を設定し、読み込み時に本文が大きく動かない
比較表は列を減らす、カード化する、または表だけ横スクロールできる
画面全体には意図しない横スクロールが出ない

WCAG 2.2のリフロー基準では、縦書き等の例外を除き、幅320 CSSピクセル相当で情報や機能を失わず、二方向スクロールを要求しないことが示されています。表や地図など二次元配置が意味上必要な部分は例外になり得ますが、ページ全体を横へ動かさせるのではなく、その部分だけに範囲を限定します。

タップ領域と固定要素は「誤操作」と「隠れ」を確認する

web.devは、適切なモバイルviewportを設定したサイトで、タップ対象をおおむね48デバイス非依存ピクセル、対象間を約8ピクセル空ける方法を推奨しています。一方、WCAG 2.2の達成基準2.5.8は、例外を除き24×24 CSSピクセル、または小さな対象の周囲に十分な間隔を確保することを最低基準としています。両者は同じ数値ではありません。社内の設計目標は48px前後を基本とし、狭い文章内リンクなどはWCAGの例外と間隔条件を個別に確認すると実務で判断しやすくなります。

メニュー、閉じるボタン、電話、CTA、ページ送りを親指で押し分けられる
リンクの見た目だけでなく、実際に反応する領域を確認する
固定ヘッダー・固定CTA・Cookie表示が本文やフォームを覆わない
画面回転やソフトウェアキーボード表示後も操作対象が見える
フォーカスされた項目が固定要素の背後へ完全に隠れない

問い合わせフォームは入力から完了画面まで通して試す

フォームは表示確認だけでなく、入力、エラー修正、送信、完了画面、通知、計測までを一つの処理としてテストします。web.devとW3Cは、各入力に意味のあるlabelを関連付け、用途に合うtypeやautocompleteを使うことを案内しています。メールにはtype="email"、電話番号にはtype="tel"を使うと、モバイルで入力しやすいキーボードを提示できます。

項目を減らす：初回対応に不要な情報を必須にしない
入力方法を合わせる：label、type、autocomplete、inputmodeを用途に合わせる
必須・任意を明示する：プレースホルダーだけを項目名にしない
エラーを近くに出す：何が問題で、どう直すかを該当欄の近くに示す
入力を保持する：一項目のエラーで他の入力を消さない
送信結果を伝える：二重送信を防ぎ、完了と次の連絡方法を明示する

表示速度は実測データと個別テストを分けて見る

Core Web Vitalsは、読み込みのLCP、操作への応答のINP、視覚的安定性のCLSで実利用時の体験を確認します。Googleが示す「良好」の目安は、75パーセンタイルでLCP 2.5秒以内、INP 200ミリ秒未満、CLS 0.1未満です。これらは問い合わせ数を保証する数値ではなく、利用体験を診断する基準として使います。

Search ConsoleのCore Web VitalsはURL群の実測傾向を確認する用途、PageSpeed InsightsやChrome DevToolsは個別ページの再現と修正候補を探す用途に分けます。実測データが少ない新しいページではラボ値しか出ない場合があるため、その旨を記録して判断します。

症状	最初に見る箇所	改善例
主要内容が遅い	ヒーロー画像、サーバー応答、Webフォント	画像の形式・寸法・優先度を見直す
タップ後に反応が遅い	長いJavaScript処理、外部タグ	処理を分割し、不要なスクリプトを減らす
読み込み中に位置が動く	画像・広告・埋め込みの領域	width・heightや予約領域を設定する

モバイルUIを改善する7ステップ

主要行動を決める：ページごとに「読む」「比較する」「電話する」「送信する」など一つの完了条件を置く
実利用を把握する：端末・OS・ブラウザ・入口ページと、導線上の離脱箇所を確認する
代表ページを選ぶ：トップ、サービス、記事、問い合わせ、完了画面を優先する
同じシナリオで操作する：検索結果やSNSから入り、目的の操作を完了するまで記録する
問題を分類する：読めない、押せない、隠れる、入力できない、遅いに分ける
影響と頻度で優先順位を付ける：完了不能、誤送信、主要導線の阻害から修正する
修正前後を再確認する：同じ端末・手順でテストし、別の画面幅に副作用がないか確認する

色や余白の好みだけで結論を出さず、「どの端末で、どの操作が、どの時点でできなかったか」を記録します。修正内容、確認日、担当者、再テスト結果を残すと、次回リニューアルにも使える品質基準になります。

モバイルUIの公開前チェックリスト

読む・理解する

viewportが設定され、ページ全体に横スクロールが出ない
見出し、本文、注記が拡大なしで読める
200%拡大や文字サイズ変更でも内容が切れない
重要な本文・見出しをモバイルだけ削っていない
画像の内容を説明する適切なaltがある

移動・操作する

メニューを開閉でき、開いた後もスクロールできる
主要CTAを他のリンクと押し分けられる
タップ対象の大きさと間隔を確認した
固定ヘッダー・固定CTAが内容やフォーカスを隠さない
リンク、電話、地図、外部ページが意図どおり開く

入力・送信する

各入力にlabelがあり、必須・任意が分かる
内容に合うキーボードと入力補完が使える
エラー箇所と修正方法が画面内で分かる
キーボード表示中も入力欄と送信ボタンを確認できる
送信、完了画面、通知、計測まで実機で確認した

速度・安定性

主要画像を表示サイズに合わせ、不要な大容量素材を減らした
画像・埋め込みに表示領域を確保した
低速回線でも主要内容と操作が利用できる
Core Web Vitalsの実測とラボ値を区別して記録した

よくある質問

スマホ対応はレスポンシブデザインだけで十分ですか？

十分とは限りません。画面幅への追従に加え、読みやすさ、タップ領域、固定要素、入力、速度、完了までの導線を確認してください。レスポンシブは構成方法であり、操作の完了を保証するものではありません。

文字サイズは何pxにすればよいですか？

すべてのサイトに共通する一つの正解はありません。書体、太さ、行間、背景とのコントラスト、利用者、端末で読みやすさが変わります。実機で拡大なしに読めるか、200%拡大や端末の文字サイズ変更で切れないかを確認します。

ボタンは24pxと48pxのどちらに合わせますか？

WCAG 2.2の最低基準と例外を満たす確認に加え、web.devが推奨する約48デバイス非依存ピクセルと約8pxの間隔を設計目標にすると誤タップを減らしやすくなります。文章内リンクなど、対象の性質に応じて判断してください。

PageSpeed Insightsの点数を100にすべきですか？

100点自体を目的にしません。主要なページで実測のLCP・INP・CLSと利用者が操作を完了できるかを確認し、遅い画像や処理など原因を修正します。ラボ値と実測値は対象や計測条件が異なります。

どのページから改善すべきですか？

問い合わせや購入に近いページで、利用者が多く、完了不能や誤操作が起きる箇所を優先します。トップページだけでなく、検索から直接入る記事、サービスページ、フォーム、完了画面まで確認してください。