スマホ対応なのに問い合わせが来ない？モバイルUXの落とし穴8つ

「スマホ対応にしたのに、問い合わせが増えない」。そんなとき、デザインの好みやアクセス数だけを見直していないでしょうか。

レスポンシブ対応は、画面の幅に合わせてレイアウトを変える作りのことです。でも、訪問した人が内容を読み、必要な情報を探し、フォームを最後まで送れるかは、別の問題です。

確かめたいのは、次の5つです。

• 読める
• 押せる
• 迷わない
• 入力できる
• 測れる

この記事では、問い合わせを止めやすい8つの落とし穴と、自分のスマホでできる確かめ方を紹介します。

スマホ対応とモバイルUXは同じではない

2つは、見ているところが違います。

• スマホ対応：画面に合わせて、どう表示するか。作り方の話
• モバイルUX：ページを開いてから問い合わせが終わるまで、行動がつながっているか。体験の話

Googleは、スマホ版のコンテンツを検索の登録と順位づけに使っています。そして、主な内容やはっきりした見出しを、パソコン版と同じにするよう案内しています。web.devも、viewport（表示領域の設定）、横スクロール、画像、タッチ操作を分けて確かめています。

出典：Google Search Central、Responsive web design basics

つまり、「スマホで崩れていない」だけでは、点検は終わりません。次の8項目を、実際の導線に沿って確かめる必要があります。

問い合わせを止めるモバイルUXの落とし穴8つ

1. 最初の画面で、価値と次の行動が分からない

スマホで開いた最初の画面が、大きな写真とぼんやりしたキャッチコピーだけになっていないでしょうか。パソコンでは同時に見えていた事業の内容や問い合わせボタンが、スマホでは画面の外に押し出されることがあります。

自分のスマホでページを開き、スクロールせずに、次の2つが分かるかを確かめます。

• 何を提供している会社か
• 次に何をすればいいか

分からなければ、提供する価値を1文で示し、主なボタンを1つ、見える位置に置きます。

2. ボタンやメニューが小さい、または近すぎる

電話番号を押したのに、隣のリンクが開く。メニューの閉じるボタンが押しにくい。見た目では気づきにくく、実機で触ると分かる問題です。

WCAG 2.2は、Webのアクセシビリティの国際的な基準です。押す対象の大きさを、原則24×24 CSS px以上としています。ただし、これは例外の条件もある最低限の基準です。数字だけで合格にせず、電話、ボタン、メニュー、ページ下の部分を片手の親指で押して、押し間違いがないか確かめてください。

出典：W3C Target Size (Minimum)

電話番号は、スマホで見る人がそのまま押したくなる場所です。2026年7月、Nutritsは営業先の候補として、埼玉県内の会社のサイトを簡単に診断しました。重点的に見た11社のうち4社は、電話番号をタップして発信するリンクを付けていませんでした。

同じ11社は、すべてSSLにも対応していませんでした（アドレスが「http」のまま）。どれも、こちらで候補に選んだ会社の例で、地域全体の割合ではありません。自分のスマホで電話番号を押し、発信の画面が開くかを確かめてみてください。

3. 横スクロール・小さい文字・拡大できない設定で読みにくい

幅の広い表や画像がはみ出して、縦に読むつもりが画面ごと横に動くことがあります。文字が小さいのに、指で広げて拡大できない状態も、最後まで読むのを妨げます。

WCAG 2.2には、Reflowという基準もあります。320 CSS px相当の幅で、情報や機能を失わないこと。原則として、縦と横の両方にスクロールさせないことです。ページを上から下まで触って、横へのずれと拡大できるかを確かめましょう。問題があれば、表・画像・長い文字列の幅と、拡大を止める設定を見直します。

出典：WCAG 2.2

4. スマホ版だけ、大事な説明やリンクが消えている

「画面が狭いから」と、料金の考え方、対応の範囲、FAQ、関連ページへのリンクを、スマホだけ隠していないでしょうか。判断の材料が足りなければ、表示はきれいでも問い合わせには進めません。

パソコン版とスマホ版の見出しを比べ、大事な説明が消えていないか確かめます。長い内容は消すのではなく、折りたたんで表示するなど、必要な人が読める形で残します。

リクマ

自社のWeb診断基準を整理したとき、スマホ最適化の不足とCTAの不足を別々の項目として見ていました。表示が画面に収まることと、次の行動が分かることは別問題だからです。

5. 表示・反応・レイアウトが安定しない

表示が遅い。ボタンを押しても反応しない。読もうとした瞬間に文字がずれる。こうした状態は、待つ負担や押し間違いにつながります。

Core Web Vitals（ページの体験を測る指標）の「良い」の目安は、次のとおりです。利用者の75%がこの範囲に入っているかで見ます。

• LCP（主な内容が表示されるまで）：2.5秒以下
• INP（操作への反応）：200ミリ秒以下
• CLS（表示のずれ）：0.1以下

出典：web.dev

ただし、達成すれば問い合わせや検索順位が上がる、という保証ではありません。PageSpeed Insightsで原因を探し、まずは重い画像やレイアウトのずれから確かめます。

6. フォームがスマホでの入力に合っていない

項目が多い。電話番号の欄で数字のキーボードが出ない。エラーの場所が分からない。フォームは、送信ボタンまで表示できていても、途中で止まります。

web.devは、次のことを案内しています。

• type、name、autocompleteなど、標準の属性を使う
• 入力する内容に合ったキーボードを出す
• 入力欄とボタンを十分な大きさにする
• いろいろな端末でテストする

出典：Sign-in form best practices、Payment and address form best practices

