Google I/O Extended 2026の資料になります。
現状、コーディングエージェントの普及により、普通のコーディングをAIにさせるところまではかなりの割合で開発者の方が進められているのではと思っています。
そこから、もう一歩進んだことができるツールも出てきています。例えば、この発表で出てくる Android Skills を使うと、Android関連の最新の専門性が必要になる作業なども含めて、もっとさまざまなことをAIに任せていけるようになってきています。
この記事では自分が確認していった中から、業務の中で利用すると効率的で高品質なアプリを作るのに役立つツールたちを紹介していきます。

間違っているところがあれば教えてください。

この記事の構成

Androidの開発環境ではAIが使えたり、AIから使える機能がたくさんあります。

こちらにだいたい全てを書いておきます

（全体像を眺める用の表です。この記事で扱うものはあとで個別に説明するので、読み飛ばして大丈夫です）

	普段の開発（作業を助ける）	クオリティをあげる
Android Studio（Agent Mode含む）	Agent Mode / Planning Mode / Next Edit Prediction / Changes Drawer / review this code / 複数スレッド並列 / sandbox・権限 / .aiexclude / model providers（ローカルGemma 4等） / MCP対応 / AGENTS.md対応 / Rules / analyze current file / Logcat Ask Gemini / Logcat自動Retrace / Compose Preview AI Actions / Generate Compose Previews / PreviewエラーAI修正 / デバイス操作・Screenshot / App Links Assistant / Create with AI / Publish for Testing（Playテストトラックへ公開） / Journeys / ユニット・Espressoテスト生成 / Screenshotテスト生成	R8 Configuration Analyzer / Profiler / LeakCanary / App Quality Insights / 依存関係の自動更新 / Migration Assistant / Views→Compose移行
Android Skills	android-cli	testing-setup / migrate-xml-views-to-jetpack-compose / navigation-3 / edge-to-edge / adaptive / camera1-to-camerax / agp-9-upgrade / play-billing-library-version-upgrade / styles / jetpack-compose-m3（Wear OS） / r8-analyzer / perfetto-sql / perfetto-trace-analysis
Android CLI	android (create\|describe\|docs\|emulator\|info\|init\|layout\|run\|screen\|sdk\|skills\|update) ／ android studio (analyze-file\|check\|find-declaration\|find-usages\|open-file\|render-compose-preview\|version-lookup)	（品質専用のコマンドはほぼ無し。Skills導入やStudio連携の入口にはなる）
他（Antigravity / AI Studio / Gradle）	AntigravityのAndroid Support / Google AI StudioのAndroid Support / Lightbuild（trusted testers限定）	（ほぼ無し）

※ 一部の機能は Android Studio のバージョンやチャンネル（Canaryなど）、AGPのバージョン、Studio Labs の設定に依存します（例: Journeys は Studio Labs の機能で AGP 9 以上が必要）。2026-06時点の情報です。

今日は試して便利だった一部のものを紹介する形で、ブログの構成はこんな感じになってます。

大きな基盤となるツールたち

個別の機能に入る前に、これから何度も出てくるツールたちを、公式の説明を引用しつつ先に紹介しておきます。

Android Studio の Agent Mode

Android Studioの機能をツールとして呼び出すことができる、Android Studioのコーディングエージェントです。
呼び出せるツールには、lint・インスペクション、Compose Preview、コードの参照検索（find-usages / find-declaration）などがあり、書いた変更をビルド前に確認しながら進められます。

公式ドキュメントの説明はこうです。

You can describe a high-level goal, and the agent creates and executes a plan, invoking the necessary tools, making changes across multiple files, and iteratively fixing bugs.

（出典: Agent Mode 公式ドキュメント）

Agent Modeが使えるツール一覧（/tools で取得）

Agent Modeで /tools というスラッシュコマンドを実行すると、そのとき使えるツールの一覧が見られます。以下は手元のAndroid Studio（Quail 3 | 2026.1.3 Canary 3）で取得したものを機能別に整理したものです。バージョンや設定で変わると思います。

ファイル操作・編集

read_file / write_file / replace_file_content / multi_replace_file_content — ファイルの読み書き・置換
list_files — ディレクトリ内のファイル一覧
view_file_outline — ファイルの構造（アウトライン）を表示

