Google ToolGrad とは何か - 「答えから先に作る」ツール利用データ生成の仕組みと実力

LLM に「天気 API を呼んで、その結果でホテルを検索して」といったツール呼び出しを覚えさせるには、大量の学習データが必要です。ところが、そのデータを作る工程そのものが高コストで、失敗も多いという問題がありました。

ToolGrad は、この問題に対して「質問から解き方を探す」のをやめ、実際に動くツール呼び出しの連鎖を先に作り、その答えに合う質問をあとから書くという逆向きの発想で取り組んだ研究です。2026年9月10日に Google Research Blog で紹介され、論文は ACL 2026 の Findings に採録されています。この記事では、論文（arXiv v3）と公式ブログを一次ソースに、仕組みと結果を整理します。

ToolGrad の概要

正式タイトル: ToolGrad: Efficient Tool-use Dataset Generation with Textual "Gradients"
著者: Zhongyi Zhou、Kohei Uehara、Haoyu Zhang、Jingtao Zhou、Lin Gu、Ruofei Du、Zheng Xu、Tatsuya Harada（Google、東京大学、理化学研究所 AIP、東北大学）
論文: arXiv 2508.04086。v1 は2025年8月、最新の v3 は2026年6月17日
学会: Findings of ACL 2026
公式ブログ: 2026年9月10日、Google XR の Zhongyi Zhou 氏と Ruofei Du 氏の執筆
公開物: コード（GitHub、Apache-2.0）、データセット ToolGrad-500、Gemma 3 ベースのモデル ToolGrad-1B / 4B / 12B（Hugging Face）

ブログの謝辞によると、研究は主に Zhongyi Zhou 氏が Google に Visiting Researcher として在籍していた期間に行われたものです。

NOTE

論文の版によって表記が変わっています。v1 ではデータセット名が「ToolGrad-5k」、要旨の成功率が「100% pass rate」でしたが、v3 では「ToolGrad-500」「almost 100% pass rate」になっています。この記事の数値はすべて v3 にもとづきます。

従来の作り方の何が問題だったのか

ツール利用データの代表例である ToolBench（ToolLLM）は、次の順番でデータを作ります。

API の説明をもとに、LLM がユーザーの質問を作る
深さ優先探索（DFS）を行うエージェントが、その質問を解くツール呼び出しを試行錯誤で探す
解けたものだけをデータとして残す

この「質問が先（query-first）」の方式には弱点があります。LLM が作った質問は、実在の API では解けないことがあります。存在しない機能を前提にしていたり、API の応答が想定と違ったりするためです。その結果、探索を何度も繰り返しても解けずに捨てられるサンプルが多くなり、API の実行回数もかさみます。論文の実験では、DFS 方式の生成成功率は 63.8% でした。

発想の転換: answer-first

ToolGrad は順番を逆にします。

実際に API を呼び出し、成功したツール呼び出しを1つずつ積み上げて連鎖（ワークフロー）を作る
完成した連鎖を見て、「この呼び出しが自然と必要になるユーザーの質問」と応答を LLM に書かせる

ブログは、明示的なツール利用の解は質問文よりも曖昧さが少ないので、解から質問への注釈付けはずっと簡単で、LLM を1回呼ぶだけで済むと説明しています。論文ではこの工程を「inverse prediction」と呼び、要約タスクに近いものとして位置づけています。

データの各サンプルは、質問 q、API ワークフロー W、応答 r の3つ組です。ワークフロー W は複数のチェーンの集合で、各チェーンは API 呼び出しの並びです。

「テキストの勾配」とは

名前の由来は、LLM へのプロンプトを「テキストによる勾配」で最適化する TextGrad です。論文は、通常の機械学習、TextGrad、ToolGrad を次のように対応づけています（Table 1 を要約）。

項目	通常の機械学習	TextGrad	ToolGrad
最適化する対象	モデルの重み	プロンプト	データセット（q, W, r）
勾配に当たるもの	損失関数の微分	LLM による批評	LLM による「最良の API の選択」
更新	重みを勾配方向に動かす	LLM がプロンプトを書き換える	ワークフローに API を1つ追加

論文自身が「textual "gradients" are not actual mathematical gradients」と注意しているとおり、数学的な勾配ではありません。「今の状態を見て、どの方向に1歩進めるとよいかを LLM に判断させ、それを反復する」という構造を、勾配法になぞらえた呼び方です。TextGrad がより良いプロンプトを目指すのに対し、ToolGrad が目指すのはより良いデータセットです。

1イテレーションの4ステップ

ToolGrad は次の4ステップを1サンプルあたり10回繰り返し、ワークフローを育てていきます。

1. API Proposer

API データベースから bs 個（論文では50個）の API をミニバッチとして取り出します。LLM はそれらの簡単な説明と現在のワークフローを見て、次に追加する候補を最大 m 個（論文では3個）選び、それぞれに「Get...」「Use...」のような命令形の使い方の指示を付けます。

