🧠 AI プロダクト動向

Anthropicの評価解説は、評価を tasks（課題設定）・trials（試行）・transcripts（エージェントが何をしたかの記録）・outcomes（環境が最終的にどうなったか）・graders（採点ロジック）・harness（実行基盤）の6要素に分解する。重要なのは transcript と outcome を別々に採点する点で、途中で遠回りしても最終的に正しい状態に到達すれば outcome は満点になり得るが、「たまたま正解に辿り着いただけ」の軌跡を見逃さないために transcript 側の採点を残す。OpenAI の Agent Skills 向け評価ガイドも同様に、成功基準を outcome（タスクが完了したか）・process（意図したツールを辿ったか）・style（出力の体裁が規約に沿っているか）の3カテゴリに分けてから Skill を書くよう求めている。

この収束の背景には、エージェントのステップ数が増えるほど「最終出力だけ一致していればOK」という評価が機能しなくなるという共通の失敗体験がある。途中のステップでツール選択を誤っても、後続のステップで帳尻を合わせて正解に見える出力を返すことがあり、出力一致だけの評価ではこの種の事故が蓄積してから発覚する。複数社が同時期に「軌跡を分解して採点する」設計を公開したのは、単発の思想ではなく本番運用で共通して踏んだ落とし穴への回答といえる。

Replit は ViBench（Playwrightベースのeval agentがアプリを操作しながら仕様通りに動くか段階的に検証するオフラインベンチマーク）・本番A/Bテスト・Telescope（失敗した実行の軌跡を要約してベクトル化し、類似パターンをクラスタリングして可視化するシステム）の三層構成で評価基盤を運用している。Braintrustは、本番で見つかった不審なトレースをワンクリックで評価データセットのエントリに変換し、そのまま次回以降のデプロイで走る回帰テストにする機能を提供する。

両社に共通するのは、評価データセットを最初から網羅的に設計するのを諦め、本番トラフィックを「継続的に増え続けるテストケース集」として扱っている点だ。事前に書いたテストは想定した失敗しか捕まえられないが、本番トレースは実際に起きた失敗分布をそのまま反映する。スケールするほど人間が全トレースを目視確認できなくなるため、クラスタリングや自動変換によって「気づいた失敗を二度と起こさないテスト」に変換する仕組みが運用の中核になっている。

Vercel社内のtext-to-SQLエージェント「d0」は当初、18個の専用ツール（スキーマ検索・クエリビルダー・検証系など）を組み合わせる構成で成功率80%だった。これを「bashコマンドを実行できる」ツール1個だけに置き換え、ファイルシステム経由で社内の意味レイヤー（Cubeの YAML定義）を直接読ませる構成に変えたところ、成功率は100%に上がり、実行時間は3.5倍短縮、トークン使用量は37%減、ステップ数は42%減少した。

この変更が「賭け」ではなく検証可能な意思決定になったのは、変更前から成功率・レイテンシ・トークン数を継続的に測る評価の仕組みが既にあったからだ。評価基盤がない状態でツールを18個から1個に削るのは根拠のない賭けだが、評価があれば「ツールを増やして安全側に倒す」のではなく「減らして数値で確認する」という逆方向の判断にも踏み切れる。