LLMを使うと、自然言語の指示からAndroid向けの操作フローをかなり速く作れるようになります。たとえば、アプリを開く、特定画面まで移動する、テキストを確認する、スクリーンショットを残す、条件によって分岐する、失敗したら停止する、といった作業は、多くのQAチームや運用チームにとって日常的です。毎回ゼロから手で組むより、プロンプトから下書きを作れるなら効率は上がります。
ただし、LLM生成のワークフローには落とし穴もあります。モデルはそれらしい手順を作れますが、実際の端末状態、package id、画面サイズ、利用可能なテンプレート、OCR対象、ロケール、アカウント条件、読み込み時間までは自動的に知りません。そこを曖昧にしたまま実行すると、「なぜ失敗したのか」が見えにくいブラックボックスになります。
自分がAndroid自動化で現実的だと思う流れは、次の形です。
- 自然言語で目的と境界を書く
- LLMにワークフローの下書きを作らせる
- Graph Viewでノード、分岐、停止条件、証跡をレビューする
- 実機またはエミュレータで小さく実行する
- スクリーンショット、OCR、ログを見て調整する
この考え方は、LaiCaiのメイン記事でも詳しく説明しています: LLM Generated Android Workflows with LaiCai Flow Graph View。
プロンプトは「作業内容」だけでなく「境界」も書く
悪いプロンプトの例は、「ログインをテストして」です。人間なら文脈で補えますが、自動化フローとしては情報が足りません。開始状態はどこか、どのアプリか、テストアカウントは承認済みか、環境は本番かstagingか、成功条件は何か、何を証跡として残すか、失敗時にどこで止めるかが不明です。
よりよいプロンプトは、次のように境界を含みます。
準備済みのAndroidテスト端末でstagingアプリを開き、承認済みQAアカウントでログインし、ホーム画面を待ち、アカウント名が表示されていることを確認し、スクリーンショットを保存し、期待テキストが見つからなければ停止してログを残す。
この程度まで書くと、LLMは「なんとなく操作する」よりも、レビューしやすいワークフローを出しやすくなります。用途も明確です。これはQAのための許可されたチェックであり、プラットフォーム規約の回避、偽装エンゲージメント、スパム、個人データの取得、ゲームの不正操作ではありません。Android自動化では、この境界を最初に書くことが重要です。
Graph ViewはLLM生成フローのレビュー面になる
LLMが作った結果が見えないスクリプトだけだと、レビューが難しくなります。Graph Viewのような視覚的な表現があると、どのノードでアプリを開くのか、どこで待つのか、どのOCRやUI解析を使うのか、どこでスクリーンショットを撮るのか、どの条件で分岐するのか、失敗時にどう止まるのかを確認できます。
Androidワークフローをレビューするとき、自分は次の点を見ます。
- 開始状態が実際の端末状態と合っているか
- app.open相当の処理が推測ではなく確認済みのpackage idを使っているか
- 画像認識、OCR、UI tree、テンプレート、モデルが実在するものか
- 画面遷移や通信のあとに明示的なwaitまたは状態確認があるか
- 重要な分岐でスクリーンショットやログが残るか
- 期待画面でない場合に安全に停止するか
このレビュー面があるから、AI Android automation toolとしての価値が出ます。重要なのは、LLMが常に正しいという話ではありません。LLMは下書きを速く作る。人間はGraph Viewで仮定を確認する。そして、実行結果を証跡で検証する。この分担が現実的です。
LLMに端末固有情報を発明させない
Android UI自動化では、小さな仮定が簡単に失敗につながります。staging版とproduction版でpackage idが違うかもしれません。ボタンの文言はロケールで変わります。初回起動だけ権限ダイアログが出ることもあります。通信が遅い端末では、500msのwaitでは足りないかもしれません。1080 x 2340のスマートフォンで成功した座標タップが、タブレットやエミュレータでは外れることもあります。
そのため、LLMには端末固有情報を推測させないほうが安全です。ワークフローの形は提案させても、package id、現在画面、利用可能なテンプレート、OCR領域、モデル、ノードスキーマは、実際の環境から取得して確認します。もし情報がないなら、フロー上に「要確認」として残すべきで、勝手に値を作るべきではありません。
これは LaiCai Flow guide のようなノードベースの考え方と相性が良いです。ノードごとに入力、待機、認識、分岐、ログ、停止条件を分けることで、生成されたフローを人間がレビューしやすくなります。
証跡は「あとで見るもの」ではなくワークフローの一部
QAや運用の現場では、自動化の結果はpass/failだけでは足りません。なぜ成功したのか、なぜ失敗したのかを後から説明できる必要があります。スクリーンショット、OCR結果、UI状態、分岐ログ、タイムスタンプ、停止理由が残っていると、レビューがかなり速くなります。
たとえばログイン確認に失敗した場合、スクリーンショットがあれば、ネットワークエラーなのか、認証エラーなのか、権限ダイアログなのか、文言変更なのかを判断しやすくなります。商品ページや設定画面のチェックでも、OCR結果と画面画像があれば、ロケール差分や読み込み遅延を切り分けやすくなります。
また、チームが実機の画面を見ながら調整したい場合、安定した Android画面をPCとMacにミラーリング する環境が役立ちます。自動化が見ている画面と、人間がレビューする画面を近づけられるからです。
AppiumやUI Automatorの置き換えではない
LLM生成のGraphワークフローは、Appium、UI Automator、単体テスト、結合テスト、スクリーンショットテスト、CIを置き換えるものではありません。これらは、コード管理された回帰テストやリリースゲートに向いています。
Graph型のAndroidワークフローが向いているのは、もう少し運用寄りの層です。QAのスモークチェック、サポートの再現手順、端末ラボの確認、複数端末での可視チェック、まだ正式なテストコードにする前の探索的な手順などです。フローが安定してから、その一部をAppiumやUI Automatorのテストに移すこともできます。
現実的には、次のように併用するのがよいと思います。
- 単体テストでロジックを守る
- AppiumやUI Automatorで主要なUI回帰を守る
- スクリーンショットテストでレイアウト差分を見る
- Graphワークフローで可視的な運用チェックやサポート再現を扱う
この分担なら、LLMは「自動化をすべて任せる存在」ではなく、「レビュー可能な下書きを作る存在」になります。
実行前チェックリスト
LLM生成のAndroidワークフローを実行する前に、最低限次を確認したいです。
- プロンプトに許可された用途と停止境界が書かれている
- Graphがサポート済みノードだけで構成されている
- アプリ起動は確認済みpackage idを使っている
- OCR、テンプレート、モデル、UI解析が実在する
- tap、swipe、waitの理由を説明できる
- 重要なチェックポイントでスクリーンショットまたはログが残る
- エラー分岐が安全に停止する
- アカウント、プライバシー、プラットフォーム規約の前提が明確
- まずエミュレータまたはテスト用端末で小さく試せる
- 実行結果を人間がレビューできる
LLMはAndroid自動化の初速を上げられます。ただし、端末を動かす前に、仮定を見える形にする必要があります。Graph Viewはそのためのレビュー面です。自然言語で意図を書き、LLMで下書きを作り、人間がGraphを確認し、実行結果を証跡で見る。この流れなら、AI支援のAndroidワークフローを現実のチーム運用に入れやすくなります。