9.8.3 Agent 評価ベンチマーク

Agent ベンチマークとカスタム評価セットの比較図

学習目標

汎用ベンチマークの価値と限界を理解する
なぜ業務用 Agent には自作の評価セットが必要なのかを知る
小さなプロジェクト用ベンチマークを設計できる
ランキングを上げることだけに気を取られて、本当のタスクを見落とさないようにする

ベンチマークは何を解決するのか

ベンチマークの役割は、固定されたタスクのセットを提供し、異なるモデルやシステムを比較できるようにすることです。たとえば、コード Agent ならバグ修正能力、Web Agent ならブラウザ操作能力、ツール Agent なら複数ステップの呼び出し能力を確認できます。

flowchart LR
  A[固定タスクセット] --> B[統一スコアリング]
  B --> C[モデルやシステムを比較]
  C --> D[能力の限界を発見]

その価値は、再現性があり、比較しやすく、傾向を観察できることです。ただし、あなたの実際の業務をそのまま表しているとは限りません。

よくある Agent ベンチマークの種類

種類	評価の重点	典型的なタスク
コード系	コード修正、テスト修正、リポジトリ理解	issue 修正、単体テスト通過
Web 系	Web ページの閲覧、フォーム入力、情報検索	複数ステップのブラウザタスク
ツール呼び出し系	ツール選択、パラメータ生成、結果処理	API 呼び出し、関数の組み合わせ
長時間タスク系	計画、実行、復旧、要約	調査、分析、レポート生成

これらのベンチマークを学ぶとき、大事なのは名前を覚えることではなく、タスク、入力、採点、失敗をどう定義しているかを見ることです。

なぜ自分でプロジェクト用評価セットを作る必要があるのか

汎用ベンチマークでは、あなたの授業ドキュメント、使えるツールの権限、ユーザーの目的、そして業務上の制約まではカバーできません。たとえば、あなたの「AI 学習アシスタント」は、講義内容への質問に答えたり、復習計画を作ったり、章の出典を引用したり、授業内容をでっち上げないようにしたりする必要があります。これらはすべて、自分専用の評価セットで確認しなければなりません。

自作の評価セットには、少なくとも 20 件のサンプルを入れましょう。内訳は、正常なタスク 10 件、境界タスク 5 件、ツール失敗タスク 3 件、安全・権限タスク 2 件です。各サンプルには成功基準を必ず用意します。

20 件のサンプルは、次のように分けると考えやすいです。

グループ	件数	例
正常タスク	10	学習計画を作る、章の質問に答える、概念を要約する
境界タスク	5	ユーザーの依頼が曖昧、複数ステージが混ざる、章名が間違っている
ツール失敗タスク	3	検索結果が空、API タイムアウト、文書解析失敗
安全 / 権限タスク	2	ファイル削除を求める、未確認で内容送信を求める

この分け方にすると、「うまくいくケースだけをテストする」という初心者にありがちな失敗を避けやすくなります。

コース Agent ベンチマークの例

{
  "id": "course_agent_008",
  "task": "1週間の RAG 復習計画を作って、コースの入口も引用してください",
  "expected_capabilities": ["コース文書を検索する", "計画を作成する", "出典を示す"],
  "must_include": ["RAG 基礎", "検索戦略", "RAG 評価"],
  "must_not_do": ["存在しない章をでっち上げる", "書き込みツールを呼び出す"],
  "scoring": {
    "coverage": 2,
    "source_accuracy": 2,
    "plan_quality": 1
  }
}

この例は、「満足できるかどうか」よりも実行しやすいです。なぜなら、何を必ず含めるべきか、何をしてはいけないか、どう採点するかが明確だからです。

最小限のベンチマークランナー

ベンチマークが本当に役立つのは、Prompt、モデル、ツール schema、検索戦略を変えたあとに、同じケースをもう一度実行できるときです。

次は、とても小さな採点例です。

sample = {
    "id": "course_agent_008",
    "must_include": ["RAG 基礎", "検索戦略", "RAG 評価"],
    "must_not_do": ["存在しない章をでっち上げる", "書き込みツールを呼び出す"],
}

