LPのスマホ対応を見直すには｜表示・タップ・入力・速度の確認手順

LPをスマートフォンで開いたとき、文字が画面からはみ出す、料金表の条件が読み取れない、入力欄が追従ボタンに隠れる。こうした問題は、見た目を小さく整えるだけでは解決しません。読む、比較する、操作する、入力を直す、相談の受付を確かめるという一連の行動を通して点検する必要があります。

この記事は、公開中のLPを管理する企業の担当者に向けた実務ガイドです。W3Cのアクセシビリティ資料とGoogleの性能測定資料、公開されたLP改善事例を参照し、問題の記録から制作会社への依頼、公開後の確認まで説明します。文中の設備点検サービスや修正票は説明用の想定例であり、Acquaやお客様の成果実績ではありません。

スマホ対応を直せば問い合わせが一定の割合で増えるとは限りません。操作できない問題は具体的に直し、事業の成果は条件を揃えて別に評価します。自社で実装できなくても、どの画面で何が起き、どうなれば修正完了なのかを伝えられることを目指しましょう。

1. スマートフォンで困る場面を、条件付きで記録する

点検するページと、利用者の目的を決める

まず対象のURLと、そこで利用者にしてほしい行動を一つ書きます。「スマホ対応を確認する」だけでは範囲が広いため、たとえば「設備点検の対応地域と料金の考え方を読み、相談内容を送る方法を探す」と具体化します。広告から入るLPなら、広告の案内と最初に見える内容が食い違っていないかも確認対象です。

点検はページを眺める作業と、目的の行動を行う作業に分けると進めやすくなります。文字や画像の崩れを先に探し、その後でサービス内容、条件、事例、相談先を順にたどります。最初から「このボタンを押す」と答えを決めてしまうと、実際の利用者がボタンを見つけられるか、押す前に必要な情報を読めるかを見落とします。

端末・向き・表示設定・入力状態を揃える

不具合を見つけたら、スマートフォンの機種、OS、ブラウザー、画面の向き、文字の拡大設定を残してください。同じ機種でも設定やブラウザーの表示領域で折り返しは変わります。「iPhoneで崩れます」よりも、対象URLと画面の状態が分かる記録の方が、制作担当者が再現するまでの時間を減らせます。

入力フォームでは、キーボードを閉じた状態だけでは足りません。文字を入力している途中、選択肢を開いた状態、入力エラーが出た状態、前の画面へ戻った状態を区別します。画面下の固定ボタンは、通常時には問題がなくても、キーボードが表示されて使える高さが減ると邪魔になることがあります。画面の高さと操作中の変化も点検に含めます。

PCの開発者ツールによる表示幅の変更は、折り返しや画像サイズを調べる補助になります。ただし、それだけで実機のキーボードやタッチ操作まで確認したことにはなりません。手元で再現できない端末は「未確認」と記録し、影響が大きい操作から実機確認を依頼します。全端末を一度に集めるより、確認できた範囲を明らかにする方が次の判断につながります。

見つけた不具合と、成果についての仮説を分ける

「ボタンの文字が切れて読めない」は表示上の事実です。一方、「ボタンが小さいから問い合わせが少ない」は、操作や流入のデータを確認する必要がある仮説です。この二つを同じ欄へ書くと、表示を直した時点で問い合わせ不足も解決したと扱いやすくなります。現象、困る理由、成果への仮説を別々に残してください。

記録の想定例は「料金表を読むために画面を横へ動かすと、ページ全体がずれて相談ボタンの右半分が見えなくなる」です。ここに再現操作と画像を添えれば、まずページ全体の横はみ出しを調べるという依頼ができます。離脱率や相談数がどう変わるかは、修正内容と期間を記録してから評価します。

2. 狭い画面でも内容と比較材料を読み取れるようにする

幅に合わせて折り返し、拡大しても内容を失わない

W3Cのリフローの解説では、縦方向に読むコンテンツについて、幅320 CSSピクセル相当でも情報や機能を失わず、二方向のスクロールを必要としない条件を扱っています。これは特定のスマートフォン機種の寸法を決める規則ではありません。狭い表示領域や拡大時にも、読む順序と操作を保つための考え方です。

実務では、長い見出し、英数字の続く商品名、URL、画像、横並びの説明を確認します。文字が外へ突き出したときに、はみ出した部分を隠す設定だけを追加すると、内容が読めなくなる場合があります。折り返しを許可する、並び方を変える、画像を領域に収めるなど、原因に対応した修正を制作担当者へ依頼します。

見出し・料金・条件を、読む順序の中で確認する

スマートフォンでは複数の情報が縦へ並ぶため、PCで隣にあった説明が離れることがあります。料金だけが先に大きく見え、対象条件や追加費用の説明が何画面も下にあると、誤った理解のまま相談へ進むかもしれません。単純にすべてを短くする前に、どの情報を一緒に読む必要があるかを整理します。