コード・リソース検索

find_files — ファイル名・パスで検索
find_declaration / find_usages — シンボルの定義場所・使用箇所を意味解析で探す
grep / code_search — パターン検索・コードベースのインデックス検索

ビルド・プロジェクト構造

gradle_build / gradle_sync — Gradleタスクの実行・プロジェクトのSync
get_top_level_sub_projects / get_build_file_location / get_gradle_artifact_from_file / get_source_folders_for_artifact / get_artifact_consumers — サブプロジェクトやモジュール構造の取得
get_assemble_task_for_artifact / get_test_task_for_artifact / get_test_artifacts_for_sub_project — ビルド・テストのタスクや対象の特定
version_lookup — 依存ライブラリなどの最新バージョン調査

静的解析・検証

analyze_file — エディタのinspectionでエラー・警告をチェック
render_compose_preview — Compose Previewをレンダリングして画像とUI階層を返す

デバイス操作・デバッグ

deploy — アプリをデバイスへデプロイ（WearOSのTileなども）
read_logcat — Logcatのログを取得
adb_shell_input / take_screenshot / ui_state / wait_tool — 画面操作、スクリーンショット、表示中のUI階層取得、待機
run_journey — 一連のUI操作テスト（Journey）を実行

ドキュメント・Web

search_android_docs / fetch_android_docs — Android Knowledge Base（公式ドキュメント）の検索・取得
web_search / read_url — Web検索とページの読み取り

その他

run_shell_command — シェルコマンドの実行
task — サブエージェントにタスクを依頼
set_plan_state — 計画（Planning Mode）の状態遷移を報告
ask_user — ユーザーに選択肢を提示して質問

Gradleのプロジェクト構造をピンポイントで引く get_* 系がけっこう充実しているのと、ui_state で画面のUI階層をテキストで取れるのが面白いところです。MCPサーバーを設定していれば、そのツールもここに追加されるようです。

Android CLI

Android開発用のコマンドラインツールです。
プロジェクト作成、ビルドと実行、エミュレータや実機の操作、SDK管理などが android というコマンドからでき、gitのようにサブコマンドを持ちます。
Android Studioがなくても動くので、AntigravityやClaude Code、Codexのような好きなエージェントからも使えます。
さらに android studio サブコマンドを使うと、起動中のAndroid Studioに接続して、その機能を外から呼べます。

公式ドキュメントの説明はこうです。

Android CLI is a command-line interface that enables you to more easily and efficiently build for Android using any tool of your choice.

（出典: Overview of Android CLI 公式ドキュメント）

そして Google I/O '26 で 1.0（stable）になりました。いま紹介した android studio サブコマンドは、この 1.0 で新しく入ったものです。ほかにも Journeys のサポートや skill の拡充が入っていて、単なる安定版化ではなく「エージェントから使える道具を増やす」リリースになっています。Android CLIの公式ブログにはこう書かれています。

...our mission is to ensure that high-quality Android development is possible everywhere.

（出典: Android CLI and skills 公式ブログ）

Gemini in Android Studioでも、Claude CodeやCodexのようなサードパーティのエージェントでも、「どこでも高品質なAndroid開発ができるようにする」のが使命とのことです。

インストールは Android のエージェント向けツール（公式）から。最近は Homebrew・apt-get・winget にも対応しました。Homebrew ならこれだけです。

brew tap android/tap
brew trust android/tap
brew install android-cli

インストールしたら、あとは以下を実行しておきます。android init を実行すると、エージェントが必要なときに Android CLI の使い方を参照できるようになります（これは skill という仕組みで実現されていて、すぐあとで説明します）。この初期セットアップさえしておけば、あとはAIがうまくAndroid CLIを使ってくれると思います（Android CLI 公式ドキュメント）。

android update # アップデート
android init # android-cli skillのインストール

Agent Skills（そもそもの仕組み）

次に紹介する Android Skills の土台になっている仕組みで、skill 自体は Android 専用ではなく、「特定の作業のやり方をエージェントに教える指示書」の共通フォーマットです。

