🧠 AI プロダクト動向

従来の評価は、モデルの出力テキストを正解文やルーブリックと突き合わせる方式が中心だった。これに対し outcome/state チェックは、判定対象をテキストではなく「実行後の環境の状態」に置く。コーディングエージェントなら テストが通るか、カスタマー対応エージェントなら返金レコードが実在するか、ブラウザ操作エージェントなら対象ページの状態が変わったかを見る。

この転換が起きた理由は、エージェントが同じ正解にたどり着く経路が一通りではなくなったからだ。ステップの順序やツール呼び出しの回数まで厳密一致を求める評価は、有効なバリエーションを次々と「不合格」に弾いてしまい、評価そのものが開発のボトルネックになる。状態を見れば、経路が違っても結果が正しければ合格にできる。

評価セットを人力で維持し続けるのは、エージェントの生産量が増えるほど破綻する。そこで採られているのが、人間のレビュー修正やコメントをそのまま「同じ種類の問題を再度検知できるか」の回帰ケースに変換し、CIのベースラインチェックやリスクスコアリングと組み合わせてマージ経路を自動判断する仕組みだ。低リスクな変更は自動パスに、高リスクな変更は適切な担当者にルーティングされる。

この構成が広がっているのは、評価セットの拡充を専任チームの追加作業にしないためだ。本番で見つかった不具合やレビュー指摘を、そのまま次の評価に変換する導線を先に作っておけば、エージェントの利用が増えるほど評価セットも自動的に厚くなる。人手を増やさずに評価のカバレッジを利用量に追随させられる。

エージェントの自律性が上がり、辿る経路（パスファインディング）が増えるほど、想定すべき評価シナリオは足し算ではなく掛け算で増えていく。この問題への対処として、恒常的にほぼ100%を維持すべき「回帰eval」と、新モデルの能力を測るための「フロンティアeval」を明確に分離し、後者の結果に応じてユースケースごとに新モデルの採否を決める運用が定着しつつある。

背景にあるのは、フロンティアモデルのリリース頻度そのものが上がったことだ。数週間おきに新モデルが出る状況では、評価は「一度作って終わり」ではいられず、リリースのたびに「このユースケースに新モデルを使うか」を素早く判断するための恒常的な意思決定インフラにならざるを得ない。