想定例として、設備点検の料金に「対応地域内」「基本作業のみ」という条件があるなら、価格の近くで確認できる配置を検討します。長い条件は詳しい説明へつなげられますが、価格の意味を変える条件まで折りたたみの奥へ隠さないようにします。写真やキャッチコピーだけで最初の画面を使い切っている場合も、誰向けの何のサービスかが伝わるかを確認してください。

文章を何行以内にするかは、文字サイズや画面幅によって変わります。「必ず3行」などの固定ルールより、一つの段落で一つの話を説明できているか、見出しだけ読んでも内容の場所が分かるかを見ます。PC版とスマホ版で別々の文章を持つ場合は、更新のたびに片方だけ古くならない管理方法も必要です。

比較表と図解は、読むための操作まで用意する

プラン比較など、行と列の関係に意味がある表を無理に縮めると、文字が小さくなり比較しにくくなります。前述のW3Cの解説にも、二次元の配置が必要な内容の扱いがあります。表の領域内だけを横に動かせる形や、項目ごとに順番を保って並べる形を検討し、ページ全体の横はみ出しと区別します。

横に動かす表では、続きがあること、どの列を比較しているか、操作後に本文へ戻れることを確認します。画像の図解は拡大して読めるリンクを用意し、要点を本文でも説明します。画像が表示されなければ料金条件が一切分からない、という状態を避けるためです。読みやすさの確認は、画像ファイルが読み込めたかどうかだけでは終わりません。

3. ボタンの押しやすさと、追従表示の重なりを点検する

見える形と、実際に押せる範囲を分けて見る

W3Cのターゲットサイズの解説は、WCAG 2.2のAA基準として24×24 CSSピクセルを基本とし、間隔や文中リンクなどの例外を説明しています。これは「あらゆるボタンを24ピクセルにすれば使いやすい」という意味ではありません。最低条件と、主な相談ボタンを余裕を持って押せる設計は区別します。

画面上では大きな枠が見えていても、文字の部分しか反応しない場合があります。逆に、隣のボタンと押せる範囲が重なっていれば、意図しない行き先へ進むかもしれません。ボタンの中央だけでなく周辺、隣接するリンクとの間隔も確認します。寸法の測定と、指で狙った操作を行えるかの点検を合わせて依頼すると、見た目だけの修正になりにくくなります。

追従ボタンは、表示中の内容を隠していないか確かめる

画面下に相談ボタンを固定すると、長いページの途中でも相談先を見つけやすくなる場合があります。一方で、本文、エラー文、同意事項、送信ボタンに重なるなら、利用者の行動を妨げます。追従表示の有無を成果の一般論だけで決めず、ページの長さ、相談までに読む条件、固定表示が使う高さを確認します。

W3Cのフォーカスを隠さないための解説では、キーボードフォーカスを受けた部品が、制作者の表示した内容によって完全に隠れないことを扱っています。固定ヘッダーやフッターも点検対象です。AAの最低条件は完全な遮蔽を防ぐことですが、実際の設計ではできるだけ操作部品が隠れない状態を目指します。

確認時は、ページ末尾、文字拡大時、横向き、フォーム入力中で追従表示を見ます。必要に応じて入力中は表示を変える、本文の余白やスクロール位置を調整するなどの案を検討します。どの案でも、相談先が消えて戻れなくならないかを確認してください。この記事の一部の点検項目を満たしただけで、サイト全体がWCAGへ適合したとは判断できません。

電話や相談リンクは、実際の受付方法と揃える

電話のリンクは、電話で相談を受け付ける体制がある場合に役立ちます。しかし、電話が難しい時間帯の利用者や、資料を整理してから相談したい人もいます。すべてのLPで電話を最優先にするのではなく、受付時間、対応する相談、別の連絡方法を明らかにします。発信操作ができることと、相手につながって相談できることは別です。

リンクを押す前には、その先が相談フォームなのか、料金説明なのか、電話の発信操作なのか分かる言葉を付けます。同じページ内へ移動するボタンでは、移動先の見出しが固定ヘッダーに隠れないかも確認します。短い文言の整理はLPのマイクロコピー改善ガイドと合わせて進められます。

4. 入力開始から修正・受付完了までを通して確認する

入力中も項目名と必要な説明が分かるようにする

W3C WAIのフォーム説明の手引きでは、必須・任意や必要な形式を案内し、プレースホルダーを項目名の代わりにしないことを説明しています。入力欄の中に薄い文字で置かれた説明は、入力すると消える場合があります。スマートフォンでも、入力した後に何の項目だったかを確かめられることが大切です。