この段階ではツールを呼び出しません。ランダムに取り出した API の大半は無関係なので、実行コストの高い次のステップに進む前にここで絞り込みます。

2. API Executor

候補の API を、ツール呼び出しができるエージェントが並列に実際に実行します。出力は API リクエストの全履歴と、成功したかどうかのフラグです。論文はこのステップを「most expensive step」と呼んでいます。タイムアウトは10秒で、結果が良くないときは入力パラメータを変えて再試行します。

3. API Selector

実行レポートの中から、LLM が最も良い API を1つ選び、既存のどのチェーンにつなげるか、または新しいチェーンを始めるかを決めます。前の API の応答を次の API の入力に使うならチェーンにつなげる、といった判断です。論文はこのステップを「勾配」の計算に当たる中心部分と位置づけています。失敗したレポートは選考の対象になりません。

4. Workflow Updater

選ばれた API をワークフローに決定的に追加します（この追加自体に LLM は使いません）。そのうえで、更新後のワークフロー全体を LLM に渡し、質問と応答を書き直させます。質問を書く際には、API やツールの名前を出さないこと、呼び出しに使った具体的な値を含めること、現実にありそうな状況にすること、すべての API 呼び出しが明示しなくても自然と必要になる内容にすること、が指示されています。

ステップの流れのまとめ

API DB から50個を抽出
  -> Proposer: 候補を3個に絞り、使い方の指示を付ける
  -> Executor: 3個を並列に実行し、成否と履歴を記録
  -> Selector: 成功したものから1個を選び、つなぐチェーンを決める
  -> Updater : ワークフローに追加し、質問と応答を書き直す
（これを10回繰り返して1サンプル完成）

成功した呼び出しだけを積み上げていくので、データは最初から検証済みの状態になります。10回すべてで3候補がどれも成功しなかった場合だけ空のサンプルになりますが、その発生率は 0.2% でした。

学習データへの加工

生成したワークフローは、そのままでは学習に使いません。論文では次の加工をしています。

ネガティブ API の追加: 実際のエージェントは、必要以上に多くのツールにアクセスできる状況で動きます。そこで、正解の API に対してテキスト埋め込みの類似度が高い API を足し、候補を10個（p=10）にそろえます。RAG で似たツールが混ざる状況を再現するためです。
形式の統一: BFCL と同じ1ターン完結のツール利用タスクの形にします。入力は OpenAI 形式のツール定義、出力は [func(a=1), ...] のような Python 形式の呼び出しです。
ハルシネーション対策: 正解のツールをすべて無関係なものに差し替え、出力を空リスト [] にした例を20%加えます。使えるツールがないときに無理に呼ばないことを学ばせるためです。

生成に使った LLM は gemini-2.5-flash-lite で、選んだ理由はコストの安さと応答の速さです。API データベースには ToolBench の API ライブラリを使い、説明文の質と実際に呼び出せるかで2段階にふるい分けて、15,368個に絞っています。シードを変えて500回実行したものが ToolGrad-500 です。

結果1: データ生成の効率

同じ API データベースで、ToolBench の DFS 方式と比較した結果です（Table 2）。

指標	DFS（query-first）	ToolGrad（answer-first）
生成成功率	63.8%	99.8%
1サンプルあたりの正解ツール呼び出し数（平均）	2.1	3.4
LLM の呼び出し回数	64.5	63.9
ツール実行ステップ数	34.3	20.0

成功率が大きく上がっただけでなく、より長い（呼び出しの多い）連鎖を、少ないツール実行で作れています。LLM の呼び出し回数はほぼ同じです。

結果2: 学習したモデルの性能

ToolGrad-500 で Gemma 3 の 1B / 4B / 12B をファインチューニングしたモデルを評価しています。

ToolBench（1ターン）

LLM ジャッジによるスコアです（Table 3）。ジャッジには gemini-2.5-pro、claude-4.5-sonnet、deepseek-v3.2、qwen3-235b の4モデルを使い、人手評価との相関は ρ=0.88 と報告されています。

モデル	スコア
ToolGrad-12B	19.6
ToolGrad-4B	17.6
Claude 4.5 Opus	15.4
GPT-5 nano	15.4
GPT-5 mini	14.7
ToolGrad-1B	14.1
Claude 4.5 Sonnet	13.5
Claude 4.5 Haiku	12.8
GPT-5	12.7
Gemini 2.5 Pro	11.4
Gemini 2.5 Flash	8.5
Gemini 2.5 Flash-Lite	6.9

注目したいのは、データを作った教師モデル gemini-2.5-flash-lite（6.9）を、1B の生徒モデルでさえ上回っている点です。ここでの評価は「必要なツール呼び出しを1回でまとめて出力する」形式で、ReAct のように1ステップずつ考える方式ではない点に注意してください。

ToolBench のデータで学習したモデルとの比較（Table 4）では、ToolBench 側は ReAct などの推論フレームワークを使い、テストと同じ分布のデータで学習するという有利な条件です。それでも ToolGrad は 1B と 12B で上回り、4B は同点でした。学習コストも大きく違い、ToolGrad-1B / 4B / 12B は A100 4枚で合計 1 / 1.67 / 2.67 GPU 時間、ToolBench 版は H100 8枚で 29 / 68 / 370 GPU 時間でした。

