Apple ML Researchは2026年10月14日(現地時間)、大規模言語モデル（LLM）エージェントにおけるツール発見アーキテクチャに関する研究結果を発表した。この研究は、Retrieve-then-Plan（RtP）とPlan-then-Retrieve（PtR）という二つの主要なアプローチを比較分析し、クエリの複雑性に応じた性能のクロスオーバーを特定した。
LLMエージェントが、実行計画を立てる前に大規模なレジストリから関連するAPIを発見する際、限られたコンテキストウィンドウが全てのツール定義を単一のプロンプトに注入することを妨げている。
主流であるRetrieve-then-Plan（RtP）アプローチは、ユーザーのクエリを埋め込み、近似近傍探索を通じて類似ツールを検索する。これに対し、Appleの研究はPlan-then-Retrieve（PtR）という代替パラダイムを研究した。PtRでは、LLMがまずAbstract Tool Stubs（必要な機能を記述する仮説的な関数シグネチャ）を生成し、これをレジストリに対する検索クエリとして用いる。
この研究はToolBench（46,984のユニークなAPIエンドポイント、50カテゴリ）を用いて評価を実施し、単一ツールクエリ（G1）、カテゴリ内複数ツールクエリ（G2）、カテゴリ横断複数ツールクエリ（G3）の各サブセットで性能を検証した。その結果、クエリの複雑性に応じた明確なクロスオーバーが確認された。単一ツールクエリではRtPがPtRを上回る一方、複数ツールクエリではPtRがRtPを上回った。このクロスオーバーは、全ての検索予算（k=1から20）、1kから47k APIにわたるレジストリサイズ、そしてGemini 2.5 Flashとgpt-oss-120bという複数のモデルファミリーにおいて一貫していた。
PtRにはスタブ幻覚（stub-hallucination）という失敗モードがあることが特徴づけられた。これはLLMがもっともらしいが存在しないAPI名を生成する現象である。シンプルなクエリでは、PtRのスタブはRtPが直接マッチさせる固有名詞のシグナルを抽象化してしまう。しかし、複雑なクエリでは、このメカニズムが多面的な意図を機能的なサブニーズに分解する。
さらに、トークンオーバーヘッドの分析により、PtRの追加の発見呼び出しは約2倍の推論コストを伴うことが示された。この追加コストは複数ツールクエリでは効果があるが、単一ツールクエリでは不利に働く。この結果は、実用的な方向性として、複雑性適応型ルーティングの重要性を示唆しており、これはパイプラインにすでに存在するゼロコスト信号（RtPのトップ1検索スコア）によって駆動できる可能性がある。
参考: Apple ML Research (アーカイブ) — 2026年10月15日 09:00 (JST)
原文ハイライト"PtR outperforms RtP on multi-tool queries"