# エージェント評価の最小構成——20タスクで動くEvals設計

> AIエージェントのevalは20タスクから始められる。実失敗起票からグレーダー設計、Langfuse・Arize Phoenixの無料構成まで、エンジニア2〜3人が1週間で動かせる手順を示す。

- Canonical: https://kuucorp.com/blog/agent-eval-minimum-viable-setup/
- Date: 2026-06-24
- Last modified: 2026-06-24
- Publisher: Kuu株式会社 (https://kuucorp.com)

---
プロンプトを1行変えただけで、エージェントのどこかが壊れていないか確認できているか。手動でチャットして「動いた」で済ませているチームは多い。Anthropicが公開した評価ガイドラインによれば、実際の失敗ケース20〜50件から始めたevalでも、プロンプト変更の影響を検出するには十分だ。エンジニア2〜3人のチームでも今週中に動かせる構成を示す。

## エージェント評価（eval）とは何か

> evalとはエージェントに入力を与え採点ロジックで品質を自動検証するテストで、20件からスタートしてもプロンプト変更の影響を定量的に捉えられます。

evalの最小単位は**タスク（task）**だ。入力・参照解答・合格基準の3点セットで1件を定義し、エージェントに投入する。1回の試行を**トライアル（trial）**、採点ロジックを**グレーダー（grader）**、試行の全記録を**トランスクリプト（transcript）**と呼ぶ。

手動確認との最大の違いは「定量化」にある。プロンプトを変更したとき、スコアが上がったのか下がったのかが数値で見える。感覚ではなくデータでシッピング判断ができるようになる。

Anthropicのガイドラインは「初期の変更はエフェクトサイズが大きいため、少数サンプルでも十分な検出力がある」と説明する。バグ報告1件がそのまま検証タスク1件になる——だから20件でも動く。

## 20タスクから始める3ステップはどれか

> 実際の失敗ケース20件を起票し、タスクspec・隔離された試行環境・採点ロジックの3要素を整えると、1週間以内にevalが稼働します。

**ステップ1: 実失敗をタスクに転記する**

サポートキューのチケットやバグ報告から20件を選ぶ。架空のシナリオより実際に起きた失敗の方が、エージェントの弱点を正確に捉える。Anthropicは「合成シナリオより実失敗を優先せよ」と明記している。「この入力を与えたとき、このアウトカムが出ること」を各タスクに明確に書く。

**ステップ2: タスクspecを書く**

各タスクに「入力」「参照解答または合格基準」「採点方法」の3点を定義する。合格基準があいまいだとグレーダーが安定しない。参照解答は人間が手作業で作成し、エージェントが到達可能であることを事前に確認しておく（解けないタスクを混ぜると偽陰性が増える）。

**ステップ3: 試行環境を隔離する**

各トライアルはクリーンな状態から独立して始まる設計が必要だ。前のトライアルの副作用——DBの状態変化・外部API呼び出し履歴——が次に漏れると再現性が失われる。モックサーバーやスナップショットDBを使い、各トライアルを完全にリセットする。

## グレーダーはどう選ぶべきか

> コードベースを主軸に、複雑な判断のみモデルベースを補完し、人間レビューはキャリブレーション専用に限定する3層構成が推奨です。

3種類のグレーダーを組み合わせて使う。

**コードベースグレーダー**: 文字列一致・正規表現・APIの戻り値確認など。高速・再現性100%・コスト最小。可能な限りここから始める。

**モデルベースグレーダー（LLM-as-judge）**: LLMに採点させる。自然言語の応答品質や主観判断が必要な場合に使う。ルーブリック（採点基準）を明文化することで採点の一貫性が上がる。

**人間グレーダー**: 主観が強いドメインや、モデルグレーダーの採点精度をキャリブレーションする用途に限る。日常の採点には使わない。

重要な設計原則は「**パスではなく結果を採点すること**」だ。ステップAからステップBを経てCに至るルートを固定すると、別の正しいルートが「失敗」として記録される。最終アウトカムが合格基準を満たしているかどうかを採点する。

[エージェントガバナンス](/glossary/agent-governance/)の観点からも、採点ロジックのバージョン管理とグレーダー自体のテストは不可欠だ。グレーダーが壊れていれば評価スコアは意味をなさない。

## ツールはどれを選ぶべきか

> 無料OSSから始め、件数が増えたらプロンプト実験管理と連携できるツールへ段階的に移行する2段階アプローチが現実的です。

主な評価ツールを比較する。

| ツール | 特徴 | 推奨用途 |
|---|---|---|
| **Arize Phoenix** | 完全OSS・OpenTelemetryネイティブ・無料無制限 | 初期スタート |
| **Langfuse** | OSS自己ホスト可・クラウド月額$49〜 | トレーシング重視 |
| **Braintrust** | Hobbyプラン無料・プロンプト実験管理が強い | 実験管理が必要になった段階 |
| **MLflow** | OSS・月30M+ダウンロード・メトリクス網羅性最大 | 既存MLパイプラインとの統合 |

**推奨スタート順序**:

1. **Arize Phoenix**: 完全無料でセルフホスト可。OpenTelemetry計装だけで連携でき、ベンダーロックインがない。エージェント評価専用のEvaluatorを標準搭載している。
2. **Langfuse**: トレーシング基盤を先に整えてから評価レイヤーを積み上げたいチーム向け。Dockerで起動すれば追加費用なし。
3. **Braintrust**: eval-driven development（プロンプト変更をeval結果で判断する開発フロー）が定着した段階で移行を検討する。

Kuuの[AIエージェント運用管理サービス（AI Ops）](https://kuucorp.com/services/ai-ops/)では、評価設計の初期立ち上げから継続運用までを支援している。

## 参考

- [Demystifying evals for AI agents（Anthropic Engineering）](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents)
- [Agent-first comparison guide vs Braintrust（Latitude）](https://latitude.so/blog/agent-first-comparison-guide-vs-braintrust)

## まとめ

AIエージェントのevalは大規模インフラなしに始められる。実際の失敗ケース20件を起票し、コードベースグレーダーを主軸にした採点ロジックを書き、Arize PhoenixかLangfuseで可視化する——これが最小構成だ。スコアが安定したらタスク数を増やし、CI/CDパイプラインへ組み込む段階（[エージェント評価のCI/CD統合](/blog/agent-evaluation-cicd-pipeline-automation/)）に移行できる。

評価設計の初期セットアップから継続運用まで、Kuuの[AIエージェント運用管理（AI Ops）](https://kuucorp.com/services/ai-ops/)から相談を受け付けている。