AIエージェントは、最終回答だけ見れば「成功」に見えることがあります。しかし、権限外のツールを使ったのか、無駄な試行を重ねたのか、実はデータが更新されていなかったのか——そんな過程を見落とすと、本番では静かに事故が育ちます。
いま必要なのは、回答の採点ではなく仕事の完了状態と過程を測る評価設計です。Anthropicのエージェント評価ガイドとOpenAIの評価ドキュメントを手がかりに、実務で使える形へ整理します。
「良い回答」と「仕事が終わった」は別です
Anthropicは、エージェント評価で記録すべき対象を大きく「トランスクリプト」と「アウトカム」に分けています。
- トランスクリプト：出力、ツール呼び出し、中間結果など、実行過程の記録
- アウトカム：処理後に環境へ残った最終状態
たとえば予約エージェントが「予約しました」と返しても、データベースに予約がなければ失敗です。逆に、最終文面が少し不格好でも、正しい予約を安全に作成できていれば、業務上の核心は達成しています。
つまり評価は、次の3層に分けると見通しが良くなります。
- 結果：期待する状態になったか
- 過程：許可された手順・ツールで進めたか
- 品質：説明、配慮、読みやすさは十分か
1回の成功率を信用しすぎない
生成AIの出力には揺らぎがあります。Anthropicは、1つの課題を「task」、その課題への各試行を「trial」と区別し、複数回の試行から性能を見る考え方を示しています。
これは自動車の安全性評価にも似ています。テストコースで一度うまく走れたことと、条件を変えても安定して走れることは同じではありません。AIも、同じ入力で1回通っただけでは再現性を判断できません。
少なくとも重要な処理では、成功件数だけでなく、失敗の種類、所要時間、ツール呼び出し回数、コストも並べて確認すべきです。
評価器は3種類を組み合わせる
Anthropicは、評価器をコードベース、モデルベース、人間の3種類に整理しています。それぞれ得意分野が違います。
- コード：テスト、状態確認、形式検査。速く、安く、再現しやすい
- 別のAI：説明の明確さや配慮など、自由文の評価に向く
- 人間：専門判断や最終校正。精度は高いが、時間と費用がかかる
おすすめは「機械で確認できることをAIに採点させない」設計です。ファイルが作られたか、テストが通ったか、DBが更新されたかはコードで判定し、文章品質のような曖昧さが残る部分だけを別AIや人が見ます。
能力評価と回帰評価を分ける
Anthropicは、評価を「能力」と「回帰」に分けています。
- 能力評価：「今までできなかった難しい仕事ができるか」
- 回帰評価：「以前できていた仕事を今も壊していないか」
新モデルで難問の成功率が上がっても、定型処理や安全確認が悪化すれば、その更新は本番向けとは限りません。難しい課題で伸びしろを測りつつ、既存業務は高い合格率を維持する。2つを同じ平均点に混ぜないことが大切です。
最小構成は「仕様→データ→採点→反復」
OpenAIの公式ドキュメントは、評価の基本を、課題の定義、テスト入力での実行、結果の分析と改善という流れで説明しています。実務では、次の小さなループから始められます。
- 実際に起きた失敗を10件集める
- 各ケースの期待結果と禁止事項を書く
- 状態確認などの自動評価を先に作る
- 変更前後を同じ条件・複数試行で比べる
- 直った失敗を回帰テストへ残す
評価データは「完成してから作る資料」ではありません。何を成功とするかをチームで合意する、実行可能な仕様書です。
まとめ
AIエージェントの評価で見るべきなのは、きれいな最終回答だけではありません。
- 環境の最終状態で、本当に仕事が完了したか確認する
- 実行過程を記録し、危険な近道や無駄を見つける
- 複数試行で揺らぎを測る
- コード、別AI、人間を役割分担する
- 能力評価と回帰評価を分ける
モデルを強くする前に、合格条件を強くする。これが、AIエージェントを「デモ」から「任せられる仕組み」へ変える近道です。