メインコンテンツまでスキップ

AIエージェントの評価

上級
What you'll learn
  • エージェント評価がプロンプト評価と異なる理由を理解する — 最終回答だけでなく軌跡が重要
  • 20〜100件の実例と明確な合格基準からなるゴールデンセットを構築する
  • 4つの層で採点する: ツールコールの正確性、軌跡の質、タスク成功、本番でのドリフト
  • LLM-as-judge を安全に使う: ルーブリック優先、人間との校正、判定の抜き取りチェック
  • CI で動作し、ユーザーに届く前に悪い変更を落とす評価を出荷する

エージェント評価は「プロンプトが正しい単語を返したか?」より難しい質問に答えます: ループで動作するモデルが、正しいツールを、正しい順序で、正しい引数で選び、正しい結果に到達し、予算と安全境界内に留まったか?

このステップを飛ばすと、システムプロンプトを調整するたびに静かに劣化する「役に立つ」エージェントを出荷することになります。

なぜエージェントに独自の評価が必要か​

シングルプロンプト評価は1つの入力 → 1つの出力を採点します。エージェントは軌跡を生成します: 多くのターンにわたる推論、ツールコール、中間観察、修正のチェーン。2つの失敗モードがこれを難しくします:

  • 正しい答え、間違った経路。 エージェントは無駄なループ、危険な行動、幸運な推測の後に正しい出力に偶然到達します。最終回答のみの評価は合格と判定しますが、本番では通用しません。
  • 間違った答え、もっともらしい経路。 各ステップは単独では合理的に見えますが、エージェントがツールを誤用したり、制約を無視したり、中間事実をハルシネートしたりします。返答だけでなくトレースを見る必要があります。

4つの評価層​

安いものから順に重ねて、高価なグレーダーを待たずに悪い変更を素早く落とせるようにします。

Guided walkthrough1 of 4
  1. 各予想ステップについて、ツール名が一致すること、必須パラメータが存在すること、型が検証されることをチェック。純粋なコード、ミリ秒、モデル不要。他のすべてが実行される前に「write_file を呼ぶべきだったのに search を呼んだ」を捕まえる。

価値を予測するメトリクス​

すべてのメトリクスがダッシュボードに載るわけではありません。2026年に出荷判断を左右する5つ:

メトリクス何を測るかなぜ重要か
タスク成功率ゴールデンセット中、エージェントが正しく完了した割合ヘッドライン。他はすべて診断用。
成功タスクあたりコスト$ / 合格ケース(入力+出力トークン、ツールコスト)10倍のコストでの成功は退行。
レイテンシ (p50 / p95)タスクあたりのウォールクロック、テール含むp95 が実ユーザーが感じる値 — 平均は嘘をつく。
ツールコール精度予想ツールコールのうち名前+引数が正しい割合軌跡の質を予測。計算が安い。
介入率本番で人間の引き継ぎが必要だったタスクの割合自律性の数字。上昇 = 信頼低下。

一緒に追跡すること — 1つだけが動くのは通常ノイズではなく先行シグナルです。

ゴールデンセットを構築する​

Guided walkthrough1 of 5
  1. 実使用(ログ、サポートチケット、ユーザー要求)から20〜100件のタスクを引く。頻繁な易しい経路、厄介な中間、すでに刺されたエッジケースをカバー。

LLM-as-judge — 安価で速いが、校正が必要​

曖昧な出力を手で採点するのはスケールしません。明示的なルーブリックで読む能力のあるモデルはスケールします — Anthropic 自身の 評価方法論ガイド がトーン、忠実性、有用性、安全性についてこのパターンを推奨しています。

ジャッジには文書化されたバイアスがあります: 長い回答、最初に表示された選択肢、自身の言い回しを反映した出力を好みます。3つの習慣が正直に保ちます:

  • 雰囲気ではなくルーブリック。 「有用性を1〜5で評価」は無用。スケール上の各点を観察可能な行動に固定する。
  • 人間ラベルサンプルで校正する。 30〜50ケースを人間に採点させ、ジャッジ対人間の一致度を測る(Cohen κ ≥ 0.6 を目標)。不一致なら、ルーブリックを厳しくする。
  • ジャッジには別のモデルを使う。 出力を生成したモデルと同じモデルで採点すると、双方向にバイアスが漏れる。
  • 毎週判定を抜き取りチェックする。 ランダムな10件のジャッジスコアとその理由を読む。ドリフトを捕まえる最も安い方法。

LLM-as-judge ルーブリックテンプレート

You are grading an AI assistant's response against a rubric. Be strict. Cite exact evidence from the response.

