今回の論文
今回取り上げるのは、Sehoon Kim、Suhong Moon、Ryan Tabrizi、Nicholas Lee、Michael W. Mahoney、Kurt Keutzer、Amir Gholami による論文「An LLM Compiler for Parallel Function Calling」です。2023年12月7日に arXiv で公開され、2024年には ICML 2024 に採択されています。公開元は arXiv / ICML 2024、研究分野は LLM エージェント、function calling、推論時オーケストレーションです。URL は https://arxiv.org/abs/2312.04511 です。
この論文を選んだ理由は、エージェント開発でよくある「ツールを順番に呼びすぎて遅い」「途中経過を毎回プロンプトに戻すのでトークンも増える」という問題に、かなり実装しやすい形で答えているからです。モデル本体を作り替える話ではなく、既存の LLM とツール群をどうつなぐかの話なので、実務への移し替えもしやすいです。
どんな技術か
LLMCompiler は、LLM エージェントのツール実行を「1回考えて1回ツールを呼ぶ」という逐次ループから、「まず実行計画を作り、依存関係がない処理はまとめて並列実行する」という形に変える技術です。
通常の ReAct 型エージェントは、思考、ツール実行、観測、再思考を何度も繰り返します。この方式は柔軟ですが、検索や API 呼び出しが複数必要なタスクでは、独立に実行できる処理まで直列化されやすいです。たとえば「2社の売上を調べて比較する」タスクでは、A社を調べてから B社を調べる必要は本来ありません。
LLMCompiler はここをコンパイラ的に扱います。ユーザー入力を受けたら、まず Planner が必要なツール呼び出しを分解し、依存関係つきのタスクグラフを作ります。そのうえで、依存が解けたタスクから順に Executor が並列実行します。要するに、エージェントの実行フローを自然言語の逐次思考として扱うのではなく、DAG として最適化しているわけです。
課題
この技術が解決しようとしているのは、ツールを使う LLM エージェントの遅さ、コスト、そして中間観測の扱いによる不安定さです。
何が難しいのかというと、エージェントのタスクには「本当に順番が必要な処理」と「実は同時にできる処理」が混ざっていることです。人間が見れば独立だとわかる処理でも、ReAct のような逐次実行では毎回 LLM が次の一手を決めるため、全部が直列に流れやすくなります。
既存の方法ではどこに限界があるのかというと、まず遅いです。検索、計算、API 呼び出し、表解析などを1つずつ実行すると、待ち時間がそのまま足し算されます。さらに、各ステップの観測を毎回プロンプトへ追加するので、入力トークンも増えやすく、結果として推論コストも膨らみます。
なぜこの課題を解く必要があるのかというと、エージェントが実運用に入ると、単発 QA よりも「複数の外部システムをまたいで処理する」ケースが増えるからです。社内検索、CRM、会計 API、在庫 DB、Web 検索、計算ツールなどを組み合わせると、推論そのものよりオーケストレーションの効率がボトルネックになりやすいです。
実際の AI システムでは、比較調査、集計、照合、候補探索、複数ページ巡回のような場面で問題になります。たとえば複数サービスの料金を調べて表にする、複数文書を読んで差分を出す、複数商品候補を比較して推薦するといったタスクでは、順番にやる設計だと UX もコスト構造も悪化しやすいです。
用語解説
- Function Calling
- LLM が外部の関数やツールを呼び出す仕組みです。検索、計算、API 実行、DB 参照などをモデル外で行うための基本機能で、LLMCompiler はこの呼び出し全体をどう編成するかを最適化します。
- ReAct
- 思考と行動を交互に進める代表的なエージェント手法です。柔軟ですが、各ツール呼び出しのたびに再推論が入りやすく、独立タスクまで逐次化されるのが LLMCompiler の比較対象として重要です。
- DAG（Directed Acyclic Graph）
- 循環のない有向グラフです。ある処理が別の処理の結果に依存する関係を表しやすく、LLMCompiler ではタスクと依存関係をこの形で表現することで、並列化可能な部分を見つけます。
- 依存関係
- あるタスクの実行に、別タスクの出力が必要な関係です。たとえば「Apple の時価総額」と「Microsoft の時価総額」は独立ですが、「両者を比較する」はその2つに依存します。LLMCompiler はこの違いを明示的に扱います。
- ストリーミング計画
- Planner が全計画を出し切るまで待たず、生成されたタスクから順次実行へ流す方式です。論文ではこれにより Planner の待ち時間を隠し、長いツール実行があるケースでさらにレイテンシを縮めています。
技術の仕組み
LLMCompiler の本質は、エージェント実行を「逐次的な思考ログ」ではなく「依存関係つき実行計画」として扱う点にあります。
基本アイデア
最初に Planner が自然言語の依頼を複数のタスクへ分解します。その際、各タスクに番号を振り、先に終わったタスクの出力を後続タスクで参照できるようにします。論文では $1、$2 のようなプレースホルダを使い、後続タスクがどの結果を必要とするかを明示しています。
たとえば「Microsoft の時価総額が Apple を上回るにはどれだけ増える必要があるか」という問い合わせなら、search(Microsoft Market Cap) と search(Apple Market Cap) は独立です。その後で math(...) を実行し、最後に LLM で答えを整形するという流れになります。
モデル構造というより実行構造の工夫
この論文は新しい Transformer 層を提案しているわけではありません。主役は LLM の外側にある実行基盤です。論文の中心コンポーネントは次の3つです。
Planner
Planner は、必要なツール呼び出し、引数、依存関係を生成します。ここでは LLM の推論能力を使って、入力タスクを DAG に変換します。論文では、Planner に対して専用プロンプトを用意し、正しい構文で依存グラフを出すように誘導しています。
重要なのは、Planner が「どの処理が並列化可能か」を暗黙に判断している点です。ReAct が1ステップずつ次の行動を選ぶのに対し、LLMCompiler は最初に実行全体の見取り図を作ります。
Task Fetching Unit
Task Fetching Unit は、依存関係が解決したタスクを Executor に渡す役目です。先行タスクの出力を受け取り、後続タスク中の $1 や $2 を実値で置き換えます。
ここは地味ですが重要です。LLM をもう一度呼ばなくても、単純なキューイングと依存解決だけで次の実行に進めるからです。つまり、ツールの結果を全部まとめて毎回プロンプトへ戻さなくても、実行制御だけなら軽量なランタイムで処理できます。
Executor
Executor は、依存がないタスクを非同期に並列実行します。論文では、検索、計算、API 呼び出しのような通常のツールだけでなく、特定用途向けの別 LLM エージェントもツールとして扱えるとしています。
各タスクは個別メモリを持ち、結果は Task Fetching Unit に返されます。これにより、中間観測を巨大な1本のプロンプトに積み続ける従来方式より、実行状態を構造化しやすくなります。
ストリーミングで Planner 待ちを隠す
Planner は便利ですが、実行前に大きな待ち時間が入ると本末転倒です。そこで論文では、Planner がグラフ全体を出し切る前でも、生成済みのタスクから順に流す streamed planner を導入しています。
これは CPU の命令パイプラインに近い発想です。とくに検索より計算や外部 API が長いケースでは、Planner の残り出力を待っている間に先頭タスクを進められるため、体感レイテンシを下げやすくなります。
動的再計画にも対応する
すべてのタスクが最初から固定できるとは限りません。途中結果を見て分岐したいケースもあります。論文では、Executor から Planner に結果を返し、新しいタスク群を再生成するループも扱っています。Game of 24 のように、中間状態を見ながら探索を続ける問題がその例です。
この点が重要なのは、LLMCompiler が単なる「一括並列化ツール」ではなく、必要なら再計画込みのエージェント実行基盤として使えることを示しているからです。
実験と結果
論文では、単純な並列検索だけでなく、依存関係を含むタスクや探索型環境でも LLMCompiler を評価しています。
何を検証したのか
検証の主眼は3つあります。1つ目は、HotpotQA や Movie Recommendation のような比較的並列化しやすいタスクで、ReAct より速く安くなるかです。2つ目は、依存関係がある独自ベンチマーク ParallelQA でも有効かです。3つ目は、動的再計画が必要な Game of 24 や、探索量が重要な WebShop でも性能が落ちないかです。
データセットと評価指標
論文では HotpotQA、Movie Recommendation、ParallelQA、Game of 24、WebShop を使っています。評価指標は主に正答率、成功率、平均スコア、レイテンシ、トークン消費、推定コストです。
面白いのは、単なる精度比較ではなく、エージェント運用で本当に効く指標を揃えている点です。速くなっても精度が落ちたら意味がありませんし、逆に精度が少し上がっても遅すぎれば実サービスには載せにくいです。LLMCompiler はそこをまとめて見ています。
HotpotQA と Movie Recommendation では大きく高速化
GPT 系モデルでの評価では、HotpotQA で ReAct の 7.12 秒に対し LLMCompiler は 3.95 秒で、1.80 倍の高速化でした。Movie Recommendation では 20.47 秒から 5.47 秒になり、3.74 倍の高速化が出ています。
コスト面でも改善が大きく、HotpotQA では推定コストが 3.37 倍削減、Movie Recommendation では 6.73 倍削減でした。これは、独立タスクを並列化できるだけでなく、中間観測を逐次プロンプトへ足し続ける回数が減るため、入力トークンが圧縮されるからです。
精度も大きくは落ちていません。Movie Recommendation では GPT 系設定で ReAct の 72.47% に対し LLMCompiler は 77.13% でした。つまり「速くなる代わりに雑になる」ではなく、むしろ改善する条件も確認されています。
依存関係がある ParallelQA でも有効
ParallelQA は論文で新しく導入されたベンチマークで、検索結果を使って計算し、そのあと比較するような、完全並列ではないタスクを含みます。ここで LLMCompiler は GPT 系設定で 35.90 秒から 16.69 秒へ短縮し、2.15 倍の高速化を示しました。精度も 89.09% から 89.38% とほぼ維持しています。
LLaMA-2 70B 設定では、ParallelQA で 59.59% から 68.14% に改善しており、速度だけでなく正答率でも差が出ています。論文の主張は、並列化できるから速いだけではなく、中間結果を何度もプロンプトへ戻さないほうが判断フローが崩れにくい、という点にもあります。
ストリーミング Planner は長い処理で効く
論文では streamed planner の効果も別途測定しています。ParallelQA ではストリーミングなしが 21.72 秒、ありで 16.69 秒となり、1.30 倍の追加高速化が報告されています。
これは、Planner の出力待ちを完全同期にしないことが効いている例です。API 呼び出しや重い計算ツールが混ざる現場では、このランタイム設計差がそのまま UX に効きそうです。
WebShop では成功率も改善
WebShop はオンラインショッピング環境を模した探索ベンチマークです。ここでは候補商品を調べ、複数ページを見て比較しながら最適な商品を選ぶ必要があります。
gpt-4-0613 設定では、ReAct の成功率 35.2% に対して LLMCompiler は 55.6% でした。gpt-3.5-turbo でも 48.2% を記録しています。論文では、ReAct は十分な探索前に決め打ちしやすい一方、LLMCompiler は複数候補の exploration を並列に進めやすいため、成功率改善につながったと分析しています。
ここではレイテンシが常に ReAct より短いわけではありません。gpt-4-0613 の WebShop では ReAct 19.90 秒、LLMCompiler 26.73 秒でした。それでも精度面の改善が大きく、LATS や LASER のような探索系ベースラインと比べると大幅に高速だった、というのが論文のポイントです。
何に使える？
LLMCompiler の価値は、ツールを複数使うアプリならかなり広く応用できる点にあります。
複数検索を伴う RAG エージェント
RAG 系エージェントでは、1つの質問に対して複数の索引、複数クエリ、複数データソースを引くことがあります。独立な検索を順番に呼ぶのではなく、先に検索計画を立ててまとめて実行すれば、応答待ちをかなり削れます。特に社内文書検索と Web 検索を併用する構成では相性がよいです。
業務自動化の集計タスク
複数 API から数字を取ってきて集計し、最後に比較やレポート化を行うタスクは、この論文の想定とかなり近いです。会計、営業、在庫、広告運用のように、複数 SaaS のデータをまとめる処理では、検索や取得を並列に行い、最後の整形だけ LLM に任せる構成が作りやすいです。
比較型の購買・推薦エージェント
WebShop の結果が示すように、複数候補を見比べる必要があるタスクでは有望です。EC の商品比較、SaaS 比較、求人推薦、不動産候補比較などでは、候補ページの読み込みや属性抽出を並列化しやすく、探索漏れを減らせる可能性があります。
マルチツールの社内アシスタント
社内アシスタントは、Slack、Notion、チケット管理、CRM、カレンダー、社内 DB など複数ツールをまたぐことが多いです。質問に対して最初に必要ツール群を DAG 化できれば、単純な問い合わせ応答よりも「複数システム横断タスク」で真価を発揮しやすいです。
コード支援や運用支援
静的解析、テスト実行、ログ検索、依存関係確認、ドキュメント参照のような工程も、独立部分は並列化できます。論文はコードエージェントを直接評価していませんが、この応用はかなり自然です。これは論文の直接実験結果ではなく、構造の類似性に基づく実務上の推測です。
開発や事業へのヒント
この論文から得られるヒントは、エージェントの性能改善を「モデルを賢くする」だけで考えないことです。実行計画の設計だけでも、かなり大きな差が出ます。
エージェントはワークフロー最適化の問題でもある
多くのチームは、ツールを増やしたあとも ReAct 的な直列ループをそのまま使いがちです。しかし、ツール数が増えるほど、どの順番で呼ぶか、どこを並列にできるかのほうが重要になります。プロダクト上の遅さをモデル品質の問題だと思っていると、改善の打ち手を見誤りやすいです。
中間観測を全部プロンプトへ戻さない設計は強い
論文の実験は、単に並列化したから速いだけではなく、トークン消費の削減も大きいことを示しています。これは API コストだけでなく、長い中間観測で推論がぶれやすい問題にも効きます。エージェント基盤を作るなら、「状態管理をプロンプトだけに依存しない」設計を早めに考えたほうがよさそうです。
小規模プロダクトでも部分導入しやすい
Planner、Task Queue、Executor の3分割は、巨大な研究システムでなくても実装できます。最初は search x 2 -> compare のような単純な DAG だけ対応し、徐々に依存解決や再計画を増やす形でも価値が出ます。特に API 待ちが長い SaaS 連携では、小規模でも体感差が出やすいです。
注目すべき方向性は「推論そのもの」より「推論の編成」
今後は、モデルが1回で賢く答えることだけでなく、複数ツールや複数サブタスクをどう編成するかが差別化要素になりそうです。これは論文の直接結論というより、その結果から見える方向性です。エージェント時代の最適化対象は、デコーダ内部だけではないと考えさせられます。
限界
LLMCompiler にも明確な限界があります。まず、Planner が最初の分解を誤ると、後段の並列実行はそのまま誤った計画を高速に進めるだけになります。つまり、実行器が賢くても、計画品質には依存します。
また、すべてのタスクが並列向きとは限りません。途中観測を見てから次の方針を決める必要が強いタスクでは、ReAct 的な逐次性のほうが自然な場合があります。論文も再計画機構を入れていますが、分岐が多いほど Planner とランタイムの複雑さは上がります。
実装面では、ツールの入出力を構造化し、依存関係を安全に解決する必要があります。プレースホルダ置換やタスク状態管理が雑だと、並列化によって逆にバグ調査が難しくなります。モデル改善よりも、基盤実装の質が成否を左右しやすいタイプの技術です。
レイテンシも常に最短になるわけではありません。WebShop のように Planner オーバーヘッドが効く場面では、単純な逐次実行より遅くなることもあります。したがって、独立タスクが十分あるか、外部ツール待ちが長いかを見極めて使う必要があります。
さらに、論文の主要評価は特定ベンチマーク上のもので、実際の社内業務フローや複雑な SaaS 連携で同じ改善率がそのまま出るとは限りません。この点は実務上の検証が必要です。
よくある質問
Q. LLMCompiler は ReAct を完全に置き換える技術ですか？
A. 完全な置き換えというより、ReAct の弱い部分である逐次実行のオーバーヘッドを補う実行基盤です。独立タスクが多い問題ではかなり有効ですが、逐次的に観測しながら方針を変えるタスクでは、再計画や通常の ReAct 的制御もまだ必要です。
Q. どんなエージェントなら効果が出やすいですか？
A. 複数検索、複数 API 取得、複数候補比較のように、同時に走らせられる処理があるエージェントです。逆に、毎ステップの観測が次の行動を強く決める単線的タスクでは、効果が限定的なことがあります。
Q. モデルを再学習しなくても使えますか？
A. 使えます。論文の主眼は学習手法ではなく、既存の LLM とツール群をどう編成するかです。Planner 用のプロンプト設計やツール定義は必要ですが、基本的には推論時のアーキテクチャ変更として導入できます。
Q. OpenAI の並列 function calling と何が違いますか？
A. 論文では、LLMCompiler は OpenAI の並列 function calling より広いタスク依存関係を扱える点を重視しています。単純な複数同時呼び出しだけでなく、依存つき DAG、プレースホルダ置換、再計画まで含めて設計されているのが違いです。
Q. 小規模チームでも試せますか？
A. 試しやすいです。特に、既にツール呼び出し型のエージェントがあり、遅さが課題になっているなら、Planner と Executor の分離だけでも価値があります。ただし、並列実行時の状態管理とエラー処理は最初から丁寧に設計したほうが安全です。
今日の学び
この論文は、ツールを使う LLM エージェントが遅く高コストになりやすいという課題を扱っています。そこで提案されたのが、タスクを DAG に分解し、依存関係のない処理を並列実行する LLMCompiler です。
ここから得られるヒントは、エージェント改善の主戦場がモデル内部だけではないことです。複数ツールをどう計画し、どう並列化し、どこで再計画するかを設計できれば、既存モデルのままでも実用性を大きく引き上げられます。