手動テストケースをそのまま実行するVLMテスト実行エージェント / VLM Test Execution Agent for Running Manual Test Cases As-Is

E2E(UI)自動テストは、ロケーター取得やUI変更追従、ゲーム画面はUI要素がロケーターで取れずテストが壊れやすいなど、実装・運用コストが高くなりがちです。そこで本セッションでは、手元にある人が実行するために作った手動用のテストケースを、自然言語のままかつ表示された画面を用いてテスト実行できる汎用テスト実行AIエージェントの設計と検証結果を紹介します。

・テスト実行エージェントの設計および技術
開発したテスト実行エージェントの思想と設計、技術、精度向上の工夫を紹介します。

・手動テストケースでどこまで自動テスト実行ができたのか？
手動テスト用に記載されたテストケースをどれくらい実行できたのか検証結果を報告します。

・発見した不具合例、人とエージェントの棲み分け
どういったテストケースの実行でどういった不具合を発見できたかの実例を紹介します。
またこの結果からエージェントと人でどのような戦略を取ってテストを行えば良いかの知見をお伝えします。

***

End-to-end (E2E) UI test automation often comes with high implementation and maintenance costs. Locators must be identified and maintained, UI changes frequently break test scripts, and game screens are particularly challenging because UI elements cannot always be identified through conventional locators.

In this session, we introduce the design and evaluation of a general-purpose AI test execution agent that can execute existing manual test cases written in natural language, using only the displayed screen—without converting them into automated test scripts.

**• Design and Technology Behind the Test Execution Agent**
We will present the design philosophy, architecture, core technologies, and techniques used to improve the accuracy and reliability of the AI test execution agent.

**• How Far Can Existing Manual Test Cases Be Automated?**
We will share evaluation results demonstrating how effectively the agent was able to execute test cases originally written for manual testing.

**• Defects Discovered and the Division of Responsibilities Between Humans and AI Agents**
We will showcase real examples of defects detected by the agent and discuss which types of test cases are well suited for AI-driven execution. Based on these findings, we will share practical insights into how human testers and AI agents can work together effectively by leveraging their respective strengths.

Transcript

