LLM-jp-4.1はどのようにツール呼び出しを学んだか：データ加工とチャットテンプレート改造の実際

LLM-jpとLLM-jp-4.1の位置づけ

LLM勉強会(LLM-jp)は、オープンで日本語に強い大規模言語モデルを構築し、その原理の解明に取り組んでいる。モデル、データ、ツール、技術に加えて、議論の過程まで含めてすべて公開することを理念にしている。Wu氏によれば、これはいわゆるオープンウェイトのモデルに近いが、作り方やデータまで公開しており、透明性の高い開発になっている。開発の中心を担うのがLLMCで、Wu氏もLLMCに在籍してLLM-jpモデルの開発に関わっている。

開発のタイムラインでは、2026年4月にLLM-jp-4が公開された。テキストのLLMとは別に、画像を読み取れるVLMの開発も前年から進めており、発表の前月に正式版がリリースされた。

さらに発表の前週には、LLM-jp-4.1が公開された。前バージョンとの主な違いは次の3点である。

数学や物理などSTEM分野の強化
ツール呼び出しへの対応
回答の簡潔化

今回の発表は、このうちツール呼び出しに焦点を当てている。

2:58

ツール呼び出しとは何か

Wu氏は、LLMは基本的に文字列を生成することしかできない、という点から説明を始めた。たとえば「明日渋谷に出かけるが、傘を持っていった方がいいか」と聞かれた場合、人間ならネットで調べられる。しかし素のLLMにはそれができないため、「申し訳ありません、分かりません」といった回答しか返せない。一方、ClaudeやChatGPTは実際にネットで調べ、さまざまなツールを使って情報を取ってくる。それを裏で実現しているのがツール呼び出しという技術だという。

仕組みはこうだ。まずLLMの入力に、質問と一緒にツールの使い方の説明を入れる。たとえば「指定した場所と日付の天気を調べるget_weatherというツールがある」と記述しておく。するとLLMはこの関数を呼び出す内容を文字列として出力する。出力が正しいフォーマットになっていれば、外部の仕組みがそれを読み取って関数を実行し、天気の情報を取ってくる。その結果、たとえば「天気は雨、降水確率80%」が、自動的にLLMの入力コンテキストへ戻される。LLMはこの文字列を読み、「明日の渋谷は降水確率が80%なので傘を持っていきましょう」と答える。

Wu氏が強調したのは、この過程でLLM自身は最初から最後まで文字列を読み取り、文字列を出力しているだけだという点である。ツールを実際に実行するのはすべて外部の仕組みだ。それでもこの設計によって、LLMは実質的に外部ツールを使いこなせるようになる。ClaudeのWeb検索も、裏ではこのツール呼び出しで動いていると紹介された。

6:35

性能：Qwen3と同水準、Qwen3.5にはまだ届かない

LLM-jp-4.1は、LLM-jpとして初めてツール呼び出しに対応したバージョンである。Wu氏によれば、BFCLやτ²-benchといったツール呼び出しのベンチマークで、Qwen3とほぼ同水準の性能が出ている。第三者による評価でも、英語版BFCLではQwen3をわずかに上回るスコアだったという。

一方で、Qwen3.5のようなより強力なモデルには「全然」及ばないとWu氏は認めた。いずれQwen3.5と同程度のスコアに到達することを当面の努力目標として、開発を続けているという。

7:31

課題1：Nemotronデータの選別、翻訳、失敗ターンへのラベル付け

開発中に直面した課題のうち、Wu氏は特に興味深かったものを2つ紹介した。1つ目は学習データの工夫である。

LLM-jp-4.1では、NVIDIAが公開しているNemotronのデータセットを学習データに使っている。ただし、そのまま使えばよいわけではなく、裏ではさまざまな処理が必要だったという。

まず難しいデータを優先的に選んだ。データ中のツール呼び出し回数の分布を見ると、呼び出しが5段以上続くデータは非常に少なかった。そこで、こうした長く難しいデータをなるべく優先して抽出し、学習に使った。この難しいデータは元データの約3.5%にすぎなかったという。

次に日本語への翻訳である。LLM-jpは日本語の性能を重視しているが、Nemotronのデータは英語だった。そのため日本語に翻訳したデータも学習に加えた。

