エージェントを作ると、最初に「動いた」が来る。次に来るのが「これは業務で使えるのか」という問いで、ここで多くのプロジェクトが止まる。
止まる理由は、評価の方法を持っていないからである。チャットボットなら回答を読めば良し悪しが分かる。しかしエージェントは何度もツールを呼び、外部の状態を書き換え、最後に「完了しました」と報告する。その報告が本当かどうかは、報告を読んでも分からない。
Anthropicは2026年1月に公開したエージェント評価の記事で、この点を明確に述べている。エージェントの評価はチャット応答の評価とは別物であり、最終メッセージだけを採点していると見えない失敗があると。
本記事は、その評価セットを実際に作って運用するための設計を扱う。「生成と評価を分ける」という原則そのものはハーネスエンジニアリングとは？エージェント品質の決め手で扱っているので、ここでは何を測り、どう作り、どう回すかに絞る。
この記事の対象読者
- エージェントを実装したが、本番投入の可否を判断する材料が無い開発者
- モデルやプロンプトを変えたときに品質が上がったか下がったか分からないチーム
- AI導入の効果を経営に説明する必要があり、定量的な根拠を用意したい推進担当者
- 本番で起きた失敗が再発しない仕組みを作りたい運用担当者
なぜチャットの評価と別物なのか
| チャット応答 | エージェント | |
|---|---|---|
| 出力 | 1つのテキスト | 複数のツール呼び出しと外部状態の変更 |
| 正解 | 概ね1つ | 複数の経路がありうる |
| 失敗の見え方 | 読めば分かる | 完了報告は正常に見える |
| 副作用 | 無い | ある（データが書き換わる） |
決定的なのは3行目である。エージェントは失敗しても「完了しました」と報告する。 途中でツール呼び出しに失敗し、諦めて要約だけ返しても、最終メッセージは正常に見える。予約を取れと言われて取れなかったのに、取れたかのように書くこともある。
つまり最終メッセージを採点している限り、エージェント特有の失敗は検出できない。
何を測るか — 最終状態を採点する
採点対象は大きく2つに分けられる。
環境の最終状態：タスク終了時に、外部システムが期待どおりになっているか。「予約レコードがデータベースに存在するか」「ファイルが正しい内容で書かれているか」「チケットのステータスが更新されているか」。これは決定論的に判定できる。
トランスクリプト（実行の全記録）：出力、ツール呼び出し、推論、中間結果を含む実行の記録。どう判断したかが分かる。
採点は最終状態を優先する。 Anthropicの記事も、エージェントが辿った経路ではなく生み出した結果を採点するほうが良い場合が多いとしている。経路を厳密に採点すると評価が硬直し、より良い解き方を見つけたエージェントを不合格にしてしまう。
ただしトランスクリプトを読まなくてよいわけではない。結果で採点し、経路は読む。 読む目的は採点ではなく、採点者が正しく機能しているかの確認と、失敗の原因究明である。
補助的に見る指標
- タスク成功率：最終状態が期待どおりだった割合。主指標
- ツール呼び出しの妥当性：不要な呼び出しや誤った引数の頻度
- コストとレイテンシ：同じ成功率なら安く速いほうがよい
- 人間介入率：どれだけ人が引き取ったか。運用負荷の実測値
成功率だけを見ない。 成功率が同じでもコストが3倍なら、それは劣化である。
評価セットの作り方
20〜50件から始める。網羅を待たない
最も多い失敗は、包括的なデータセットを作ろうとして着手が遅れることである。Anthropicの記事は、実際に起きた失敗から20〜50件の簡単なタスクを集めて早く始めることを推奨している。開発の初期は効果量が大きいため、少ないサンプル数でも差が見える。
完璧な評価セットを待つ間に、品質の分からないものが本番に出る。先に20件作ることが正しい。
実際の失敗を出発点にする
ゼロから想像でケースを作らない。材料は既にある。
- 手動で確認していたチェック項目
- 報告されたバグ
- 本番のトランスクリプトのうち、人が引き取ったもの
- 「この聞き方をされると弱い」と現場が知っている質問
バグ報告をテストケースに変換する運用を定着させる。 これができると、同じ失敗が二度起きない仕組みが自動的に育っていく。
タスクは曖昧さを残さず、参照解を持たせる
「良い感じに要約して」は評価できない。何をもって成功とするかが一意に決まる書き方にする。参照解（期待される最終状態）を必ず付ける。
正例と負例を両方入れる
成功すべきケースだけを集めると、「常に実行する」エージェントが満点を取る。実行してはいけないケース、情報が足りず確認を返すべきケース、権限が無いので拒否すべきケースを入れる。
実務では負例のほうが事故に直結する。「やらないべきときにやらない」を測れない評価セットは、本番の安全性を保証しない。
環境は隔離してリセット可能にする
エージェントは外部状態を書き換えるため、実行のたびに環境を初期状態へ戻せないと再現性が無い。本番データベースに対して評価を回さない。前の試行の副作用が次の試行の入力になる状態は、評価として成立しない。
採点者の設計
決定論的な判定を優先する
判定できるものはコードで判定する。 レコードの存在、数値の一致、スキーマ適合、ファイルの内容。LLMに採点させる必要は無い。
決定論的な判定は速く、安く、ぶれない。LLM採点者は「他に手が無いとき」の選択肢である。
LLM採点者を使うときの3条件
主観的な品質（文章の質、説明の妥当性、トーン）はコードで測れない。ここでLLM採点者を使うが、以下を満たさないと採点そのものが信用できない。
1. 人間の専門家と定期的に校正する。 採点者の判定と人間の判定を突き合わせ、ずれていたら基準を直す。校正していない採点者のスコアは、上がっても意味が分からない。
2. 逃げ道を用意する。 情報が足りないときに「不明」を返せる選択肢を構造として与える。逃げ道が無い採点者は、判断できない場合でも無理に○か×を付ける。 これはノイズになる。
3. 次元ごとに分ける。 1人の採点者に「総合的に良いか」を聞かない。正確性、網羅性、トーンといった軸ごとに独立した採点者を立てる。総合評価は分解できない曖昧な数字になりやすい。
採点者が正しいかを確認する
トランスクリプトを読む。 採点結果だけを見ていると、採点者のバグに気づけない。合格したケースと不合格のケースをそれぞれ数件読み、採点が妥当かを人間が確認する。この作業を飛ばした評価セットは、間違った方向に最適化する装置になる。
運用 — 作って終わりではない
回帰スイートとして回す
モデルを変えたとき、プロンプトを変えたとき、ツールを足したときに自動実行する。「変えたら良くなった気がする」を「変えたらこの指標がこう動いた」に変えるのが評価セットの本来の価値である。
サチュレーションを監視する
全問正解が続いたら、その評価セットは差を検出できなくなっている。満点は良い知らせではなく、評価セットの寿命が来た合図である。 より難しいタスク、より曖昧な指示、より複雑な負例を足して難度を上げる。
本番のトレースを取り込む
本番で起きた失敗をテストケース化する経路を作っておく。評価セットが本番から育つ構造にできると、想像で作ったケースより実態に合った品質保証になる。
よくある失敗
最終メッセージだけを採点する。 エージェント特有の失敗が検出できない。最終状態を見る。
完璧な評価セットの完成を待つ。 20件で始める。
正例だけを集める。 「やらないべきときにやらない」が測れない。
本番環境で評価を回す。 副作用が残り再現性が無くなる。隔離してリセット可能にする。
LLM採点者を校正せずに使う。 スコアが動いても何が起きたか分からない。
成功率だけを見る。 コストとレイテンシと人間介入率を併記する。
満点を成果として報告する。 評価セットが古い可能性を疑う。
FAQ
Q1. 評価セットは何件必要か？
まず20〜50件で始める。 実際の失敗から集めれば、この規模でも初期の改善は十分検出できる。網羅性を追うのは、その仕組みが回り始めてからでよい。件数より、実態に基づいているかのほうが効く。
Q2. 経路を採点してはいけないのか？
主指標にしないほうがよい、という意味である。経路を厳密に採点すると、より良い解き方を見つけたエージェントが不合格になる。結果で採点し、経路は原因究明と採点者の検証のために読む。 ただし「この操作は絶対に踏んではいけない」という禁止経路は、明示的なチェックとして入れる価値がある。
Q3. LLM採点者のスコアはどこまで信じてよいか？
人間の専門家との校正が取れている範囲までである。校正していないスコアは、絶対値としても相対値としても解釈できない。定期的に人間の判定と突き合わせ、ずれを補正する運用とセットで初めて使える。
Q4. 評価セットの保守は誰がやるのか？
作った人ではなく、本番の失敗を最初に見る人が起点になる設計が回りやすい。運用担当がバグ報告をテストケース化する経路を持ち、開発側が回帰スイートに取り込む。専任を置く必要は無いが、経路は決めておく。
Q5. 評価にかかるコストが気になる
決定論的な判定を増やすほど安くなる。LLM採点者は主観的な品質の軸だけに絞る。また、全件を毎回回す必要は無い。変更の影響範囲に応じてサブセットを回し、リリース前にフルスイートを回す運用でよい。
Q6. 評価結果を経営にどう説明するか？
タスク成功率の推移と、人間介入率の推移を並べる。「AIが何％正しいか」より「人がどれだけ引き取らずに済んでいるか」のほうが、業務価値として通じる。 コスト削減効果もここから逆算できる。
Q7. 評価セットを作る余裕が無い場合は？
手動で確認している項目を書き出すところから始める。 それは既に評価基準である。文書化されていないだけで、誰かの頭の中に基準はある。20件書き出せば評価セットの初版になる。
次に読むべき記事
- ハーネスエンジニアリングとは？エージェント品質の決め手 — 生成と評価を分ける原則と、ハーネス全体の設計
- ループエンジニアリング入門｜自律エージェントを動かし続けるハーネス設計の体系 — 停止条件と検証階層
- マルチエージェント実装ガイド｜協調・分業の設計パターンと運用設計 — 複数エージェント構成での評価対象
- AI PoCが失敗する5つの構造的理由と回避策｜本番化に進めるPoCの設計 — 検証段階でのつまずき
まとめ
- エージェントの評価はチャットの評価と別物である。失敗しても完了報告は正常に見えるため、最終メッセージの採点では特有の失敗を検出できない
- 採点は環境の最終状態を優先する。経路を厳密に採点すると、より良い解き方を不合格にする。結果で採点し、経路は読む
- 評価セットは実際の失敗から20〜50件で始める。包括的なデータセットの完成を待たない
- 正例と負例を両方入れる。「やらないべきときにやらない」を測れない評価セットは安全性を保証しない
- 環境は隔離しリセット可能にする。本番に対して評価を回さない
- 判定できるものはコードで判定する。LLM採点者は主観的な軸に限り、人間との校正・逃げ道・次元ごとの分割の3条件を満たして使う
- 満点が続くのは評価セットの寿命が来た合図である。難度を上げる
- 成功率だけでなく、コスト・レイテンシ・人間介入率を併記する
FDXのエージェント評価設計支援
FDXはAX（AI Transformation）の実装パートナーとして、エージェントの実装だけでなく、業務で使える品質かを判定する評価設計と、その運用移管までを対応領域とする。
「動くものはできたが、本番に出す判断ができない」という段階であれば、現場が手動で確認している項目を評価セットに変換するところから着手するのが早い。業務の分解と適用範囲の整理はAX診断で扱っている。実装体制の相談はお問い合わせからどうぞ。
出典・参考文献
- Anthropic Engineering Blog「Demystifying evals for AI agents」2026年1月9日公開（実際の失敗から20〜50件で開始する、バグ報告をテストケース化する、経路より結果を採点する、決定論的な判定を優先する、LLM採点者は人間との校正と「不明」の選択肢を持たせ次元ごとに分ける、トランスクリプトを読んで採点者を検証する、サチュレーションを監視する）