エージェント評価ベンチマーク実践：AgentBenchからDeepEvalまでの性能テストガイド

先週、あるカスタマーサービスエージェントをテストしていました。100個のテストケースを実行して、成功率は78%。まあまあかなと思いました。それから同じテストをもう一度実行してみると、成功率が65%になりました。私はパソコンの前で、この2行の結果を5分くらい見つめていました。

エージェントの評価というのは、私が以前やっていた通常のQ&A評価とは全く別物です。Q&Aモデルなら「フランスの首都は？」と聞いて「パリ」と答えれば正解、「マルセイユ」と答えれば不正解、白黒はっきりしています。でもエージェントは違います。思考し、計画し、ツールを呼び出し、途中で気が変わることもあります。同じタスクでも、今日はルートAで成功し、明日はルートBで失敗し、明後日はルートCでまた成功するかもしれません。

正直に言うと、エージェントの評価を始めた頃は正直戸惑っていました。AgentBenchやWebArenaといったベンチマークの論文やドキュメントを一通り読みましたが、読めば読むほど混乱しました。その後、プロジェクトでいくつか失敗を経験して、ようやく分かってきました。エージェントの評価は「ゴール」だけを見てはいけない。「軌跡」を見る必要があるのです。

一、なぜエージェントの評価は通常のQ&Aより難しいのか？

エージェントの核心的な問題は、自律性があることです。毎回の実行で、異なるパスを選択する可能性があります。

具体的な例を挙げましょう。以前、旅行予約エージェントをテストしたことがあります。タスクは「明日の北京から上海への一番安いフライトを予約して」でした。最初の実行では、まずCtrip（携程）を検索し、3つのフライトを比較し、一番安いものを選んで予約しました。完璧です。2回目に同じタスクを実行すると、Ctripを検索した後、さらに飞猪（Fliggy）も検索し始め、5分間無限ループに陥り、最終的にタイムアウトで失敗しました。

同じ入力、異なる実行軌跡。これがエージェント評価の核心的な難点です。単純な「正解/不正解」のラベルではなく、実行プロセス全体を分析できるフレームワークが必要なのです。

3層評価フレームワーク

Anthropicの公式な見解では、エージェントの評価は3つの層で見るべきとしています。

推論層（Reasoning Layer）：エージェントの計画は正しいか？タスクを正しく理解しているか？合理的な実行計画を立てているか？

行動層（Action Layer）：エージェントが選んだツールは正しいか？パラメータは正しく渡されているか？ツール呼び出しの順序は合理的か？

全体実行（Overall Execution）：タスクは最終的に完了したか？何ステップかかったか？効率はどうか？

DeepEvalのドキュメントに印象的なデータがありました。ツール呼び出しの失敗は最も一般的なエージェントの問題です。約40%のエージェントの失敗は、ツールの選択ミスかパラメータの誤りが原因です。これは何を意味するか？大部分のエージェントの問題は行動層にあり、推論層ではないということです。

従来の指標の限界

従来のQ&A評価では、正解率やF1スコアといった指標で十分です。エージェントでは通用しません。

あなたのエージェントのタスク成功率が78%だとしましょう。この数字から何が分かりますか？ほぼ何も分かりません。

なぜか？78%は以下のいずれかを意味する可能性があるからです。

• 計画は正しかったが、ツール呼び出しが失敗した（行動層の問題）
• 計画自体が間違っていて、その後の作業が無駄だった（推論層の問題）
• 計画も正しく、ツール呼び出しも正しかったが、最後のステップでミスをした（全体実行の問題）

失敗の原因によって、最適化の方向は全く異なります。計画が間違っているならプロンプトを変更するかモデルを変える必要があります。ツール呼び出しが間違っているならツールの定義を変更するかバリデーションを追加する必要があります。最後のステップでのエラーなら、境界条件の処理が問題かもしれません。

つまり、エージェント評価の核心は「成功したかどうか」ではなく、「どこで失敗したか」なのです。

二、5大主流評価ベンチマーク比較

