想定読者
本記事は、以下のような方々を想定読者としています。
- AIを活用した自動テストを検討している方
- QAエンジニア、テストエンジニア、品質保証に関わる実務者
はじめに
本記事をご覧いただきありがとうございます。 QA部の木下です。
主にDMM TVのQA業務を担当しています。
昨今、AIを活用した開発効率化が急速に進み、QA領域においても「AIにテスト設計やテストの実行を任せる」手法が現実味を帯びています。
今回は、CursorとMaestro MCPを組み合わせ、テストコードを一行も書かずに自然言語でネイティブアプリを操作・検証した取り組みについて紹介します。
ネイティブアプリのQAやテスト業務に携わり、AIを活用した自動化を検討している方の参考になれば幸いです。
本取組の背景
DMM TVはアニメを主軸に、バラエティや2.5次元作品・舞台・ミュージカル、ドラマ、映画など幅広いジャンルのコンテンツを提供する、DMMの総合動画配信サービスとして2022年12月にローンチされました。
引き続きより良いユーザー体験のため、機能の改修・追加が行われ、多種多様なコンテンツを提供する総合動画配信サービスとして成長を続けています。
日々進む機能改修に対し、QAチームでは主に2つの性質の異なるテストを実施しています。
「機能テスト」
新規機能の追加や振る舞いの変更が伴う既存機能の修正に対し、仕様通りに動くかを確認するテストです。
機能テストは改修のたびにテスト内容が変化するため、従来のスクリプトベースの自動テストでは、テストコードのメンテナンスコストが実行メリットを上回ってしまい、自動化には向かないとされてきました。
「回帰テスト（リグレッションテスト）」
プログラムの一部を変更した際に、振る舞いの変更が伴わない既存機能に影響が出ていないかを確認するテストです。
回帰テストは同じテスト項目を繰り返し実行するため、自動化の恩恵をもっとも受けやすい領域です。
実際にDMM TVでも自動テストを導入し、手動テストとの役割分担を最適化しています。
今回の取り組みでは上記の「機能テスト」を対象に実施しました。
先述のとおり、機能テストは自動テストの導入が不向きのため手動でテストを行なっています。
手動でテストを行う場合、テスト実行者がテストケースを読み解き、一つずつ画面を操作して確認するという一連の工程に時間がかかるという課題があります。
人の手による操作である以上、どれだけ熟練した担当者であっても、手順の勘違いや確認漏れといったヒューマンエラーの可能性を完全にゼロにすることは困難です。
また、テスト実行者のリソース確保にも限界があります。
これらの手動テストの課題を解決し、「手動テストの延長線上で、誰でも即座に実行できる自動化」を目指して、Cursor × Maestro MCPでのテスト実行に取り組みました。
使用したツールについて
今回の取り組みに使用した主要ツールは以下のとおりです。
| ツール | 用途 | 選定理由 |
|---|---|---|
| Cursor（v2.3.41） | IDE / AIエージェント | 文脈理解に優れ、MCPを介して外部ツールを直感的に操作できるため。 |
| Maestro MCP（v2.0.10） | スマートフォン操作 | 自然言語の指示を、シミュレータへの操作（タップ、スクロール等）に変換するブリッジ。 |
| Xcode（v16.3） Android Studio（v2025.2.1） |
シミュレータ | 実機に近い環境での検証。 今回はAndroid 14（Pixel 6）とiOS 18（iPhone 13）をメインに使用。 |
従来のMaestroによる自動化は、あらかじめ「どのボタンを押し、何を待つか」をYAMLファイルに定義する必要がありました。
しかし、MCPを介することで、Cursor上のLLMがアプリのView Hierarchy（画面構造の階層データ）をリアルタイムで解析できるようになります。
そのため、AIが「今、画面に何が表示されているか」を自ら把握し、次に取るべき行動をその場で判断して実行します。
これにより、人がテストスクリプトを書くという手順を省くことができます。
具体的な手順
①関連ドキュメントのインプット
テストケースをCSV形式で出力し、Cursorにインプットします。
また、併せてCursorのContext機能を活用し、AIに「DMM TVの仕様」を学習させます。
- テストケース（CSV形式）：スプレッドシートで管理している検証ステップと期待値。
- 画面仕様書：各画面の名称や遷移ロジックの詳細。
- ナレッジドキュメント：サービス固有の用語などを記載します。また、テストに使用するテストデータのタイトルや、テストに使用するアカウント情報などこちらに記載します。
Webブラウザのテストの場合はURLを記載することでテスト対象画面へ直接遷移が可能ですが、ネイティブアプリの場合はテスト対象画面への直接遷移が困難です。
そのため、テストケース内には「どのボタンを経由して目的の画面へ行くか」という導線を明記しておく必要があります。
②プロンプトによる実行指示
テストケースと仕様のインプットが完了しましたら、テスト実行者へ依頼するのと同等の粒度で指示を出します。
取り組み時は以下のようなプロンプトをCursorに入力しました。
入力したプロンプトの例：
Maestro MCPを使用し、添付したテストケースCSVのNo.1〜8を実行してください。 最終的に『期待値と実際の挙動に差がなかったか』をまとめたテストレポートを出力してください。
画面仕様書やナレッジドキュメントで仕様を学習・参照させているため、プロンプトはシンプルな内容にしています。
また、テスト完了後にテストレポートを出力するよう指示することで、AIが実行したテスト内容に誤りや齟齬がないか確認できるようにします。
③テストレポートの確認と分析
テストケースの実行が一通り完了すると、Cursorはテストレポートを出力します。
プロンプトで指示したとおり、テストレポートには「Pass/Fail」の結果を表示するだけではなく、何をもってPassとしたか、またはFailとしたかが記載されます。
# DMM TVアプリ 未ログインテスト結果レポート ## テスト実行情報 - **実行日時**: 2025-12-17 14:13:22 - **デバイス**: Pixel_7 (emulator-5554) - **アプリ**: DMM TV - **プラットフォーム**: Android - **クール前**: 冬アニメ配信カレンダー - **クール中**: 秋アニメ配信カレンダー ## テストサマリー | 結果 | 件数 | |------|------| | **合格 (PASS)** | 7 | | **部分確認 (PARTIAL)** | 0 | | **未実行 (NOT_EXECUTED)** | 1 | | **不合格 (FAIL)** | 0 | | **合計** | 8 | ## テストケース詳細 --- ### ✅ Test Case No.1: クール前のお気に入りボタン押下テスト - **画面**: アニメTOP - **パーツ**: 配信スケジュール棚 - **機能**: お気に入り - **前提条件**: クール前の場合、未ログイン、アプリの通知許可をオンに設定済み - **アクション**: 1. アニメTOPに遷移 2. 配信スケジュール棚を確認 3. 任意の曜日選択 4. お気に入りボタンを押下 - **期待値**: ログインを訴求するダイアログが表示されること - **結果**: ✅ **PASS** - **詳細**: 通知許可設定を確認（`granted=true`）した上でテストを実施。クール前（冬アニメ）の月曜日を選択し、お気に入りボタンを押下。ログインダイアログが正常に表示されたことを確認。ダイアログには「お気に入り登録はログイン後にできます」「ログインしますか？」というメッセージと「ログイン」「キャンセル」ボタンが表示された。通知許可がオンの状態で正常に動作することを確認。 --- ### ✅ Test Case No.2: クール前のお気に入りボタン押下テスト（通知許可オフ） - **画面**: アニメTOP - **パーツ**: 配信スケジュール棚 - **機能**: お気に入り - **前提条件**: クール前の場合、未ログイン、アプリの通知許可をオフに設定済み - **アクション**: 1. アニメTOPに遷移 2. 配信スケジュール棚を確認 3. 任意の曜日選択 4. お気に入りボタンを押下 - **期待値**: ログインを訴求するダイアログが表示されること - **結果**: ✅ **PASS** - **詳細**: 通知許可設定をオフ（`granted=false`）に変更した上でテストを実施。クール前（冬アニメ）の月曜日を選択し、お気に入りボタンを押下。ログインダイアログが正常に表示されたことを確認。通知許可がオフの状態でも、未ログイン時のお気に入りボタン押下ではログインダイアログが正常に表示されることを確認。 --- ### ✅ Test Case No.3: クール中のお気に入りボタン押下テスト - **画面**: アニメTOP - **パーツ**: 配信スケジュール棚 - **機能**: お気に入り - **前提条件**: クール中の場合、未ログイン、アプリの通知許可をオンに設定済み - **アクション**: 1. アニメTOPに遷移 2. 配信スケジュール棚を確認 3. 任意の曜日選択 4. お気に入りボタンを押下 - **期待値**: ログインを訴求するダイアログが表示されること - **結果**: ✅ **PASS** - **詳細**: クール中（秋アニメ）のお気に入りボタンを押下。ログインダイアログが正常に表示されたことを確認。クール前と同様の動作が確認できた。 ---
上記のようなテストレポートが出力されることで、「なぜPassと判断したか」の根拠が明確になり、QAエンジニアによる最終確認がスムーズになります。
実際に使ってみてわかったこと
良かったこと
①非エンジニアでも自動テストが可能に
手動実行している機能テストの項目書をインプットし、プロンプトで指示が出せるため、プログラミング知識がないメンバーでも自動でテストを実行できました。
従来の自動テストに必要なテストスクリプトの準備が不要なため、気軽に実行できます。
この点は、自動テストのハードルを下げられたように感じます。
②手動実行から自動実行への置き換えによる生産性向上
単純な動作確認のテストでは、着手から完了までの時間は手動実行と同等〜微増となりました。
バックグラウンドで実行させることができれば、QAエンジニアはその間にテスト設計や難易度の高い探索的テストに集中でき、生産性の向上が見込まれます。
課題と感じたこと
①「違和感」の判定が苦手
Cursorに限らず、AIを使用してテスト実行するうえで発生する課題ですが、「アニメーションが少しカクつく」「バナーの色味が仕様書より薄い」といった、感性に依存する部分の判定は現時点では困難です。
仕様書に明文化しにくい感覚的なテストは、現状AIではスキップせざるを得ません。
同様に、バナーやパッケージなど画像内に表示されるロゴやテキストから作品タイトルを確認するテストの場合も、AIでは判定できずスキップとなりました。
②日本語入力の制約がある
Maestro（Android）では現時点でUnicode文字の入力（例：日本語）がサポートされていません。
そのため、日本語入力が必要なテアプリ内の検索機能のテストや特定の日本語タイトルの作品を検索するテストはスキップとなりました。
日本国内向けのサービスとしては、今後の改善が待たれるポイントです。
③複雑なテストケースを実行すると、Cursorが不安定になる
複雑なテストケースや一度に多くのテストケースを指示すると、Cursorのコンテキスト溢れや、Maestro MCPとの通信回数の増加につながります。
それにより、テストの途中でCursorの処理が中断されるケースも見られました。
再度プロンプトを入力することでCursorはテストケースの続きを実行できます。
中断せず実行するためには小分けにして実行するなどの運用上の工夫が必要と感じました。
今後の展望とまとめ
今回の取り組みを通じて、全てのテストを即座にAIへ置き換えるのはまだ時期尚早であるものの、「定型的な動作確認」においては有効なアプローチになると感じました。
AIに任せられることと任せられないところを踏まえ、AIを「QAエンジニアの頼れる副操縦士」として、さらに効率的かつ的確なテストを行えるよう構築していきたいと考えています。
また、Maestro MCPはFire TVやAndroid TVなどのテレビデバイスのアプリにも使用可能です。
スマホやタブレットのテストだけではなく、テレビデバイス向けへのテスト実行範囲拡大も視野に入れ、マルチデバイスにおける検証コストの削減を進めていく所存です。
自動テストの導入障壁だった「コードの学習コスト」や「テストスクリプトの作成」なしで、誰でも自動実行できる点は今後のQA業務にとって大きな武器になります。
本記事が、ネイティブアプリのテスト業務における自動テストの効率化やAI活用を検討する皆様の一助となれば幸いです。
関連記事
QA部では、AI技術を活用したテスト業務の効率化や、品質保証のさらなる高度化に向けた取り組みを推進しています。
本記事でご紹介した内容のほかにも、AIを実務に投入した事例や記事を公開しています。
ぜひあわせてご覧ください。
developersblog.dmm.com
developersblog.dmm.com