制作担当者には、項目名と入力部品の関連付け、補足説明の読み上げ、必要な入力補助を確認してもらいます。管理担当者が画面を見る際は、入力前と入力後で説明が失われないか、必須と任意が色だけで区別されていないかを見ます。項目を減らすときも数だけで決めず、返信や担当の振り分けに何が必要かを受付担当者と揃えます。

エラーが出たら、直す場所と残る内容を確認する

W3C WAIの入力検証の説明を参照し、受け付けられる形式とエラー時の案内を整理します。利用者が画面で入力できたことと、受付側で安全かつ正しく処理できることは同じではありません。ブラウザー側の入力チェックだけでなく、サーバー側の検証も実装担当者の確認範囲になります。

操作の点検では、未入力、形式が違う入力、長い相談文など、確認する条件を先に決めます。エラーが出た際、該当する欄が見えるか、何を直すか分かるか、問題のない入力まで消えないかを確認してください。「エラー文が出た」で終えず、その後に修正して先へ進めるところまでを一つの確認項目にします。

想定例として、メールアドレスの形式を直す場面では、氏名と相談文を再入力せずに済むかを見ます。ただし、機密情報をいつまでも端末へ保存してよいという意味ではありません。入力内容をどこへ、どの程度の時間残すかは、情報の扱いと実装条件に合わせます。入力保持の便利さと保存の仕組みは分けて確認しましょう。

キーボード・戻る操作・受付完了まで点検する

スマホのキーボードを開くと、画面の一部が使えなくなります。その状態で補足説明と次の操作が見えるか、欄を移動できるか、キーボードを閉じた後にレイアウトが戻るかを確認します。選択メニューや日付入力などは、機種によって表示が異なる可能性があるため、実際に使う機能から確認範囲を決めます。

確認画面のあるフォームなら、入力へ戻って修正し、再び確認へ進む操作も対象です。送信後は、何が受け付けられ、次に誰がどの方法で対応するか読めるようにします。送信ボタンの反応、完了画面、受付側の受信は別々に確認し、試験は担当者と合意した情報と送信先で行います。詳しい全体設計は問い合わせフォーム改善のガイドを参照してください。

5. 表示速度は点数と実際の利用データを分けて読む

読み込み・反応・ずれを別の現象として調べる

「遅い」と感じる場面には、主な内容が表示されない、押しても反応が遅い、表示中に位置が動く、といった違いがあります。画像だけを軽くしても、押した後の処理が重ければ操作の問題は残ります。どのタイミングの何が妨げなのかを記録し、診断結果と対応させます。

GoogleのWeb Vitalsの解説では、読み込みのLCP、応答性のINP、視覚的な安定性のCLSを扱っています。良好の目安はそれぞれ2.5秒以下、200ミリ秒以下、0.1以下です。実際の利用データでは75パーセンタイルで評価し、モバイルとデスクトップを分けて確認します。単発の計測値や総合点だけで、すべての利用者が快適だとは判断しません。

実測データがない場合も、診断の条件を残す

利用者の実測が十分に集まっていないページでは、公開ツールに個別のデータが出ないことがあります。その場合に数字を補って掲載したり、別ページの値をそのページの結果として扱ったりしないでください。実測がないことと、表示上の問題がないことは別です。まず再現できる操作と、試験環境で分かる改善候補を確認します。

ラボ診断の結果を比較する場合は、URL、測定日時、モバイル設定、変更内容を記録します。一回の点数が上がっただけで結論を出さず、修正した要素と診断の指摘が対応しているかを見ます。外部の動画、広告、計測タグなどが関係する場合も、必要な機能まで無断で外すのではなく、用途と担当者を確認してから変更案を決めます。

修正依頼では「90点にする」だけでなく、「最初に表示する大きな画像が遅い」「クリック後の処理に時間がかかる」のように現象を伝えます。点数は調査の入口として使えますが、表示、操作、実測のCore Web Vitals、相談の成果は異なる確認です。どの結果をもって今回の修正が完了したとするか、先に揃えておきます。

画像は寸法と読み込み順を一緒に調整する

Googleの画像の遅延読み込みの解説は、初期表示で見える画像、特にLCP画像は遅延させず、画面外の画像で遅延読み込みを使う考え方を説明しています。画像の幅と高さを指定し、読み込み前から表示領域を確保することも扱っています。すべての画像へ同じ設定を付ければよいわけではありません。

圧縮形式だけでなく、実際の表示サイズ、端末の解像度、画像内の文字、拡大表示の用途を確認します。画面のCSS幅と必要な画像の画素数は同じとは限らないため、「スマホだから横430ピクセルで十分」と一律に決めません。軽量化した後には、細部や文字を読めるか、縦横比が変わらないか、別の画面幅でも適切な画像が使われるかを点検します。

6. 公開されたLP改善事例を、条件と一緒に読む

Vodafoneの事例で、何を比較したのか