実機でテスト送信をして、キーボード、必須の項目、エラーの表示、完了の画面、通知まで確かめます。項目は「最初の返信に本当に必要か」を基準に減らしてください。

7. 固定のバナーやキーボードが、送信ボタンを隠す

画面の下に固定したボタン、チャット、Cookieの表示、スマホのキーボード。これらが重なると、本文や送信ボタンが押せなくなることがあります。

フォームに入力している状態で、最後までスクロールして送れるかを確かめます。重なりを消す方法には、次のようなものがあります。

• フォームのページだけ、固定のバナーを外す
• チャットの位置を変える
• ポップアップを出すタイミングを遅らせる

8. パソコンの疑似表示や、1回の測定だけで判断する

Chromeのデバイスモードは便利です。でも公式の説明でも、スマホの体験の「おおよその近似」であって、実機そのものではないとされています。タップの感触、画面に出るキーボード、実際の通信の環境は、実機で確かめます。

出典：Chrome DevTools

PageSpeed Insightsにも注意点があります。測定の環境で調べる「ラボデータ」と、実際の利用者の「フィールドデータ」では、条件が違うのです。1回の点数だけで決めず、実機、フィールドデータ、端末ごとの成果を組み合わせます。

出典：PageSpeed Insights

実機でできる5分チェック

外注や大きな改修の前に、自分のスマホで次の5点を確かめます。

1. 開く：スクロールせずに、事業の内容と主なボタンが分かるか
2. 読む：上から下まで触って、横へのずれ、重なり、小さすぎる文字がないか
3. 押す：電話、ボタン、メニューを、親指で正しく押せるか
4. 入力する：フォームを最後までテストして、キーボード、エラー、送信の完了を確かめられるか
5. 比べる：パソコン版にある大事な見出しや説明が、スマホ版でも読めるか

見つけた問題は、その場で全部直さず、リストにします。いくつも同時に変えると、どの変更が結果に効いたのか分かりにくくなるからです。

直す順番

順番は、見た目より「問い合わせを最後まで終えられるか」で決めます。

1. 送れない：ボタンが隠れる、エラーで進めない、通知が届かない
2. 読めない・押せない：横へのずれ、拡大できない、押し間違いがある
3. 判断できない：提供する価値、料金の考え方、対応の範囲、ボタンが分からない
4. 遅い・安定しない：表示や反応が遅く、レイアウトがずれる

リクマ

問い合わせ導線を改善するとき、一度に全部を変えず、一箇所だけ変えて次の期間のフォームログで検証する判断をしたことがあります。原因を追える変更単位にしておくことを重視しています。

問い合わせが来ない原因を、導線以外も含めて整理したいなら、問い合わせが来ない理由の記事も参考にしてください。集客の入口から見直すなら、小さなお店がホームページで集客するために必要なことの記事で、全体像を確かめられます。

あわせて読みたいホームページから問い合わせが来ない6つの理由｜最初に直す1か所の見つけ方→

あわせて読みたい小さなお店がホームページで集客するために必要なこと→

GA4とPageSpeed Insightsで改善を測る

PageSpeed Insightsは、ラボとフィールドを分けて見る

• ラボデータ：同じ条件で、問題の原因を探すための材料
• フィールドデータ：実際の利用者が体験した、過去のデータ

条件が違うので、数値が一致しなくてもおかしくはありません。

アクセスの量などによって、フィールドデータが出ないこともあります。その場合は、ラボデータで直す候補を見つけ、実機での確認とGA4の結果で補います。直す前の日付と数値を記録し、同じURLを続けて見てください。

GA4では、端末ごとの「中身のある問い合わせ」を見る

GA4では、端末の種類（device category）、ブラウザ、画面の解像度などを確かめられます。フォームの完了をキーイベントとして測ったうえで、スマホとパソコンの完了率や、特定のブラウザでの偏りを比べます。

出典：GA4 Tech overview

差があっても、スマホの使いにくさが原因だとすぐには言えません。流入元や、検索した人の意図の違いもあるからです。実機で再現できる不具合と組み合わせて、改善の仮説を立てます。

リクマ

フォーム送信には、見込み客の相談だけでなく、テスト送信や営業提案も混ざります。送信数だけを追わず、有効な問い合わせを分けて見る必要があると実感しました。

よくある質問

レスポンシブ対応済みなら、SEOでも問題ありませんか？

レイアウトが崩れていないことと、主な情報や見出しがそろっていることは別です。Googleの案内に沿って、スマホ版でも大事な内容にたどり着けるかを確かめてください。

Core Web Vitalsを良くすれば、問い合わせは増えますか？

保証はありません。表示や操作をじゃまする問題を見つける指標として使い、ボタン、フォーム、判断の材料も合わせて確かめます。

ボタンは24×24 CSS pxあれば十分ですか？

24×24 CSS pxは、例外の条件もある最低限の基準です。最後は、実機で親指を使い、押し間違えない大きさと間隔かを確かめます。

最初に1つ直すなら、どこですか？

フォームを最後まで送れない箇所があれば、そこからです。送れるなら、最初の画面からボタン、フォームの完了まで順にたどり、最初に止まる箇所を1つ選びます。

まとめ：スマホで、問い合わせの完了までたどる

「スマホ対応済み」という表示だけでは、モバイルUXの良し悪しは判断できません。読める・押せる・迷わない・入力できる・測れるの5点を、実機での導線と、端末ごとのデータで確かめることが大切です。

まずは自分のスマホで5分チェックをして、問い合わせを実際に止めている箇所から、1つずつ直してください。

「自分では問題の箇所を判断しにくい」「直す順番まで整理したい」という方は、無料Web診断をご利用ください。スマホでの表示、導線、計測の状況を確かめ、直す優先順位を整理します。