Googleは2026年9月16日、Androidアプリ開発向けのAI評価基盤「Android Bench 2.0」を公開した。初代が測っていたのは、中央値32行、1〜2ファイルの局所的な修正である。2.0は、人間の技術者なら数日から数週間を要するlong-horizon tasks（長期タスク）へ対象を広げ、最大8,200行、294ファイルに及ぶ変更も試す。

首位のGPT 6 AstraとCodexの組み合わせは、平均完了率82.2%に達した。それでも完全合格した実行は28.0%にとどまる。完了率は作業量やコード量の割合ではなく、機能、回帰、要求、視覚を重み付けした得点である。主要な画面や機能が動いても、回転後の状態保持や依存関係で止まり、ライフサイクルや二次画面を仕上げ切れない実行がある。Android Bench 2.0が測り始めたのは、コードを大量に書けるかではなく、最後まで製品として成立させられるかである。

AD

高い完了率でも残る、完全合格への壁

Android Bench 2.0の順位表は、合格率と完了率を分けて表示する。合格率は、機能テストと視覚要件をすべて満たし、制約違反もなく、得点が1.0になった実行の割合だ。対する完了率は、機能と回帰、要求と視覚の各得点をタスクごとの重みで足し、制約違反のペナルティーを掛けた連続指標である。

上位4システムを並べると、二つの数字が同じ方向には動かない。

モデル＋エージェント 合格率 平均完了率 平均時間 全30件の平均費用
GPT 6 Astra＋Codex 28.0% 82.2% 7.9時間 375.7ドル
Claude Fable 5.1＋Claude Code 22.7% 82.4% 22.2時間 492.6ドル
GPT 5.6 Sol＋Codex 19.3% 74.3% 8.6時間 235.8ドル
Gemini 3.8 Flash＋Antigravity SDK 8.0% 47.4% 12.1時間 34.5ドル

Fable 5.1は完了率でAstraをわずかに上回るが、合格率では下回る。Astraの合格率にも13.3〜42.0%という広い信頼区間が付く。小さな順位差を確定的な能力差と読むには、30件の課題はまだ少ない。

タスク別結果は、完了率が拾う「惜しい失敗」の中身を見せる。BitwardenのNavigation 3移行では多数のファイルを変更してテストを通しても、終了時の画面遷移が欠けて視覚的な引っかかりが残った例がある。ニュースアプリの動画再生では、画面外へ出たプレーヤーを解放できず、バックグラウンドで再生が続いた。見た目が完成していても、運用中に効く欠陥が残る。

つまり82.2%は「82.2%の確率で仕事を任せられる」という意味ではない。主要機能まで進む力と、人間が最終確認すべき残存リスクを一つの平均に圧縮した数字である。

32行から最大8,200行へ広がった仕事量

初代Android Benchは、既存のGitHubリポジトリに対する小規模な修正を中心に設計されていた。変更量の中央値は32行、対象は1〜2ファイルで、先端モデルの合格率が約91%へ達した。Googleはこの状態を、評価が飽和したと判断した。

2.0は30件の長期タスクを用意し、各システムに1件あたり5回の独立実行を課す。新規アプリ作成は1,200〜5,500行、20〜70ファイル。ライブラリやアーキテクチャの移行は200〜8,200行、5〜294ファイルに及ぶ。ほかに新機能の追加と、FlutterやReact NativeからネイティブAndroidへの変換がある。

旧版の約91%と2.0の28.0%をそのまま結び、AIの能力が落ちたと解釈してはならない。測定する仕事量、採点方法、実行基盤が同時に変わったからだ。むしろ28.0%は、短い修正で見えなくなっていた差を再び測れるようにした結果である。

Googleが示す得意不得意も、コード量だけでは説明できない。JavaからKotlin、RetrofitからKtor、ViewModel層の導入など、変換規則が安定した作業は多くのファイルへ広がっても進めやすい。一方、破壊的なAPI変更、実行時にしか分からない依存性注入の欠落、学習例が少ない新ライブラリでは止まりやすい。長さより、既存アーキテクチャの暗黙のつながりが難所になる。

AD

動けば合格ではない、AVD上の多面的検証

30件は毎回、新しいDockerコンテナで動く。KVM対応のAndroid Virtual Device（AVD）を使い、環境には最低16 CPU、72GB RAM、500GBストレージを割り当てる。モデルはMarkdownでコマンドを書くだけではなく、構造化されたAPI経由でシェルを操作する。

検証は二層ある。決定論的な側ではInstrumentationテストを走らせ、SQLiteやRoomの中身を直接調べる。Intent、ネットワーク呼び出し、Wear OSとの同期も監視し、既存機能を壊していないか回帰テストで確かめる。内部クラスの形を固定する単体テストより、利用者が触る状態変化を重視した設計である。

