【MagicPod MCP Server活用】毎朝のCI失敗の調査をAIエージェントに任せる

公開日：2026/10/06

AIエージェントは、ここ1年だけを見ても驚くほどの速度で進化しています。Claude、Cursor、Codexといったツールは、数ヶ月前にはできなかったことを当たり前のようにこなすようになりました。

MagicPodは、この進化の速度に合わせ、常にお客さまが活用できる自動テストプラットフォームであり続けたいと考えています。

一方で、日々のテスト運用には、まだ人が時間をかけている作業が残っています。
毎朝届く夜間CIの失敗レポートを開いて、1件ずつ原因を切り分ける。そんな作業に心当たりのある方もいるのではないでしょうか。

今回は、お客さま自身が使っているAIエージェントからMagicPodを直接操作することを可能にする新しいMagicPod MCP Serverと、私たち自身がこの仕組みを使って日々のCIチェックをどう変えたか、具体的な事例を交えてご紹介します。

MagicPod MCP Serverを刷新しました

MagicPod MCP Server（MCPサーバー）は、AIエージェント（Claude、Cursorなど）から自然言語でMagicPodを操作できるようにする仕組みです。
旧MCPサーバーは、お使いのPC上で動かすローカル実行が前提でしたが、刷新後はMagicPodのインフラ上で稼働する形になり、あわせてAIエージェントから使える機能そのものも大きく増えました。

MagicPodのインフラ上で動くようになったことで、AIエージェントに必要な機能を、MagicPod本体と直接つないだ形で提供できるようになりました。

例えば、これまでもAIによるテスト編集機能として「MagicPod Autopilot」がありましたが、刷新後はお客さまが日頃使っているAIエージェントからも、テストケースの作成・編集を直接行えるようになりました。

MagicPodのクラウド環境での実行だけでなく、MagicPod Desktopを利用したローカルでのテスト実行もできるようになっています。

テスト編集まわりでは、他にもできることが増えています。

エージェントが実際の画面をキャプチャし、そこから安定して動くロケータを提案したり、既存のロケータがまだ有効かを検証したりできます。
テストが落ちたときの「アプリ側の不具合なのか、ロケータが古くなっただけなのか」という切り分けを、エージェントと一緒に進められます。
QRコードの読み取りのように、画像をテストデータとして使うテストであれば、その画像のアップロードもできます。
開始と終了のステップを指定した部分的な実行もできるので、直したい箇所だけを繰り返し試せます。

テストケースや共有ステップの整理も任せられます。
フォルダを作り、その中へテストケースや共有ステップ、フォルダ自体をまとめて移動できます。
すでにExcelなどでテストケースを管理している場合、「この資料の構成にあわせてフォルダとテストケースを作って」と頼めば、構造を保ったまま用意できます。これまでは、移行したあとに手作業で並べ替える必要がありました。

テストの実行結果を取得する部分も広がっており、本記事でご紹介するのは、まさにその部分を使った事例です。
詳しい機能一覧やセットアップ方法はヘルプセンターをご覧ください。

旧MCPサーバーと並行してご利用いただくこともできますが、今回ご紹介する内容には新MCPサーバーでのみ使えるものが含まれるため、新MCPサーバーへの移行をおすすめします。

MagicPodのCIについて

MagicPodでは夜間にCIを回しており、朝になるとSlackに結果レポートが届きます。
担当者はこのレポートを見て、失敗した項目を1件ずつ「これは何が原因で失敗したのか」と調べていきます。

同じテストで過去にも失敗していないか
直近のコミットで、原因になりそうな変更が入っていないか
実行環境に起因する問題ではないか
テストそのものの設定不備ではないか

こうした観点で調べたうえで、失敗を「デグレ疑い」「既知のFlaky」「テスト側の不具合」「インフラ要因」などに分類します。
そして、判断の根拠となる実行結果やログへの直接リンクを添えてレポートにまとめ、コミットの担当者に確認を依頼したり、テスト設定を修正したりしています。

MagicPodのCIでは、いわゆる結合テストの他に、MagicPod自体のe2eテストが行われています。
そのため、いろんなOSやブラウザでのパターンでのテストがあり、その量も多いです。
MagicPodの実行結果やCIのログを横断的に確認しながら手作業で調査するため、失敗件数が多い日は、この調査だけでかなりの時間を取られていました。

事例紹介: 毎朝のCIの失敗原因の調査

