AI エージェント評価は、あとから足す項目ではなく導入ゲートになっていく

評価セットが増えるほど、task ごとの難しさが分解された

AgentBench は多種の tool task を、GAIA は一般 assistant の実用問題を、SWE-bench は issue resolution を、OSWorld は desktop action を測った。ひとつの総合スコアではなく、workflow ごとの failure mode を見る必要があることがはっきりした。

guardrail は model の外側に置くべき論点になった

Anthropic の Building effective agents と computer use 系の source は、途中観測と手前の制御を別レイヤーとして持つ必要を示した。高性能な model を選んでも、trace と escalation がなければ実務導入は難しい。

適用範囲を絞った team のほうが rollout しやすい

当時の公開根拠を並べると、成功に近いのは万能 agent を目指す構成より、support triage、research summary、issue routing のような bounded workflow に agent をはめる構成だった。評価のしやすさが導入速度を決めている。

リサーチ・ダイジェスト作成

• 公開資料の収集、分類、比較、初稿生成を行い、人が根拠を確認して仕上げる。
• 評価しやすいのは、引用形式や粒度をあらかじめ固定できる workflow である。

問い合わせ一次切り分け

• 意図分類、FAQ 検索、回答案の下書き、必要時のエスカレーションを担う。
• 曖昧案件だけ人へ戻す条件を固定すれば、導入ゲートを作りやすい。

SWE-bench は『コード生成できる』と『issue を解ける』の差を明確にした

issue を理解し、relevant file を探し、patch を作り、test を実行して初めて task completion になる。この差分があるため、社内でも code assistant を導入するなら snippet quality ではなく end-to-end issue handling を eval したほうがよいことが読み取れる。

BrowserGym と OSWorld は、環境が変わるだけで難易度が変わることを示した

browser task で通る agent が desktop task では崩れる、あるいはその逆が起きうる。つまり『agent が得意か』ではなく、『どの environment と permission model に対して安定か』を測らないと、導入可否を誤る。

support triage のような bounded workflow は eval を設計しやすい

意図分類、根拠文書の参照、回答案の下書き、human escalation の 4 step に分けると、どこで失敗したかを trace で追いやすい。これは research benchmark から production eval へ写しやすい実務例だった。