ThinkingBoxベンチマークが507のビジネスワークフローにおけるAIエージェントの一貫性のギャップを明らかに

TL;DR

ThinkingBoxは、Hugging Face経由で現在利用可能であり、AIエージェントの最終データベース状態をチェックすることで評価する。これにより、ほとんどのエージェントは1回の実行では成功するが、20回の試行で正しい結果を再現できないことが明らかになり、12のLLM間でコストと一貫性のトレードオフが顕著であることがわかった。

1つのツール呼び出しは結果ではない

エージェントが有効なツール呼び出しを行っても、誤ったデータベースレコードを生成する可能性がある。

  • 12のLLMで121,680回のアブレーション実験を行った結果、79,853回の試行が実行チェックに失敗した。
  • その失敗のうち**67.24 %**は、クリーンに終了し、ツールエラーを報告せず、状態を変更した。
  • 失敗したトレースのうち、**77.61 %**は誤ったフィールド値を持ち、**43.30 %**は意図しない副作用を生じ、**25.36 %**は必要な効果を欠いていた。

"軌道は主張である。データベース状態こそが証拠。繰り返しは信頼の試練である。"

したがって、このベンチマークは表面的な対話やツール呼び出し回数ではなく、終端バックエンド状態に基づいてエージェントを評価する。

1回の成功は信頼性ではない

各タスクを20回実行することで、エージェントがどれだけ信頼できるかがわかる。

以下の3つのメトリクスが報告されている：

メトリクス 測定内容 解決する問い
pass@1 成功した試行の割合 モデルは通常、どのように動作するか？
pass@20 20回の試行の中で少なくとも1回成功したタスクの割合 たとえ1回でもタスクを解決できるか？
Observed 20/20 20回すべてで成功したタスクの数 すべての試行で正しく動作できるか？

ブログはObserved 20/20に焦点を当てる——つまり、すべての繰り返しで成功したタスクの実際の数である。

エージェントの背後にあるモデルに頼れるか？

幅（pass@20）と一貫性（Observed 20/20）はモデルによって大きく異なる。

  • Kimi‑K3は少なくとも1回で**93.89 %**のタスクを解決（最大の幅）だが、**Observed 20/20は13.41 %**にとどまる。
  • Claude Opus 5は少なくとも1回で解決するタスクは**79.09 %**と少ないが、**Observed 20/20は47.53 %**で、最も高い一貫性を達成している。
  • Claude Opus 5.5はpass@1が（67.16 % vs 66.50 %）で改善されたが、一貫して正しいタスク数は増加していない（依然として241のObserved 20/20）。

"実際のレコードに影響を与える業務にモデルを選ぶなら、pass@20は見ないべき欄だ。"

一貫性のコスト

成功タスクあたりのコストは、OpenRouterのリストレートに基づくトークン使用量から計算される。

  • GPT‑5.4：507試行で$43.49 → $0.131/成功タスク
  • GPT‑5.6 Sol：成功あたりのコストが最も低く、$0.127
  • Claude Opus 5.5：成功あたり$0.276、より高い正確性

パレートコストフロンティア

3つのモデルがフロンティア上にある（他のモデルより安価かつ正確なものは存在しない）：

  1. GPT‑5.6 Sol – 成功あたり最も安価
  2. GPT‑5.4 – 成功あたり$0.004追加で中程度の正確性向上
  3. Claude Opus 5.5 – 成功あたり$0.276でさらに1.8 %の正確性向上

信頼できるタスクあたりのコスト（20回実行の一貫性）

モデル 20/20で成功したタスク数 20回実行の推定コスト 信頼できるタスクあたりのコスト
GPT‑5.4 128 (25.25 %) $869.80 $6.80
GPT‑6 Astra 231 (45.56 %) $1,720.60 $7.45
Claude Opus 5.5 241 (47.53 %) $1,880.77 $7.80
… … … …