この調査を、新MCPサーバーを使って行うためのスキルを用意しました。
スキルとは、AIエージェントに作業のやり方を教える手順書のようなものです。
実態は、調査の手順をMarkdownで書き下したファイルです。
この事例は Claude Code 上で構成していますが、他のAIエージェントでも同じ考え方で組み立てられると思います。

今はスキルを起動するだけで、AIエージェントが同じ調査を自動でこなしてくれます。
この調査のやり方自体は、MCPサーバーを導入する前から変わっていません。変わったのは、それを実行するのが人からAIエージェントになったことです。

役割は2つに分かれています。

進行役
- Slackのレポートを解析し、失敗を1件ずつ調査役に渡して、返ってきた結果をまとめます。
  - Slack Plugin を使用しています。
調査役
- 渡された1件だけを調べます。MagicPod MCPサーバーを使うのはこちらだけです。
- 1件ごとに独立して動くので、調査の内容が互いに混ざりません。
- コードベースを調査するために Bash(git status *) や Bash(git log *) 、Bash(git diff *) などの読み取りツールを許可しています。

スキルを実行すると、下記のような流れで調査が行われます。

スキルの実行を指示する
進行役がSlackから当日のCIレポートを取得し、内容を解析する
進行役が失敗項目の中から、MagicPodの一括実行を1件取り出す
その1件を調査役に渡し、調査を行う
1. list_batch_run_test_runs で、失敗・中断した項目を洗い出し、調査対象を列挙する
2. get_test_run で、個々の失敗したテストの実行結果と失敗分析を取得する
3. get_test_case_detail で、テストの説明に書かれた # CI Notes を読む
4. list_test_runs で、直近の実行と比較して再発しているかを判定する
5. 原因がわからなければ、過去に確認済みの既知不具合の一覧と照合する
6. それでもわからなければ、Slackの関連チャンネルを検索する
7. デグレの可能性が残る場合は、コードベースの直近のコミットを調べる
8. ここまでに集めた根拠をもとに失敗を分類する
調査役からの結果を、進行役がまとめて提示する

list_batch_run_test_runs などは、MCPサーバーが提供するツールの名前です。本記事執筆時点のもので、今後変更される可能性があります。最新の一覧はヘルプセンターをご覧ください。

このうち、直近の実行と比較する部分では、条件ラベル・実行方法・ブランチが一致する実行だけを対象にしています。単に「過去も失敗している」ではなく、同じ条件で同じ失敗が起きているかを見ないと、再発かどうかは判断できないためです。直近5回分を確認し、必要ならさらに10回分まで遡ります。

ここで使っている get_test_run と list_test_runs は、新MCPサーバーで初めて使えるようになったツールです。

私たちは、AIエージェントがMagicPodを扱うときに何が必要になるかを起点に、新しいMCPサーバーを見直しました。「特定のテスト実行を直接指定して取得する」「あるテストケースの実行履歴を新しい順に並べて取得する」といった操作は、そうして新たに用意したものです。

「MagicPodのCIについて」で挙げた調査の観点のうち、「同じテストで過去にも失敗していないか」は、失敗を「デグレ疑い」と「既知のFlaky」に振り分けるうえで最も有用な材料です。この履歴の突き合わせをエージェントが直接行えるようになったことで、今回の自動化が組み立てられるようになりました。

調査が終わると、失敗の分類と、その判断の根拠がまとまったレポートが出てきます。それを見て、確認が必要な内容をざっと把握します。判断の根拠としたテストケースやコミットなどへのリンクが含まれているので、確認も簡単に行えます。

KNOWN_FLAKINESS — TC26 "Display only" の左ペインレンダリングによるvisual-diff不安定性

- Report item: Cloud browser x MagicPodDev (Chrome) (item-005)
- Affected executions:
  - TC26 — Display only · run 4170 · failed

────────────────────────────────────────
[Current failure]
  Observation: 複数のassertNoVisualDiffステップが許容値超過（例：「repeat edit page (2)」diff 4.92% vs 許容3%）
  Evidence:    run 4170
────────────────────────────────────────
[Classification]
  Observation: TC26の# CI Notesに2026-08-06以降の左ペインレンダリング不安定という既知flakinessが記載済み、visual-diff閾値は3.0%へ既に引き上げ済み
  Evidence:    TC26 # CI Notes
────────────────────────────────────────
[Recurrence]
  Observation: 直近2夜(08-26, 08-25)はunresolved（シグネチャ一致は未確認）、それ以前2夜(08-24, 08-23)は成功
  Evidence:    08-26 run, 08-25 run
