Cursor などの AI Agent が使える IDE だけで、MagicPod の失敗テストについて 原因調査を行うシンプルな方法 を紹介します。
（この記事はMagicPodアドベントカレンダー2025の21日目です。本文はOpenAIのCodexを活用して作成しました。）
手順
- ローカルにアプリのリポジトリをクローンする。
- Cursor などの AI Agent がセットアップされた IDE でリポジトリを開く。
- MagicPod のテスト結果画面で「テスト失敗の理由を問い合わせる」ボタンを押し、問い合わせフォームに 添付されているファイルをすべてローカルにダウンロード する。
※ 実際に問い合わせフォームを送信する必要はありません。 - IDE を MagicPod の MCP サーバー に接続しておくとより安心ですが、ひとまず任意で問題ありません。
- 以下のようなプロンプトで AI Agent に質問を投げる。
テスト失敗・根本原因調査 依頼テンプレート
# 依頼内容
あなたは熟練でスキルの高いプロの開発者です。
リポジトリの内容とMagicPodテスト結果資料を参照して、テスト失敗の根本原因を特定し、アプリ側の潜在的な問題を見つけて修正案を示して下さい。
テスト側のワークアラウンドではなく、実装の改善を優先して下さい。
以下の観点で回答してください：
1) flakyかアプリ起因かの判断
2) ロケータ/タイミング/環境要因の可能性
3) 必要な追加情報
# 発生している事象の説明（できるだけ詳しく）
- 事象
- 再現頻度
# 重点
- アプリ側に修正すべき問題が無い場合は、その旨を明確に述べ、テスト側が flaky なだけであれば改善提案を出すこと
- パフォーマンス / 無限スクロール / 仮想化・配列上限の観点を特に見ること
# MagicPodテスト結果資料（必ず参照）
# 求めるアウトプット
1) 根本原因の説明
- ログ / ソースの具体的な箇所を引用し、なぜそう判断するかを示す。
2) 修正案（できるだけ具体的に）
- アプリ側: 具体的な変更方針
（例: 仮想化導入、配列上限、ロード待機 / 再試行の設計）
- テスト側: アプリ問題が無い場合のみ、flaky 改善策を明記する。
3) 切り分け結果
- アプリ側に問題があるか / ないかを明確に記載し、ない場合はテスト側フレークの理由を述べる。
4) モデル名の署名
- レポートの最後に、レポートを作成したAI Agentのモデル名を署名する。
5) 出力先ファイル
- MagicPodテスト結果資料と同じフォルダにMDファイルで出力する。
使ってみた所感
耐久テストなどでは、テスト実装側の問題によって失敗するケース も多く、
MagicPod のテスト失敗ログだけを渡されても、開発チーム側での調査が難しいことがあります。
そのような場合でも、
- アプリのリポジトリ
- MagicPod の失敗テスト詳細ログ
- UI Tree
- スクリーンショット
を突き合わせて AI Agent に調査させることで、
- アプリ側の問題
- 自動テスト側の問題
を 解像度高く切り分けてもらえる 点は、大きなメリットだと感じました。
また、自動テスト側を修正する場合も、UI Treeやスクリーンショットを渡しているため、AI Agent がテストを修正するための具体的なロケーターまで、そのままコピペできるレベルで作成してくれます。
補足
- 「発生している事象の説明」を最初に詳しく書いておくことで、Agent がログやソースを読む際のコンテクスト理解の解像度が上がるようです。
- ChatGPTとGeminiなど**複数のモデルでそれぞれ調査レポートを作成し、意見相違があれば付き合わせるようにすると、より精度が高くなり安心だと思います。
- 原因調査に使ったCodexに、そのままこの記事の下書きも作ってもらいました。
MagicPodの公式サイトはこちらです。
https://magicpod.com/