PR：本記事にはアフィリエイト広告（プロモーション）を含みます。
AIエージェントの評価とは、最終回答の正しさだけでなく、試行の途中の記録、ツール呼び出し、終了時の環境の状態を分けて測ることです。エージェントは同じ課題でも毎回違う手順を通るため、1つの正解文と突き合わせるだけの方式が成立しにくくなります。
手順の順番まで採点しようとする評価は壊れます。合否は終了時の環境の状態を照合して取り、途中の経路は失敗の理由を説明するために使う、という配分が実務的な出発点になります。
- トランスクリプト（経路）＝どう考え、何を呼び、どこで外れたかの全記録
- ツール呼び出し＝正しい道具を選んだか、呼ぶべき時に呼んだか
- アウトカム＝試行が終わった時点で環境に残っている状態
AIエージェントの評価は、LLMの評価と何が違うのか？
測る対象の数が違います。LLMの評価は入力に対する出力を1つ見れば済みますが、エージェントは応答するまでに複数の行動を取るため、最終出力と一連の行動の両方を見ることになります。Googleは、モデルが確率的である以上、決定論的な合否の断定はエージェントの評価に適さないことが多いと述べています。
Googleの公式ドキュメントは、必要になるのは最終出力とエージェントの軌跡の両方に対する質的な評価だとしています。軌跡という語も同じ資料が定義しており、利用者へ応答する前にエージェントが取る一連の行動を指します。用語の例として挙がるのは、過去のやり取りと照らして曖昧な言葉を特定する、規程文書を引く、知識ベースを検索する、APIを呼んで記録を残す、といった行動です。
行動の記録はトレースと呼ばれます。OpenAIの公式ドキュメントは、1回の実行のトレースがモデル呼び出し・ツール呼び出し・ガードレール・引き継ぎの端から端までの記録を含むと説明しています。
| 対象 | 測るもの | 代表的な失敗の形 |
|---|---|---|
| LLM単体 | 入力に対する出力1つ | もっともらしいが誤っている文が返る |
| RAG | 検索が必要な文書を引けたか、その文書に沿って答えたか | 文書は引けているのに答えが外れる |
| AIエージェント | 経路・ツール呼び出し・終了時の環境の状態 | 「やりました」と答えるが環境が変わっていない |
RAGの回答品質をどう測るかは本記事の対象ではありません。検索・データ・生成のどこで落ちているかを順に切り分ける手順はRAGの精度が上がらない原因は？検索・データ・生成で切り分けるで扱っています。
そもそも何をエージェントに任せるべきかという手前の判断も、本記事では扱いません。ワークフローとの違いと導入の条件はAIエージェントとは？ワークフローとの違いと実務で使う条件で整理しています。
AIエージェントの何を測ればよいのか？
3つに割ります。試行の全記録であるトランスクリプト、その中のツール呼び出し、そして試行が終わった時点の環境の状態であるアウトカムです。Anthropicは、航空券を予約するエージェントが「予約しました」と答えても、アウトカムは環境のデータベースに予約が存在するかどうかだと説明しています。
評価の骨組みを作る単位も同じ資料が定義しています。Anthropicによれば、タスクとは入力と成功条件が定義された1つのテスト、試行とはタスクへの1回の挑戦、採点者とはエージェントの性能の一側面を採点するロジックです。より安定した結果を得るために複数回の試行を走らせること、そして1つのタスクに採点者を複数付けられることも、同じ資料に書かれています。
トランスクリプトの定義は範囲が広く取られています。Anthropicは、トランスクリプト（トレース、あるいはトラジェクトリとも呼ばれる）を、出力・ツール呼び出し・推論・中間結果・その他のやり取りを含む試行の完全な記録だと定義しています。
アウトカムの定義が、エージェント評価をLLM評価から引き離す部分です。Anthropicはアウトカムを試行終了時の環境の最終状態と定義し、航空券予約の例で「予約しました」という発話とデータベース上の予約の有無を区別しています。エージェントの自己申告と、環境に実際に起きた変化は別物として扱う、という切り分けになります。
| 測る対象 | それで分かること | 向く採点方法 |
|---|---|---|
| トランスクリプト（経路） | どう考え、何を呼び、どこで外れたか | モデルによる採点・人の確認 |
| ツール呼び出し | 正しい道具を選んだか、呼ぶべき時に呼んだか | コードによる照合 |
| アウトカム（終了時の環境の状態） | 実際に仕事が終わったか | コードによる照合 |
3つのうち合否の主軸になるのはアウトカムです。Anthropicが採点者を「トランスクリプトかアウトカムのどちらかを評価するもの」と整理していることから考えると、経路とツール呼び出しは、アウトカムが不合格だったときにどこで外れたかを説明する材料として効きます。
特定のツールを使ったかどうかは、記録を見れば真偽で答えが出る評価ポイントになります。呼ばれるべき道具が呼ばれたかを条件として置いておくと、私の実務では評価が強固になり、エージェントの動きを任意の形に制御できるようになります。
本記事が扱うのは、記録が残っている前提での採点の方法だけです。エージェントの行動をそもそも何の単位で記録に残すか、どのシステムへ書き出すかという設計は別のテーマになります。
途中の経路は、どこまで採点すべきか？
手順の順番までは採点しません。Anthropicは、正しい順序のツール呼び出しの並びに従ったかを確かめたくなる本能は共通しているとしたうえで、この方法は硬すぎて過度に脆いテストになると述べています。エージェントは設計者が想定しなかった妥当なやり方を頻繁に見つけるためです。
同じ資料は代わりの方針も1行で示しています。多くの場合、通った経路ではなく、エージェントが生み出したものを採点するほうがよい、という記述です。
では経路は何のために見るのか、という問いにOpenAIの公式ドキュメントが答えています。同社はトレース採点を、判断・ツール呼び出し・推論の端から端までのログに対して、正しさ・品質・期待への適合を測る構造化された点数やラベルを与える作業だと定義しています。ブラックボックスの評価と違い、トレースの評価はエージェントが成功または失敗した理由を理解するための材料を多く与える、とも書かれています。
順序ではない形なら、経路に対して採点できます。OpenAIの公式ドキュメントが採点する問いの例として挙げているのは3種類で、正しいツールを選んだか、引き継ぐべきときに引き継ぎが起きたか、指示や安全方針に違反していないか、という問いです。
ここから配分が決まります。経路は合否の主軸ではなく、失敗の説明に使う、という置き方です。アウトカムが不合格のとき、経路を見れば道具を選び間違えたのか、道具は正しいが渡した入力が悪かったのか、そもそも呼んでいないのかを分けられます。
理想の軌跡との比較も、同じ考え方で運用できます。Googleは、エージェントの性能評価には実際の軌跡を期待される理想の軌跡と比較することが必要になると述べています。比較の対象を「同じ順番か」ではなく「必要な行動が含まれているか」に置き換えると、妥当なやり方の幅を潰さずに済みます。
例えば、社内の申請を処理するエージェントが、規程を先に引いてから残高を確認する経路と、残高を確認してから規程を引く経路の両方を通る、という状況が考えられます。想定例として、どちらの順番でも申請の可否が正しく決まるなら、順番を合否条件にせず、2つの行動が両方含まれていることだけを採点対象にする形が取れます。
経路が悪いときの直し方そのものは本記事の対象外です。何をいつモデルへ渡すか、道具をどう設計するかはコンテキストエンジニアリングとは？RAG・メモリ・ツールの設計で扱っています。
「できました」という回答が本当かは、どう確かめるのか？
環境の状態を目標の状態と突き合わせます。2024年6月に公開されたτ-benchの論文は、会話の終了時点のデータベース状態を、あらかじめ注釈しておいた目標状態と比較する、効率的かつ忠実な評価プロセスを採ったと述べています。エージェントの自己申告ではなく、環境に残った変化を見る方式です。
照合を担当するのはコードによる採点者です。Anthropicは採点者をコードによるものとモデルによるものに分け、コードによる採点の中身として3種類を挙げています。文字列一致の確認、アウトカムの検証、状態の確認です。
コードによる採点の性質も同じ資料が整理しています。強みは速い・安い・客観的・再現できることで、弱みは期待した形と完全には一致しない妥当なゆらぎに対して脆いことです。
終了状態の照合は、エージェント評価で唯一「安く、毎回同じ結果で」回せる部分になります。Anthropicが挙げた再現性という強みと、τ-benchが採った目標状態との照合方式から考えると、測れる終了状態を1つ決めることが評価設計の最初の作業になります。
例えば、問い合わせ対応のエージェントに記録の登録まで任せる、という構成が考えられます。想定例として、応答文の良し悪しを測る前に、指定した項目が登録されているかどうかという1つの終了状態を先に決めておくと、合否の判定がコードだけで完結します。
終了状態が定義できない仕事は、どう扱うのか？
成果物そのものをモデルによる採点に回すことになります。調査・要約・提案のように環境に残る変化が無い仕事では、照合すべき最終状態を定義できないためです。
代償は採点の性質から出ます。Anthropicはモデルによる採点を、柔軟で拡張しやすく機微を捉えられる一方、非決定論的でコードによる採点より高価だと整理しています。終了状態が定義できない仕事ほど、採点のコストと不確かさが上がる、という判断軸になります。
任せる仕事を設計する段階で、測れる終了状態を作れるかどうかを先に見ておくと選択肢が増えます。同じ調査業務でも、結果を所定の形式で保存させる工程まで含めれば、保存されたかどうかという照合可能な終了状態が1つ生まれます。
採点はコードとLLMのどちらにやらせるのか？
対象ごとに割り当てます。Anthropicは採点者をコードによるものとモデルによるものに分け、前者は速く・安く・再現できる一方、後者は柔軟で機微を捉えられるが非決定論的でコストが高いとしています。1つのタスクに採点者を複数付けられるとも同じ資料は述べており、二者択一にはなりません。
モデルによる採点の中身も整理されています。Anthropicが挙げるのは3種類で、評価基準表に沿った採点、自然言語で書いた主張が満たされているかの判定、2つの出力を比べる採点です。
| 測る対象 | 既定の採点者 | モデルに回すのはどんな時か |
|---|---|---|
| アウトカム | コード | 終了状態が環境に残らない仕事のとき |
| ツール呼び出し | コード | 呼ぶべきだったかの判断が文脈に依存するとき |
| トランスクリプト（経路） | モデル・人 | — |
配分が偏ると、評価そのものの性質が変わります。Anthropicがモデルによる採点を非決定論的だとしていることから考えると、モデルに回す割合が増えるほど、同じ出力に対する点数が試行ごとに揺れやすくなります。
評価が揺れると、改善したかどうかが判定できなくなります。エージェント側の変更による差なのか、採点側の揺れなのかを分離できないためです。設計は、コードで測れる対象をできるだけ増やす方向へ寄ります。
エージェントにレビューを任せる構成では、返ってくるのが文章なので採点が難しくなります。それでも決定論的に測れる採点者を必ず1つは残す、というのが私の実務での置き方です。数値が1つも出ない評価は、暗中模索の改善に入って終わりなき戦いになります。
定量化の入口は難しくありません。出力に必ず入っているべき単語が拾えているか、文章の長さと密度が想定の範囲に収まっているか、といった形で、私は必ず数値で表せる部分を残します。
モデルの判定だけを重ねる構成には、誤差の伝播という弱点が残ります。採点の一段一段に確率的なずれが乗るため、私が信頼の根拠に置くのは数値で表せる側の結果です。
同じ課題でも結果がぶれるのは、どう扱えばよいのか？
1回の合否ではなく、複数回の試行で測ります。Anthropicは、pass@1が50%とは評価内のタスクの半分に初回で成功する状態を指すと説明し、1回あたりの成功率が75%でも3回すべてを通す確率は(0.75)³で約42%になると示しています。1回動いたことと、任せられることは別の話になります。
複数試行を前提にした指標も提案されています。2024年6月に公開されたτ-benchの論文は、複数試行にわたるエージェントの挙動の信頼性を測る新しい指標としてpass^kを提案しました。
同じ論文は当時の測定値も報告しています。2024年6月時点の測定として、gpt-4oのような当時最先端の関数呼び出しエージェントでもタスクの50%未満しか成功せず、一貫性も低い（小売の設定でpass^8が25%未満）と述べられています。モデルは入れ替わるため数値そのものは古くなりますが、同じタスクを繰り返すと成功率が大きく落ちるという構図は指標の設計思想として残ります。
合格ラインは1つの数字ではなく、「何回中何回」という形を取ります。Anthropicが示した(0.75)³の計算とτ-benchのpass^kから考えると、取り消しのきかない操作を任せる構成ほど、初回の成功率ではなく複数試行での一貫性で見る必要が出ます。
評価のばらつきは、エージェントのせいなのか？
環境が原因の場合があります。Anthropicは、各試行を綺麗な環境から始めて分離すべきだとしたうえで、実行間で不要に共有された状態が、エージェントの性能ではなくインフラの不安定さによる相関した失敗を生むと述べています。例として挙がるのは、残ったファイル、キャッシュされたデータ、資源の枯渇です。
共有された状態は逆向きにも働きます。同じ資料は、共有された状態が性能を人為的に高く見せることもあると述べています。前の試行が作った中間結果が残っていれば、本来は失敗するはずのタスクが通ってしまうためです。
前提条件も明示されています。Anthropicは、評価の中のエージェントが本番のエージェントとおおよそ同じように機能し、環境自体がさらなるノイズを持ち込まないことが不可欠だとしています。評価用に簡略化した構成で測った数字は、本番の判断材料にならない、という線引きになります。
評価の種類によって、期待する通過率も変わります。Anthropicは、回帰の確認に使う評価はほぼ100%通るべきであり、能力を測る評価は低い通過率から始めてエージェントが苦戦するタスクを狙うべきだとしています。目的が逆の2種類を同じ集合に混ぜると、どちらの数字も読めなくなります。
評価の設計は、資料を読んで型どおりに組めば終わる作業にはなりません。測る対象の割り方も採点者の当て方も、手を動かした回数で精度が変わります。エージェントの評価設計は経験値がものを言う領域で、そのまま大きな専門性になるというのが私の見立てです。
よくある質問
公開されているベンチマークのスコアで、自社のエージェントの評価は代用できますか？
代用できません。公開ベンチマークは共通の環境と課題で複数のシステムを比べるための仕組みであり、自社の業務手順・データ・許容できる失敗の種類は含まれていないためです。参考になるのは測り方の設計で、τ-benchが採った「会話終了時のデータベース状態を目標状態と照合する」という方式は、自社のタスクにそのまま移植できます。
本番の監視をしていれば、評価は作らなくてよいですか？
役割が違うため置き換えになりません。Anthropicは、自動化された評価が反復を速くし、コミットごとに走らせられる一方、本番の監視は合成された評価が取りこぼす問題を捉え、エージェントが実際にどう振る舞っているかについての基準を与えると整理しています。変更を出す前に落とすのが評価、出した後に気づくのが監視、という分担になります。
採点を自動化したら、人が中身を読む作業はなくせますか？
なくせません。Anthropicは、多くの試行のトランスクリプトと点数を読まない限り採点者がうまく働いているかは分からないとしたうえで、タスクが失敗したときに記録を見れば、エージェントが本当に誤ったのか採点者が妥当な解を弾いたのかが分かると述べています。仕組みが堅牢になった後は、人によるレビューは時々で足ります。
AIエージェントの評価は何から学べばよいですか？
1つのタスクに、終了状態を照合する採点者を1つ付けるところからです。合否がコードだけで決まる状態を作ると、採点者を足したときに何が効いたのかを比較できます。検索して答える仕組みの側で評価を作る手順はRAG導入の手順は？社内データで失敗しない進め方で扱っています。
まとめ
AIエージェントの評価は、測る対象を経路・ツール呼び出し・終了時の環境の状態の3つに割るところから始まります。合否はコードで照合できる終了状態で取り、経路は失敗の理由を説明する材料に使います。
同じタスクでも結果はぶれるため、合格ラインは1回の成否ではなく「何回中何回」で決めます。まずは1つのタスクに、照合できる終了状態を1つ決めるところから始められます。
PR
評価の作り方まで含めて、手を動かして学び直す
測る対象の割り方や採点者の当て方は、公式ドキュメントを読むだけでは自分の業務に落ちません。手を動かしながら学び直したい場合や、チームに説明する必要がある場合は、AI・データサイエンスに特化した社会人向けオンラインスクールのキカガクが、生成AIを業務で使うためのコースを提供しています。講座の比較軸は生成AI講座の選び方｜社会人が失敗しない4つの基準で整理しています。
※ 説明会の参加は無料です。受講費用、開講日程、カリキュラムの詳細は公式サイトで最新情報を確認してください。
評価の設計まで踏み込める人がどんな条件で求められているかは、機械学習・データサイエンス領域の案件条件を見ると具体的に分かります。転職や独立の予定がなくても、自分のスキルが市場でどう評価されるかを測る材料になります。
にほんブログ村
