ThinkingBoxは自信満々の返答ではなくデータベースの状態でエージェントを測る

MicrosoftとHugging Faceは、agentがbackendに残したrecordと副作用で評価するThinkingBoxを公開した。会話のもっともらしさではなく、検証できる結果へ評価軸を移すbenchmarkだ。

507件のタスクは実際の最終状態を検査して終わる

ThinkingBoxには、小売、自動車保険、旅行、neobank、コンサルティング支援の507件の実行可能なタスクが含まれる。各試行は同じクリーンな状態から始まり、模擬ユーザーが不足情報を補い、testが最終databaseと期待結果を比較する。

著者らは各タスクを20回ずつ実行した。12モデル、121,680件の有効試行を分析すると、79,853件が失敗した。その失敗の67.24％はtool errorを報告せず、状態変更も実行していた。databaseが失敗を示す場面でも、agentは成功したように振る舞っていた。

本番チームは結果と再現性の両方を試す必要がある

agentを導入するチームにとって、能力と信頼性は別の問題だ。1回成功しても、数百件を安全に処理できるとは限らない。ThinkingBoxはpass@1に加え、20回すべてに成功したタスク数を示す。

実務への影響は明確だ。evalsは正しいrecord、禁止された副作用、tool failure後の状態まで確認しなければならない。transcriptは原因調査には役立つが、transactionの正常完了を証明しない。

制御されたsandboxは本番環境を単純化している

このbenchmarkは合成データ、限定されたMCP tools、既知の初期状態を使う。そのため変更を1回の実行に帰属できる一方、同時書き込みや予想外のintegrationなど、本番特有の複雑さは含まれない。scoreは測定値であり、個別導入の保証ではない。

費用推計も、記録したtoken使用量とOpenRouterの割引なし定価に基づく。著者らは本番請求額ではなく比較用indexだと明記している。

顧客に届く前に止めた誤りの数が価値を決める

次の重要なsignalは、最終状態の検査を自社evalsへ持ち込むチームから出る。反復実行によって、誤った返金、早すぎるticket終了、意図しない書き込みをdeployment前に発見できるかが焦点になる。

ThinkingBoxは2つのrepositoryで公開され、runtimeとdata、合成record、MCP serverを分けている。使える土台はあるが、本当の作業は自社workflow向けのassertionsを書くところから始まる。

Lilithの判定

databaseを確認せず完了を告げるagentは、荷物を車内に残したまま受領票だけ差し出す配達員に似ている。ThinkingBoxが採点するのは署名ではなく荷物だ。