市場にはエージェント評価ベンチマークがたくさんあります。その中から5つの主流なものを選んで説明します。実際に調査または実行したものばかりです。

AgentBench：総合能力ベンチマーク

AgentBenchは清華大学がICLR’24で発表したもので、LLM-as-Agent専用の最初の総合ベンチマークと言えます。データベースクエリ、Webブラウジング、API呼び出し、コード実行など、8つの環境をカバーしています。

実際に実行してみた感想：確かにカバー範囲が広く、汎用エージェントの選定評価に適しています。ただし環境構築がかなり手間で、Docker環境が必要です。また、Devセットだけで4000回以上のLLM呼び出しが必要で、コストも安くありません。

適したシーン：いくつかのモデルから1つを選んでエージェントのバックボーンにする場合、AgentBenchが総合スコアを提供してくれます。

KiloClaw - 企業向けマネージド OpenClaw、AI エージェントのオーケストレーションとスマートルーティングを加速

今すぐ始める →広告

WebArena：Webナビゲーション専用

WebArenaはWeb環境に特化しています。実際のWebサイト環境（ECサイト、フォーラム、地図など）を構築し、その中でエージェントにナビゲーションタスクを実行させます。

例えば「Redditでスレッドを見つけてコメントする」といったタスクです。実際のWeb環境でのエージェントの操作能力をテストします。

適したシーン：ブラウザエージェントやWeb自動化を開発している場合、WebArenaが最も適したベンチマークです。

τ-Bench：マルチターン対話テスト

τ-Bench（タウ・ベンチと読みます）はAnthropicが開発に参加したベンチマークで、マルチターンインタラクションシーンに特化しています。小売カスタマーサービス、航空予約などの実際のサービスシーンをシミュレートし、ユーザーロールを演じるエージェントとの対話を行います。

このベンチマークの特徴は、単発のタスク完了だけでなく、マルチターン対話でのエージェントのパフォーマンスをテストすることです。

適したシーン：カスタマーサービスエージェントや予約エージェントなど、対話型サービスエージェントを開発している場合。

SWE-Bench：コード能力ベンチマーク

SWE-Benchはプログラミング能力専用のテストです。GitHubから実際のissueとPRを収集し、エージェントにコード修正をさせます。

このベンチマークはかなりハードルが高いです。コード能力だけでなく、プロジェクト構造を理解し、問題を特定し、テストに通るコードを書く必要があります。

適したシーン：プログラミングアシスタントエージェントやコード修正エージェントを開発している場合。

Claw-Eval / ACE-Bench：2026年新ベンチマーク

Claw-Eval（後にACE-Benchに改名）は2026年に登場した新しいベンチマークで、特徴は難易度が設定可能なことです。エージェントのレベルに合わせてタスクの難易度を調整できます。

このアプローチは良いアイデアです。評価は一度きりではなく、継続的なプロセスです。エージェントの能力が向上すれば、タスクの難易度もそれに合わせて上がります。

適したシーン：企業内でのカスタム評価や、継続的にイテレーション可能な評価体系を構築したい場合。

ベンチマーク選定の意思決定

ベンチマークの選定に標準的な答えはありません。シーンに合わせて選ぶ必要があります。

私の提案：まずAgentBenchでベースラインを構築し、エージェントの総合能力を確認する。その後、具体的なシーンに合わせて専用ベンチマークで詳細にテストする。

三、エージェント評価指標体系

ベンチマークの説明が終わったので、次は具体的にどの指標でエージェントのパフォーマンスを測定するかです。私は6つのコア指標をまとめました。これでエージェント評価の各層をほぼカバーできます。

1. タスク成功率（Success Rate）

最も直接的な指標です。タスクは完了したか？

ただし、この指標には落とし穴があります。「完了」とはどういう意味か？エージェント自身が完了と言えば完了なのか、それとも客観的な基準が必要なのか？

私の現在のやり方は、明確な検収条件を定義することです。例えば「フライト予約」タスクなら、検収条件は以下の通りです。

• 注文番号が存在する
• フライト情報が正しい
• 価格が期待範囲内

