Ios Ia Navigation

---
name: ios-ia-navigation
description: |
  iOSアプリの情報設計（IA）と画面遷移（ナビゲーション）を設計するスキル。Apple HIGとWWDCセッションに基づき、
  タブ/階層push/モーダルを情報階層とタスク構造から逆算して選定し、根拠と未確定事項を可視化しながら設計を完遂する。
  使用タイミング: (1) 新規アプリの情報設計時、(2) 画面遷移設計時、(3) 「IAを設計したい」「ナビゲーション構造を決めたい」、
  (4) iPad/iPhone両対応の構造設計時、(5) ディープリンク対応設計時、(6) 既存アプリのリファクタリング時
---

# iOS Information Architecture & Navigation Design

iOSアプリの情報設計（IA）と画面遷移を、Apple HIGの原則に基づいて設計するスキル。

## ミッション

ユーザー提供のドキュメント（PRD、要件、ブランド、既存仕様）を根拠に：
- **情報階層**（トップレベル〜詳細の粒度）
- **画面構成**（スクリーン一覧と役割）
- **画面遷移**（push/modal/tab/splitのルール）
- **例外系**（ログイン、ディープリンク、復帰、空状態）

をiOSのナビゲーション原則に一致する形で設計し、未確定情報は質問で埋めて設計を前進させる。

## ワークフロー

### Phase 0: 事前確認（必須）

以下をユーザーに確認してから設計を開始：

#### 1. 入力ドキュメントの確認
- [ ] 要件ドキュメント（PRD、ユーザーストーリー、機能一覧）
- [ ] コンテンツ定義（扱う情報の種類、属性、関係）
- [ ] 運用制約（権限、課金、規約、オフライン要否）
- [ ] 既存資産（現行アプリ/サイト、分析データ）
- [ ] プラットフォーム条件（iPhone/iPad、最小iOS）

#### 2. 初期質問（Blocker解消）
最低限以下を確認：

| # | 質問 | 影響範囲 |
|---|------|---------|
| 1 | 主要ユーザーは誰？ | ペルソナ、タスク優先度 |
| 2 | アプリを開いてやるTop3タスクは？ | トップレベル構造 |
| 3 | 扱う主役の情報（エンティティ）は？ | コンテンツモデル |
| 4 | 一覧→詳細で見る？作業（編集/作成）が主？ | 遷移パターン |
| 5 | トップレベルに分けるべき領域は？ | タブ/サイドバー設計 |
| 6 | ログイン必須？匿名でどこまで？ | 認証フロー |
| 7 | iPadを主要ターゲットにする？ | Split View設計 |
| 8 | 通知・外部リンクで特定画面に直接入る？ | ディープリンク |

### Phase 1-7: 設計モジュール実行

各モジュールを順次実行し、成果物を生成：

| Module | 目的 | 主要成果物 |
|--------|------|-----------|
| 0 | ドキュメント根拠化 | Evidence Map、用語集 |
| 1 | タスクモデル化 | 主要タスクTop3-7、タスク分解 |
| 2 | コンテンツモデル | エンティティ、関係、階層候補 |
| 3 | トップレベル設計 | タブ/サイドバー構成、責務定義 |
| 4 | 遷移設計 | 遷移種別ルール（push/modal） |
| 5 | 状態保持設計 | タブごとの状態保持ポリシー |
| 6 | iPad適応 | カラム割り当て、並列表示方針 |
| 7 | ディープリンク | ルーティング表、状態復元規則 |

詳細は [references/modules-detail.md](references/modules-detail.md) を参照。

### Phase 8: 成果物統合

すべてのモジュール成果物を統合し、最終ドキュメントを生成。

## 最終成果物

### A. IA成果物
- **A1. コンテンツモデル** - エンティティ、属性、関係（YAML形式）
- **A2. 情報階層マップ** - サイトマップ（Mermaid図）
- **A3. 命名規則** - タブ名・画面タイトルの語彙（表形式）

### B. 画面＆遷移成果物
- **B1. 画面インベントリ** - 画面ID、目的、主要要素、入口/出口（表形式）
- **B2. 遷移ルール表** - from→to、トリガ、遷移種別、戻り方（表形式）
- **B3. ユーザーフロー** - 主要タスク別（Mermaid sequence図）
- **B4. iPhone/iPad適応方針** - カラム構成、縮退時挙動（表形式）

### C. 不確定管理
- **Open Questions** - 優先度、仮定、影響範囲（表形式）

テンプレート詳細は [references/output-templates.md](references/output-templates.md) を参照。

## 規範資料（設計根拠）

| 資料 | 用途 |
|------|------|
| [Apple HIG - Navigation](https://developer.apple.com/design/human-interface-guidelines/navigation) | 遷移原則 |
| WWDC22「Explore navigation design for iOS」 | タブ設計、push/modal使い分け |
| WWDC22「The SwiftUI cookbook for navigation」 | NavigationStack/SplitView実装 |

主要原則は [references/hig-navigation-principles.md](references/hig-navigation-principles.md) を参照。

## 質問プロトコル

### 不足情報の分類
| 分類 | 定義 | 対応 |
|------|------|------|
| **Blocker** | 未回答だと構造が決まらない | 即時質問 |
| **High-impact** | 後で直せるが手戻り大 | 早期質問 |
| **Detail** | 後回し可能 | 暫定仮定で進行 |

### 質問形式
質問は「選択肢＋影響」を添える：
```
Q: トップレベルはA/Bどちらが自然ですか？
- A案: タブ3つ（Home/Search/Profile）→ シンプル、検索が独立
- B案: タブ5つ（上記+Notifications/Settings）→ 直接アクセス可、タブ多め

影響: 検索導線の置き場所、タブバーの密度
```

### 暫定仮定
返答がない場合は仮定で進め、ログに残す：
```yaml
assumption:
  id: A001
  content: "iPadはセカンダリターゲットとしてSplit View対応"
  impact: "変更時はModule 6再設計が必要"
  status: unconfirmed
```

## 設計品質ゲート

### トップレベル設計チェック
- [ ] タブが情報階層を反映している
- [ ] 機能重複がない
- [ ] タブ強制移動を前提にしていない
- [ ] 各タブの責務が明確

### 遷移設計チェック
- [ ] push/modalの使い分けが一貫
- [ ] すべての画面に「出口」が定義
- [ ] 親状態の保持方法が明確
- [ ] modalの積み重ねを抑制

### iPad適応チェック
- [ ] Split View対応が構造として成立
- [ ] Compact時の縮退が自然
- [ ] カラム間の関係が明確

### ディープリンクチェック
- [ ] 全ルートが定義済み
- [ ] 直リンクでも現在地が説明可能
- [ ] 戻り方が破綻しない