skydoves

KMPデスクトップはAIエージェントに速いのか？検証してみる はじめに この記事 を読みました。 AI エージェントにアプリを操作させて動作を確認するとき、Android エミュレータではなく Kotlin Multiplatform のデスクトップ版を使った方が速い、という内容です。記事には実測値も載っています。 エージェントがアプリを操作する方式 1 件あたり Android エミュレータ（Android CLI の layout + adb） 5.68 秒 Android エミュレータ（生の UIAutomator + adb） 4.14 秒 デスクトップ（Compose MCP） 0.60 秒 デスクトップ（UI を飛ばして presenter に直結） 0.0008 秒 Android とデスクトップで 7〜9 倍、UI を飛ばせば 1,000 倍の差があるとのことです。 読んで最初に思ったのは「本当にそうなのか」ということでした。同じ Kotlin のコードが動いているのに、デスクトップにしただけでそこまで速くなるものでしょうか。記事は著者ご自身の App Platform という仕組みの上で計測されているので、ごく普通の KMP アプリでも同じことが起きるのかを手元で確かめてみました。 検証に使ったもの nowinandroid-kmp を使いました。Google の Now in Android を Kotlin Multiplatform に移植したもので、Android もデスクトップも同じ画面、同じ ViewModel、同じデータ層で動きます。「アプリの差」と「それ以外の差」を切り分けるのに向いています。 Mac デスクトップ Android マシン MacBook Pro（Apple M4 Pro） 同じ Mac 上のエミュレータ（Pixel 9, Android 15） 画面 460×915 に固定し、Android と同じ縦長レイアウトに 1080×2424 Compose Multiplatform 1.12.0 1.12.0 道具は記事と同じものを揃えました。 デスクトップ: Compose Multiplatform 1.12 で入った Compose Hot Reload の MCP サーバー（./gradlew :app:desktopApp:hotMcpServer）。get_semantic_tree で画面のツリーを取り、click(nodeId) で押します Android その 1: adb exec-out uiautomator dump でツリーを取り、adb shell input tap で押す Android その 2: Google の Android CLI（android layout と android input tap） 方式 10 件合計 Mac デスクトップ版 Android エミュレータ 作業も記事に合わせました。一覧の項目を開き、詳細になったことをツリーで確認し、戻り、一覧に戻ったことをツリーで確認する。これを Interests 画面の上から 10 件ぶん繰り返します。1 件につき「見る・押す・見る・押す・見る」の 5 回です。アプリと MCP サーバーは接続済みのウォーム状態から測り、各方式 3 回やって中央値を取りました。 普通に測ったら、記事の通りでした 方式 10 件合計 1 件あたり 記事の値 Mac: Compose MCP 5.0 秒 0.50 秒 0.60 秒 Android: 生 UIAutomator + adb 59.5 秒 5.95 秒 4.14 秒 Android: Android CLI 65.8 秒 6.58 秒 5.68 秒 12 倍違いました。 実際に動いている様子です。左右とも実時間で、上のタイマーが経過秒数と完了した件数です。Mac が 10 件終わった 5 秒の時点で、Android はまだ 1 件目です。 Android が 10 件終わるまでの全体はこちらです（60 秒かかるので 4 倍速）。 記事は 7〜9 倍でしたが、こちらはそれより開きました。3 回測っても Mac は 4.996〜5.001 秒で、ほとんどぶれません。記事の主張は、ごく普通の KMP アプリでもそのまま再現しました。 疑って測りに行った側としては少し拍子抜けです。ただ、数字の内訳を見ていくと、記事を読んだだけでは分からなかったことが見えてきました。 でも、Mac が速いのはアプリではありませんでした 1 回の呼び出しにかかった時間の中央値です。 方式 ツリー取得 クリック Compose MCP 0.100 秒 0.100 秒 生 UIAutomator + adb 1.954 秒 0.033 秒 Android CLI 1.813 秒 1.195 秒 Android の 1 件 6 秒のうち、5.9 秒が uiautomator dump 3 回分です。タップそのものは 33 ミリ秒しかかかっていません。アプリが画面を切り替える時間は、この 6 秒の中でほぼ見えません。 Mac 側だけを実時間で見るとこうなります。1 件 0.5 秒なので、画面がパタパタと切り替わります。 一方の Compose MCP は、ツリー取得もクリックも きっかり 0.100 秒でした。スクリーンショットも、ログ取得も、status を聞くだけでも 0.100 秒です。これはアプリの処理時間ではなく、MCP サーバーが 100 ミリ秒周期で返事をしている時間です。つまりアプリの応答は 100 ミリ秒の中に収まっていて、測定値に顔を出していません。 実は前回、JVM に Java Agent を差し込んでアプリのログ（screen_view イベント）で画面遷移の時間だけを測ったことがあります。そのときは Mac も Android も 0.1 秒前後で、同じでした。アプリは速くなっていないのです。 速くなったのは、エージェントが画面を「見る」ための経路です。 Android では 1 回見るたびに adb を跨いで UIAutomator が画面全体をなめます。デスクトップでは Compose のセマンティクスツリーをプロセス内から JSON で渡してもらえます。エージェントの仕事は「見て、押して、また見る」の繰り返しなので、「見る」が 2 秒か 0.1 秒かがそのまま効きます。 Android CLI は生 UIAutomator より遅かった もう一つ意外だったのが、Google が「エージェント向け」として出している Android CLI が、生の UIAutomator より遅かったことです。 android layout は 1.8 秒と UIAutomator より少し速いのですが、android input tap "text=Compose" のようにセレクタで押す方式なので、タップのたびに内部でレイアウトを取り直します。それで 1 回 1.2 秒。合計で 1 件 6.6 秒になりました。記事でも Android CLI の方が遅く、同じ傾向です。 ただし Android CLI には利点もあって、セレクタで押せるので座標計算が要らず、エージェントのツール呼び出し回数を減らせます。今回のループのように「押す前に必ず見る」のであれば、二重にレイアウトを取っているぶんが無駄になる、という話です。 まとめ 記事 今回 UI 経由の Android とデスクトップの差 7〜9 倍 12〜13 倍 差の理由 観測とツール呼び出しのコスト 同じ（Android は 1 件 6 秒のうち 5.9 秒がツリー取得） UI を飛ばして presenter に直結 1,000 倍 未検証（NiA-KMP にそのような入口はありません） Now in Android KMP のデスクトップ版は、リリースするわけではなく、実質的に開発用の存在です。それでも持っておく価値があると分かりました。 エージェントに「触って確認する」作業をさせると、Android の 12 倍速く回ります Compose Multiplatform 1.12 以降なら MCP サーバーは最初から付いてきます。.mcp.json に hotMcpServer を書くだけです Android は最後の確認（見た目、タッチターゲット、アニメーション）だけに回せます KMP を「Android と iOS を両方出すため」にだけ使っていると、デスクトップ版は余計なターゲットに見えます。しかし AI にアプリを触らせて開発する前提で見ると、デスクトップ版は一番速い入口でした。記事の主張は正しかったと思います。 計測で詰まったところ Compose Hot Reload 1.2.0 の take_screenshot は、ウィンドウの画面領域をそのまま撮る方式でした。別のウィンドウが手前にあるとそれが写ります（1.3.0 からは Compose 側で描画内容を撮るようになるそうです）。上の GIF は alwaysOnTop = true を一時的に付けて撮り直しています。 Android CLI を一度使うと、端末内に com.android.cli.interact.instrumentation という instrumentation サーバーが常駐して UiAutomation を占有します。その状態で uiautomator dump を叩くと Killed とだけ出て死にます。am force-stop で止めてから生 UIAutomator を測りました。 uiautomator dump の XML は & が & になっています。unescape を忘れて「Android Studio & Tools」が見つからず、1 回目の計測が止まりました。 hotMcpServer は起動直後に「No application is currently connected」を返すことがあります。status が connected: true になるまで待ってから始める必要がありました。 hotMcpServer 自体は Gradle タスクなので、立ち上がるまでに 8〜22 秒かかります。計測には含めていませんが、エージェントが最初に接続するときは待たされます。 計測の限界 件数は記事の 15 件に対して 10 件です（スクロールなしで画面に収まる範囲）。1 件あたりの値で比較しています。 エージェントの推論時間は含んでいません（記事も同じです）。実際にはツール呼び出し 1 回ごとに推論が挟まるので、呼び出し回数が多い方式ほど差は広がります。 エミュレータは Mac 上で動いているため、実機の性能ではありません。 Android が記事より遅いのは、Now in Android の詳細画面が記事カードを含んでツリーが大きいことと、エミュレータと計測が同じ Mac で動いていることが効いていると考えています。 参考 Headless App Agents - Ralf Wondratschek Compose Hot Reload（kotlinlang.org）（MCP サーバーの設定方法） Compose Multiplatform 1.12.0 リリースノート Android CLI for agents nowinandroid-kmp