検収条件が明確であればあるほど、成功率指標は有意義になります。

2. ツール呼び出し正確率

この指標は2つの部分に分かれます。正しいツールを選ぶこと、正しいパラメータを渡すこと。

正しいツールを選ぶとは、エージェントがツールを呼び出す必要があるときに、正しいツールを選択することを指します。正しいパラメータを渡すとは、ツールのパラメータの形式と内容が両方とも正しいことを指します。

実際のプロジェクトで気づいたのですが、この指標は特にエージェントの弱点を浮き彫りにします。あるエージェントはタスク成功率82%でしたが、ツール呼び出し正確率は68%しかありませんでした。詳しく調べると、「検索」と「予約」という2つの操作でよく間違ったツールを選んでいることが分かりました。

3. 進捗率（Progress Rate）

マルチステップタスクの場合、進捗率はエージェントがどこまで進んだかを反映します。

あるタスクに5つのステップがあるとし、エージェントが第4ステップで失敗したとします。成功率は0%ですが、進捗率は80%です。この2つの数字を一緒に見ると、このエージェントは成功に近く、おそらく最後のステップの最適化だけが足りないことが分かります。

4. 推論品質指標

この種の指標はエージェントの計画能力を評価します。

PlanQuality（計画の合理性）：エージェントが立てた計画は合理的か？ステップ間の論理関係は正しいか？

PlanAdherence（計画の一貫性）：エージェントが実際に実行するとき、元の計画から逸脱していないか？

この2つの指標はLLMを使って評価する必要があります。DeepEvalのPlanQualityMetricはまさにこれを行います。別のLLMを使ってエージェントの計画品質を判断します。

5. 効率指標

StepEfficiency（ステップ効率）：エージェントはタスクを完了するのに何ステップかかったか？理論上の最小ステップ数は？

Alibaba Cloud - 開発者向けクラウドの第一候補、ライトサーバー15%OFF、プロジェクトの迅速な立ち上げを支援

15%割引を入手 →広告

あるタスクが最小3ステップで完了できるのに、エージェントが10ステップかかった場合、StepEfficiencyは30%です。

トークン消費もあります。これは直接コストに関わります。同じタスクを完了するのに、あるエージェントは1000トークン、別のエージェントは5000トークン使う場合、コストは5倍違います。

6. 安定性指標

エージェントのパフォーマンスは安定しているか？同じタスクを10回実行して、成功率の標準偏差はどのくらいか？

この指標は以前あまり重視していませんでした。ある時、本番環境で問題が発生して初めて気づきました。テスト環境でうまく動いていたエージェントが、本番環境では成功率の変動が激しかったのです。後で分かったのですが、本番環境のリクエストタイムアウト設定がテスト環境より短く、一部のタスクが途中で切断されていました。

指標と3層フレームワークの対応

これらの指標を前述の3層評価フレームワークに対応させます。

こうして特定の指標が低いのを見れば、問題がどの層にあるか分かり、最適化の方向も明確になります。

四、オープンソース評価ツール比較：DeepEval vs LangSmith vs Arize Phoenix

指標が定義できたら、何を使ってテストするか？私は3つの主流なオープンソース評価ツールを比較しました。

DeepEval：コンポーネントレベル評価の首选

DeepEvalはConfident AIが開発したオープンソースのPythonフレームワークで、LLMとエージェントの評価に特化しています。

最大の特徴はコンポーネントレベル評価です。エージェントの任意のノードに評価を挿入でき、最終結果だけでなく中間プロセスも評価できます。

6つの主要な指標が組み込まれています。

• TaskCompletionMetric（タスク完了）
• StepEfficiencyMetric（ステップ効率）
• ToolCorrectnessMetric（ツール正確性）
• ArgumentCorrectnessMetric（引数正確性）
• PlanQualityMetric（計画品質）
• PlanAdherenceMetric（計画一貫性）

私は旅行予約エージェントプロジェクトでDeepEvalを使って評価しましたが、効果的でした。@observeデコレータがあり、エージェントの実行中に推論、ツール呼び出しなどのコンポーネントを自動的に追跡し、層ごとに評価できます。