画面はピクセルの完全一致では判定しない。時刻、電池アイコン、フォント描画の違いまで誤差として拾い、意味の上では正しい画面を落とし得るためだ。代わりに自動操作で画面とアクセシビリティツリーを取得し、Gemini 3.5 Flashが基準画像と比べて0〜1で採点する。静止画を画面へ貼って試験をすり抜ける手口は、タッチ対象やネイティブ要素を読むアクセシビリティ検査で防ぐ。

Googleは360回の校正実行で、この視覚判定が反復間で100%一致したと説明する。ただし、一致したのは同じ判定器の出力である。人間のAndroid技術者とどの程度一致するか、特定のモデル系列に有利な癖がないかまでは、この数字から分からない。

採点も甘い部分点ではない。ビルド失敗や試験の不正回避、ネイティブ化課題でFlutter、Dart、JavaScriptのファイルを再利用した場合、完了率へ掛ける係数は0.0になる。Jetpack Compose課題で旧式APIを使えば0.5倍だ。大量の画面を作っても、土台の制約を外せば得点を失う。

順位表が比べるのはモデルではなくシステム

順位表の各行は、モデル単体ではない。GoogleはGPT 5.6 SolをCodexで、Gemini 3.8 FlashをAntigravity SDKで走らせた。Claude系にはClaude Code、QwenにはQwen Coderを組み合わせている。agent harness（エージェント実行基盤）が変われば、使えるツール、文脈の圧縮、キャッシュ、失敗からの戻り方も変わる。

Google自身、プロンプトキャッシュや短いツール用コンテキストがトークン削減につながり、実行基盤の設計が結果へ良い影響を与えると説明する。これは実務には近い。開発者が買うのはモデルの重みだけでなく、実行基盤を含む製品だからだ。だが「どのモデルが最も賢いか」を知りたい場合には、変数が一つ増える。

費用と時間も、そのまま効率順位にはできない。公式方法論は、早い段階で失敗するシステムほど総実行時間と費用が小さく見える偏りを認めている。APIまでのネットワーク経路は待ち時間へ混ざり、価格改定は異なる時期の費用比較を崩す。プロバイダー側のプロンプトキャッシュが利用量へ完全に現れない場合もある。

したがって34.5ドルのGemini 3.8 Flashを、375.7ドルのAstraより安く同じ仕事をこなす構成とは呼べない。完了率は47.4%と82.2%で大きく異なる。費用を比べるなら、まず同程度の合格率と完了率にそろえる必要がある。

AD

方法論と順位表で食い違う30件の分類

Android Bench 2.0は、ベンチマークの答えが学習データへ混ざる問題に四つの対策を置いた。新規作成には公開実績のない社内アプリを使う。移行課題は上流リポジトリに存在しない組み合わせを選び、変換課題には既存のネイティブAndroid版がないアプリを使う。さらにエージェントの実行軌跡を監査し、外部からのコード取得や得点稼ぎを探す。

代償もある。フレームワークはGitHubで公開されているが、30件の完全なデータセットは非公開で、Googleは汚染を避けた公開方法を検討中としている。第三者は環境の骨格を調べられても、同じ課題と重みで順位を完全再現できない。汚染耐性を高めるほど、外部監査は難しくなる。

公式ページ同士にも、小さいが無視できない食い違いがある。公式方法論は30件をアプリ新規作成9件・移行13件・新機能6件・変換2件とする一方、リーダーボードのフィルターは新規作成10件・移行13件・新機能5件・変換2件と表示し、新規作成と新機能の分類が1件ずつ食い違う。9月18日の確認時点では、ページ更新の時差か再分類かは説明されていないため、カテゴリ別の成績を読む前に定義をそろえる必要がある。

ほかにも測れない領域は残る。Bluetooth機器、物理カメラ、GPUシェーダーはソフトウェアで模擬し、バックエンドにはローカルのモックを使う。折りたたみ端末、大型画面、Android Autoは今後の対象だ。Android開発のすべてを代表する順位ではない。

Android Bench 2.0は、総合首位を一つ選ぶための表というより、自社のレビュー工程を設計する材料として読む方がよい。新規開発が中心なら作成課題を、既存アプリを抱える組織なら移行と回帰の失敗理由を見る。合格率が近い構成を比べたうえで、信頼区間、平均完了率、時間、費用を重ねる。

人間の役割も変わる。平均完了率が8割を超えても完全合格が3割に届かないなら、レビューは書き方の好みより、状態の永続化とライフサイクルへ寄せるべきだ。依存関係とアクセシビリティも重点になる。高い完了率は人手が不要という合図ではない。残りの欠陥を発見できる試験と設計レビューが必要だという合図である。

同じモデルを複数の実行基盤で走らせ、非公開課題を汚染させず第三者が監査でき、公式ページのカテゴリ定義も一致する。その条件がそろったとき、Android Bench 2.0はモデルの宣伝順位から、AIを開発工程へ組み込むための測定器へ近づく。