実体は「SKILL.md という指示書ファイルを入れたフォルダ」です（Agent Skills Overview (agentskills.io)）。
エージェントは普段、各 skill の description（どういうときに使うか）の一覧だけを見ていて、頼まれたタスクがそれに合ったときだけ中の指示書を読み込みます。
毎回プロンプトでやり方を説明する代わりに、必要なときだけ読まれる手順書を置いておける、というのがポイントです。
元は Anthropic が作ってオープン標準になり、Claude Code / Codex / Gemini CLI / Cursor / VS Code など多くのツールが対応しています。
Claude Code などで普段 skill を使っている人は、それと同じものです。

Android Skills（Androidの作業版）

その仕組みに乗せて、Androidの特定作業のやり方をまとめた skill を公式が用意したものが Android Skills です（XMLからComposeへの移行、R8、Perfetto など）。

GitHubで内容は公開されているので、自分で見ていくことが出来ます。

公式ドキュメントの説明はこうです。

Android skills are AI-optimized instructions, to help AI tools and agents better understand and execute specific patterns that follow best practices and guidance on Android development.

（出典: Overview of Android skills 公式ドキュメント）

Android Studioにバンドルされていて、Android CLIからも導入できます。

どんなものがあるか、種類ごとに一言ずつ。（一覧は2026-06時点の `android skills list`、分類と一言は自分でまとめたものです）

移行 / 近代化

migrate-xml-views-to-jetpack-compose — XMLレイアウトを候補選定→計画→変換→Preview比較の手順で1枚ずつComposeへ移行
navigation-3 — Navigation 2→3移行の手順＋deep link / scene / 複数backstack / Hilt連携などのレシピ集
camera1-to-camerax — Camera1/2の自前実装を、依存追加〜旧コード削除〜撮影〜前後切替までCameraXへ移行
agp-9-upgrade — 非KMPプロジェクトをAndroid Gradle Plugin 9へ。built-in Kotlin / kapt→KSP / gradle.properties掃除＋sync検証
play-billing-library-version-upgrade — 古いPlay Billingを検出し、非推奨API（SkuDetails等）を刷新して最新版へ

UI / Compose

edge-to-edge — Composeアプリのedge-to-edge化。Activity検出〜insets適用〜IME / システムバー対処まで
adaptive — UIを端末サイズ別に適応。ナビをNavigationSuiteScaffold、画面をNav3 Sceneの複数ペイン、リストを可変列Gridに
styles — 自作Composeの色/形ハードコードを実験的なStyles API（Modifier.styleable）へ移行（Material製は対象外）
jetpack-compose-m3 — Wear OS の Compose Material3 移行（AppScaffold等）。Material2.5 / Horologistから

品質 / 性能

r8-analyzer — R8のkeepルール/設定を解析し、冗長・広すぎるルールを洗い出してサイズ削減レポートを出す（9.3.7-dev以降は定量化）
perfetto-trace-analysis — Perfettoトレースを仮説→SQL→検証ループで掘り、遅延/jank/メモリの根本原因を特定
perfetto-sql — 自然文の分析意図からPerfetto SQLを組み立て、trace_processorで実行・抽出

検証 / テスト

testing-setup — 既存の依存/テスト構成を解析し、DI / ユニット / UI / スクショ / E2E / カバレッジを一通り整備

CLI / 環境

android-cli — androidコマンド一式（create / sdk / emulator / run / screen / layout / docs / studio）をエージェントから叩く土台

連携 / AI

appfunctions — アプリの操作をAppFunctionsとしてシステムに公開（Kotlin生成/KDoc調整/ADB検証）。UIなしでエージェントから呼べる
engage-sdk-integration — Play Engage SDKをvertical別に組み込む（Converter/Worker/Publisher等の雛形〜設定）
verified-email — Credential Managerの検証済みメール取得（OpenID4VP / SD-JWT）をOTPレスで実装

XR

display-glasses-with-jetpack-compose-glimmer — Android XRのディスプレイ眼鏡向けUIをJetpack Compose Glimmerで作る手順＋デザイン規約
display-ai-glasses-with-jetpack-compose-glimmer — Display AI Glasses向けの投影UI（黒背景必須・GlimmerThemeなどの作法込み）

この記事では全部は紹介しきれないので、実際に触って良かったものをピックします。

入れ方は android skills 配下のサブコマンドで、探して入れるだけです。

android skills list              # 使えるskillの一覧
android skills find r8           # キーワードで探す
android skills add r8-analyzer   # インストール