DeepEvalには付属のConfident AIクラウドプラットフォームもあり、評価結果を可視化したり、データセット管理をしたりできます。ただしオープンソース部分だけでも十分使えます。

LangSmith：LangChain公式製品

LangChainを使ってエージェントを開発している場合、LangSmithが最もスムーズな選択です。LangChainとシームレスに統合され、実行チェーン全体を自動的に追跡できます。

LangSmithの強みは全チェーン追跡です。エージェントの各LLM呼び出し、各ツール実行が見え、完全な実行軌跡が全て残ります。

ただし商用製品で、価格制限があります。小規模テストなら問題ありませんが、大規模評価になるとコストが上がります。

Arize Phoenix：可観測性優先

Arize PhoenixはOpenTelemetryアーキテクチャベースで、可観測性に特化しています。

その考え方は、エージェントの実行プロセスを分散システムとして監視するということです。LLM呼び出し、ツール呼び出しは全てSpanで、実行軌跡全体がTraceです。

Phoenixは本番環境の監視に特に適しています。異常検知、パフォーマンス分析などの機能があり、デプロイ後の継続的な監視に向いています。

選定の意思決定

ツールの選定は、状況によります。

LangChainを使っているか？
  → はい：LangSmithを優先（シームレスな統合）
  → いいえ：本番監視が必要か？
       → はい：Arize Phoenix + DeepEval
       → いいえ：開発評価のみ → DeepEval

私の実際の組み合わせは、開発フェーズでDeepEvalを使って評価し、本番環境でArize Phoenixを使って監視しています。2つのツールは補完的で、効果的です。

五、コード実践：DeepEvalで旅行予約エージェントを評価する

理論ばかりでなく、実践的な内容に入りましょう。以下は完全なDeepEval評価コード例で、実際の旅行予約エージェントプロジェクトで使用したものです。

エージェント実装

まず、@observeデコレータを使って各コンポーネントを追跡するシンプルな旅行予約エージェントを定義します。

from deepeval.tracing import observe
from deepeval.metrics import (
    PlanQualityMetric,
    PlanAdherenceMetric,
    ToolCorrectnessMetric,
    ArgumentCorrectnessMetric,
    TaskCompletionMetric,
    StepEfficiencyMetric
)

# ツール定義
@observe(type="tool")
def search_flights(origin: str, destination: str, date: str):
    """フライト検索"""
    # 実際のプロジェクトでは実際のAPIを呼び出す
    # サンプルはモックデータを返す
    return [
        {"flight": "CA1234", "price": 500, "time": "08:00"},
        {"flight": "MU5678", "price": 450, "time": "10:30"},
        {"flight": "CZ9012", "price": 520, "time": "14:00"}
    ]

@observe(type="tool")
def book_flight(flight_number: str, passenger_info: dict):
    """フライト予約"""
    # 実際のプロジェクトでは実際の予約APIを呼び出す
    return {"order_id": "ORD123456", "status": "confirmed"}

# エージェント本体
@observe(type="agent")
def travel_agent(user_input: str):
    """
    旅行予約エージェント
    入力：ユーザーの予約リクエスト
    出力：予約結果または失敗情報
    """
    # 推論層：タスクを解析し計画を立てる
    @observe(type="reasoning")
    def parse_and_plan(input_text):
        # 本来はLLMを呼び出して解析・計画する
        # サンプルはシンプルなルールで解析
        plan = {
            "task": "book_flight",
            "origin": "北京",
            "destination": "上海",
            "date": "明日",
            "steps": ["search", "compare", "book"]
        }
        return plan

    plan = parse_and_plan(user_input)

    # 行動層：ツール呼び出しを実行
    # ステップ1：フライト検索
    flights = search_flights(
        plan["origin"],
        plan["destination"],
        plan["date"]
    )

    # ステップ2：最も安いフライトを選択
    cheapest = min(flights, key=lambda x: x["price"])

    # ステップ3：予約
    result = book_flight(
        cheapest["flight"],
        {"name": "テストユーザー"}
    )

    return result

