AIエージェントがツールを使って作業するとき、既存の手法では「1回のツール呼び出し → 結果を確認 → 次のツール呼び出し」というステップを繰り返します。この逐次的な実行が原因で、単純な作業でも大量の推論トークンと往復通信が発生していました。arXiv論文2606.13663が提案するHyperToolは、この制約を「複数ツールを1ブロックのコードで並列実行する」という発想で突破し、MCP-Universeベンチマーク（エージェントがMCP：Model Context Protocol経由で複数ツールを操作する能力を測るベンチマーク）でQwen3-32Bの精度を15.69%から35.29%へと2倍以上に向上させました。
背景と文脈
LLMエージェントがツールを活用するアーキテクチャは急速に普及しています。Web検索・コード実行・データベース照会・外部APIなど、現実の業務に必要な操作のほとんどをツール呼び出しでカバーできるようになりました。特にMCP（Model Context Protocol：エージェントと外部ツールの接続を標準化するプロトコル）の普及で、多様なツールを統一的に扱える環境が整ってきました。
しかし従来の手法には「実行粒度のミスマッチ（execution-granularity mismatch）」という根本的な問題があります。1つのツールを呼び出すたびに推論トークンを生成し、結果を受け取ってから次を呼ぶため、10個のツールを使う作業では10往復の推論が必要になります。この逐次実行は精度だけでなくレイテンシとコストにも悪影響を与えていました。
コードを生成して実行させる「コード生成エージェント」に比べると、ツール呼び出しエージェントは制御しやすく安全である一方、表現力と効率の面で劣ることが課題として認識されてきました。HyperToolはこの差を埋める試みです。
技術/ビジネス面
HyperToolの仕組みはシンプルです。既存ツールをそのまま使いながら、複数ツールの呼び出しと中間結果の受け渡しを1つのコードブロックにまとめて実行できるインターフェースを提供します。エージェントはHyperTool経由で「まずツールAを呼び、その戻り値をツールBに渡し、さらにツールCと並列実行する」といった処理を1ステップで表現できます。内部では各ツールのスキーマをそのまま使うため、既存ツールの変更が不要です。
MCP-Universeベンチマーク（MCPで接続されたサーバー群を通じてエージェントが複雑なタスクを完了する能力を測定）での結果は顕著でした。Qwen3-32Bでは精度が15.69%から35.29%、Qwen3-8Bでは9.93%から33.33%に上昇しました。GPT-OSSやKimi-k2.5などの競合手法を平均精度で上回っています。
改善幅がこれほど大きい理由として、論文は「中間結果をローカルで保持して次のツールに渡せる」ことの重要性を挙げています。従来は毎回ツールの戻り値をモデルのコンテキストウィンドウに読み込んでいたのに対し、HyperToolでは中間変数として保持することでコンテキスト汚染を防げます。
これからどうなるか
HyperToolが示す最も重要な含意は、「エージェントの能力向上はモデル自体の強化だけでなく、ツール実行の設計でも実現できる」という点です。同じモデルを使いながらインターフェース設計だけで精度が2倍以上になるのであれば、推論コストを抑えつつエージェントの実用性を高める余地は大きいといえます。
ツール呼び出しを多用するエージェントを開発している場合、現在の実装を見直す価値があります。逐次ツール呼び出しを並列化できる箇所がないか確認し、HyperToolに類似した「コード的な中間処理を挟んだツール実行」を取り入れることでレイテンシとコストの両方を削減できる可能性があります。
今後はHyperToolをベースにした推論フレームワークや、OpenAI互換プロキシとして提供するライブラリが登場することが考えられます。MCPが普及するにつれ、並列ツール実行の重要性はさらに高まるでしょう。
まとめ
HyperTool（arXiv:2606.13663）は、複数ツールの並列実行を1ブロックで記述できるインターフェースを提案し、Qwen3-32Bの精度を2倍以上に向上させました。エージェントのツール設計を見直す具体的な指針を提供する論文です。
参考リンク
アイキャッチ画像: Photo by ThisisEngineering on Unsplash
