コア価値: バグの早期検出 (Shift-Left) および中長期的な動作確認コストのゼロ化
1. 大前提 (The Core Principle)
-
視覚的検証의 必須性: モバイル開発において作成されたPull Request (PR)を完璧にレビューするためには、コードがいかに堅牢なアーキテクチャ、高い可読性を持ち、100%のテストカバレッジを達成していたとしても、レビューアが実際のUI動作やフローを目で確認できる必要がある。
-
現状の生産性ボトルネックの克服: 現在のモバイルアプリ開発において、開発者の作業で最もボトルネックとなっているのは「動作確認」と「動画の撮影・添付」である。動画添付と「簡易的な」動作確認が同時に解決される状態が理想的である。
-
早期バグ検出の経済性 (Shift-Left Testing): バグはQAやテスターなど複数の人の手を経る前に、開発者段階で可能な限り早期に検出することが最もコストが低く抑えられる。自動化パイプラインによって実装直後に非同期検証が常時作動すべき理由がここにある。
-
価値中心の速度制御: 新規開発における「簡易的な」動作確認は、コードの再利用性よりも「確認完了までの速度」が核心である。これらは開発者の介入なしに並行して自動実行されるため、実行速度が多少遅くともリスクテイクが可能である。
-
コスト複雑度の制約: パイプラインの稼働件数が増加しても、発生するインフラコストは常に線形未満、すなわち $O(n)$ 未満でなければならない（許容される遅さの閾値は、チーム内の共通認識と仮説に基づくROI計算に従う）。
2. 何を実現したいか？ (Core Objectives & Cost Scalability)
-
手動リソースの最小化と可視化: 開発者本人が直接動作確認するのと同等の動画を、従来よりも可能な限り「低いコスト」で録画可能にし、実装した開発者本人およびレビューアが即座に確認できる環境を提供する。
-
新規・追加開発コストの抑制 ($O(n \log n)$ の実現): 既存機能の追加開発および新規開発にかかる動作確認コストの複雑度が、長期的には $O(n \log n)$ に収収束する設計とする。毎回木をゼロから作り直すのではなく、小さな「枝（コンポーネント/アサーション）単位」を再利用可能にし、これらを意味のある「大きなレイヤー（画面・フロー単位）」へと段階的にビルドアップ（レイヤーアップ）していく構造を作る。
-
既存機能確認コストのゼロ化: システムが高進化するにつれ、回帰テスト（Regression）に該当する既存機能の確認に投入される開発者の動作確認コストを、中長期的に 「0 (Zero)」 にする。
3. コスト収束モデルのイメージ化 (O(n \log n) Layer-Up Architecture)
毎回「木」をゼロから新しく作るのではなく、「小さな枝」を再利用可能なアセットとしてストックし、それらを組み合わせて大きなレイヤー（コンポーネント ➔ 画面 ➔ フルシナリオ）へビルドアップしていきます。
【コスト抑制のレイヤーアップ・アーキテクチャ】
[ 1. 小さな枝単位 (Base) ] ➔ 100%再利用・使い回し
├── ボタンクリック
├── 入力フィールド検証
└── APIモック定義
▼
[ 2. レイヤーアップ (Combine) ] ➔ 枝を意味のある単位へ結合
├── [枝の結合] ログインフロー
├── [枝の結合] カート追加処理
└── [枝の結合] 決済画面バリデーション
▼
[ 3. 最終的な木 (Scale) ] ➔ 自動結合によるフルシナリオ
├── E2E 購入完了フロー
└── 既存機能自動回帰 ➔ 【中長期の開発者コスト = 0】
4. 段階別マトリクスおよび要求事項検証
[1段階] 動作説明 (Specification Generation)
【核心の問い】 どうすれば低コスト・超高速・安定した性能でスクリプトを作成できるか？
| 判断基準の類型 | 要求事項 | 詳細および実現方法 |
|---|---|---|
| ◆ Required | 1時間以内に作成 | AIエージェントのスキャフォールディング技術を適用し、初期骨格の自動ビルドで作成速度を確保。 |
| ◆ Required | 再利用可能 | 作成されたテストスクリプトをRepositoryでファイル管理し、回帰テスト資産化（中長期コストゼロの基盤）。 |
| ◆ Required | AIの自己ループ | 実行エラーログやXML Hierarchy構造をフィードバックし、AIが自律的にスクリプトを自己修復（Self-Healing）。 |
| ◆ Required | 2回以内の修正で成功 | 厳格な構文制約とテンプレートベースのプロンプティング適用により、エンジニアリングの信頼性を確保。 |
| ◆ Required | 開発者がレビュー可能 | 基礎スクリプトの構文構造を簡潔に維持し、開発者が直感的に判読・修正できるように設計。 |
| ◇ Optional | 5分以内に作成 | コンテキストの軽量化および最小限のコアロジック自動抽出を通じてビルド時間を最適化。 |
| ◇ Optional | マルチプラットフォーム SSOT | Single Source of Truth (SSOT) アキテクチャにより、クロスプラットフォーム間でテストコードを共通化。 |
| ◇ Optional | ファイルの再修正なし | 初期の1回生成のみで、追加の手動ハンドリングなしにダイレクトで実行成功することを目指す。 |
| ◇ Optional | 長期的なトークン防御 | UIツリー圧縮技術などを活用し、長期的なトークン消費量を $O(n \log n)$ に防衛。 |
| ◇ Optional | テスターがレビュー可能 | ドメイン知識の少ないQA・テスターグループでも全体の流れを容易に把握できるネイティブテキストフォーマット。 |
-
📂 補助ツールの候補: Figma UI/UXスペック、要件定義書、プロトタイプ動画、Bajutsu、既存のテスト設計書
-
🤖 実現手段: AIエージェント、テストファイルによる生成
[2段階] 動作実行 (Deterministic Execution)
【核心の問い】 どうすれば再現安定性（Flakyゼロ）を維持したまま、人間が許容できる速度で動作させられるか？
| 判断基準の類型 | 要求事項 | 詳細および実現方法 |
|---|---|---|
| ◆ Required | 速度の上限線 | 人間が手動でテストする速度の2.5倍以下（2.5倍より短い時間）で迅速に完結すること。 |
| ◆ Required | フレーキーゼロ | 非決定論的な要素を排除し、完全な決定論的（Deterministic）な駆動環境を保証（早期検出の正確性を確保）。 |
| ◇ Optional | ターゲット速度 | 最適化されたランタイムにより、人間が手動で実行する速度の1.2倍以下の時間まで短縮。 |
| ◇ Optional | ランタイム制限 | パイプラインの詰まりを防ぐため、1つのシナリオ・動画あたりの再生時間を1分以下に強制。 |
| ◇ Optional | AI介入の分離 | 実行時点では固定型のスクリプトエンジンのみを稼働させ、実行ごとの無駄なAI呼び出しコストを遮断。 |
-
📂 補助ツールの候補: アニメーション速度の調整（Scale Up）
-
🛠️ 候補技術: Appium, Maestro, MobileMCP, Firebase Test Lab
[3段階] 動画撮影および添付 (Media Automation)
【核心の問い】 どうすれば、どこにでも簡単に添付でき、誰もが迷わず閲覧できるか？
-
◆ Required - GitHubに表示可能であること: PRのコメントレイアウト内にインラインで滑らかにレンダリング（埋め込み再生）されること。
-
◆ Required - Notionに表示可能であること: 社内の知識管理ツールであるNotionのメディアブロックおよびリンク埋め込みと完全に互換すること。
-
◇ Optional - 比較的軽量な容量および無変換・無圧縮: レビューアが別個のローディングやダウンロード、手動のエンコードを挟むことなく、ダイレクトにループ再生で確認できる構造の確保。
-
🛠️ 候補技術: AIエージェント, Maestro機能, Playwright, Robolectric + Roborazzi, SwiftSnapshotTesting, Firebase Test Lab, TestPlans, simctl or screenrecord