評価指標の設定

from deepeval import evaluate
from deepeval.test_case import LLMTestCase

# テストデータ定義
test_cases = [
    LLMTestCase(
        input="明日の北京から上海への一番安いフライトを予約して",
        expected_output={"order_id": "ORD123456", "status": "confirmed"}
    ),
    LLMTestCase(
        input="来週の水曜日に広州から深圳へのフライトを調べて",
        expected_output={"flights": [...]}
    )
]

# 評価指標設定
metrics = [
    TaskCompletionMetric(
        threshold=0.7,
        evaluation_model="gpt-4o"
    ),
    StepEfficiencyMetric(
        threshold=0.5,  # 最低50%の効率を期待
        minimum_steps=3  # 最小3ステップ必要
    ),
    ToolCorrectnessMetric(
        threshold=0.8
    ),
    ArgumentCorrectnessMetric(
        threshold=0.8
    ),
    PlanQualityMetric(
        threshold=0.7,
        evaluation_model="gpt-4o"
    )
]

評価実行

# 方法1：単一評価
for test_case in test_cases:
    result = travel_agent(test_case.input)
    test_case.actual_output = result

evaluate(test_cases, metrics)

# 方法2：データセット一括評価
from deepeval.dataset import EvaluationDataset, Golden

dataset = EvaluationDataset(goldens=[
    Golden(input="明日の北京から上海への一番安いフライトを予約して"),
    Golden(input="来週の成都から昆明へのフライト情報を検索して")
])

for golden in dataset.evals_iterator(metrics=metrics):
    output = travel_agent(golden.input)
    # 評価は自動的に記録・計算される

評価結果の解釈

DeepEvalは各指標のスコアと通過率を出力します。以下のような結果が得られたとします。

この結果から何が分かりますか？

• タスク完了率は高い（85%）、大部分のタスクは成功
• ステップ効率が低い（45%）、エージェントが余分なステップを踏んでいる可能性
• ツール選択正確率は高い（90%）が、引数正確率は低い（72%）

最適化の方向が明確になりました。引数構築ロジックの改善と、不要なステップの削減に注力すべきです。

六、本番環境での評価実践

開発段階の評価が終わってエージェントをデプロイしても、評価は終わりではありません。むしろ、ここからが本番です。

Railway - モダンなデプロイプラットフォーム、煩わしい運用から解放、数分で公開

今すぐ始める →広告

本番環境でのエージェントのパフォーマンスは、開発環境と往往にして異なります。ユーザー入力はよりランダムで、境界ケースは多く、同時接続のプレッシャーも大きい。開発から本番までの完全な評価サイクルが必要です。

開発段階：ベースラインの構築

開発段階では、エージェントのベースライン能力を確立することが目標です。

まずAgentBenchのような総合ベンチマークで一通りテストし、汎用能力でのレベルを確認します。その後、カスタムデータセットで具体的なシーンをテストします。データセットは、典型的なタスク、境界ケース、失敗ケースをカバーする必要があります。

開発段階の評価でやるべきこと。

• テストデータセットのカバレッジ ≧ 80%のユーザーシーン
• 各指標に明確なベースライン値がある
• 失敗ケースを記録し、失敗原因の分布を分析

デプロイ段階：グレースケールとA/Bテスト

エージェントをデプロイする際、いきなり全量公開してはいけません。まずグレースケール（段階的ロールアウト）です。

グレースケール評価の核心は比較です。グレースケールグループとコントロールグループのパフォーマンスの差です。

# グレースケール評価例
def ab_test_evaluation():
    # コントロールグループ：旧バージョンのエージェント
    control_results = evaluate_agent(old_agent, test_cases)

    # グレースケールグループ：新バージョンのエージェント
    treatment_results = evaluate_agent(new_agent, test_cases)

    # 主要指標の比較
    comparison = {
        "success_rate": {
            "control": control_results.success_rate,
            "treatment": treatment_results.success_rate,
            "delta": treatment_results.success_rate - control_results.success_rate
        },
        "step_efficiency": {
            "control": control_results.step_efficiency,
            "treatment": treatment_results.step_efficiency,
            "delta": treatment_results.step_efficiency - control_results.step_efficiency
        }
    }

    return comparison