ちなみに、最初のセットアップで実行した android init との違いはこうです。

android init：基本の android-cli skill（Android CLI自体の使い方をエージェントに教える）を導入
android skills add：r8-analyzer のような作業ごとのskillを個別に追加

--agent=claude-code で対象のエージェントを、--project=<path> で入れたいプロジェクトを指定でき、指定したエージェントの設定（例: .claude/skills/）に展開されます。Android Studio の Agent Mode には最初からバンドルされているので、Studio内で使う場合はこの手順自体が不要です。

Antigravity / Google AI Studio など

Android Studioの外側にも、エージェントでAndroid開発をする入り口が増えています。

Antigravityは、editor / terminal / browser をまたいで、エージェントが自分で計画して実行して検証するプラットフォームです（Build with Google Antigravity 公式ブログ）。
I/O 2026では、Antigravity 2.0でAndroid CLIによるAndroid開発が公式サポートされました（What's new in Android Developer tools 公式ブログ）。

Google AI Studioも、プロンプトからAndroidアプリを生成して、埋め込みのAndroid Emulatorですぐプレビューし、USB接続の実機へADBでデプロイするところまでできるようになっています（同じく上のWhat's newブログより）。

この中で、開発の中で個人的に使えそうなものを、「普段の開発を助けるもの」と「普段の開発から外れた改善タスクで使えるもの」に分けて、ピックして紹介していきます。

普段の開発で使えるもの

普段の開発は、だいたい「コードを調査して、実装して、警告をチェックして、UIを確認して、端末で動かして確認する」というループの繰り返しだと思います。

実装そのものはエージェントに任せるとして、その前後のステップを支えるツールを、このループの順番で紹介していきます。いまどのステップの話かは、各節の頭の図のハイライトで示します。

find-usages / find-declaration

（Agent Mode / Android CLI）

なぜ便利か
エージェントがコードを読むとき、grep で呼び出し元を一つずつ辿っていくと、関係ない同名のヒットまで引っかかって、コンテキストを無駄に使ってしまうことがあります。

これは何
android studio の find-usages / find-declaration は、起動中のAndroid Studioのインデックスを使って、意味ベースで探してくれます。

使ってみた
使い方はこんな感じです（--project で対象を指定。開いているプロジェクト名は android studio check で分かります）。
今回は公開サンプルの nowinandroid で試してみました。

find-declaration は、定義の場所（ファイルと行番号）と、その前後のコードまで返してくれます。

$ android studio find-declaration --project=nowinandroid NiaAppState
/.../nowinandroid/app/src/main/kotlin/.../ui/NiaAppState.kt
Line: 69
Context:
@Stable
class NiaAppState(
    val navigationState: NavigationState,
    coroutineScope: CoroutineScope,
    networkMonitor: NetworkMonitor,
    ...
)

find-usages は、使われている場所を main も test もまたいで列挙してくれます（--short で場所だけ）。

$ android studio find-usages --project=nowinandroid --short NiaAppState
.../ui/NiaAppState.kt:59
.../ui/NiaApp.kt:91
.../ui/NiaApp.kt:142
.../ui/NiaAppStateTest.kt:84
.../ui/NiaAppStateTest.kt:128
.../ui/NiaAppStateTest.kt:148

触ってみて
面倒なポイントは、Android Studioを開いておく必要があるのと、コード検索のときに grep ではなくこのコマンドを優先して使うようAIに教える必要があるところです（android init で入る skill は Android CLI 全般の案内なので、この用途への寄せまでは効かない気がしています）。
大したことはない簡単なAgent Skillにはなりますが、その用途向けに android-cli-code-skill を用意したので、読み込ませてみるとAIが使ってくれるはずです。

