GoogleのARTEMISがAndroid自動化をオープンソース化：99%というAndroidWorldの主張が実際にカバーする範囲

の最新のコミットはgoogle/artemis機能ではない。それはクレジット表記だ — 「fix: READMEと関連するファイルヘッダーをApache 2.0の要件に従って完成させる」は、Minitapが「Googleにはもっと期待していた」というタイトルの投稿を公開してから3日後の2026年9月12日にプッシュされた。GoogleのARTEMISは、同社が新たにオープンソース化したAndroid自動化エージェントだ：平易な英語の指示を、実機のAndroidデバイスやエミュレータ上での実際のタップ、スワイプ、タイピング、検証に変換し、その過程でログとスクリーンショットをキャプチャし、Google ResearchのAndroidWorldベンチマークで99%以上のタスク完了率を報告している。これは今年8月にGoogleのPixel Test Engineering FusionチームによってApache 2.0の下で公開され、本当に午後の時間を費やす価値がある。また、9月中旬現在、モバイルエージェントがどのように構築されるかについて、ベンチマークの数値よりも多くを物語るオープンソースの帰属をめぐる争いの中心にもなっている。どちらの話も真実だ。しかし、リポジトリの最後のコミットがライセンス修正だった理由は、そのうちの1つだけだ。

実際に出荷されたもの

ARTEMISはモデルでもチャットボットのラッパーでもありません。それは制御ハーネスであり、視覚言語モデルと実機の端末の間に位置するPython 3.12+のシステムです。英語でタスクを与えると、画面を観察し、行動を決定し、ADBを通じて実行し、何が起きたかを確認し、そのまま続行します。箱に入っていたものは5つです：

• CLI と Python SDK。 code>./start.sh/code> は ADB、scrcpy、FFmpeg、uv 環境を初期セットアップします。code>uv run artemis run "…" --profile flash/code> はタスクをヘッドレスで実行します。その code>artemis-client/code> SDK は pytest と CI 向けに同じ呼び出しをラップし、次を返します: code>succeeded/code>、 code>status/code>、 code>device_serial/code> および code>trace_id/code> を後で追跡できます。

• Web コンソールです。 code>uv run artemis ui/code> は code>localhost:8000/code> でビジュアルテストコンソールを提供し、ループをステップごとに確認できます。

• ネイティブな MCP サーバー。 これが普及の決め手となった部分です。code>uv run artemis mcp --install all/code> は code>mobile_run_task/code>、code>mobile_manage_task/code>、code>mobile_get_device_state/code>、code>mobile_inspect_trace/code>、code>mobile_diagnose/code> を、MCP 対応のあらゆるアシスタントに公開します。Antigravity、Claude Code、Codex 向けのファーストクラスのインストールパスに加え、Cursor、Windsurf、VS Code、Cline/Roo 向けの設定生成も備えています。サーバーが接続されたアシスタントからなら、「APK をビルドし、インストールし、設定を開き、機内モードを切り替え、結果をスクリーンショットする」はスクリプトではなく、一文になります。

• アクセシビリティヘルパーです。 最初のタスクでは、Artemis Accessibility Helper をインストールします。これは UiAutomation 接続を保持せずに画面レイアウトを読み取ります。これは意図的な設計で、同じデバイス上にある他の UiAutomator ベースのツールが抑制されないようにするためです。スマートフォン上で動作し、外部には何も送信しません。また、接続できない場合は UIAutomator2 にフォールバックし、そのフォールバックはタスクタイムラインに表示されます。

• ログとトレースの取得。クラッシュスタック、キーフレームのスクリーンショット、診断レポートは、呼び出し側が後から付け足すのではなく自動的に収集される——これが、単なるデモではなく回帰テストスイートとして使える理由である。

FlashとProは、同じ名前を共有する2つの異なる製品です

ARTEMIS を何かと比較してベンチマークする前に理解しておくべき最も重要なことは、code>--profile flash/code> と code>--profile pro/code> は、1つのエージェントにおける速度設定ではありません。それらは2つのエージェントです。

• Flash — 1ステップあたり約3～5秒の反応型の観察・行動ループであり、計画もメモも、実行前の安全チェックも、チェックポイント検証も、最終レポートも、ADB shellもない。履歴は蓄積されるのではなく圧縮されるため、このループはデフォルトで無制限である。

• Pro — ステップあたり約15～40秒のマルチエージェントグラフ。明示的な code>verify/code> および code>assert/code> 項目を含む生きたMarkdownプランを維持するPlanner、フルツールセットを備えたOperator、チェックポイントを検証して終了レビューを実行する読み取り専用のCheckerから構築されています。 code>--verification-level/code> は次のいずれかを取ります: code>off/code>、code>final/code>（既定）、code>checkpoints/code> または code>strict/code>。

