GoogleがAndroid Bench 2.0を公開、最高通過率は91%から28%へ
Googleは、実務のソフトウェア開発に近い課題でAIの能力を測定する新ベンチマーク「Android Bench 2.0」を公開しました。ベンチマークとは、AIの性能や能力を客観的に比較・測定するための指標や評価プログラムのことです。Googleの発表によると、長期開発タスクにおける最高通過率は約28%となり、原版タスクで記録された約91%を大きく下回りました[1]。
この数値の急減は、AIモデル自体の性能が劣化したことを意味するものではありません。原版のAndroid Bench 1.0で示された約91%という数値は、100件の局所的なGitHubプルリクエスト課題において上位モデルがタスクを解決した割合です[2]。プルリクエストとは、コードの変更や修正を提案して統合を求める仕組みを指します。これは部分的な完成度の平均値ではありませんでした[2]。
一方で、Android Bench 2.0の約28%という通過率は、発表時点で首位の構成となったGPT-6 AstraとCodexが課題を完全に解決した実行の割合です[3]。この数値は、30件の長期タスクを各5回実行した合計150回の試行から算出されています[3]。同じ構成における平均完了率は82.2%に達しており、課題を完遂できたかを示す通過率とは別の指標として扱われています[3]。
従来の二値による合否判定では、要求事項の90%を満たしていても、境界条件の検証処理であるassertion（アサーション）を1件落とすだけで通過率は0%と採点されてしまいます[4]。アサーションとは、想定通りの結果になっているかを確認する判定処理のことです。Android Bench 2.0では完了率を導入することで、未達成となった実行における技術的な進捗も区別して測れるようになりました[4]。
このように、評価対象となる課題セットと合格条件が大きく変更され、結果はモデルとエージェント環境の組み合わせで測定されています。したがって、91%から28%への数値の差を、AIモデル一般の性能低下幅と解釈する根拠にはならないと整理されています[5]。
後輩合格率が9割台から3割弱に急落したと聞くと、AIの能力が急に落ちたように見えてしまいますね。
先輩そう受け止めやすい数字だね。でも今回は解かせている問題の難易度や合格の基準そのものが刷新されているよ。
後輩単純なテストの点数が落ちたのではなく、試験科目そのものが別物に切り替わったということですか？
先輩その通りだね。小規模な計算問題から長編論文の作成に変わったようなものだから、過去の数字と横並びには比べられないよ。
後輩表面的なパーセンテージの上下だけを見て、モデルの良し悪しを判断してはいけないわけですね。
なぜ新たな指標が必要になったのか：旧版の飽和と実務との乖離
新たな評価指標が必要になった最大の理由は、旧版であるAndroid Bench 1.0の評価能力が限界を迎えたことにあります。1.0の環境では、最先端の能力を持つフロンティアモデルが局所的なバグ修正テストで約90%の通過率に達しました。そのため、Googleはベンチマーク自体が飽和していたと説明しています[6]。
通過率が測定の上限に近づくと、上位モデル同士の能力差や、モデルの追加的な進化を測る余地が狭まります。その結果、ベンチマークが本来持つべき識別力が低下するという測定上の問題が生じるとされています[7]。従来の試験では、モデル間の微細な実力差を正確に見極めることが難しくなっていました。
さらに、評価対象のスコープが実務から乖離していた点も課題でした。Android Bench 1.0は局所的なGitHubのプルリクエストを対象としており、タスクにおける変更行数の中央値はわずか32行でした[8]。Googleは、こうした小規模なパッチ修正を中心とした評価範囲では、アプリ全体の構造に関わるアーキテクチャ作業を測定できないと整理しています[8]。
検証方法にも実務との大きな隔たりが存在していました。1.0の検証は画面を持たないターミナル環境（文字入出力のみの環境）で行われていました[9]。そのため、画面の描画やレイアウトの忠実度、ユーザ操作に伴うライフサイクル（アプリの一時停止や再開など状態の変化）の挙動までは確認されていませんでした[9]。
この評価範囲では、画面の見た目や実際のユーザー操作に不具合があっても、テストスコアに反映されない場合がありました。そのため、コードの文面や端末内テストの結果だけでは、実際のアプリ体験の品質を十分に判断できないと考えられます[10]。Googleは、開発者がAIに委ねる業務が複雑化するなかで、局所的な修正にとどまらず実際のモバイル開発課題を測る評価が不可欠になったと説明しています[11]。
後輩以前のテストで満点に近かったのであれば、実際の開発現場でもAIは十分に使えていたのではないですか？
先輩数行のバグ修正に限れば確かに頼れたね。ただ、実際のアプリ開発は画面の崩れを防いだり複数の画面を行き来したりする作業が多いよ。
後輩文字の処理としては正しく動いていても、画面を表示したらレイアウトが壊れていた、という見落としがあり得たんですね。
先輩そういうことだね。従来の机上テストと、利用者が実際に触るアプリの体験との間に大きな開きが存在していたんだよ。
後輩現場で実用に耐えるかを確かめるには、画面描画まで含めて検証する仕組みが必要だったのですね。
何が変わるのか（1）：小規模パッチから数千行規模の長期タスクへ拡大
Android Bench 2.0における最も大きな変更点は、評価タスクの規模と範囲の大幅な拡大です。Googleは、既存のリポジトリに対する小規模な変更を中心としていた初版の設計を改めました[12]。新版では、依存関係の更新や新機能の追加、アプリのゼロからの構築、クロスプラットフォームアプリのAndroid移植といった長期課題へと評価対象を広げています[12, 13]。
従来の1.0では、局所的なプルリクエストを対象とし、コード変更量の中央値は32行にとどまっていました[14]。これに対してAndroid Bench 2.0では、30件の本格的な長期タスク（Long-Horizon Tasks）が設定されています[14]。これらは規模が大きく曖昧さを含み、複数段階の手順を要する開発作業です[13]。
Googleが公表した公式資料によると、2.0における典型的な課題スコープは極めて広範囲に及びます。新規アプリの作成タスクでは、変更規模が1,200〜5,500行、対象ファイル数が20〜70ファイルに達します[15]。また、ライブラリやアーキテクチャの移行タスクでは、200〜8,200行、5〜294ファイルに及ぶ変更が求められます[15]。
以下の表は、Android Bench 1.0と2.0におけるタスクの規模感および対象範囲の違いを整理したものです。変更規模が数十行単位から数千行単位へと拡大したことが分かります[8, 14, 15]。
| 比較項目 | Android Bench 1.0 | Android Bench 2.0 |
|---|---|---|
| 評価タスクの対象 | 局所的なGitHubプルリクエスト（バグ修正等） | 長期タスク（依存関係更新、新機能追加、新規構築、Android移植） |
| 評価タスク数 | 100件（旧タスク群） | 30件 |
| タスクあたりの変更規模 | 中央値 32行（1〜2ファイル） | 新規アプリ作成: 1,200〜5,500行（20〜70ファイル） 移行作業: 200〜8,200行（5〜294ファイル） |
このように、1.0が中央値32行の局所的な作業を中心としていたのに対し、2.0は新規作成や移植を含む30件の長期課題へと刷新されました[16]。長期タスク評価は、実務で委ねられる規模や曖昧さ、複数段階の問題解決を再現し、計画の策定から変更の統合、動作確認までを含むAIの総合的な遂行力を見極めるために重要だと考えられています[17]。
後輩数行の修正パッチと数千行の新規構築では、作業の量以外に何が根本的に違うのでしょうか？
先輩全体の整合性を崩さずに作業を進める計画力だね。課題全体で複数ファイルにまたがる変更があるからだよ。
後輩短距離走のように勢いだけでコードを書いても、途中で矛盾が起きて全体が破綻してしまいますね。
先輩その通りだね。途中で発生したエラーの原因を突き止め、設計を修正しながら最後まで完走できるかが問われるよ。
後輩単にコードの断片を出力する能力ではなく、プロジェクト全体をまとめ上げる実行力が試されているのですね。
何が変わるのか（2）：エミュレーターによる実画面検証と連続完了率の導入
評価環境と採点方式の刷新も、Android Bench 2.0の重要な進化点です。複数日に及ぶような複雑な開発作業では、合格か不合格かという二値の判定だけでは、途中で達成された技術的な進捗を隠してしまいます[18]。未達となったタスクの部分的な進捗を適切に捉えるため、Googleは連続完了率（completion rate）を導入しました[18, 19]。
採点方式だけでなく検証の仕組みも大きく変わりました。文字ベースのターミナル内検証にとどまっていた1.0に対し、2.0ではエミュレーターを用いた実画面検証が行われます[20]。エミュレーターとは、パソコン上で仮想的にAndroidスマートフォンの動作環境を再現するソフトウェアです。Android instrumentation testsを用いて画面上の操作や状態遷移を確かめ、SQLiteやRoomによるデータ永続化、Intentなどの外部境界も厳密に検証します[21]。
画面の表示品質については、エミュレーター上の操作を通じて画面画像とアクセシビリティ階層を取得します[22]。アクセシビリティ階層とは、画面内のUI部品の構造を示したデータのことです。取得したデータを基準となる参照画像と比較し、視覚判定器が0.0から1.0の範囲でスコアを算出します[22]。
評価プロセスの全体像は以下の図のように構成されています。エミュレーター上での各種テスト結果から4つの評価要素が算出され、連続完了率と最終的な通過率が判定されます[21, 22]。
連続完了率は、機能性、回帰防止、要件遵守、視覚忠実度という4つの評価要素を重み付けして合算し、制約違反に応じた乗算ペナルティを適用して算出されます[23]。一方で、pass rate（通過率）も主要な指標として残されています[23]。すべての機能試験に合格し、視覚要件を満たし、制約違反が一切ない完全な実行だけが合格として扱われます[23]。
後輩実務で使うツールであれば、完全に動かなければ意味がない気もしますが、なぜ部分点を測る必要があるのですか？
先輩合否の二択だけだと、あと一歩で完成したのか、最初の一歩で完全に止まったのかが判別できないからだよ。
後輩どこまで自律して進められたかが分かれば、人間がどこをレビューして手助けすればいいか見当がつきますね。
先輩その通りだね。利用する開発者にとっても、AIを改善する開発企業にとっても、具体的な進捗度合いや課題が見えやすくなるよ。
後輩単に足切りをするための試験ではなく、実用化に向けた協業の目安としても役立つのですね。
誰にどう影響するのか：アプリ開発者、モデル開発企業、ツール提供者への波及
Android Bench 2.0の公開は、モバイルアプリの開発者、AIモデルを開発する企業、そしてエージェントツールを提供する事業者という3者に大きな影響を与えます。評価が単一の合格率から多面的な実務評価へと進化したことで、それぞれの意思決定の基準が明確になります。
まずAndroid開発者にとっては、自らの開発業務に最適なAIツールを選定するための具体的な手掛かりとなります。Googleの説明によると、開発者はpass rateとcompletion rateの2つの指標を参照することで、実務に近い課題に対するモデルやコーディングエージェントの適性を比較できます[24]。これにより、自社の開発体制に合わせた現実的なツール導入が可能になります。
次にモデル開発企業にとっては、自社モデルの強みと弱みを長期タスクの文脈で詳細に把握できる利点があります[25]。たとえタスク全体としては不合格になった場合でも、連続完了率を見ることで改善の進捗度合いを追跡できます。そのため、Android開発に特化したモデルの改良を着実に進めることが可能になります[25]。
さらに、エージェント環境やツールを提供する事業者にも影響が及びます。Android Bench 2.0では、AIモデル単体だけでなくCodexやAntigravity SDKなどのエージェント環境もあわせて評価されています[26]。Googleは、ハーネス（AIに指示を渡しツールと連携させる実行基盤）の設計が開発成果に直結すると説明しています[26]。
この結果は、エージェント提供者によるハーネス設計の改善を後押しします[27]。Googleは具体的な工夫として、プロンプトキャッシュやコンパクトなツール表示枠（ウィンドウ）の導入がトークン消費の削減につながる例を挙げています[27]。単にAIモデル自体の性能を追求するだけでなく、モデルを取り巻く実行環境全体の最適化が重要視されるようになります。AI評価における単一スコアからの脱却や実行基盤の重要性については、単一スコア依存から脱却へ、AI評価の実行条件開示が開発と選定を変えるでも詳しく整理されています。
後輩AIモデルそのものの賢さだけでなく、周りの実行環境の作り込みまで評価に影響してくるのですね。
先輩モデルにどんなツールを渡し、プロンプトをどう整理して与えるかで作業結果が大きく変わるからだよ。
後輩腕利きの職人でも、使いやすい作業机や道具箱が揃っていないと力を発揮できないようなものですか？
先輩まさにその通りだね。頭脳となるモデルと、それを支える実行基盤の両方が揃って初めて実務で成果を出せるよ。
後輩現場でツールを選ぶときも、モデルの知名度だけでなく環境全体の設計を見る視点が必要になりますね。