────────────────────────────────────────
[Commit relationship]
  Observation: 検索していない（既存の# CI Notesで既知flakinessと説明済みのため）
  Evidence:    link unavailable
────────────────────────────────────────

- Confidence: medium（既知パターンと一致するが、既存の閾値(3%)を上回る規模での失敗であり悪化の有無は未確認）
- Remaining gaps: 直近2夜のunresolvedがこのシグネチャと同一機構かは深掘りしていない。今回の悪化（閾値超過）が既存記載範囲内かは要確認。
- Suggested manual action: バッチのGUIから該当パターンを再実行し、ケース担当者に閾値超過の規模拡大について確認する。

このスキルを運用するにあたって工夫している点はいくつかありますが、ここでは3つご紹介します。

1つ目は、読み取り専用にしていることです。 MagicPod MCPサーバーでは、読み取りだけでなく書き込みを行えるツールもあります。調査中にエージェントが誤ってそれらを実行しないよう、読み取りツールのみを利用するよう指示しています。

2つ目は、根拠が十分でないときに結論を出させないことです。調査結果を分類する際、無理に判断せず、担当者が確認する必要があると報告するようにしています。

3つ目は、テストごとのメモをエージェントに渡していることです。スキルやログ以外に、テストの説明へ # CI Notes というメモを残すようにしています。ここに「不安定なケース」などを書いておくことで、エージェントがテストの情報を取得したときに、そのテスト特有の事情を判断に利用できるようになります。

この仕組みの効果は、作業が速くなったことだけではありませんでした。もう一つは、調査の進め方が、チームで共有できる形になったことです。

この調査は、どこを見て、何と突き合わせて、どう分類するかという判断の積み重ねです。
そしてその多くは、何度も経験することで各人の頭の中に蓄積されていきました。
私自身、このCIチェックの担当歴は浅く、以前はこの調査に数時間かかってしまう日もありました。

チームメンバーがこのスキルを用意してくれたことで、これまで暗黙知だったものが明文化されました。
今では、多くの失敗がエージェントの調査で分類まで終わり、判断がつかなかったものだけが人に回ってきます。調査そのものは30分ほどで完了します。
人が引き取った分も、コンテキストを持つエージェントと一緒に調べられるため、確認はスムーズに進みます。
速さ以上に、「何をどう調べるべきか」を毎回思い出さなくてよくなったことも作業の負荷を減らしていると感じています。

課題と今後の計画

MagicPod MCPサーバーを用いることで、これまで手作業で行っていた調査を、エージェントに任せられるようになりました。

一方で、すべてをエージェントに任せているわけではありません。
エージェントが出すのはあくまで初期調査の結果であり、最終的な判断は人が行っています。

例えば画像差分チェックについては、エージェントは差分の検知までを行い、実際に見て判断するのは人が行っています。
見た目の良し悪しは人が確認するのがよいだろう、という判断がまずありました。
加えて、現状では期待値画像をエージェントが取得できないという制約もあります。

どこまでを任せるかは、いまのところこうした判断で決めています。
ただ、冒頭で触れたとおり、AIエージェントにできることはこの1年でも大きく変わりました。
いま人が行っている作業のうち、AIエージェントに任せられるようになるものも出てくるはずです。
その範囲を広げていけるように、私たちも準備を進めています。

例えば、失敗したテストの再実行です。
いまは再実行が必要かどうかを報告するところまでで、実行するのは人ですが、
これを扱えるようにする機能を開発しています。朝の一連の作業は、もう一段短くなるはずです。
画像差分についても、この問題を解消できる新しい機能を検討しています。

「AIエージェントの進化速度に合わせて、自らも進化し続けるプラットフォーム」。
それが私たちの目指しているところです。

まとめ

新しいMCPサーバーを使った、日次CIチェックの初期調査という毎日発生する作業を自動化する取り組みについて紹介しました。

調査のやり方そのものは変えていません。変わったのは、それを実行するのが人からAIエージェントになったことです。
それだけで調査にかかる時間は短くなり、これまで経験のある人の頭の中にあった手順が、チームで共有できる形になりました。
今後AIエージェントを活用していく上で、属人化していた調査ノウハウを明文化し、再現可能な形に整えていくことが重要になってくると考えています。

毎日繰り返している作業や、特定の人にしかできない調査は、皆さまのチームにもきっとあるはずです。
セットアップ方法はヘルプセンターにまとめていますので、ぜひお試しいただき、皆さまの業務にどう活かせそうか探していただけるとうれしいです。