MagicPod MCPとAIエージェントで実現するAIネイティブなE2Eテストワークフロー例
こんにちは。MagicPodでエバンジェリストをしている伊藤由貴です。
以前からMagicPodでは公式のMCPサーバーを提供し、Claudeなど外部のAIエージェントと連携してテストの作成や実⾏などを⾏えるように取り組んできました。
今回はそんなMagicPod MCPに新バージョンが登場。従来よりも使いやすく、かつ⾼パフォーマンスになっています。
本記事ではMagicPod MCPを使ったAIネイティブなE2Eテストのワークフローの⼀例を、サンプルを⽤いてご紹介します。皆様の開発現場での参考になれば幸いです。
目次
ワークフローの全体像
今回はMagicPod MCPを使い、Claude CodeとMagicPod等を連携させながら、仕様変更をもとにMagicPodのテストをアップデートして実⾏するまでの流れを作ってみます。
まず、仕様変更の内容がドキュメントに記載されます。ドキュメントの場所として今回はNotionを使います。Confluenceなど他のツールであっても、AIエージェントから⾒に⾏ける場所にあるか、MCPサーバーなどが提供されていれば同様のフローが実現可能です。
仕様変更の内容をもとに、開発者は⽣成AIを⽤いてコードを追加・変更し、それがステージング環境にデプロイされます。
並⾏して、仕様変更の内容に基づいた既存のリグレッションテストの変更をテストケースに反映します。
そしていよいよMagicPodの出番です。Claude Codeがリグレッションテストの変更点をもとに、MagicPod上の⾃動テストを修正し、実⾏します。
⾃動テストの修正と実⾏がうまくできれば、アプリケーションに仕様変更が適切に反映され、かつ⾃動テストも最新のアプリケーションと整合性が取れていることになります。
テスト対象
今回はテスト対象として、
HOTEL PLANISPHERE - テスト⾃動化練習サイト
を⽤います。
ただし、こちらのサイトに対して実際に変更を加えるわけにはいかないので、仕様変更を
反映したバージョンとして別サイト
HOTEL PLANISPHERE - テスト⾃動化練習サイト（仕様変更版）
を⽤意しました。
実際の流れ
ここからは、実際に概要図の流れに沿って使い⽅の例を⾒ていきましょう。
説明のためステップバイステップで⽰していますが、現場でワークフローを組んで⼤きな問題がなければ、より⼈間の関与を減らして⾃動で進む割合を増やしていくことも可能です。この点は記事後半でご説明します。
1. 仕様変更の記載
今回の仕様変更の内容をNotionに書いたものが以下です。
あくまでもワークフローの例なので、⾮常にシンプルな変更です。
ホテル予約サイトの予約可能期間を3ヶ⽉（90⽇）から2ヶ⽉（60⽇）に短縮しました。
2. 仕様変更をもとにテストの変更内容を把握し、テストケース⼀覧をアップデート
Notionにあらかじめテストケースの概要が記載されている、とします。
このページに対して、先の仕様変更内容をAIを⽤いて反映させます。
⾃動テスト⾃体はMagicPod上に実装されているので、このページではあくまでもテストの概要や⽬的のみが記載されており、細かい⼿順は省いています。
Claude Codeに以下のように指⽰しました。
Notionの「[DesignDoc] 宿泊予約システム：予約可能期間の仕様変更」ページに記載された仕様変更内容と 「E2Eテストケース⼀覧：宿泊予約システム」に記載の既存のテストケース定義をもとに、 仕様変更の影響を受けるテストケースを特定し、修正内容を 「[DesignDoc] 宿泊予約システム：予約可能期間の仕様変更」ページの「3. 影響分析 & ⾃動テスト修正計画」にまとめて。 そのうえで、変更内容を「E2Eテストケース⼀覧：宿泊予約システム」に反映して。
Claude Codeはテストケースの変更を読み取り、⾃動テストの修正箇所を特定します。
内容を確認しました。仕様変更は「予約可能⽇：本⽇+3ヶ⽉ → 本⽇+2ヶ⽉」で、 影響を受けるのは「本⽇+90⽇」という具体的な予約可能⽇数に依存しているTC-001とTC-002です（TC-003, TC-004はアカウント登録関連で無関係）。 影響分析をまとめて、DesignDocの「3. 影響分析 & ⾃動テスト修正計画」セクションを更新します。 （中略） 更新完了しました。DesignDocの「3. 影響分析 & ⾃動テスト修正計画」に以下を追記しました。 影響分析結果 - TC-001, TC-002: 影響あり（要修正）— 「本⽇+90⽇」の最⻑予約可能⽇を前提にしているため、「本⽇+2ヶ⽉」への仕様変更（3ヶ⽉→2ヶ⽉）に伴い記述・検証⽇付の修正が必要 - TC-003, TC-004: 影響なし — アカウント登録系のテストで予約可能期間に依存しない 追加した内容 - 影響テストケースと修正内容の⼀覧表 - 新規追加を推奨するテストケース3件（境界値の正常系・異常系、カレンダーUIのdisabled表⽰確認） - 対応状況（現在：未着⼿） （中略） 更新内容 - TC-001・TC-002：「本⽇+90⽇」→「本⽇+2ヶ⽉」に修正 - TC-005（境界値正常系）、TC-006（境界値異常系）、TC-007（カレンダーUI）を新規追加（MagicPod上のNo.60/61/62に対応） - 最終更新⽇を2026-09-01に更新
Notionの仕様変更ページ、影響分析＆⾃動テスト修正計画の項⽬に結果が書き込まれました。
特に指定はしていませんが、「追加が推奨されるテストケース（新規）」も記載されていますね。
テストケース定義の書かれたページも同様で、仕様変更が反映されています。
今回はごく単純な例のため特に問題やミスなどは⾒られませんでしたが、
現場における実際のテストに反映する場合には、ドキュメントの読み取り箇所を具体化するなど、プロンプトやファイルに対する⼯夫が必要になります。
また、仕様変更の反映が適切に⾏われているかどうかの⼈間によるレビューも、特にワークフローを構築してすぐの段階では⼤切です。精度を確かめたうえで、問題がなければ徐々に⼈間の関与を減らしていきたいところですね。
3. ⾃動テストの修正と実⾏
テストケースの変更がドキュメント側で反映されたら、その内容をもとに⾃動テストの修正と実⾏に移ります。
Claude Codeに対して、MagicPod MCPを⽤いて⾃動テストを修正するように指⽰します。
実際にMagicPodのテストに対して、これらの変更を反映したい。 対象は以下。 https://app.magicpod.com/ProjectName/newMCP_Blog/?branch=main ⼀括実⾏設定は 5:newMCP_After
MagicPod上でテストの修正が始まります。
バッチラン#1は完了し、TC-001（No.52）・TC-002（No.53）とも succeeded です。TC-003（No.54）・TC-004（No.55）も成功しており、4件全て成功です。 実施結果まとめ ┌──────────┬──────────────┬────────────────────────────────────────────────────────────────────────────────┬────────────────┐ │ テストID │ MagicPod No. │ 修正内容│ ⼀括実⾏#1結果 │ ├──────────┼──────────────┼────────────────────────────────────────────────────────────────────────────────┼────────────────┤ │ TC-001. │ 52 │ Date calculation の duration_array を90⽇→60⽇に変更（本⽇+2ヶ⽉以内の安全側） │ ✅ succeeded │ ├──────────┼──────────────┼────────────────────────────────────────────────────────────────────────────────┼────────────────┤ │ TC-002. │ 53 │ 同上⼀括実⾏設定に含まれている全ケースが実⾏され、すべてPassしていることが確認できました。│ ✅ succeeded │ ├──────────┼──────────────┼────────────────────────────────────────────────────────────────────────────────┼────────────────┤ │ TC-003. │ 54 │ 変更なし│ ✅ succeeded │ ├──────────┼──────────────┼────────────────────────────────────────────────────────────────────────────────┼────────────────┤ │ TC-004. │ 55 │ 変更なし│ ✅ succeeded │ └──────────┴──────────────┴────────────────────────────────────────────────────────────────────────────────┴────────────────┘ ⼀括実⾏設定「5:newMCP_After」（バッチラン#1、branch=main）で全4件が成功したことを確認済みです。 続けて、DesignDocの「3. 影響分析 & ⾃動テスト修正計画」に対応完了の記録を追記します。 （中略） 完了しました。 実施内容 - MagicPod（newMCP_Blog、branch=main）で TC-001（No.52「ログインせずに予約」）、TC-002（No.53「ログインして予約」）のDate calculationステップを 90⽇後 → 60⽇後（本⽇+2ヶ⽉以内に確実に収まる安全側の⽇数）に修正 - ⼀括実⾏設定「5: newMCP_After」でバッチラン#1を実⾏し、TC-001〜TC-004の4件全てが succeeded を確認 - DesignDocの「3. 影響分析 & ⾃動テスト修正計画」に対応状況（完了）と実施結果を追記済み 未対応・積み残し - DesignDoc内で提案した新規テストケース3件（境界値正常系・異常系、カレンダーUIのdisabled確認）はまだ未作成です。必要であれば続けて着⼿します。
⼀括実⾏設定に含まれている全ケースが実⾏され、すべてPassしていることが確認できました。
念のためテストケースの変更履歴を確認してみましたが、MCPサーバー経由で適切に変更できています。
ここまでで、仕様変更をもとにした⾃動テストの修正と実⾏の流れが実現できました。
ちなみに、新規テストケースの内容の作成も依頼したところ、問題なく追加してくれました。
新規3テストケースの作成が完了しました。 作成したテストケース ┌─────┬───────────────────────────────────────────┬────────────────────────────────────────────────────────────────────────────────────────────────────┐ │ No. │ 名前 │内容 │ ├─────┼───────────────────────────────────────────┼────────────────────────────────────────────────────────────────────────────────────────────────────┤ │ 60 │ 境界値：本⽇+2ヶ⽉ちょうどで予約成功 │ 60⽇後の⽇付で予約が正常完了することを確認 │ ├─────┼───────────────────────────────────────────┼────────────────────────────────────────────────────────────────────────────────────────────────────┤ │ 61. │ 境界値：本⽇+2ヶ⽉+1⽇はエラーで予約不可 │ 61⽇後の⽇付で「2ヶ⽉以内の⽇付を⼊⼒してください。」のエラー表⽰・予約が進まないことを確認 │ ├─────┼───────────────────────────────────────────┼────────────────────────────────────────────────────────────────────────────────────────────────────┤ │ 62. │ カレンダーUI：2ヶ⽉超の⽇付がdisabled表⽰ │ カレンダーの「次の⽉」送りボタンが上限⽉（10⽉）でdisabled状態になり、11⽉以降に進めないことを確認 │ └─────┴───────────────────────────────────────────┴────────────────────────────────────────────────────────────────────────────────────────────────────┘
実運⽤をする場合の⼯夫
今回のものは⾮常にシンプルな例でしたので、実際に現場でこのようなワークフローを構築するうえでは、いくつか追加の⼯夫が必要になります。
例えば、途中でも触れたテストケース⼀覧について。現場レベルではより多くのE2Eテストケースがあるため、Claude Codeを⽤いて「仕様変更の影響を受けるテスト」を探す難易度が上がります。
テストケースの詳細を全てドキュメント化しておけばAIも読み取れますが、都度AIに読ませるのは効率が悪いです。
例えばタグやラベルを使って、各テストが操作する機能や画⾯などの単位で情報を付与しておくのも⼀つの⼿です。
また、MagicPod MCPを⽤いればMagicPod上のテストのステップを確認することもできるので、ある程度ドキュメント上で対象テストを絞り込んだうえで、あとは実際のテストステップを⾒ながら該当テストを探すという2段階の探し⽅もできそうです。
SKILL化でさらに効率UP
今回ブログでの紹介のためにステップバイステップで進めましたが、実際に現場業務としてワークフローをすすめる際には、もう少し⽣成AIが⾃動で進めてくれたほうが効率的です。
この場合、Notion上の仕様変更確認から、MagicPodへの反映・実⾏確認までの流れをSKILL.md としてまとめましょう。
ClaudeCodeにはSkill Creator機能があるため、「スキル化したい」と伝えればOK。
本記事でご紹介した内容をSKILL化した場合のサンプルは以下です。（⻑いので抜粋です。）
--- name: spec-change-impact-sync description: 仕様変更のDesignDoc（Notion）を起点に、既存E2Eテストへの影響分析、MagicPodでのテスト修正・新規テスト作成、⼀括実⾏での検証、Notionへの結果反映までを⼀気通貫で⾃動実⾏する。「仕様変更をテストに反映して」「この仕様変更の影響分析して」 「DesignDocを⾒てMagicPodのテストを直して」など、Notion上の仕様変更ドキュメントを起点にE2Eテスト（MagicPod）を追随させたいときに使う。単発のNotion編集やMagicPod単体の操作には使わない（この⼀連の流れ全体が必要なときに使う）。 --- # 仕様変更 影響分析＆テスト同期スキル Notion上の仕様変更ドキュメント（DesignDoc）を起点に、「既存のE2Eテストが壊れないか」「新しい境界を確認するテストが要るか」を判断し、MagicPod上のテスト修正・新規作成・実⾏検証、そしてNotionへの結果反映までを⼀つの流れとして進める。 ## いつ使うか - Notionに仕様変更のDesignDoc（変更前/変更後、期待される挙動が書かれたページ）があり、それがE2Eテストに与える影響を確認・反映したいとき - 「このDesignDocの内容をMagicPodのテストに反映して」のように、Notion→MagicPod→Notionの⼀連の流れをまとめて頼まれたとき このスキルは「読む・考える・直す・確かめる・書き戻す」の5フェーズを想定しているため、Notionの1ページを読むだけ、あるいはMagicPodのテストを1件直すだけの依頼には使わない （過剰）。 ## 全体の流れ（5フェーズ） \``` 1. DesignDoc確認 Notionの仕様変更ドキュメントを読み、変更前/後・期待挙動を把握する 2. 影響分析 既存のE2Eテストケース⼀覧を読み、どのテストが影響を受けるか判定する 3. テスト対応 影響を受けるテストを修正し、必要があれば新規テストを作る 4. 検証 個別実⾏→⼀括実⾏（バッチラン）で全体が壊れていないことを確認する 5. Notion反映 DesignDocの「対応状況」とテストケース⼀覧の両⽅に結果を書き戻す \``` （以下略）
加えて、ドキュメントの具体的な場所や仕様変更の反映先なども併せて記載しておくと、
AIとのやりとりを減らせます。
まとめ
今回は、Claude CodeをハブにしてMagicPod MCPを他のツールと連動させ、E2Eテストへの仕様変更の反映と⾃動テストの修正を⾏う簡単なワークフローについてご紹介しました。
特に開発サイクルが早く回っているチームにおいては、仕様変更をテストのドキュメントや⾃動テスト⾃体に反映するのがなかなか⼤変だと思います。
本記事を、AIの⼒を借りてスピーディに進める際の参考にしてみてください。
