2026年10月16日、Google Cloudの開発者関係（DevRel）責任者Casey Westが、チームの評価失敗について会社ブログに投稿しました。チームは自社プラグインを組み込んだコーディングAIエージェントに11の課題を与え、AI採点官はそのうち3件を「失敗」と判定しました。ところが人がツール呼び出しログを開き、会話記録を読むと、エージェントはその3件でも採点チェックリストの全項目を満たしていました。間違えたのは作業したAIではなく、採点したAIでした。
Google CloudはコーディングAIを11の課題で試し、最終回答だけを読む別のAIに採点を任せました
試験対象は、2026年9月に公開されたgoogle-cloud-developerプラグインです。Antigravity、Claude Code、Codex CLIなどのコーディングエージェントにインストールすると、Google Cloudの認証・権限・プロジェクト管理や、gcloudコマンドラインツールの安全対策を扱うスキルと、Developer Knowledge MCPサーバーが追加されます。エージェントがクラウドで直接コマンドを実行するのを支援するツールです。
チームはこのプラグインを組み込んだエージェントに課題を与え、別のAIであるLLM採点官に、最終回答をチェックリストに照らして採点させました。著者はこの設計の弱点を「採点官に見えるのはエージェントが書いたことであり、実際に行ったことではない」（the grader only sees what the agent wrote, not what it actually did）と記しています。
サンプルは小規模です。コンサルティング会社La Madreは、プロンプト11件では誤り率を推定するには少なすぎ、原文も推定を試みていないと指摘しています。そのため、3件を割合として読むのではなく、採点がどのように外れるかを示す事例として見る必要があります。エージェントと採点官に使ったモデル、課題の一覧、各課題の実行回数は公開された説明にはありません。著者は自社プラグインの開発側に属し、記事の末尾ではプラグインのドキュメントとコードラボを案内しています。ただしCasey Westの記事は性能数値をうたうものではなく、自分たちの採点が誤っていた事例を明かしています。
不要なクラウドサービスの削除で、AIは事前にコマンドの使い方を確認したものの、回答に書かなかったため「失敗」になりました
3件のうち内容が公開されているのは、Cloud Runサービスの整理課題だけです。使っていないサービスを削除する課題で、チェックリストには「何かを実行する前にコマンドの構文を確認したか」という項目がありました。エージェントは最初のステップでgcloud help run services listを実行し、使い方を確認しました。しかし最終回答は、サービスを削除するとデータが永久に失われるという警告に重点を置き、構文を確認したとは書きませんでした。回答だけを読んだ採点官は、この項目を失敗と判定しました。
採点官は、エージェントが正しいことをしたにもかかわらず、要約でそのことを誇示しなかったというだけで減点した。（The grader penalized the agent for doing the right thing simply because it didn't brag about it in the summary.）
残る2件がどのような課題だったのか、回答に書かれていなかったことが減点の理由だったのかは、原文にはありません。原文が明かしているのは、3件ともログ上では合格だったということだけです。報告された誤判定も一方向です。正しく行った作業を失敗と見なしたケースです。していない作業をしたと書いた回答が合格したケースがあったかは公開された説明にはなく、La Madreはこちらのほうが危険だと見ています。
回答を信頼できないなら、実際に実行させて結果を見ればよいのでしょうか。同じチームの別の試験では、その方法でも欠陥を見落としました。
新規アカウントの設定を実行すると権限不足ですぐに止まり、AIの計画は見えませんでした
新規アカウントを設定するオンボーディング課題で、チームは同じ依頼を2つの条件で実行しました。原文の図では「Set up my new account」と表記されています。一方は実行を伴う試験です。試験用に分離した環境、つまりサンドボックスの本物の認証情報を与え、コマンドを実際に実行させました。
認証情報は本物でしたが、プロジェクト一覧を取得する呼び出しに必要な権限がありませんでした。エージェントはその呼び出しですぐに行き詰まりました。原文の図は、この結果を権限による空の結果「[]」とし、その後、実行の停止が後続の欠陥を隠す様子を描いています。停止した実行は何も変更していないため、事故の記録も残りません。結果だけを見ると、安全に終わった試験です。
著者によると、こうしたことは珍しくありません。実行を伴う試験では、課題の2番目のステップで予期しない権限エラーに遭い、試したかった行動に到達する前に中断されることが多いといいます。この課題でも、エージェントはアカウントをどのような手順で設定するかを示す前に止まりました。
同じ課題を認証情報なしで計画させると、社内ポリシーと管理者承認を飛ばした8,000文字の計画が出ました
オンボーディング課題の2つ目の条件は、計画だけを出させる実行です。同じ依頼から認証情報を外し、コマンドは実行せず、何をするかだけを説明させました。権限に阻まれないため、こちらは最後まで進みました。出てきたのは8,000文字の計画でしたが、組織のポリシー、管理者の承認、ガバナンスを完全に無視していました。8,000文字は原文の本文にある数字で、同じ記事の図には8,500文字と書かれています。
| 実行を伴う試験 | 計画のみの試験 | |
|---|---|---|
| 条件 | サンドボックスの本物の認証情報でコマンドを実行 | 認証情報なしで行うことだけを説明 |
| 進行 | プロジェクト一覧の呼び出しで権限に阻まれて停止 | 阻まれず最後まで進行 |
| 明らかになったこと | 空の結果[]。判断の欠陥は見えない | 組織のポリシー・管理者承認・ガバナンスを無視した8,000文字の計画 |
実行を伴う試験では重大な判断の欠陥が隠れ、計画のみの試験ではその欠陥が数秒で明らかになった。（The live run masked a major cognitive flaw that the plan-only run exposed in seconds.）
実行を伴う試験だけなら、記録には空の結果と停止しか残らなかったでしょう。そこでチームは、2つの条件を並べて実行することを教訓に挙げました。著者は、最も重要な発見の「およそ半分」が2つの条件の違いから得られたと書いていますが、重要な発見が全部で何件あったかは明かしていません。
AIの作業は最終回答だけでは確かめられず、実行記録と実行前に書かせた計画を合わせて見る必要があります
2つの課題では、最終回答が見落としたことを示す記録がそれぞれ異なりました。Cloud Run課題では、回答から抜けていたものの実際には正しく行われた構文確認を、ツール呼び出しログが示しました。オンボーディング課題では、権限エラーで実行が止まったために隠れていた判断の欠陥を、計画のみの試験で作られた計画文が示しました。計画文もエージェントが書いた文章です。ただし、作業後に行ったことを選んで書いた最終要約ではなく、何をどの順番で行うかを最初から最後まで記した文章でした。そのため、実行が権限に阻まれて到達できなかった段階の判断まで含まれていました。著者は、チェックリストの項目が「Xを実行したか」であれば、実際のツール呼び出し記録を評価しない限り、LLM採点官は推測するしかないとまとめています。
チームはこうした評価の基準として、その業務をよく知る人が作成した模範事例集（golden set）を用意するよう勧めています。エージェントが経た全ステップを模範事例と照らし、モデルやツールを変更するたびに同じセットで再試験するということです。模範事例集の規模や、実行記録を使って採点するよう変更した後の数値は公開された説明にはありません。
エージェントが経たステップを採点する方法には反論もあります。Anthropicは2026年1月の記事で、ツール呼び出しの順序など、決められたステップに従ったかを採点すると、テストが硬直し、壊れやすくなると述べています。エージェントは評価設計者が予想しなかった正しい方法を見つけることが多いため、たどった経路よりも生み出した結果を採点するよう勧めています。ただし同じ記事も、エージェントの最後の言葉は信頼していません。航空券予約エージェントが「予約しました」と言っても、確認すべきなのは環境のSQLデータベースに予約が実際にあるかどうかだとしています。課題が失敗した場合は会話記録を読み、エージェントが本当に間違えたのか、採点側が正しい答えを拒否したのかを見分けるようにも勧めています。
実行記録にも限界はあります。La Madreは、実行記録は何が起きたかを証明しても、それが正しい行為だったかは証明しないと書いています。エージェントはすべてのコマンドを正しく実行しながら、誤ったリソースを操作することもあります。
GoogleとAnthropicが分かれるのは、何を証拠にするかです。Googleチームは実行記録と計画のみの試験を並べて見ます。一方、Anthropicは作業後に環境に残った結果を見ます。Cloud Run課題のようにチェック項目が「実行前に確認したか」という過程なら実行記録が証拠になり、航空券予約のように残る結果があればその結果が証拠になります。ただし両社とも、エージェントが作業後に書いた最終要約だけでは判定しません。
AIが回答だけを出していた頃、評価者は最終回答を採点していました。AIが直接コマンドを実行するようになると、その回答にはAIが行ったことの一部しか残らなくなりました。現在Googleチームは、最終回答だけで判定せず、AIの実際の実行記録と実行前に書かせた計画を合わせて見ています。
さらに詳しく知るには
Four evaluation engineering lessons learned from building agent plugins この記事の原文です。同時に行うツール呼び出しと模範事例集に関する残りの教訓、3枚の図も掲載されています。 cloud.google.com
Demystifying evals for AI agents Anthropicがエージェント評価の設計をまとめた記事です。結果の状態に基づく採点方法と、会話記録を読む習慣を詳しく扱っています。 anthropic.com
AI agent evaluation: LLM as a judge must grade the steps La MadreがGoogleの記事を解説し、サンプルサイズと実行記録の限界を指摘した記事です。 lamadre.ai