はじめに

API を使って仕事をこなす LLM エージェントを学習させるには、単なる指示応答では足りません。検索、更新、作成、送信といった操作を伴うため、連続した軌跡データが必要になります。ところが、そうしたデータを集めるには、実行可能な API、状態を持つバックエンド、そして現実的な初期データを備えた環境を丸ごと用意しなければならず、拡張性の面で大きな障害になります。

この論文は、その前提をひっくり返します。環境を先に作るのではなく、LLM 自体を「その場で動くデジタル世界モデル」として使うのです。

提案手法の流れ

API 仕様だけを入力として、次のように軌跡を合成します。

• タスク生成: LLM が、与えられた API で解ける多様なタスクを作る。
• 教師エージェントによる実行: teacher agent がタスクを段階的に解く。
• 応答シミュレーション: 別の LLM simulator が、タスク文脈と過去の履歴を踏まえて一貫した API 応答を返す。
• 品質判定: LLM judge が不自然な軌跡や品質の低い軌跡を除外する。

特に重要なのは、単なる静的な模擬ではなく、状態の整合性を保つ点です。API 利用は、前の操作が次の状態に影響することが多いため、応答の一貫性が学習品質を左右します。

この研究の意義

この方法の利点は明快です。

• 完全な環境を先に構築しなくても学習データを作れる。
• 新しい API 群にも素早く適用できる。
• 情報検索型タスクと状態変更型タスクの両方を扱える。
• 大規模なデータ生成のコストを下げられる。

著者らは AppWorld と OfficeBench で評価し、合成データで微調整したモデルが有意な性能向上を示したと報告しています。つまり、API エージェントに必要な教師信号は、必ずしも現実環境から直接集める必要がないということです。

まとめ

この論文の本質は、「環境を実装できないなら学習できない」という常識への挑戦です。LLM を使った API シミュレーションは、企業内ツールや業務フローのように、本番環境をそのまま公開しにくい領域で特に有望です。

一方で、シミュレータの偏りや judge の厳密さといった課題も残ります。それでも、実行環境なしで高品質な軌跡を作れるという発想は、API エージェント学習のスケール方法を大きく変える可能性があります。

Source: Hugging Face Daily Papers