はじめに
ジョブカン事業部のアドベントカレンダー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の一環で作成されました。
弊社では新卒・中途・インターン等の採用を行っています。