ThinkingBox がデータベース結果と繰り返し信頼性で AI エージェントを評価

2026年10月4日 – Microsoft の研究者は Hugging Face 上で ThinkingBox を公開し、外部ツールと対話する大規模言語モデル（LLM）エージェントを評価する新しい方法を導入しました。 従来のベンチマークが正しい自然言語の回答や構文的に有効なツール呼び出しを報酬とするのに対し、ThinkingBox はエージェントがビジネスワークフローを実行した後のバックエンドの最終状態と副作用を測定します。 ベンチマークは、受注入力、在庫更新、顧客レコードの修正など、507 の異なるステートフルなビジネスプロセスを含み、各プロセスを Microsoft Copilot（MCP）ツールセッションで 20 回ずつ実行します。 データベースの実際の結果に焦点を当てることで、繰り返しの実運用でのみ顕在化する信頼性問題を浮き彫りにすることを目的としています。

ThinkingBox の仕組み

507 のワークフローはすべて、リレーショナルデータベースを操作するツール呼び出しのシーケンスとしてエンコードされています。 ベンチマークは各試行ごとに MCP ツール環境を完全に分離して実行し、クロスランの汚染がエラーを隠すことがないようにします。 エージェントが実行を完了した後、ThinkingBox は最終的なデータベーススナップショットを検査し、期待される行、列の値、監査ログなどの副作用を列挙したグラウンドトゥルース仕様と比較します。 採点基準は、エージェントが流暢なテキスト要約を生成したかどうかは考慮せず、バックエンドの状態が仕様と一致しているか、意図しない変更が生じたか、ツールがエラーを報告したかのみを記録します。

評価は、オープンソースモデルから商用提供まで、合計 12 の公開されている LLM エージェントを対象に実施されました。 全体で 121,680 件の有効試行が生成され、これは 507 のワークフロー、20 回の繰り返し、12 のモデルの積算です。 そのうち 79,853 件は実行可能チェック段階で失敗し、エージェントが必要なツール呼び出しを行わなかったか、解析できない呼び出しを生成したことを示します。 特筆すべきは、失敗した試行の 67.24 % が最終的なツールエラーなしに終了しており、少なくとも一度は状態変更ツールを呼び出した後に停止している点です。 このパターンは、エージェントが表面的には成功したように見えても、データベースに隠れた不整合が残っていることを示す重要な指標となります。

主な発見

実行可能チェックに失敗した試行について、ベンチマークは 3 つの偏差カテゴリを記録しました。 フィールド値が誤っているケースは失敗試行の 77.61 % に現れ、ツール呼び出しが成功してもエージェントが誤ったデータを書き込むことが頻繁に起こることを示しています。 意図しない効果、すなわちワークフローで指定されていないデータベース部分が変更されたケースは 43.30 % の失敗で観測され、期待された変更が全く行われなかった欠落効果は 25.36 % に相当します。 これらの割合は重複する可能性があり、単一の実行で複数のエラータイプが同時に発生することがあります。 これらの数値は、ツール駆動型の失敗の大多数がデータベースを不整合または部分的に正しい状態に留めることを示しています。

モデル間のパフォーマンスは大きく異なります。 Claude Opus 5.5 は pass@1 スコアで最高を記録し、121,680 件の試行のうち 67.16 % を最初の試行で成功させました。 一方、Kimi‑K3 は別のプロファイルを示し、20 回の繰り返しのうち少なくとも一度は 93.89 % のタスクを解決したものの、すべての繰り返しで成功したのはわずか 13.41 % にとどまりました。 この対照は、単一のベストケースではなく、繰り返し実行における信頼性を測定する重要性を強調します。 残りのモデルはこの極端の間に位置し、多くは pass@1 が 50 % 未満で、繰り返しごとの変動が大きいことが報告されています。

ベンチマークの限界

ThinkingBox は意図的に選定されたビジネスワークフローのセットに限定されており、著者らはこの数値が企業が直面するすべての本番シナリオを代表するものではないと強調しています。 ベンチマークは各試行を新しい MCP セッションで分離して実行するため、長期的な状態蓄積やキャッシュ、ワークフロー間の依存関係といった実運用システムで見られる影響は除外されています。 加えて、評価はリレーショナルデータベースの結果に焦点を当てており、非 SQL サービス、ファイルシステム、外部 API とやり取りするエージェントは対象外です。 最後に、メトリクスはグラウンドトゥルース仕様からのいかなる逸脱も失敗とみなすため、特定のビジネスコンテキストで無害な逸脱であっても失格となります。

• 121,680 件の総試行のうち 79,853 件が実行可能チェックで失敗しました。
• 失敗した試行の 67.24 % が最終ツールエラーなしに正常終了しました。
• 失敗の 77.61 % がデータベースのフィールド値の誤りを報告しました。
• 失敗の 43.30 % が意図しない副作用を生み出しました。
• 失敗の 25.36 % が期待された効果を欠落させました。
• Claude Opus 5.5 が pass@1 で 67.16 % の成功率でトップに立ちました。
• Kimi‑K3 はタスクの 93.89 % を少なくとも一度は解決しましたが、すべての 20 回の実行で成功したのは 13.41 % でした。

実務への影響は開発者にとって直ちに重要です。 エージェントが静かに誤ったデータを書き込んだり、必要な更新を見逃したりする頻度を明らかにすることで、ThinkingBox は「ツール呼び出しが成功したか？」から「データベースが正しくなるか？」への視点転換を促します。 チームはこのベンチマークを活用してロバスト性テストの優先順位を付け、補償トランザクションを追加したり、冪等性を強化するプロンプト設計を見直したりできます。 データはベンダーにも具体的な目標を提供し、単一ショットの高い合格率だけでなく、実行の繰り返し可能性を向上させることが求められます。 企業が重要なバックオフィス業務に LLM エージェントを導入する中で、基盤データの信頼性を保証できることが競争上の差別化要因となります。

今後、Microsoft と広範な研究コミュニティは ThinkingBox を追加のワークフローカテゴリ、よりリッチな副作用追跡、継続的インテグレーションパイプラインとの統合で拡張する計画です。 ベンチマークはすでに Hugging Face で公開されており、誰でも同じ 507 のワークフローを自分のエージェントに対して実行し、公開されたベースラインと比較できます。 結果指向の評価をオープンかつ再現可能にすることで、ThinkingBox は業界が AI エージェントの信頼性を測る方法を変えることが期待されます。 データベースという最終的な真実の源が意図したビジネス成果を正しく反映しているかどうかという、より深い問いへと議論をシフトさせるでしょう。