AIエージェントの評価とリグレッション — evalの回し方

検証ループを組むと、1回の作業は自走するようになります。次に出てくる問題は別の種類のものです。設定を変えたら良くなった気がするが、本当に良くなったのか分からない。指示ファイルを直した、ツールを足した、モデルを変えた——そのたびに手応えは変わりますが、手応えは証拠ではありません。

これを潰すのが評価（eval）です。この章では、エージェントに対する評価が普通のテストと何が違うのかを確認したうえで、どう始めてどう回すかを整理します。

ふつうのテストとは別物である

Anthropicが2026年1月に公開した記事は、エージェントの評価が難しい理由を構造から説明しています。エージェントは複数のターンにわたって動作し、ツールを呼び、状態を変え、途中の結果を見て適応します。だから単一の入出力を見る評価より複雑になる、というものです。

普通のテストと並べると違いがはっきりします。

最後の行が効いてきます。正解が1つに定まらないものを、どう採点するのか。

結果を採点するのか、経路を採点するのか

ここが評価設計の中核です。同記事は2つを明確に区別しています。

• 結果（outcome） — 作業が終わった時点での、環境の最終状態
• 記録（transcript） — 出力・ツール呼び出し・推論・途中結果を含む一部始終

そして推奨は明快で、エージェントが取った経路ではなく、生み出した結果を評価するほうがよいというものです。

理由も示されています。エージェントは設計者が予想しなかった有効な手を見つけることが多く、経路で採点するとそれを罰してしまうからです。同記事では、モデルが評価の仕様には反しつつユーザーにとってより良い解を見つけた例が挙げられています。

「正解の手順」を採点すると、想定外の良い解を減点することになります。

結果を見るとはどういうことか。同記事の例が分かりやすく、予約エージェントが「予約しました」というテキストを返しても、実際に予約がデータベースに存在するかどうかが本当の結果です。エージェントの自己申告は結果ではありません。

ただし例外もあります。コードの品質のように、どう書いたかそのものを見たい場合は記録も採点対象になる、と同記事は述べています。

20〜50件から始める

評価の話になると「ちゃんとしたスイートを整備してから」と考えがちですが、公式の指針は逆です。

同記事が示す開始規模は20〜50個の簡単なタスクです。理由は、開発の早い段階では変更ひとつひとつの影響が大きいため、小さなサンプルでも十分に信号が取れるからです。

そして明確な警告があります。完璧なスイートを待つな。待つほど、すでに動いているシステムから成功基準を逆算するのが難しくなる、というものです。

評価を作るのに最も向いているのは、まだ何も安定していない時期です。

材料の取りどころも具体的に示されています。

モデルに採点させるとき

正解が複数ありうるタスクでは、モデル自身に採点させる方法（LLM-as-judge）が有効です。柔軟でスケールし、ニュアンスも拾えます。ただし同記事は、注意点をはっきり列挙しています。

較正を省くと、採点器が何を測っているのか誰も分からないまま数字だけが動く状態になります。これは評価がない状態より危険です。数字があると、それを信じてしまうからです。

採点器そのものを疑う

同記事でいちばん実務的なのが、この視点です。スコアが上がらないとき、エージェントの性能の問題なのか、評価の問題なのかを区別する必要がある。

記事には、あるモデルのスコアがあるベンチマークで42%から95%に跳ね上がった例が挙げられています。モデルが劇的に賢くなったのではなく、採点のバグと課題の曖昧さを見つけて直した結果です。

そして、それを見つける方法は1つしかないとも述べられています。多くの記録を実際に読むこと。採点器がうまく働いているかどうかは、集計値からは分かりません。

スコアだけを見ていると、測れていないものを改善しようとすることになります。

同記事は「失敗は公正に見えるべき」という言い方もしています。記録を読んで、その失敗がエージェントのせいだと納得できるかを確かめる、ということです。納得できないなら、直すべきは採点器のほうです。

飽和を監視する

評価には寿命があります。同記事が挙げるのが飽和で、能力を測る評価が100%に達すると、そこから先は改善の信号が出なくなります。

例として、あるコーディングのベンチマークが30%から80%超まで進んだ経緯が触れられています。かつては差がついた課題が、今はほぼ全部通る。そうなったら、より難しい評価に作り替える必要があるということです。

これは本書全体のテーマとも重なります。評価もまた、放っておくと腐ります。

運用に載せる

最後に、続けるための形です。同記事が推奨しているのは評価駆動開発で、機能を実装する前にその機能の評価を作り、通るまで反復するという進め方です。

体制についても知見が示されています。うまくいった形は、評価チームが中核の仕組みを持ち、ドメインの専門家と製品チームが課題を持ち寄るというものでした。評価の維持を「誰かが気づいたらやる作業」にすると続きません。

同記事の締めの表現を借りれば、ユニットテストを保守するのと同じくらい日常的なものとして扱う、というのが到達点です。

よくあるハマりどころ

完璧なスイートを待つ。 前述のとおり、待つほど作りにくくなります。20件でいいので今日作るほうが価値があります。

経路を採点する。 「この手順を踏むこと」を評価にすると、より良い解が減点されます。結果で見ます。

採点器を疑わない。 スコアが動かないとき、まず疑うべきは評価側かもしれません。記録を読みます。

モデル採点を較正せずに信じる。 人間の判断と突き合わせていない採点は、方向が合っている保証がありません。

1回作って放置する。 飽和した評価は、通っていても何も教えてくれません。

自己申告を結果として扱う。 「完了しました」は出力であって、環境の状態ではありません。

ちゃんと使うためのポイント

• エージェントの評価は非決定的で、正解が複数ありうる。ユニットテストとは別物
• 経路ではなく結果を採点する。ただしコード品質など、書き方そのものを見たいときは記録も対象
• 20〜50件から始める。完璧なスイートを待たない
• 材料は手で確かめていること・バグトラッカー・実際の失敗から取る
• モデル採点は人間と較正する。「不明」を許し、観点ごとに分ける
• スコアが動かないときは採点器を疑い、記録を読む
• 評価は飽和する。通り切ったら作り替える
• 実装前に評価を作り、ユニットテストと同じ頻度で保守する

次の章では、ここまで積み上げてきた仕組みを回し続けるためのコストを扱います。評価もエージェントも、動かせば費用がかかります。

参考リンク

• Demystifying evals for AI agents（Anthropic, 2026-01-09） — 本章の中心。結果と記録の区別、開始規模、モデル採点の注意、飽和
• Define success criteria and build evaluations（Claude 公式ドキュメント） — 成功基準の立て方と評価の実装
• Writing effective tools for AI agents（Anthropic, 2025-09-11） — 評価を使ってツールの変更効果を測る進め方