AIコーディング、スコア低下の理由をベンチマークは答えない――Google推奨、エージェントの「行動評価」とは：ハーネスエンジニアリングを始めると“はまる”落とし穴

Googleは、AIコーディングエージェントの振る舞いを個別に検証する「行動評価」の考え方を公開した。エンドツーエンドのベンチマークは、総合スコアが動いた理由までは答えてくれないという。

[＠IT] PC用表示関連情報

LINE

Hatena

　Googleは2026年9月9日（米国時間）、AIコーディングエージェントのハーネスを改善する「行動評価」の考え方を、開発者向けブログで公開した。

　Googleは、エージェント型のコーディングシステムでハーネスエンジニアリングに取り組み始めた開発者が、同じ落とし穴にはまると指摘する。「Terminal-Bench」「DeepSWE」といった一般的なエンドツーエンドのベンチマークを回し、総合スコアが数ポイント動くのを眺めても、「なぜ変わったのか」が分からないというものだ。エンドツーエンドのベンチマークはモデルの性能を測り、「どこを深く調べるべきか」を決めるための事実上の標準になっているが、その調査には高いコストもかかる。

　Googleによると、期待する振る舞いが起こっているかどうか、退行せず正しい方向に進んでいるかどうかを確かめるには、多くの場合、行動評価の方が優れた尺度になる。変更が結果を左右する理由を知る手掛かりにもなるという。

スコア低下の理由をベンチマークは答えない

　多くのチームは、試験を受ける学生と同じようにAIエージェントを評価している。大きなコードベースと制限時間を与え、通過したテストの数で成否を測る。スコアが下がったとき、モデルが曖昧なプロンプトで自信過剰になったのかどうか、提出前にテストスイートの確認を忘れたのかどうか、ハルシネーションで実在しないCLIのオプションを作り出したのかどうかは、エンドツーエンドのベンチマークからは直接は分からない。

　行動評価は、ハーネスの動作を改善する統合テストのように機能する。十分に豊富な行動評価のセットがあれば、エージェントに期待する振る舞いの基準ができ、そこに近づけるようにプロンプトを反復して改善できる。複数ファイルにまたがるリファクタリング全体を解けたかどうかではなく、次のような個別の観察可能な動作を測る。

仕様が不十分なプロンプトを与えられたとき、推測せずに確認の質問をするかどうか
ビルドファイルを変更したとき、完了を宣言する前にローカルの検証ツールを実行するかどうか
ドキュメントを生成するとき、公式リポジトリのリンクを示すかどうか

「評価を回す意味がない」

　エージェントをゼロから立ち上げる段階では、開発者の勘とドッグフーディング（自社製品の社内試用）から始まる。エージェント自身を構成するコードベースを改善し、定型のコードを処理し、自前のMarkdownレンダラーを書き、日常的な開発作業をこなせるエージェントができるまでは、「評価を回す意味がない」とGoogleは説明している。

　評価は開発の第2段階に属する。前進を確かめ、退行を防ぐためのものだ。評価スイートの第一目的は、「エージェントが2％良くなったこと」を祝うことではない。新しいプロンプトの調整やツールスキーマの変更、モデルの更新が、「エージェントを全体として悪化させていない」という揺るがない確信を得ることにある。

中間の実行ステップを検証するテストを書く

　堅牢（けんろう）な評価フレームワークは、振る舞いに関する検証を、ローカルで動く高速で決定論的なユニットテスト形式のチェックに分離する。より小さく観察可能な行動に注目することで、信頼できるセーフティーネットを構築できる。中核となる行動を誤って壊してしまった場合でもすぐに把握できるので、システムプロンプトの改善を繰り返したり、別のモデルへ切り替えたりする作業を安心して進められる。

　行動評価は、特定のツール呼び出しやファイルの変更といった中間の実行ステップを検証する。Googleは例として、天気を尋ねられたエージェントが、学習済みの知識だけで回答せず、Web検索ツールを呼び出したかどうかを検証するテストコードを示している。

　行動評価のスイートが充実すれば、プロンプトエンジニアリングを自動化できる。例えば、失敗したテストに合格するまで、大規模言語モデル（LLM）に自身のシステムプロンプトを繰り返し調整させる。その間、他のテストはCI/CD（継続的インテグレーション／継続的デリバリー）のガードレール（安全対策）のように働き、変更によって既存機能が壊れていないかを確認する。

3段階のループで小さく始める

　繰り返し使える形にするために、Googleは3段階の行動テストのループから小さく始めることを勧めている。

1．1つの失敗モードを選ぶ

　エージェントが最近犯した間違い、例えばタスク完了を報告する前にユニットテストを実行し忘れたことを探す。実行されなかった明確な行動を1つ選び、それを標的にする。

2．タスクの複雑さに応じて柔軟な検証を書く

　最適解が1つに決まる単純なタスクでは、テストランナーを呼び出したかどうかなど、特定の節目に到達したかを確認する厳密な単一ターンの検証を組む。

　複雑なタスクでは、モデルが予想外でも完全に正しい経路を取ることがあるので、硬直したツールの実行順序を強制しない。LLMを審判役として使う「LLM-as-a-Judge」のような結果に基づく緩やかなチェックで、エージェントが選んだ手順が安全に問題を解決したかを評価する。

3．バッチ評価を自動化して安定性を監視する

　AIモデルの非決定性によってノイズが乗る単発の評価結果でプルリクエスト（PR）を止めるのではなく、バッチ評価を自動化してより多くのデータを集める。

　合格率の推移を追うことで、モデルの振る舞いが正しい方向に向かっているかどうかを確認できる。この方向性のシグナルに頼れば、想定内のばらつきで開発を止めることなく、プロンプトの調整やモデルの更新を安全に進められる。

　エージェント活用を始めるのに、ベンチマークスコアをさらに高める必要はなく、「必要なのはエージェントの挙動を厳しく検証できる評価ハーネスだ」とGoogleは述べている。安定して壊れにくいハーネスを作るには、モデルを最終試験の結果だけで評価するブラックボックスとして扱うのをやめ、ハーネスをユニットテストや統合テストを介する通常のソフトウェアとして扱う必要がある。

　行動評価はハーネスエンジニアリングの柱の一つだが、より大きなエンドツーエンドの評価スイートを置き換えるものではなく、互いを補完する関係にある。マクロなベンチマークが最終的な到達点を検証し、ミクロな行動評価が安全で素早い反復を可能にする相棒として働く。両方を採用することで、プロンプトの変更や新機能の構築、新しいモデルの投入といった場面で、より高い確信を持って改善を繰り返せるとしている。