口座に60ドルある。作業中はつねに最低20ドルは残しておくこと、という条件がついている。エージェントが60ドルの手数料を一度に決済する。その瞬間、残高はゼロになる。条件を破った。
決済はシステムが受理した。しばらくして返金と調整が入り、締め時点の残高はふたたび20ドルを超える。数字だけ見れば、何事もなかったように見える。
それでもこの業務は失敗だ。承認を得ていない送金は、お金があとで戻ってきてもコンプライアンス違反として残る。途中で一度ラインを越えたという事実は、結果が復元されても消えない。
この場面こそ、BizBenchというベンチマークが測ろうとしているまさにその一点だ。Ant Internationalと北京大学(Peking University)の研究陣が作った。決済会社の実際の業務手順をそのまま移した環境で、複数ステップの業務を連続して処理するAI(以下、エージェント)を試す。ふつうの評価は「仕事を終えたか」だけを見る。BizBenchは「終えるまでの過程でルールを守ったか」まで見る。それも人間の審判の勘ではなく、あらかじめ決めたルールで同じ記録につねに同じ判定を下す方式で — これを決定論的採点と呼ぶ。
50個の課題に最新モデルを走らせた。トップモデルですら厳格な成功率は60%台にとどまった。そして結果だけを見る評価がこれまで覆い隠してきたもの — 結果は正しいのに過程でルールを破った実行 — が、くっきりと浮かび上がった。
既存のベンチマークのほとんどは最後の状態だけを見る。リポジトリのイシューを直したか(SWE-bench)、最終的なアプリケーションの状態が正しいか(AutomationBench)、といった具合だ。最終状態だけを採点すると、そこへ至る道のりで起きた違反は集計から消える。冒頭の60ドルのように。BizBenchは途中の行動ひとつひとつを、その時点で有効なルールに照らして見る。分かれ道はここにある。
ルールを守ることがなぜそれほど難しいのか。ルールそのものが入り組んでいるからだ。現実の業務ルールはポリシーマニュアルやFAQ、運用通知に散らばっている。異なるチームが異なる時点で手を入れる。古い指針が現行ポリシーの隣にそのまま生き残っている。見た目には衝突する二つの指針が、じつは適用対象だけが違う場合もある — 国が違うか、商品が違うか、有効期間が違うか。満期を迎えた保険約款でも、約款が生きていた時代の事故は依然として補償されるのと同じだ。だから「関連文書を検索して見つける」だけでは足りない。いまこの取引に対して権威があり、現行で、適用可能なルールがどれなのかを選び出さなければならない。BizBenchは古く衝突する指針を環境の中にわざと混ぜ込む。この「選択」を課題の一部にしたのだ。
BizBenchは一つの課題を三つの角度から採点する。
三つの検査をすべて通過してはじめて課題成功として数える。だから名前が「厳格成功(strict success)」だ。設計の意図は明快だ。良い結果ひとつで途中の違反を覆わせない。かといって、決められた正解経路ひとつを強いることもしない。条件さえ満たせば、互いに異なる正当な戦略をすべて認める。
採点は人間ではなく機械が、決められたルールで行う。業務状態と取引履歴の台帳(元帳)、領収書、イベント履歴を証拠とし、実際に実行された行動と、提案・承認・拒否にとどまった試みとを区別する。承認が実際に実行された条件を正確にカバーしているか、順序のうえで承認が作業より先だったかを、途中途中で確認する。最低準備金のように作業中ずっと守るべき条件は、状態が変わるたびに検査し直す。
一つのことがこの採点をとりわけ厄介にしている。顧客が最初から「よしなに全部やって」と白紙承認を与えるわけではない、という点だ。顧客役はシミュレータが担い、複数ターンの対話で情報を小出しにし、承認要求に答える。承認は具体的な要求とその時点の条件に紐づいて記録される。条件が変われば既存の承認は効力を失い、取り直さねばならない。このルールひとつが、後で結果を分ける。
技術ノート — BizBench環境 - 凍結されたリリース基準で50個の課題、知識文書789個。 - エージェントが常用するツールは9個で、これを通じて601個の業務機能を発見・呼び出す。顧客シミュレータ専用ツールは10個。 - すべての実行はデータベースの独立したコピーの上で動く。ある課題が別の課題を汚染しない。 - ランナーは累積トークン・ツール呼び出し・スケジューラステップに上限を置かず(壁時計タイムアウトとツールエラー閾値だけを維持)、コンテキストが溢れると知識検索・文書読み取りの応答のうち最も古い4分の1を差し替えるが、実行記録全体は保存する。 - 三つの検査をすべて通過したという条件を、論文はG ∧ P ∧ Fと表記する。
数字を見る前に、列の意味から。目標・過程・保護は、それぞれの検査を通過した割合だ。途中失敗(IF)は、結果がどうであれ途中でルールを破った実行の割合。厳格成功は三つの検査をすべて通過した割合。すべて百分率。そして条件がひとつ付く。Claude Opus 5とMuse Spark 1.3は課題あたり1回実行で、残りは3回実行したうえで、一度の実行が成功する値を平均したものだ。
| モデル | 目標 | 過程 | 保護 | 途中失敗(IF) | 厳格成功 |
|---|---|---|---|---|---|
| Claude Opus 5 (1回) | 64.0 | 96.0 | 98.0 | 4.0 | 64.0 |
| GPT-6 Sol | 64.7 | 94.7 | 100.0 | 5.3 | 61.3 |
| GLM-5.3-Flash | 48.0 | 79.3 | 87.3 | 29.3 | 43.3 |
| DeepSeek-V4.1-Flash | 46.7 | 92.0 | 96.7 | 9.3 | 43.3 |
| DeepSeek-V4-Pro | 41.3 | 85.3 | 88.7 | 24.7 | 39.3 |
| Muse Spark 1.3 (1回) | 38.0 | 94.0 | 98.0 | 6.0 | 38.0 |
| Qwen3.8-27B | 42.0 | 74.0 | 93.3 | 28.0 | 32.7 |
| DeepSeek-V4-Flash | 7.3 | 53.3 | 95.3 | 47.3 | 5.3 |
| Qwen3.5-397B-A17B | 1.3 | 46.7 | 93.3 | 56.7 | 0.7 |
| Qwen3.5-9B | 0.0 | 18.7 | 89.3 | 83.3 | 0.0 |
いちばん上の行から。トップモデルであるClaude Opus 5とGPT-6 Solの厳格成功率は、それぞれ64.0%、61.3%だ。目を引くのは、この二つのモデルで目標スコアと厳格成功がほぼ重なっている点だ(Opus 5は両方とも64.0、GPT-6 Solは目標64.7に厳格61.3)。過程検査で削られてスコアが下がったわけではない、という意味だ。彼らにとって難しいのは途中でルールを守ることではなく、業務全体を最後までやり遂げること、それ自体なのだ。
では、結果だけを見ると見落とす違反はどこで浮かび上がるのか。目標と厳格成功のあいだが開いたモデルを見ればいい。Qwen3.8-27Bは目標を42.0%達成するが、厳格成功は32.7%まで落ちる。結果だけ見れば42%の性能と読まれたであろう実行が、過程の有効性まで問うと10ポイント近く削られた。結果ベースの評価が無効な実行を成功として集計しうる、という懸念が、ここで数字として裏づけられる。
言葉ではなく実際の実行でもそのとおりに出た。DeepSeek-V4.1-Flashの四回の実行は目標を達成し、締め時点の現金準備金も要求閾値の上で終えた。ところが途中のどこかの段階で、その閾値をすでに一度破った後だった。見た目は成功、過程では失敗。冒頭の60ドルの場面が、実際のモデルで再現されたわけだ。
ここまでが数値がはっきり語ってくれることだ。やり遂げること自体が難しいということ、そして結果だけ見れば違反が覆い隠されるということ。数値が語ってくれないこともある。厳格成功率64%が「モデルはまだまだだ」という信号なのか、「ベンチマークが現実の決済業務の難しさを正直に写し取った」という信号なのかは、この一つの数字では切り分けられない。両方が混ざっているのだろう。
同じモデルでも走らせるたびに結果が揺れる。GPT-6 Solは三回実行して三回とも成功した課題が40.0%にとどまった。「選択した実行すべてで成功した課題の割合」を一般化した指標をpass^kと呼ぶが、複雑な計算を取り払って言えば、「何度やらせても毎回通るか」を見るものさしだ。一度はできて一度はできない不安定さが、ここに表れる。だから課題あたり1回だけ走らせたOpus 5・Muse Spark 1.3と、3回平均を取った残りを一つの表で比べるときは、1回実行では運の良い・悪い実行を平均でならせない、という点を踏まえて読む必要がある。
実行記録には、信頼性のほかに効率の信号も残る。DeepSeek-V4.1-Flashは一回の実行に平均191.3回ツールを呼び出した。模範実行より約70%多い。目標をそれなりに当てるモデルですら、相当な無駄を抱えて進む。小さいモデルではもっと劇的だ。Qwen3.5-9Bは平均187.2回を呼び出し、その半分以上がエラーだった。エラーの主因は非公開リソースへのアクセス試行で、150回実行するあいだ、すべての課題の目標を達成した例は一度もなかった。だから呼び出し回数そのものより、失敗した呼び出しを原因別に切り分けることが先だ。権限外のリソースを叩き続けているなら、それは性能の問題ではなく権限モデルの問題だ。
保護スコアは表全体でひときわ高い。最下位のQwen3.5-9Bですら保護は89.3だ。ここから「保護は簡単な能力だ」と結論づけたくなる。しかし、保護対象に触れなかったことと、業務を安全にやり遂げたことは別だ。目標にほとんど届かなかった実行は、そもそも危険な行動をする機会自体が少なかっただけかもしれない。何もまともにできなければ、壊すものもない。保護スコアは単独で切り離して読まず、そのモデルが目標をどれだけ達成し、実際にどれだけ行動したのかと併せて見てはじめて意味が生きる。
では、やり遂げに失敗したモデルは「どこで」失敗したのか。この問いに論文がすべての答えをくれるわけではない。論文が観察として指摘したのは、Qwen3.5-9Bの事例のように権限外のリソースへのアクセスがエラーを膨らませた、という程度だ。ここから先は実務目線の整理だ。失敗地点はおおむね三つに分かれる。どのルールを適用するかを誤るルール選択、承認の範囲や順序を破る承認管理、作業順序を間違える実行順序。三つは処方が違う。ルール選択が問題ならルール格納庫のメタデータと検索を、承認管理が問題なら承認と実行を突き合わせるロジックを、実行順序が問題なら計画とゲート設計を手直しせねばならない。どれなのかを切り分けるには、実行の途中記録が残っていなければならない。結果だけ書かれたログでは、そもそも診断ができない。
採点器を信じられてはじめて、スコアも意味を持つ。研究陣は課題ごとに模範実行記録を一つ作っておく。ルールをすべて守りながらその課題を実際に解き切った記録だ(論文はこれをゴールデントレースと呼ぶ)。これがあるということは、目標・過程・保護を同時に満たす解が少なくとも一つは存在する、という保証だ。複数の作業が共有リソースとタイミングで絡み合うと、個別には可能なことが、一緒に置かれたときに両立不可能になることもある。だから作業を個別に検証したあとでも、課題全体を初期状態から再生し直して相互作用を確認する。公開された50個の課題はすべてこの模範実行を通過する。
採点器は逆向きにも試す。同じ目標を別の経路で解いた有効な実行は通過させ、特定の要件をわざと破った実行は落とさねばならない。先の準備金の例のように、途中でラインを越えてから後で復元した実行は、過程検査で必ず失敗しなければならない。取引の有効性を左右する事実を変えれば判定も追随して変わらねばならず、逆に結果が同じ変形 — 同じ作業をもう一度呼んでも結果が変わらない再試行のようなもの — は判定を変えてはならない。研究者5名と業務ドメインの専門家チームが、課題と合格検査を顧客要求・文書・記録に照らして検討し、食い違ったところは直して走らせ直した。
ベンチマークは一つの先進的な決済会社の手順に根ざしている。機密のため敏感な細部は抽象化して書き直してあるので、実際の運用環境のすべての肌理を写し取ったとは見なしにくい。課題数50個は、深さ — つまり長く複数のワークフローが絡む課題を取る代わりに、幅を譲った選択に見える。だからこのスコアを、あらゆる産業、あらゆるドメインのエージェントの信頼性へと広げれば誇張になる。著者らもこれを「複雑なビジネス環境において、課題完了を超えた信頼性」を測るテストベッドだ、と線を引いている。
構造的な限界も明かしておく。顧客シミュレータにDeepSeek-V4.1-Flashを使っているため、シミュレータ自体の安定性が評価に影響しうる。論文はこれを別節(5.6)と付録で個別に点検する。
最後に、役割を取り違えてはいけない。BizBenchは違反を実行が終わった後に見つけ出す評価器だ。実際のプロダクトに必要なのは、違反が起きる前に防ぐ仕組みだ。両者は別物だ。そして、機械がきっちり割り切って判定しにくい領域 — あいまいなポリシー解釈のようなもの — が残るなら、そこに人間のレビューをどこで挟むかはあらかじめ決めておかねばならない。
小企業の顧客社のAI PMに、ひとつ依頼が入る。「来月の広告予算を再配分して」。PMは承認を受け、再配分計画を立てる。ここまではきれいだ。
作業の途中で顧客がひとこと付け加える。「あ、余った予算で外注デザイナーの残金も精算しておいて」。人間の担当者なら自然にまとめて処理するだろう依頼だ。ところがまさにこの地点に、BizBenchがつまみ上げた落とし穴がそのまま入っている。
最初に受けた承認は「広告予算の再配分」までだった。残金の支払いは、そこになかった新しい支出だ。支払いの金額と範囲が変わったのだから、既存の承認はこの新しい支払いをカバーしない。取り直さねばならない。しかも残金の支払いはお金を引き出す行為なので、月間運用準備金の下限に触れうるし、外注契約の単価は昨年版と今年版がドライブのどこかに一緒に生き残っているかもしれない — どちらがいま有効な単価なのかを選ばねばならない。
正しい処理は一本の流れでつながる。支払い範囲が変わったことをまず気づき、既存の承認がこの支払いまでカバーするか確認し、カバーできなければ再承認を要求し、準備金の下限を割らないか確認したうえで実行する。最終結果だけを見る自動化は、この過程を飛ばして「予算再配分完了、残金支払い完了」と報告して終わる。そのあいだに準備金を一瞬割ったり、変わった範囲を再承認なしに支払ったり、満期の単価を適用していたりすれば — 画面上は無事でも、コンプライアンス上は事故だ。
ONTLEはこの流れの前半をすでにプロダクトに組み込んである。外部へ出ていく発信は承認ゲートをまず通し、元に戻しにくい作業は実行前に計画を確定させる。「最初の支払いの前に承認を受ける」という段階は機能している、という意味だ。まだ設計が足りないのはその次だ。作業の途中で支払い条件が変わったときに既存の承認を自動で無効化し、再承認を要求すること、そして準備金の下限のように作業中ずっと守るべき限度を各段階で検査すること。条件と状態に紐づいたこの途中検査を、自動化ロジックの正式な段階へと引き上げること — それが、私たちに残された設計課題だ。