昨今自律的な行動をとることのできるエージェントが流行っていますが，これらはLLMに外部環境との作用が可能なツールを持たせたものとみなすことができます．なのでAgentが適切に行動するにはWeb検索や書類作成等のツールを適切に利用することが必須であり，そのためには正しい指示（ツールのマニュアル）やロバストなツール設計（MCPといったプロトコル化）が重要になります．
そうしたなか，ツールの利用方法を推論時にコンテキストで渡すのでなく，事後学習のタイミングであらかじめ教える「Tool/Agentic Reinforcement Learning」（以後 Agentic RL）が注目されています．LLMの従来の事後学習が対話能力を獲得するInstruction Tuningや人間との出力傾向をアラインするRLHFであったことに対して，Agentic RLではLLMに特定環境下にて自由に行動をしてもらい，そこからツール利用をはじめとしたタスク特化の能力を獲得します．Agentic RLは2025年後半以降LLMの学習スタックには欠かせないステップとなっており，GPT，Claude等のフロンティアモデルはもちろん，KimiやQwen等のオープンモデルにおいても事後学習プロセスに組み込まれています．
しかしこれらのモデルはあくまでも汎用的なAgent/Tool行動を学ぶものであり，Instruction TuningやAlignmentがそうであったように，下流にいるモデルの使い手がより細かなタスクに特化するよう追加の事後学習を用いることで真価を発揮します．例えば今回のタスクでは，検索ツールがAND条件で動作するため，キーワードを絞って検索する必要がありますが，フロンティアモデルは汎用的な検索戦略しか持たないため大量のキーワードを投げてヒット0件を繰り返します．システムプロンプトで「AND検索です」と明示すれば一定の改善は見込めますが，それ以上に暗黙的な知識――そのメールボックス特有の語彙や構造，効率的な絞り込みパターン――はプロンプトでは伝えきれません．Agentic RLは，こうした形式知化の難しい暗黙知を試行錯誤を通じて直接モデルの重みに落とし込める点に強みがあります．
特に我々が可能性を感じたのは下記の点です：
- コストパフォーマンス: 日々賢くなっているGPTやClaudeですが，逆にいうと小さなローカルモデルでもできるタスクの幅が急速に広がっています．常に最新の強いモデルを使うのではなく，適材適所としてタスクに合わせた軽量モデルを都度利用することでコスパが上げられると考えています．
- 暗黙的な構造の理解: AlphaGoが人の思いつかない手を指すように，強化学習は人が言語化のできない（つまりプロンプト等で与えられない）データやタスクに潜む暗黙的なルールを見出す能力を秘めています．
- レッドオーシャンのど真ん中: Tool RL/Agentic RLは日本ではまだ馴染みのない手法ではありますが，米国ではこの技術を礎としたスタートアップ企業が続々と輩出されています．今この技術をキャッチアップすることは刺激に溢れてシンプルに楽しいと感じました．
しかし我々も単なるキャッチアップで済ませるつもりはありません．現在我々はこのAgentic RLを手の内化すべく社内で技術検証を実施しています．今回の取り組みの目標は明快で，ある特定のタスクにおいてフロンティアモデルと同精度あるいはそれを超える軽量モデルを自社で学習・推論することです．
本記事では，この目標を達成するための学習基盤としてPrime Intellect Labを紹介し，我々のメール検索タスク「EnronHop」をケーススタディとして，環境の構築から学習の実行までの流れを解説します．
結論を先に書くと，4BパラメータのQwen3がFull Fine-Tuningで55.4%，Prime LabのLoRA学習で47.7%に到達し，いずれもGPT-5-mini（40.0%）を上回りました．さらにMoEモデル（30B-A3B）では62.1%に到達しています．（ちなみにこのタスクではGPT-5は37.0%でした）
1. Agentic RLの要素とPrime Intellect Lab
Agentic RLを実施する上では前述のツールに加えて幾つかの要素が必要になります：
- 学習モデル: 学習対象となるLLM
- 学習環境: モデルが自由にツールを使えるタスクの実行環境
- 学習手法: エージェントが環境下で得た知識を反映させるためのモデル重み更新手法
- 学習リソース: GPU等の計算資源
Agentic RLは従来の学習データを渡すだけの手法と異なり，自律的行動からのマルチターン学習であるため考慮しなければならない点が増え複雑に見えます．今回は上記の要素を全て単一サービス内に内包したPrime Intellect Labを紹介します．
Prime Intellect LabはTool RLに特化したOpinionatedなオープンソースのTraining as a Serviceであり，使いやすいことはもちろん，デザインチョイスが非常に勉強になるのが利点です．なおPrime IntellectはGPUメタクラウド（H100，A100，RTX 4090）も提供しており，Lab自体がそのインフラ上で動作しています．
1.1 Prime Labの構成
Prime Labは以下の3つの柱で構成されています：
- Environments Hub: Tool RL時代のHugging Faceを目指す学習環境のハブ
- Hosted Training: マネージドGPUインフラによるRL学習．ハードウェアのセットアップは一切不要
- Hosted Evaluations: 標準化されたモデル評価
Environments Hub
Agentic RLにはモデルが自由に動ける環境が不可欠ですが，Environments Hubはこの環境を後述のverifiersを通じて抽象化・ポータブルにすることで，誰もが自分の作った強化学習環境を共有し他者に使ってもらえるハブを実現しています．かつてHugging Faceがデータセットのハブを作ったように，今度は環境のハブが生まれた形です．
利用者は公開されている環境をそのまま使うことも，自分好みにカスタマイズすることも，新しく作って共有することもできます．
いくつかタイプがあって，用途ごとに使い分ける形になります：
| タイプ | 用途 |
|---|---|
SingleTurnEnv |
1ターンで完結するタスク |
MultiTurnEnv |
ツールなしのマルチターン |
ToolEnv |
マルチターン + ツール利用（今回はこれ） |
StatefulToolEnv |
状態を保持するToolEnv |
MCPEnv |
Model Context Protocol環境 |
例えば，有名な数学の問題ベンチマークであるAIMEシリーズ，MLE-benchなどのコードベンチマークなども環境として公開されています．
中身は評価アルゴリズムを示したpythonファイルや問題セットを示したjsonlファイルなどで構成されており，環境ごとに一定異なります．環境の定義や依存関係などはuvでお馴染みのTOMLファイルで記述する形になります．
verifiers: 環境構築ライブラリ
Environments Hub上の環境は，Prime Intellectが開発しているverifiersというオープンソースライブラリで構築されています．
verifiersの設計思想は，報酬を静的な関数ではなくエージェントと環境の相互作用の結果として定義する点にあります．従来のtrl（HuggingFace）では f(output) → scalar という関数型の報酬が基本でしたが，verifiersではエージェントが環境内でツールを使いながらタスクを遂行し，その結果として報酬が決まる agent ↔ environment → reward の形をとります．
コアのパターンは Dataset + Harness + Rubric = Environment です：
- Dataset: 学習に使う問題セット（質問と正解のペア等）
- Harness: エージェントの実行環境とツール呼び出しの管理機構
- Rubric: 報酬関数のコンテナ（複数の報酬関数を重み付きで合成可能）
環境はPythonパッケージ（wheel）としてビルドされ，Environments Hubを通じて共有・配布されます．エントリーポイントとなる load_environment() 関数については3.2節で詳述します．
Agentic RLでは，エージェントがツールを呼び出しながらタスクを解く必要があるため，ToolEnvタイプがメインの選択肢になります．ToolEnvは会話ループ・ツール呼び出し・報酬計算を一括管理してくれるため，開発者はツールの実装と報酬関数の定義に集中できます．
なお，verifiersではコード実行やツール呼び出しの安全性を担保するためにSandbox（使い捨てDockerコンテナ）が提供されています．SandboxEnv（コンテナ化bashシェル）とPythonEnv（永続Python REPL）の2種類があり，ネットワークアクセスの無効化やリソース制限（CPU・RAM・ディスク・GPU割り当て）を細かく指定できます．今回のToolEnvではSandboxを直接使いませんが，コード生成タスク等ではSandbox内でエージェントのコードを安全に実行しながら学習を回すことが可能です．
1.2 対応モデル（2026年3月時点，抜粋）
| モデル | パラメータ | アーキテクチャ | 備考 |
|---|---|---|---|
| Qwen/Qwen3-4B-Instruct-2507 | 4B | Dense | 今回使用．検証用に推奨 |
| Qwen/Qwen3-4B-Thinking-2507 | 4B | Dense | Thinkingモード |
| Qwen/Qwen3-30B-A3B-Instruct-2507 | 30B (3B active) | MoE | 今回使用．実験用に推奨 |
| Qwen/Qwen3-30B-A3B-Thinking-2507 | 30B (3B active) | MoE | Thinking variant |
| Qwen/Qwen3.5-4B / 9B / 35B-A3B / 397B-A17B | 4B〜397B | — | |
| Qwen/Qwen3-VL-4B / 8B-Instruct | — | — | Vision-Language |
| PrimeIntellect/MiniMax-M2.5-bf16 | 230B (10B active) | MoE | コーディング・エージェント向け |
| zai-org/GLM-4.7 | — | — | |
| nvidia/OpenReasoning-Nemotron-7B | — | — | |
| HuggingFaceTB/SmolLM3-3B | — | — | |
| arcee-ai/Trinity-Mini / Nano-Preview | — | — |
1.3 アーキテクチャ
Labの内部構造を概観すると，Trainer（RLループ），Inference（vLLM），Orchestrator（協調制御）の3コンポーネントが，Environments Hubを通じてverifiersの各環境と接続する設計になっています：
外部サービスとしてW&B（実験管理），HuggingFace（データセット），OpenAI（ジャッジAPI）と連携します．
1.4 Hosted Training の特徴
| 項目 | 詳細 |
|---|---|
| ステータス | Private Beta（2026年3月時点，レートリミット付きで無料(エグすぎ)） |
| RL手法 | LoRAベースRLのみ |
| アルゴリズム | GRPO（デフォルト） |
| マルチテナンシー | 共有ハードウェア上のマルチテナントLoRA |
| 基盤ライブラリ | prime-rl（オープンソース） |
| Beta期間中の実行数 | 3,000以上 |
| GPUスケール | 最大256 GPUを即時利用可能 |
| 将来の料金体系 | トークン単位課金を予定 |
※ちなみにこのprime-rlはGitHubで公開されていて，アルゴリズムの実装も確認できます．つまりローカルでも同じことができ，実際に我々もローカル環境でのFull Fine-Tuningによる学習を実施しています．
2. 新しい学習スタイル: 環境Hub x Hosted Training
従来，Agentic RLを自前で回そうとすると，こんな作業が必要でした：
| ステップ | 従来のワークフロー | 所要時間の目安 |
|---|---|---|
| 1 | GPUクラスタの確保・セットアップ | 数日〜数週間 |
| 2 | 分散学習フレームワーク（DeepSpeed / FSDP）の構築 | 数日 |
| 3 | vLLM推論サーバの構築・チューニング | 1〜2日 |
| 4 | 非同期パイプラインの実装（Orchestrator） | 数日 |
| 5 | 環境・報酬の実装 | 1〜2日 |
| 6 | 学習スクリプトの実装・デバッグ | 数日 |
| 7 | 実験管理（W&B連携等） | 半日 |
Prime Labでは，開発者が担当するのは5だけです．1〜4と6〜7はプラットフォームが吸収してくれます．「環境を書いて，プッシュして，TOML設定を書いて，学習する」―― これだけで回り始めます．
2.1 ワークフロー: 「環境を書く -> プッシュ -> 学習」
# 1. CLIをインストール
uv tool install -U prime
# 2. ログイン
prime login
# 3. ワークスペースを初期化
prime lab setup
# 4. テンプレートから環境を作成
prime env init my_env
# 5. 環境を実装（verifiers ToolEnv）
# ... Pythonコードを書く ...
# 6. ビルドしてHubにプッシュ
cd environments/my_env
uv build
prime env push --path . --visibility PRIVATE
# 7. TOML設定ファイルを記述
# ... モデル，batch_size，ロールアウト数，環境参照 ...
# 8. 学習を開始
prime rl run config.toml --env-file .env
# 9. ログを監視
prime rl logs <run-id> -f
GPUの確保も，分散学習の設定も，コンテナのビルドも不要．環境のPythonコードとTOML設定だけで学習が回り始めます．これがPrime Labの最大の価値です．加えて，WebUIからの学習管理やW&B連携による実験管理も非常に便利です．
こちらは学習中のダッシュボードですが，中央にwandbのような報酬曲線がリアルタイムで表示され，右側にはconfig周りの設定が確認できます．
またロールアウトのログもリアルタイムで確認できます．エージェントの行動や環境からの応答，実際の報酬などが逐次表示されるため，学習の進行を詳細にモニタリングできます．
2.2 分離型 vs 非同期型の学習
RLの学習方式にも大きな違いがあります．
trlの分離型（Disaggregated）では，すべてのGPUが同じフェーズを実行します．生成 → 学習 → 重みロード → 生成 ... というサイクルを全GPUが同期して繰り返します．この方式の問題は，特にAgentic RLのようにマルチターンで長い系列を生成するタスクでは，生成フェーズ中に学習用GPUが完全にアイドルになることです．長い思考連鎖（CoT）を含む32Bモデルで32Kトークンのロールアウトを生成する場合，生成だけで数時間かかり，その間学習GPUは90〜95%の時間を無駄にします．
prime-rlの非同期型（Asynchronous）では，この問題をOrchestrator・Trainer・Inference Serverの3コンポーネント分離で解決しています．推論（vLLM）と勾配計算（FSDP2）は別々のGPUプール上で同時に動作し，Orchestratorがロールアウトの受け渡しを協調制御します．
Staleness問題とAIPO
非同期型の本質的な課題は，推論に使ったポリシーが学習中のポリシーよりkステップ古い（stale）ことです．つまりロールアウトがoff-policyになります．
prime-rlではこの分布シフトに対処するため，AIPO（Asynchronous Importance-weighted Policy Optimization）を採用しています．AIPOはLlama-RLで提案されたトークンレベルの重要度サンプリング補正で，古いポリシーμで生成したデータを現在のポリシーπで重み付けし直します：
PPOと異なりCriticネットワーク・GAE・KLペナルティが不要で，GRPOのグループ相対アドバンテージとの相性が良いのが特徴です．
3つのStaleness制御戦略
prime-rlでは以下の3つの戦略を組み合わせてStalenessを制御します：
| 戦略 | 設定パラメータ | 動作 |
|---|---|---|
| バージョン棄却 | max_async_level |
kステップ以上古いロールアウトを破棄 |
| キュー深度制限 | max_off_policy_steps |
未処理ロールアウトのキュー上限 |
| IS補正 | AIPOのクリップ比率 | 古いサンプルを重要度比で重み付け |
今回のTOML設定で max_async_level = 4 としたのは，4ステップ以上古いロールアウトを棄却する設定です．
3. ケーススタディ: EnronHop
ここからは，Prime Labを使って実際にエージェントを学習させた事例を紹介します．
3.1 タスク: マルチホップメールQAエージェント
我々が取り組んだのは，Enronメールコーパス（517,401通）を対象としたマルチホップ質問応答です．エージェントは Search -> Read -> Answer のフローで，複数のメールを横断しながら質問に答えます．こちらのデータセットは我々が独自に作成し，HuggingFaceに公開しています．
データセットは違いますが，同一タスクが既にenvironmentとして実装されていて，Hubに公開されています．art-eというenvです．
このタスクの難しさを端的に示すと，GPT-5ですら全体正解率37.0%です：
| モデル | 全体 | 1-hop | 2-hop | 3-hop | 4-hop |
|---|---|---|---|---|---|
| GPT-5 | 37.0% | 53.4% | 28.3% | 12.2% | 0.0% |
| GPT-5-mini | 40.0% | 54.1% | 28.3% | 4.9% | 10.0% |
なぜフロンティアモデルでも精度が低いのか
タスク自体の難易度に加え，環境の制約がこの精度の低さに大きく寄与しています．具体的には，(1) 検索ツールがAND条件のFTS5であるためキーワード選択が非常にシビアであること，(2) 最大ターン数が限られており（10〜15ターン），試行錯誤の余地が少ないこと，(3) 51万通という大規模コーパスから正解メールを特定する必要があること，が主な要因です．フロンティアモデルであっても，これらの制約下でのツール利用に最適化されていないため，限定的な精度にとどまります．
3.2 verifiersで環境を構築する
Prime LabでRL学習を行うには，verifiersライブラリを使って「環境」を実装します．主要コンセプトは以下の通りです：
| コンセプト | 説明 |
|---|---|
vf.ToolEnv |
マルチターンのツール利用環境の基底クラス |
vf.Environment |
load_environment() が返すトップレベルオブジェクト |
vf.Rubric |
1.1節で述べた報酬関数のコンテナ |
今回の環境（enronhop_env）には3つのツールを定義しました：
| ツール | シグネチャ | 役割 |
|---|---|---|
search_inbox |
(keywords: list[str]) -> list[SearchResult] |
FTS5検索，AND条件，最大10件．メール一覧と各個の冒頭一文を返す |
read_email |
(message_id: str) -> Email | None |
メール全文を返す |
return_final_answer |
(answer: str, sources: list[str]) -> None |
最終回答を提出，エピソード終了 |
検索バックエンドはSQLite FTS5で，厳密なAND条件で動作します．すべてのキーワードがマッチしたドキュメントのみが返されるため，キーワードが多すぎると何もヒットしません．このトレードオフが今回のRL学習において重要なポイントになります．
エントリーポイントは load_environment() 関数です：
def load_environment(
max_turns: int = 10,
num_examples: int = -1,
train_data_file: str = ...,
test_data_file: str = ...,
corpus_data_file: str = ...,
judge_model: str = "gpt-5-nano", # 報酬算出時に利用するJudgeモデル
) -> vf.Environment:
3.3 Hubへのプッシュと学習設定
環境をビルドしてHubにプッシュします：
cd environments/enronhop_env
uv build
prime env push --path environments/enronhop_env --visibility PRIVATE
# -> o-taisei/enronhop_env
次にTOML設定ファイルを記述します．実際に使用した設定がこちらです：
model = "Qwen/Qwen3-4B-Instruct-2507"
max_steps = 300
batch_size = 256
rollouts_per_example = 16
oversampling_factor = 2.0
max_async_level = 4
[sampling]
max_tokens = 4096
[[env]]
id = "o-taisei/enronhop_env"
args = {
max_turns = 15,
judge_model = "gpt-5-nano",
train_data_file = "hf://datasets/DeL-TaiseiOzaki/enronhop/train.jsonl",
test_data_file = "hf://datasets/DeL-TaiseiOzaki/enronhop/test.jsonl",
corpus_data_file = "hf://datasets/miluki/enronhop-corpus/emails.jsonl"
}
[wandb]
entity = "xxx-xxx"
project = "enronhop_env"
[eval]
interval = 100
num_examples = 64
rollouts_per_example = 1
eval_base_model = true
[infrastructure]
compute_size = "M"
.env に HF_TOKEN と OPENAI_API_KEY（ジャッジモデル用）を設定したら，あとはコマンド一発です：
prime rl run configs/rl/enronhop_env.toml --env-file .env
WebUIダッシュボードで報酬曲線やロールアウトのログをリアルタイムに監視しながら，学習の進行を確認できます．環境を書く -> プッシュ -> TOML設定 -> 学習開始．このシンプルさがPrime Labの真骨頂です．
4. 報酬設計の試行錯誤
ここからは実際の学習の過程で行った報酬設計の試行錯誤を紹介します．
4.1 実験1: ナイーブな報酬 --> 7.8%
最初の実験はシンプルな設定から始めました．こちらの設定は前述のart-eのデフォルトの報酬関数に近いもので，正解に対して+1，不正解に対して-1，未回答（あるいは"I don't know"と解答）は0という非常にナイーブな設計でした．
結果は7.8%．GPT-5-mini（40.0%）の5分の1以下です．学習曲線を見ると，ステップ90付近で報酬がわずかに上昇（ピーク0.11）した後，ステップ170で突然崩壊して0に張り付きました．
ロールアウトのログからは2つの失敗パターンが見えました:
- ツールの使い方の問題: キーワードを5個以上入れてAND検索が全くヒットしない
- 未回答報酬の存在: 未回答でも0点でペナルティなしのため，回答を出さない戦略が強化される
根本原因は回避トラップ（avoidance trap）です．問題が難しすぎて正解をほぼ得られない状況で，不正解のペナルティ（-1）が「回答を一切出さない」戦略を強化してしまいます．回答しなければ0点で安全だからです．一度この方策に収束すると，正の報酬を得る機会が永久に失われ，回復不能になります．
4.2 実験2: 中間報酬 --> 55.4%（GPT-5越え）
実験1の失敗から，正解に近づく行動にも報酬を与えるべきだと考えました．証拠メールを読んでいる = 回答に近づいているのだから，その行動自体に価値がある，というロジックです．
v0.2.0では報酬を3コンポーネントに分解しました:
# v0.2.0 -- Range: [0.0, 1.35] -- negative rewards: NONE
# 1. Process bonus (max 0.15)
process_bonus = 0.0
if used_search_inbox: process_bonus += 0.05
if used_read_email: process_bonus += 0.05
if called_final_answer: process_bonus += 0.05
# 2. Witness coverage (max 0.10)
coverage = evidence_emails_read / total_evidence_emails
witness_reward = 0.1 * coverage
# 3. Correctness (max 1.10)
if correct:
efficiency = max(0, 1 - turns / max_turns)
correctness = 1.0 + 0.1 * efficiency
else:
correctness = 0.0
reward = process_bonus + witness_reward + correctness
今回の報酬では，不正解を提出しても（0.15 + coverage），何もしない（0.00）より必ず高い報酬が得られるため，回避トラップが構造的に排除されます．加えて，細かく報酬が分解されているので，多くの場合1step内における報酬の分散が大きくなり，学習シグナルが強化されます．
結果としては，55.4%と大幅に改善し，GPT-5-mini（40.0%）を大きく上回りました．学習曲線も安定して上昇し，ステップ500で0.60--0.80に安定化しました．
| 指標 | GPT-5-mini | Qwen3-4B（Full-FT） | Qwen3-4B（LoRA，Prime Lab） |
|---|---|---|---|
| 正答率 | 40.0% | 55.4% | 47.7% |
| 速度 | 16.3s | 5.6s | -- |
4.3 実験の横断比較
類似する報酬で30Bも学習しました．
| モデル | 報酬設計 | 正答率 |
|---|---|---|
| Qwen3-4B（実験1，ナイーブ） | -1/0/+1 | 7.8% |
| Qwen3-4B（実験2，中間報酬） | process + correctness | 55.4% |
| Qwen3-30A3B（実験3） | outcome reward | 62.1% |
| GPT-5-mini（ベースライン） | -- | 40.0% |
Qwen3-30A3Bのoutcome rewardについて
Qwen3-30A3Bにおいてはモデルの能力が十分であり，学習初期から一定の報酬を獲得できることを確認しました．そこでなるべくロバストな報酬設計にすべく，報酬デザインは「最終回答が正しかったら1，それ以外は0」というoutcome rewardのみを利用しています．中間報酬を排除することで，報酬ハッキングのリスクを最小化しつつ，モデル自身が最適な行動戦略を発見することを促しています．
5. 結果と行動分析
実験2のQwen3-4B（中間報酬設計）を対象に，128個のロールアウト（RL 64 + ベースモデル 64）を分析した結果，RLモデルが獲得した5つの行動が明らかになりました:
| 獲得行動 | 詳細 |
|---|---|
| 適切量の検索キーワード | 2.0語/検索（vs 4.8）．マルチワード率 0.3%（vs 45.1%） |
| 必ず回答を送信する | 送信率 90.6%（vs 26.6%） |
| キーワード削減で復帰 | 検索失敗時にキーワードを減らす（ベースモデルは増やす） |
| 検索ヒット後は必ず読む | メール読取率 91%（vs 27%） |
| IDを捏造しない | 捏造率 0.7%（vs 57.8%） |
RLモデルはSearch-Read-Answerのメール検索エージェントとしての自然なロールを獲得できていました．特にキーワードの適切な量を見つける能力は重要で，検索キーワードが多すぎるとヒットしないという環境のトレードオフをRLが自律的に学習していました．また，検索失敗時にキーワードを減らすことで復帰する戦略も獲得しており，ベースモデルとは対照的に失敗から学ぶ能力が身についていました．
さらに，回答を必ず送信する行動も獲得しており，回避トラップの問題が解消されていることがわかります．捏造率の大幅な減少も見られ，RLモデルはIDを捏造せず正しい形式で回答を提出する能力を獲得していました．
5.1 学習過程で自発的に出現する能力の段階的獲得
最終的に獲得した行動だけでなく，学習の過程でどのような順序で能力が出現するかにも興味深い傾向が見られました：
- 初期（〜ステップ100）: ツール利用の基本習得 — まず
search_inboxやread_emailを正しいフォーマットで呼び出す能力が獲得されます．ベースモデルではツールを呼ばずに直接回答しようとする傾向がありますが，RLの初期段階でツールを使う行動が強化されます． - 中期（ステップ100〜300）: 適切なキーワード選択 — ツールが使えるようになった後，検索キーワードの質が向上します．キーワード数が4-5語から2語程度に収束し，AND条件の厳しさに適応していきます．この段階で正答率が急上昇します．
- 後期（ステップ300〜）: Reasoning・タスクプランニングの出現 — 最も興味深いのは，明示的に教えていないにもかかわらず，エージェントが自発的にタスクの計画を立て始めることです．例えば「まずAについて検索し，その結果からBのメールを特定し...」というような段階的な推論が出現します．
我々はQwen3-4B-Thinkingモデル（Thinkingモード）でも同様の実験を行いましたが，興味深いことに，Non-ReasoningモデルがRL学習を通じて獲得する推論量と，Reasoningモデルの推論量が，学習が進むにつれて互いに同量あたりに収束する傾向が見られました．Non-Reasoningモデルは推論ステップを使用するようになり，Reasoningモデルは元々Overthinkingだったのが，効率的な思考に収束していくのです．これはAgentic RLが単なるツール利用の最適化にとどまらず，モデルの推論能力そのものを引き出す可能性を示唆しています．実際，ThinkBrake[1]ではSLMのThinkingモデルがOverthinkingによりTool useの性能がInstructモデルと比べて劣化することが報告されており，Agentic RLによる思考量の最適化はこの問題に対する一つの解になり得ると考えています．
6. おわりに
本記事では，3つの実験を通じた報酬設計のイテレーション（7.8% --> 55.4% --> 62.1%）と，そこから得られた実践的な教訓をまとめました．
Prime Intellect LabがAgentic RLを身近にする
今回のプロジェクトで最も強調したいのは，Prime Intellect Lab[2]がAgentic RLの敷居を大幅に下げてくれたことです．TOML設定ファイルとCLIコマンドだけでGPUインフラの管理なしにRL学習が始められる．環境を書いてプッシュし，学習を走らせてW&Bでモニタリングする――これが「新しい学習スタイル」です．ベータ期間中は無料で利用できます．
ツール学習はAgentの基盤技術
本プロジェクトを通じて強く感じたのは，ツール学習は今やAgentの基盤を成している技術だということです[3]．ツールを適切に使いこなす能力が，エージェントの性能を大きく左右します．今回のタスクでは，検索キーワードの適切な量を見つける能力が正答率に大きく寄与していました．ツール学習の重要性は今後さらに増していくと考えられます．
最後まで読んでいただきありがとうございました．Agentic RLはまだ黎明期ですが，報酬設計一つで7.8%が55.4%に化けるというのはなかなかの体験でした．小さなモデルでも正しく育てれば大きな成果を出せる，この可能性に興味を持っていただけたら嬉しいです．
参考文献
-
Wen, Y. et al. "ThinkBrake: Adaptive Thinking Time Control for Efficient Reasoning of LLMs." arXiv:2510.00546, 2025. https://arxiv.org/abs/2510.00546 ↩︎
-
Prime Intellect. "Lab Blog Post." https://www.primeintellect.ai/blog/lab ↩︎
-
Wang, Y. et al. "OpenClaw-RL: Train Any Agent Simply by Talking." Princeton University. https://github.com/Gen-Verse/OpenClaw-RL ↩︎
Discussion