Apple機械学習研究、AIエージェントの道具探しは「検索が先か、計画が先か」を比較単純な依頼は検索先、複数ツールの依頼は計画先が上回り、計画先は推論コストが約2倍

Apple機械学習研究（Apple Machine Learning Research）が、AIエージェントが大量のAPIの中から必要な道具を見つける方式を比べた論文「Plan or Retrieve First? A Scale Study of Tool Discovery Architectures」を公開しました。Appleの研究ページには2026年10月公開、学会はEMNLPと表示されています。arXiv（アーカイブ）への投稿は2026年10月13日（UTC）です。著者らはToolBench（ツールベンチ）の4万6,984個のAPIで、「依頼文で先に検索する方式」と「LLMが先に計画を書き、それで検索する方式」を比べ、依頼が単純なら前者、複数ツールが要る依頼なら後者が上回ったと報告しています。

3行まとめ

1. Apple機械学習研究が、ToolBench（4万6,984 API・50カテゴリ）でツール探しの2方式RtPとPtRを比較した論文を公開した（EMNLP、著者5人）
2. 著者らによると、単一ツールの依頼はRtP、複数ツールの依頼はPtRが上回り、この入れ替わりはk=1〜20、登録簿1,000〜47,000 APIで保たれた
3. PtRは道具探しにLLMを1回追加するため推論コストがおよそ2倍で、著者らは依頼の複雑さに応じて切り替える方式を「実用的な方向」として挙げている

本記事の内容は、日本時間10月16日5時台に公式ページで確認したものです。

何を比べた研究なのか

AIエージェントが使える道具（API）が数万個あると、その定義を全部1回のプロンプトに入れることはできません。著者らは「コンテキストウィンドウに限りがあるため」と説明しています。そこで、先に候補を絞り込む工程が要ります。比べられた2方式は次のとおりです。

PtRでは、LLMが「こういう機能のAPIが要る」という仮の関数の形を先に書きます。依頼文そのものではなく、その仮の形で検索する、という順番です。

どの条件で、何が分かったのか

評価はToolBenchで行われました。論文の要旨によると、API数は4万6,984個、カテゴリは50です。依頼は3種類の部分集合に分けられています。

著者らが「依頼の複雑さで勝者が入れ替わる交差」と呼ぶ結果は、次のとおりです。

• 単一ツールの依頼（G1）ではRtPがPtRを上回り、複数ツールの依頼ではPtRがRtPを上回った
• この入れ替わりは、取得件数kが1から20のすべてで成り立つ
• 登録簿の規模を1,000個から4万7,000個まで変えても崩れない
• モデルはGemini（ジェミニ）2.5 Flashとgpt-oss-120bの両方で一貫していた

なお、本記事が取得した2ページには、グループごとの具体的な成功率の数字は載っていません。載っているのは要旨までで、数値は論文本体を確認する必要があります。

なぜ単純な依頼ではRtPが勝つのか

著者らは「スタブの幻覚」という失敗の型を挙げています。LLMがもっともらしいが実在しないAPI名を作ってしまう現象です。著者らはこれを「諸刃の剣」と呼びます。

• 単純な依頼では、PtRのスタブが固有名詞の手がかりを抽象化して落としてしまう。RtPは依頼文の固有名詞をそのまま照合できる
• 複雑な依頼では、同じ仕組みが、複数の意図を機能ごとの小さな必要に分解する働きをする

つまり、同じ性質が依頼によって欠点にも長所にもなる、という説明です。

料金・コストはどうなるのか

PtRは道具探しの段階でLLMを1回余分に呼びます。著者らはトークンの負担を分析し、この追加の呼び出しで推論コストが「おおよそ2倍」になると述べています。複数ツールの依頼ではその分の見返りがあり、単一ツールの依頼では不利になる、という整理です。

そのうえで著者らが実用的な方向として挙げるのが、依頼の複雑さに応じて方式を切り替える「適応的ルーティング」です。切り替えの判断には、パイプラインにすでにある追加コストゼロの信号、つまりRtPの検索結果の1位のスコアが使えると述べています。

日本の読者にとって何が関係するのか

今回の発表は研究論文であり、製品や機能の提供開始ではありません。日本での提供、料金、対応プランといった項目は当てはまりません。関係があるのは、社内の業務ツールやMCPサーバーなど、エージェントに渡す道具が増えてきたときの設計の考え方です。道具が数千〜数万になったときの候補の絞り込み方が、精度とコストの両方に効いてくるという論点を、登録簿の規模や取得件数を変えて比べた研究です。

ただし、実験の対象はToolBenchのAPIです。社内ツールの登録簿で同じ入れ替わりが起きるかは、この論文からは分かりません。

筆者が公式ページで確認できたこと

日本時間10月16日5時1分ごろにAppleの研究ページを取得したところ、本文は論文の要旨だけでした。ページには「published October 2026」とあり、日付は月までしか書かれていません。5時1分ごろに取得したarXivのページでは、投稿は2026年10月13日と日付まで確認できました。両方の要旨は、筆者の見る限り、句読点の書式（Apple側のダッシュがarXivではカンマ、引用符の形）を除いて同じ文面でした。なお、筆者は論文のPDFや本文の表は取得しておらず、実装を動かしてもいません。

論文本体で確かめたい点

• グループ（G1・G2・G3）ごとの具体的な数値と、差の大きさ。要旨には勝ち負けの向きしか書かれていない
• 「推論コストがおよそ2倍」の内訳（入力と出力のトークンの割合など）
• 適応的ルーティングは、要旨では「実用的な方向」として挙げられているだけで、切り替えを実装して測った結果は要旨に書かれていない。論文本体にあるかは未確認
• 評価に使った2つのモデル以外（他社の最新モデルなど）でも成り立つか

著者はMingfei Zhang、Amit Surana、Ziauddin Majid、Chenxi Wang、Michael Xuの5人です。関連する過去の研究として、Appleのページは「ProTIP: Progressive Tool Retrieval Improves Planning」（2023年12月20日）と「Context Tuning for Retrieval Augmented Generation」（2023年12月18日）を挙げています。

参照した公式ページと確認時刻

• Apple Machine Learning Research「Plan or Retrieve First? A Scale Study of Tool Discovery Architectures」: https://machinelearning.apple.com/research/plan-retrieve-tool-discovery （日本時間2026年10月16日5時1分ごろ取得）
• arXiv:2610.19068: https://arxiv.org/abs/2610.19068 （同5時1分ごろ取得）

本記事は続報があり次第更新します。