スマホファーストと CV の関係 — 「閲覧」と「CV」は別軸で考える

第 1 章のラストは、レスポンシブとモバイルの話です。 Lesson 1-5 で「人物=サイト、服装=CSS、特技=JS」と例えました。 レスポンシブは、その人(HTML)が 相手の状況に合わせて服装(CSS)を変える 仕組みのことです。 技術論の細部には深入りせず、現場で担当者が判断するためのチェックポイントに絞って整理します。

1. 2026 年、「レスポンシブ対応」の議論はもう古い

1-1. 「対応した、しない」は前世代の話

数年前まで、Web の現場では「レスポンシブにしますか?」という質問が出ていました。 でも 2026 年の今、その議論はほぼ消えました。 どのサイトもレスポンシブが前提です。 新規構築でレスポンシブを採用しない、というのはまずあり得ません。

1-2. 数字の現状

業種にもよりますが、Web サイトのスマホ閲覧比率は 50〜80% 程度に到達しています。 BtoC では 80% 近く、BtoB でも 50% を切ることは稀です。 Google は モバイルファーストインデックス(モバイル版を主軸に検索順位を決める仕組み)を採用しており、スマホで適切に見られないサイトは検索順位でも不利になります。

1-3. 論点は「対応の有無」から「使えるかどうか」に移った

重要なのは、レスポンシブ対応をしていることではなく、スマホで実際に使えるかどうか です。 見えているのに押せない、読めるのに離脱されている、というサイトは現場で山ほどあります。 本 Lesson の主軸は、ここから先の「実際に使えるか」の話です。

2. 「人物」シリーズで言うと — 服装(CSS)を相手に合わせて変える

Lesson 1-5 で「Web サイト=人物」「HTML=その人」「CSS=服装」と例えました。 レスポンシブは、その世界観で言うと 「相手に合わせて服装を変える」 ことです。 同じ人(HTML)が、スマホで会うときと PC で会うときで、服装(CSS)を変える。 中身は同じでも、見え方を場に合わせる、という発想です。

例えると、立食パーティでドレスを着る人が、座敷の食事会ではきものに着替えるようなものです。 中身の人格は変わっていません。 でも、その場で動きやすい服装に変えている。 レスポンシブが正しく機能しているサイトは、これと同じ振る舞いをします。 PC ではゆとりのあるレイアウトで、スマホでは縦に詰めた読みやすい構成で、同じ情報を届けます。

3. 3 つの方式 — 用語整理だけしておく

技術的には、スマホ対応の方式は 3 種類あります。 現場ではほぼレスポンシブ一択ですが、業者の口から他の言葉が出ても困らないように、整理しておきましょう。

3-1. レスポンシブ

1 つの HTML を用意し、画面幅に応じて CSS が見た目を切り替える方式です。 現在の主流で、本書のこれ以降の議論はすべてレスポンシブ前提で進みます。

3-2. 別 URL 方式

`m.example.com` のような、スマホ専用のサイトを別途用意する古い方式です。 SEO やコンテンツ管理のコストが二重になるため、今は廃れ気味です。 既存サイトがこの構成のままなら、リニューアル時に統合を検討してください。

3-3. アダプティブ

アクセスしてきた端末を判別して、別の HTML を出し分ける方式です。 限定的に採用されるケースはありますが、新規ではほぼ使いません。 「業者がこの言葉を出したら、特殊なケースなのだな」と思っておけば十分です。

4. 「対応してる」だけでは UX は保証されない — 崩れの 4 定番

レスポンシブ対応をうたっているサイトでも、実際にスマホで見ると「使えない」状態になっていることがあります。 現場でよく見る崩れは、おおむね次の 4 パターンです。

4-1. 画像のはみ出し

PC 用の画像が、横幅を固定指定したまま入っているケースです。 スマホで見ると画面の幅を超えて、横スクロールが出るか、レイアウトが破綻します。 特に過去に PC 専用で作られたサイトの一部を流用したときに起きがちです。

4-2. テーブルの横スクロール

料金表や比較表など、表組み(テーブル)はスマホでの崩れの定番です。 PC で 5 列ある表をそのままスマホに出すと、横スクロールしないと全列が見られません。 縦並びに変換するか、要約版を別途用意するか、いずれかの工夫が必要です。

4-3. 文字が小さすぎる / 大きすぎる

スマホの本文文字サイズは 16px 以上 が基本ラインです。 これより小さいとズームしないと読めず、即離脱の原因になります。 逆に、デザイン重視で 22px などにしてしまうと、行数が増えてスクロールが多くなり、読み手の負担が上がります。 本文 16px〜18px、見出しはそれより一段大きく、という範囲が無難です。

