検証公開 2026-09-26· 約6分

Google Research「ToolGrad」──ツール使用データを「答えから先に」作る。API連鎖を先に組んでから質問を書く逆順で合格率ほぼ100%、Gemma 3 12Bの微調整版がBFCLで83.1（Gemini 2.5 Pro 83.2・Claude 4.5 Opus 82.8・GPT-5 74.4と並ぶ）。教師のGemini 2.5 Flash-Liteを生徒が上回る

Google Researchは2026年9月10日、ACL 2026で発表した「ToolGrad」を解説した。LLMにツール使用を教えるデータは、従来「仮の質問を作ってから深さ優先探索のエージェントに解かせる」順序で作られ、失敗が多くコストが高かった。ToolGradは逆に、動作確認済みのAPI連鎖を先に組み、それに合う質問と回答を1回のLLM呼び出しで後付けする。プロンプト最適化のTextGradにならい、実行報告から最良のAPI呼び出しを選ぶ工程を「テキストの勾配」として使う。生成した500件（ToolGrad-500）でGemma 3の1B・4B・12Bを微調整すると、ツール集合が異なるBFCLで12B版が83.1。データを作った教師のGemini 2.5 Flash-Liteを生徒が上回った。

執筆・編集：AI時短ラボ

「解答から先に作る」逆順の狙い
確認はブログのみ、論文とコードは未読
重み公開の有無・コスト・BFCLの版は不明
出典はGoogle Researchのブログ
関連記事

2026年9月18日・日本時間時点の情報です。 Google Researchのブログ（9月10日）を読んだ。エージェントの「ツール呼び出し」を学ばせる訓練データをどう作るかという裏方の話で、日本語ではほぼ扱われていない。エージェントを組む側の全体像はAIエージェントの作り方に。

3行まとめ

何が新しいか。 LLMにツール使用を教えるデータは、従来「APIの候補から仮の質問を作る→深さ優先探索（DFS）のエージェントに解かせる→うまくいった軌跡だけ残す」順序で作られてきた（ToolBench・ToolACE）。探索の失敗が多く、成功例を蒸留する構造そのものが非効率だった。**ToolGradは順序を逆にする。動作確認済みのAPI連鎖を先に組み、それに合う質問と回答を1回のLLM呼び出しで後付けする。**明示的な解答のほうが質問より曖昧さがないので、注釈が簡単になる、という理屈。

「テキストの勾配」。 プロンプト最適化のTextGradは、LLMの批評文を数値勾配の代わりに使う。ToolGradはこれをデータ生成に転用し、4つの部品を回す。API Proposer（候補APIを数個に絞る）→API Executors（並列に実行して報告書を作る）→API Selector（報告書を読み、最良の1呼び出しを選んで連鎖に足す＝勾配に相当）→LLM Updater（新しいAPI集合に合わせて合成質問と回答を書き直す）。ToolBenchの実在API 1万6千超を使った比較で、より長い連鎖を、より高い合格率で、より低いコストで生成できた（図の説明には合格率99.8%とある）。

小さいモデルが上位に並んだ。 生成した500件（ToolGrad-500）でGemma 3の1B・4B・12Bを微調整し、ToolBenchとはツール集合が違う**BFCL（Berkeley Function Calling Leaderboard）**で評価。12B版が83.1で、発表時点のGemini 2.5 Pro（83.2）・Claude 4.5 Opus（82.8）に並び、GPT-5（74.4）を上回る。データはGemini 2.5 Flash-Liteで作ったので、生徒が教師を追い越したことになる。ツール特化のToolACE・Hammer-2.1-7Bにも差をつけた。

「解答から先に作る」逆順の狙い

「質問→解答」ではなく「解答→質問」の順に作るのは、正解が確実に存在するデータだけを残す発想で、エージェントの記憶蒸留のような「軌跡から学ぶ」系統とは出発点が違う
同じ週にGoogle Researchが出したRetrieve-for-Trainも「重い探索を一度だけ回し、軽いモデルに焼き込む」型で、両方とも「推論時に考えさせない」方向に寄っている
数字はGoogle自身の測定で、比較対象のモデル名にも発表時点の版（Gemini 2.5 Pro・Claude 4.5 Opus・GPT-5）が使われている。現行世代との比較ではない
筆頭のZhongyi Zhou氏はGoogleの客員研究員として研究した、と謝辞にある。共著者にはKohei Uehara・Tatsuya Haradaの各氏の名前がある