「地図を表示するだけなら、Google Maps を埋め込めばいい」
最初はそう考えていた。でも、飲食店予約サービスの店舗詳細ページに地図を組み込む設計を担当したとき、「地図を見せる」ことと「地図をサービスに溶け込ませる」ことはまったく違う問題だと気づいた。
Google Stitch で地図UIを含む画面を設計してみると、地図の「配置・サイズ・操作性・周辺情報との関係」のひとつひとつが、ユーザー体験に直結することがわかってきた。
結論から言うと——地図・位置情報UIの設計で最も重要なのは、「地図だけ」ではなく「地図と周辺情報の関係性」だ。ユーザーが地図から何を読み取り、次にどんなアクションをとるのか——その流れを設計することが、位置情報UIをサービスに溶け込ませる鍵になる。
地図・位置情報UIの役割
位置情報UIとは、ユーザーの現在地・目的地・スポットの場所などを地図や位置情報と組み合わせて表示するUI群のことです。飲食店予約・不動産・配送追跡・フードデリバリー・旅行計画など、場所に関わるほぼすべてのサービスで必要になります。
地図UIが使われる主なシーン：
- スポット詳細画面：店舗・施設・物件の場所を確認する。周辺の交通機関・駐車場情報とセットで表示されることが多い
- 一覧＋地図の複合画面：リスト形式とマップ形式を切り替えられる画面。不動産・求人・飲食店検索でよく使われる
- リアルタイム追跡画面：配送・ライドシェア・友人の現在地などをリアルタイムで追う画面
- ルート案内画面：現在地から目的地までの経路を表示する画面
地図UIが難しい理由
地図UIの設計が難しい理由は、「地図」という特殊なコンテンツを扱う点にある。
地図は情報密度が高く、それ自体がUI要素を持つ（ズーム・パン・ピン・ラベルなど）。テキストやカードのUIとは異なる操作体系を持つため、サービス固有のUIと地図を自然に共存させることが設計上の課題になる。
Stitch で地図UIを設計した体験
飲食店予約サービスの「店舗詳細ページ」に地図を組み込む設計をStitchで行った。
最初のプロンプトと課題
「店舗詳細ページに地図を表示する画面を作って」というプロンプトで生成すると、ページ中段に正方形の地図エリアが配置されたUIが生成された。地図の上にはピンが刺さっていて、住所テキストが下に表示される。
悪くはない。でも「地図を確認した次にどうするか」が伝わってこなかった。電車？徒歩？駐車場は？——ユーザーが地図を見た後に必要とする情報が、地図の周辺に配置されていなかった。
設計を見直した。「地図はあくまで『場所を確認するツール』であり、確認した後のアクションにつながる情報を周辺に配置する」という方向性を決め、プロンプトを書き直した。
「地図 + アクション情報」の複合設計
書き直したプロンプト：「飲食店詳細ページの地図エリア。地図（高さ200px、角丸8px）+ 地図の下に最寄り駅（徒歩X分）・駐車場有無・住所テキストを縦に並べる。右下に『Google マップで開く』外部リンクボタン。地図エリア全体をタップするとGoogle マップが起動する。スマートフォン向け。」
生成されたUIは、地図を確認したユーザーが自然に「最寄り駅から徒歩X分か」「駐車場があるな」という情報にアクセスでき、さらに詳しく知りたいときは外部マップアプリに遷移できる構成になっていた。
実際に使ってみてわかったのは、地図UIの設計で重要なのは「地図そのもの」より「地図とその周辺に置く情報の関係性」だということだ。
地図UI設計の主要パターン
Stitch でさまざまな地図UIを設計してきた経験から、よく使うパターンを整理する。
リスト＋マップの切り替えUI
不動産・飲食店検索などでよく使われる「リスト表示とマップ表示を切り替える」パターン。
設計のポイント：
- 切り替えボタンは画面上部の固定エリアか、FAB（フローティングアクションボタン）として配置
- マップ表示時は地図上にピンを表示し、タップで詳細カードがボトムシートに表示される
- リスト表示からマップ表示に切り替えたとき、選択中のアイテムが地図上でハイライトされる
Stitch でプロンプトに「リスト表示とマップ表示の切り替えタブ付き。マップ表示時はボトムシートに選択スポットのサマリーカードを表示」と指定すると、この複合UIが生成される。
現在地表示と「近くのスポット」UI
ユーザーの現在地を基点にした「近くのスポット」表示は、位置情報を活用する最も一般的なパターンだ。
設計時の注意点：「現在地の取得を許可していないユーザー」の状態も必ず設計する。現在地が取得できない場合の代替表示（検索エリア入力フォーム・デフォルト地域の地図表示）をセットで設計することが重要だ。
Stitch での地図プレースホルダーの扱い
Stitch はリアルの地図（Google Maps・Apple Maps）をそのままUIとして生成することはできない。地図エリアは「地図風のグレー矩形」または「地図のスクリーンショットを貼ったイメージ」として表現される。
これは制約だが、設計上は問題ない。重要なのは「地図エリアのサイズ・配置・周辺のUIとの関係」であって、地図の中身そのものではないからだ。
Stitch で地図プレースホルダーを使うときは、プロンプトに「地図プレースホルダー（高さ〇〇px・角丸〇px・背景色#E5E7EB）、中央にピンアイコン（24px）」と明示することで、意図した大きさと位置に地図エリアが生成される。
よくある失敗と対処法
- 失敗1：地図エリアが大きすぎてコンテンツを圧迫する——スマートフォン画面で地図を半画面以上占めるサイズにすると、住所・営業時間・レビューなどの重要情報がスクロールしないと見えなくなります。モバイルでは地図の高さを150〜250pxに抑え、タップで全画面マップに切り替えられる設計がバランス良いです。
- 失敗2：地図だけ置いて周辺情報を設計しない——地図を表示した後にユーザーが必要とする情報（交通・駐車場・住所・外部マップリンク）を設計しないと、地図を見た後の行動が途絶えます。地図と周辺情報は必ずセットで設計しましょう。
- 失敗3：現在地未許可状態の設計がない——位置情報の取得許可を得られなかった場合の代替UIがないと、ユーザーは「地図が表示されない」状態で迷子になります。許可なし状態の代替表示（住所入力・デフォルト地域）を必ず設計しましょう。
- 失敗4：地図上のピン・ラベルが多すぎる——多数のスポットを同じ地図に表示する場合、ピンが密集して何も読めなくなります。クラスタリング（近いピンをまとめて数字で表示）や、表示件数の上限設定が必要です。
- 失敗5：モバイルでの操作性を考慮しない——地図のズーム・パン操作がページスクロールと競合することがあります。「地図エリアをタップして全画面モードにしてから操作する」設計が、モバイルでは使いやすいことが多いです。
よくある質問（FAQ）
Q. Google Stitch で地図UIを設計するとき、実際の地図データはどう扱いますか？
A. Stitch はGoogle MapsやApple Mapsの実データを表示することはできません。地図エリアはプレースホルダー（色付き矩形＋ピンアイコン）として設計します。実装時にGoogle Maps API・Mapbox・Leaflet.jsなどの地図ライブラリを埋め込む前提で、Stitch では「地図エリアのサイズ・配置・周辺UIとの関係」を設計することに集中しましょう。
Q. リスト表示とマップ表示の切り替えUIをStitchで設計するとき、どんなプロンプトが効果的ですか？
A. 「画面上部に『リスト』『マップ』の切り替えタブ。マップ表示時：画面上部2/3が地図エリア、下部1/3にスワイプ可能なスポットカードが横スクロールで表示。リスト表示時：スポットカードが縦に並ぶ一覧。タブはFixed（スクロールしても固定）で表示。」というプロンプトが効果的です。両方のモードをStitchで生成して並べて確認しましょう。
Q. 配送追跡・ライドシェア向けのリアルタイムマップUIはStitchで設計できますか？
A. リアルタイムの動的な地図更新はStitchでは表現できませんが、「追跡中の静止状態」として設計することは可能です。「配送員の現在位置を示すアイコン（バイクマーク）・自宅の目的地ピン・推定到着時間のバナー」を含む地図UI画面をStitchで設計し、リアルタイム更新の仕様はエンジニアに別途伝える方法が現実的です。
Q. 地図UIのダークモード設計はどうすればいいですか？
A. 地図プレースホルダーのダークモードは「背景#1F2937・ピンアイコン#60A5FA」のように指定します。実際のGoogle Mapsにはダークモード対応のスタイルオプションがあるため、実装時にはMap Styleで「night」または「dark」スタイルを指定するよう実装仕様に含めておきましょう。
Q. 地図上にカスタムピンや複数カテゴリのアイコンを使うUIはStitchで設計できますか？
A. 設計できます。「地図上にカテゴリ別ピンを表示。飲食店（フォークアイコン・オレンジ）・カフェ（コーヒーカップアイコン・ブラウン）・ショッピング（バッグアイコン・パープル）のカラーコーディングで区別」というプロンプトで、複数カテゴリのカスタムピンを含む地図UIが生成されます。凡例（Legend）も含めるとより完成度が上がります。
まとめ：地図はUIの「主役」ではなく「文脈の補助」だ
Google Stitch で地図UIを設計してみて、「地図をどう見せるか」より「地図を見た後にユーザーが何をするか」を考えることが本質だと感じた。
地図は強力なUIコンポーネントだ。ひと目で「場所」を伝える力は他のどのUI要素も持っていない。でもその力に頼りすぎると、地図周辺のUI設計が疎かになり、ユーザーは「場所はわかったけど、次に何をすればいいかわからない」状態に陥る。
地図を「サービスの一部」として設計するには、地図エリアを「場所を確認するための補助ツール」と位置づけ、次のアクションにつながる情報を周辺に揃えることが重要だ。
次のステップ：自分のサービスで地図を使っているページを確認し、「地図を見た後にユーザーが次に必要とする情報が、地図の周辺に配置されているか」をチェックしてみましょう。
