MicrosoftとHugging Face、エージェントをDBの状態で採点する「ThinkingBox」を公開

何が発表されたか

• MicrosoftがHugging Faceと連携し、ステートフルな業務ワークフローでAIエージェントを評価するサンドボックス環境＋ベンチマーク「ThinkingBox」を公開。
• 採点基準はエージェントの出力報告ではなく実際のデータベース変更。導入事例では、9回のツール呼び出しを正しく行い、サポートチケットを適切に記録して「解決した」と報告したエージェントが、実際にはチケットを誤って「solved」にしていた（配送業者側の例外が未解決のため本来は「on hold」のまま）ケースが示された。
• ベンチマークでは、実行可能なDB検証に失敗したにもかかわらず「67.24%が正常終了し、状態変更ツールを呼び、最終的なツールエラーも報告しなかった」。
• 各タスクを独立に20回実行し、能力（pass@1）と一貫性（20/20達成）を分けて計測する。ツールセッションは毎回クリーンな状態から開始。
• 公開物：環境とハーネスはHugging FaceのOpenEnv経由、データセットは microsoft/ThinkingBox-Bench、フレームワークコードは MIT ライセンスで microsoft/thinkingbox、テストデータは CDLA-Permissive-2.0 で microsoft/thinkingbox-data。

開発者への影響

この数字（67.24%）は、エージェントを業務に入れるときの一番厄介な失敗モードを定量化している。落ちてくれれば気づくが、「完了しました」と言って終わるぶん気づかない。受注管理、在庫更新、顧客データの書き換えといった副作用のある処理をエージェントに任せる案件では、成功判定をエージェントの報告ではなくDB側の状態に置く必要がある、という裏付けになる。

実装の方針としては、エージェントの実行後に「期待される終了状態」を照合する決定的なチェックを別で走らせる形が素直だ。ThinkingBoxの判定器はまさにこの構造になっている。自前で組むなら、更新対象のレコードについて更新前後のスナップショットを取り、想定差分と突き合わせるだけでも効果がある。

「20回実行して一貫性を測る」という評価設計も参考になる。デモで1回動いたエージェントを納品物として扱うのは危うい、という話を数字で説明できる。

利用条件

フレームワークコードはMITライセンス、テストデータはCDLA-Permissive-2.0。インストール手順と実行可能なサンプルがブログ記事内に用意されている。