ちなみに、多分競合はLSP (Language Server Protocol) だとは思っています。LSPは、定義ジャンプや参照検索のようなコード解析をエディタが言語サーバーに任せるための標準プロトコルで、エージェントに同じ能力を持たせる手段としても使われています。JetBrains公式の Kotlin LSP が今年のKotlinConfで Alpha になっていて、Claude Codeだと公式プラグインで入れられます。手元で試したら、シンボル一覧の取得はすぐ動きました。
ただ、KMPプロジェクト（roborazzi）で expect / actual の解決を比べてみたら、Studio連携は find-usages が source set をまたいで16箇所見つけ、find-declaration は iosMain の actual まで辿れたのに対して、Kotlin LSPは同じファイル内の2件しか見つけられず、actual の解決もできませんでした（入れた日に軽く試しただけなので、インデックスやセットアップの問題の可能性もあります）。README にも、Android Gradle Pluginサポートはexperimental、KMP対応はこれから、と書かれています。
現時点だとAndroid / KMPまわりはStudio連携のほうが強そうですが、どちらも出てきたばかりです。grepではなく「コードの構造を分かった上での検索」をエージェントに渡す選択肢が、急に増えてきた感じがします。

analyze current file / analyze-file

（Agent Mode / Android CLI）

なぜ便利か
AIにコードを書かせると、ビルドさえ通れば警告は見られないまま進みがちです。
レビューもPRでしか見ない人が多いので、エージェントが書いたコードには警告が溜まっていきやすい気がします。
analyze-file は、Android Studioが普段エディタ上で出している警告やエラー（lint / inspection）を、ビルド前にそのまま拾えるツールです。

使ってみた
android studio analyze-file <ファイル> で、そのファイルへの指摘を一覧で取れます。
nowinandroid の NiaAppState.kt にかけてみると、こんな WARNING が出ました。

$ android studio analyze-file --project=nowinandroid .../ui/NiaAppState.kt
WARNING
line: 115
message: This method should only be accessed from tests or within private scope

「テストか private からしか触らないで」という可視性の指摘で、ビルドは通るけど直しておきたいやつです。
（先ほど紹介した find-declaration で辿ると、currentKey の @VisibleForTesting をファイル外から呼んでいたのが原因でした）

Agent Mode では、これと同じ inspection が書き込みの前後に自動で走ります。I/O のセッションで file critic と呼ばれていた内部の仕組みで、「lint と合わせて 3,000 近い inspection が、すべてのファイル書き込みの前後で走っている」と説明されていました。

エラーだと、こんな感じで返ってきます。

File was written, and introduced 2 errors.
Line 226: Error: Unresolved reference 'getNonExistentMemoryStats' ...

警告でも同様に、未使用変数のような指摘がその場で返ってきました。

This change introduced 2 warnings
Line 83: Property "unusedVariable" is never used
Line 83: Unused variable

エラーも警告も自動で拾ってくれるので、Agent Mode の中では file critic のチェックがかなり手厚い印象です。

触ってみて
ビルド前に静的に警告やエラーを確認できるので、増えがちな警告を増えないようにメンテしたり、エラーを効率的に処理できます。
Agent Modeではこのチェックが勝手に走りますが、他のエージェント（AntigravityやClaude Codeなど）にも Agent Hooks と呼ばれる、「ファイル編集の直後」のようなタイミングで任意のコマンドを自動実行できる仕組みがあります。ここに analyze-file を差し込むと、エージェントが編集するたびにビルド前のエラーチェックが走り、ビルドを待つより時短になりますし、コンテキストの節約にもなります。
編集後にエラーだったときにエージェントに知らせるHooksの例をリポジトリとして置いておきます。

render-compose-preview

（Agent Mode / Android CLI）

なぜ便利か
これを使うとPreviewの画像と、そのUIツリーが取れます。
UIを作っていて「ここに変なマージンが入っちゃってる」みたいなとき、ライブラリの中のComposableなどだとマージンがどこで入っているのかコードからは分かりにくいので、それをAIに把握させて探させたりできます。

使ってみた
Agent Modeには render-compose-preview というツールがあり、これを使うと画像を描画するのと、UIツリーの情報を取得できます。

同様にAndroid CLIでも同じ名前のツールがあり、利用できます。

android studio render-compose-preview --output-image-file=.../TodoDetailScreenPreview.png .../TodoDetailScreen.kt TodoDetailScreenPreview

これで画像ができます。

android studio render-compose-preview --output-image-file=.../TodoDetailScreenPreview.png .../TodoDetailScreen.kt TodoDetailScreenPreview --print-semanticsのように --print-semantics つきで動かすとこんな感じでUIツリーが見られます。

 --print-semantics
