振る舞い評価とは、タスク全体をエンドツーエンドで解決できたかどうかを採点するのではなく、AI エージェントが実行中に取る個別の観測可能な行動に対してアサーションを行うことで、エージェントを測定するプラクティスである — 仕様が不十分なプロンプトを与えられたときに確認の質問をしたか、ビルドファイルの変更を完了と宣言する前にローカルのバリデーターを実行したか、記憶から答えるのではなくライブ検索を参照したか、といった行動である。Google のエンジニアたちは、このような評価を、エージェントのハーネスの動作を改善するための統合テストのように機能するものとして説明しており、最終的な文字列の一致ではなく、特定のツール呼び出しやファイルの変更といった途中の実行ステップに対してアサーションを行う。
用法
このプラクティスが対比として定義される相手は、エンドツーエンドのベンチマークである。Google のエンジニアたちは、一般的なアプローチを、試験を受ける学生を評価するようにエージェントを評価するものだと特徴づける — 大きなコードベースを渡し、制限時間を課し、何件のテストが通ったかで採点する — そして、その結果得られる複合スコアが数パーセントポイント動いたとき、こうしたベンチマークは通常、その理由に直接答えてはくれないと論じる。答えられないまま残るものとして彼らが挙げる例は、曖昧なプロンプトに対してモデルが自信過剰になったのか、提出前にテストスイートの確認を忘れたのか、存在しない CLI フラグをハルシネーションしたのか、といったことである。
彼らの説明では、振る舞い評価のアーキテクチャは、振る舞いに関するアサーションを、ローカルで実行される高速で決定論的な単体テスト風のチェックへと切り分ける — 彼らの例では、ローカルの振る舞いスイートが 5 秒未満で実行される。十分に豊富なアサーションがあれば、チームは狙っている振る舞いのベースラインを持つことになり、中核的な振る舞いが壊れたらすぐに分かる状態で、システムプロンプトを反復改善したりモデルを切り替えたりできる、と彼らは論じる。さらに彼らは、このスイートによってプロンプトエンジニアリングを自動化できると示唆している。LLM が失敗しているテストが通るまで自らのシステムプロンプトを調整し、その間、スイートの残りの部分が既存の機能を壊さないための CI/CD 風のガードレールとして働く、というものである。
別のベンダーは、この用語を使わずに、同じ形のチェックをより狭い対象について説明している。OpenAI の Evals で Agent Skills を体系的にテストする は、これを OpenAI Codex のエージェントスキルに適用している。各 eval はエージェントをあるプロンプトで実行し、その行動を構造化された JSONL のイベントトレースとして記録し、そのトレースを決定論的なチェックで採点する — エージェントが npm install を実行したか、package.json が作成されたか、期待されるコマンドが期待される順序で実行されたか、といったチェックである。この記事は「プロセスゴール」— エージェントがスキルを呼び出し、意図されたツールと手順に従ったか — を、アウトカム、スタイル、効率のゴールと並んで、最初に定義しておくべき 4 種類の成功の一つとして挙げており、失敗をトレースを開いてすべてのコマンド実行を順に読むことで説明できるという理由から、こうしたチェックを重視している。Google のエンジニアたちと同様に、固定のチェックでは捉えられないものについてはモデルによる採点のステップを加えている。2 回目の読み取り専用の実行で、スタイルと規約をルーブリックに照らして採点し、結果を実行間で比較できるよう JSON スキーマに制約するというものである。また、スキルの実行だけでなく発動についてもテストしており、スキルが過剰に発動するのを捉えるために、少なくとも一つの陰性対照 — スキルを呼び出すべきでないプロンプト — を含む小さなプロンプトセットを用いる。
適用される場面
Google のエンジニアたちは、こうした評価をエージェント開発の第 2 段階に位置づけている。彼らが示す前提は、エージェントをゼロから立ち上げる際には、チームは開発者の直感とドッグフーディングから始めるということであり、エージェントが自らのコードベースをドッグフーディングできるようになるまで — ボイラープレートを処理し、自分用の Markdown レンダラーを書き、日常的な開発タスクを実行できるようになるまで — 評価を実行すること自体に意味がないということである。eval は前進を確実にし、リグレッションを防ぐためのものであり、スイートの主な目的は 2% の改善を祝うことではなく、プロンプトの微調整、ツールスキーマの変更、モデルのアップグレードがエージェントを全体として悪化させていないという確信を与えることだ、と彼らは述べている。
このプラクティスは、エージェントの途中のステップが観測可能でアサーション可能であること — 彼らの例では、レスポンスで返されるツール呼び出しに対してアサーションを行っている — そして、チームが保持する価値のある具体的な振る舞いを名指しできることを前提としている。彼らが提案する出発点は 3 ステップのループである。エージェントが実際に犯した最近の誤りから失敗モードを一つ選ぶこと、タスクの複雑さに見合ったアサーションを書くこと、そして安定性を監視するためにバッチ評価を自動化することである。
彼らは、このプラクティスが誤って適用される 2 つのあり方を明示している。固定のツールシーケンスに対して硬直した単一ターンのアサーションを書くことは、モデルが予想外だが完全に正しい経路をとりうる複雑なタスクではうまくいかない — そうしたタスクには、LLM-as-a-Judge のような、よりあいまいさを許容するアウトカムベースのチェックを推奨している。また、単発の eval 実行でプルリクエストをブロックすることは、モデルの非決定性によって結果にノイズが多いため妥当ではない。彼らは、集計した合格率を時間とともに追跡し、その方向性のシグナルを行動の根拠として扱うことを推奨している。
どの程度確立しているかについていえば、Google の説明は一つのエンジニアリングチームが推奨するプラクティスであり、雇用主の開発者ブログで公開され、自社の SDK で例示されたものであって、測定された結果でも業界のコンセンサスでもない。OpenAI のガイドも同じ種類の情報源であり、ベンダーが自社のエージェントについて推奨するプラクティスで、測定結果は報告していない。OpenAI 版も段階的な出発点を共有しており、単一のスキルについて 10〜20 のプロンプトを推奨し、実際の失敗からセットを増やし、ビルドやランタイムのスモークテストのような遅いチェックはリスクを下げる場合にのみ追加するとしている。彼らは、これをより大規模なエンドツーエンドのスイートを置き換えるものではなく補完するものとして慎重に提示している — 彼らの枠組みでは、マクロなベンチマークは最終的な到達点を検証し、ミクロな振る舞い評価は安全で迅速な反復を可能にするのであり、推奨は両方を採用することである。
関連用語
- ハーネスエンジニアリング — これらの評価が役立つ、より広い分野
- LLM-as-a-Judge — 複雑なタスクに推奨される、よりあいまいさを許容するアサーションのスタイル
- 軌跡評価 — 出力だけでなくエージェントが何をしたかを見る、もう一つのアプローチ
- 検証ループ — エージェントの作業をチェックすることに関する一般的な関心事