Skip to Content
Docs04. 評価Agent 評価の基礎
中級evaluationai-agent更新: 2026-10-04この記事の誤りを報告

この記事の音声は準備中です。

音声の一覧・再生リストへ

Agent 評価の基礎

この記事の目的

「作ったが品質が分からない」状態を脱するために、Agent の評価を 何を測るか(評価対象)・どう採点するか(採点方法)・何で測るか(データセット) の 3 つの設計判断に分解して組み立てられるようになります。本セクション(04-evaluation)の他の記事すべての前提になります。

対象読者

  • Agent のプロトタイプはできたが、本番投入を判断する基準を持っていないエンジニア
  • 「デモでは動く」と「品質が分かっている」の差を埋めたいテックリード

前提知識

本文

概要: なぜ Agent の評価は普通のテストより難しいか

assert 出力 == 期待値 が成立しない理由が 4 つ重なっているためです。

  1. 非決定性 — 同じ入力でも実行ごとに出力・経路が変わります(temperature を下げても消えません)
  2. 経路の自由度 — 正解にたどり着く手順が 1 つに定まりません
  3. 開放的な出力 — 文章での回答は文字列一致で正誤判定できません
  4. 多段の複合 — 失敗の原因がどのステップにあるか、最終出力だけでは分かりません

この 4 つに対応するのが、本文で扱う複数回実行・不変条件による評価・LLM-as-a-Judgeコードでは採点できない開放的な出力を、基準を与えた別の LLM に判定させる評価手法。judge 自体の検証(人手ラベルとの一致率測定)を前提とする。・軌跡評価最終出力だけでなく、Agent ループの実行記録(軌跡: 思考・ツール呼び出し・結果の列)に対して経路の正しさ・効率・安全性を評価すること。という道具立てです。

詳細: 評価対象の 3 層

層見るもの例主な用途
最終成果(outcome)タスクが達成されたか回答が正しい。あるべき最終状態(DB・チケット)になっている投入判断・リリースゲート
軌跡(trajectory)途中の経路適切なツールを適切な引数で、無駄なく安全に呼んだかデバッグ・安全性の検証
単一ステップ(component)部品単体検索の再現率、分類の正答率、ツール実装の動作原因の切り分け・高速な改善反復

原則は「判断にはまず最終成果、原因究明には軌跡、改善の反復には部品」です。軌跡の詳細は 軌跡(trajectory)評価 で扱います。

詳細: 採点方法の 3 分類

方法仕組み長所短所
コードベース採点決定的なロジックで判定(完全一致・正規表現・スキーマ検証・最終状態の検証)速い・安い・再現可能開放的な出力を判定できない
LLM-as-a-Judge別の LLM に基準を与えて判定させる開放的な出力を扱える。スケールするjudge 自体の検証が必要。コスト・非決定性
人手評価人間が判定する基準・専門性・評価者間一致を確認できれば強い参照になる遅い・高い。継続実行に向かない

三択ではなく組み合わせます。コードで採点できるものは必ずコードで採点し(judge に回さない)、開放的な出力だけを LLM-as-a-Judge に回し、人手は judge の検証と少数の重要ケースに集中させるのが基本形です。

詳細: 評価データセットの作り方

  • 小さく始めます — 20〜50 件は失敗の発見と評価を回し始める出発点です。小さい差の立証や安全性・一般化の確認に十分とは限りません
  • ソースは実際の失敗です — 開発中に遭遇した失敗、ユーザーからの報告、本番ログが重要な供給源です(想像で書いたケースは実入力より簡単になりがちです)。本番データを使う場合は個人情報・秘密情報の除去を通します
  • 期待値は「満たすべき条件」で書きます — 「正解文字列」ではなく「金額 X が含まれる」「規定違反を指摘している」「書き込み操作をしていない」のような条件にします(経路の自由度・開放的出力への対応)
  • 分布を意識します — 正常系だけでなく、曖昧な依頼・情報不足の依頼・拒否すべき依頼を混ぜます
  • 育て続けます — 本番で見つかった失敗を修正と同時にケース化します(回帰テストと CI 組み込み)

詳細: 評価ハーネスの最小構成

