/moai e2e

Web・モバイル・デスクトップアプリケーションの E2E (End-to-End) テストを生成し実行するコマンドです。プロジェクトタイプを 自動検出 し、プラットフォームに合った CLI 優先ツールチェーン を選択してトークンを最小化しながら実行します。

情報

一行要約: /moai e2e は「ユーザージャーニー検証ツール」です。ログイン → 決済 → 確認のような実際のユーザーフローをブラウザ・シミュレーター・デスクトップアプリで最後まで実行して検証します。

情報

スラッシュコマンド: Claude Code で /moai:e2e と入力すると、このコマンドをすぐに実行できます。/moai だけ入力すると、利用可能なすべてのサブコマンド一覧が表示されます。

ユニットテストが関数 1 つを検証するとすれば、E2E テストは ユーザーの実際のジャーニー全体 を検証します。/moai e2e はこのプロセスを自動化します — プロジェクトが Web かモバイルかデスクトップかを自ら判別し、プラットフォーム別の基本ツールチェーンを選んでテストスクリプトを書き実行します。

全体のフローは次のとおりです。

flowchart TD
    Start["/moai e2e 実行"] --> Detect["プラットフォーム自動検出
(プロジェクトマーカースキャン)"]
    Detect --> Select["ツールチェーン選択
(デフォルト値推奨 + ユーザー確認)"]
    Select --> Journey["ユーザージャーニーマッピング
(ルート・ドキュメント分析)"]
    Journey --> Script["テストスクリプト作成"]
    Script --> Run["CLI 優先実行
(出力はファイルへ、コンテキストには要約のみ)"]
    Run --> Record["記録 (オプション)
--record 時にネイティブトレース"]
    Record --> Report["結果報告
(ジャーニー別ステータス + アーティファクトパス)"]

> /moai e2e

引数なしで実行するとプロジェクトタイプを検出した後、推奨ツールチェーンと発見されたユーザージャーニーを提示し、選択を受けて進行します。

# ツールチェーンを指定してすぐ実行
> /moai e2e --tool playwright

# 特定のジャーニーのみ実行
> /moai e2e --journey login

# 実行プロセスを記録 (トレース/レコーディング)
> /moai e2e --record

プラットフォームごとに基本ツールチェーンが決まっており、すべての基本経路は CLI のみで完結 します。

選択したツールチェーンがインストールされていない場合、インストールコマンドを先に提示し、承認後にインストール → バージョン再確認 → 進行します。

デスクトップネイティブレーンは 3 つの OS (macOS・Windows・Linux) のアクセシビリティレシピをすべてドキュメント化しますが、ホスト OS ルール に従い、ホストと異なる OS のレシピは宣言的ドキュメントとしてのみ扱い、実際のプローブ・実行はホスト OS に対してのみ行います。

プロジェクトの マーカーファイル を読んでプラットフォームを分類します。検出はマーカーベースで、特定の言語やフレームワークを優遇しません。

プロジェクトドキュメントとルート定義 (routes.ts、urls.py、router.go、ナビゲーショングラフなど) を読んでテストするユーザージャーニー候補を発見します。ログイン、核心機能、エラー処理のような重要な経路が優先です。

ジャーニー: ユーザーログイン
ステップ:
1. /login へ移動 (Web) | ログイン画面でアプリ起動 (モバイル/デスクトップ)
2. メールアドレス入力
3. パスワード入力
4. 送信
5. /dashboard へのリダイレクト確認
6. ウェルカムメッセージ表示確認

選択されたツールチェーンの規約に合わせて e2e/ ディレクトリにテストスクリプトを作成します。

すべてのジャーニーステップは 検証可能な結果 と対になります — アサーション (assertion) のないナビゲーションスクリプトは作成しません。

テストを実行し、ジャーニー別の PASS/FAIL 状態・所要時間・アーティファクトパスを表で報告します。失敗したジャーニーは失敗地点のログ抜粋とスクリーンショットパスが併せて提供されます。

--autofix フラグを与えると Phase 3 実行で 失敗や改善の余地 が見つかったとき、オーケストレーターが修正を manager-develop エージェントに委任して Phase 3 を再実行するループに入ります。フラグがないか Phase 3 が green ならこのステップはスキップします。

flowchart TD
    Run["Phase 3 実行"] --> Fail{"失敗/改善阻止?"}
    Fail -->|"いいえ"| Green["Phase 5 報告"]
    Fail -->|"はい (--autofix)"| Approve["進入承認 1 回"]
    Approve --> Group["阻止のグループ化
独立=並列 / 依存=順次"]
    Group --> Fix["manager-develop
autofix: localize→repair→validate"]
    Fix --> Run

• 進入承認 1 回: 最初の委任前にオーケストレーターが 1 回承認を受けます。この承認がループ全体を包み、以降の反復では再度尋ねません。拒否すると従来の手動の次ステップフローに戻ります。
• 阻止のグループ化: 異なるファイルを触る独立した阻止は並列 fan-out、同じモジュールを触る依存する阻止は順次処理します (同時書き込み衝突の防止)。
• ループ限界: 最大 3 回反復 (ci-autofix-protocol.md と同じ)。green なら報告、3 回使い切ったら残余の失敗とアーティファクトパスをユーザーに回帰します。

/moai e2e の核心的な設計原則は CLI 優先 (CLI-first) です。AI コンテキストに冗長な出力を積む代わりに、最も安い経路から使います。

1. CLI + 制限された末尾出力: 実行ログ全体は e2e/.runs/ 配下のファイルに保存し、コンテキストには終了コード + 最後の一部のみを表示します。ログファイルのパスは常に引用されます。
2. 構造化リポーター: 失敗分析時に全体の再実行の代わりに JSON リポーター出力から 失敗したスペックのみ を選別して読みます。
3. MCP は条件付き: パフォーマンストレース、Lighthouse 類の監査のように CLI で不可能な機能にのみ MCP ツールを使います。MCP はどの基本経路でも必須の依存性ではありません。

報告書・トレース・スクリーンショット・レコーディングはプロジェクトローカルの e2e/ ディレクトリに保存され パスで引用 されます — 内容がコンテキストにインライン化されません。

--record フラグを使うと選択したツールチェーンの ネイティブ記録機能 で実行を記録します。

テストする E2E 表面が検出されないと (例: Web/モバイル/デスクトップの進入点がない純粋なライブラリ)、どのマーカーを確認したかの根拠とともに 「E2E 対象なし」 を報告し、e2e/ アーティファクトを作らずに正常終了します。

Electron でも Tauri でもない ネイティブデスクトップアプリ (純粋な macOS アプリ、WinUI、Qt/GTK など) が検出されるとこの分岐へは行きません — デスクトップネイティブ自動化レーン (macOS の axcli、Windows の FlaUI.WebDriver、Linux の dogtail) にルーティングされ、正常にテストが進行します。「E2E 対象なし」分岐はどの表面もない純粋なライブラリにのみ予約されています。

/moai e2e の実行主体は e2e-tester エージェントです。すべてのユーザー選択質問は MoAI オーケストレーターが担当し、e2e-tester は選択結果を受け取って実行のみを行います。

flowchart TD
    User["ユーザーリクエスト"] --> Orchestrator["MoAI オーケストレーター"]
    Orchestrator --> Detect["e2e-tester
プラットフォーム検出 + ツールチェーンプローブ"]
    Detect --> Ask["オーケストレーター
ツールチェーン・ジャーニー選択質問"]
    Ask --> Exec["e2e-tester
スクリプト作成 + CLI 実行 + 記録"]
    Exec --> Report["オーケストレーター
結果報告"]

• /moai fix - 一回限りの自動修正
• /moai loop - 反復修正ループ
• /moai - 完全自律の自動化