はじめに
こんにちは！メドレーで QA エンジニアをしている @Daishu です。
「E2Eテストが失敗したけど、これって本当のバグ？それとも環境要因？」
毎朝、このような確認を繰り返していませんか？本記事では、MagicPod の E2E テストの失敗を自動分析する Slack bot「MagicPod Assistant」の仕組みと実装について解説します。
MagicPod Assistant - Slack bot icon
💡 本記事は MagicPod ミートアップ で発表した内容の技術詳細版です。
MagicPod 以外の E2E テストツールでも応用可能だと思います。
日々のE2Eテストの失敗確認って大変ですよね？
私たちのチームでは、毎朝統合ブランチに対して E2E テスト (MagicPod) を実行しています。
これにより、以下を実現しています：
- 前日にマージされた Pull Request のデグレチェック
- 問題があれば、開発者へ素早くフィードバック
- 統合ブランチを stable に保つ
当然ですが「失敗したテスト = 不具合検知」ではありません。
テスト失敗の要因は様々なため、失敗したテストを 1 件ずつ確認していく作業が必要です：
自動テスト失敗要因となる主な 3 パターン
毎朝の失敗テストの確認の光景
これを毎朝 30 分〜 1 時間かけて実施しています。この作業はデグレの早期キャッチには重要ですが、調査・分析に時間を取られてしまう状況でした。
失敗したテストの確認を自動化したい
従来のプロセスを踏襲して Slack スレッド駆動で失敗確認を自動化できないか検討しました：
# 情報の集約
- MagicPod の失敗通知の Slack をスレッド化して、調査結果をすべて集約したい
- 失敗したケースの再実行した結果もスレッド内に通知したい
# AI 活用
- AI を活用した失敗原因調査を全員が見える場所で行いたい
- 全員が同じ AI/プロンプトを利用することで、分析精度の標準化・改善を行いたい
# コスト
- 人間は判断のみとして、確認コストを最小限にしたい
- LLM のトークンの利用は最小限に抑えたい
MagicPod Assistant とは
E2E テストが失敗したら、AI が自動で原因を分析して Slack に報告する Bot です。MagicPod の実行結果は Slack 通知できますが、その投稿をスレッドにして Bot にメンションして起動します。
失敗通知の中で MagicPod Assistant を呼び出している
主な機能
すべての操作は MagicPod Assistant の投稿に表示されたボタン、モーダルで行います。
| 機能 | 説明 |
|---|---|
| 🔍 失敗原因の自動分析 | 環境要因・コード変更・UI 変更を段階的に分析 |
| 🔄 テストの自動再実行 | 環境要因の場合は自動で再実行して結果を通知 |
| 💬 AIチャット | 分析結果に対して追加質問が可能 |
| 📝 不具合記録 | Google Spreadsheets に E2E テストの実績として登録 |
特徴①：失敗要因を段階的に分析する
トークン使用量を抑えつつ高精度な分析を実現するため、3 段階の分析アプローチを採用しています：
失敗原因は段階的に分析している
自動テストの失敗を段階的に深掘りすることで、トークン使用量を最小限に抑えます。多くのケースは Code Analyzer までで解決するため、Visual Analyzer の実行はオプショナルです。
| 段階 | 説明 | 処理時間 | トークン使用 |
|---|---|---|---|
| 🔍 Quick Triage | 最小限の情報で失敗原因を素早く判定 | 5秒 | 最小（〜500） |
| 💻 Code Analyzer | 直近の変更履歴から原因を特定 | +15秒 | 中（〜6000） |
| 🖼️ Visual Analyzer | Code Analyzerの推測を画像で確証 | +20秒 | 大（画像含む） |
特徴②：Slack スレッドへの情報集約
Bot を呼び出したスレッドにすべてのやり取りが集約されるため、チーム全体で経緯を追跡可能：
📍 MagicPod の一括実行の失敗通知（起点）
└─ @Bot メンション
└─ 🔍 Quick Triage の結果
└─ 🔄 失敗したテストの再実行結果の通知
└─ 💻 Code Analyzer の結果
└─ 🖼️ Visual Analyzer の結果
失敗要因の段階分析の詳細
MagicPod Assistant のコア機能である失敗分析を段階ごとに説明します：
① Quick Triage - 要因のクイック判定
最初の分析では、AI が最小限の情報で失敗原因を判定します。自動テスト失敗の大半は環境要因による一時的な失敗であり、人間は「再実行すべきか」の判断のみ行います。
プロンプト設計の概要
最小限のトークンで高速に再実行の要否を判定：
役割：E2E テスト失敗の初期判定専門家
入力：
- テスト実行結果（成功/失敗数）
- 失敗テスト詳細（テスト名、エラーメッセージ）
- MagicPod 自己修復の検出有無（Couldn't healパターン）
判定：
- エラーパターンから原因を推定（環境要因/コード変更/不安定なテスト）
- 自己修復検出時は再実行確率を上昇
- 再実行済みの場合は確率を調整
出力：推奨アクション（rerun/investigate/report_bug）、再実行確率、信頼度
Quick Triage シーケンス図
② Code Analyzer - 変更履歴から原因特定
環境要因でない場合、AI が直近の変更履歴 (PR・コミット) を分析して原因を特定します。多くの場合、この段階で原因が特定できます。
また、Code Analyzer 自体にも段階を設けてトークンを節約しています：
トークンを節約しつつ漏れをなくす 2 段階設計
第 1 段階では対象期間のすべての PR のメタ情報を AI に渡し、暗黙的な関連も含めて分析を行います。第 2 段階ではユーザーが選択した PR のみ詳細な差分を取得し、精度とコスト効率を両立しています。
プロンプト設計の概要（2段階分析）
2 段階分析により、不要なコード差分の取得を回避し API コストを削減：
第1段階：PR メタ情報分析
役割：PR とテスト失敗の関連性評価専門家
入力：
- テスト失敗情報（エラーメッセージ、失敗ステップ）
- 全PRのメタ情報（タイトル、説明文、マージ時刻、ラベル）
処理：
- 全PRを俯瞰して暗黙的な関連も含めて評価
- エラーメッセージと PR 内容のキーワードマッチング
- UI変更関連キーワードの重点チェック
出力：関連性スコア付き PR ランキング
第2段階：PR 差分詳細分析
役割：コード変更の影響分析専門家
入力：
- 選択された PR の全差分（テストコードを優先的に表示）
- Quick Triage の分析結果（セッションから取得）
- エラー詳細情報
処理：
1. テストコード変更から仕様変更を把握
2. 実装コード変更の妥当性と副作用を確認
3. 仕様変更と不具合の両方を検出
出力：原因確定（仕様変更/不具合/両方）、修正提案
Code Analyzer シーケンス図
③ Visual Analyzer - 画像による補完分析
Visual Analyzer は、Code Analyzerの「答え合わせ」の役割を果たします。コードで「ID 属性が変更された可能性」を検出しても、実際の UI を見ないと確証が得られないケースがあります：
- Code Analyzer：「PR 39107 でメモ関連の変更あり」（推測）
↓
- Visual Analyzer：「実際に ID 属性が'memo'→'patient-memo-input'に変更」（確証）
この2つを組み合わせることで、誤判定を防ぎ、確実な原因特定が可能になります。
プロンプト設計の概要
画像認識とコード分析を統合し、最終的な確証を提供します：
役割：UI変更検出とテスト修正提案の専門家
入力：
- Quick Triage、Code Analyzer の分析結果（セッションから取得）
- 失敗時のスクリーンショット
- Code Analyzer からの疑われる原因と確認ポイント
処理：
1. UI表示状態の確認（タブ選択状態、モーダル表示等）
2. Code Analyzer の指摘との照合
3. 問題箇所と修正案の特定
出力：UI変更箇所、修正 XPath 提案、確証レベル
Visual Analyzer シーケンス図
システム構成
Slack × AWS Lambda × 各種APIを組み合わせたサーバーレス構成で実装しています：
Slack イベントをトリガーに Lambda 関数が起動し、イベントに対応した操作を各 API から取得/実行します。
その他に実装した機能
技術詳細は割愛しますが、アイデアとしてご紹介します。
1. 再実行した結果を元スレッドに通知
通常、MagicPod の UI から一括実行した場合、別ポストに投稿されてしまいますが、MagicPod Assistant はテスト再実行の結果も元スレッドに通知するので、情報が集約されます。
※ 一括実行設定のメンション設定も上書きして、呼び出したユーザーにのみメンションします。
2. AI チャット機能
自動分析で不明な点があれば、その場で AI に質問できます。文脈を維持したまま深掘りできるため、想定外のケースにも対応可能です。
3. 不具合登録
E2E テストが見つけた不具合を予め連携した Google Spreadsheets に登録可能です。E2E テストの実績として記録を残すことができます。
まとめ
開発速度が上がると E2E テストの実行回数も増え、確認コストがボトルネックになる懸念があります。MagicPod Assistant は、AI と人間の分業により、この課題に対する 1 つの解決策となることを目指しています。
まだ検証フェーズで継続しながら改善を重ねていますが、最終的には MagicPod を利用する全プロダクトへの活用を進めて全社的な作業効率化に繋げたいと、考えています。
今後の改善予定
- 成功時の画像との比較分析：Visual Analyzer の精度向上のため、成功したテスト実行時のスクリーンショットとの差分比較機能
- 分析精度の向上：より多くのケースでの検証とプロンプトチューニング
同じような課題を抱えている方の参考になれば幸いです。ありがとうございました！
メドレーでは生成 AI 利用のガイドラインが社内で展開されており、各部門の業務ではそのガイドラインに沿って利用をしています。
参考：MagicPod ミートアップでのライブデモ
MagicPod ミートアップで実際の E2E テスト失敗をターゲットにしたデモを行いました。MagicPod Assistant の動作イメージが気になる方は、以下の折りたたみから実際のやり取りをご覧ください！
👇 実際の動作イメージは下記参照
👉 ミートアップで実演した動作イメージはこちらをクリック
デモシナリオ：患者メモ機能のテスト失敗
失敗内容：「当日メモを入力」ステップでエラー
エラー：要素が見つからない (XPath: //input[@id='memo'])
原因：PR #39107「患者メモ機能の初期表示カスタマイズ」により、初期表示タブが変更された
🔍 Quick Triage
5 秒程度で環境要因ではなくコード変更の可能性を判定。AI は「UI変更の可能性（信頼度90%）」と分析し、テスト手順の修正が必要と提案しました。
💡実行者を context 表示しているのもポイントです
💻 Code Analyzer
第 1 段階
指定期間にマージされたの数十件の PR から関連性の高い 3 件に絞り込み、PR #39107 を主原因として判定しました。
失敗結果と指定した期間内にマージされた PR のメタ情報を突き合わせてピックアップ
第 2 段階
主原因としてピックされた PR #39107 に対してコードレベルの分析を行うと、初期表示タブの変更が直接的な原因と判断しました 👏
指定したPR の diff の中身を確認して真の原因を特定
🖼️ Visual Analyzer
CodeAnalyzer の時点で失敗原因の特定は完了していますが、実施してみました。Visual Analyzer は入力欄のID属性が "memo" から "patient-memo-input" に変更されたのではないかと分析しました。
MagicPod から取得したスクリーンショットから何が UI として表示されているのか判断
分析に利用した画像もスレッドに投稿する機能も実装すると、便利です。
🗣️ AI チャット
最後にライブデモをしていたことを AI にチャット機能で伝えると、MagicPod 社サイドから回答するユーモア (?) も持ち合わせていて、MagicPod の方々も大勢いたので焦りました 😅
チャットでも分析結果の文脈が維持されている
最後までご覧いただき、ありがとうございました！
Discussion