本文へスキップ
サイト総合診断

モバイルフレンドリーとは — viewport とレスポンシブ対応

モバイルフレンドリーとは、スマートフォンの画面で見やすく操作しやすい状態を指します。要点は 3 つで、viewport メタタグで実寸表示にすること、レスポンシブデザインで画面幅にレイアウトを合わせること、そして Google はスマホ版の内容で評価する(モバイルファーストインデックス)ため、PC 版だけを充実させても不利になることです。

執筆: 公開:

モバイルフレンドリーとは何ですか?

モバイルフレンドリーとは、スマートフォンで文字が読みやすく、リンクやボタンが押しやすく、横スクロールなしで閲覧できる状態を指します。PC 向けのページをそのまま縮小表示するのではなく、画面幅に合わせてレイアウトを組み替え、拡大操作なしで内容が伝わることが条件です。Google もスマホ版を基準に評価するため、今では必須の前提になっています。

スマホからの閲覧が多数を占める今、モバイルフレンドリーは「あると良い」ではなく前提条件です。 判断は難しく見えて、実際は具体的なチェック項目に分解できます。次の 3 つが満たせていれば、ほとんどのサイトは合格します。

  • 実寸で表示されるviewport の指定があり、勝手に縮小されない
  • 画面幅に合う — レスポンシブデザインで、横スクロールなしに収まる
  • 操作しやすい — 文字が拡大不要で読め、リンクやボタンが指で押せる大きさ

いずれも見た目の印象ではなく、HTML と CSS の実装で決まります。だからこそ機械的に確認でき、直し方も明確です。以下で 1 つずつ見ていきます。

viewport メタタグが無いとどうなりますか?

viewport メタタグが無いと、多くのスマホはページを 980px 前後の仮想的な PC 幅で描画し、全体を縮小して表示します。結果、文字は小さく潰れ、利用者は毎回ピンチ拡大を強いられます。head 内に width=device-width を含む 1 行を置くだけで、端末の実際の画面幅で表示され、この問題は解消します。まず確認すべき最初の項目です。

これが最も基本で、かつ抜けていると影響が大きい項目です。スマホのブラウザは、viewport の指定が無いページを「PC 用に作られたページ」と見なし、980px 前後の仮想的な横幅で描画してから、画面に収まるよう全体を縮小します。 結果として文字は豆粒のようになり、利用者は毎回ピンチ操作で拡大しなければ読めません。

