Google、AIコーディングエージェント評価を詳説
- •Googleのガイドは、Terminal-BenchやDeepSWEに加え、AIコーディングエージェントの行動評価を求めた
- •行動評価はツール呼び出し、ファイル変更、検証器、確認質問、リポジトリリンクを確認する
- •Googleは、集計合格率を監視する3段階ループとバッチ評価を推奨した
Google DevelopersはSept. 9, 2026、テイラー・マレン(Taylor Mullen)とクリスチャン・ガンダーマン(Christian Gunderman)によるAIコーディングエージェント向けハーネスエンジニアリングのガイドを公開し、Terminal-BenchやDeepSWEのようなエンドツーエンドのベンチマークに加えて、行動評価が必要だとした。ガイドは、複合ベンチマークのスコアが数パーセントポイント動いても、エージェントが過信したのか、テスト検証を省いたのか、CLIフラグを幻覚したのか、別の具体的な失敗をしたのかが開発者には分からない場合が多いと述べた。
行動評価は、大規模なコーディングタスクが最後に合格したか失敗したかだけを見るのではなく、エージェントのワークフロー内で期待される行動が起きたかを測る。Googleはこれを、エージェントハーネスの動作に対する統合テストに近い確認だと説明し、情報不足のプロンプトに対して確認質問をすること、ビルドファイルを変更した後にローカル検証器を実行すること、ドキュメント生成時に正規のリポジトリリンクを示すことを例に挙げた。
ガイドは、チームがday oneから複雑な評価ハーネスを作るべきではないとする。ゼロからエージェントを立ち上げる場合、開発者はまず直感、ドッグフーディング、定型コード処理、マークダウンレンダラー作業、日常的な開発タスクに頼り、エージェントが自分自身のコードベースで作業できる段階まで進めるべきだという。評価は、2%の改善を祝うためではなく、前進を確かめ、回帰を防ぐ第2段階に位置づけられる。
Googleは、ローカルで実行できる高速で決定的なユニットテスト風チェックから成る行動評価フレームワークを推奨した。記事にはAntigravity SDK向けのpytest例があり、エージェントにMountain View, Californiaの天気を尋ね、記憶で答えるのではなくSEARCH_WEBを使ったことをテストで検証する。
ガイドは、行動評価では最終的な文字列の一致ではなく、ツール呼び出しやファイル変更など、中間の実行ステップに対してアサーションを置くべきだとした。十分に豊かなテスト群があれば、失敗したテストが通るまでLLMに自分のシステムプロンプトを調整させ、プロンプトエンジニアリングを自動化できる。一方で、残りのテスト群はCI/CD風のガードレールとして働き、既存機能の破損を防ぐ。
Googleは、行動テストの3段階ループを提案した。最近の失敗モードを1つ選び、タスクに対して十分に柔軟なアサーションを書き、安定性を監視するためにバッチ評価を自動化する流れだ。最適解が1つの単純なタスクには厳格な単一ターンのアサーションが合う一方、複雑なタスクではLLM-as-a-judgeのような、より曖昧な結果確認が必要になる場合がある。個々のAIモデル実行はノイズが多く非決定的になり得るため、バッチ評価は時間の経過に伴う集計合格率の追跡に役立つ。
ガイドは、行動評価がより大きなエンドツーエンド評価スイートを置き換えるものではないと結論づけた。マクロなベンチマークは最終結果を検証し、ミクロな行動評価はプロンプト変更、機能追加、まったく新しいモデルのデプロイ時に、より安全な反復を支える。