4-4. ボタンが押しにくい

指で押せるボタンサイズは、最低 44 × 44px 必要、というのが業界の目安です。 これを下回ると、押し間違いが多発します。 また、ボタンが近接しすぎていると、隣のボタンを誤タップする原因にもなります。 Lesson 4-4 で詳しく扱いますが、「ボタンを大きくしすぎる」のも別の問題を生むので、適切な範囲を狙う必要があります。

「見えているのに使えない」サイトは、対応していないのとほぼ同じです。 レスポンシブ対応の有無で安心せず、上の 4 つを必ず確認してください。

5. スマホ表示崩れチェック — 3 段構えで見つける

スマホ表示の確認は、1 つのツールに頼らず、3 段構えで見つけるのが現場のルールです。それぞれに役割があります。

5-1. Step 1:Chrome DevTools のデバイスシミュレータ

PC の Chrome で F12 を押して開発者ツールを起動し、左上のアイコンで「Toggle device toolbar」を選ぶと、画面が指定サイズのスマホとして表示されます。 iPhone、Pixel、iPad など、複数の端末を瞬時に切り替えられるので、簡易確認はここで十分です。 担当者でも今日から使えるツールなので、まず試してください。

5-2. Step 2:iOS 実機(Safari)

シミュレータでは再現できない癖が、iOS の Safari にはあります。 特にフォーム、動画埋め込み、Safe Area(ノッチ周りの余白)の扱いは、実機でないと見えません。 会社支給か個人の iPhone で、必ず実機確認してください。

5-3. Step 3:Android 実機(Chrome)

Android は機種ごとの差が大きく、フォント描画やスクロール挙動、入力 UI に独自の癖があります。 1 機種で十分なので、Android 実機での確認は必須にしてください。 会社で 1 台、検証用に確保しておくのが理想です。

5-4. なぜ両方の OS が必要か

iOS と Android では、同じデザインが 別物に見えることがあります。 フォント、スクロールバー、フォーム UI、絵文字の描画、Safe Area の余白、ボタンのタップ反応 — このあたりが、見た目と挙動の両方で違って出ます。 片方だけ確認して「大丈夫です」と業者が言ってきたら、両方の確認結果を求めてください。

5-5. 業者に確認依頼する場合の伝え方

新規構築・リニューアル・大型改修の納品時には、業者に対して次のように依頼してください。

「DevTools 確認 + iOS 実機 + Android 実機 の三段で確認した結果をください」。 確認スクリーンショットや動画、機種名・OS バージョンを記載した報告書を出してもらいます。 「シミュレータで確認しました」だけで終わらせない、という意思を明文化することが大事です。

6. 2026 年のスマホファースト論 — 思考停止で推奨はしない

6-1. 原則:多くの場合スマホファーストで OK

一般消費者向けの商品・サービス、短時間で検討して決める商材は、スマホファーストで設計してください。 その場で目に入って、その場で問い合わせるか申込まで持っていく流れになるからです。 BtoC の多くの案件は、これに該当します。

6-2. 見極める:自社の情報はスマホファースト向きか?

一方、スマホファーストが「全案件で正解」ではありません。 自社の商材によって、ユーザーが実際にどのデバイスで何をするかが大きく違うのです。

• 一般消費者向け / 即決系:スマホファースト推奨
• BtoB 業務系:業務時間中の PC が主、PC ファースト寄りの設計が現実的
• 高単価・高関与商材:スマホで見つけても、PC でじっくり比較・決裁するパターン

6-3. 「閲覧率」と「CV率」は別軸

ここが本 Lesson で一番伝えたい論点です。 サイトを見られている数(閲覧率)と、申込・問い合わせなどの成約率(CV率)は、デバイス別に見ると別の動きをします。 BtoB や高単価商材では、「スマホ閲覧 70%、PC 閲覧 30% なのに、CV は PC で 70%」というパターンが珍しくありません。 閲覧率だけ見て「スマホファーストで」と決めると、CV を取り逃します。

6-4. GA4 で 2 軸を確認する

自社サイトでこの判断を下す前に、必ず GA4(Google アナリティクス 4)で以下の 2 軸を見てください。

• デバイス別のセッション割合(=閲覧率)
• デバイス別のコンバージョン率(=CV率)

両方を必ず見ます。 片方だけで判断するのが、現場のあるあるな落とし穴です。

