はじめに

「テスト仕様書をそのまま渡すだけで、AIが自動でAndroidアプリをテストしてくれるとしたらどうでしょう？」

これまで、UIテストやE2Eテストの自動化にはテストコードの実装や環境構築といった大きな工数が必要でした。そのため「自動化したいけれど人も時間も足りない」という課題を抱えるチームは多く存在します。

WebアプリをAIが自動テストする AgentiTest などの AI駆動の自動テストフレームワーク が登場し、手動テストに頼らざるを得なかった領域を効率化する動きが始まっています。

本記事では、これを Android アプリに適用する取り組みとして、手動テスト用の仕様書をAIに与え、アプリ操作から合否判定まで自動化できるのかを検証しました。具体的には、試験手順と判定基準をAIに入力すると、AIがアプリを実際に操作し、結果を自動で記録・判定します。テスト実行者は、ブラウザ上でスクリーンショットやAIの操作ログを確認するだけで、試験の正当性や合否の妥当性を素早くチェックできます。

例えば以下の仕様書を与えると、AIはChromeを起動し、メニューから「New Tab」を選択、新しいタブが開いたことを確認して合否を判定します。

項目	内容
試験項目名	Chrome ブラウザ：メニュー操作による新規タブの作成
前提条件	Chrome がインストールされ、初期状態でタブが1つ開かれていること
試験手順	1. Chrome を起動する 2. 画面右上のメニューアイコン（三点リーダー）を選択する 3. 表示されたメニューから [New Tab]を選択する
判定基準	画面上部のタブバーに新しいタブが追加され、合計2つのタブが表示されていること

このように、「コードを書かなくても、仕様書だけでテスト自動化が可能になる」 という新しい可能性が見えてきています。本記事では、この仕組みを用いて どの程度コストをかけずに手動テストを自動化できるのか を調査した結果を紹介します。

Webアプリ向けAI駆動の自動テストフレームワーク はこちら

自動テストの実行例

次に示すのは、AI駆動型の自動テストフレームワークで、先ほど提示した仕様書の 「試験手順」 と 「判定基準」 をAIに解釈させ自動テストを実行した際の結果です。

試験手順:
1. Chrome を起動する" 
2. 画面右上のメニューアイコン（三点リーダー）を選択する
3. 表示されたメニューから[New Tab] を選択する
判定基準: 画面上部のタブバーに新しいタブが追加され、合計2つのタブが表示されていること

判定基準に合致する場合は、判断理由とともに {EXPECTED_STATS_RESULT} と答えなさい。

次の動作が確認できます

初期状態: ホームスクリーンが表示されています
AIがChromeを起動します
AIがメニューアイコンを選択してメニューを表示します
AIがメニューの中から [New tab] を選択して、新規タブが作成されました

実際の処理はやや時間を要するため、ここでは3倍速にして再生しています。

自動テスト結果の確認

自動テスト結果は Allure で保存されます。自動テストの結果をスクリーンショットとともに確認できるだけでなく、実行時の AI の思考過程やテストの流れも追跡できます。
そのため、AI が正しくテストを実施したか、あるいは失敗した場合に「どの時点で」「どんな理由で」失敗したのかをすぐに把握し、迅速に対応することが可能です。

Overview

自動テスト実行時のログ

Step1. 計画

テスト開始時の画面の状態が確認できます。また、AIが作成したAndroidアプリの操作プランが確認できます

Step2. 実行

作成した計画に従ってAIがAndroidアプリを操作したログが確認できます
AI が appium_activate_app という、appium の機能を呼び出して Androidアプリを起動するツールを利用して、Chromeを起動したことが確認できます

Step3. 再計画

Chromeを起動した後の画面の状態が確認できます。
また、Chromeが起動した状態で、次にAIが作成したテスト実施のための再計画が確認できます。
次に、「メニューアイコンをタップする。」計画となっています。

Step7. 再計画

テスト計画の合否判定基準に基づき、AIが２つのタブが表示されていることを確認しています。この判定に基づき、EXPECTED_STATS_RESULT (all_status_visible) を回答に含めています。

Step8. テスト合否判定

実行したテストは、ASSERT, ERROR, EXCEPTION を発生させることなく最後まで実行され、 EXPECTED_STATS_RESULT を含む文字列を返しました、したがって、このテストは合格として判断されました。

AI駆動の自動テストフレームワークの実装例

ここからは、実際に AI駆動の自動テストフレームワーク がどのように動くのかを、構成とコードの両面から確認します。ソースコードは下記で公開しています。

ソースコードの全体像

フレームワーク全体は、AIが計画を立てて実行し、必要に応じて再計画するという流れを中心に構成されています。

AI×自動テストの融合

このフレームワークの中心は TestAgent クラスです。
TestAgent は Plan-and-Execute 型のエージェント をラップし、StateGraph によって 「プランニング → 実行 → 再計画」 のワークフローを制御します。つまり、人が手順書どおりに操作する代わりに、AIが自分で考えて実行し、必要なら計画を修正します。

ワークフロー構築部分

