フレームワーク活用ガイドひとことで言うと#
「まずスマートフォンの小さな画面で最高の体験を設計し、そこからタブレット、デスクトップへと段階的に拡張する設計思想」。画面が小さいモバイルでは本当に必要なコンテンツと機能だけが残る。この制約が、すべてのデバイスで優れた体験を生む原動力になる。
押さえておきたい用語#
- ブレイクポイント（Breakpoint）
- 画面幅に応じてレイアウトを切り替えるCSS上の境界値。コンテンツが崩れる地点で設定する。
- タッチターゲット（Touch Target）
- モバイルでタップ可能な要素の最小サイズ。Appleは44×44px、Googleは48×48dpを推奨。
- ファーストビュー（First View）
- スクロールせずに最初に見える画面領域。ここに最重要コンテンツを配置する。
- min-widthメディアクエリ
- モバイルファーストCSS の基本。小さい画面を起点に、大きい画面向けのスタイルを追加する書き方。
モバイルファーストの全体像#
こんな悩みに効く#
- デスクトップ版を先に作ってからモバイル対応すると、毎回レイアウトが崩れる
- モバイルでの利用率が60%を超えているのに、モバイル体験の品質が低い
- 画面に機能を詰め込みすぎて、情報の優先順位が曖昧になっている
基本の使い方#
モバイルの小さな画面ではすべてを表示できない。だからこそ、優先順位が重要になる。
整理の手順:
- ページの目的（ユーザーが達成したいこと）を1つ定義する
- 必要なコンテンツと機能をすべてリストアップする
- 「必須」「重要」「あると便利」の3段階で優先度を付ける
- 「必須」だけでモバイル画面を構成する
ポイント: モバイルで表示しないと決めたコンテンツは、デスクトップでも本当に必要か再考する。多くの場合、モバイルで不要なものはデスクトップでも不要。
320px〜375px幅の画面を基準にUIを設計する。
モバイルUI設計のポイント:
- 1カラムレイアウト: 横並びは避け、縦にコンテンツを積み上げる
- タッチターゲット: ボタンやリンクは最低44×44px（Appleガイドライン）
- 親指ゾーン: 片手操作で届きやすい画面下部に重要な操作を配置する
- フォーム最適化: 適切な入力タイプ（tel, email, number）で最適なキーボードを表示
- テキスト: 最小14px（推奨16px）、行間1.5倍以上で読みやすく
やってはいけないこと:
- ホバー操作に依存する（モバイルにマウスはない）
- 小さなテキストリンクを密集させる
- 横スクロールを要求する
モバイルのデザインをベースに、画面幅に応じてレイアウトを拡張する。
一般的なブレイクポイント:
- 〜599px: スマートフォン（1カラム）
- 600〜899px: タブレット縦（2カラム可）
- 900〜1199px: タブレット横/小型PC（2〜3カラム）
- 1200px〜: デスクトップ（フルレイアウト）
拡張時のポイント:
- カラム数を増やして並列表示する
- サイドバーを追加する
- より詳細な情報を表示する（モバイルでは隠していた補足情報）
- ナビゲーションをハンバーガーメニューから展開型に変更
ポイント: ブレイクポイントはコンテンツが崩れる地点で設定する。デバイスの画面サイズに合わせるのではなく、コンテンツの見え方で判断する。
実際のデバイスでパフォーマンスと使い心地を検証する。
テストの観点:
- 表示速度: モバイル回線（3G/4G）での読み込み時間。目標は3秒以内
- タッチ操作: ボタンやリンクが指で押しやすいか、誤タップがないか
- フォーム入力: キーボードの種類、オートコンプリート、入力の手間
- 画像: 適切なサイズで配信されているか
- 実機テスト: シミュレーターだけでなく、実際のスマートフォンで確認する
最適化のポイント:
- 画像の遅延読み込み（Lazy Loading）
- CSSのmin-widthメディアクエリ（モバイルファーストのCSS）
- Core Web Vitalsのスコア改善
具体例#
課題: デスクトップ向けに設計されたニュースサイト。モバイルからのアクセスが70%を占めるが、モバイル版は「デスクトップの縮小版」で、記事の読みにくさとページ速度の遅さが問題。
モバイルファーストで再設計:
| 要素 | Before（デスクトップ→縮小） | After（モバイルファースト） |
|---|---|---|
| レイアウト | 3カラム→無理に1カラムに押し込み | 1カラムで設計→PC版で3カラムに拡張 |
| 記事タイトル | 14px（小さすぎる） | 20px（モバイルで読みやすいサイズ） |
| 画像 | デスクトップ用の大画像をそのまま配信 | モバイル用に最適化した画像を配信 |
| ナビゲーション | 全カテゴリを上部に横並び→はみ出る | ハンバーガーメニュー→PC版で展開 |
| 読み込み速度 | 8秒（モバイル回線） | 2.5秒（モバイル回線） |
結果: モバイルの直帰率が65%から42%に改善（35%減少）。平均滞在時間は1分20秒から2分45秒、Lighthouseスコアは35から82に向上。
課題: リード獲得フォームがデスクトップ前提の横2カラム設計。モバイルからのフォーム完了率が12%と低く、デスクトップの28%と大きな差があった。
モバイルファーストで再設計:
- フォームを1カラム縦積みに変更
- 入力項目を15項目から7項目に削減（「必須」のみに絞込み）
- 電話番号はtel型、メールはemail型で最適キーボードを表示
- 送信ボタンを画面下部に固定（sticky）
結果: モバイルのフォーム完了率が12%から25%に向上（2.1倍）。デスクトップでも1カラム化の恩恵で28%から34%に改善。
課題: 店舗検索・メニュー閲覧・モバイルオーダーを提供するWebサイト。ユーザーの85%がスマホからアクセスするが、メニューページの読み込みに6秒かかり、モバイルオーダーの離脱率が52%。
モバイルファーストで再設計:
- メニュー画像をWebP形式・srcsetで最適化（6秒→1.8秒）
- 注文ボタンを画面下部に常時表示（スクロールに追従）
- 位置情報から最寄り店舗を自動選択（手動入力を排除）
- デスクトップ版ではサイドにカートサマリーを常時表示
結果: モバイルオーダー数が前年比140%に増加。離脱率は52%から28%に改善し、平均注文単価も8%上昇。
やりがちな失敗パターン#
- デスクトップ版を作ってから「モバイル対応」する — 後からモバイル対応すると、機能やコンテンツを削ることになり、モバイルが「劣化版」になる。最初からモバイルで設計し、デスクトップで拡張する
- モバイル版で機能を削りすぎる — 「モバイルだからシンプルに」と重要な機能まで削ると、ユーザーがデスクトップ版を求めてしまう。コア機能はモバイルでも提供し、UIを最適化する
- 画面サイズだけで判断する — モバイルの制約は画面サイズだけではない。通信速度、タッチ操作、利用状況（移動中、片手操作）も考慮する。デバイスのコンテキスト全体を意識する
- ブレイクポイントをデバイスに合わせて固定する — 端末は無数にある。特定の端末サイズではなく、コンテンツが崩れるポイントで設定するのが正解
まとめ#
モバイルファーストは、小さな画面の制約を活かしてコンテンツの優先順位を明確にし、すべてのデバイスで優れた体験を構築する設計思想。モバイルでの体験をベースに段階的にデスクトップへ拡張することで、「機能てんこ盛り」 を防ぎ、本質的に使いやすいUIが生まれる。まずは次のプロジェクトでモバイル画面から設計を始めてみよう。