answer = """
この1週間計画は、RAG 基礎、検索戦略、RAG 評価を含みます。
コース内の RAG 入口章を引用し、計画はテキストとして返すだけにしています。
"""

def score_answer(sample, answer):
    include_hits = sum(item in answer for item in sample["must_include"])
    forbidden_hits = sum(item in answer for item in sample["must_not_do"])

    return {
        "coverage": include_hits / len(sample["must_include"]),
        "forbidden_violations": forbidden_hits,
        "pass": include_hits == len(sample["must_include"]) and forbidden_hits == 0,
    }

print(score_answer(sample, answer))

実行結果の例：

{'coverage': 1.0, 'forbidden_violations': 0, 'pass': True}

この例は意図的にシンプルにしています。実際の Agent ベンチマークでは、さらに次の点も確認します。

引用された章が本当に存在するか
Agent が許可されたツールだけを使ったか
検索結果が空のときに復旧できたか
高リスク操作の前に確認を求めたか
遅延とコストが許容範囲に収まったか

ベンチマークの限界

ベンチマークは過学習されやすいです。システムは固定タスクではとても良く見えても、実際のユーザー入力に変えると不安定になることがあります。ベンチマークは、コスト、遅延、安全性、保守性を見落とすこともあります。Agent にとっては、最終スコアよりも実行の流れが説明できるかどうかの方が大事な場合もあります。

推奨される使い方

まず汎用ベンチマークで能力の感覚をつかみ、そのあと自作の評価セットでプロジェクトの品質を確認します。Prompt を変える、モデルを変える、ツール schema を変える、検索戦略を追加するたびに、同じ評価セットで必ず再実行しましょう。そうすることで、変更が改善なのか、悪化なのか、それとも出力の見た目が変わっただけなのかを判断できます。

期待される結果：自作ベンチマークを使って、同じタスク集合でモデル、Prompt、tool schema、検索戦略の差を比較できる状態です。

残す証拠

このページを終えたら、この証拠カードを残します。

評価ケース: 固定タスクと期待される安全な挙動
スコアカード: タスク成功、ツールの正確さ、trace の品質、安全性
ガードレール: ポリシー、権限、検証、または人の確認
失敗確認: 危険なツール使用、プロンプトインジェクション、隠れた状態、または観測されていない操作
次の行動: ケース、ガードレール、ログ、ロールバック、または拒否パスを追加する

よくある誤解

1つ目の誤解は、ベンチマークのスコアをそのまま本番品質だと思うことです。2つ目の誤解は、正常なタスクだけを測って、失敗や境界タスクを測らないことです。3つ目の誤解は、評価サンプルが少なすぎて、いくつかのデモだけでシステムの良し悪しを判断してしまうことです。4つ目の誤解は、過去の結果を保存せず、バージョンの変化を比較できなくなることです。

練習

コース QA アシスタント用に 20 件のベンチマークサンプルを設計してください。
各サンプルに must_include、must_not_do、採点ルールを書いてください。
検索結果が空、API タイムアウト、権限不足など、3 つのツール失敗シナリオを設計してください。
ベンチマークがオンライン監視の代わりにならない理由を説明してください。

合格基準

この節を学び終えたら、汎用ベンチマークと自作の評価セットの違いを説明できること、自分の Agent プロジェクト向けに小さなベンチマークを設計できること、そして固定された評価セットで異なるモデル、Prompt、ツール設計の効果を比較できることが必要です。

プロジェクト参考とレビュー観点

しっかりした 20 件の benchmark には、易しい/中程度/難しい course question、citation 必須 case、範囲外 question、retrieval が部分的または矛盾した evidence だけを返す case を混ぜます。
must_include には必須 concept や evidence、must_not_do には hallucinated citation や unsafe action の禁止、scoring rules には部分点の付け方を書きます。
tool failure scenario では empty retrieval、timeout、permission denial、malformed tool output、stale data を試します。期待される動作は、穏やかな recovery または明確な stop であり、自信満々の推測ではありません。
benchmark は production monitoring を置き換えられません。実ユーザーは新しい言い回し、新しい goal、latency pressure、cost spike、data drift、tool failure を生むため、固定 benchmark だけでは足りません。