従来の評価は、モデルの出力テキストを正解文やルーブリックと突き合わせる方式が中心だった。これに対し outcome/state チェックは、判定対象をテキストではなく「実行後の環境の状態」に置く。コーディングエージェントなら テストが通るか、カスタマー対応エージェントなら返金レコードが実在するか、ブラウザ操作エージェントなら対象ページの状態が変わったかを見る。
この転換が起きた理由は、エージェントが同じ正解にたどり着く経路が一通りではなくなったからだ。ステップの順序やツール呼び出しの回数まで厳密一致を求める評価は、有効なバリエーションを次々と「不合格」に弾いてしまい、評価そのものが開発のボトルネックになる。状態を見れば、経路が違っても結果が正しければ合格にできる。
", "examples": [ { "product": "Anthropic（公式エンジニアリングブログ）", "approach": "コーディング/カスタマー対応/ブラウザ/データエージェントそれぞれについて、テキスト一致ではなくテストの合否や実データの状態変化を判定基準にするよう明文化", "detail": "自社エージェント運用の知見として、判定基準をコード実行結果や環境状態という「壊れにくい対象」に固定する具体的な手法を提示している点が代表的", "source_url": "https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents" } ], "takeaway": "経路（トラジェクトリ）の妥当性ではなく、最終的な環境状態を検証対象にする。ステップ順序を厳格にチェックする eval は、有効なバリエーションを弾いて壊れやすい。" }, { "heading": "レビュー指摘がそのまま回帰テストになる", "body_html": "評価セットを人力で維持し続けるのは、エージェントの生産量が増えるほど破綻する。そこで採られているのが、人間のレビュー修正やコメントをそのまま「同じ種類の問題を再度検知できるか」の回帰ケースに変換し、CIのベースラインチェックやリスクスコアリングと組み合わせてマージ経路を自動判断する仕組みだ。低リスクな変更は自動パスに、高リスクな変更は適切な担当者にルーティングされる。
この構成が広がっているのは、評価セットの拡充を専任チームの追加作業にしないためだ。本番で見つかった不具合やレビュー指摘を、そのまま次の評価に変換する導線を先に作っておけば、エージェントの利用が増えるほど評価セットも自動的に厚くなる。人手を増やさずに評価のカバレッジを利用量に追随させられる。
", "examples": [ { "product": "Cursor（自動コードレビュー機構 Bugbot）", "approach": "人間のレビューコメントによる修正を回帰ケースに変換し、CIと専用エージェントによるエビデンス収集、リスクスコアリングによる自動マージ判断と組み合わせて運用", "detail": "Arize Observe 2026でCursorのフィールドエンジニアリング責任者が公開した運用フローで、レビュー指摘から評価セット拡充までを自動化のループにしている点が具体的", "source_url": "https://www.youtube.com/watch?v=Lsp5YZ9Jj3Q" } ], "takeaway": "評価セットは人力でメンテしない。本番のバグ報告やレビュー指摘が、そのまま次の回帰チェックに変換される導線を先に設計する。" }, { "heading": "エージェントの複雑化が評価の組み合わせ爆発を生む", "body_html": "エージェントの自律性が上がり、辿る経路（パスファインディング）が増えるほど、想定すべき評価シナリオは足し算ではなく掛け算で増えていく。この問題への対処として、恒常的にほぼ100%を維持すべき「回帰eval」と、新モデルの能力を測るための「フロンティアeval」を明確に分離し、後者の結果に応じてユースケースごとに新モデルの採否を決める運用が定着しつつある。
背景にあるのは、フロンティアモデルのリリース頻度そのものが上がったことだ。数週間おきに新モデルが出る状況では、評価は「一度作って終わり」ではいられず、リリースのたびに「このユースケースに新モデルを使うか」を素早く判断するための恒常的な意思決定インフラにならざるを得ない。
", "examples": [ { "product": "Notion AI（70人規模のAIチーム）", "approach": "手作業のJSONL採点から、LLM-as-judgeとカスタムスコアラーを組み合わせた数百のデータセット運用に移行し、回帰evalとフロンティアevalを分離して新モデルをユースケース別に24時間以内に採否判断", "detail": "Braintrustが公開した顧客事例で、「エージェントが辿る経路が増えるほど評価の組み合わせが爆発する」という課題認識と、それに対応した運用の変化が具体的に語られている", "source_url": "https://www.braintrust.dev/customers/notion" } ], "takeaway": "評価基盤は静的な合否判定ではなく、新モデルのリリースサイクルに合わせて『採用可否を短時間で判断できる』運用速度を持たせることを目標にする。" } ] }, "editorial": "3つの事例に共通するのは、evalを品質保証チームの後工程ではなく、開発ループそのものの一部として設計し直している点だ。ただしLangChainの調査が示す通り、観測性の導入率89%に対し評価の導入率は52%にとどまる。トレースは取れているのに、それを合否判定に変換する仕組みがまだ整っていないチームの方が、実際には多数派だろう。", "quick_picks": [ { "title": "LangChain「State of Agent Engineering」レポート", "summary": "1,340人へのサーベイで、観測性導入89%に対し評価導入は52%にとどまり、品質が本番投入の最大の障壁として挙げられたと報告している。本文で扱った『evalが後回しになりがち』という課題を裏付ける一次データだ。", "url": "https://www.langchain.com/state-of-agent-engineering" }, { "title": "Anthropic「Claude Code品質低下」ポストモーテム", "summary": "Claude Codeの品質劣化を招いた3つの独立したharness変更（reasoning-effort低下・キャッシュ最適化バグ・冗長性抑制プロンプト）を公式に分析している。regression evalが機能していれば本番投入前に検知できたはずの変化だった可能性を示す事例として、本文の回帰eval論と対になる。", "url": "https://www.anthropic.com/engineering/april-23-postmortem" }, { "title": "Engineering Reliable Coding Agents（arXiv）", "summary": "コーディングエージェントの信頼性はモデル単体ではなくharness・実行状態・検索・メモリ・権限・レビュー画面・リソース配分に依存すると論じ、164の学術文献と100件の実務記録を統合したモノグラフ。『多くの見かけ上のモデル失敗は、実はシステムの別の場所に原因がある』という指摘は、本文のoutcome/stateチェック論の理論的裏付けになる。", "url": "https://arxiv.org/abs/2608.13867" } ] }