テスト自動化を“1チームの成功”から“全社標準”へ。NTTドコモが100プロダクト規模で進めるMagicPodの展開戦略とは
株式会社NTTドコモ
株式会社NTTドコモ様に、MagicPod選定の決め手や導入時から現在までの活用状況について、MagicPod代表の伊藤がお話を伺いました。
株式会社NTTドコモ
ドコモグループは通信事業、スマートライフ事業、法人事業の3本柱で事業を運営しています。コンシューマ向けの通信以外のサービスはスマートライフ事業が受け持っており、100以上のプロダクトの開発と保守運用をプロダクトデザイン部が担っています。プロダクト例：dポイント、dカード、d払い、Lemino、dアニメストア、dヘルスケア、ドコモでんき、ドコモガス、ひかりTVなど。
POINT
- 手動のE2Eテストが開発スピードのボトルネック。リリースの後ろ倒しも発生
- コスト他社比4分の1、ローカル実機対応、CI/CD連携の3点でMagicPodを選定
- テスト実行工数23人日→3人日。3回リリースで導入コストの元が取れる計算に
- コスト削減目的で始めた自動テストが、品質向上という想定外の効果も生んだ
- AIエージェント「Autopilot」を活用し、テストケース作成時間を66%削減
左から
・出井 明莉さん コンシューマサービスカンパニー 第一プロダクトデザイン部 サービス基盤 サービス基盤担当
・三井 力さん コンシューマサービスカンパニー シニアプリンシパルアーキテクト
・上田 史貴さん コンシューマサービスカンパニー 第一プロダクトデザイン部 映像サービス 第二技術開発担当
・伊藤 望 MagicPod CEO
三井さん（以下、三井）：私は第1・第2プロダクトデザイン部のシニアプリンシパルアーキテクトを担当しています。もともとはプロダクトデザイン部長でしたが、今は両部にまたがる技術的なコンサルティングや方向付けを担っています。
ドコモの事業は通信事業、スマートライフ事業、法人事業の3本柱で構成されていて、我々の第1・第2プロダクトデザイン部はスマートライフ事業のプロダクトの開発と運用を担当しています。
扱っている100以上のプロダクトの6割がアジャイル開発で、E2Eのリグレッション試験がボトルネックになりやすいという課題がありました。
そこでテスト自動化の取り組みとして出井のベースアプリチームで去年の5月頃にMagicPodを導入したところ効果が得られ、大規模なLeminoのQAチームでも良い成果が出ました。それを社内の技術共有会でも共有しまして、この2チーム以外からも「うちもMagicPodを導入したい」と問い合わせが増えている状況です。
出井さん（以下、出井）：私は第一プロダクトデザイン部でサービス基盤を担当しています。私たちの部門は直接お客さまにサービスを提供するというより、社内向けに各サービスやアプリが共通で利用できるプラットフォームを開発しています。
その中で、私のチームではサービスサイトを短期間・低コストでアプリ化できる「ベースアプリ」の開発をしています。ドコモならではの認証やプッシュ通知といった共通機能を備えつつ簡単なカスタマイズでアプリが作れるのが特徴で、現在は7つのサービスに導入されています。
私はプロダクトオーナーを務めていまして、もともとNTTドコモソリューションズ（旧：NTTコムウェア）に入社し、エンジニアとしてドコモ向けの開発を行っていました。2022年頃にドコモに転籍し、現職に就いています。自動テストはMagicPodが初めてで、それまでは手動でE2Eテストやリグレッション試験を行っていました。
上田さん（以下、上田）：私は2024年に新卒で入社し、1年目から映像再生ライブラリ開発チームでプロダクトオーナーを務めています。Leminoに関わり始めたのは2025年1月からで、Leminoでも試験自動化を進めていこうというタイミングで声をかけていただき、参画を希望しました。
プロダクトオーナーとして試験設計には関わっていたものの、試験自動化は開発チームにお任せしていたので自分自身に知見があったわけではありません。本当にゼロからのスタートでしたが、現在は試験自動化チームのリーダーとして推進しています。
伊藤：開発体制についてもお聞きしたいのですが、これだけのプロダクト数があると内製化もかなり進められているのでしょうか？
三井：社員が数百人しかいないのにプロダクトが100以上ありますので、全員がプロダクトオーナーをしていたら開発を社員で全て埋めることは到底できません。そこで、基本的にはパートナーと準委任契約を結び、一体となって開発する体制をとっています。例えばLeminoチームにはコードを書く社員もいますので、私はよく「準内製」という言葉を使っています。
MagicPod導入前の課題
出井：私たちのチームでは開発から運用保守まで1つのチームで担っているため、試験にリソースを割くのが難しい状況でした。課題は大きく2つあり、1つは後工程での試験実施による手戻りです。
本来はPBI（プロダクトバックログアイテム）ごとにリグレッション試験や端末バリエーション試験を行うべきところが、実際には複数スプリントをまとめて後工程で試験する運用になっていました。そのため過去に開発した部分の不具合や端末・OS依存の不具合が一気に見つかり、大きな手戻りが発生することもありました。
2つ目は手動試験による開発スピードの停滞です。ベースアプリはドコモの多くのサービスに利用されているため開発スピードが求められるのですが、手動試験の工数がボトルネックになっていました。
伊藤：まとめてテストすること自体にはメリットもあったのではないですか？
出井：仰るとおりで、最後に一括でテストすることで工数削減につながります。ただ、例えば2ヵ月かけて開発した後のテストで最初に実装した部分のバグが出てしまうと、大きな手戻りにつながり結果工数が膨らんでしまうということもあります。チーム内では、最後にまとめてテストを行うことに対する不安の声が挙がっており、安心感の醸成という観点で課題がありました。
上田：Leminoの場合は開発チームが複数あり、さらにQAチームが別に存在するという体制で開発スピードの向上やコスト削減が大きなテーマになります。アジャイル化を進めていく中では特にテスト工程がボトルネックで、リリース前のE2Eテストをすべて手動で行っていたため、工数とコストが膨大になっていました。具体的には、テスト後半で不具合が見つかるとリリースまでに修正が間に合わないという事態になり、リリース自体が後ろ倒しになることもありました。
三井：Leminoは複数スプリントの開発をまとめてからE2Eのリグレッションを実施しリリースするという流れで、そのサイクルをMagicPodが短くしてくれています。出井のベースアプリチームはさらに進んで、PBI単位でリグレッション試験を開発の中に組み込んでどんどん回していく、より理想に近い形になっています。バグに気づいた時点ですぐ直せますし、ビジネスのアジリティも上がります。
d払いのように大きなサービスであれば有スキル者を投入してAppiumでテストを自動化する選択肢も出てきますが、全チームにそのメンテナンスコストを求めるのは現実的ではありません。そこで出井や上田たちの取り組みを成功事例として、MagicPodの導入を推進しているのです。
MagicPod選定の理由・経緯
三井：テスト自動化にあたり、スマホアプリの自動化に取り組んでいたチームにとってMagicPodのようなツールが出てくる前はAppium一択でした。そこにノーコード系のツールが出てきて、もっと楽にできるんじゃないかという流れが生まれました。
ドコモとしては、まずセキュリティレギュレーションを満たせるかが重要です。ローカル実行ができることやパスワードの取り扱いなどの条件をクリアしたツールをいくつか試しましたが、MagicPodはブラウザとスマホの両方で使いやすく、圧倒的に優位でした。
出井：私たちのチームもAppiumを含むいくつかのツールを検討しましたが、どれもコストまたはリソース面で選択肢から外れ、実際にトライアルを行ったのはMagicPodだけです。去年の5月頃からトライアルを始めて7月には実運用に入りました。
コスト以外にもプロダクトオーナーの目線からもUIがわかりやすかったこと、GitHubをリポジトリとして使っていたのでGitHub Actionsと連携してCI/CDに組み込めたことが選定のポイントとして大きかったです。「開発が終わったらすぐに自動テストが走って結果を確認できる」という流れを作れたのは非常に良かったです。
伊藤：ノーコードであることはどの程度重視されましたか？
出井：基本的に開発チームのメンバーにも触ってもらっているのでノーコードであること自体はそこまで重視していませんでした。ただ、プロダクトオーナーとしてGUI上からテストの状況を確認できるのは助かっています。そういう意味ではノーコードの良さを感じています。
また、ベースアプリはWebViewを多用する構造なのですが、MagicPodがWebViewにも対応しており問題なくテストできている点も助かっています。
上田：LeminoではMagicPodを含む3つのツールで比較しました。まずLeminoでどれくらいの料金になるかざっくり計算したところ、MagicPodが他社の約4分の1で大きな差になりました。
機能面では、よりお客さまの環境に近い条件でテストするためローカル実行への対応が重要でした。スマホアプリとブラウザ、テレビ系のプラットフォームが対象になるのですが、テレビを除けばローカルでもクラウドでも、モバイルアプリでもWebブラウザでも、すべての組み合わせに対応していたのがMagicPodだけだったと記憶しています。
LeminoアプリはFlutterで開発しているのですが、トライアルで2つの課題がわかりました。1つはFlutterの仕様上、複数のウィジェットが1つのUI要素として認識されてしまい、特定のボタンをタップするといった操作がうまくいかないこと。もう1つは、AndroidとiOSでロケータが異なるため別々にテストケースを作らなければならないことです。
ただ、MagicPodのヘルプページに解決策が紹介されていて、FlutterのSemanticsウィジェットを使って各UI要素にユニークIDを付与し、Android/iOSで共通のロケータを利用できるようにすれば1つのテストケースで済むとわかりました。
伊藤：開発チームは協力的でしたか？ QAチームからの依頼に難色を示されてしまうという話をよく聞きます。
上田：ID付与は機能とは直接関係のない開発なので、最初はあまり積極的ではなかったと思います。そこで、開発チーム向けに課題と期待できる効果を共有し、テストケースのメンテナンスコストが半分程度に下げられるという話をしました。そうした説明をしたことで納得してもらえて、その後は開発チームからID付与案をもらい、それをレビューするという流れで実装を進めていきました。
今では新規画面や機能が追加される際に、アジャイルのリファインメントの場で開発チーム側がID付与の必要性を議論して、自律的に対応してくれる運用になっています。
伊藤：それは素晴らしいですね。MagicPod導入の稟議はスムーズに通りましたか？
出井：トライアルの結果をもとに導入効果を説明しました。自動化はプロダクトデザイン部全体としても推進することになっていた領域でしたので、特に否定されることなく導入に至りました。
三井：私も社内の技術共有会で定期的に「自動試験ができない限り、いくら他を効率化してもE2E試験がボトルネックになる」と伝え続けていました。
そうやって推進してきた中で、導入コストの安さはもちろんですが、実際に使ってみて良かったと感じたのは品質への好影響です。もともとデリバリーの短縮とコスト効率化を目的に始めたのですが、結果として品質も上がりました。
大きなアプリになるとリグレッション試験の範囲を専門の担当者が1〜2日かけて検討し、ここまでやれば大丈夫と影響範囲を絞るわけですが、たまに見誤りが起きる。自動テストなら範囲を絞らずに全部回してしまえばいいし、テストの実行回数自体が増えるので、手動では見つからなかったはずの不具合が見つかることがあります。実際、Leminoでもそういうケースがありました。
去年参加した「内製開発Summit」でも、私たちの見た登壇企業の半数以上がMagicPodのアイコンをスライドに載せていて、この方向で推進していいんだなと確信しました。内製志向の人たちは自分事としてツールを選んでいるので、その選択に信頼が置けるんです。
MagicPodの活用状況
出井：手動で多くの時間を要していたリグレッション試験やバリエーション試験を自動化できたことで、試験工数を50%ほど削減することができました。いわゆるシフトレフトが実現でき、自動化で浮いた稼働を開発に回せるようになったのは大きいです。
上田：2026年1月時点で、アプリとWebブラウザのリグレッションテストのうち自動化可能な項目はほぼすべて自動化しています。MagicPodがあることで試験を手動の約10倍の速度で実施できるので不具合をできるだけ早く発見してリリース前に修正するというサイクルが確実に速まっていますし、手動では見落としていたような不具合の検出にも成功しています。
直近のスマホアプリリリースでは約1,800ケースを実行し、テスト実行工数は23人日から3人日まで削減できました。
三井：出井のところは1チームで完結しているため、試験の効率化分を開発に回せます。LeminoのようにQAチームが分かれていてテスターがパートナーの場合は、パートナーの工数削減、つまりコスト削減に直接効いてくるという違いがあります。いずれにしても、試算では3回リリースすれば導入コストの元が取れるという数値が出ていますので、リリース頻度の高いスクラム開発との相性は非常に良いです。
上田：運用としては、リリース前にリグレッションテストを実行し、結果はSlackに通知してQAチーム全員で確認できるようにしています。主に見るのは失敗したケースで、失敗原因を分析してアプリ側の不具合であれば開発チームにエスカレーションし、修正するかどうかを判断してもらうという流れです。リグレッション試験全体で新規の不具合が1件見つかるかどうかという頻度なので、開発チームへのエスカレーションはそこまで多くはありません。
Leminoの場合、現時点ではGitHub Actionsとの連携はしておらず、コマンドラインから実行しています。ブラウザからだと1件ずつしか実行できないのですが、コマンドラインなら並列で動かせるのでそちらを使っています。将来的にはCI連携をやっていきたいです。
伊藤：実機でのテストというと、NTTグループの「Remote TestKit」との連携は検討されていますか？
三井：以前から話には出ています。MagicPodとの連携は今後必ず必要になると考えていて、端末を大量に買い込んで試験しているチームもありますので、そういったチームにも広げていきたいですね。
伊藤：MagicPodからRemote TestKitへの接続は、実行先を切り替えるだけで使えるようになっています。実機を毎回接続する手間がなくなりますし、テストの実行回数を増やすソリューションとしても有効です。興味があればぜひCSチームにご相談ください。
テスト自動化エージェント「MagicPod Autopilot」の活用
上田：最近はテストケースを作成する際にMagicPodのAutopilot機能を活用しています。具体的には、Leminoの試験項目からテストケースの情報とAutopilotに渡すプロンプトを作成し、それをAutopilotに投入してテストケースを生成するという流れです。最終的に担当者はAIが自動作成したテストケースをレビューして修正するだけという運用を目指しています。
最初はプロンプトのテンプレートを試験項目の種類別に20種類ほど用意していたのですが、テンプレートを作ること自体に時間がかかるので、次のステップとしてプロンプトの作成まで自動化することを目指しています。
伊藤：Autopilotの効果として一番期待しているのはどのあたりですか？
上田：一番はテストケースの作成時間の削減です。加えて、MCPサーバーと連携すればAutopilotを並列で実行できるのではないかと考えていて、そうなればさらにスピードが上がります。品質面でも人が作る場合はどうしてもテストケースの品質にばらつきが出ますが、Autopilotを使うことで一定のレベルに揃えられるのではないかと期待しています。
三井：Autopilotの効果を数値で見ると、最初はテストケース作成時間の21%削減でした。Autopilotの癖を理解してプロンプトのテンプレートを整備していくと31%まで伸び、さらにClineとMagicPod MCPサーバーを使って既存テストの内容やテスト観点を踏まえたプロンプトを自動生成するようにしたところ、66%削減まで到達しています。
上田：生成されたテストケースの精度も正直ばらつきがあって、1〜2ステップの修正で済むものもあれば全体的に改修しないと動かないケースもあります。ただ、ゼロから作るよりはレビュー・修正のほうが圧倒的に速いので、効率化の効果は十分に感じられています。
三井：テストが失敗した時の原因調査についても、ClineとMagicPod MCPサーバーを組み合わせて原因調査と修正案の提示を試みています。まだ正答率は50%程度なのですが、こういった分析の自動化は今後必ず必要になってくると考えています。
伊藤：MagicPod側でも原因分析機能の開発を進めていまして、分析結果をもとに関連するテストに変更を入れるといった使い方もできるようになっていく予定です。既存テストの変更もMCPサーバー経由で行えるようになっています。
三井：AIによる原因分析の話で1つ思い出したのですが、先日システム監視ツールのイベントに登壇した際に、DatadogやNew RelicのMCPと組み合わせたら面白いんじゃないかという話になりました。MagicPodでテストが失敗した情報と、DatadogやNew Relicのパフォーマンス情報を突き合わせれば、アプリの観点だけでなくシステム全体を含めた原因分析ができるのではないかと。
伊藤：テスト実行時のパフォーマンス情報はMagicPod側では取れないので、New Relicなどと連携してテスト結果にパフォーマンスの情報を組み合わせるというのは面白いですね。クライアントからバックエンドまで、一気通貫で見える世界になると思います。
上田：伊藤さんに1つ伺いたいのですが、最近はPlaywright MCPのように、コードが書けなくてもAIに指示するだけでテストが作れるツールも出てきています。その中でMagicPodの優位性はどこにあるのでしょうか。
伊藤：Playwright MCPで生成されるのはコードなので、内容が妥当かどうかはコードを読める人でないと判断できませんし、修正もプロンプト経由になるのでブラックボックスになりがちです。加えてGitの操作やエージェント環境の構築など前提知識も必要で、QAチーム全体への展開にはハードルが高い。幅広い人に直感的に使えるという点で、ノーコードツールには引き続き価値があると考えています。
三井：実は商用環境の外形監視にAppiumとPlaywrightを使っている専門チームがあるのですが、そこは1チームで完結していてコード書ける人がいるからコードベースでも回せるんです。ただ、すべてのプロダクトチームの、コードを書かない人も含めた全員にそれを求めるのはなかなか難しい。だからこそ、私はMagicPodの活用を推奨しています。
最後に
出井：自動テストの導入はハードルが高いと感じるかもしれませんし、特に大きなサービスほど導入コストも上がります。ただ、自動テストは今後ますます注目される領域ですので、まずは小さくスモールスタートで始めて、そこから広げていくというスタンスをおすすめしたいです。私たちのチームもまさにそのやり方で成果を出すことができました。
上田：私が感じるMagicPodの一番の強みはサポート体制です。ツール選定ではコストや機能面に目が行きがちですが、長期的に使い続けることを考えるとサポートの充実度は非常に大きいです。活発なSlackコミュニティもあり、MagicPodと利用者が1つのチームのような雰囲気があります。開発側の動きも可視化されているのでこちらのモチベーションにもなります。トライアルされる際にはぜひサポートにも問い合わせてみて、MagicPodの雰囲気に触れてみてほしいです。
三井：QCD、つまり品質・コスト・デリバリーのすべてに効くというのが実感です。普通はどれかを犠牲にするトレードオフになりがちですが、自動テストはトレードオンなんですよね。
自動テストに取り組んでいる人と話すと、みんな口を揃えて「一度やったらもう手放せない」「なぜ他のチームがやらないのか不思議だ」と言います。結局、やった人とやっていない人の間には経験と情報の格差があるんですよね。メンテナンスの大変さはありますが、それを差し引いても得られるものは大きい。MagicPodを活用することでリグレッション試験が楽になり、どんどん価値を提供できるチームへ成長していけたらと思っています。
＜参考＞
MagicPod User Meetup 2026 三井様登壇資料
【NTTドコモ様】ドコモで実践するMagicPod活用による 開発の効率化と付随して得られたもの
MagicPod BLOG Award 特別賞受賞 上田様BLOG
MagicPod × FlutterでAndroid/iOS自動テストを一本化して自動化コストを約50%削減した話
株式会社NTTドコモ
- コーポレートサイト：https://www.docomo.ne.jp/corporate/
- ドコモ開発者ブログ：https://nttdocomo-developers.jp/