グレースケール比率の推奨：まず1%、24時間観察して問題なければ5%、その後10%、20%、50%、100%。各ステップで主要指標の変化を確認します。

本番段階：継続的監視

エージェントが本番環境に入ると、評価は監視になります。

監視の焦点は異常検知です。成功率が突然低下する、レスポンス時間が突然長くなる、あるツール呼び出しが突然失敗する。これらの異常をリアルタイムでアラートし、ユーザーからの大規模なフィードバックの前に問題を発見できるようにする必要があります。

サンプリング戦略：本番環境では全てのリクエストを評価することはできません。サンプリングが必要です。私の推奨は以下の通り。

• 通常タスク：1%-5%をサンプリング
• 重要タスク（決済、予約など）：100%評価
• 異常リクエスト（失敗、タイムアウト）：100%を評価キューに投入

コスト管理：評価自体にもコストがかかります。特にLLMを使って推論品質を評価する場合。いくつかのテクニックがあります。

• 小さいモデルで評価（例：gpt-4o-mini）
• 非同期評価、メインフローをブロックしない
• 評価のサーキットブレーカーを設定、最大サンプル数100-1000

人力レビューの必要性

自動評価がいくら良くても、境界ケースは人の目が必要です。

私の現在のやり方：自動評価が「不確定」と判定したケースは、人力レビューキューに入れます。毎週10-20ケースを人力で確認し、自動評価の正確性を判断します。

人力レビューにはもう一つの価値があります。自動評価ではカバーできない問題を発見できることです。例えば、エージェントの返信の口調が悪い、ユーザーに混乱を与えているといった問題は、自動評価では発見しにくいですが、ユーザー体験には大きな影響を与えます。

完全な評価サイクル

全体のフローをつなげます。

開発段階
├── AgentBench ベースラインテスト
├── カスタムデータセット評価
└── 失敗ケース分析
    ↓
デプロイ段階
├── グレースケールテスト（1% → 5% → 10% → ...）
├── A/B 比較評価
└── ロールバック機構
    ↓
本番段階
├── サンプリング監視（1%-5%）
├── 異常検知アラート
├── 人力レビューキュー
    ↓
最適化イテレーション
├── 失敗ケースの原因分析
├── プロンプト/ツール調整
└── 再評価
    ↓ (ループ)

これは継続的なイテレーションのプロセスであり、一度きりの作業ではありません。エージェントの能力は劣化し、ユーザーシーンは変化し、新しい問題が現れます。評価も一緒に進化させる必要があります。

結論

エージェント評価というのは、結局のところ、ゴールだけを見ずに軌跡を見るということです。

私が経験した失敗：成功率78%で十分だと思っていたら、本番環境で同じタスクの成功率が30%も変動した。ツール呼び出しに問題ないと思っていたら、失敗の40%がパラメータの誤りだった。開発評価で十分だと思っていたら、本番環境の問題が全く違った。

3層評価フレームワークが私の考えを整理してくれました。推論層で計画を見る、行動層でツールを見る、全体実行で結果を見る。5大ベンチマークがベースラインを構築してくれました。AgentBenchで総合テスト、τ-Benchでマルチターンテスト、SWE-Benchでコードテスト。DeepEvalがコードによる評価を実現してくれました。@observeデコレータでコンポーネントを追跡し、6つの指標で層ごとに分析。

次にできることは以下の通りです。

1. AgentBenchでエージェントをテストし、ベースラインを構築する
2. DeepEvalでコンポーネントレベルの評価を行い、弱点を見つける
3. 本番監視システムを構築し、異常検知と人力レビューを組み合わせる

評価はゴールではなく、スタート地点です。エージェントの能力が進化すれば、評価も一緒に進化させる必要があります。