同じタスク記述に対して5～10倍のレイテンシ差があり、これはスモークテストと100ステップ以上の探索的実行との違いです。Google自身の位置づけは、Proは長期的な作業と継続的なcode>[Loop:continuous]/code>モニタリング向けであり、Flashは定型的で決定論的なUI作業向けである、というものです。どのプロファイルが生成したものかを示さずにステップのタイミングを引用しているレビューは、何も伝えていません。

位置決め戦略こそが真のエンジニアリングだ

ほとんどのモバイル自動化フレームワークは、セレクターで破綻する。ARTEMISはダイナミックファーストで構築されている。アクセシビリティ要素インデックスが存在すればそれを使い、存在しなければ——Canvas、Composeサーフェス、Flutterビュー、ゲームなど——座標とビジョンにフォールバックする。保守すべきXPathレイヤーも、古くなるIDもない。このことは重要だ。なぜなら、あなたが最もテストしたいアプリケーションは、毎週新しいビルドを出荷するものだからだ。

Pro プロファイルはセーフティネットを追加します。すべてのアクションは実行前チェックを通過し、XML 優先でピクセルフォールバックを備え、タップを奪おうとしているシステムポップアップを捕捉します。失敗すると「実行インシデント」が開かれ、後続の成功で解決されるまでコンテキスト内に留まります。別の修復エージェントを起動するのではなく。長いセッションは圧縮され、古いスクリーンショットは視覚要約になり、完了したステップは、code>search_history/code> と code>replay_steps/code> が引き戻せる、呼び出し可能な区切りへとチャンク化されます — これが、100 ステップのコンテキストを手頃なコストに保つものです。

リーダーボードで99.1%、そしてローンチ記事が省く注意点

ARTEMISの看板となる主張は、AndroidWorldにおける99%超の完了率である。AndroidWorldはGoogle Researchによる、20あまりのアプリにまたがる116の現実的なタスクのベンチマークで、Pass@1として採点される。2026年9月11日時点で、AndroidWorldのリーダーボードはARTEMISを99.1%、Minitapのmobile-useを91.4%と記載し、人間のパフォーマンスは80%だった。数字の上では、これは公開されている結果の中で最先端である。

その数字と併せて押さえるべき点が2つある。第一に、AndroidWorld のリーダーボードは、提出物を独立に検証しないことを明示している——そこに載るすべての数値は、ARTEMIS のものも含め、それを生み出したチームによる自己申告であり、ロバストネス解析によって、タスクの変動だけでエージェントのスコアが大きく動きうることが示されている。99.1% は、公開され検証可能なベンチマークに対する強いベンダー主張として扱うべきであり、それは現実的で有用なものではあるが、監査済みの測定値として扱うべきではない——実際、そうではない。第二に、比較の形が重要である。ベンチマークは固定されたタスクセットであり、ARTEMIS が公表した比較チャートは、他の項目を含めつつ、モバイル利用を省略したと報じられている。最も強い従来の結果がチャートから欠けているベンチマークでは、生のパーセンテージが示唆するよりも主張が弱くなる。

今月の本当のニュースである、その紛争

自社のブログとリポジトリの公開Issueで、Minitap — オープンソースのmobile-useプロジェクトがAndroidとiOS向けに同じ仕事をするモバイルテストスタートアップ — は、ARTEMISの229ファイルのうち228ファイルが自社のものと同一だと主張した。公開された具体的な内容は異例なほど具体的だ。自社の実装と一致するAndroid端末接続コード、「Hopper」という名前のエージェントに属する指示の逐語的な再利用、そしてAlice、Bob、Charlieに新年のメッセージを送るWhatsAppの例が、同じコメント、同じクリーンアップ手順、同じバグを伴って再現されている。さらに、Minitapの3人の著者 — Pierre-Louis Favreau、Jean-Pierre Lo、Nicolas Dehandschoewercker — の名前を記載したファイルが8月にforce-pushで置き換えられ、名前が削除され、別の著者に差し替えられたと主張している。

ライセンス問題は曖昧ではない。mobile-use は Apache 2.0 であり、Apache 2.0 は、著作権表示を保持し、変更内容を明示することを条件に、まさにこの種の再利用——商業利用、派生利用、クローズド——を認めている。認めていないのは、著作権表示を削除した状態でコードを配布することだ。疑惑が表面化して以来、リポジトリには「このプロジェクトには Minitap, Inc. が開発したソースコードが含まれています」という文言と、minitap-ai/mobile-use へのリンクが掲載されており、その帰属表示を完了させた9月12日のコミットは、執筆時点で code>main/code> 上の最新の変更である。Minitap は、帰属表示の削除を自社の未回答のリーダーボード提出に結びつける証拠を何も公表しておらず、Google も詳細な公開回答を出していない。率直に読めばこうだ。共有されているコードは正当であり、常に許可されていた。書類上の対応は、一定期間、不備があったが、今は修正されている。

誰もコストを見積もらない部分：モデルの請求額

