AsyncFC：エージェントの「待ち時間」をモデル改造なしで削る研究

過去24時間の新着から、今日は arXiv cs.CL の5月15日新着リストに掲載された “Concurrency without Model Changes: Future-based Asynchronous Function Calling for LLMs” を取り上げたい。これは新しいLLMそのものではなく、LLMエージェントがツールを呼び出すときの実行方式を変える研究だ。論文のv1は2026年5月14日 17:02 UTCに提出され、cs.CL / cs.AI / cs.LGカテゴリに登録されている。(arxiv.org)

何が問題なのか

現在の多くのLLMエージェントは、ツール呼び出しを同期的に扱う。つまり、モデルが関数呼び出しを出すと、ランタイムがその関数を実行し、結果が返ってくるまでモデルの生成は止まる。検索、DB照会、ファイル操作、テスト実行、API呼び出しのように時間のかかる処理が入ると、モデル自体が速くても全体の体感速度は落ちる。論文はこの「関数実行待ちによる直列化」を、エージェントの実用上のボトルネックとして扱っている。(arxiv.org)

提案手法 AsyncFC の発想は、非同期プログラミングで使われる future / promise に近い。関数の実行結果を待たずに、まず「あとで値になるプレースホルダ」をモデルへ返す。モデルはその future を見ながら次の推論や次のツール呼び出しを進め、必要になった時点で await_future に相当する操作で実値を受け取る。重要なのは、これはモデルのファインチューニングや既存関数の書き換えではなく、実行レイヤー側の変更として設計されている点だ。(arxiv.org)

技術的な新しさ

AsyncFCの核は三つある。

第一に、デコードと関数実行の重ね合わせ。従来は「呼ぶ→待つ→読む→次を考える」だったが、AsyncFCでは「呼ぶ→futureを返す→裏で実行しつつ次を考える」に変わる。これにより、モデル生成時間とツール実行時間を重ねられる。(arxiv.org)

第二に、futureを引数として渡せるスキーマ変換。単に「結果待ちID」を返すだけでなく、未解決のfutureを後続の関数呼び出しの入力として扱えるよう、同期的な関数スキーマをfuture対応に自動変換する。これは、モデルが未確定の記号的参照をかなり自然に扱える、という観察に依存している。(arxiv.org)

第三に、依存関係を壊さないスケジューラ。非同期化は速くなる一方で、状態を変更する関数を不用意に並列実行すると競合が起きる。AsyncFCは、読み書きするリソースを開発者が注釈できる仕組みを用意し、依存関係が安全な場合だけ並列化する。注釈がない場合は保守的に直列実行し、それでもデコードと実行の重なりによる高速化は得られる設計になっている。(arxiv.org)

結果をどう読むべきか

論文は、Berkeley Function Calling Leaderboard、SWE-bench Lite、HotpotQA系の非同期思考実験で評価している。BFCL v4 Web Searchでは、現実的なバックエンド遅延を用いた条件で1.26倍の高速化を報告している。BFCLは、関数呼び出しをエージェントの基礎能力として評価するベンチマークで、v4ではWeb検索、メモリ、フォーマット感度などを含む構成になっている。(arxiv.org)

SWE-bench Liteでは、300タスクの小規模・低コストな評価セットを使い、AsyncFCをSWE-agentに統合した実験で1.44倍の高速化を報告している。ただし、表上の解決率はベースライン47.6%に対してAsyncFC 44.3%であり、著者らは統計的に有意な精度劣化の証拠はないと述べているものの、ここは「高速化しても品質が完全に不変」と読むより、「少なくともこの実験条件では大きな劣化は確認されなかった」と慎重に受け止めたい。(arxiv.org)

また、HotpotQAで外部推論ターンをツールとして扱う実験では、精度75.0%を保ったまま1.24倍の高速化を示している。これは、AsyncFCが検索やファイル操作だけでなく、「別の思考プロセスを裏で走らせる」ような非同期思考にも拡張できる可能性を示している。(arxiv.org)

なぜ重要か

この研究が面白いのは、性能改善の場所を「モデル内部」ではなく「実行系」に置いていることだ。エージェントの体感性能は、モデルのトークン生成速度だけで決まらない。検索APIの遅延、テストの実行時間、外部サービスの応答、ファイルI/O、権限確認などが積み重なって決まる。AsyncFCは、LLMエージェントを一種の分散システムとして見て、そのスケジューリングを改善する試みと読める。

これは今後のエージェント基盤にとって重要な方向だと思う。モデルが十分に賢くなるほど、次に効いてくるのは「どの順番で、何を待ち、何を並列化し、どこで人間に確認を戻すか」になる。つまり、エージェント開発はプロンプト設計だけでなく、OS、DB、分散システムに近い設計問題へ移っていく。

留保点

一方で、AsyncFCの効果はタスク構造に強く依存する。論文自身も、厳密に逐次的なタスクや関数遅延がほとんどないタスクでは高速化が限定的で、await_future の追加ターンや並列デコードの計算コストが上回る可能性を認めている。(arxiv.org)

また、実運用では副作用のあるツールが問題になる。メール送信、予約、支払い、コード変更、ロボット動作のような操作では、キャンセル、再試行、順序保証、監査ログ、冪等性が重要になる。AsyncFCは依存関係注釈と保守的スケジューリングでこの方向に踏み込んでいるが、プロダクション環境ではツールごとの安全契約をかなり丁寧に設計する必要がある。

今回の論文は「もっと大きなモデルを待つ」以外の改善余地を示している。エージェントの次の進歩は、推論能力だけでなく、待ち時間・依存関係・副作用をどう扱うかという実行基盤の設計から来るかもしれない。