Apr 20, 2026

Android CLI スキルで Claude Code が UI テストを自動実行できるか検証してみた

はじめに

Android CLI という、Android 開発支援スキルを検証しました。スキルをインストールすることで、他AIがエミュレーターの操作・UI テスト・ドキュメント検索などを自律的に行えるようになります。
今回は Claude Code で検証しました。

Android CLI スキルとは

Claude Code にはスキルという仕組みがあり、外部からインストールすることで専門的な操作手順を追加できます。 Android CLI スキルをインストールすると、以下のようなコマンドが使えるようになります。

コマンド	概要
`android emulator start <AVD名>`	エミュレーターを起動（起動完了まで自動待機）
`android run`	アプリをデバイスにデプロイ・起動
`android screen capture`	スクリーンショット取得
`android screen capture -a`	UI 要素にラベルを付きでスクリーンショット取得
`android screen resolve`	ラベル番号から adb タップ座標を自動生成
`android layout --pretty`	UI ツリーを JSON 形式で取得
`android docs search`	Android 公式ドキュメントを検索

Journey テストとは

スキルの references/journeys.md に、AI エージェントが UI テストを自動実行するための仕様が記述されています。テストケースは XML で自然言語のステップとして書くだけでよいです。

<journey name="出勤打刻テスト">
  <description>
    「開始」ボタンをタップし、履歴画面で出勤時刻が記録されることを確認する
  </description>
  <actions>
    <action>タイムカード画面が表示されていることを確認する</action>
    <action>「開始」ボタンをタップする</action>
    <action>画面右上の一覧ボタン（リストアイコン）をタップする</action>
    <action>履歴一覧画面に遷移し、出勤時刻（HH:mm形式）が表示されていることを確認する</action>
  </actions>
</journey>

AI がスクリーンショットを見ながら adb でタップ操作を行い、各ステップの成否を判定・レポートします。 Espresso などの従来の UI テストフレームワークと異なり、コードを一切書かずに自然言語だけでテストが書けます。

実際に動かしてみた

社内開発中の Android アプリ（勤怠管理アプリ）で試しました。

つまったポイント

① 実機とエミュレーターが混在すると android screen capture が実機側を撮影する

android screen capture はデバイス指定オプションがないため、エミューレーターと実機の2台を認識している状態では、実機のスクリーンショットが取れてしまいました。
実機を外すことで解決しましたが、開発中は実機を繋ぎっぱなしにすることが多いため、デバイス指定ができるとより便利になると思います。

② ボタン座標の特定

最初はスクリーンショットから目視で座標を推測してタップしていましたが、うまく当たらないことがありました。 android screen capture -a（アノテーション付きスクリーンショット）を使うと、UI 要素にラベル番号が付与されます。そのラベル番号を android screen resolve に渡すと、正確な adb タップコマンドを自動生成してくれました。

# アノテーション付きスクリーンショットを撮る
android screen capture -a -o /tmp/annotated.png

# ラベル 13 の要素のタップコマンドを生成
android screen resolve --screenshot=/tmp/annotated.png --string="adb shell input tap #13"
# → adb shell input tap 880 226

この仕組みが非常に便利で、座標を人間が調べる手間がなくなります。

テスト結果

{
  "journey": "出勤打刻テスト",
  "results": [
    { "action": "タイムカード画面が表示されていることを確認する", "status": "PASSED" },
    { "action": "「開始」ボタンをタップする", "status": "PASSED" },
    { "action": "画面右上の一覧ボタン（リストアイコン）をタップする", "status": "PASSED" },
    { "action": "履歴一覧画面に遷移し、出勤時刻（HH:mm形式）が表示されていることを確認する", "status": "PASSED" }
  ]
}

全ステップ PASSED。履歴画面に「11:37」として出勤時刻が正しく記録されていることを確認できました。

所感

UI テスト自動化の課題が解消されるかもしれない

UI テストは実装コストが高く、アプリの変更のたびにテストが壊れてメンテナンスが大変というのが長年の悩みでした。今回の Journey テストは自然言語で書けるため、レイアウトが多少変わっても AI が視覚的に判断して操作できます。 Espresso のように View の ID やクラス名に依存しないので、壊れにくいテストが書けそうです。

なお、android layout --pretty は UI ツリーを JSON で返すため、人間がデバッグで使うには情報量が少ない印象です（adb dumpsys の方が詳細です）。ただ AI にとっては構造化された JSON の方が扱いやすく、スクリーンショットと組み合わせることで素早く UI 要素を特定できます。このスキルは人間が直接使うツールというより、AI エージェントが Android を操作するためのインターフェースとして設計されていると感じました。

docs 検索機能も注目

もしかすると docs 検索機能の方が重要かもしれません。その時々の Google 推奨の実装方法を、低コストで参照できるということだと思います。Journey テストよりも日常的に使う機会が多そうです。

スキルは https://github.com/android/skills からダウンロードできるようです。

おわりに

このスキル、開発者が使うよりも AI エージェントが使ったときに強く効果を発揮すると感じました。
良い結果が出たので、Gemini CLI でどうなるか、後日検証しようと思います。