ToolBottleneckBench解説：AIエージェントはどこでつまずくのか

David

くらちゃんやData Brainの開発では、AIが必要な情報を探し、道具を使って仕事を進める仕組みに向き合っています。その中で生まれた問いを扱うのが、私たちの共同研究論文 ToolBottleneckBench です。AIが仕事を完了できなかったとき、モデルの能力と、動かす仕組みのどちらに原因があるのか。実験を通じて切り分けました。

道具が増えると、何が難しくなる？

メールを探す、予定を確認する、顧客情報を書き換える。AIエージェントは、こうした操作を「ツール」として呼び出します。ユーザーの依頼を読み、使う道具を選び、返ってきた情報を見て、次の操作へ進みます。

たとえば「来週の打ち合わせに必要な資料を集めて」という依頼には、予定表とファイル検索の両方が必要かもしれません。使える道具が増えれば対応できる仕事も広がりますが、最初に選ぶ候補も増えます。

そこで成功率が下がったとして、AIは道具を選び間違えたのでしょうか。それとも、選んでいる途中で処理を止められたのでしょうか。成功・失敗の件数だけでは、この違いが見えません。

AIを動かす側には、一度に生成できる文章量、ツールを呼べる回数、タスク全体で使える予算などの設定があります。論文では、この周辺の仕組みを実行環境として扱い、モデルとセットで評価します。

同じ仕事で、四つの条件を変える

主実験では、12種類の業務目的から作った36組のタスクを、21のモデル・サービス構成で評価しました。同じ組の中では、達成する目標と重要な事実をそろえ、次の条件を変えます。

「登録された道具」と「AIに見せる候補」は別です。大量のツールが登録されていても、検索で16個に絞って渡す場合があります。必要な道具がこの段階で抜けたのか、渡した後で使えなかったのかを分けて見ます。

手順数の比較では、呼び出し回数だけでなく、情報の分かれ方も変わります。一つの操作でまとめて取れる情報を、複数の結果から順番に集める必要が出てきます。仕事の流れ全体として、どれだけ負荷が増えるかを見る設計です。

返却形式は、元のデータをそのまま渡す形、整理した形、型を明示した形、リンクでつなぐ形を比べました。「compact」という名前の形式でも、この実装では元データより大きくなっています。形式の名前より、実際にモデルへ渡した情報量を見ることが大切です。

成功の判定は、正しい答えを返すことに加え、根拠、手順、許可された変更、予算など九つの要件をすべて満たすこと。英語で作成した架空の業務タスクを使い、条件をそろえて比較しています。

予算も固定しました。一回の応答は1,024トークン、タスク全体は128,000トークン、ツール呼び出しは最短手順に二回を加えた回数までです。トークンはモデルが文章を処理・生成する単位で、サービスによっては内部の思考も一回の応答上限に含まれます。

候補を増やすと、成功率は下がった

AIに見せる道具を8個から128個にすると、主実験の成功率は平均で 12.3ポイント低下しました。36組のうち34組で低下が見られ、今回の四つの条件では、候補数の影響が最もはっきり現れました。

この比較では、最初の操作が終わると、正解の道具情報を使って候補を絞っています。最初の選択後を助ける実験条件です。候補を最後まで全部見せ続ける場合には、成功率の差は 17.5ポイント に広がりました。

一方、主実験の範囲では、手順を2回から6回へ増やした効果は全体として明確ではありませんでした。返却データの形式を変える効果も比較的小さく、今回の結果は「まず候補の多さを詳しく調べよう」という手がかりになりました。

選び間違える前に、止まっていた

128個の道具を見せた条件で、一回の応答上限に達した実行は411件。そのうち 391件は、一度も道具を呼ぶ前に終了していました。

この違いを確かめるため、一回の応答上限だけを1,024から 16,384トークン へ増やしました。タスク全体の予算と、道具を使える回数はそのままです。

打ち切りが多かった六つの構成では、8個と128個の候補の間にあった成功率の差が、43.7ポイントから2.7ポイントへ縮まりました。この六構成の128ツール条件では、打ち切り率もすべて1.4%以下になりました。

つまり、この比較で大きく効いていたのは、道具を選ぶための一回分の余裕です。候補が多いほど説明を読み比べる処理が増えます。タスク全体に予算が残っていても、一回の応答上限に先に達すると操作を始められません。

ここで見ている六構成は、主実験の21構成から打ち切りの多いものを選んだ比較です。全体の12.3ポイントと六構成の43.7ポイントは、対象をそろえて読む必要があります。また、打ち切りが少なくても候補増加の影響を受ける構成があり、ログから原因を確かめることが重要になります。

「選択に失敗」の中身を読む

評価器は九つの要件を順番に確認し、最初に満たせなかったものを失敗名として記録します。「選択失敗」という名前でも、実際に間違った道具を使ったとは限りません。

今回、選択失敗と記録された849件は、すべてツール呼び出しがゼロ回でした。そのうち838件は応答上限に達しています。「どれを使うか決めるところまで進めなかった実行」が、多く含まれていたのです。

同じ「失敗」でも、メール検索が一度も始まっていない場合と、検索はできたのに最後の要約を返せなかった場合では、対応が変わります。前者で要約の指示だけを改善しても、途中で止まる原因には届きません。ログを段階ごとに残すと、こうした遠回りを減らせます。

失敗を調べるときは、最終回答に加えて、最初の呼び出しまで進んだか、何回実行したか、何によって止まったかを残します。道具の検索、候補からの選択、操作の実行を分けることで、次に直す場所が見えてきます。

道具の渡し方と、仕事の分担を変える

論文では、実行の仕組みを変える実験も行っています。

一つは、接続先を先に選んでから、その中の道具を探す方法です。2,048個のツールがある条件では、必要なツールを候補に含められた割合が19.4%から77.8%に上がりました。これは検索段階の改善です。最終的に仕事が完了した割合とは分けて測っています。

もう一つは、結果に含まれる「次のレコード」へのリンクを、プログラムにたどらせる方法です。毎回AIに次の操作を選ばせず、手順が決まっている部分を任せます。

30回の呼び出しが必要な別実験では、24種類の業務目的・17構成で、成功率が0%から96.6%になりました。平均29.9回の呼び出しのうち28.7回はプログラムが担当しています。改善は、この実行分担を変えた結果です。

この二つは、直している場所が違います。前者は「必要な道具が届くまで」、後者は「道具を使い始めてから」の処理です。失敗した段階が分かれば、検索を変えるのか、応答予算を見直すのか、定型処理をプログラムに任せるのかを選びやすくなります。

AIの成績と一緒に、動かし方を見る

同じモデルでも、道具の見せ方と予算によって結果は変わります。外部のToolSandboxでの追加比較では、候補を増やしたとき、成功率の低下よりトークン消費の増加が明確でした。影響の現れ方は、仕事や環境によって変わります。

ToolBottleneckBenchが用意したのは、この違いを調べるための比較方法です。成功率と一緒に、候補の数、応答上限、実際の終了理由を見る。そうすることで、「もっと強いモデルに変える」以外の改善点も具体的に探せます。

論文・コード

Zichuan Xu, Yuyang Dong, Makoto Onizuka, Chuan Xiao. ToolBottleneckBench: Measuring Tool-Agent Performance under Controlled Pressures and Fixed Harness Budgets.

• 論文・概要
• 論文PDF
• コード・実行手順