今回の論文
今回取り上げるのは、Timo Schick らによる 2023 年の論文「Toolformer: Language Models Can Teach Themselves to Use Tools」です。公開元は NeurIPS 2023 で、研究分野は LLM のツール利用、自己教師あり学習、エージェント基盤です。URL は https://proceedings.neurips.cc/paper_files/paper/2023/file/d842425e4bf79ba039352da0f658a906-Paper-Conference.pdf です。
この論文を選んだ理由は、いまの AI エージェントや function calling 的な仕組みの根本にある問いを、かなり技術的に正面から扱っているからです。単に「プロンプトでツールを使わせる」のではなく、LLM 自身がどの場面でツールが役立つかを学習する設計になっており、エージェント、業務自動化、RAG 付きアプリの設計にそのままつながります。
どんな技術か
Toolformer は、LLM が外部ツールを使うべき位置を自分で見つけ、API 呼び出し文をテキスト中に挿入し、その返り値を使って次のトークン予測を改善する技術です。
普通の LLM は、計算、日付計算、最新情報の検索、固い事実の参照のような処理が苦手です。これらはモデルの内部知識だけで頑張るより、外部の専用ツールを呼んだほうが正確です。ただし難しいのは、毎回人間が「ここで検索して」「ここで計算して」と教え続けるのはスケールしないことです。
Toolformer はここを変えます。少数のデモだけを手がかりに、まずモデル自身が API 呼び出し候補を大量に生成します。次に、その API を本当に実行してみて、返り値を入れたほうが将来トークンの予測損失が下がるものだけを残します。最後に、そのデータでモデルを追加学習し、「いつ、どのツールを、どう呼ぶか」を学ばせます。
要するに Toolformer は、ツール利用をルールベースで埋め込むのではなく、言語モデリングの延長として学習させる技術です。
課題
この技術が解決しようとしている課題は、LLM 単体では苦手な処理を、プロンプト職人芸や大量の人手ラベルに頼らず補えるようにすることです。
何が難しいのかというと、ツール利用には少なくとも 4 つの判断が必要だからです。どのタイミングで呼ぶか、どのツールを選ぶか、どんな引数を渡すか、返り値をどう文脈に取り込むかです。どれか 1 つでも外すと、ツールを使っても性能は上がりません。たとえば検索結果を呼んでも、そもそも検索語がずれていれば役に立ちませんし、計算ツールを呼ぶべき場面で内部知識だけで答えると誤答しやすくなります。
既存の方法にはいくつか限界がありました。1 つは、人手でツール利用データを大量に作る方法です。これは高価ですし、タスクや API が増えるたびに保守負荷が増えます。もう 1 つは、特定タスク向けに few-shot プロンプトを作る方法です。これは動くことは多いですが、ツール利用がプロンプト依存になりやすく、汎化しにくいです。
なぜこの課題を解く必要があるかというと、実際の AI システムでは「言語生成のうまさ」だけでなく、「外部世界に正しくアクセスできるか」が重要だからです。社内ナレッジ検索、ワークフロー自動化、スケジュール計算、コード支援、問い合わせ対応などでは、モデルが全部を暗記している前提は成り立ちません。ツール利用を学習で扱えるようにしておくと、エージェントをプロンプト頼みでなく、より安定した振る舞いに近づけられます。
用語解説
- 自己教師あり学習
- 人手ラベルを大量に用意せず、元データやモデル自身の出力を使って学習信号を作る方法です。Toolformer では「API を呼んだ結果が将来トークン予測に役立つか」を使って学習データを自動生成するため、この考え方が中核になります。
- API 呼び出し
- 外部ツールを関数のように呼ぶ操作です。Toolformer では `QA(...)` や `Calculator(...)` のような文字列として文中に埋め込み、返り値もテキストとして扱います。つまりツール利用を特別な制御信号ではなく、言語列の一部として学習しています。
- Perplexity / 損失
- モデルが次トークンをどれだけうまく予測できたかを見る指標です。Toolformer は API 呼び出し候補を「予測損失を本当に下げるか」で選別します。ここが単なるデモ模倣ではなく、役に立つ呼び出しだけを残す仕組みになっています。
- In-Context Learning
- モデルに少数例を見せ、その場で出力パターンを真似させる使い方です。Toolformer では最初の候補生成にだけこの能力を使い、その後は生成した呼び出しを学習データ化します。つまり最終的にはプロンプト芸に閉じず、重み側へ能力を移しているのが重要です。
- Zero-shot 評価
- 対象タスク専用の追加学習をせずに解かせる評価です。Toolformer はツール利用を学んだ結果、外部ツールの助けを使いながら未知タスクでも性能を上げられるかを検証しています。
技術の仕組み
Toolformer の技術的な核は、API 呼び出しデータを自動生成し、その中から本当に役立つものだけを残してモデルを再学習する流れにあります。論文の価値は、ツール利用を推論時の小手先ではなく、学習パイプラインとして定式化した点です。
基本アイデア
やっていることは大きく 3 段階です。まず、通常のテキストコーパスに対して「ここで API を呼ぶとしたら何を呼ぶか」をモデルにサンプリングさせます。次に、その API を実行して返り値を得ます。最後に、その返り値を入れたときに将来トークンの予測が良くなる呼び出しだけを残し、その拡張コーパスでモデルを fine-tuning します。
この設計の良い点は、ツール利用が役立つかどうかを、モデルの本業である next-token prediction に引き戻して判定していることです。人間が「これは良い API 呼び出しだ」とラベルするのではなく、予測性能改善という形で自動判定します。
ツールの表現方法
論文では API 呼び出しを、テキスト列の中に埋め込める線形化表現として扱います。たとえば QA(question) や Calculator(expression) のような形です。返り値があれば QA(question) -> result のように結果まで含めたトークン列になります。
重要なのは、モデルが特別な外部実行エンジンの中間表現を覚えるのではなく、ツール利用を言語列の一部として読むことです。これにより、既存の自己回帰 LM を大きく作り変えずに学習できます。
API 呼び出し候補の生成
著者らは、各ツールごとに少数のデモを含むプロンプトを用意し、元の言語モデルに「どこで呼び出せそうか」をサンプリングさせます。たとえば QA ツールなら、文中の事実参照部分に対して質問文を挿入するような候補を作ります。
ここでのポイントは、最初から正解データを持っていないことです。モデルは候補をかなり雑に出します。そのため、この段階の生成だけでは品質は保証されません。後段のフィルタが本体です。
API 実行と損失ベースのフィルタ
候補ができたら、実際にその API を叩いて返り値を取得します。そのうえで、API 呼び出し結果を文脈に入れた場合と、入れない場合で、後続トークンの損失を比較します。
もし API の返り値を使ったほうが将来の予測が明らかに楽になるなら、その呼び出しは有益だとみなします。逆に、役に立たない呼び出しや、文脈にノイズを足すだけの呼び出しは落とします。
この損失ベースフィルタが、Toolformer の一番面白い工夫です。ツール利用を「人間っぽく見えるか」ではなく、「言語モデルとして本当に役立つか」で選んでいるからです。
学習データの再構築
フィルタ後の API 呼び出しを元テキストへマージして、ツール使用済みの拡張コーパスを作ります。このコーパスには、計算機、質問応答、検索、翻訳、カレンダーのような複数ツールの呼び出し例が混ざります。
その後、ベースモデルをこの拡張データで fine-tuning します。するとモデルは、単に API の構文を真似るだけでなく、「こういう文脈ではこのツールが有効だった」という分布的パターンを重みの中に取り込みます。
推論時の流れ
推論時は、モデルが通常の生成をしながら、必要だと判断した箇所で API トークンを出します。システム側はそれを検知して API を実行し、返り値を文脈へ挿入して続きを生成させます。
現在の function calling とかなり近い見た目ですが、発想は少し違います。function calling は多くの場合「呼べる関数一覧」と「正しい JSON を出すこと」に強く依存します。Toolformer はそこに至る前段として、そもそもツールが必要な局面を学習している点が本質です。
重要な工夫
重要な工夫は 2 つあります。1 つ目は、候補生成を few-shot プロンプトで始めつつ、最終的な判断は損失改善で行うことです。これにより、人手デモを増やさなくてもデータを増幅できます。2 つ目は、元の pretraining に近い一般コーパス上で学習することで、ツール利用能力を特定タスク専用に閉じないことです。論文でも、API 呼び出しを無効化した状態の perplexity は悪化しておらず、一般言語能力を大きく壊していないことが確認されています。
実験と結果
論文では、Toolformer が本当にツールを適切に使えるか、ツールを使わなくても言語能力を壊していないか、どの程度のモデルサイズでこの能力が出始めるかを検証しています。
何を検証したのか
主な検証は 4 つあります。1 つ目は、知識穴埋めや算数のように、ツールが効きそうなタスクで性能が上がるか。2 つ目は、QA や日付推論でも効くか。3 つ目は、ツール学習で通常の言語モデリング能力が落ちないか。4 つ目は、小さすぎるモデルでも同じようにツールを使えるのか、という点です。
どんなデータセットや評価指標を使ったのか
知識系では LAMA の SQuAD、Google-RE、T-REx サブセットを使っています。算数系では ASDiv、SVAMP、MAWPS を使っています。QA 系では WebQuestions、Natural Questions、TriviaQA、時間推論では TEMPLAMA と DATESET を使っています。
評価は厳密な完全一致ではなく、zero-shot であることを踏まえた比較的ゆるい基準です。たとえば LAMA では正解語が先頭 5 語以内に含まれるか、算数では最初に出した数値が正しいか、QA では最初の 20 語以内に正答が入るか、という形です。実務上の観点では、厳密な形式一致よりも「必要な外部ツールを使って正答に近づけるか」を見る評価だと考えるとわかりやすいです。
LAMA と算数で大きく改善
LAMA の結果では、Toolformer は GPT-J ベースの比較群を大きく上回っています。たとえば SQuAD サブセットでは GPT-J が 17.8、通常コーパス追加学習の GPT-J + CC が 19.2、API 無効化時の Toolformer が 22.1 に対し、API 有効化の Toolformer は 33.8 でした。T-REx でも 31.9 から 53.5 へ伸びています。
算数では差がさらに大きく、ASDiv で 7.5 から 40.4、SVAMP で 5.2 から 29.4、MAWPS で 9.9 から 44.0 まで改善しています。論文では、算数タスクの 97.9% でモデルが calculator を選んだと報告しています。つまり、計算を内部知識で近似するのではなく、外部ツールへ切り出したことがそのまま効いています。
大きいモデルより勝つ場面がある
面白いのは、Toolformer が 6.7B の GPT-J ベースでありながら、66B の OPT や 175B の GPT-3 を超える場面があることです。たとえば ASDiv では GPT-3 が 14.0 のところ Toolformer は 40.4、MAWPS では GPT-3 の 19.8 に対して Toolformer は 44.0 でした。
ここから言えるのは、「モデルを大きくする」ことと「正しいタイミングで外部ツールを使う」ことは別の軸だということです。計算や検索のように外部ツールが明確に勝つ処理では、ツール利用能力のほうがパラメータ数より効く場面があります。
QA と時間推論でも改善
質問応答では、QA ツールを使うとタスク自体が簡単になりすぎるため、論文では一部評価でそのツールを無効化しています。それでも Toolformer は WebQuestions で 26.3、Natural Questions で 17.7、TriviaQA で 48.8 を出し、多くのベースラインを上回っています。
時間推論でも、TEMPLAMA で 16.3、DATESET で 27.3 と、ベースモデル群より良い値を出しています。特に DATESET はランダムな日付計算タスクなので、カレンダーや計算的補助を活用する設計の価値が見えやすいです。
言語モデルとしての能力は壊していない
ツール学習でありがちな懸念は、「ツールを使うことばかり覚えて、普通の言語生成が壊れないか」です。この論文では WikiText と未使用 CCNet サンプルで perplexity を見ており、API 無効化時でも通常追加学習と大きな差が出ていません。少なくともこの設定では、一般言語能力を大きく犠牲にせずツール利用を足せることを示しています。
小さいモデルでは効きにくい
スケーリング実験では、GPT-2 系の 124M、355M、775M、1.6B も試しています。結果として、十分なツール利用能力がはっきり出るのは概ね 7.75 億パラメータ付近からでした。論文のメッセージは明確で、小さいモデルに同じ仕組みを載せても、ツールを有効に使う判断まで学ぶのは難しいということです。
何に使える？
Toolformer の考え方は、いまのエージェント設計や業務自動化にかなり直接的に使えます。特に「どのタイミングで外部機能を呼ぶか」をプロンプトで固定したくない場面で有効です。
社内エージェントのツール選択
社内ナレッジ検索、勤怠確認、経費確認、チケット参照、顧客情報検索のように複数 API がある環境では、毎回ルールベースで分岐を書くと保守が重くなります。Toolformer 的な発想を使うと、ツール利用ログを学習データ化し、「この問い合わせではどの社内 API を呼ぶと回答品質が上がるか」をモデルに寄せられます。
数値処理を含む業務自動化
請求金額の集計、在庫差分計算、日付計算、SLA 判定のような処理は、LLM に説明文を書かせるだけならともかく、数値部分を内部推論に任せると危険です。Toolformer の設計は、こうした箇所だけを calculator や業務ロジック API へ逃がす考え方として使えます。生成は LLM、正確な計算は関数、という責務分離がしやすいです。
RAG と検索の前後処理
RAG では「検索が必要か」「検索クエリをどう作るか」が重要です。Toolformer は検索ツールを文脈中で選ぶ学習をしているため、検索を毎回固定で実行するよりも、必要なときだけ呼ぶ設計の参考になります。たとえば問い合わせ文によっては検索せず内部知識だけで返し、製品名や仕様番号が出たときだけ検索 API を使う、といった動的制御に応用できます。
開発支援ツールやコードエージェント
コード生成やデバッグ支援でも、LLM がすべてを直接生成するより、ドキュメント検索、型情報参照、テスト実行、静的解析の結果を取り込んだほうが良い場面が多いです。Toolformer の技術自体はコード専用ではありませんが、「返り値が後続生成の損失を下げるツールを学習的に選ぶ」という発想は、コードエージェントの道具選びにもそのままつながります。
開発や事業へのヒント
この論文から得られるヒントは、エージェントの価値を上げる本質は、プロンプトにツール一覧を書くことではなく、「どの場面で呼ぶと得か」をデータ化することだという点です。
ツール利用ログは学習資産になる
自分で AI アプリを作るなら、function calling の成功失敗ログを単なる監視情報で終わらせず、学習データ候補として扱う価値があります。どの問い合わせで何のツールを呼んだか、返り値のあとに回答品質がどう変わったかを取っておけば、Toolformer 的な自己改善ループに近づけます。
ルールベース分岐を減らせる
既存サービスでは、問い合わせ分類器とツール分岐ロジックを手で増やしていくと、すぐに複雑化します。Toolformer の考え方を使うと、固定ルールを少なくして、モデルが「その API を呼ぶと先の生成が楽になるか」で判断する方向へ寄せられます。完全自動にする必要はなくても、優先順位付けの補助として十分使えます。
小規模プロダクトでも部分適用しやすい
論文そのものを完全再現するのは重いですが、考え方は小規模でも使えます。たとえば 2 から 3 個の内部 API だけを対象にし、few-shot で候補を作り、返り値が回答評価を改善した例だけを蓄積する、といった運用は十分現実的です。特に B2B SaaS のように問い合わせパターンが比較的安定している領域では、少数ツールでも効果が出やすいはずです。
今後注目すべき方向性
今後は、1 回のツール呼び出しだけでなく、複数ツールの連鎖、失敗時の再試行、返り値の検証まで含めた学習が重要になりそうです。これは論文の範囲を超える推測ですが、現在のエージェントが苦手な「正しい順序で複数ツールを扱う」問題に対して、Toolformer は出発点としてかなり重要です。
限界
Toolformer にも明確な限界があります。まず、論文でも認めている通り、複数ツールを連鎖させる使い方は扱えていません。各ツールの呼び出し候補を独立に生成しているため、あるツールの出力を次のツールの入力にするようなチェーン利用は学習データに入りにくいです。
次に、サンプル効率の問題があります。大量コーパスを処理しても、本当に有益な API 呼び出し例はそこまで多く残りません。論文でも、ツールによっては 100 万件以上の文書を処理しても数千件規模の有効例しか得られないと述べています。つまり、雑に回すだけでは学習データ効率が良くありません。
また、ツールごとに少数デモ用プロンプトや閾値設計が必要で、完全に手離れしているわけではありません。どの API がどんな入力形式かを最低限教える必要があり、返り値の品質が悪いツールでは学習全体が不安定になります。
実運用では、外部 API の遅延、失敗、権限制御、監査ログ、コストも問題になります。論文はツール利用の学習に主眼があり、プロダクション向けのリトライ戦略や権限分離までは扱っていません。したがって、そのまま製品に入れるより、学習思想を設計原則として取り込むのが現実的です。
よくある質問
Q. Toolformer は今の function calling と何が違うのですか？
A. function calling は主に推論時の出力形式とツール接続の仕組みです。Toolformer は、その前段で「そもそもいつツールを呼ぶべきか」を自己教師ありで学習する点が違います。実装上は近く見えても、学習の考え方が異なります。
Q. Toolformer は RAG の代わりになりますか？
A. 代わりというより補完です。RAG は主に検索して文脈を渡す仕組みですが、Toolformer は検索を含む外部ツールの呼び出し判断を学ぶ技術です。検索 API を道具の 1 つとして扱う設計なので、RAG の前段制御に近い位置で効きます。
Q. 小さいモデルでも同じように使えますか？
A. 論文の結果では、小さいモデルではツール利用の恩恵がかなり限定的です。ツールを正しく呼ぶには、文脈理解、引数生成、返り値の利用まで必要なので、ある程度のモデル能力が前提になります。
Q. すべての業務 API にこのまま適用できますか？
A. そのままは難しいです。入力形式が複雑な API、厳密な認可が必要な API、複数ステップ前提の API では、追加の設計が必要です。ただし「有益な呼び出しだけを残して学習する」という考え方自体は応用できます。
Q. いま開発するなら、論文をそのまま再現すべきですか？
A. 多くの現場では完全再現より、ログ設計と部分適用から始めるほうが現実的です。function calling のログ、検索ヒット率、回答改善の有無を計測し、役立つ呼び出しパターンを蓄積するだけでも Toolformer 的な価値を取り込めます。
今日の学び
この論文は、LLM が計算や検索のような外部能力を必要とする場面で、毎回人手でツール利用を教え続けなければいけない課題を扱いました。そこに対して Toolformer は、API 呼び出し候補を自動生成し、将来トークンの予測損失を本当に下げる呼び出しだけを残して学習する方法を提案しました。
ここから得られるヒントは、エージェント開発で重要なのはツール一覧を増やすことより、「どの呼び出しが本当に役立ったか」を学習可能な形で残すことだという点です。ツール利用ログを資産として扱えるようになると、AI アプリはプロンプト依存から少しずつ抜け出せます。