なぜ AI エージェントに RL リサーチを任せるべきか
正直に言うと、強化学習（RL）の研究は 意味のある指標が出るまでのセットアップコスト が大きすぎます。リポジトリをクローンし、依存関係を揃え、GPU メモリを確保し、チェックポイントのパスを整理し……という作業で、肝心のアイデア検証に使える時間が削られていきます。
ところが最近のコーディングエージェントは、この「退屈なインフラ作業」をかなり上手にこなします。リポジトリを調査し、ランタイムをセットアップし、ビルドエラーを解決し、実験を起動し、メトリクスを分析して要約まで出してくれます。
本記事では NVIDIA NeMo RL + NeMo Gym + Codex（GPT 5.5）+ Brev GPU インスタンス の組み合わせで、ユーザー側のコーディングをほぼゼロにした autoresearch ワークフローを段階的に整理します。実際に検証済みのシナリオなので、そのまま追試できます。
基本原則: autoresearch の目的は研究者をループから外すことではなく、反復的なセットアップとイテレーションをエージェントに委譲する ことです。目標設定、マイルストーンレビュー、戦略修正、最終判断は依然として人間の役割です。
前提条件
- VS Code + Codex プラグイン（GPT 5.5 モデル）
- NVIDIA Brev インスタンス（L40S 48GB GPU × 1）
- NeMo RL リポジトリ（Brev Launchable 使用時は
/home/ubuntu/RLに事前クローン済み） - Hugging Face / Weights & Biases の認証情報（モデル・データセット・ロギング用）
3つのエージェント能力を10ステップで検証する
このワークフローが検証するエージェント能力は次の3点です。
- Full-stack autonomy: ソフトウェアスタックの構築、依存解決、GPU メモリ・ディスク・チェックポイント管理、実験起動、モニタリング、デバッグ
- Goal-driven autoresearch: ベースラインのプロファイリング → 仮説立案 → 実験 → メトリクス分析 → 目標までのイテレーション
- Paper-to-code: 論文を読み → 実装計画を立て → アルゴリズムをコード化 → テスト追加 → 検証学習の開始
Step 1〜4: インスタンス起動と Codex 接続
Brev Launchable で L40S インスタンスを起動し、VS Code の SSH config にホストを追加します。Windows の場合は C:\Users\<user>\.ssh\config に以下を記述します。
Host Brev-Ubuntu
HostName <BREV_IP_ADDRESS>
User ubuntu
IdentityFile C:/Users/<user>/.brev/brev.pem
VS Code で Connect to Host → Brev-Ubuntu を選択。続いて Codex IDE 拡張をインストールし、API キーまたは ChatGPT アカウントでサインインします。
権限モードは Auto-Review から始めるのがおすすめです。サンドボックス化されたコマンドは実行しつつ、権限昇格が必要な操作はレビューを通すモードです。Full Access は便利ですが、セキュリティ感覚に自信がある場合のみ使いましょう。
Step 5: NeMo RL スモークテスト
Codex に /goal コマンドで持続的な目標を渡します。
/goal Use the nemo-rl-brev-etiquette skill under `./skills`, set up NemoRL to
do a smoke test RL training of the Qwen3-VL-2B-Instruct model
Codex が自律的にこなすべき項目:
- Brev 運用スキルのロード
- NeMo RL サブモジュールの初期化
- Hugging Face から Qwen3-VL モデルをダウンロード
- 大容量アセット（HF, Torch, Triton, uv, Ray, ログ, ワーカーキャッシュ）を
/ephemeralにルーティング - 依存関係・設定問題を解決し、学習ステップを1回完了
所要時間はおよそ 40分〜1時間。目標は「最適化されたセットアップ」ではなく、リポジトリ構築 → モデルアクセス → 依存解決 → 学習実行までの end-to-end 経路検証 です。
Step 6: セッションメモリで状態を永続化
Now use the nemo-rl-session-memory skill under `./skills`, persist this setup information
ネットワーク切断や VS Code 再起動後は、次のように復元します。
Use the nemo-rl-session-memory skill under `./skills`, load the latest session, and provide me with a summary
Step 7〜8: 新規 Gym 環境の作成とキャンペーン開始
/goal Now using the Nemo gym circle click environment as a reference,
implement a new Gym environment named "star count", that teaches
a model to count the number of stars of different colors on a canvas of
different resolutions. Show me several examples
続いて時間制限をかけてキャンペーンを実行します。
/goal Now use the nemo-rl-autoresearch and nemo-rl-session-memory skill under `./skills`,
start a new auto research session, goal: Train the Qwen3-VL-2B-Instruct model to high accuracy,
using SFT algorithm on the star count gym environment.
Start with profiling the model out of the box accuracy. Time budget: 5h
重要: プロンプトには 目標・手法・タスク環境・ベースライン要件・時間予算 を必ず含めてください。autoresearch スキルがこれを計測可能な stop rule と実験台帳（ledger）に変換します。
実測結果（star count SFT キャンペーン）
- ベースライン（固定 64-example held-out eval split）: 25.0% exact accuracy、mean reward 0.705
- 初回 LoRA スモークラン: 78.125%
- 2048-train/256-val 160-step ラン: 95.3125%
- 4096-train/512-val 320-step ラン: 96.875%（mean reward 0.992）
- 最良チェックポイントは
step_240
合計 +71.875%p の改善。残存エラーはフォーマット失敗ではなく、特定色の off-by-one カウントミス でした。したがって次の実験方向は dense / visually ambiguous シーンに対する hard-case augmentation が自然に導出されます。
Step 9〜10: Paper-to-code
論文を1本投入します。例は LLMs Can Learn to Reason via Off-Policy RL（OAPL アルゴリズム）。
/goal Start a new session with nemo-rl-session-memory skill under `./skills`. First, read
this paper https://arxiv.org/abs/2602.19362 in pdf format, form a plan then implement it.
Write and run unit tests to satisfaction. Write document. Then start a new autoresearch
session with the nemo-rl-autoresearch skill, train a Qwen3-1.7B model with this algorithm
on the DAPO-math-17K dataset. Time budget: 10h
Codex が分解して進める段階:
- PDF 読込 → 2. アルゴリズム抽出 → 3. NeMo RL フックポイント調査 → 4. 実装計画 → 5. コード変換 → 6. ユニットテスト → 7. ドキュメント作成 → 8. Qwen3-1.7B + DAPO-math-17K 検証キャンペーン
⚠️ 実務上の注意: 上記プロンプトは意図的に重いです。実際には 段階的に分割 してください。(1) 読込＋計画 → 人間レビュー、(2) 実装＋テスト＋ドキュメント → 承認、(3) 最後に autoresearch 検証キャンペーン。この流れの方がはるかに安全です。
失敗モードと注意事項
エージェントが強力になったとはいえ、以下のパターンには必ず警戒してください。
| 失敗モード | 症状 | 対応 |
|---|---|---|
| Context drift | コンテキスト圧縮を何度も経て、目標・ロード済みスキル・stop rule を忘れる | session-memory スキルで durable diary を維持 |
| Local housekeeping | ログ・チェックポイント・データセットがファイルシステム上に散乱 | マシン固有の etiquette スキルでパス規則を明示 |
| Steering drift | 途中の指示がかえってセッションを早期終了させる | 長時間キャンペーン中は介入を最小化 |
| Low-signal loops | ステップ数が少なすぎる／バッチが小さすぎてシグナルが取れない | 人間が介入して方向転換 |
日本の開発コミュニティにおける適用文脈
日本でこのワークフローを回す際に特に注意すべき点を挙げます。
- GPU リソースの確保: Brev のようなクラウド GPU は便利ですが、社内規定やコスト管理の都合で国産クラウド（さくらのクラウド、AWS ap-northeast-1 など）に載せ替えるケースが多いです。その場合は
brev-etiquetteスキルを自社インフラ向けに書き直す必要があります。 - 閉域網環境: セキュリティポリシーで Hugging Face への直接アクセスが禁止されている現場は珍しくありません。ミラーレジストリのパスをスキルに明記しておけば、エージェントが自動で迂回します。
- 実験トラッキング: W&B が使えない場合、MLflow や社内トラッカーにルーティングするようスキルをカスタマイズしてください。設定を怠ると、学習を完走しても結果が残らない事故が起きます。
この技術の限界
- エージェントは研究者ではありません。 Codex は「有能なインターン」程度に捉えてください。1行1行のコードを理解する必要はありませんが、方法論を検証できる能力 は人間側に必要です。
- 長時間キャンペーンでは必ず予算を明示 してください。時間制限、GPU-hour 予算、最大実験回数のうち最低1つを設定しないと、実験スイープが制御不能になります。
- Paper-to-code はまだ危険です。 アルゴリズム実装が微妙に間違っていても学習は「それなりに」回ってしまい、問題の発見が遅れます。self-consistency（2ブランチで別々に実装して比較）や別エージェントによる cross-check を必ず入れてください。
次のステップ学習方向
- Agent Skills のドキュメント整備 — NVIDIA の verified Agent Skills ドキュメントと
NVIDIA/skillsGitHub リポジトリを確認してください。NeMo RL Auto Research スキルがリファレンスとして有用です。 - NeMo Gym 環境を自作する —
star countの例のようにドメイン特化環境を実装すると、エージェントの得意・不得意が体感できます。 - スキルを生きたドキュメントとして扱う — スキルは一度書いて終わりではなく、各実行で得た教訓を反映して更新し続けるべきです。Codex 自身にスキルをリファクタリングさせることも可能です。
まとめ：エージェントは研究者を置き換えない
要点を整理します。
- エージェントが担う: セットアップ、デバッグ、ロギング、実験ループの実行、次ステップの提案
- 研究者が担う: 目標定義、ドメイン判断、キャンペーンの舵取り、どの結果が意味を持つかの決定
NeMo RL + NeMo Gym + Brev + Codex + 少数の運用スキルの組み合わせで、セットアップ・デバッグ・反復実験に費やしていた時間とコンピュートを大きく削減できます。浮いたリソースは 「次にどの実験を走らせる価値があるか」 を考えるために使いましょう。
すぐ試したい場合:
- Brev Launchable でチュートリアル環境をそのまま起動
NVIDIA/skillsリポジトリで NeMo RL Auto Research スキルを確認- NeMo RL / NeMo Gym の公式ドキュメントを一読
根拠資料は NVIDIA Developer Blog の原文 から確認できます。