ComposeViewAdapter (left: 0, top: 0, right: 1080, bottom: 1920)
  ComposeView (left: 0, top: 0, right: 1080, bottom: 1920)
    View (left: 0, top: 0, right: 1080, bottom: 1920)
      View (left: 42, top: 42, right: 1038, bottom: 580)
        TextView (left: 243, top: 242, right: 838, bottom: 316) text="Memory Metric Display"
        TextView (left: 409, top: 327, right: 671, bottom: 380) text="System Healthy"
        TextView (left: 195, top: 422, right: 340, bottom: 464) text="Allocated"
        TextView (left: 180, top: 464, right: 355, bottom: 527) text="2898 MB"
        TextView (left: 445, top: 422, right: 610, bottom: 464) text="Total Heap"

触ってみて
ライブラリの中も含めて「どこに何があるか」をAIが画像＋座標で把握できるので、マージン調整のような細かいUI修正で効きそうです。

端末操作

（Agent Mode / Android CLI）

なぜ便利か
Androidアプリを作っていると、AIエージェントが「出来ました！」と言ってから、実際に動かすとボタンが効かず調整が必要だったりして、リリースまでが長いと感じることがあります。
Agent Modeは、この距離を縮めてくれます。

端末操作セットアップ

Android StudioのAgent Modeなら、端末操作のツール（take_screenshot / adb_shell_input / run_journey）が最初から入っているのでセットアップは不要です。
他のエージェントから使う場合も、最初に紹介した Android CLI のセットアップ（android init まで）が済んでいれば、追加の準備は不要です。

エミュレーターの起動

セットアップさえしておけば、Agent Modeで Android emulatorを起動できる？ というだけで、以下のAndroid CLIのコマンドを使いながら、emulatorの起動を行うことができます。
(このタスクではAgent ModeもAndroid CLIを使うみたいです)

android emulator list
android emulator start Pixel_9

apkデプロイ

Android Studioに載っているAgent Modeは独自のAndroidのツールを持っているので、
deploy ツールでapkのインストールとアプリの起動を行うことができます。

Antigravity CLIでインストールする例です (Claude CodeやCodexでも同様に動きます)
こちらは android run --apks=/.../app-debug.apk を実行し、インストールし、アプリを起動しています。

Android StudioのAgent Modeでの実際の端末操作
Agent Modeでは run_journey を使うか、take_screenshot / adb_shell_input ツールを使います。

take_screenshotと adb_shell_input は何となく分かると思うのですが、
take_screenshotはスクリーンショットを取得するツールで
adb_shell_inputはタップやキーボード入力などを行うツールです。
では run_journey とはなんでしょうか？

Android StudioのAgent Modeの run_journey とはなにか？

run_journey の正体は、Journeys という機能のAgent Mode統合です。Journeysは、Geminiの推論と画像認識を使って、自然言語でE2EのUIテストを書ける機能です（Otter 3 feature drop 公式ブログ）。

adb_shell_input がタップや入力を1つずつ指定するのに対して、Journeysは「設定画面を開いてダークモードをオンにする」のような手順（journey）を書くだけで、画面のどこをどう操作するかはGeminiが判断してくれる、という違いです。手順は .journey.xml というファイルとして保存できるので、使い捨てではなく、実行するテスト項目として管理できます。

実際にAgent Modeで動かしてログを見ると、run_journey はサブエージェント¹のように動いていて、内部では adb_shell_input ツールなどを利用しているようでした。

I/O Connect '26のセッション（Develop faster with Android Studio, AI and skills）では、Agent Modeとの統合で失敗したテストを反復的に修正できるようになったことに加えて、Android CLI経由でCIのようなヘッドレス環境でもjourneyを実行でき、PRごとにアプリの挙動が仕様からズレていないか確認できる、という使い方も紹介されていました（CI実行はまだ試せていません）。

ちなみに、この「Android CLI経由で実行」の仕組みを調べてみると面白くて、android journeys のような専用コマンドがあるわけではありませんでした。android init で入るandroid-cli skillの中にjourneyの実行手順書（references/journeys.md）が同梱されていて、skillを読んだエージェント自身が、journey XMLをテストとして解釈し、android layout やadbを使って実行するランナーになる、という作りです。journey XMLを、特定のツール専用ではなくエージェント全般で走らせられるテストフォーマットにしていきたいのかな、という感じがしました。