以下は、エージェントのワークフロー（グラフ）を組み立てる際の“骨格”です。
どのノードで何をして、どのタイミングで終了するかを定義しています。

workflow = StateGraph(PlanExecute)
workflow.add_node("planner", plan_step)
workflow.add_node("agent", execute_step)
workflow.add_node("replan", replan_step)
workflow.add_edge(START, "planner")
workflow.add_edge("planner", "agent")
workflow.add_edge("agent", "replan")
workflow.add_conditional_edges("replan", should_end, ["agent", END])
graph = workflow.compile()

planner：plan_step で初期プランを生成
agent：execute_step でプランの最初のステップを実行
replan：replan_step で進捗や失敗に応じて再計画
should_end：終了判定（続行か終了かを条件分岐）

各ステップの簡略コード

各ノードは小さな非同期関数として実装され、計画 → 実行 → 再計画 がシンプルに循環します。

async def plan_step(state):
    # Generate a step-by-step plan for the given goal
    return {"plan": ["step1", "step2"], "replan_count": 0}

async def execute_step(state):
    # Execute the first step in the plan and record the result
    return {"past_steps": [("step1", "result1")]}

async def replan_step(state):
    # Replan remaining steps based on progress or errors
    if state["replan_count"] > 5:
        return {"response": "再計画回数制限"}
    return {"plan": ["step2"], "replan_count": state["replan_count"] + 1}

TestAgentの動作概要

TestAgent がタスクを受け取ってから応答を返すまでの流れは次のとおりです。
この一連のループで、「計画 → 実行 → 再計画 → 終了」 まで自動で進みます。

タスク受領：TestAgent.validate_task() でテストタスクを受け取る
ワークフロー生成：agent_session() で graph を生成
順次実行：graph.astream() でワークフローを逐次実行
- plan_step で計画
- execute_step で実行
- replan_step で必要に応じて再計画
- should_end で終了判定
応答返却：最終的な応答（response）が得られるまで継続

アーキテクチャ概要

フレームワークは次の 3層構造 で設計されています。

エージェント層
- TestAgent / SimplePlanner が計画と実行の中心
ツール層
- Appium モバイルアプリを自動操作するためのフレームワーク
- Jarvis-Appium (Appium MCP クライアント) で実デバイス操作を制御
AI層
- OpenAI の GPT モデルを用いてテスト計画やアクションを推論

この分離により、AIの意思決定 と デバイス操作 を疎結合に保ち、交換可能な形で拡張できます。

テスト自動化の実装技術

このフレームワークを支える主要技術は以下のとおりです。

pytest
- 非同期コードのテスト
- マーカーによるカテゴリ分け
- CI/CD での自動実行
Allure
- スクリーンショットやログの自動添付
- 実行履歴をリッチに可視化
Jarvis-Appium
- MCP クライアントを通じて Android アプリ操作を柔軟に制御
- LLM からの操作指示を実デバイスに橋渡しする役割を担う

メトリクスと可観測性

実運用で効くのは 「見える化」 です。
このフレームワークでは、失敗時の原因追跡や改善サイクルを回しやすくするための可観測性を備えています。

処理時間計測：各ステップの実行時間を Allure に添付
詳細なログ：UI 要素、スクリーンショット、テキスト出力を記録
パフォーマンス分析：ボトルネックを可視化し、改善を容易に

まとめ

本記事では、「手動テスト用の仕様書をAIに与えるだけでAndroidアプリの自動テストが可能か」 というテーマで検証を行いました。

従来の課題
UIテストやE2Eテストはコード実装や環境構築に大きな工数がかかり、チームの負担になっていました。
AIによる新しいアプローチ
テスト仕様書を入力するだけで、AIが実際にアプリを操作し、合否を自動判定。スクリーンショットや操作ログも自動で記録され、ブラウザ上で簡単に確認できます。
実装のポイント
TestAgent を中心にした Plan-and-Execute 型ワークフロー を採用し、Appium・pytest・Allure といった既存ツールと組み合わせることで、柔軟かつ透明性の高いテスト自動化を実現しました。
検証結果
実際のテストでは、仕様書通りに Chrome の新規タブ作成を自動で実行し、判定基準に基づいて正しく合否を判断できました。

今回の取り組みは、「コードを書かずに仕様書だけで自動テストを動かす」 という未来の可能性を示すものです。まだ発展途上ではあるものの、チームの負担を減らし、小規模でも品質保証を実現できる強力な手段になり得ます。

冒頭で問いかけた 「テスト仕様書をそのまま渡すだけで、AIが自動でアプリをテストしてくれる世界」 は、すでに現実に近づいていると言えるでしょう。

今後の展望

AI駆動の自動テストはまだ発展途上ですが、

テスト設計者がコードを書かずに自動化できる
テスト実行後の検証や不具合特定をスピードアップできる
小規模チームでもコストを抑えて品質保証が可能になる

といった大きな利点があります。

今後は、より複雑なフローや多様なアプリに対応できるか、また実運用でどこまで信頼できるかを検証することが重要です。それでも、今回の取り組みは 「AIとテスト自動化の融合が現実的になりつつある」 ことを示す有意義な一歩となりました。