ツール呼び出しは成果ではない
ある顧客から問い合わせが届きました。745ドルのキッチン家電がナッシュビルの配送センターで「例外」状態のまま、推定配達日を15日過ぎている、という内容です。AIエージェントはかなり丁寧に動きます。注文照会、追跡確認、顧客プロファイル参照、返金ポリシーの二重検索、既存チケットなしの確認、チケット起票、タイムライン記録——合計9回のツール呼び出しを実行しました。ポリシー判断も正しく、当該顧客セグメントは遅延補償の対象外でした。
ところがエージェントはチケットを resolved で閉じ、こう返します。
「ご質問は解決いたしました。他にお手伝いできることはありますか？」
二点が誤りです。第一に、配送業者の例外はまだオープンであり、要求される最終状態は hold でした。第二に、顧客は実際に尋ねた内容への回答を得ていません。
ツール呼び出しだけを数える評価者には、整った9回の呼び出しが見えます。応答文だけを見る評価者も合格を出します。データベースだけが否と言っているのです。
この乖離を測定するのがThinkingBoxです。507のステートフルな業務ワークフローを複数のLLMで各20回実行し、最終的なバックエンド状態と副作用のみを採点します。本記事では、何が分かったのか、一貫性のコストはいくらか、そしてOpenEnvで自分で実行する方法を整理します。
根拠資料: ThinkingBox: Grading AI Agents on Database State, Not Sentences
一度の成功は信頼ではない
返金を一度だけ正しく処理し、次の四回で失敗するエージェントは、返金エージェントとして機能していません。そこでThinkingBoxは全タスクを 同一の初期状態から20回独立実行 し、三つの数値を報告します。
| 指標 | 測定対象 | 答える問い |
|---|---|---|
| pass@1 | 全試行のうち成功した割合 | 普段どれくらいできるか |
| pass@20 | 20回中最低1回成功したタスクの割合 | できることはあるか（広さ） |
| Observed 20/20 | 20回すべて通過したタスク数 | 常に正解できるか（一貫性） |
12モデル・121,680件の有効試行のうち、79,853件が実行可能チェック（executable check）を通過しませんでした。その失敗のうち 67.24%はクリーンに終了 し、状態変更ツールを呼び出し、最終ツールエラーも報告していません。ログだけ見れば成功に見えたわけです。しかし実行チェックでは、77.61%でフィールド値が誤り、43.30%で意図しない副作用が発生し、25.36%で必要な効果が欠落していました。
ベンチマークを自分で実行する（主要コード）
ThinkingBoxはHugging Faceで公開されており、OpenEnvインターフェース経由でエピソードごとにbinaryなpass/fail報酬を返します。前提はLinux/WSL、Python 3.11+、uv、Dockerです。
# 1. OpenEnv + ThinkingBox環境
git clone https://github.com/huggingface/OpenEnv
cd OpenEnv
uv sync --project envs/thinkingbox_env --frozen
# 2. 実行可能ベンチマーク（固定リリース）
git clone https://github.com/microsoft/thinkingbox-data
git -C thinkingbox-data checkout thinkingbox-bench-v1.0
# 3. ThinkingBox CLI（tbコマンドを提供）
uv tool install "thinkingbox @ git+https://github.com/microsoft/thinkingbox"
Typesense 30.1を起動し、続いてMCPサーバーとOpenEnvサーバーを立ち上げます。ターミナルは分けたほうが扱いやすいです。
# Typesense（検索・状態バックエンド）
mkdir -p .typesense-data
docker run --rm -d --name thinkingbox-typesense \
-p 8108:8108 \
-v "$PWD/.typesense-data:/data" \
typesense/typesense:30.1 \
--data-dir /data --api-key=Fake --enable-cors
until curl -fsS http://127.0.0.1:8108/health; do sleep 1; done
# MCPセッションプロキシ + サーバー起動
cd OpenEnv
tb mcp-start --host 127.0.0.1 --port 7111 \
--servers "$PWD/thinkingbox-data/servers/servers.yaml"
# OpenEnvサーバー（エージェント／シミュレートユーザー／判定モデルを指定）
OPENENV_TB_CONFIG="$PWD/thinkingbox.yaml" \
uv run --project envs/thinkingbox_env --frozen server
準備状態は必ずゲートで確認してください。データ・設定・セッションプロキシのチェックが通るまで /ready は503を返します。
curl -sS http://127.0.0.1:8000/ready
実際のエピソードを一つ採点します。example_usage.py はリセットとツール一覧のみなので、アクション・効果・アサーションまで見るにはパッケージ済みのevaluatorを使います。
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 \
--errors-output errors.jsonl \
--repeat 1 --message-timeout 1800
ポイントは --errors-output です。運用上の失敗をモデル結果と混ぜずサイドカーに分離し、再実行可能にします。正規の結果を出す際は、これらの失敗を解消するか明示的に集計へ反映する必要があります。原論文ではシステムエラーも失敗試行としてカウントしています。
一貫性の値段と失敗シグネチャ
多くのリーダーボードはpass@1で止まります。しかし本番導入を検討する人にとって重要なのは 成功した作業単位あたりのコスト です。ThinkingBoxは507×20キャンペーンの実トークン使用量をOpenRouterの定価で換算し、二つの指標を計算します。
- 成功試行あたりコスト = 507試行のコスト ÷ (507 × pass@1)
- 信頼できるタスクあたりコスト = 20回キャンペーン全体のコスト ÷ 20/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 |
| GPT-5.6 Sol | 82 (16.17%) | $800.00 | $9.76 |
| Claude Opus 5 | 241 (47.53%) | $3,206.00 | $13.30 |
| Kimi-K3 | 68 (13.41%) | $1,406.40 | $20.68 |
興味深いのはここです。単発成功あたり最安のGPT-5.6 Sol（$0.127）は、信頼タスクあたりでは$9.76まで跳ね上がります。安く当たる答えと、安く信頼できる答えは別物 なのです。
広さと一貫性は別軸で動く
Kimi-K3はベンチマークで最も広いカバレッジを持ちます。507件中476件（93.89%）を最低一度は解きます。完全に失敗したタスクは31件で全モデル中最小。リテールではpass@1 82.24%と商用モデルを上回ります。しかし20回すべて通過したタスクは68件（13.41%）に過ぎません。
Claude Opus 5は正反対です。最低1回成功は79.09%と低いものの、20回全通過は47.53%と大幅に高い。しかも新しいモデルがこれを解決するわけではありません。Claude Opus 5.5はpass@1で67.16%とOpus 5（66.50%）を上回りますが、20/20通過タスク数は ちょうど241件で同一 です。ヘッドライン精度0.66ポイントは信頼性を1ミリも買っていません。
失敗の80%は推論ではなくツール処理
失敗トレースごとに決定論的な診断シグネチャを一つ付与したところ、結果は非常に実務的でした。
| 失敗シグネチャ | 割合 |
|---|---|
| ツール使用（Tool usage） | 79.9% |
| 誤った状態更新 | 10.3% |
| 不完全なユーザー解決 | 7.0% |
| 状態変更アクションなし | 2.9% |
パターンは単純です。エージェントはたいていワークフローを 試みるだけのところまでは 進みます。その後のツールエラー、失敗した前提条件、空の検索結果から復帰できません。これはモデルというより リトライとエラー回復の設計問題 です。
日本のエンタープライズ環境では特にここが重要です。社内システムはレガシーAPIが多く、「空の検索結果」と「権限なし」が同じコードに落ちるケースが珍しくありません。その状態でエージェントがリトライを無限ループさせると、バッチコストが一気に跳ねます。まずツールエラーをrecoverable / non-recoverableに分類することをお勧めします。
このアプローチの限界
ThinkingBoxも万能ではありません。公開ベンチマークの全タスクは 合成による再構成 です。ワークフローとポリシーは実際のエンタープライズ・エージェントパターンをモデル化していますが、顧客は実在しません。507件のうち477件は状態のみで採点し、30件だけが応答ルーブリックを追加します。つまり「この説明はユーザーにとって十分に親切だったか」といった定性的な品質はほとんど測っていません。コスト数値も2026年9月20日時点のOpenRouterスナップショットに基づく定価換算であり、実際のクラウド請求額ではありません。
まとめ：20/20を設計入力として使う
この研究で本当に有用なのはpass@1リーダーボードではなく 環境 です。本番にそのまま適用できる四つの原則に整理します。
- コミット前にターミナル状態を確認する。 モデルが「完了しました」と要約した文ではなく、実際に変わったレコードを見てください。このシグナルはベンチマーク専用ではなく、本番にもそのまま存在します。
- ツール／システムエラーを分類する。 リトライに意味があるエラーとそうでないエラーを分けないと、リトライが暴走します。
- ツールの表面積を削る。 ワークフローに必要な最小限のツールだけを公開するだけで、ツール使用失敗率は大きく変わります。
- 巻き戻しコストの高い変更には人間の承認を挟む。 返金、アカウント状態変更、削除などが該当します。
ベンチマークを回す際は反復指標を必ず併記してください。kをいくつに設定するにせよ、best-of-kなのかevery-of-kなのかを明示することが肝心です。「うちのエージェントは90%成功」という一文は、20回中1回なのか20回全部なのかで全く意味が変わりますから。
次のステップ学習方向
- OpenEnv環境を直接実行: 上記のインストール手順に従い、リテールタスクを一つご自身のモデルで再現してください。
sandbox_external_retail_group1.py:test_case_ST003_006が冒頭のケースです。 - 失敗トレースを開く: クリーンに終了したのに失敗したランを探し、DBで実際に何が変わったか確認してください。ご自身の評価体系が何を見落としているかが見えてきます。
- MCPツール設計へ拡張: ツールスキーマと前提条件検証の設計は別テーマです。社内MCPサーバーを自作するなら、スキーマ検証レイヤーを先に固めることをお勧めします。