他エージェントでのAndroid CLIを使った実際の端末操作

他のエージェントではAgent Modeのtake_screenshot や adb_shell_inputなどは利用できませんが、 Android CLIのskillを使ってAndroid CLIの知識を得て、
android layout -pやadb shell input tapなどを使って動いてくれます。

android layout -p の結果は以下のようになっていて、クリックできるものを抽出し、効率的に次の adb shell input tap などを行えるようにしてくれます。

...
 {
    "text": "This is your new Todo list app.",
    "center": "[504,599]", // 座標がある
    "key": 3506402
  },
  {
    "interactions": [
      "checkable",
      "clickable",
      "focusable"
    ],
    "state": [
      "checked"
    ],
    "center": "[148,800]",
    "key": 3506402
  },
  {
    "interactions": [
      "clickable",
      "focusable"
    ],
    "center": "[934,800]",
    "key": 3506402
  },
  {
    "text": "Check this out",
    "center": "[394,767]",
    "key": 3506402
  },
  {
    "text": "You can add, edit, and delete tasks.",
    "center": "[540,852]",
    "key": 3506402
  },

触ってみて
サンプルとして、ToDoリストアプリでToDoの追加をお願いしました。N=1ではあるのですが、Agent Mode(Gemini Flash 3)はToDoの追加に失敗してしまいました。Android CLIを使ったAntigravity CLI(Gemini 3.1 Pro)では成功しました。要因としては、モデルの違いに加えて、Agent Modeがスクリーンショットベースで動こうとするあたりが効いていそうです。Agent Modeは今後に期待ですが、基本的に端末操作で利用するのはかなりいいと思います。普段自分の開発でも利用してます。

Agent Modeで失敗してしまった例

クオリティをあげるもの

普段の開発とは少し外れた、アプリの品質を上げる作業（ビルドサイズの削減やパフォーマンス改善など）で使えるものを紹介します。

r8-analyzer

なぜ便利か
R8（リリースビルドの最適化・難読化・コード縮小）の設定は、-keep ルールが増えがちだったり、依存ライブラリが持ち込むルールまで効いていたりで、何がどう効いているか把握しづらいです。R8 Configuration Analyzer は、その設定状況をスコア付きで可視化してくれます。

これは何
ここで出てくるものは2つに分かれます。ひとつは R8 Configuration Analyzer で、これは R8（Android Gradle Plugin に同梱）が持つ解析機能です。適用されている keep ルールや最適化の効き具合を、スコアやレポートの形で出してくれます。もうひとつが Android Skills 側の r8-analyzer で、この解析機能を使って、設定の問題点の洗い出しや改善提案を AIエージェントからやらせるための skill です。

触ってみて
自分のアプリで動かしてみたら、Optimization score が 0% になっていて驚きました。

以下のように教えてくれます。

Optimization Score: 0.00%
Obfuscation Score: 88.93%
Shrinking Score: 89.06%

追ってみると、原因は自分が書いた keep ルールではなく、ある依存ライブラリの consumer rule（AAR に同梱されてアプリ側へマージされる proguard ルール）に -dontoptimize が入っていることでした。-dontoptimize は1行でアプリ全体の R8 最適化を無効化してしまうもので、しかも依存経由で transitive に入ってくるので普通は気づきにくいです。調べてみたら同じ件の issue も上がっていました。

「自分のコードは悪くないのに最適化が効いていない」みたいなものに、AIに R8 設定を解析させて初めて気づけたところで、検証をエージェントに任せる良さを感じました。

ちなみに skill の中身は、ざっくりこういう流れの手順書になっています（r8-analyzer の SKILL.md を読んで自分で図にしたものです）。

注意点
r8-analyzer の skill には解析パスが2つあって、R8 が 9.3.7-dev 未満だと keep ルールのパターンから推測するヒューリスティックな分析になり、結果がかなりブレます。各 keep ルールが実際に保持しているクラスやメンバの数（影響範囲＝keep rule radius）まで見た定量的な分析にするには R8 を 9.3.7-dev 以上にする必要があります。このあたりは別記事に書いたので、実際に試す前に読んでおくのがおすすめです。Android Skillsのr8-analyzerのskillについての注意点