BFCL（未知のツールでの評価）

学習に使っていないツールで評価する Berkeley Function Calling Leaderboard（BFCL v1/v2）の結果です。公式ブログによると、全体スコアは次のとおりです。

モデル	BFCL 全体スコア
Gemini 2.5 Pro	83.2
ToolGrad-12B	83.1
Claude 4.5 Opus	82.8
GPT-5	74.4

論文本文でも、ToolGrad-12B は Gemini 2.5 Pro に 0.1 差の2位と書かれています。元の Gemma 3 からの伸びは、Non-live の Overall で 12B が 79.44 から 87.81、Live の Overall で 74.24 から 78.46 でした（Table 6）。

スケーリングで分かったこと

論文は、フレームワークの各モジュールは一体として機能するので個別に取り除く実験（アブレーション）は妥当でないとし、代わりに規模を変える実験をしています。

イテレーション数を 4 / 8 / 12 / 16 と変えると、成功率は 8〜12 のあたりで頭打ちになる
学習サンプル数を 100 / 500 / 1k / 1.5k / 2k と変えると、Gemma-3-4B の BFCL スコアは「first increases and then decreases」、つまり増やしすぎると下がる（どのサンプル数でも元のモデルは上回る）

データセットが500件と小さいのは、この結果とも関係しています。ピークとなる具体的なサンプル数は図でしか示されておらず、数値としては確認できていません。

著者が認めている限界

論文の Limitations とディスカッションでは、次の点が挙げられています。

学習データに推論過程が含まれないため、ReAct や DFS のような推論を伴う複数ステップのツール利用には制約がある
検証したのは SFT だけで、強化学習（RL）でのデータの有効性は未検証
生成された質問が、実際の人間の依頼の仕方を反映しているとは限らず、言い回しの多様性も不足しがち
スケーリングの頭打ちが小さな規模で起きるため、実データの代わりに合成データを使う動機を弱める
メモリ機構がなく、各サンプルが独立に作られるので、似たツール利用が繰り返されやすい
対象は1ターンのツール利用で、BFCL v3 / v4 のようなマルチターンやエージェント的なタスクは範囲外

ブログは今後の方向性として、より動的で大規模な API エコシステムへの拡張と、個人向けに継続的に学習する仕組みを挙げています。

試してみるには

GitHub の README によると、GPU なしでも動くデモが用意されています。Gemini API キーと Node.js 20 が必要で、MCP の filesystem サーバーをツールとして使います。

git clone https://github.com/zhongyi-zhou/toolgrad.git
cd toolgrad
uv venv
uv sync
source .venv/bin/activate
export GEMINI_API_KEY=your_api_key
export PYTHONPATH=./
python examples/mcp_filesystem.py

PyPI にも toolgrad パッケージがあります（v0.2.0、Python 3.10 以上）。自分で ToolBench の API からデータを生成する場合は、ToolBench のキーとツール定義一式が別途必要です。学習済みモデルは Hugging Face の zhongyi-zhou/toolgrad-1b / toolgrad-4b / toolgrad-12b で公開されており、ベースは Gemma 3 の instruction tuned 版、ライセンス表記は Gemma です。

WARNING

ライセンス表記は配布先によって異なります。GitHub リポジトリは Apache-2.0、Hugging Face のデータセットは Apache 2.0、モデルは Gemma ライセンスですが、PyPI のメタデータは CC-BY-4.0 になっています（2026年9月14日時点）。利用前にそれぞれの表記を確認してください。

まとめ

ToolGrad は、ツール利用の学習データを「実際に動く呼び出しの連鎖を先に作り、質問をあとから書く」answer-first 方式で生成する
「テキストの勾配」は、LLM に次の1手（追加する API）を選ばせて反復する構造を勾配法になぞらえたもので、数学的な勾配ではない
生成成功率は DFS 方式の 63.8% から 99.8% に上がり、より長い連鎖を少ないツール実行で作れた
500件のデータで学習した ToolGrad-12B は、BFCL で 83.1 と Gemini 2.5 Pro（83.2）に迫った
推論を伴うマルチステップ利用、RL での有効性、マルチターンは今後の課題

ローカルで動かせる小さなモデルにツール呼び出しを覚えさせたいとき、「良いデータをどう作るか」は避けて通れません。ToolGrad は、その部分を安く確実にする1つの答えとして参考になる研究です。Gemma 系のモデルについては Gemma 4 の解説や DiffusionGemma の解説、LLM にツールを渡す標準仕様については MCP のロードマップ解説もあわせてどうぞ。

Google ToolGrad とは何か - 「答えから先に作る」ツール利用データ生成の仕組みと実力

ToolGrad の概要

従来の作り方の何が問題だったのか

発想の転換: answer-first

「テキストの勾配」とは