TRLのAsyncGRPOが「エージェント自身にループを持たせたまま」強化学習できるようになった

強化学習でエージェントを訓練するとき、これまでのTRLのAsyncGRPOTrainerは「白箱（white-box）」方式が前提だった。TRL側がenvironment_factoryを通じてエージェントの各ターンを1つずつ制御し、その過程でトークンとログ確率を取得する。この方式は、エージェント自身が独自のツール呼び出しループを持つ既存のコーディングエージェント（opencodeのような）をそのまま学習対象にするのには向かない。TRL v1.10.0（2026年8月13日公開）のリリースノートに、この制約を回避する新しい経路が追加されたと書かれている。

3行まとめ

• TRL v1.10.0のAsyncGRPOTrainerに、opencodeのようなエージェント自身がツールループを持つ「黒箱」型を強化学習できる実験的経路が追加された
• サンプル実装はagentica-org/DeepCoder-Preview-Dataset（codeforces・LiveCodeBench v5・PrimeIntellect・TACOの4サブセット）を使い、Qwen3-4B-Instruct-2507で動作確認済み
• 報酬は「全held-outテスト合格で1.0、それ以外0.0」の二値ベースに、bash未実行で-0.1、ツール呼び出し20回超過で最大-0.5の段階ペナルティを加える設計

「黒箱（black-box）」でエージェントのループごと訓練する

リリースノートの説明はこうだ。

New experimental loop-owning (black-box) path for AsyncGRPOTrainer — for training external agents like opencode that run their own tool loop, rather than TRL driving each turn as in the environment_factory white-box path.

（AsyncGRPOTrainer向けの新しい実験的な「ループ所有型（黒箱）」経路——opencodeのような、自分自身のツール呼び出しループを持つ外部エージェントを訓練するためのもので、environment_factoryによる白箱方式のようにTRLが各ターンを制御するのとは異なる）

opencodeはエージェント自身がツールをどう呼ぶか、いつ会話を終えるかを自分で判断しながら動く。これまでのTRLの仕組みでは、こうした「エージェント側が主導権を握るループ」を学習ループの中に組み込むのが難しかった、という文脈で読める。

仕組み：セッション内プロキシがトークンを横取りする

具体的な実装は次のように説明されている。

The agent runs in an OpenEnv session in transparent_proxy mode; an in-sandbox proxy captures each turn's token ids and logprobs. On completion, TRL reads the trace, rebuilds per-turn training rows, and scores the workspace with the session's verify(). Ships with three caller-supplied policy hooks (rollout_reward_fn, train_turn_fn, agent_turn_fn) so you can drop framework aux calls (title generator, context summarizer) and reinforce only the turns you want.

（エージェントはtransparent_proxyモードのOpenEnvセッション内で動き、サンドボックス内のプロキシが各ターンのトークンIDとログ確率を捕捉する。完了時にTRLがそのトレースを読み込み、ターンごとの学習用データ行を再構築し、セッションのverify()でワークスペースを採点する。呼び出し側が指定する3つのポリシーフック（rollout_reward_fn・train_turn_fn・agent_turn_fn）を備えており、フレームワーク側の補助的な呼び出し（タイトル生成やコンテキスト要約など）を除外し、強化学習の対象としたいターンだけに絞り込める）

つまり、エージェントが内部で行う「このタスクのタイトルを考える」「これまでの文脈を要約する」といった、学習の本質とは関係のない補助的な呼び出しまで巻き込んで強化学習してしまわないよう、フックで対象を絞り込める設計になっている。

動作確認の範囲──サンプルスクリプトの中身を読む

リリースノートには、examples/scripts/openenv/opencode.pyという自己完結型のサンプルが同梱され、「ローカルのサブプロセスサンドボックス＋DeepCoderのheld-outなstdin/stdout検証器」を使い、Qwen3-4Bでエンドツーエンドの動作確認をしたと明記されている。このサンプルスクリプト本体（615行）を実際に取得して読むと、リリースノートには書かれていない実装の詳細がいくつも見つかった。