Perfetto trace 分析（perfetto-trace-analysis / perfetto-sql）

なぜ便利か
Android の起動速度や jank は、ログだけだと原因まで追いづらいです。Perfetto trace を見ると、Main Thread、RenderThread、I/O wait、Binder、Compose の recompose、dex/resource 読み込みなどを時系列で確認できます。さらに Perfetto SQL を使うと、「起動中に長かった処理」「main thread が Running / Runnable / I/O wait のどれに時間を使っていたか」まで定量的に出せます。

これは何
性能まわりの Android Skills は2つあります。perfetto-trace-analysis は、Perfetto trace を渡すと根本原因まで調べ切る調査用の skill です。cpu / io / memory などの hints を手がかりに仮説を立て、自分で Perfetto SQL を発行してデータを集め、原因が確定するまでドリルダウンして、証拠付きのレポートを出します。

もう一方の perfetto-sql は、「知りたいこと」を正しい Perfetto SQL に翻訳して実行することに特化した skill です。調査全体を任せるなら perfetto-trace-analysis、単発で数字が欲しいときは perfetto-sql、という使い分けだと理解しています。ちなみに trace-analysis 側は perfetto-sql とほぼ同じSQLガイドを内蔵していて、調査中のSQLもその作法で書かれます。

触ってみて
自分のアプリで起動traceを取ってみると、最初は am start -W の TotalTime を見ていました。ただ、これは初回表示寄りの数字で、実際に画面が見えて使える状態とは少しズレることがあります。

そこで reportFullyDrawn() とアプリ内ログを足して、初回表示と「起動後の画面が見えるところ」までを分けて測るようにしました。そのうえで perfetto-sql を使うと、起動中に長かった slice や main thread の状態を数字で確認できました。

たとえば、ある trace では Compose の recompose、bindApplication、RenderThread の描画処理などが長く出ていて、main thread も CPU で動いていた時間だけでなく、Runnable 待ちや I/O wait がそれなりにありました。単に「起動が遅い」ではなく、CPUなのか、I/Oなのか、描画なのか、初期化なのかを分けて見られるのがよかったです。

こちらも skill の中身は手順書になっていて、R8のような分岐ではなく、根本原因が確定するまで調査ループを回す形です（perfetto-trace-analysis の SKILL.md を読んで自分で図にしたものです）。

注意点
計測条件で結果はかなり変わります。デバッグビルドはリリースと結構ランダムに遅くなるので、起動性能を見るなら debuggable=false で profileable=true なビルドを用意するのが大事です。

また、エミュレータでも傾向は見られますが、I/O wait やGPUまわりは実機と差が出やすいです。エミュレータで怪しい場所を見つけて、最終判断は実機で確認するのがよさそうです。

あと、perfetto-sql で SQL を書くときは pid/tid ではなく upid/utid を使う、文字列検索は LIKE ではなく GLOB を使う、dur = -1（未完了の slice）を考慮する、といった作法があります。このあたりを skill が守らせてくれるので、何も知らない状態で SQL を書かせるより安心感がありました。

まとめ

Agent Mode・Android CLI・Android Skills を一通り見て、その中で使えそうなものを紹介してきました。

Agent Mode は Android Studio の機能をそのままツールとして呼べるので、デフォルトでは一番Android開発がしやすい状態だと思います。
Android CLI で、その Android Studio のツールが他のコーディングエージェントにも開かれました。I/O '26 で 1.0 になり、いろいろなエージェントからAndroid開発がしやすい状態にかなり近づいてきた気がします。ただしサードパーティのエージェントで使うには、自分でインストールしてエージェントが使える状態にしておく必要があります。
Android Skills は、人間でも“スキル”が要るような手間のかかる作業をカバーしてくれます。これも存在を知ってAgentに使わせる必要があるので、どんなSkillがあるかは把握しておくとよいです。また、使うSkillの中身は人間が読んでも発見があるので、一度覗いてみるのがおすすめです。

エージェントとその周りの環境を整えて、開発を効率化していきましょう。

コンテキストをメインのエージェントから分離し、作業結果だけをメインに返す仕組み。途中の細かい動作はメインからは見えないが、その分コンテキストを節約でき、メインのエージェントを賢いまま保てる。 ↩