Googleのweb.devに掲載されたVodafoneの改善事例は、2021年3月に公開されたLPの比較記録です。見た目と機能を揃えた二つの版へ流入を半分ずつ割り当て、片方の描画処理や画像などを改善しました。報告ではLCPが31%改善し、売上が8%増加しています。

この数字は、その対象ページと試験条件で報告された結果です。固定CTAを付けた効果でも、フォームを3項目へ減らした効果でもありません。日本の中小企業のLPが同じ改善率になるとも言えません。事例を読むときは数字の大きさだけでなく、何を変え、何を揃えて比較し、どの指標で結果を見たかに注目します。

変更したものと、揃えたものを記録する

自社の改善へ応用できるのは、変更内容を切り分ける考え方です。たとえば写真を軽量化すると同時に、料金、見出し、広告文、相談フォームまで変えたなら、結果が変わっても画像だけの効果とは言えません。複数の修正が必要な場合は、無理に一つの要因に帰属させず、何を同時に変更したかを残します。

説明用の記録表には、比較する期間、対象URL、流入元、端末区分、変更点、残した条件、相談の定義を置きます。「改善前」「改善後」というラベルだけでは、季節や広告配信の違いを見落とします。表示の不具合を直すことと、その変更の事業効果を実験で推定することは、必要な準備と証拠が異なります。

少ないアクセスでできる確認を先に進める

事例と同じ規模の比較試験を、そのまま小規模サイトへ持ち込む必要はありません。利用が少ない段階でも、文字が切れる、条件が読めない、ボタンを押せない、エラーから進めないといった問題は確認できます。まず困る場面を再現して修正し、その後で成果を比較できるデータが揃っているかを判断します。

利用者に見てもらう場合は、答えを教えずに目的の行動をお願いし、読んだ場所や迷った操作を記録します。短い感想だけでなく、実際に何ができたかを確認するためです。進め方はLP公開前のユーザーテストのガイドへつなげられます。少人数の観察も改善の材料になりますが、全利用者の割合や売上への効果を確定する数字としては扱いません。

7. 優先順位を決めて修正を依頼し、公開後を確かめる

依頼書には、再現操作と完了条件を入れる

問題が複数あるときは、操作を完了できないもの、料金や対象条件を誤解するもの、読むのに余計な操作が必要なものなど、利用者への影響から整理します。「見た目が好みではない」という要望も記録できますが、送信できない問題と同じ優先度で並べない方が、対応順を相談しやすくなります。

修正票には、URL、確認した環境、開始時の状態、再現手順、実際の結果、期待する結果を入れます。たとえば「スマホでフォームのメール欄に入力すると、下部の固定相談ボタンがエラー文を隠す。入力中もエラーと次の操作を確認できる状態にする」と書けば、変更案と完了確認を結び付けられます。スクリーンショットは現象の補助として添え、操作順は文章でも残します。

公開後は、直した箇所と周辺の操作を確認する

制作担当者から修正完了の連絡が来たら、同じURLと条件で再現手順を試します。テスト環境で確認した内容が公開URLにも反映されたか、表示が古いままではないか、変更した画像や文言が正しいかを見ます。画像の圧縮なら画質と寸法、ボタン位置ならリンク先と隣接要素、入力欄ならエラー後の動作まで確認します。

狭い幅だけで直してPCやタブレットで崩れることもあるため、変更した仕組みに応じて周辺の幅を確認します。電話のリンクを点検する場合も、実際の発信を伴う確認は受付担当者と調整します。フォームの送信試験は、テスト内容が実際の相談と混ざらないよう、識別方法と受信先を決めて行ってください。

確認票には「確認済み」「再現しない」「未確認」を分けて残します。手元の一台で問題が出なかったことを、全機種での解決と書かないようにします。依頼から差し替えまでの管理方法はホームページの修正依頼ガイドも参考になります。

利用・受付・相談の結果を分けて見直す

最後に、修正後の状況を三つに分けて記録します。一つ目は表示や操作が直ったか、二つ目は目的の画面へ進み受付まで完了できるか、三つ目は有効な相談や商談につながったかです。クリック数が増えても受付に失敗していれば改善の途中であり、相談数が増えても対象外の相談ばかりなら条件説明を再検討する必要があります。

集計では期間、訪問の数え方、対象の端末、相談として数える条件を揃えます。率だけでなく件数も残し、流入や料金を同時に変えた場合はその事実も記録します。成果の原因を断定できない場合は、分からないまま残して構いません。次の点検で確かめる問いを具体的にすることが、改善を続けるための材料になります。

スマホ対応の見直しは、一度チェックリストを埋めて終える作業ではありません。写真や文章、フォーム、外部サービスを更新したときに、今回の再現手順を使って確かめます。自社で切り分けが難しい場合は、気になるURLと端末、困る操作、確認できた範囲を揃えてLPの制作・改善をご相談ください。作業範囲と優先順位を具体的に話し合うところから始められます。