2026 年に入って、モバイルアプリの主要画面遷移が静かに置き換わっている。これまで「タップ → フルスクリーン遷移 → 戻る」が支配的だった画面構造が、地図・音楽・配車・決済といった頻繁に使われるユースケースで「タップ → 画面下から半分立ち上がる BottomSheet」へ移行している。
本稿では、その代表例として Uber / Spotify / Google Maps / PayPay の 4 アプリを取り上げ、それぞれの BottomSheet 設計を 4 軸で構造分析する。なぜ各社が「フルスクリーンではなく半モーダル」を選んでいるのか、そして自社プロダクトに半モーダルを取り入れるとき、どの軸で意思決定すべきかを整理する。
なぜ今 BottomSheet なのか — 3 つの構造変化
BottomSheet (半モーダル) 自体は新しい UI ではない。Google Maps は 2014 年から、Apple Maps は 2020 年から本格採用している。にもかかわらず 2024〜2026 年に急速に普及した背景には、3 つの構造変化がある。
第一に、OS の標準コンポーネント化。iOS 15 で UISheetPresentationController が公開され、Android では Material 3 の ModalBottomSheet が成熟した。アプリ側で物理シミュレーション付きのカスタム実装を書く必要がなくなり、3 行のコードで「ドラッグで snap する半モーダル」が出せるようになった。
第二に、画面サイズの大型化と片手操作の限界。日本のスマートフォンの平均画面サイズは 6.5 インチ前後まで上がった一方、ユーザーの手の大きさは変わらない。画面上部のヘッダーやナビゲーションバーへは親指が届かない。下から立ち上がる半モーダルは、操作領域を物理的に届きやすい範囲に集中させる解になる。
第三に、コンテキスト維持の重要性。フルスクリーン遷移は「今いた画面の情報を一度失う」コストを伴う。地図上のピン・再生中の曲・選択中のサービスといった「ユーザーが直前まで見ていたコンテキスト」を背景に残したまま、操作の選択肢だけを前面に出す設計が、タスク完了率を引き上げることが各社の A/B テスト結果として知られるようになった。
4 軸で見る BottomSheet 設計
本稿では以下の 4 軸で各社の BottomSheet を解剖する。
| 軸 | 観点 | 設計差が出るポイント |
|---|---|---|
| トリガー設計 | 何をきっかけにシートが立ち上がるか | 起動直後の常駐 / タップで召喚 / コンテキスト変化で自動展開 |
| Snap Point 設計 | シートが止まる位置の段階数 | Peek のみ / Peek + Large / Peek + Medium + Large |
| 背景コンテキスト保持 | 背景の画面情報をどれだけ活かすか | 背景は完全に暗転 / 透けて見えるだけ / 背景も操作可能 |
| ジェスチャー & OS 標準化 | OS 標準コンポーネントへの準拠度 | 自前実装 / OS 標準を一部カスタム / 完全に標準準拠 |
特に重要なのが Snap Point の段階数だ。シートが止まる高さを 1 段にするか、2〜3 段にするかで、ユーザーが「自分でシートを開閉する操作」を学習する必要があるかどうかが変わる。
3 段階の snap point は「ちらっと見るだけの Peek」「選択肢が見える Medium」「コンテンツに集中できる Large」と機能を分けて配置できる。一方で段階数が多いほどユーザーが迷いやすく、設計者には「中間状態をなぜ用意するか」の明確な理由が求められる。
Uber — 「タスク完了型」シートで予約導線を切り分ける
Uber の BottomSheet は、地図というメインコンテキストを背景に残したまま「配車予約というタスク」を完了させるための設計だ。
- トリガー設計：起動直後にシートがすでに Medium で立ち上がっている。ユーザーが「呼び出す」操作をしない。
- Snap Point：Peek (現在地表示のみ) → Medium (車種選択) → Large (詳細・料金内訳) の 3 段階。
- 背景コンテキスト保持：背景の地図は常にスクロール・ピン操作可能。シート展開中も地図は死んでいない。
- ジェスチャー：自前実装寄り。ハンドル (画面上端の小さな横線) を引っ張ると snap する独自挙動。
ポイントは「配車予約はマルチステップだが、ステップごとに画面を切り替えない」という意思決定だ。出発地確認 → 車種選択 → 料金確認 → 配車確定 を 1 枚のシートの高さ変化で表現することで、ユーザーの「自分は今どのステップか」という認知負荷を下げている。フルスクリーン遷移で同じ機能を組むと「戻る」操作が頻発し、地図を見失う。
示唆：「マルチステップだが地図・タイムラインなどの背景文脈を消したくないタスク」では、フルスクリーン遷移より高さの違う複数 snap を使った方がタスク完了率が上がる可能性が高い。
Spotify — Mini Player は「常駐レイヤー」としての BottomSheet
Spotify の特徴は「画面下に常に Mini Player が貼り付いている」設計だ。これも構造的には BottomSheet の Peek 状態にあたる。
- トリガー設計：再生中の曲がある間は常時表示。ユーザーが消す操作がない。
- Snap Point：Peek (Mini Player) ↔ Large (フルスクリーン Now Playing) の 2 段階。中間状態はない。
- 背景コンテキスト保持：背景は完全に操作可能。プレイリスト閲覧・検索・ホーム遷移を妨げない。
- ジェスチャー：タップでフル展開、下スワイプで Mini 化。スワイプ感度は OS 標準より重め (誤操作防止)。
Spotify の判断は「再生コントロールという機能はアプリ内のどこに居ても呼び出せるべき」というプロダクト思想に直結している。タブバーやヘッダーに置く選択肢もあり得たが、「今何が鳴っているか」というコンテキスト情報を常に画面下に置くことで、ユーザーがアプリを離れて他の作業 (検索・プレイリスト編集) をしても「再生体験そのものは切れない」感覚を作っている。
示唆：「メイン機能 (この場合は音楽再生) が常時バックグラウンドで動き続けるアプリ」では、Mini Player 型の常駐 BottomSheet がタブバー以上に強い継続接点になる。動画配信・通話・ライブコマースなどでも同じ構造が応用できる。
Google Maps — Snap Point 3 段階の「教科書」
Google Maps は BottomSheet 設計の事実上の教科書である。Apple HIG (Human Interface Guidelines) と Material Design 3 の「3 段階 detent」記述例として実装パターンが直接引用されることが多い。
- トリガー設計：地図上のピンタップ・検索結果タップ・現在地情報の表示で自動展開。明示的な「呼び出しボタン」はない。
- Snap Point：Peek (店舗名と評価のみ) → Medium (主要情報 + アクションボタン) → Large (写真・口コミ・営業時間) の 3 段階。
- 背景コンテキスト保持：背景の地図は常に操作可能。シートを Medium まで展開していてもピンの位置・周辺の地理感覚は失われない。
- ジェスチャー：ほぼ OS 標準準拠 (iOS は
UISheetPresentationControllerに近い挙動)。
ここでのキー設計判断は「Peek」の存在だ。ピンをタップしたとき、いきなり Medium まで開かず「Peek (店名 + 評価のみ)」で一旦止める。この 1 段階を挟むことで「タップしたけどこの店じゃない」とユーザーが判断したときに、シートを閉じる手間なく次のピンに移れる。Medium まで一気に開いてしまうと「閉じる → 別のピンをタップ → また開く」のループが発生する。
示唆：Snap Point は「使うかもしれないが、まだ確定していないユーザーの探索行動」を低コストで吸収する役割を持つ。検索 / 探索フローを持つアプリ (不動産 / 求人 / 飲食店検索 / EC 商品検索) では Google Maps の 3 段階を出発点にすると失敗しにくい。
PayPay — 「決済アクション」を画面の上半分に閉じ込める
PayPay は厳密な意味での 3 段階 BottomSheet を使っていないが、「画面の一部だけを占有して決済タスクを完了させる」という設計思想は他 3 社と共通する。特に「スキャンして支払う」のフローは画面上部に決済情報・QR バーコードを集中させ、下部に支払い方法切替の選択肢を置く構造で、構造的には逆向きの半モーダル (TopSheet) と見ることもできる。
- トリガー設計：ホーム画面のタブからスキャン画面に遷移。常駐ではない。
- Snap Point：基本 1 段階。決済アクション中は固定。
- 背景コンテキスト保持：背景は決済中は無効化される (誤操作防止)。
- ジェスチャー：閉じる方向のスワイプのみ。展開操作は持たない。
PayPay の意思決定は「決済というクリティカルな操作中は背景操作を排除する」という金融系アプリ共通の安全要件に従っている。ここでの教訓は「BottomSheet を採用するか否かは UI 美観の問題ではなく、背景に何を残すべきか / 残してはいけないかの判断」だということだ。配車・音楽・地図は背景を残すべきタスクだが、決済確定は背景を消すべきタスクである。
示唆：金融 / 認証 / 確定操作は背景を残さない設計が安全。一方、検索 / 選択 / プレビューは背景を残した方が体験が良い。BottomSheet 採用の判断は「タスクの確定度」で分ける。
4 社 × 4 軸の設計マトリクス
| 軸 | Uber | Spotify | Google Maps | PayPay |
|---|---|---|---|---|
| トリガー設計 | 起動直後に自動展開 | 再生中は常駐 | コンテキストで自動展開 | タブ遷移で召喚 |
| Snap Point 段階数 | 3 (Peek/Medium/Large) | 2 (Peek/Large) | 3 (Peek/Medium/Large) | 1 (固定) |
| 背景コンテキスト保持 | ◎ 地図常時操作可 | ◎ 全画面操作可 | ◎ 地図常時操作可 | × 背景無効化 |
| OS 標準準拠度 | △ 一部カスタム | △ 一部カスタム | ◎ ほぼ標準 | ○ 標準モーダル相当 |
| 背景にあるタスク性質 | 探索 + 確定 | 並行作業 | 探索 | 確定 |
注目すべきは「Snap Point 段階数」と「背景にあるタスク性質」の相関だ。探索フェーズが長いタスクほど snap 段階が多く、確定フェーズが中心のタスクほど段階が少ない。これは偶然ではなく、ユーザーが「途中で気が変わる余地」をどれだけ設計に組み込むかという判断の差である。
なぜ「フルスクリーン遷移の代替」として定着しつつあるか
3 つの理由がある。
- 戻る操作のコストが下がる：フルスクリーン遷移は「戻る」ボタンや左端スワイプを伴う。BottomSheet は下スワイプ 1 つで閉じる。1 タスクあたりの摩擦が小さくなる。
- オンボーディング不要：snap point を使った設計は、ユーザーが「ドラッグして大きさを変える」操作を直感的に学習する。Material 3 / iOS の標準コンポーネント化により、他アプリでも同じ挙動なので転移学習が効く。
- デザイナーと PdM の設計コストが下がる：従来は「詳細画面を別ページで用意する」必要があったが、BottomSheet は「同じ画面の中の情報レイヤー」として扱える。情報設計が単純化する。
ただし、安易な BottomSheet 採用は逆効果になりやすい。特に「フルスクリーンで集中して入力させたい長文フォーム」「ステップが 7 段階以上ある手続きフロー」「PayPay のような確定操作」を BottomSheet に押し込むと、操作領域が狭くなり離脱率が上がる。
自社プロダクトへの適用ガイド
PdM・事業責任者が自社アプリに BottomSheet を導入する判断は、以下 3 つの問いから始める。
- 背景に残すべき情報があるか：地図・タイムライン・再生中コンテンツ・選択中の商品など、「ユーザーが直前まで見ていたコンテキスト」を残すと判断精度が上がるタスクか？
- 探索フェーズか確定フェーズか：選択肢を比較する探索なら BottomSheet (3 段階 snap)。確定操作ならフルスクリーンか全画面モーダル。
- OS 標準で済むか：iOS 15+ / Android Material 3 の標準コンポーネントで実装可能なら、自前実装で工数を使うべきではない。標準準拠は将来の OS アップデート追従コストも下がる。
上記 3 問に「Yes」が並んだら BottomSheet の採用候補。snap point は まず 2 段階 (Peek + Large) から始め、データを見ながら必要なら Medium を追加する のが安全。Google Maps の 3 段階を最初から真似ようとすると、自社のタスク構造に合わない中間状態を作ってしまいやすい。
テクラル研究所からの提案
私たちテクラル研究所では、上記のような UI/UX トレンド分析を踏まえた モバイル UX 改善 / リニューアル設計の伴走 を提供しています。BottomSheet 化のような「画面構造のリファクタリング」は、単に見た目を変えるのではなく、ユーザーのタスク構造を分解し直す作業です。
具体的には次のような相談を承っています。
- UX 診断：既存アプリの主要画面遷移を解剖し、BottomSheet 化・snap point 設計の改善余地を提案
- 設計 + 実装伴走：iOS UIKit / SwiftUI / Android Jetpack Compose / React Native のいずれでも OS 標準コンポーネント準拠で実装支援
- PoC / MVP 開発：新規アプリの設計段階から BottomSheet / 半モーダル中心の UI 構造を組み込み、最短 1 か月で動くプロトタイプを構築
「半モーダル化を検討しているが、自社のタスクに合うかわからない」「フルスクリーン遷移ばかりで離脱率が高い」といった段階でも、まずは壁打ち相手としてご相談ください。お気軽にお問い合わせいただければと思います。
出典
- Apple Developer Documentation, "Sheets — Human Interface Guidelines" — https://developer.apple.com/design/human-interface-guidelines/sheets
- Apple Developer Documentation, "UISheetPresentationController" — https://developer.apple.com/documentation/uikit/uisheetpresentationcontroller
- Material Design 3, "Bottom sheets" — https://m3.material.io/components/bottom-sheets/overview
- App Store / Google Play 公開スクリーンショット (Uber / Spotify / Google Maps / PayPay)