1回の正しい答えを得るための最も安価なモデルは、一貫して正しい答えを得るための最も安価なモデルではない。

失敗のシグネチャ

4つの診断カテゴリが失敗の大部分を説明する。

シグネチャ 失敗の割合
ツール使用 79.9 %
間違った状態更新 10.3 %
ユーザー解決の不完全 7.0 %
状態変更アクションなし 2.9 %

主な問題はモデルの推論ではなく、ツールの扱いの誤りである。エージェントはツール呼び出しが失敗するワークフロー段階に到達した後、回復できず、より良いリトライおよびエラー回復ロジックの必要性を示している。

仕組み

ThinkingBoxはサンドボックス環境とベンチマークデータセット（ThinkingBox‑Bench）を提供する。

  1. タスク定義 – 初期バックエンド状態、ユーザーの目的、利用可能なMCPツール、ポリシー、実行可能チェック
  2. 隔離されたMCPセッション – 20回の繰り返しの各試行は、新規のデータベーススナップショットから開始される
  3. エージェント実行 – モデルがツールと対話し、状態を更新し、最終応答を生成する
  4. 副作用抽出 – 実際のデータベース変更を記録する
  5. 決定論的ジャッジ – 抽出された状態を必要な終了状態と比較。正しい状態に到達したすべての軌道が合格とされる

すべての評価ロジックは評価者側で実行される。モデルはゴールデン状態や採点コードを見ることはない。

自分で実行してみよう

ThinkingBoxはHugging Faceに公開され、完全なOpenEnv統合を備えている。

必要条件

  • Linux/WSL、Python 3.11+、uv、Docker
  • OpenEnv、thinkingbox-dataのピンされたリリースをクローンし、thinkingbox CLIをインストールする

クイックスタート（抜粋）

# OpenEnv + ThinkingBox環境をクローンしてインストール
git clone https://github.com/huggingface/OpenEnv && cd OpenEnv
uv sync --project envs/thinkingbox_env --frozen

# v1.0のデータリポジトリをクローン
git clone https://github.com/microsoft/thinkingbox-data && \
  git -C thinkingbox-data checkout thinkingbox-bench-v1.0

# CLIをインストール
uv tool install "thinkingbox @ git+https://github.com/microsoft/thinkingbox"

その後、ブログに記載された通りにTypesense、MCPセッションプロキシ、OpenEnvサーバーを起動（3つの別々のターミナル）。準備が整ったら、1つのタスクを評価する：

echo "- sandbox_external_retail_group1.py:test_case_ST002_001" > one_task.yaml
uv run --project envs/thinkingbox_env thinkingbox-eval \
  one_task.yaml \
  --config "$PWD/thinkingbox.yaml" \
  --output results.jsonl \
  --repeat 1 --message-timeout 1800

CLIはバイナリの成功/失敗報酬を返し、再現性のためにシステムエラーをログに記録する。

今後の展開

このベンチマークの主な貢献は、再現性と状態ベースの採点を簡単に採用できる環境を提供することである。

実践者への推奨事項：

  1. 失敗を検査する – 最終対話ではなく、実際のデータベース変更を確認する
  2. OpenEnvを用いて自分のモデルでタスクを再現する
  3. 繰り返しメトリクス（例：best-of-kやevery-of-k）を報告し、集計方法を明確にする

すべてのコードはオープンソース（サンドボックスはMIT、データはCDLA‑Permissive‑2.0）。ベンチマークは合成だが、実世界の企業エージェントのパターンを模倣している。

リソース

  • ThinkingBox環境: https://huggingface.co/docs/openenv/environments/thinkingbox
  • ThinkingBox‑Benchデータセット: https://huggingface.co/datasets/microsoft/ThinkingBox-Bench
  • 論文: arXiv:2608.19741
  • GitHubリポジトリ: microsoft/thinkingbox, microsoft/thinkingbox-data, microsoft/thinkingbox-training（RLトレーニングは近日公開予定）

Sources