ARTEMIS には「Multi-Model — Gemini | Claude | GPT-4o | Qwen-VL」と書かれたバッジが付属しており、その設定ファイルは code>config/artemis.jsonc/code> で、そこに、認証情報を持っている任意のビジョンモデルを指定します。そのファイル内でユーザー向けとなるものは、実際のワークフローで Pro を実行し、長時間稼働するエージェントに実際どれだけコストがかかるかを見るまでは、何もありません。

プロファイルごとに計算してみてください。1ステップ15～40秒で100ステップのPro実行は、実時間で25分から1時間ちょっとになります。そしてその各ステップは、少なくとも1回のスクリーンショットを伴う視覚モデル呼び出しです。Flashは1ステップあたりは安いものの、より激しくループします。そしてコンテキストが切り詰められるのではなく圧縮されるため、上限だと思っていたターン制限を平然と超えて実行されます。どのプロファイルを選んでも、テストスイートに応じて増える費目はモデルであり、ライセンスやハードウェアではありません。

ここが、ルーティング層がもはや抽象化ではなくなる地点だ。長いAndroidセッションを駆動するビジョンモデルは、厄介な2つの性質を備えたワークロードである。すなわち長時間生存すること、そしてステップ74の途中でプロバイダー側の一時的な不具合が起きても許容できないことだ。なぜなら、その実行のコンテキストはそのプロバイダーのエンドポイント上にあるからだ。ARTEMISを単一のOpenAI互換ベースURLに向け、フェイルオーバーによって同じモデルの別プロバイダーへ実行を移す——これが、不安定なテストと失われた午後との分かれ目になる。最初に試す候補として興味深いのはQwen3.8-Flashだ — 100万トークンのコンテキストを持つ6BアクティブのマルチモーダルMoEで、当社のカタログでは入力100万トークンあたり0.15ドル、出力100万トークンあたり0.47ドル、キャッシュ読み取りは0.018ドル、キャッシュ書き込みは0.230ドルで掲載されている。ここで重要なのはキャッシュ読み取りの価格だ。Pro実行ではステップごとに成長するコンテキストを再読み取りするからである。

ただし、それが何を意味するかについては正確を期しておこう。Qwen3.8-FlashはARTEMISのテスト済みバックエンド一覧には含まれていない。そこに挙がっているのはGemini、Claude、GPT-4o、Qwen-VLだ。これはハーネスに適合する可能性が十分にあるモデルであり、ハーネスはそうしたモデルを受け入れるよう明示的に作られている。だが、その組み合わせのベンチマークを公開した者はいない。もし公開したと主張する者がいれば、でっち上げたものとして扱うべきだ。

ロードマップ、そしてそのどれだけがなくてはならない部分なのか

公開中のロードマップには4つの項目があります：エディタ内デバッグ、テスト記録、デバイス制御を備えたAndroid Studio統合、iOSサポート、低遅延でプライバシー優先の作業のためのオンデバイス軽量視覚言語モデル、そしてリアルタイム双方向音声対話です。

信じるべきなのは1つ目だ。なぜなら、それはPixelのテストエンジニアリングチームから出てくる自然な次の成果物であり、研究リスクが伴わないからだ — エージェントはすでにデバイスを操作しており、必要なのはIDE内のパネルだけだ。iOSは、外から見えるよりもはるかに大きな主張だ。位置特定戦略の全体がAndroidのアクセシビリティサービスに依存しており、iOSには同じ権限モデルを持つ同等のサーフェスが存在しない。したがって、移植ではなく知覚レイヤーの書き直しを想定すべきだ。オンデバイスVLMの項目こそ、注意深く追う価値がある。なぜなら、それはリスト上で、現在大規模テストスイートで支配的になっているステップごとのAPIコストを取り除く唯一の項目であり — そして、UIタスクをまとまりある形で遂行できる、小型で高速な視覚対応モデルを意味する。これは「ツール使用が得意な小型モデル」よりも、はるかに狭いターゲットだ。

今週それで何をするか

クローンして、code>./start.sh/code>を1つのエミュレータに対して実行し、既存のEspressoスイートがカバーするタスクをFlashに与えてください。そうすれば、dynamic-firstロケータがアプリのComposeサーフェスで生き残るかどうかを1時間以内に判断できます。これが、残りのすべてに意味があるかどうかを決める問いです。次に、同じタスクをProで実行し、2つのトレースを比較してください。1ステップあたり3～5秒と15～40秒の差が、あなたの予算の在り処であり、それを抜きにARTEMISのコストを論じることはできません。

コードを読んでいる間は、ヘッダーも読んでください。Minitap の帰属情報を追加した9月12日のコミットは、リポジトリ内で最新のコミットです。つまり、あなたが読んでいるファイルヘッダーは4日前のものであり、プロジェクトは公開の場で活発に修復されている最中です。それは、それを避ける理由にはなりません。スライドで成功率を引用する前に、自分が手にしているストーリーがどのバージョンなのかを確認すべき理由です。

ARTEMIS を単一の OpenAI 互換ベース URL に向けること同じモデルの別プロバイダーへフェイルオーバーで実行を移すことが、不安定なテストと失われた午後との違いだ。