1回なら65%、20回すべてなら25%。Microsoftは507件のエージェントタスクを各20回ずつ走らせました
By Surya Pratap
2026年8月27日
12分で読めます
AI・テクノロジー
2026年8月27日
12分で読めます
デモの数字と、プロダクトの数字Hover to exploreMicrosoftが先週、近年でもっとも曖昧さのないタイトルのベンチマークを公開しました。「One Success Isn't Reliability」——1回の成功は信頼性ではない、というものです。
論文（arXiv 2608.19741、2026年8月20日）が示すのは、ステートフルな業務ワークフローで働くエージェントのためのオープンソースのサンドボックスThinkingboxと、それに付随する507タスクのベンチマークです。どちらもGitHubにあります。
見出しになる結果は、同じモデルが同じタスクで出した2つの数値です。
pass@1が65.36%。pass^20は25.25%。
初回で正解するのは3回に2回ほど。20回すべてで正解するのは4回に1回ほど。エージェントのデモを成功させたあと、顧客の前で同じものが崩れるのを見た経験があるなら、この隔たりがその全部の説明であり、ようやく誰かがそれを測りました。
エージェントのベンチマークの多くは、トランスクリプトを採点します。正しいツールを呼んだか。終わったと言ったか。最後のメッセージは正しそうに見えるか。
Thinkingboxが採点するのはデータベースです。
Thinkingboxのタスクが実際にどう走るか
ふだんは別々に検証される5つの要素を、まとめて扱う
そのうえで、バックエンドを実行間で初期化しながら、全体を20回繰り返します。
この設計こそが貢献です。結果の面白い部分はすべて、この2つの選択——状態を見ること、そして繰り返すこと——から導かれます。
507のタスクは5つのドメインにまたがります。小売とEC（98タスク）、旅行と宿泊（104）、自動車保険（100）、ネオバンクの社内IT（104）、コンサルティングのIT・人事サポート（101）です。
プロプライエタリとオープンウェイトを合わせて十数のモデルが実行されました。公表された分布は次のとおりです。
見るべきは順位ではなく比率です。表全体を通して、pass^20はpass@1の3分の1から10分の1のあいだに落ち着きます。エージェントの精度としてどんな数字を目にしていたとしても、繰り返し使う利用者が体験する数字はそれよりはっきり低く、その割引率を数値化したベンチマークを私が見たのはこれが初めてです。
スライドに載せるならこの結果です。
最良のモデルは、10件に9件ほどのタスクで少なくとも1回は成功しました。20回すべてで成功したのは、4件に1件ほどです。
つまり注目すべき集団は、信頼できるタスクでも不可能なタスクでもありません。実行ごとに結果が揺れた334件——ベンチマークの3分の2——のタスクです。
なぜその帯域で信用が死ぬのか
つねに動くタスクは機能です。まったく動かないタスクは既知の制約であり、設計で回避できます。たいてい動くタスクこそが、うまくデモでき、自信を持って出荷し、そのあと顧客に説明する羽目になるタスクです。現実的な業務ワークフローの3分の2が、入手可能な最良のモデルでこの帯域に入るということは、デモを作った場合の既定の結果は「動くデモ」であり、そしてそれはほとんど何も教えてくれない、ということです。
エージェントのPoCが本番にこれほど繋がらない理由を考えたことがあるなら、これがその機械的な答えです。PoCは短く、人が見ていて、試行数が少ない。良い実行だけを標本抽出しているのです。
ここからが、エンジニアリング上の帰結がもっとも直接的な部分です。
失敗試行の80.88%が、きれいに終わっていました。 会話は正常に終了。状態を変更するツール呼び出しは実行され、成功を返しました。何も例外を投げていません。ただ最終状態が誤っていただけです。
論文自身の結論は率直です。応答レベルおよびツール呼び出しレベルのシグナルは、エンドツーエンドのタスク完了を示す明確な代理指標にはならない。
内訳として、支配的だった失敗モードは次のとおりです。
この2つを合わせて読むと、広く共有されている前提が崩れます。多くのチームのエージェント監視は、ツール呼び出しのトレースとトランスクリプトの確認で構成されています。この失敗分布に対して、それが捕まえられるのは5件に1件ほどです。残りの4件は成功とまったく同じに見えます。同じきれいな終了、同じ有効な呼び出しであり、両者を分けるのは終了時点のデータベースの状態だけです。
これは昨日扱った調査、エンジニアの85.5%がエージェントの出力を信頼していたという結果への、率直な答えでもあります。当然そうなります。失敗の5件に4件は、彼らの立っている場所からは見えないのです。
成功率はドメインによって大きく変わりました。小売でおよそ52%、**自動車保険でおよそ23%**です。
同じモデル、同じハーネスで2倍以上の差であり、平均に均してしまうのではなく理解する価値があります。小売のワークフローは短く、許容度が高く、ポリシーに縛られにくい傾向があります。保険のワークフローは長く、規則に条件づけられ、序盤の誤った値が後続すべてを静かに汚染する工程に満ちています。
創業者にとっての実務的な翻訳はこうです。あなたのドメインの数字は、見出しの数字ではありません。 自動化しようとしている対象が保険金請求のような形——多段階、ポリシーによる関門、状態が重い——であれば、ベンチマークの示唆は「レンジの下限を想定すべき」であり、それを顧客より先に自分で知っておくべきだ、ということです。
留保を3つ。目を引くベンチマークは、読みすぎを誘うからです。
テストされたモデルは現在のフロンティアではありません。 この表はGPT-5.4とClaude 4.6世代の上に作られています。フロンティアはその後動きました。GPT-5.6もClaude Opus 5も、この作業のあとに登場しています。絶対値はすでに過去のものです。新しいモデルでpass@1とpass^20の比率が改善するのかどうかが本当に開かれた問いであり、ここにその答えはありません。
ベンチマークでの順位は能力の順位ではありません。 ここではClaude Opus 4.6がClaude Sonnet 4.6を下回っています（pass@1で37.91%対58.45%）。これを素朴なリーダーボードとして読むことには慎重であるべきだ、という合図です。ハーネスとの相性、プロンプト形式、ツール呼び出しの流儀で、これらの数値は動きます。結果の形は堅牢なものとして、順序はこの構成に固有のものとして扱ってください。
これはシミュレーションです。 隔離されたバックエンドとシミュレートされた利用者は、静的なテストケースよりはるかに優れています。それでも、あなたのデータとあなたの利用者を伴う本番システムではありません。誤差の向きも分かりません。実際のワークフローは、利用者が補足してくれるぶん易しいかもしれませんし、現実がシミュレータより雑然としているぶん難しいかもしれません。
3枚目のカードが最も割に合います。これはモデルの問題ではなく、より良いプロンプトも要りません。ツール呼び出しが失敗しているのにオーケストレーションがエージェントを進ませているなら、それは自信のある誤答を量産する機械であり、ベンチマークによれば、それが不具合の4分の3を占めています。
Microsoftは、本当に重要なもの——システムで何が変わったか——を採点するエージェントのベンチマークを作り、そのうえで全体を20回走らせて持ちこたえるかを見ました。どちらの選択も後から見れば当然で、どちらも標準ではありませんでした。
結果はこうです。当時入手できた最良のモデルは、初回で65.36%、毎回では25.25%正解しました。タスクの3分の2は実行ごとに揺れました。失敗の5件に4件はきれいに終わり、有効なツール呼び出しを伴い、そしてあなたが導入しているトランスクリプトベースの監視では成功に見えるはずです。
これらはどれも、エージェントが使えないという意味ではありません。意味しているのは、デモは根拠ではないこと、単発実行の精度は引用すべき指標ではなかったこと、そして多くのチームが作ってきた監視は、実際に起きている失敗を見られないということです。
対処法は奇抜なものではありません。20回走らせる。データベースを確認する。ツールが「できない」と答えたらエージェントを止める。
出典: arXiv 2608.19741「One Success Isn't Reliability: Thinkingbox, a Sandbox and Benchmark for Agents in Stateful Business Workflows」 · GitHubのmicrosoft/thinkingbox · モデル別スコア、507タスクの内訳、正常終了80.88%という数値、ドメイン別平均は、論文および付随する分析で公表されたものです。第6節の留保は筆者によるものです。
IdeaToMVP Academy
4-week live cohort for founders. Learn to ship AI agents, scope MVPs, and automate your business — taught by the same team that writes these guides.
