AIエージェントの評価における課題とGoogleの提言
AIエージェントのスキル開発が加速する中で、その評価方法が重要視されています。多くの開発者が、SKILL.md ファイルを作成し、手動でプロンプトをテストするだけでメインブランチにマージする傾向にあるとGoogleは指摘しています。しかし、これはコンテキストウィンドウを不必要に肥大化させ、大規模言語モデル（LLM）のパフォーマンスを低下させるだけでなく、誤った評価結果につながる可能性があると警鐘を鳴らしています（Google Cloud Blog）。
プロンプトをチャットに貼り付け、一度パスするのを確認してメインにマージするだけでは、適切な評価とは言えません。
Googleは、自社のGoogle Cloud Developer Plugin開発を通じて得た知見を元に、効果的なスキル評価のための5つのエンジニアリングプレイブックを公開しました。これらのルールは、GeminiやAntigravityといったエージェントを多数のシナリオで検証し、Claude Sonnet 5をGKE Autopilot上の隔離された環境で利用するなど、厳格なテストを経て確立されたものです。
スキル評価の5つのルール
Googleが提唱するスキル評価のルールは以下の通りです。これらのルールは、AIエージェントのスキルがトークンに見合う価値があるかを検証するために用いられます。
-
トリガーの競合とセキュリティリスクを事前検知する 評価でプラグインとベースラインの改善がゼロ（Δ = 0）の場合、真っ先にSKILL.mdの本体を修正したくなりますが、その前にやるべきことがあります。多くのケースで、エージェントがそもそもスキルをロードしていない可能性があります。コーディングエージェントは、最初にSKILL.md全体を読むわけではなく、YAMLフロントマターの短い名前と説明だけを確認します。ワークスペースにスキルが10個以上あると、「トリガーの不足」（説明が開発者の意図ではなく内部実装を表す）と「兄弟ハイジャック」（「クラウドデプロイメントを支援」のような広いフレーズが別のスキルで先にプロンプトを傍受する）という2つの失敗モードが発生します。 Googleは、
skill-reachというオープンソースツールを公開し、コンテナサンドボックスを使用する前にフロントマターの競合を検出できるようにしました。これは、マニフェストを検証し、最も近い競合スキルとの語彙の重複を計算し、Claude Code、Google Antigravity、OpenAI Codexで経験的なルーティングプローブを実行します。また、NVIDIAのSkillSpectorと組み合わせることで、プロンプトインジェクション、サイレントデータ漏洩、ツールポイズニング、トリガー乱用といったエージェント固有のリスクも検出できます。 -
開発者ラップトップでの評価は信頼しない ワークステーションで直接スキルベンチマークを実行すると、その数値は信用できないものになります。開発者のラップトップは、キャッシュされたGoogle Cloud認証情報、エクスポートされたプロジェクト変数、温かいbash履歴、グローバル環境ルールなど、ベースラインを汚染する環境状態が満載だからです。支援なしのベースラインエージェントは、ローカルシェルプロファイルにあるデフォルトのプロジェクトIDやトークンを継承することで、スキルが解決しようとしている正確な失敗を隠蔽し、クラウドデプロイメントテストに合格してしまう可能性があります。 また、ホストリソースの競合もエージェントの挙動を歪めます。内部テストでは、ワークステーションがCPU負荷の高い状態で全く同じエージェントベンチマークを実行すると、スコアが低下することが示されました。ファイルスキャンが遅くなったり、サブプロセスがタイムアウトしたりすると、エージェントは探索パスを途中で放棄してしまうことにつながります。
-
Pass@3でアブレーション測定し、感覚で判断しない プロンプトを単一回実行し、緑色のチェックマークのスクリーンショットを撮るだけでは、本当の評価ではありません。マルチターンツール使用エージェントは、シェル終了コードと標準出力のスニペットごとに分岐します。Googleの検索研究では、ベンチマークタスクの3分の1以上が、まったく同じコードとプロンプトを連続して実行しても異なるスコアを出すことが判明しました。 比較対象となるペアベースラインがない完璧なスコアも同様に無意味です。Claudeのプラグイン評価ツールとNVIDIAのSkillEvaluatorは、複数回の繰り返しでペアアブレーションを実行します。アームAはクリーンなサンドボックスでスキルなしのベースモデルを実行し、アームBはスキルありで実行します。これは、以前私が記事を執筆した「Physical-Engineering's Last Exam (PLE)」のようなベンチマークでも重要な考え方だと感じます（Google Cloud Blog）。
Googleはこれらの他にも2つのルールを提唱しており、詳細は元記事に譲りますが、本質的には「コンテキストウィンドウを肥大化させないための厳格な評価」という点に集約されると感じます。
今後の展開：より厳格な評価がAIエージェントの普及を加速させる
Googleがこのような詳細な評価ガイドラインを公開したことは、AIエージェントの品質と信頼性を向上させる上で非常に重要な一歩だと考えます。今後、skill-reachやNVIDIAのSkillEvaluatorのような評価ツールの普及が進むことで、より多くの開発者が効率的かつ堅牢なAIエージェントを構築できるようになるでしょう。特に、マルチターンで複雑なタスクをこなすエージェントにとって、曖昧な評価は致命的なバグにつながりかねません。
InfoQの記事でも指摘されているように、信頼性の高いエージェントAIアーキテクチャは、コンテキストエンジンが情報を選択、注入、圧縮、有効期限切れさせることに依存します。トークン予算の最適化は、まさにこの文脈で非常に重要な要素です（InfoQ）。
今後は、開発ツールと評価フレームワークの連携がさらに深まり、AIエージェントが企業システムや個人プロダクトに組み込まれる際のハードルが下がっていくのではないでしょうか。この動きは、AIエージェントの本格的な普及を後押しすると予測しています。
エンジニア目線で見ると：コストと信頼性のバランスが重要
今回のGoogleの発表は、AIエージェント開発に携わるエンジニアにとって非常に示唆に富む内容だと感じます。特に、個人プロダクトでAIエージェントを試している私のような開発者にとって、ローカル環境での「感覚的な」評価がどれほど危険か、改めて認識させられました。
GCPを主軸に使っている身としては、GKE Autopilot上で隔離された環境を簡単に構築できるのは大きなメリットです。skill-reach のようなツールがオープンソースで提供されるのは非常に歓迎すべき動きではないでしょうか。手動での確認では見落としがちなトリガーの競合やセキュリティリスクを、開発の早い段階で検出できるのは、時間とコストの節約に直結します。
また、為替の変動でクラウドの利用コストに敏感になっている昨今、無駄なコンテキストウィンドウの肥大化は避けたいところです。単にSKILL.mdの命令文を増やすのではなく、YAMLフロントマターの記述や、適切なスキルルーティングの設計がいかに重要か、再認識させられます。自分のアプリにエージェント機能を組み込む際には、Pass@3のような厳密な評価指標と、クリーンなサンドボックス環境でのテストを徹底したいと強く思います。