1. ⼿動テストケースをそのまま 実⾏するVLMテスト実⾏ エージェント 〜モンストでの適⽤と検証結果〜 株式会社MIXI 開発本部 たんぽぽ室 QAG SDETチーム/QAEチーム マネージャー 松⾕ 峰⽣ ©MIXI
2. ⾃⼰紹介 株式会社MIXI 開発本部 たんぽぽ室 QAG SDETチーム / QAEチームマネージャー 松谷 峰生 (まつや みねお) 趣味 : ロボット開発、小説執筆、マンガ執筆 ペット : フクロモモンガ 僕が描いている商業マンガが出ていたりします。 今連載マンガ2本を持っています。 • あなたの知らないテストの言葉 • マンガではじめるMagicPod入門 ©MIXI 2
3. 今⽇のお話 既存の手動テスト用のテストケースを AIが実行できたら便利ですよね。 画面入力可能なLLM(今はほとんどのモデルができる )を使って、人が行うように目で見て 操作する形で 手動テスト用に作られたテストケースを実行できるエージェントを 開発し、実際に手動用のテストケースを実行させたお話をします。 テスト ケース ©MIXI この手順を実 行してと。 Passだな！ テスト ケース この手順を実 行します。 Passでした。 3
4. AIでのUI⾃動テスト実⾏を 考えている⼈/⾏っている⼈の 参考になりましたら 幸いです。 ©MIXI
5. VLMで⼿動テスト⽤テストケースを実⾏する利点 既存の資産 (テストケース )を使える 手順、期待結果が定まっている 手動テストケースの利 用のメリット 人との共同テスト実行ができる 人が見て操作する、の再現 要素が取れないモノに対応できる 保守コストの低減 ©MIXI VLM利用の メリット 通常のUI自動テストと 比べたメリット 5
6. これから話すツールの 使い⽅のイメージ ©MIXI
7. 全部AI、全部⼈、ではなくハイブリッドという落とし所 「テスト項目 1から50まではAさんで、 51〜150まではリスクも低いから AIの実 行でお願いします〜」 今はAI利用など言われますが、全てAIか、全て人か、の0か100かの話になりが ちです。リスクや AIの特性に応じて、人と AIでの実行範囲分割のテスト戦略が 現実的な落とし所ではないか と考えています。 この辺はリスク高い し判断が重要。 人の確認がいいな ©MIXI リスクが低い部分の確 認は私が確認します。 7
8. デモ ©MIXI
9. デモ では、ウェルカムクエストのはじめ「ギミックを学ぼう！その１」のテスト実行を行 います。 テスト項目は以下です。 (本当のテストは細かく確認しています。デモ用です ) • 前提条件 ◦ ウェルカムクエスト出現中 • テスト手順 ◦ ウェルカムクエスト「ギミックを学ぼう！その 1」を選択する。 ◦ 戦闘をクリアし、報酬をもらい、最後にホーム画面まで移動する • 期待結果 ◦ ギミックを学ぼう！その 1をクリアでき、報酬をもらえること、最後に ホーム画面まで移動できること ©MIXI 9
10. アーキテクチャ ©MIXI
11. 前提 • Androidを対象としています • テストケース全体から１項目ずつ読み込んでテスト実行するツールです • 人がテスト実行をする時は、テスト項目の期待結果だけを確認するわけ ではなく、テスト手順の途中でもおかしいことがあると気付きます。それを 考慮した設計にしています。 あれ？ この段だけ低くない？ ©MIXI 11
12. 最初に簡単に全体の構成の説明(後ほど補⾜) Driver用行動計画 1. 2. 3. Driver (操作部) Assertion スレッド (検証部) map 作成・更新 4. 5. 6. 最終検証 7. ©MIXI (以降同じテスト項目は リプレイ機能で実行可能 ) 1テスト項目読み込み後、行動計画を立てる ゲーム操作のみを行うDriverと、Driverの行動結果 を検証するAssertionスレッドに別れ並列実行される Driverはtool callでゲーム操作やデバッグツール操 作を適宜行う Assertionは「過去のテストケース」から抽出した「ど うなれば正しいか」を使い検証を行う Stepを進めながら「どこで」「何を」「どうしたら」「どう なった」という地図を作る(map) 最終検証は期待結果を満たしたか検証する。また 必要に応じてAPIでUser dataを読み、確かに経験 値やアイテムが更新されたか確認する (同じテスト項目は以降リプレイ機能で実行可) 12
13. Plan (⾏動計画) テスト項目1件を読み込むと、まずは行動の計画を行います。 これは期待結果を満たす(テストケースを最後まで実行する)ために、どのように ゲームを操作すればいいかの一連の行動計画 を立てます。 この際、mapを使って行動計画を立てます。 mapがない場合は行動計画なしでテスト実行します。 map(このツール内での用語) : 実際のゲームの状態の地図。どの画面で、どの要素に対して、どういう操作をし たら、どのようになった、が記録されている。 テスト実行をすればするほど知見として成長する。 ©MIXI 13
14. Driver (操作部) Driverは端末からスクリーンの画像を受け取り、要素の特定と操作 を行いま す。 tool callを使い、ゲーム操作や、デバッグツールを AI判断で呼び分けます。 行動計画がある際は計画した行動を使いますが、行動が成立しない場合はAI 操作にバトンタッチします。 端末操 作用 apk 端末操作はAccessibility Service を利用している ©MIXI デバッグ ツールや api 画面 Driver (操作部) tool call Responses API Websocket mode 14
15. Assertion (検証部) AssertionはDriverと並列に走り、Driverの各ステップでの行動結果(あくまで stepの妥当性。遷移やUI等)を検証します。 過去に作られたテストケースをまとめて入れている DBと接続し、その行動と マッチするテストがあったら、その期待結果と比較されます (≠今やっているテ スト項目 ) つまり、各ステップにおいての妥当性は過去のテストの期待結果に求めてい ます。 マッチするテストがなければ、大きなUI崩れがないか、遷移が不自然(これまで の文脈から大きく外れる)といったことが検証されます。 Driverからのstepの データ ©MIXI Assertion スレッド (検証部) で比較 過去のテストから抽出し た「どう動くべきか」の データ 15
16. Final Assertion (最終検証) Driverでテスト実施を最後まで実施したと判定し、Assertion部の結果が出揃っ たら、最終検証が行われます。 ここでは与えられたテスト項目の期待結果が満たされているか判定 します。 UI自動テストで得た結果のみではなく、アイテム付与やステージクリアなど、 データ変更を伴うものはAPIでUser Dataを取得し、確かに変更されているか の確認が実施 されます。なのでUIおよびAPIを通したデータ更新の双方から 判定を実施 します。(テスト実行前にもUser Dataを取得するのでその比較) Driverの結果 Final Assertion tool call User Data API Assertionの結果 ©MIXI 16
17. Report (AI実⾏において最重要) ©MIXI 結果の判定理由が出力される 17
18. Report (AI実⾏において最重要) 「タップ対象を誤った可能性が高 い」のように、結果の理由が出力 される ©MIXI 18
19. 検証と結果 ©MIXI
20. 実際のテストケースでツールの検証 実際のテスト102件を対象に、ツールが想定した通りに動くかの実験を行いまし た。 件数が少ないですが、そもそも意図した通りテスト実行ができるのか、できない 場所の傾向を掴むために行いました。 結果は以下の通りです。 検証結果 (gpt-5.5) 件数 割合 意図した通りのテストができた 87 / 102 85.2% 意図した通りのテストができなかった 15 / 102 14.8% ツールが意図した通り正しくテスト実行できたか。 バグ検出精度ではない ©MIXI 20
21. 「意図した通りのテストができなかった」内訳 理由 件数 前提条件・条件セットアップ不足 4 手順が曖昧・伝達不足 4 ステップ上限 3 表示されているものが確かに意図した画像か 3 明確な嘘 (できていないものをできたとした) 1 ©MIXI 21
22. 前提条件‧条件セットアップ不⾜ 私が一番盲点だった部分です。 期待結果を得るためのテスト手順はテスト項目に記載されています。 盲点だったのが「前提条件を整えるための手順は記載されない 」です。 例えば「ウェルカムクエスト出現中」や「XXを所持している」などです。 ゲームであればデバッグツールを使用して条件を整える必要がある場所 もあ ります。 これら前提条件は暗黙の了解であることが多かった です。 AIでテスト実行を行うためには、前提条件を整える手順を記載するか、知識とし て与える必要があります。 また実際のテストケースでは、上から実施することで前提条件が整っている、 という形も多い です。よって順番に実施するのも良さそうです。 ©MIXI 22
23. ⼿順が曖昧‧伝達不⾜ テスト手順を確認すると「任意のシングルガチャを引く」と書いてあったりします。 これが本当に「任意」だったら AIは実行できます。 なのですが実は(ただし12周年ガチャは除く)という暗黙の例外がある場合 で す。 ゲームの場合、例外はそのときのキャンペーンなどで、ファーストビューにある ことが多く 、それでAIが人の意図とは異なる動作をしてしまうことがありました。 他にも、実は一回別の場所に移動してからもう一度戻って確認して欲しかった、 みたいな場所ももちろん記載してなければAIはそのままその場所でPassを出し てしまいます。「人なら当然そうやって見るでしょ？」みたいな部分は明文化 し ておくのが良さそうです。 ©MIXI 23
24. ステップ上限 AI自動テスト実行ツールには、無限に実行しないためにStepの上限を設けてい ます。 テスト項目の中には、記載としては短いステップながらも、実際に試すと非常 に長い動作が必要な場合 があります。 こういった場所はテスト意図が複数含まれている場合や、前提条件を整えるた めのステップが含まれる、といったことがあります。 ©MIXI 24
25. 表⽰されているものが確かに意図した画像か 例えば「ログインボーナスのダイアログに真獣神玉が表示されていること 」など です。 AIは「真獣神玉が表示されているためPass」としていましたが、本当にテスト ケースが意図したモノと表示画像が一致しているかを AIだけで判定できてい るか疑問 です。 (User dataとしてはアイテム付与がされているから、「付与されていること」はわ かるとは思われる) ここはAI任せにせず、テンプレートマッチングなどの機械的な比較ツール を作 りtool callし判定するのが良さそうです。 ©MIXI 25
26. 明確な嘘 (できていないものをできたとした) 今回の実験では、文字入力をミスって入力できていないにも関わらず「入力がで きている」と判定していました。 (この事例についてはエラー対応を入れて解決したが…) 今後のモデルではどうなるかはわかりませんが、まだこういった事例が発生する のでAIでのテスト結果のチェックは必要 です。 そのときのコストの考え方として、チェック活動にかける労力と、最初から人が テスト実行した場合の労力との比較 がありそうです。 ©MIXI 26
27. 発⾒した不具合例 ©MIXI
28. 不具合発⾒例 テスト項目の期待結果 「注目！」「絶級」「未クリア」「すべて」ボタンが表示 されていること 実機 「注目！」「絶級」「未クリア」「すべて」のうち、「絶 級」「未クリア」「すべて」は表示されている一方、 「注目！」ボタンが表示されておらず、代わりに 「コラボ」が表示されているため、期待結果を満た していない。 ※ここは仕様変更があった場所で、テストケース側が新仕様用 に書き換えられていなかった。しかし 期待結果との相違を見つ けられている。 ©MIXI 28
29. 不具合発⾒例 (※モンスト以外) 以下のような現象がアプリにあったのです が、それを発見しています。 AとB、2つの設定項目がある。 Bの項目を先に設定しなければ、 Aは何を設定して も「なし」と表示される。 実機 繰り返し設定で「毎日」を選択していたは ずなのに、戻り先の「繰り返し」項目が 「なし」と表示されており設定が反映され ていないため不整合 ©MIXI 29
30. 不具合発⾒例 (※モンスト以外) 実際に人のテストで見逃されており、この ツールで発見できた問題です X画面からY画面に遷移し、再度 X画面に戻ると、 X 画面のタイトルが Y画面のタイトルになっている 実機 話しかけ設定追加画面のUIが表示され ている一方で、ヘッダーのタイトルが「繰 り返し設定」のままになっており画面状 態が矛盾している。 ©MIXI 30
31. 既存のUI⾃動テストから⾒た このテスト実⾏AIエージェントの メリット & デメリット ©MIXI
32. このAIエージェントのメリット テスト実装コストの大幅削減 既存の手動用テストケース使ってテスト意図を 満たすテスト実行が可能。 ロケーターを探す、全ステップをコーディング する必要がない。 テスト修正コストの大幅削減 AI判定のため、UI変更や表示タイミングの調 整が不要 で、テスト意図を満たすテスト実行が 可能。 ©MIXI 32
33. このAIエージェントのメリット 新規実装部分に対しての 早い段階からのテスト実行可能 ©MIXI これまではリグレッションテストがメイン。理由 は開発中にスクリプトを組むと作り直す可能性 が高かったため。 このツールは、修正コストを抑えられるため、 開発初期時からのテスト可能。 その際はユースケーステストなど粗い粒度で 行うと良さそう です。 33
34. このAIエージェントのデメリット テスト結果分析時間の増大 トークン使用料がかかる ©MIXI AI作業のため、結果を人間が意図通りのテス ト実行がされたか確認する必要 がある。 ここは、リスクがある場所はAIテストを使わな いといった戦略や、人が手動実行した場合のコ ストとの比較で考える、などがある。 AI作業のため、トークンに応じて費用がかか る。 ホーム→ウェルカムクエストその１クリア→ホー ムまでは1.02ドル(163円)。 1Step(検証含む)あたり0.06ドル (約10円) 34
35. テストの戦略例 ©MIXI
36. テスト実⾏の戦略例 (リスクベースド) 問題発生時のダメージが大きく (リ スクが高い )、周辺を含めた詳細 なテスト実行が必要 人によるテスト実行 問題発生時のダメージが大きく (リスクが高い )、明確な手順と期 待結果に沿った繰り返しテスト実 行が必要 スクリプトを用いた自動テ スト実行 問題発生時のダメージが大きくな く、リスク受容できる範囲でのテス ト実行 AIを用いた自動テスト実行 ©MIXI 36
37. まとめ ©MIXI
38. まとめ 🟩結論 • 手動テストケースを資産のまま、VLMでそのまま実行できる。実際のテスト 102件で 85.2%が意図通りに動作した。 • ただしAIは万能ではなく、「人・スクリプト・ AI」をリスクに応じて使い分けるハイブ リッドが現実解。 🟩実践する人への Tips（失敗分析より） • 前提条件は暗黙知になりがち。整える手順を明文化する（または知識として与える） • 「任意のガチャ」「人なら当然こう見る」など、暗黙の例外・意図も書き下す 🟩運用上の注意 • AI実行では判定理由が出るレポートが最重要。結果はAI任せにせず人が確認する • チェックの労力と、最初から人が実行する労力を天秤にかけて採用範囲を決める ©MIXI 38
39. ©MIXI
40. Appendix ©MIXI
41. 失敗した設計 Codex Appなど、既存のエージェントループを含むアプリで実現を試みました。 サブエージェントでDriverとAssertionを分けて実行しました。 現状のツールではウェルカムクエストその１は 4分程度で終わるのですが、 Codex Appでの実行では 33分かかりました。 画像の認識が非常に重いように見えています。 Codex App 画像 サブエー ジェント Driver (操作部) adb 操作命 令 ©MIXI サブエー ジェント Assertion (検証部) 41
42. ©MIXI