Cursor などの AI Agent が使える IDE だけで、MagicPod の失敗テストについて 原因調査を行うシンプルな方法 を紹介します。
（この記事はMagicPodアドベントカレンダー2025の21日目です。本文はOpenAIのCodexを活用して作成しました。）
手順
- ローカルにアプリのリポジトリをクローンする。
- Cursor などの AI Agent がセットアップされた IDE でリポジトリを開く。
- MagicPod のテスト結果画面で「テスト失敗の理由を問い合わせる」ボタンを押し、問い合わせフォームに 添付されているファイルをすべてローカルにダウンロード する。
※ 実際に問い合わせフォームを送信する必要はありません。 - IDE を MagicPod の MCP サーバー に接続しておくとより安心ですが、ひとまず任意で問題ありません。
- 以下のようなプロンプトで AI Agent に質問を投げる。
テスト失敗・根本原因調査 依頼テンプレート
# Role
あなたは、大規模アプリケーションのデバッグとQAオートメーションに精通した「シニア・フルスタック・エンジニア」です。コードの静的解析と実行ログを照らし合わせ、問題の根本原因を技術的に特定するエキスパートとして振る舞ってください。
# Goal
提供されたリポジトリ情報とMagicPodのテスト結果を分析し、テスト失敗の「真の根本原因」を特定してください。
特に、テスト側の場当たり的な修正（Waitの追加など）ではなく、アプリ側の実装改善（パフォーマンス向上や安定性確保）による解決を最優先とします。
# Inputs
- **事象の概要**: {{EVENT_DESCRIPTION}}
- **再現頻度**: {{REPRODUCTION_FREQUENCY}}
- **リポジトリ・ソースコード**: [ここにコードやファイル構成を貼り付けるか、参照先を指定]
- **MagicPodテスト結果資料 (ログ/スクリーンショット情報)**: [ここにログを貼り付けるか、ファイルを指定]
# Analysis Process (Thinking Process)
回答を生成する前に、以下のステップで思考してください：
1. **ログ解析**: MagicPodのスタックトレースやエラーメッセージから、失敗時のDOM状態とタイムアウトの性質を特定する。
2. **コード照合**: 失敗した操作に対応するアプリ側のコンポーネント実装を確認する。
3. **ボトルネック特定**:
- 仮想化（Virtual List）が正しく動作しているか？
- 配列のレンダリング上限やメモリリークの可能性はないか？
- APIレスポンス待ちとUIの更新タイミングに不整合はないか？
4. **判定**: 「アプリの実装不備（Race Condition, Performance Issue等）」か「テストコードの不備（Flaky）」かを論理的に切り分ける。
# Evaluation Criteria (重点確認事項)
- **仮想化/無限スクロール**: 要素の再利用（Recycling）や、スクロール中のDOM消失がテスト失敗を招いていないか。
- **配列上限**: 大量データ読み込み時のメインスレッドのブロック。
- **タイミング**: テストが待機している要素が、アプリ側の非同期処理の都合で不安定になっていないか。
# Output Format
以下のMarkdown形式でレポートを作成してください。
---
## 1. 根本原因の説明
- **現象の要約**: なぜ失敗したのかを技術的に要約。
- **根拠**: ログの該当箇所やソースコードの行数を引用し、論理的な関連性を説明。
## 2. 修正案
### A. アプリケーション側の改善（最優先）
- 具体的な修正方針（例：仮想化ライブラリの導入、データのプリフェッチ、DOM構造の最適化など）。
### B. テスト側の改善（アプリ側に問題がない場合のみ）
- Flakyを解消するための堅牢なロケータの書き換えや、同期処理の提案。
## 3. 切り分け結果
- [ ] アプリ側に問題あり / [ ] テスト側のフレーク
- 判断理由の総括。
## 4. 必要な追加情報
- 現状の情報だけでは特定できない場合、確認すべきログや追加の調査項目。
---
**Reporter AI Model**: [使用しているモデル名を記載]
使ってみた所感
耐久テストなどでは、テスト実装側の問題によって失敗するケース も多く、
MagicPod のテスト失敗ログだけを渡されても、開発チーム側での調査が難しいことがあります。
そのような場合でも、
- アプリのリポジトリ
- MagicPod の失敗テスト詳細ログ
- UI Tree
- スクリーンショット
を突き合わせて AI Agent に調査させることで、
- アプリ側の問題
- 自動テスト側の問題
を 解像度高く切り分けてもらえる 点は、大きなメリットだと感じました。
また、自動テスト側を修正する場合も、UI Treeやスクリーンショットを渡しているため、AI Agent がテストを修正するための具体的なロケーターまで、そのままコピペできるレベルで作成してくれます。
補足
- 「発生している事象の説明」を最初に詳しく書いておくことで、Agent がログやソースを読む際のコンテクスト理解の解像度が上がるようです。
- ChatGPTとGeminiなど**複数のモデルでそれぞれ調査レポートを作成し、意見相違があれば付き合わせるようにすると、より精度が高くなり安心だと思います。
- 原因調査に使ったCodexに、そのままこの記事の下書きも作ってもらいました。
MagicPodの公式サイトはこちらです。
https://magicpod.com/