<task>{task}</task>
<response>{response}</response>

Rubric (rate 1–5 per dimension):
- Task completion: 1 = ignored task; 3 = partial; 5 = fully done, no gaps.
- Faithfulness: 1 = contains false claims; 3 = mostly grounded, one soft claim; 5 = every claim traceable to input/tools.
- Efficiency: 1 = wandered/looped; 3 = extra steps; 5 = minimum viable path.

Output JSON only:
{"task_completion": N, "faithfulness": N, "efficiency": N, "evidence": "<quote>", "verdict": "pass"|"fail"}

軌跡レビュープロンプト(層2)

You are auditing an AI agent's tool-call trajectory. The goal was: {goal}
Expected minimum steps: {n_min}

<trajectory>
{list of tool_name(args) -> result, in order}
</trajectory>

Answer in JSON:
{"steps_taken": N, "wasted_steps": N, "wrong_tool_calls": [<indices>], "unsafe_actions": [<indices>], "verdict": "pass"|"fail", "reason": "<one sentence>"}

敵対的ケース生成器(セットを成長させる)

Generate 5 new eval cases that are likely to break an agent whose current failures cluster around: {failure_pattern}.

For each case give: input, expected output OR pass criterion, ideal tool sequence, and why this case is hard.

Return YAML.

CI ゲート: 出荷前に悪い変更を落とす​

評価は自動的に退行をブロックしたときにだけ元が取れます。すべてのプロンプト/モデル/ツール変更のチェックとして CI に組み込む:

# tests/eval_gate.py — runs on every PR
import json, sys
from anthropic import Anthropic
from my_agent import run_agent

client = Anthropic()
golden = json.load(open("evals/golden.v3.json"))

results = []
for case in golden:
    trace = run_agent(case["input"])
    layer1 = tool_calls_match(trace, case["expected_tools"])   # deterministic
    layer3 = judge(client, case, trace.final_output)           # LLM rubric
    results.append({"id": case["id"], "layer1": layer1, "layer3": layer3["verdict"]})

pass_rate = sum(r["layer3"] == "pass" for r in results) / len(results)
tool_acc  = sum(r["layer1"] for r in results) / len(results)

# Gates — tighten over time
assert pass_rate >= 0.85, f"Task success dropped to {pass_rate:.0%}"
assert tool_acc  >= 0.90, f"Tool-call accuracy dropped to {tool_acc:.0%}"
print(f"PASS: task={pass_rate:.0%} tools={tool_acc:.0%}")

実行ごとのスコアを保存してトレンドをチャート化。マージ間の3ポイント以上の低下はノイズではなく本物の退行です。

評価が期待外れになるアンチパターン
  • 最終回答だけを判定 — すべての軌跡バグを見逃す。層1と2も採点する。
  • 静的ゴールデンセット — 本番失敗で成長しなければ本番を予測しなくなる。月次で予算を確保する。
  • エージェントとジャッジが同じモデル — 双方向のバイアス。採点には別のモデルにローテーション。
  • ゲートにコストやレイテンシがない — 8ツールコールを追加するプロンプト調整は評価に「合格」しつつ請求を10倍にできる。
  • 雰囲気だけの採点 — 「良く感じる」はメトリクスではない。2つの数字を差分できなければ、自信を持って出荷できない。
Key takeaways
  • エージェントは回答ではなく軌跡を生む — 結果だけでなく経路を評価する
  • 安い順に重ねる: ツールコール正確性 → 軌跡質 → タスク成功 → 本番ドリフト
  • 出荷判断を左右する5つのメトリクス: タスク成功率、成功あたりコスト、p50/p95 レイテンシ、ツールコール精度、介入率
  • LLM-as-judge はスケールするが、明示的ルーブリック、別モデル、人間ラベルでの校正が必須
  • 本番失敗で成長しないゴールデンセットは本番を予測しなくなる — 月次で成長させる
  • 評価をハードゲートとして CI に組み込む — ユーザーより先に退行を捕まえるチェック

自分を確認する​

自分を確認する

0/4
  1. なぜエージェントには最終回答評価ではなく軌跡評価が必要か?
  2. 評価を階層化しています。安いから高いへの正しい順序は?
  3. LLM-as-judge を信頼できるように保つ習慣のペアはどれ?
  4. CI ゲートがタスク成功率を通過しましたが、レイテンシとタスクあたりコストが2倍になりました。正しい判断は?
Enter キーまたはスペースキーでカードを裏返します。左右の矢印キーでカードを移動できます。用語を表示しました。
1 / 7

次へ​