LASSIC Media らしくメディア
アプリのE2Eテスト自動化（Appium/Maestro）を外注する進め方
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- AppiumとMaestroは記述方式・学習コスト・CI統合のしやすさが異なり、チームの技術スタックによって最適な選択が変わります
- E2Eテスト自動化の外注では対象テスト選定から基盤構築・フレーキー対策まで、工程ごとに外注先と役割分担を決めておくことが重要です
- 費用は端末・OSマトリクスの広さとCI実行頻度によって大きく変動するため、依頼前にスコープを絞り込む準備が成否を左右します
目次
モバイルE2Eテスト自動化とは
モバイルアプリのE2E（エンド・ツー・エンド）テスト自動化とは、ログインから決済・通知受信まで実際のユーザー操作を再現し、アプリ全体の動作を自動的に検証する仕組みを指します。手動回帰テストの代わりに自動化ツールがシナリオを繰り返し実行することで、リリースごとの品質チェックを継続的に行えます。
手動回帰テストは、アップデートのたびに同じ操作を繰り返す必要があり、テスターの工数が積み上がります。リリース頻度が月1回から週1回以上に高まると、手動テストだけでは検証が追いつかなくなります。
自動化を導入することで、プルリクエストのたびに主要シナリオを自動検証できるようになります。不具合をコードレビュー段階で検出できるため、リリース後の差し戻しリスクを下げられます。一方で、自動化基盤の構築・保守には専門知識が必要なため、外注を活用するケースが増えています。
AppiumとMaestroの比較
E2Eテスト自動化のツールとして代表的なのがAppiumとMaestroです。両者は設計思想が大きく異なり、チームの技術スタックや運用体制によって適切な選択が変わります。
| 比較項目 | Appium | Maestro |
|---|---|---|
| テスト記述方式 | Java・Python・JavaScript等の言語でコードを書く | YAMLファイルでシナリオを記述。コード不要 |
| 環境構築の手間 | Appiumサーバの起動・ドライバ設定・依存ライブラリ管理が必要。セットアップに数時間かかることがある | 1コマンド（brew install maestro等）でインストール完了。Maestro Studioで操作を視覚的に記録・生成できる |
| 学習コスト | プログラミング経験が前提。WebDriverプロトコルの理解も必要 | YAML構文のみ。非エンジニアでもシナリオ編集が可能 |
| CI統合 | GitHub Actions・CircleCI・Bitriseに統合可能 | 同様にGitHub Actions・CircleCI・Bitriseに統合可能 |
| クラウド実行 | BrowserStack・Sauce Labs等のサードパーティサービスを利用（各社料金による） | Maestro Cloud：執筆時点の目安として月額125ドルから。 並列実行数に応じた従量課金*1 |
| ローカル実行 | OSSのため無料 | OSSのため無料 |
| 柔軟性・拡張性 | プログラムで複雑なロジック・条件分岐・外部API呼び出しを実装しやすい | シンプルなフロー向き。複雑な条件分岐は苦手 |
| 向いているケース | エンジニアチームが主体・複雑なシナリオ・多言語テストコードの資産がある場合 | 素早く始めたい・QAや企画担当もシナリオに関与させたい場合 |
どちらのツールも、GitHub Actions・CircleCI・Bitriseといった主要CIサービスへの統合が可能です。ツールの差は「誰がテストを書き・保守するか」という運用設計に直結します。
AppiumはOSSとして長い実績を持ち、Java・Python・JavaScriptなど複数言語のバインディングが揃っています。既存のテストコード資産や開発チームのスキルセットと親和性が高い場合は、Appiumが選ばれます。
MaestroはYAML記述とMaestro Studio（視覚的なシナリオ作成ツール）により、エンジニア以外もシナリオの作成・修正に参加できます。立ち上げの速さを優先する場合に有利です。
E2Eテスト自動化の導入ステップ
手動回帰の限界と自動化の価値
アプリのリリースサイクルが短縮されると、手動テストの工数は比例して増加します。特にiOS・Android両対応・複数OSバージョン・複数端末サイズを考慮した端末/OSマトリクスの確認は、手動では組み合わせ数が膨大になります。
E2Eテスト自動化を導入すると、プルリクエストのたびに主要フローを自動検証できます。リリース判定に必要な回帰テストの大部分を自動化すれば、QAエンジニアがより複雑な探索的テストに集中できます。
対象テストの選定 — 回帰対象の優先付けが最初の論点
E2Eテストの自動化は「すべてのシナリオを自動化する」ことが目標ではありません。自動化の費用対効果が高いのは、リリースのたびに毎回確認が求められる主要フロー（ログイン・購入・通知受信など）に絞り込んだ回帰テストです。
画面遷移が頻繁に変わるUIや、一度しか確認しない探索的テストは手動が効率的です。自動化の対象を絞り込む段階で、外注先と「何を自動化し・何を手動に残すか」の合意を取ることが、後の保守コスト削減に直結します。
基盤構築 — 環境構築とテスト記述
Appiumを選択した場合、Appiumサーバの起動・iOSならXCUITest Driverの設定・AndroidならUiAutomator2 Driverの設定が必要です。依存ライブラリのバージョン管理を怠ると、OSアップデートや端末変更のたびに動作が壊れます。
Maestroを選択した場合、インストール後すぐにYAMLでシナリオを記述できます。Maestro Studioを使えば実際の操作を記録してYAMLを自動生成できるため、初期のシナリオ作成速度が上がります。どちらの場合も、テストコードをGitリポジトリで管理し、変更履歴を追跡できる体制を最初に整えておくことが大切です。
CI組込み — GitHub Actions・CircleCI・Bitriseへの統合
基盤構築後は、CI/CDパイプラインにテスト実行ステップを組み込みます。プルリクエスト時に自動でテストが走るよう設定することで、コードレビューと同時に動作確認が行えます。
CI実行のたびに実機またはエミュレータ・シミュレータでテストを動かすと、実行時間がパイプライン全体のボトルネックになる場合があります。並列実行数とコストのバランスを検討する必要があります。
フレーキー（不安定）テストへの対処
E2Eテストで頻出する課題がフレーキーテスト（flaky test）です。フレーキーテストとは、コードの変更がないにもかかわらず成功したり失敗したりする不安定なテストを指します。主な原因はネットワーク遅延・非同期処理の待機不足・アニメーションのタイミングなどです。
対策としては、要素が表示されるまで待機するウェイト処理の充実・リトライ設定の追加・依存する外部サービスをモックに置き換えるなどが有効です。フレーキーテストを放置すると、開発チームが「テスト結果を信用しない」状態になり、自動化の価値が下がります。
継続保守 — シナリオの更新とコスト管理
アプリのUI変更や機能追加のたびにテストシナリオを更新する必要があります。保守工数を見積もらずに自動化を始めると、アップデートのたびにテストが壊れる状態になります。外注先に保守フェーズの費用感を確認し、継続契約の形態（運用保守契約か都度発注か）を事前に決めておきましょう。
外注で進める手順
依頼前の準備 — アプリ情報とテスト要件の整理
外注先への依頼を始める前に、以下の情報を整理しておくと見積もりの精度が上がります。
- アプリのプラットフォーム（iOS・Android・両対応）
- 自動化したい主要シナリオの数と内容（ログイン・購入フローなど）
- 対象とする端末・OSバージョンの範囲
- 既存の開発環境（使用言語・リポジトリ管理方法・CI/CDサービス名）
- 内製でテストを保守するか・保守も外注するかの方針
RFP（提案依頼書）の作成と相見積もり
上記の情報をまとめたRFP（Request for Proposal）を作成し、複数の外注先に提案を依頼します。自動化対象のシナリオ数・端末マトリクスの規模・CI連携の要件を具体的に記載するほど、外注先の提案精度が高まります。
相見積もりは2〜3社程度が現実的です。価格だけでなく、提案されたツール選定の根拠・フレーキー対策の方針・保守体制を比較することが大切です。
パイロット運用 — 小規模で始めて精度を検証
最初から全シナリオを一括で自動化しようとすると、スコープが広がりすぎてプロジェクトが長期化します。まず3〜5シナリオのパイロット運用を行い、CI連携の動作・フレーキーテストの発生頻度・保守コストの実績を先に把握することが、本格展開の精度を高めます。
パイロット後に本格展開するかどうかを判断する検収基準（成功率・実行時間・フレーキー発生率）を事前に取り決めておくと、外注先との認識齟齬を防げます。
本格展開と保守体制の確立
パイロット検証を経てから対象シナリオを拡大します。端末/OSマトリクスを広げると実行コストが比例して増加するため、優先度の高い組み合わせから段階的に拡張しましょう。
保守フェーズでは、アプリのUIが変わるたびにテストシナリオの修正が発生します。外注先に月次・四半期ベースの保守サポートを依頼するか、シナリオ更新のみ都度発注するか、契約形態を明確にしておくことが継続運用のポイントです。
費用が変わる要素と依頼前の確認ポイント
費用を左右する4つの要素
E2Eテスト自動化の外注費用は、以下の要素によって変動します。費用感は市場参考値であり、一次資料に基づく確定値ではありません。外注先に見積もりを取る際の参考としてください。
- 自動化するシナリオ数：シナリオが増えるほど構築・テストコードのレビュー工数が増加します
- 端末/OSマトリクスの広さ：iOS・Android・複数OSバージョン・実機検証の組み合わせが多いほど実行コストと工数が上がります
- CI実行頻度：プルリクエストごとに実行するか・スケジュール実行か・並列数の設定によってクラウド実行コストが変わります
- 保守の継続契約有無：UIリニューアルや機能追加のたびにシナリオ更新が必要なため、保守契約の有無で総コストが大きく異なります
依頼前に確認しておくべき7つのポイント
外注先への依頼前に、以下の点を社内で確認しておくと、提案の比較がしやすくなります。
- 自動化したいシナリオの一覧と優先順位は決まっているか
- 対象プラットフォーム（iOS/Android）と検証したい端末・OSバージョンの範囲は決まっているか
- 既存のCI/CDサービス（GitHub Actions・CircleCI・Bitriseなど）は何を使っているか
- アプリのソースコードにアクセスできるか・テスト環境は別途用意できるか
- 社内でテストシナリオを保守する担当者を確保できるか
- パイロット運用後の検収基準（成功率・実行時間など）は設定できるか
- AppiumとMaestroのどちらを希望するか・または外注先に選定を委ねるか
これらを事前に整理しておくことで、外注先との初回打ち合わせが具体的な議論になります。特にツール選定を外注先に委ねる場合は、選定根拠の説明を提案に含めるよう依頼しましょう。
外注先の選び方
Appium/Maestroの実務経験があるかを確認する
E2Eテスト自動化を外注する際に確認したいのは、該当ツールの実務導入経験です。「テスト自動化ができます」という説明だけでなく、Appiumまたは MaestroをどのCIサービスと連携し、フレーキーテストをどのように管理してきたかを具体的に聞いてみましょう。
モバイルに特有の課題（iOS・Androidの両対応・実機検証の環境管理）への対応経験があるかどうかも重要な確認ポイントです。Webアプリのテスト自動化は経験豊富でも、モバイル実機への対応が手薄なベンダーは存在します。
保守・更新フェーズの体制を確認する
テスト自動化の価値は初期構築後の継続運用で発揮されます。外注先がシナリオ更新・フレーキー対応・端末マトリクス拡張を継続して支援できるかどうかを確認しましょう。
初期構築のみで保守は対応しないベンダーに依頼した場合、アプリのUIが変わるたびに社内でシナリオを更新する必要が生じます。社内に保守担当者がいない場合、テストが形骸化するリスクがあります。
テストコードの納品形式と移管方針を確認する
テストコード・YAMLファイル・設定ファイルがGitリポジトリで納品されるか、社内に移管された後も外注先なしで運用できる状態になるかを確認します。ベンダーロックインを避けるためにも、成果物の所有権と移管手順を契約に明記することが大切です。
まとめ：Appium/Maestro外注で押さえる3つの判断軸
本稿では、モバイルアプリのE2Eテスト自動化をAppiumまたはMaestroで外注する進め方を整理しました。要点を3つに集約すると次のとおりです。
第一に、ツール選定はチームの技術スタックと運用体制に合わせて行うことです。エンジニアが主体でコードで柔軟に管理したい場合はAppium、素早く始めてQA担当もシナリオに参加させたい場合はMaestroが向いています。
第二に、外注範囲は「初期構築のみ」か「保守込み」かを最初に決めることです。アプリのUI変更のたびにシナリオ更新が発生するため、保守フェーズの費用と責任分担を契約前に明確にしておくことが、継続運用の成否を左右します。
第三に、パイロット運用を小さく始め、フレーキーテストの発生状況とCI実行コストを実測してから本格展開することです。端末/OSマトリクスを最初から広げすぎると、実行コストと保守工数がすぐに肥大化します。
よくある質問
AppiumとMaestroはどちらから始めるのが現実的ですか？
社内にモバイルテスト自動化の経験がない場合は、Maestroから始めることをお勧めします。YAMLでシナリオを記述でき、Maestro Studioで操作を視覚的に記録できるため、最初のシナリオを短期間で作成できます。一方、開発チームが複数言語のテストコード資産を持っている場合や、複雑な条件分岐を含むシナリオが多い場合はAppiumが適しています。
フレーキーテストが多発すると何が起きますか？
フレーキーテスト（flaky test）が増えると、開発チームが「テスト結果は当てにならない」と判断し始め、失敗しても無視する習慣がつきます。結果として自動化への投資が形骸化するリスクがあります。対策として、要素の待機処理の充実・外部サービスのモック化・リトライ設定の追加が有効です。外注時はフレーキー対策の方針と対応フローを提案に含めるよう依頼することが大切です。
MaestroのローカルとMaestro Cloudの違いは何ですか？
Maestroのローカル実行はOSSで無料ですが、テストを動かすにはローカルマシンに端末（実機またはシミュレータ）を接続する必要があります。Maestro Cloudはクラウド上で複数端末を並列実行できるサービスで、執筆時点の目安として月額125ドルから、並列実行数に応じた従量課金です（*1料金は変更される可能性があるため、依頼前にMaestro公式サイトで最新情報をご確認ください）。CIと組み合わせて自動実行したい場合はMaestro Cloudが利便性の面で有利です。
E2Eテスト自動化を内製せずに外注するメリットはありますか？
自動化基盤の構築には、Appium・Maestroの設定に加えて、CI/CDとの統合・フレーキー対策・端末管理のノウハウが必要です。これらを内製で習得するには、エンジニアの学習時間と試行錯誤の工数が発生します。外注先に依頼することで、実務経験のある体制を初日から活用でき、既存の開発リソースをプロダクト開発に集中させられます。ただし、保守フェーズで社内担当者が関与できる体制を同時に整えておくと、外注依存を下げられます。
外注した場合のテストコードの所有権はどうなりますか？
テストコード・YAMLファイル・設定ファイルの所有権は、契約内容によって異なります。納品物をGitリポジトリで社内に移管し、外注先なしでも保守できる状態にすることを契約に明記しておくことが重要です。所有権の取り決めを曖昧にしたまま依頼すると、ベンダー変更時に成果物の引き渡しでトラブルになる場合があります。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：Maestro「Maestro Cloud 料金ページ」（2024年。執筆時点の目安。料金は変更される可能性があります）
