スマホ向けLPOの実務|CTA・フォーム・表示速度の検証手順

2026年8月31日

著者: 与謝秀作
スマホ向けLPOのコツ|モバイルUIでCVRを高める改善ポイント

スマホ向けLPO(ランディングページ最適化)では、実際の端末で情報を読み、入力し、失敗から復帰できるかを確かめます。ボタンの色や位置だけでなく、拡大、横向き、キーボード、通信の状態を含めて再現し、操作の問題と成果の計測を分けて記録します。

流入と実際の利用環境を確認する

最初に対象URLと言語、主要な流入経路、利用端末やブラウザの分かる範囲を確認します。スマホが必ず流入の大半とは仮定せず、自サイトの観測に基づいて優先する環境を選びます。利用データに現れていない支援操作や、拡大表示も検証対象から除外しません。

スマホは片手の親指だけで使われるとは限りません。両手、横向き、外付けキーボード、読み上げなどでも、同じ情報と主要な操作に到達できるかを見ます。内容の順序に問題がある場合は目的別のLP構成テンプレート、一般的な配色や強調はLPデザインの確認方法で整理し、実機の再現条件と分けて修正します。

タップ・拡大・横向き表示を検証する

見える文字の大きさだけでなく、押せる領域と隣接操作との間隔を確認します。WCAG 2.2のターゲットサイズの解説では、AAの最小サイズは24×24 CSSピクセルで、間隔、同等の操作、文中リンクなどの例外があります。これは物理的な画面ピクセルや、使いやすさを保証する最大・推奨サイズではありません。適用条件を確かめた上で、実際に押し間違えないかも試します。

縦向きだけでなく横向き、文字の拡大、ブラウザの表示拡大を試し、条件や送信操作が切れないかを見ます。W3Cのリフローの解説は、縦スクロールする内容で320 CSSピクセル相当の幅でも情報や機能を失わず、原則として二方向スクロールを要しないことを扱います。固定320pxでページを制作する指示ではなく、二次元配置が必要な内容等の例外もあります。

固定CTAとキーボードの重なりを見る

画面下に固定するCTAは一つの選択肢です。フォームを入力するとキーボード、同意バナー、エラー案内が同時に表示される場合があります。固定ボタンが欄や条件を覆わないか、次の欄や送信へ進めるか、横向きや拡大でも確認します。

WCAGのフォーカスを隠さない条件では、AAの基準として、フォーカスを受けた部品が作成者によるコンテンツに完全には隠れないことを求めています。一部の重なりがすべて同じAA違反という意味ではありませんが、操作しやすさの確認では部分的な隠れも調べます。固定を外す、入力中の配置を変えるなど、再現した問題に合う案を検討します。

ラベル・入力方式・自動入力を試す

入力欄には目的が分かるラベルを関連付け、必須か任意か、なぜ必要かを案内します。W3Cのフォームのラベルの説明を参考に、入力すると消えるプレースホルダーだけへ依存しないようにします。項目を減らすことは検討できますが、減らせば必ず完了率や相談の適格性が上がるとは限りません。

入力の意味を扱うtype、入力方式のヒントとなるinputmode、補完の目的を示すautocompleteを区別します。MDNのinputmodeの説明では、inputmode自体は妥当性の制約を課さないとされています。数字用の画面が出ても、必要な値が正しいと確認できるわけではありません。MDNのautocompleteの説明も参照し、メールや氏名等の目的に合う指定を検討します。補完候補やキーボードはOS・ブラウザ・言語で実動作を確かめます。

エラーから成功まで操作を再現する

未入力、入力途中、誤入力、送信中、通信失敗、成功という状態を順に試します。入力中の警告は早すぎると作業を妨げるため、欄を離れた時や送信時の確認も含め、状況に合うタイミングを選びます。W3Cのフォーム通知の解説は、エラーの所在と修正方法、成功を分かる形で伝える考え方を示しています。

下表は架空のフォーム設計例です。実装後には、残すべき入力が消えないか、エラー箇所へ移動できるか、通知が読み上げでも伝わるかを確認します。再送時の二重処理を防げるかも、見た目のボタン状態とは別に確認します。

状態

架空の設計例

確認すること

未入力

ラベルと必須理由を示す

プレースホルダーだけに依存しない

入力途中

必要なヒントと補完を用意

入力が終わる前の過剰な警告を避ける

エラー

要約と該当欄に修正案内

入力保持、移動、読み上げ

送信中・失敗

状態と復帰方法を表示

重複処理の防止、再送の挙動

成功

受け付けた内容と次の手順を示す

実際の成功条件と計測を別に確認

最初の画像と表示速度を確認する

画像の容量や不要な処理を見直す時は、画面外の画像と最初に必要な主要画像を分けます。すべての画像を必要になるまで読み込まない設計にすると、重要な画像を遅らせる場合があります。web.devのLCP最適化の説明では、LCPに当たる画像を遅延読み込みしないように案内しています。LCPは大きな主要コンテンツの表示を測る指標です。

検証では端末と通信条件、初回と再訪、キャッシュの有無を記します。速度の測定、利用者が操作を始められる状態、成果の変化を同一視しません。主要な画像や文字が見えた後に配置が動き、押そうとしたボタンがずれる問題も操作の観察へ残します。

端末別修正票と成果の分母を残す

実機テスト票には、再現に必要な情報と期待する動作、実際の動作を記します。次は票のひな型で、テストを実施済みという記録ではありません。

環境・状態

試す操作

残す記録

実利用OS・ブラウザ

縦横表示、拡大、戻る、再読込

機種、OS、ブラウザ版、URL、日時

320 CSSピクセル相当

リフローと横スクロール

内容・機能の欠落、例外の理由

キーボード表示

入力、次へ、送信、エラー修正

固定CTAとバナーの重なり

タップ・支援操作

主要操作、間隔、フォーカス移動

押し間違い、到達や通知の問題

不安定な通信

失敗、再送、成功表示

二重処理と復帰の挙動

率の計算も分母を残します。以下は期間・ホスト・言語・チャネルを固定した同じ入口セッション群の架空例です。実績や改善予測ではありません。

単位

仮定の値

計算・注意

対象LP入口セッション

1,000

条件を固定した対象

その中の開始セッション

80

同じ対象群

その中の検証済み成功セッション

55

成功条件と重複を確認

開始からの成功率

68.75%

55÷80×100

入口からの成功率

5.5%

55÷1,000×100

送信イベント

60件

55人や登録人数と同一視しない

修正票には重要度、担当、対象版、再確認日を加えます。操作を直した事実と事業成果の変化は別に評価し、少数の前後差だけでCVR改善の因果を断定しません。未検証の成功イベントは成果として数えず、確認が必要な項目として管理します。

関連記事