建設資材を扱う商社のWeb担当の方から、こんな連絡がありました。
「営業から苦情が来ていて。展示会で名刺交換した相手に『御社のサイト、スマホで見たら文字が小さくて何も読めなかった』と言われたらしいんです」
サイトを見せてもらうと、たしかにPCでは普通に表示されるものの、スマホで開くとPC用のレイアウトがそのまま縮小表示されているだけ。テキストは虫眼鏡で見るレベルの小ささで、問い合わせボタンに至ってはピンチアウトしないとタップできない状態でした。
このサイトは2019年に制作されたもので、当時の制作会社は「PC版をしっかり作れば大丈夫です」という方針だったそうです。7年前の話なので仕方ない面もありますが、問題はそこから一度もモバイル対応に手を入れていなかったことです。
Google Search Consoleを確認すると、モバイルユーザビリティのエラーが40件以上。検索順位もこの2年で主要キーワードが軒並み10〜20位下がっていました。
この手の相談は、月に2〜3件は入ります。共通しているのは、「レスポンシブ対応が大事らしい」とは聞いているけれど、具体的に何をどうすればいいのかわからない、という点です。
この記事では、レスポンシブデザインの仕組みから、設計の考え方、よくある失敗パターンまでを書きます。技術的な話も出てきますが、制作会社に依頼するときの判断材料として使えるレベルに噛み砕くので、エンジニアでなくても大丈夫です。
レスポンシブデザインを支える3つの技術要素
レスポンシブデザインとは、ひとつのHTMLファイルで、PC・タブレット・スマホなど画面サイズの異なるデバイスすべてに対して最適なレイアウトを自動で切り替える設計手法です。
「スマホ用のサイトを別に作る」のとは違います。URLもHTMLも1つ。CSSの書き方を工夫することで、同じページの見せ方だけを変える。これがレスポンシブの基本的な考え方です。
仕組みを支えているのは、主に3つの技術要素です。制作会社との打ち合わせで出てくる用語なので、概要だけでも把握しておくと話が早くなります。
メディアクエリ(Media Query)
画面の横幅に応じて、適用するCSSを切り替える仕組みです。「横幅が768px以下ならこのスタイル、それ以上ならこのスタイル」というルールを設定します。
この切り替えのポイントを「ブレイクポイント」と呼びます。一般的には、スマホ向け(〜480px)、タブレット向け(481px〜768px)、PC向け(769px〜)の3段階か、もう少し細かく4〜5段階に分けるケースが多いです。
制作会社に確認したいのは、「ブレイクポイントは何pxに設定していますか」という質問です。これで相手がレスポンシブの設計をきちんとやっているかどうかがわかります。答えが曖昧なら要注意です。
フルイドグリッド(Fluid Grid)
レイアウトの幅をpx(固定値)ではなく%(相対値)で指定する設計手法です。画面幅が変わっても、各要素が液体のように伸縮して画面に収まります。
たとえば、PC表示で「メインコンテンツ70%、サイドバー30%」と指定しておけば、画面幅が1200pxでも900pxでも比率が維持される。さらにメディアクエリと組み合わせて、スマホ表示では「メインコンテンツ100%、サイドバーはその下に移動」と切り替えます。
最近のCSSでは、CSS Gridのauto-fitとminmax()を使えば、メディアクエリを書かなくてもかなり柔軟なレスポンシブが実現できるようになっています。制作会社がCSS Gridを使いこなしているかどうかは、技術力の判断材料のひとつです。
フルイドイメージ(Fluid Image)
画像のサイズも固定値ではなく、親要素の幅に合わせて伸縮させる技術です。CSSでmax-width: 100%と指定するのが基本です。
ただし、PC用の大きな画像をそのままスマホに読み込ませると表示速度が落ちます。そこで使われるのが<picture>要素やsrcset属性です。画面サイズに応じて読み込む画像ファイルそのものを切り替えることで、スマホでは軽量な画像だけを読み込むようにします。
この画像の出し分けをきちんとやっているかどうかは、Core Web Vitals(後述)のスコアに直結します。制作を依頼するなら「スマホ向けに画像の出し分けはしますか」と確認してください。
モバイルファーストとデスクトップファーストの違い
レスポンシブデザインには、設計の起点をどこに置くかで大きく2つのアプローチがあります。
デスクトップファースト
PC版のデザインを先に作り、そこからスマホ向けに要素を削ったり並べ替えたりして調整する方法です。従来はこちらが主流でした。
CSSの書き方としては、まずPC向けのスタイルを書き、max-widthのメディアクエリで小さい画面向けのスタイルを追加していきます。
メリットは、PC画面の広さを活かしたリッチなレイアウトが作りやすいこと。デメリットは、スマホ表示で「足す」のではなく「削る」作業になるため、情報の優先順位が曖昧になりやすいことです。BtoBの業務系サイトなど、PCからの閲覧が多いサービスでは今でも有効な選択肢です。
モバイルファースト
スマホ版のデザインを先に作り、タブレットやPC向けに要素を追加・拡張する方法です。2010年代半ばからこちらが推奨されるようになりました。
CSSでは、スマホ向けのスタイルをベースに書き、min-widthのメディアクエリで画面が大きくなるにつれてスタイルを追加します。
最大のメリットは、小さい画面で「本当に必要な情報は何か」を最初に考えることになるので、情報設計がシャープになることです。不要な装飾や二次的な情報を最初から切り捨てる判断が入ります。
あるBtoBサービスサイトの案件では、モバイルファーストで設計し直した結果、スマホからの問い合わせが月8件から月22件に増えたケースがあります。大きかったのは、フォームの項目をスマホ基準で7項目から4項目に絞ったこと。PC版でも同じ項目数で運用しましたが、むしろPCからのCVRも改善しました。入力が楽であることは、画面サイズを問わずユーザーの共通ニーズだったわけです。
どちらを選ぶべきか
2026年時点では、モバイルファーストを基本にするのが望ましいです。理由はシンプルで、Googleの検索エンジンがそう判断しているからです。
ただし、BtoBの管理画面やダッシュボード系のツールなど、PC利用が圧倒的に多いサービスは例外です。その場合はデスクトップファーストで設計し、スマホでは最低限の閲覧性を確保する、というバランスが現実的です。
重要なのは、どちらのアプローチを採るかを制作の初期段階で明確に決めること。途中でアプローチを変えると、CSSの設計が破綻します。
なぜモバイル対応がビジネスに直結するのか
「スマホ対応したほうがいいのはわかるけれど、うちのサイトはBtoBだからPCで見る人が多いはず」
この反論はよく聞きます。ただ、データを見ると少し違う景色が見えてきます。
国内のモバイル利用の実態
総務省の「令和6年通信利用動向調査」によると、インターネット利用時の端末でスマートフォンを使用する割合は91.0%に達しています。パソコンは72.2%。モバイル社会研究所の調査ではスマートフォンの個人所有率が98%に到達しており、もはやスマホを持っていない人のほうが圧倒的に少ない状態です。
「BtoBだからPCがメイン」は一面的な見方です。たしかにオフィスの業務中はPCで情報を見ることが多い。でも、展示会の帰りに電車の中でスマホから社名検索する、会食中にスマホでサービス概要を確認する、週末に自宅でスマホから競合を比較する。こうしたBtoBの意思決定プロセスに、モバイルは深く入り込んでいます。
実際、Statcounterの統計では、日本国内のWebアクセスにおけるモバイル比率はデスクトップとほぼ拮抗しており、グローバルで見ればモバイルが6割を超えています。
Googleのモバイルファーストインデックス
Googleは2024年7月5日に、モバイルファーストインデックス(MFI)への完全移行を完了しました。これ以降、すべてのWebサイトはモバイル版のページを基準に検索順位が評価されています。
何が変わったかというと、PC版でどんなに立派なコンテンツを載せていても、スマホ版でそのコンテンツが表示されていなければ、Googleの評価対象に入らないということです。
冒頭の建設資材商社の例でいえば、PC版には製品の詳細スペック表があったのに、スマホ表示では表が崩れて読めない状態でした。Googleのクローラーはスマホ版を見て「このページには十分な情報がない」と判断し、順位を下げていた可能性が高いです。
モバイル対応は「ユーザー体験の改善」だけの話ではありません。検索からの集客に直結するSEOの基盤です。
Core Web Vitalsとレスポンシブの関係
レスポンシブデザインの話をするとき、避けて通れないのがCore Web Vitals(コアウェブバイタル)です。
Core Web Vitalsとは、Googleがページの品質を測るために使っている3つの指標です。
| 指標 | 測定内容 | 基準値 |
|---|---|---|
| LCP(Largest Contentful Paint) | ページの主要コンテンツが表示されるまでの時間 | 2.5秒以内 |
| INP(Interaction to Next Paint) | ユーザーの操作に対するページの応答速度 | 200ミリ秒以内 |
| CLS(Cumulative Layout Shift) | ページ読み込み中のレイアウトのズレ | 0.1以下 |
この3指標すべてが検索ランキングの評価対象になっています。そして、レスポンシブデザインの実装品質が、これらのスコアに直接影響します。
LCPとレスポンシブの関係
スマホでLCPが悪化する最大の原因は、画像の最適化不足です。PC用の横幅1920pxの画像をスマホでもそのまま読み込んでいたら、当然表示は遅くなります。
前述のフルイドイメージの技術、つまりsrcsetによる画像の出し分けが、ここで効いてきます。ある製造業クライアントのサイトでは、スマホ向けの画像最適化だけでLCPを4.8秒から2.1秒に改善しました。
CLSとレスポンシブの関係
CLS(レイアウトのズレ)は、レスポンシブ対応のサイトで特に問題が起きやすいです。画像や広告の読み込みが遅れて、あとからコンテンツがガクッとズレる。フォームに入力中にレイアウトが動いて別のボタンを押してしまう、といった現象です。
対策は、画像やiframe要素に対して事前にアスペクト比を指定しておくことです。CSSのaspect-ratioプロパティか、HTML上でwidthとheight属性を明示するだけで、CLSは大幅に改善します。
Core Web Vitalsについてさらに詳しく知りたい方は、コーポレートサイトの作り方の記事でも表示速度の重要性に触れています。また、Webデザインのトレンド2026の記事ではアクセシビリティとパフォーマンスの関係を解説しています。
レスポンシブデザインでよくある5つの失敗
ここからは、実際の案件で遭遇した「レスポンシブ対応したつもりだけれど失敗している」パターンを紹介します。制作会社から納品されたサイトをチェックするときの参考にしてください。
失敗1:タップ領域が小さすぎる
PC版のリンクやボタンをそのままスマホに持ってくると、指でタップするには小さすぎることがよくあります。
Googleはタップターゲットのサイズとして最低48x48pxを推奨しています。AppleのHuman Interface Guidelinesでは44x44pt。つまり、ボタンやリンクの実効的なタップ領域は最低でも44〜48pxは確保する必要があります。
ある不動産会社のサイトで、物件一覧ページのフィルターボタンが24px四方しかなかったケースがありました。PCではマウスカーソルで問題なく操作できるけれど、スマホでは隣のボタンを誤タップしてしまう。フィルター機能の利用率を調べたら、PC版の5分の1以下でした。
ボタンを48px以上に修正し、ボタン同士の間隔も8px以上空けた結果、スマホでのフィルター利用率が3.2倍になりました。
失敗2:フォームがスマホで使いにくい
BtoBサイトの問い合わせフォームは、会社名・部署・役職・氏名・メールアドレス・電話番号・問い合わせ内容と項目が多くなりがちです。PC版では横2列に並べて1画面に収まるレイアウトでも、スマホでは縦に延々とスクロールする羽目になる。
よくある問題をリストにすると、こうなります。
- ラベルと入力欄がPC版のまま横並びで、入力欄が極端に狭い
- セレクトボックスの選択肢が多すぎて、スマホでは延々スクロールする必要がある
- 確認画面でエラーが出ると、ページ先頭に戻されてどこがエラーなのか探さないといけない
- 入力欄をタップしたときのキーボード表示でレイアウトが崩れる
- 電話番号の入力欄でテンキーが出ない(
type="tel"が設定されていない)
フォームはスマホで縦1列レイアウトに切り替え、入力項目はスマホ基準で本当に必要なものだけに絞る。HTMLのinputmode属性を使って、メールアドレスならメール用キーボード、電話番号ならテンキーを出す。こうした一つひとつの配慮が、CVRを左右します。
失敗3:ホバー前提のUIをスマホに持ち込む
PCでは「マウスを乗せると詳細が表示される」UIが便利に使えます。ナビゲーションのドロップダウンメニュー、ツールチップ、画像のオーバーレイ効果などです。
でも、スマホにはマウスカーソルがありません。ホバーが存在しない。つまり、ホバーでしか表示されない情報は、スマホユーザーにとって存在しないのと同じです。
製造業のクライアントで、製品カタログページの各製品にマウスを乗せると型番と価格帯が表示される仕様だったケースがあります。PC版では便利でしたが、スマホではその情報に一切アクセスできなかった。スマホユーザーの製品ページ滞在時間がPC版の半分以下だった原因は、これでした。
対策としては、ホバー前提のUIはスマホではタップで展開するアコーディオンに切り替える、または最初から表示しておく。情報の出し方をデバイスに応じて変える設計が必要です。
失敗4:テーブル(表組み)が横にはみ出す
製品スペックや料金表など、BtoBサイトにはテーブルが頻出します。PC版で5列以上あるテーブルをそのままスマホに表示すると、はみ出して横スクロールが必要になるか、文字が潰れて読めなくなる。
対処法はいくつかあります。
- 横スクロール可能なコンテナで囲む(ユーザーに横スクロールできることを視覚的に示す)
- スマホ表示ではテーブルを崩して、各行をカード形式で縦に表示する
- 列を減らして、スマホでは重要な項目だけ表示し、詳細は別ページに誘導する
どの方法が適切かは、テーブルの用途と情報量によります。制作会社に「テーブルのスマホ対応はどうしますか」と事前に確認してください。何も考えていない会社は、PC版を縮小表示するだけで終わらせます。
失敗5:スマホで「PCサイト」が表示される
意外と多いのがこれです。レスポンシブ対応しているはずなのに、スマホで見るとPC版が表示されてしまうケース。
原因のほとんどは、HTMLの<head>内にviewportの設定がないか、設定が間違っていることです。正しくは以下の記述が必要です。
<meta name="viewport" content="width=device-width, initial-scale=1">
これが抜けていると、スマホのブラウザはページを「横幅980px」として表示しようとします。結果、PC版のレイアウトがそのまま縮小表示される。
納品時にスマホ実機で確認していれば一発で気づく問題ですが、制作会社がPCのブラウザの開発者ツールだけでテストして済ませているケースでは、この初歩的なミスが残ることがあります。
自社サイトのレスポンシブ対応チェックリスト
制作会社から納品されたサイト、あるいは自社で運用中のサイトをチェックするときの最低限のリストです。
- viewportメタタグが正しく設定されている
- スマホ表示で横スクロールが発生しない
- テキストがスマホでピンチアウトなしで読める(最低16px以上)
- ボタンやリンクのタップ領域が48px以上確保されている
- フォームの入力欄がスマホで操作しやすい幅になっている
- Google Search Consoleで「モバイルユーザビリティ」のエラーが0件
- PageSpeed Insightsのモバイルスコアが70点以上
- テーブルやホバーUIがスマホ表示で崩れていない
上から順に優先度が高いです。特に最初の4項目は、対応していないと検索順位に直接影響するので最優先で確認してください。
なお、既存のPC専用サイトにレスポンシブ対応を追加する場合、10ページ以下の企業サイトで30〜80万円・1〜2ヶ月、20〜50ページの中規模サイトで80〜200万円・2〜4ヶ月が目安です。全ページの一括対応が難しい場合は、トップページ、問い合わせフォーム、サービスページの順に段階的に対応する方法もあります。
コーポレートサイト全体の設計については、コーポレートサイトの作り方の記事で詳しく解説しています。
レスポンシブは「対応」ではなく「前提」へ
レスポンシブデザインは、メディアクエリ・フルイドグリッド・フルイドイメージの3つの技術で、ひとつのHTMLを画面サイズに応じて最適化する設計手法です。2024年7月にGoogleがモバイルファーストインデックスへの完全移行を終えた現在、レスポンシブ対応はSEOの必須条件になっています。
設計アプローチは、BtoC・一般向けサイトならモバイルファーストが基本です。BtoBサイトでも、モバイルファーストを基本にしつつPC表示も丁寧に作り込む、というのが現実的な落とし所になります。
そして、レスポンシブの品質はCore Web Vitalsのスコアに直結し、検索順位に影響します。「対応しているかどうか」ではなく「どの品質で対応しているか」が問われる時代です。
自社サイトのモバイル表示が気になったら、まずはスマホ実機でトップページと問い合わせフォームを触ってみてください。文字が読みにくい、ボタンが押しにくい、表示が遅い。こうした体感があれば、それは訪問者も同じことを感じています。
既存サイトのモバイル対応に不安がある、どこから手をつけるべきか判断がつかないという場合は、株式会社ティーラのWeb制作・運用支援にお気軽にご相談ください。現状のレスポンシブ対応状況の診断から、改善の優先順位づけまでお手伝いできます。あわせて、Webデザインの最新トレンドとレスポンシブの関係についてはWebデザインのトレンド2026の記事も参考にしてみてください。
参考文献
- 総務省「令和6年通信利用動向調査」 https://www.soumu.go.jp/menu_news/s-news/01tsushin02_02000178.html
- NTTドコモ モバイル社会研究所「モバイル端末の保有状況」 https://www.moba-ken.jp/project/mobile/
- Statcounter GlobalStats「Desktop vs Mobile Market Share Japan」 https://gs.statcounter.com/platform-market-share/desktop-mobile/japan/
- Google Search Central Blog「モバイルファーストインデックスへの移行完了」 https://developers.google.com/search/blog/2024/06/mobile-indexing-vlast-final-final.doc
- Google「Web Vitals」 https://web.dev/articles/vitals
- Google Search Central「Mobile-first indexing best practices」 https://developers.google.com/search/docs/crawling-indexing/mobile/mobile-sites-mobile-first-indexing