viewport メタタグの有無による表示の違い
状態スマホでの描画幅利用者の体験
width=device-width端末の実際の画面幅拡大せず読める(正しい
指定が無い980px 前後の PC 幅全体が縮小され、毎回拡大が必要(NG
user-scalable=no実寸だが拡大禁止弱視の利用者を締め出す(NG
viewport の正しい指定と、避けるべき指定
<!-- これを head 内に置く。width=device-width で端末の実寸表示になる -->
<meta name="viewport" content="width=device-width, initial-scale=1">

<!-- ★ 無いと 980px 前後の PC 幅で描画され、全体が縮小表示される(NG) -->

<!-- ★ 拡大の禁止は入れない。弱視の利用者を締め出す(NG) -->
<meta name="viewport" content="width=device-width, initial-scale=1, user-scalable=no">

指定する内容は width=device-width, initial-scale=1 の 1 行で十分です。 幅を端末に合わせ、初期倍率を等倍にする、という意味です。ここに拡大を禁じる値を足さないことが、 アクセシビリティを保つ上で大切です。

レスポンシブデザインとは何ですか?

レスポンシブデザインとは、1 つの HTML を CSS のメディアクエリと可変レイアウトで画面幅に応じて組み替える手法です。スマホ用に別 URL を用意する必要がなく、同じ内容を 1 つの URL で配信できるため、Google も推奨しています。固定 px 幅ではなく %・fr・max-width などの可変指定を基本にし、折り返しや段組みを画面幅で切り替えます。

viewport で実寸表示にしたら、次は中身を画面幅に合わせて組み替える番です。 これがレスポンシブデザインで、柱は 2 つあります。

  • 可変レイアウト — 幅を固定 px ではなく %frmax-width で指定し、画面幅に追従させる
  • メディアクエリ@media (min-width: 768px) のように、画面幅で段組みや余白を切り替える
可変レイアウト + メディアクエリの最小例
/* 可変レイアウト: 固定 px ではなく画面幅に追従させる */
.container {
  width: 100%;
  max-width: 960px;
  margin-inline: auto;
}

/* メディアクエリ: 画面幅で段組みを切り替える */
.grid { display: grid; grid-template-columns: 1fr; }
@media (min-width: 768px) {
  .grid { grid-template-columns: 1fr 1fr; }
}

スマホ用に別 URL(いわゆる m ドット)を用意する構成もありますが、内容の同期や正規 URL の管理が二重になり、事故が増えます。 1 つの HTML と CSS で完結するレスポンシブは、URL が 1 本で済むぶん Google にも管理者にも素直です。

モバイルファーストインデックスとは何ですか?

モバイルファーストインデックスとは、Google がスマホ版のページ内容を基準にクロール・評価する仕組みで、現在はほぼ全サイトがこの方式で処理されます。PC 版にだけ本文や構造化データを載せ、スマホ版で省略していると、その省略した内容は評価対象から外れます。本文・見出し・alt・構造化データを PC 版とスマホ版で揃えることが重要です。

ここは誤解が多い点です。「PC 版が本番で、スマホ版はおまけ」という感覚は、もはや逆になっています。 Google はスマホ版のページを主としてクロールし、検索順位もスマホ版の内容で決めます。 したがって、次のような「スマホ版だけ省略」は、そのまま評価の取りこぼしになります。

  • 本文の一部をスマホで折りたたみ・非表示にしている — 表示自体はしていれば通常は評価されるが、DOM から丸ごと削ると対象外になる
  • 構造化データを PC 版にしか入れていない — スマホ版にも同じ 見出し構造・JSON-LD を置く
  • 画像の alt をスマホ版で省いている — PC 版と揃える

タップ領域や文字サイズは何を守ればいいですか?

タップ領域は十分に大きく、本文は拡大不要な文字サイズにし、横スクロールを発生させないことが要点です。指で押す対象は目安として 24×24px 以上、快適には 48px 前後を確保し、隣の要素と間隔を空けます。本文は 16px 前後を基準にし、ページ幅は画面に収めて、左右にはみ出す要素を作らないようにします。

レイアウトが画面幅に合ったら、最後は指での操作に耐えるかどうかです。マウスカーソルと違い、 指は太く、狙いも大まかです。小さすぎるリンクや、隣同士が近すぎるボタンは、誤タップの元になります。

タップ領域・文字サイズ・横スクロールの目安
項目目安補足
タップ領域24×24px 以上(推奨 48px 前後)隣の要素との間隔も空ける
本文の文字サイズ16px 前後拡大しなくても読めることが基準
横スクロール発生させない画面幅を超える要素を作らない
タップ領域と文字サイズの確保
/* タップ領域を確保する。小さいアイコンボタンでも実寸を広げる */
.icon-button {
  min-width: 48px;
  min-height: 48px;
}

/* 本文は拡大不要なサイズに。16px 前後を基準にする */
body { font-size: 16px; line-height: 1.7; }

横スクロールは、幅を px で決め打ちした画像・表・埋め込みが原因で起きがちです。 画像には max-width: 100% を効かせ、表のように縮められないものは、その要素だけを横スクロールさせてページ本体は画面内に保ちます。

よくある実装ミスは何ですか?

よくある失敗は、viewport の指定で拡大を禁止すること、固定幅の要素で横スクロールを生むこと、スマホ版で内容を削ることの 3 つです。user-scalable=no や maximum-scale=1 は拡大を封じ、弱視の利用者を締め出します。幅の広い画像や表は max-width と横スクロール用の工夫で、ページ全体ではなくその要素の中だけに収めます。

  • 拡大の禁止user-scalable=nomaximum-scale=1 を viewport に入れる。弱視の利用者が拡大できなくなる
  • 固定幅による横スクロールwidth: 1200px のような決め打ちや、はみ出す画像・表
  • スマホ版で内容を削る — モバイルファーストインデックスで、削った分がそのまま評価から外れる
  • タップ領域が狭い・密集 — 小さなアイコンやリンクが隣接し、誤タップを誘発する

いずれも「スマホでの見え方を後回しにした」結果として現れます。設計の早い段階からスマホ幅で確認しておくと、 こうした手戻りを避けられます。表示速度の観点は Core Web Vitals も併せて参照してください。

モバイルフレンドリーはどう確認しますか?

確認は Search Console の「ページ エクスペリエンス」やブラウザの Lighthouse で行います。かつて存在した Google 単体のモバイルフレンドリー テストは 2023 年 12 月に終了したため、現在はこれらを使います。加えて、実機やブラウザの開発者ツールの端末エミュレーションで、拡大せず読めるか・横スクロールが出ないかを目視で確かめるのが確実です。

かつては URL を入れるだけの「モバイルフレンドリー テスト」という単体ツールが Google から提供されていましたが、2023 年 12 月に終了しました。現在は次の方法で確認します。

  • Search Console — 「ページ エクスペリエンス」で、実サイトのモバイル面の状況を確認する
  • Lighthouse — ブラウザの開発者ツールに内蔵。ページ単位で機械的にチェックできる
  • 端末エミュレーション / 実機 — 開発者ツールの端末表示や実機で、拡大せず読めるか・横スクロールが出ないかを目視する

機械が判定できるのは viewport の有無や文字サイズといった形式的な部分までです。 「指で押しやすいか」「一目で読めるか」は、最後は実機で自分の指で触って確かめるのが確実です。

参考にした一次情報

関連する解説

自分のサイトは、実際どうなっているか

この記事で説明した項目は、すべて無料の診断ツールで実測できます。URL を入れるだけ・登録不要です。

無料で診断する