モバイルアプリの企画で一番時間が溶けるのは、実装ではなく「要件が固まる前の往復」です。画面構成を描いては直し、また描く。プロトタイプ段階のこのループが、そのままスケジュールを押していきます。
Gemini に情報設計を任せ、Figma に形にしてもらう。この分担にしてから、初期フェーズの手戻りが目に見えて減りました。実際のプロジェクトで踏んだ順番のまま、要件定義からユーザーテストまでを追いかけます。
要件定義フェーズ：Gemini による IA（情報設計）
ステップ 1：初期アイデアの構造化
まずは、頭にあるアイデアを Gemini に投げかけます。このとき、完全に完成した要件定義書である必要はありません。
入力例：
「オンライン食べログアプリを作りたいです。
コンセプト：グルメ情報シェア型アプリ
- ユーザーが訪問した飲食店の料理写真をアップロード
- 店舗情報（地図・営業時間・メニュー）を表示
- 他ユーザーの写真・レビューを閲覧
- 好きな店をお気に入り登録
- フォロー機能で、友人の投稿を購読
ターゲット：20～40代の食べ歩き好きな層
まだ具体化していない部分も多いですが、
このアプリの全体像を、機能単位で整理してもらえますか？」
ステップ 2：ユースケース分析
Gemini の出力をベースに、主要なユースケースを列挙してもらいます。
Gemini への続きの質問：
「上記のアプリで、以下のペルソナが操作する
主要なユースケースを5つ挙げてください。
各ケースについて、関連する画面を列挙してください。
ペルソナ A：新しい飲食店を発見したい人
ペルソナ B：自分の美食体験をシェアしたい人
ペルソナ C：友人の食事体験を追跡したい人」
この過程で、アプリに必要な画面数・機能の優先度が自動的に明確化されます。
ステップ 3：画面遷移図の自動生成
Gemini に、テキストベースの画面遷移図を生成してもらいます。
依頼内容：
「以上のユースケースを踏まえて、
このアプリの画面遷移図をテキスト形式で表現してください。
各画面のメイン機能と、遷移先を明記してください。」
Gemini の出力例：
1. タブバーナビゲーション（底部の4つのタブ）
- タブ1：フィード（友人の投稿一覧）
- タブ2：検索（店舗検索）
- タブ3：投稿作成（写真アップロード）
- タブ4：プロフィール（自分の情報）
2. フィード画面
- 画像 + 店舗名 + レーティング + ユーザー名
- タップで店舗詳細へ
3. 店舗詳細画面
- 大きな画像スライダー
- 基本情報（営業時間・住所・電話）
- タブ：メニュー / レビュー / 地図
- ボタン：お気に入り登録 / 電話 / 地図開く
4. 検索画面
- テキスト検索 + フィルター（ジャンル・距離）
- 検索結果リスト
5. 投稿作成画面
- カメラ / ギャラリーから選択
- タグ付け（店舗名・ジャンル）
- テキスト入力（コメント）
- 公開設定
6. プロフィール画面
- ユーザー情報
- 投稿一覧（グリッド表示）
- フォロー / フォロワー数
この出力を、Figma で詳細化する際の、非常に正確な参考資料として活用できます。
Figma でのプロトタイプ構築
ステップ 1：デバイスフレームの設定
Figma を開き、まずモバイルデバイスのフレームを作成します。
推奨設定：
- iPhone 15 / 15 Pro（390×844px）：最新標準サイズ
- 複数デバイス対応なら、別フレームで 411×915px（Android）も並行
ステップ 2：ローフィデリティのワイヤーフレーム化
グレースケールで、Gemini が提案した画面を線画化します。
この段階での作業内容：
- ナビゲーション構造の配置確認
- テキスト・画像領域の仮配置
- ボタン・入力フィールドの位置決め
色・詳細デザインはまだ不要。レイアウトの論理性を確認することが目的です。
ステップ 3：ハイフィデリティへの格上げ
Gemini に色・タイポグラフィの提案をもらい、デザインシステムを構築します。
Gemini への依頼：
「グルメアプリのデザインシステムを定義してください。
- プライマリカラー：1色（アクション・重要な要素）
- セカンダリカラー：1～2色（補助情報）
- ニュートラル：グレースケール（背景・テキスト）
- アクセント：1～2色（警告・成功状態）
また、タイポグラフィスケール（見出し・本文・キャプション）も提案してください。
このアプリは、食べ物の美しさを引き立てる点が肝心です。」
得られた提案を Figma の Variables / Colors で設定し、全画面に適用していきます。
ステップ 4：コンポーネント化
Figma のコンポーネント機能を活用し、再利用可能な UI 部品を定義します。
モバイルアプリで頻出のコンポーネント：
- Button（primary / secondary / ghost バリエーション）
- TextField / TextArea
- Card（店舗 card / ユーザー card / 投稿 card）
- TabBar
- Modal / BottomSheet
- Rating Star
- Tag
これらを一度定義すれば、複数画面での使用時に一括更新が可能になります。
ステップ 5：インタラクティブプロトタイプの構築
Figma Prototyping を活用し、実際の操作フローを可視化します。
主要な Prototype 設定：
タブナビゲーション：
- タブをクリック → 対応する画面に遷移
- アニメーション：Smart Animate で自然な移動を表現
検索フロー：
- 検索フィールド入力 → キーボード表示
- 検索ボタン → 結果画面へ遷移
店舗詳細からのアクション：
- 「電話」ボタン → 通話画面（or 確認モーダル）
- 「地図」ボタン → 地図アプリへのリンク（外部リンク）
- 「お気に入り」ボタン → ハート icon の色変更（On/Off 状態）
Figma Prototyping の高度な活用：
- Smart Animate：画面遷移時に、同じレイヤー（例：ユーザー avatar）を滑らかにアニメーション
- Overlay：キーボード・メニュー・モーダルを、背景を暗くして重ねる
- Scroll：長いリストを、フレーム内でスクロール可能に設定
これにより、単なる画面デザイン集ではなく、実際の操作感を再現したプロトタイプ が完成します。
情報設計（IA）の詳細化
ナビゲーション構造の最適化
初期案のタブバーナビゲーション（4 タブ）が本当に最適か、Gemini と検討します。
質問例：
「このアプリで、ボトムタブバーに4つのタブがあります：
フィード / 検索 / 投稿 / プロフィール
ユーザーの行動フローを考えると、
どのタブへのアクセス頻度が高いと予想しますか？
また、タブの順序を変更すべきでしょうか？」
ユーザー心理を考慮した、より直感的なナビゲーション設計が得られます。
画面遷移の矛盾検出
複数画面を Figma で設計していると、矛盾が生じることがあります。
「店舗詳細画面から、投稿作成画面へ直接遷移できるか？」「フィード画面でユーザー名をタップしたら、そのユーザーのプロフィールへ遷移すべきか？」
これらを Gemini に相談すれば、ユーザー体験を損なわない、論理的な遷移フローが構築できます。
ユーザーテスト用プロトタイプの準備
Figma Share リンクの生成
Figma のプロトタイプは、リンク共有で、デザイナー以外も閲覧・操作できます。
設定手順：
- 「Share」ボタン → 「Copy link」
- リンクをテスターに配信
- テスターは、ブラウザだけで、プロトタイプを操作可能
テスト用シナリオの作成
ユーザーテストを有効にするため、Gemini に実タスクシナリオを生成してもらいます。
依頼例：
「このグルメアプリのユーザーテストを行います。
テスターは、実際のユースケースに基づいたタスクを実行します。
以下の3つのペルソナ別に、テストシナリオを3～4タスク作成してください。
各タスクは、明確だが、操作方法は指示しないレベルで。
ペルソナ A：新しい飲食店を探しているグルメ好き
ペルソナ B：自分の食べ歩き体験をシェアしたい人
ペルソナ C：友人が行った飲食店を確認したい人」
出力例（ペルソナ A）：
タスク 1：「イタリアンレストランを、近所から探してください」
タスク 2：「見つけたレストランの詳細情報を確認し、営業時間を確認してください」
タスク 3：「そのレストランを、お気に入りに追加してください」
このシナリオをもとにテストを実施することで、直感性や情報の発見しやすさといった、定性的なフィードバックが得られます。
フィードバック収集と改善ループ
ユーザーテストから得られるデータ
テスト実施時に、以下のデータを記録します。
- 所要時間：各タスク完了までの時間
- 操作ミス：期待と異なるボタンをクリックした回数
- コメント：テスター本人の感想・困った点
Gemini による改善提案
フィードバックを Gemini に提示し、改善案を得ます。
例：
「ユーザーテストの結果、多くのテスターが
『検索フィルター』の位置に気づきませんでした。
現在、フィルターボタンは検索フィールド横に配置していますが、
より発見しやすい配置を3案提案してください。」
改善案を受け取ったら、Figma で新バージョンを作成し、再度テストを実施。このループを 2～3 回繰り返すことで、洗練されたプロトタイプが完成します。
実装チームへの引き継ぎ
Figma Handoff の活用
Figma Dev Mode で、実装に必要な情報（サイズ・距離・色コード・フォント）を自動抽出できます。
出力される情報の活用：
- iOS / Android の実装チームに、統一された仕様を配信
- デザイントークン（色・フォント・スペーシング）を自動生成し、CSS / Swift コードに変換
Prototype の仕様書としての活用
構築したインタラクティブプロトタイプ自体が、実装チームへの「仕様書」となります。
「ユーザーがこのボタンをタップしたときの遷移」「このモーダルのアニメーション」といった、動的な仕様が、実装チームに正確に伝わります。
ベストプラクティス
1. 早期かつ頻繁なテスト
完璧なプロトタイプを一度に作るのではなく、ローフィデリティの段階から、早期にテストを実施しましょう。修正が容易です。
2. Gemini との対話記録
Gemini との対話内容（なぜこのナビゲーション構造か、どうして4タブか）を、Figma の「Comments」や別ドキュメントに記録しておくと、後々の意思決定に役立ちます。
3. プロトタイプの版管理
Figma の Branch / Version 機能を活用し、テスト前後の版を管理。比較検討が容易になります。
実装例：フィットネスアプリのエンドツーエンドフロー
Phase 1：Gemini での IA 設計（1～2 時間）
要件整理 → ユースケース分析 → 画面遷移図生成
Phase 2：Figma でのプロトタイプ構築（1～2 日）
ワイヤーフレーム → ハイフィデリティ → インタラクティブ設定
Phase 3：ユーザーテスト（1 日）
5～10 名のテスター実施 → フィードバック収集
Phase 4：改善と再テスト（1～2 日）
Gemini による改善提案 → Figma で修正 → 簡易テスト
Phase 5：実装チームへの引き継ぎ（0.5 日）
Dev Mode で仕様抽出 → デザイントークン生成
総所要時間：約 1 週間（従来は 3～4 週間）
まとめ
Gemini × Figma を活用したモバイルアプリプロトタイプ開発は、以下の大きな利点があります。
- 速度：要件定義から実装引き継ぎまで、1 週間程度で実現
- 品質：AI と人間のバランスが取れた、ユーザー中心のデザイン
- 透明性：Gemini との対話記録が、意思決定の根拠となる
プロダクト開発に携わるなら、このワークフローの習熟は、競争優位性へと直結します。ぜひ、次のプロジェクトから試してみてください。