6-5. 両軸が必要なら、両方を本気で設計する

スマホ閲覧が多くて PC で CV する、というパターンの場合、PC カンプを「形だけ」にしてはいけません。 PC でも CV を確実に取るための導線設計、フォーム設計、視覚的な階層を別途用意します。 「PC は申し訳程度に対応している」サイトでは、CV を逃し続けます。

6-6. デザイン依頼時の伝え方

業者にデザインを依頼するときは、こう明文化してください。

「スマホファースト前提でカンプを作ってください。ただし PC でも CV を取る予定なので、PC カンプも同等の精度で作ってください」。 この一文を入れるだけで、PC カンプが手抜きで上がってくる事故をかなり防げます。

6-7. 「デバイス別 CV率」の解釈の罠 — 商材特性と現状の体験品質を踏まえて読む

H2-6-3 で「閲覧率と CV率は別軸」と書きました。 ただし、その「デバイス別 CV率」を単独で判断軸にするのも危険です。 CV率は 結果の数字 にすぎず、その結果がなぜ出ているかの 文脈 を読まないと誤判断になります。 解釈には、2 つのレイヤーを踏まえる必要があります。

(A)商材特性による利用のされ方

自社の商材によって、ユーザーの利用パターンは大きく違います。

• 契約・入力項目が多い商材:スマホでサイトに到達して内容を確認・比較、PC に切り替えて契約・購入、というパターンが多発します。スマホ CV率は低く出ますが、スマホ閲覧が CV の起点 になっています。ここでスマホ閲覧を軽視すると、CV ファネル全体が崩れ、機会損失が拡大します。
• スマホで完結する商材(食品 EC、コンビニ予約、シンプルな申込など):スマホ CV率が PC を上回ることも多い領域です。
• BtoB 高額・高関与商材:PC 中心ですが、社外移動中の比較検討にスマホが使われます。スマホ閲覧は「思い出し」「再確認」の役割を持っています。

自社の商材がどの利用パターンかを把握せずに、デバイス別 CV率だけで判断すると、「スマホ CV率が低いからスマホは後回し」と短絡してファネル全体を崩します。

(B)現状の体験品質による歪み

もう一つの注意点が、スマホ UI の不備で CV率が歪んでいるケースです。

• フォームが入力しにくい、ボタンが押しにくい、読み込みが遅い → スマホ CV率が下がる
• その状態で「スマホは CV しない」と判断すると、改善機会を永遠に逃す

「現状の数字」と「あるべき姿の数字」は分けて考えてください。

• 現状:デバイス別 CV率
• あるべき姿:各デバイスでの体験が整った時の CV率(仮説)
• 改善機会:両者のギャップ

仮説を立てて改善検証する流れは、Lesson 8-4 で深掘りします。

解釈の組み合わせ — 商材特性 × 現状の体験品質

「スマホ閲覧の役割」と「PC 利用の役割」を、ユーザー行動の流れとして 設計してください。 デバイス別 CV率は、その文脈の中で意味を持つ数字です。 単独で絶対視しないこと、これが本 Lesson の独自視点です。

7. タブレット対応はどこまでやるか

タブレット対応をどこまでやるかは、案件によって差があります。 一般のコーポレートサイトやサービスサイトなら、多くのケースで「スマホ縦持ちの延長」で十分です。 iPad のような中サイズの画面では、スマホ用レイアウトを少しだけ広めに表示するだけで違和感なく見られます。

一方、業務系サイトや教育系サイトは、タブレット利用が多い傾向があります。 現場の人が iPad で確認しながら作業する、教室で生徒が iPad で開く、というシーンがあれば、タブレット用のレイアウト最適化に投資する価値があります。 iPad Pro のような大型タブレットだけは別途確認、というのが現実的な落とし所です。

8. デザイン依頼時のチェックリスト

最後に、業者にデザインを依頼するときの担当者用チェックリストを置いておきます。

• スマホ・PC 両方のカンプを必ず受け取る
• スマホで実機確認した結果を業者から貰う(iOS / Android 両方)
• タップ可能領域 44 × 44px 以上を確認
• 本文の文字サイズ最小 16px を確認
• フォームがスマホで入力しやすいか確認(入力タイプ、自動補完、エラー表示)
• GA4 のデバイス別 CV率を踏まえて、PC 設計の重みを決める

9. 次に読むなら

• Lesson 2-1 サイトの目的を言語化する(第 2 章の入口)
• Lesson 4-4 スマホ UI の 30 チェック(深掘り)