解説
AIエージェントの『完了』報告は本当か ThinkingBoxが問うデータベース検証
社内のAIエージェントが「対応完了」と返してきたとき、その言葉をそのまま信じていないでしょうか。MicrosoftとHugging Faceが公開した評価手法「ThinkingBox」は、エージェントの発言ではなく、作業後にデータベースへ残った記録を基準に合否を判定します。報告と実態のずれを放置すると、顧客対応や経理処理の現場で見えない失敗が積み重なります。
何が起きたか
MicrosoftとHugging Faceは、AIエージェントの評価手法「ThinkingBox」を解説するブログを公開しました。Hugging Face経由で利用できるようになっています。
ThinkingBoxは、エージェントが最終的に返す文章や呼び出したツールの数ではなく、作業後にデータベースに残った状態を採点基準にする仕組みです。ブログは具体例として、745ドルの家電製品の配送が遅延した顧客対応のケースを紹介しています。エージェントは9回のツール呼び出しを行い、注文確認・配送追跡・顧客プロファイル参照・返金ポリシー検索などを実施したうえで、最終的に「解決済み」としてチケットを閉じました。しかし配送業者側の例外処理はまだ開いたままで、必要な状態は「保留」のはずでした。顧客が実際に求めていた回答も得られていませんでした。
ベンチマークは507件の業務シナリオを対象に、各タスクを20回ずつ繰り返し実行し、複数の言語モデルで採点しています。12モデル・121,680件の有効試行を対象にした分析では、実行チェックに失敗した79,853件のうち67.24%が、エラーも出さず見かけ上は正常に完了していました。失敗した試行のうち77.61%は値の記入ミス、43.30%は意図しない副作用、25.36%は必要な処理の欠落が見つかっています。
単発の成功率(pass@1)ではClaude Opus 5.5が67.16%で最上位、オープンウェイトモデルではKimi-K3が57.37%で最も高くなっています。しかし20回全てに成功した割合で見ると、Claude Opus 5とClaude Opus 5.5がともに507件中241件（47.53%）にとどまり、Kimi-K3はわずか68件（13.41%）でした。
背景・解説
ThinkingBoxは、MicrosoftとHugging Faceが共同で公開したAIエージェント向けベンチマークの名称です。エージェントが受発注や保険、旅行手配、銀行口座管理、コンサルティング業務などの「状態を持つ業務」をこなした後、バックエンドのデータベースやツールのログに残った最終状態を自動チェックで検証する仕組みを指します。
背景にあるのは、これまでのエージェント評価の多くが「ツール呼び出しが正しい形式で行われたか」「最終的な返答が自然かどうか」を基準にしていたという課題です。ブログは、これらの指標だけではエージェントが実際に正しい処理を完了したかどうかを見抜けないと指摘しています。文章やログが整っていても、データベースの値が間違っていたり、余計な副作用が残っていたりするケースがあるためです。
ThinkingBoxは一つの指標だけでなく三つの数値を報告します。単発の成功率を示す「pass@1」、20回のうち一度でも成功すれば加点される「pass@20」、そして20回全てで成功した割合である「observed 20/20」です。ブログは三つ目の指標を重視しており、一度の成功と毎回の成功は別物だと整理しています。例えばGPT-6 Astraは単発成功率の78%を20回繰り返しても維持できた一方、GLM-5.1やKimi-K2.6、DeepSeek-V4-Proは単発成功率のおよそ8%しか維持できませんでした。
コスト面の指標も用意されています。「成功1件あたりのコスト」はトークン使用量と公開料金から算出した参考値で、GPT-5.6 Solが1件あたり0.127ドルと最安でした。一方、「20回全てに成功したタスク1件あたりのコスト」で見ると、GPT-5.4が6.80ドルで最も低く、Claude Opus 5.5は7.80ドルで241件の安定成功を確保しています。安いモデルほど信頼できるとは限らないことを、この二つの指標の違いが示しています。
仕事や業務への影響 — AI Topicaの見方
エージェントの返答が「完了しました」であっても、実際の記録を見るまでは信用すべきではありません。これが今回の評価手法から得られる実務上の結論です。
例えば、従業員30人の物流会社が配送問い合わせ対応にAIエージェントを導入した場合、担当者は毎月のチケット終了率だけでなく、同じ業務を20回繰り返させて何回システム上のステータスが正しく更新されているかを月次で確認すべきです。ブログの事例でも、9回のツール呼び出しをこなしたエージェントが、配送業者の例外処理を閉じ忘れたまま「解決済み」と報告していました。見た目の会話の滑らかさだけで合否を判断すると、同種の見落としは繰り返されます。
単発の成功率が高いモデルを選ぶだけでは不十分です。507件中241件という「毎回成功する業務」の件数は、トップモデルでも全体の半分に届きません。経理や保険金請求など、記録の正確さが損害に直結する業務では、単発の精度よりも20回連続成功の件数を選定基準にすべきです。
コストの考え方も見直しが必要です。1回あたりの安さを重視すると、毎回成功させるコストでは順位が入れ替わるモデルが存在します。導入担当者は、月間の処理件数に対してどれだけの「安定成功タスク」を確保できるかで予算を組むほうが現実的です。
不確かな点・注意
今回のベンチマークは英語圏の小売・保険・旅行・銀行・コンサルティングという五つの業務領域を想定した507件のシナリオが対象で、日本語でのやり取りや日本独自の業務慣行を扱った検証ではありません。
コスト試算も、公開されている料金表から算出した参考値であり、実際のクラウド請求額とは異なります。値引きや契約条件によって実際の費用は変動します。
ブログで紹介された失敗の原因分類は、本文で一部が途中までしか示されておらず、全体像は論文側の詳細を確認する必要があります。
ベンチマークの対象モデルや評価方法は今後改訂される可能性があり、ここで紹介した順位や数値は本記事の出典が公開された時点のものです。