3つ目が、失敗したターンへのラベル付けだ。実際のデータを見ると、途中のターンでモデルが誤った呼び出しをしてエラーが返ってくる例がある。こうした誤ったツール呼び出しは学習させたくない。一方で、エラーから立て直す方法は学習させたい。そこでエラーを含むターンは入力としては残し、学習の目標からは除外する必要がある。ところが、どのターンでエラーが起きているかという情報は元のデータセットに含まれていない。そのためチームが自らラベルを付与した。Wu氏はこれもデータエンジニアリング上の工夫の一つだと説明した。

10:26

課題2：Harmonyテンプレートでは並列呼び出しができない

2つ目の課題は、ツール呼び出しのフォーマット、つまりモデルと外部の仕組みの間の「約束」の設計である。Wu氏によれば、この設計はかなり難しい。

このフォーマットはチャットテンプレートと呼ばれる。モデルは学習中にこのテンプレートを覚えることで、推論時に次に取る行動を正しく表現できるようになる。前述の外部の仕組みも、このチャットテンプレートの定義に基づいてモデルの出力をパースしている。

LLM-jp-4は、OpenAIが開発したHarmonyというテンプレートを採用している。通常の出力より構造化された形式である。当初は既存のテンプレートを使えばエンジニアリングの労力を大幅に減らせると考えていた。しかし実際には「全然そういうことがなくて」、うまくいかない点が多かったという。

具体的な問題として挙げられたのが、BFCLの一部カテゴリーで評価ができなくなることだ。Harmonyテンプレートは、2〜3個の関数を一度に呼ぶ並列ツール呼び出しを表現できない。そのため、Harmonyを使っているとBFCLの4つのカテゴリーで評価ができない。Wu氏によれば、これはLLM-jpに限らず他のHarmony利用者もGitHubで報告している問題である。しかしOpenAIは対応しなかったため、自分たちでHarmonyを改造する必要があった。

改造の内容はこうだ。Harmonyのツール呼び出しは、「call」トークンで終わる決まりになっている。これを拡張し、「end」トークンで終わることも許容するようにした。これにより並列ツール呼び出しが可能になったという。

13:35

ツール呼び出しの先にあるもの：研究の自動化

Wu氏は、ツール呼び出しそのものが目的ではないと述べた。本当の目的は、LLMがさまざまなツールを使いこなし、実世界のタスクをこなせるようにすることだという。LLM-jp-4.1はツール呼び出しがある程度できるようになったものの、高度なケースにはまだ届いていない。今後の努力の方向としては検索やコーディングなど多くの候補がある。そのうえで今回は、LLMエージェントによる研究の自動化の事例を3つ紹介した。

1つ目は、AIエージェントのための学会「Agents4Science 2025」である。スタンフォード大学の研究者が主催し、2025年10月にオンラインで開催された。投稿論文はすべてAIを著者にする必要がある。人間の研究者はAIエージェントを開発し、そのエージェントが作った論文を投稿する。査読の第一段階もAIエージェントが担い、その後、上位の論文を人間の査読者が評価した。投稿論文のうち48本が採択され、LLMCからも2本ほど採択されたという。

2つ目は、日本のスタートアップSakana AIが開発した研究用エージェントシステム「AI Scientist」である。研究論文をエンドツーエンドで作成できるシステムで、生成した論文が機械学習のトップ国際会議ICLR 2025のワークショップで、人間による査読の第一段階を通過した。この成果は2026年3月にNatureに掲載され、当時大きな話題になったとWu氏は紹介した。

3つ目は、Anthropicが2026年6月に公開した研究者向けAIワークベンチ(発表では「Claude Science」と紹介)である。研究者向けに作られたツールで、文献調査やコードの実行などを支援する。すべての結果がどのように作られたかを記録として残せる点が特徴として挙げられた。Wu氏は、こうした研究者向けのAI応用は今後も多く出てくるだろうとの見方を示した。

16:49

結び：実用レベルに向けて

最後にWu氏は、LLM-jp-4.1で追加したツール呼び出し機能は、こうしたエージェントを実現するための第一歩だとまとめた。最先端のモデルや米国のモデルと比べれば、まだ改善すべき点が多い。それでも近い将来に実用レベルのモデルを提供できるよう、引き続き取り組むと述べて発表を締めくくった。