評価ハーネスモデルの外側 — ループ・ツール・フィードバック・環境・制御の総体。同じモデルでも作り込みで性能と信頼性が変わるため、モデルと並ぶ一級の設計対象として扱う。(evaluation harness)とは、評価を繰り返し実行可能にする仕組み一式のことです。最小構成は 4 つの部品です。

Agent 評価の基礎: 詳細: 評価ハーネスの最小構成の図Agent 評価の基礎: 詳細: 評価ハーネスの最小構成の図
Agent 評価の基礎: 詳細: 評価ハーネスの最小構成の図
図を元の大きさで表示

図の中をスクロールして読めます。キーボードでは図の領域へ Tab で移動し、矢印キーを使います。読み終わったら、この見出しをもう一度選ぶと閉じます。

Agent 評価の基礎: 詳細: 評価ハーネスの最小構成の図Agent 評価の基礎: 詳細: 評価ハーネスの最小構成の図

専用の評価プラットフォームやフレームワーク付属の機能もありますが、この 4 点セットは小規模なら自作でも十分に成立します。重要なのはツールの選択より「データセットと採点基準がチームの資産としてバージョン管理されていること」です。

設計判断: メトリクスの決め方

  • 基本はケース単位の合格/不合格、集計はスイート全体の成功率です。「品質スコア平均 7.2」のような 1 本の数値は、何が起きたか説明できず行動につながりません
  • 非決定性には複数回実行で対応します。重要ケースは 1 ケースを N 回(目安 3〜5 回)実行し、「1 回でも成功すればよい」タスクか「毎回成功すべき」タスクかで基準を変えます(後者は全回成功を要求します)
  • 品質と同時にコスト・レイテンシ・ステップ数を記録します。これを見ないと「成功率の見かけの差は 3 ポイント、コストは 3 倍」を見落とします。3 ポイントを改善と呼ぶには、次節のばらつきと同じケースでの比較を確認します

詳細: 件数とばらつき、変更前後の比較

実運用に近い分布から独立に採った二値の合否を前提に、成功率 pp の 95% 区間の半幅(誤差幅)は正規近似で 1.96p(1−p)/n1.96\sqrt{p(1-p)/n} です。成功率 80% 付近なら、20 件で約 ±18 ポイント、50 件で約 ±11 ポイント、200 件でも約 ±6 ポイントです。小標本・端の成功率では正規近似が不適切なので、Wilson 区間などを使います。例として 16/20 の Wilson 区間は約 58〜92%、40/50 は約 67〜89% です。これは無作為なケース選択による標本のばらつきの目安で、judge の誤採点や分布の偏りは含みません。

変更前後は同じケースで比べ、ケースごとの成功から失敗・失敗から成功への変化を見ます。同じケースを複数回実行してもケース数が増えたとは数えず、反復をまとめたケース単位で差の区間を見積もります(例: ケース単位の paired bootstrap)。50 件の 3 ポイント差だけで改善を断定せず、区間が広ければケースを増やすか判断を保留します。失敗を集めた回帰スイートの成功率は、本番全体の成功率推定とは別です。詳しくはオンライン評価を参照します。

設計判断: 開発フェーズ別の投資

フェーズ評価への投資
プロトタイプ目視 + 手元 10 ケース程度の再実行。この段階で重厚なハーネスは作らない
投入前ハーネス + リスク・入力範囲・必要な差の精度に応じた件数 + 関係者で合意した合格基準。50 件を一律の投入条件にしない
運用中本番ログからのケース追加、CI での回帰実行(回帰テストと CI 組み込み)、本番監視(可観測性とトレーシング)との接続

実務での注意点

アンチパターン

チェックリスト

  • いま測っているものが 3 層(最終成果・軌跡・部品)のどれか説明できる
  • 各ケースの期待値が「満たすべき条件」で書かれている
  • コードで採点できる部分がコード採点になっている(judge を無駄に使っていない)
  • 重要ケースを複数回実行し、成功率で判定している
  • 品質と同時にコスト・レイテンシを記録している
  • 人手評価の基準・専門性・評価者間一致を確認した
  • 同じケースで変更前後を比較し、件数とばらつきを報告した(同じケースの反復を独立ケース数に数えない)
  • データセットと採点基準がバージョン管理されている
  • 本番の失敗をデータセットに追加する運用が決まっている

関連トピック

参考資料

TODO・未確認事項

セクション概要LLM-as-a-Judge