はじめに

ジョブカン事業部のアドベントカレンダー18日目です！

ジョブカン開発グループ、インターンの@jptl_3です。
情報系学部の4年生で、研究では大規模言語モデル(以下LLM)の性能測定や、マルチエージェントモデルの開発に取り組んでいます。

近年、弊社アドベントカレンダー12/9に投稿された記事: Cursor & GitHub Copilot でコードレビュー楽していこうぜの様に、生成AIを用いて開発体験向上を目指す試みが増えているなと感じます。

プライベートな開発でもLLMを導入し、研究用のソースコードや大学の雑務を代行するツールを開発していきたいところですが、学生のお財布で従量課金制のAPIを叩くには限界がありました。そこで一時期、「オープンソースLLMをローカル環境で実行できないか？」ということに取り組んでいました。

しかし、コンシューマー向けのGPUで動作するLLMのパラメーター数は~20Bと小さいため、複雑なタスクを実行しようとすると無限推論ループに入ってしまい、実用的とはいい難い性能でした。

やはり、ローカルLLMを用いた開発は無謀なのか？と考えていた時...

Tool Orchestraモデルの概要

11/27、nvidia/Nemotron-Orchestrator-8Bというモデルが公開されました。
本モデルは、外部のLLMやツールを利用しながら課題を解く、言わば「半ローカル、半クラウド型LLMシステム」という立ち位置です。

ToolOrchestra: Elevating Intelligence via EfficientModel and Tool Orchestrationによると、ツール呼び出し可能な環境で課題を解くベンチマークで、「GPT5以上の正答率」と「APIの使用料金を3割程度に収める」の2つを達成しました。

ローカルモデル信者の私としては、クラウド型LLMの助けを借りているとはいえ、GPT5以上の精度を叩き出したことに興奮を覚えました！

システムアーキテクチャ

外部ツールを利用しながら課題を解くと聞くと、AIエージェントをイメージします。
Tool Orchestraと何が違うのでしょうか。

初めに、Tool Orchestraのシステムアーキテクチャを以下に示します。

単語の定義は次の通り

tool群: web検索, python実行環境
特化モデル: 数学やコーディングに特化した専門家モデル
汎用モデル: GPT-5やClaudeなどのAPI経由で呼び出す大規模モデル

次に、AIエージェントの基本的なアーキテクチャを以下に示します。

両者を比較すると、汎用モデルの立ち位置が違います。
従来のAIエージェントでは、ChatGPTなどの賢いモデル(汎用モデル)が推論を行い、必要な知識を外部ツールが補うという構成を取っています。
対して、Tool Orchestraアーキテクチャでは、Nemotron-Orchestrator-8Bという小さなモデルがシステムの中心に位置しており、賢いモデルはその下についています。

通常、サイズの小さなモデルは推論能力で劣るため、成果物の品質も低くなります。
したがって、システムの中心に据えることは良くないことです。
しかし、Nemotron-Orchestrator-8Bは「課題を切り出し、外部ツールに依頼する」能力が高くなるようなチューニングを施されています。

例えるなら、AIエージェントは優秀なプレイヤーが業務の大半をこなすことに対し、Tool Orchestraは優秀なマネージャーが仕事を適切に割り振っていくイメージです。
尚且つ、マネージャーは自社の社員(ローカル環境で動作する)のため、1~10まで外注するより安く済むというロジックです。

学習方法

Nemotron-Orchestrator-8Bは「課題を切り出し、外部ツールに依頼する」能力を強化学習を用いて向上させています。強化学習とは行動の良し悪しを「報酬」という形で定義し、AIが試行錯誤の中で正答に近づくような行動を探します。将棋AIのAlphaZeroなどで使われている手法です。本研究では、GRPOというdeepseek_mathで注目された手法を用いています。
細かい解説は他記事に譲ります。

学習データはどう集めたの？

強化学習を行うためには「タスク」と「正誤判定」の2点が必要です。
今回の「タスク」はLLMやツールを駆使して複雑な課題を解くことで、このような既存データはめったにありません。また、LLMが呼び出すツールを1つ1つ手作業で実装することは大変骨が折れる作業です。

本論文ではこれらの問題を「LLMに作らせる」ことで解決しています。

以下、学習環境の作成方法です。

「金融・スポーツ・ネットショッピング」などのテーマを用意する
与えられたテーマをもとに、LLMがデータベースとツールを使える仮想環境を作成する
作成した環境におけるタスクと正誤判定の基準を作成する

また、タスク遂行可否の判断基準として以下3点が用いられました。

必要な関数が呼び出されているか
必要な情報に言及しているか
データベースはタスク完了後の状態になっているか

作成したデータをGeneralThought-430Kと混ぜ合わせてQwen3-8Bに学習させることで、Nemotron-Orchestrator-8Bは開発されました。

感想

本論文を読んで個人的に衝撃を受けたこと

ローカルLLM - クラウドLLM型アーキテクチャの提案
API利用料金が3割になるならローカルLLM始めたいという人は結構いそう。
自分が良く使うフレームワーク関連のコーディングツールを備えたOrchestrationモデルが登場したら使ってみたい。
バイブコーディングによる学習環境の提案
LLMだけで高品質なデータセットと仮想的な環境を用意できるのであれば、手作業でのデータ成形を行う必要がなくなる分野がありそう。

個人的に気になること

ツールの追加削除は可能なのか？
「GitHubのwikiを追加したい」や「数学LLMは使わないから削る」などの変更にどの程度対応できるのだろうか。
その場合、Tool Orchestratorモデルを再学習する必要はあるのか。
完全ローカル型Tool Orchestraは可能なのか？
GPT5の代替としてgpt-oss 20bを使った場合どの程度精度が低下するのだろうか。
あまり精度が変わらない場合自宅PCでAIシステムが完結するかも？

2025/12/09現在、hugging face上に"This model is for research and development only"という記述があります。本記事はモデルの利用を促す目的はなく、利用時は各自ライセンスをご確認ください。

弊社情報

本記事はジョブカン Advent Calendar 2025の一環で作成されました。
弊社では新卒・中途・インターン等の採用を行っています。