まず、使用モデルはQwen/Qwen3-4B-Instruct-2507で、2GPU構成（1枚はvLLMサーバー、もう1枚はトレーナー）を前提としたコマンド例がスクリプトのdocstringに記載されている。vLLM側は--enable-auto-tool-choice --tool-call-parser hermes --logprobs-mode processed_logprobs --return-tokens-as-token-ids --weight-transfer-config '{"backend":"nccl"}'というフラグを要求しており、ツール呼び出し・トークンID返却・NCCL経由の重み同期のすべてが必須と明記されている。

学習タスクはagentica-org/DeepCoder-Preview-Dataset（Hugging Face上のデータセット）から出題される競技プログラミング問題で、実際にこのデータセットのページを確認すると、codeforces・lcbv5（LiveCodeBench v5）・primeintellect・tacoという4つのサブセット（config）で構成されていた。エージェントはsolution.pyを書き、検証器はエージェントには見せていないheld-outテストで採点する。

報酬関数opencode_rewardのロジックもコードに明記されている。

出典: examples/scripts/openenv/opencode.py内のopencode_reward関数（TRL v1.10.0）

さらにopencode_agent_turnsという関数は、opencodeがタイトル生成やコンテキスト要約のために内部で発行する「ツールなしの、あるいは別のシステムプロンプトを使った」LLM呼び出しを、最初に見つかったツール有効なシステムプロンプトを基準にして除外し、実際のエージェントループのターンだけを学習対象に残す仕組みになっている。これはリリースノート本文で触れられていた「フレームワーク側の補助的な呼び出しを除外する」という説明の、コード上の実装そのものだ。

なお、opencode自体は公式ドキュメントによれば「ターミナル・デスクトップアプリ・IDE拡張として使えるオープンソースのAIコーディングエージェント」で、インストールスクリプト（curl -fsSL https://opencode.ai/install | bash）やnpm/Homebrew/Docker経由でのインストール手段が用意されている。

同じリリースでは、AsyncGRPOの観測性・サンプリング制御まわりの改善も並行して入っている。ロールアウトのトレースをtrackio（TRLが使う実験管理ツール）へ記録する機能、ステップ時間のメトリクス、AsyncGRPOConfigでのtop_p・top_k・min_p・repetition_penalty対応などだ。

まだ実験的機能という位置づけ

このループ所有型の経路は、リリースノートの見出し自体が「New experimental」と明記しており、TRL v1.10.0で本採用になったDistillationTrainerとは違い、実験段階のままだ。仕組みの中身が具体的に書かれている一方で、既存の白箱方式との性能比較や、opencode以外のエージェントフレームワークでの動作実績は、このリリースノートには記載がなかった。

2GPUを用意してこのサンプルを動かしてはいない

本記事はTRL v1.10.0のリリースノート本文と、サンプルスクリプトopencode.pyのソースコード、DeepCoder-Preview-Datasetのデータセットページを情報源としている。ソースコードを読んで報酬関数や環境変数の中身までは追えたが、この記事を書いている自分の手元でvLLMサーバーとトレーナーの2GPU構成を実際に用意し、opencode.pyを走らせてQwen3-4Bを学習させる検証は行っていない。そのため、リリースノートが主張する「エンドツーエンドで動作確認済み」という結果が実際にどの程度の学習曲線・成功率で再現するかは、この記事の範囲では確認できていない。rollout_reward_fn・train_turn_fn・agent_turn_fnという3つのポリシーフックを、opencode以外の別のコーディングエージェント（例えばAider等）に対してそのまま使い回せるかどうかも、リリースノートとサンプルコードのどちらにも記載がなく確認できなかった。

関連記事: ファインチューニング やり方・費用・いつ使うべきか【2026年入門】 / AIコーディングアシスタント比較──Copilot/Cursor/Claude Code【2026年】 / AIエージェントとは

感想・指摘はコメント欄へ。