この記事は CyberAgent Developers Advent Calendar 2025 24日目の記事です。
はじめに
はじめまして。
柳萬 真伸（@nobu_nobu_dog）と申します。
株式会社MG-DXにて、医療・薬局業界のDXを支援するサービス「薬急便（やっきゅうびん）」の開発に携わり、主にフロントエンド領域を担当しています。
薬急便では複数の薬局チェーンに対応するため、UI や機能をチェーンごとにカスタマイズしており、サービス全体の仕様は多岐にわたります。
その結果、サービスの成長と拡大に伴ってテストケースが膨れ上がり、テスト作業の負荷が増大していることが課題となっていました。
本記事では、MG-DX におけるノーコードE2Eテストツール mabl を導入した背景と成果について紹介します。
mabl を導入した結果、
– テスター人数：7 名 → 4 名
– テストカバレッジ：約 50% → 約 78%
といった成果を、実現することができました。
この記事で書くこと
本記事では、テスト項目が膨れ上がり、テスト工数が逼迫していた状況から、ノーコードE2Eテストツール「mabl」を導入し、テスト運用を改善した事例を紹介します。
– なぜE2Eテスト自動化を検討したのか
– どのように導入したか
– 導入後の結果
を中心にまとめています。
この記事はこんな人向けです
– テスト体制に課題を感じている方
– Playwright などの E2E テストを導入したものの、運用・保守が回らなくなっている方
– QA 専任、または開発兼任でテスト自動化を検討している方
導入前の背景
開発体制と、その利点・課題
私たちのチームは、3 週間スプリントのスクラム開発を採用しています。
– 開発期間：2 週間
– QA 期間：1 週間
スクラム開発によって機能改善のスピードは向上していたものの、プロダクトの成長に伴い、徐々に新たな課題が顕在化してきました。
開発完了後、テスト対象がQA期間に一気に集中する構造となっており、その結果、QA工程がボトルネックとなってフィードバックが遅延するケースが増加していました。
当時のテスト体制
体制は以下のような構成でした。
– 社内 QA 担当(PM 兼務)： 1 名
– 外部テスター：3 名
– グループ内テスター：4 名
テスト管理はスプレッドシートで行っており、
– 全体のテスト項目数：約 4,600 件
– リグレッション対象：約 2,300 件
という規模になっていました。
不足が見込まれる場合は、エンジニアやデザイナーにも協力を依頼し、多くの人手によって何とか品質を維持している状態でした。
抱えていた主な課題
テストカバレッジの低下
時間制約の中でテストを終わらせる必要があり、変更の少ない箇所は確認を省略せざるを得ない場面がありました。
テスト品質のばらつき
スプレッドシートの手順書は抽象的になりやすく、実施者の経験やドメイン知識に依存する部分が大きくなっていました。
テスト工数の増加
プロダクトの成長に比例してテスト対象も増え、リリース直前までテストが終わらないケースも発生していました。
なぜ E2E テスト自動化を検討したのか
こうした課題に対する解決策として、私たちは E2Eテストの自動化 に着目しました。
E2Eテストを自動化することで、テストを短時間で繰り返し実行できるようになり、リリース前にテストが集中する状況を緩和できます。また、テスト手順の属人化を防ぎ、常に一定水準の品質を担保できる点も大きなメリットです。
実際、プロダクト内にはすでに Playwrightを用いたE2Eテスト が一部存在していました。しかし、
-
継続的に整備されておらず、テストケースが最新の仕様に追従できていなかった
-
保守・運用が一部のメンバーに依存しており、属人化していた
といった課題から、安定した運用には至っていませんでした。
そこで今回は、開発者だけでなく QA担当者も主体的にテストの作成・保守を行えること を重視し、ノーコードで扱えるE2Eテストツールを前提に、改めて検討を進めることにしました。
mabl とは
mabl は、ブラウザ操作を録画して E2E テストを作成できるノーコードテスト自動化ツールです。
主な特徴は以下です。
– ブラウザ操作の記録（レコーディング）でテストを作成可能
– API 、パフォーマンス、アクセシビリティも統合的にテスト可能
– ローカル、クラウド、CI/CD 環境など、柔軟にテスト実行
– データ駆動でテストを作成できる
AI機能も拡充されており、AI Agent によるテスト作成や、MCP 経由でのテスト取得・実行なども可能になっています。
mabl を選んだ理由
複数のノーコード E2E テストツールを比較した結果、最終的に mabl を選んだ理由は 「運用し続けられるイメージが持てたこと」でした。
運用面の強み
– 録画ベースでテストを作成でき、非エンジニアでも扱いやすい
– ブランチ機能により、複数人やテストに詳しくない人などが使っても安全に運用できる
– 変更履歴が分かりやすく、レビューや差分確認が容易
また、Playwright のコードと連携できる機能もあり、将来的に Coding Agent と併用する構成にも適応しやすい点も魅力でした。
導入の進め方
ステップ 1：自動化対象の整理
薬急便はWebブラウザベースのほか、一部ネイティブアプリやLINEミニアプリでも提供しています。
最終的には下記の機能は自動化対象外となりました。
– 通知機能
– ビデオ通話機能
– LINEミニアプリ
– ネイティブアプリ(別プランの加入が必要なため)
これらの自動化可否を整理した結果、全体の約 70% は自動化できる見通しが立ちました。
ただし、重要機能については手動テストと自動テストの両方でダブルチェックするようにしました。
ステップ 2：テスト作成
初期段階では、既存のリグレッションテストの中から完全に自動化できそうなテストケースを優先してテスト作成を開始しました。
なるべく早く成果を上げるために、自動化のみで完結できる部分から着手し、最初の段階で約35ケースを作成しました。
テスト作成を機能単位でタスク化し、スクラム開発の中で管理しました。段階的に進めることで、進捗と成果をチーム全体で共有できました。
ステップ 3：運用ルールの策定
運用フローとしては、開発期間中に発生する仕様変更について、QA管理者が随時内容を収集・整理し、テスト観点として反映できる状態にしています。QA 期間に入った初日には、その変更内容をもとに mabl のテストケースを修正し、翌日以降は修正済みの mabl テストを実行する、という流れで進めています。
ブランチ運用については、機能修正が発生するたびに個別のブランチを作成し、作業を行うルールとしています。また、リリース単位でもブランチを切り、その時点の状態を残すようにしています。
具体的には、master ブランチを起点として、各機能修正ごとにブランチを作成します。リリース時には master からリリースバージョン用のブランチを切り、そのブランチを履歴として保持することで、後から特定バージョンのテスト内容や状態を追えるようにしています。
導入後の成果
今回のテスト改善の取り組みによって以下の成果を得ることができました。
– テスターの人数を7人 → 4人に
– テストカバレッジを約50% → 約78%
テスターを減らしたことで、予算・手間的にも改善されました。
また、E2Eテストでカバレッジを上げたからこそ発見できた不具合の検知事例も出てきています。
直面しているテスト運用上の課題と、現在の対応
mabl を導入・運用していく中で、特に影響が大きかった3 つの課題と、現在取っている対応・方針を紹介します。
1. 環境差異による「Flaky」なテスト
課題
STG 環境と DEV 環境の差異によって、
– ある環境では通るが、別環境では落ちる
– 再実行すると通るが、原因が分からない
といったFlaky なテストが発生しやすい状況が続いています。
これは手動テスト・自動テストの双方で起こり得るもので、
「本当に不具合なのか」「環境起因なのか」の切り分けに時間を取られやすいのが課題です。
現在の対応
– テストデータ管理の徹底
– テスト用データの前提条件を明確化する
– 環境ごとの差分を最小限に抑える
– 環境の役割分離
– DEV / STG / 本番の用途を明確に分け、テスト対象を整理する
2. テストのブラックボックス化
課題
スプレッドシートや Playwright のテストは、
– 「何を確認しているテストなのか」
– 「なぜこの手順になっているのか」
が分かりづらく、テストの意図がブラックボックス化しやすいという問題がありました。
この状態だと、失敗時に「何が期待値だったか」の確認コストが上がります。
現在の対応
mabl 運用では、ブラックボックス化を防ぐために以下をルール化しています。
– echo ステップで、テスト意図をログに明記する
– 「>>>>> start 〇〇の確認」
– mabl MCPやCoding Agent を使用して、テスト内容を取得・可視化する
– mabl 上に定義されているテストケース、ステップ、アサーションを MCP 経由で取得
– 取得した情報を Coding Agent で整形・再構成し、人が読みやすく理解しやすい形式に変換
– これにより、テスト仕様の把握やレビュー、改善を効率的に行えるようにしている
3. テストの妥当性を担保する難しさ
課題
自動テストの数を増やし、一定のカバレッジ向上は実現できたものの、重要な機能については依然として手動テストと自動テストのダブルチェックが必要な状態が続いていました。
この状況では、自動化による効率化や負荷軽減の効果が限定的となり、改善が頭打ちになってしまいます。
背景には、
– テストケースを十分にレビューできていない
– 自動テスト自体の品質にばらつきがある
といった課題があり、「自動テストをどこまで信頼して任せられるか」を判断しづらい状態でした。
現在の対応
まずは手動テストの結果と突き合わせながら、信頼できるテストから段階的に自動化を進めています。
あわせて、AI を活用したレビューを導入し、手動テストのテストケースと mabl のテストケースを比較することで、網羅性や観点の抜け漏れを可視化し、テスト品質の底上げを図っています。
今後について
今後は、mabl を「導入した」だけで終わらせず、運用として回り続ける状態に近づけることを主眼に、次の 3 点に取り組んでいきます。
1. AI を活用した運用工数の削減
テストのブラックボックス化や、テストの変更やテストのレビューにかかる作業は、現在も運用工数を押し上げる要因となっています。
そのため、今後は mabl MCP を活用し、人が手作業で行っていた整理・確認作業を AI に委ねることで、テスト運用全体の工数削減を進めていきたいと考えています。
2.品質保証のさらなる高度化
回帰テストのカバレッジ拡大は一定進みましたが、今後は単純に「数を増やす」のではなく、
– 不具合発生時の影響が大きい領域への重点的なテスト投資
– 重要フロー・変更頻度の高い箇所を軸としたテスト設計
といった リスクベースでの品質保証をより強化していきます。
3. 開発と QA の連携強化
これまでは QA 期間にテストが集中しがちでしたが、今後は開発期間中から
仕様変更の共有 → テスト更新 → レビューが自然に回る流れをより強くしていきます。
具体的にはmabl MCPを使用して開発とテスト作成を一貫した流れでできるようにしたりや、AI Agentを使用したテスト作成も取り入れていきたいと考えています。
おわりに
本記事では、MG-DX におけるテスト体制改善の取り組みと、mabl を中心とした E2E テスト自動化の導入・運用についてご紹介しました。
テスト自動化は「導入して終わり」ではなく、プロダクトやチームの変化に合わせて試行錯誤し続けるものだと、改めて感じています。
本記事で紹介した事例や工夫が、テスト自動化や QA 改善に取り組まれている方にとって、何か一つでもヒントや参考になれば幸いです。
最後までお読みいただき、ありがとうございました。