なぜ今「エージェント主導のリサーチ」なのか
強化学習（RL）研究の真のボトルネックはアイデアではなく実験インフラです。リポジトリをクローンし、依存関係を揃え、GPU メモリとチェックポイントのパスを整理し、ベースラインを計測するだけで数日が溶けます。本来重要なメトリクスは、インフラが整ってから初めて見えてくるものです。
そこで登場するのが autoresearch という考え方です。人間がゴールと予算だけを渡せば、コーディングエージェントが仮説を立て、実際のコードベースを編集・実行しながら、メトリクスを改善するアイデアだけを残していきます。本記事では NVIDIA NeMo RL と NeMo Gym、そして Codex（GPT 5.5）を組み合わせ、実際に動作するワークフローを段階的に整理します。
重要なのは「研究者をループから外す」ことではなく、定型的なセットアップと実験実行をエージェントに委譲することです。ゴール設定、マイルストーン確認、戦略の舵取り、最終判断は依然として人間の役割です。
実践ワークフロー：10ステップで再現する
前提条件
- VS Code + Codex プラグイン（GPT 5.5）
- NVIDIA L40S 48GB GPU を搭載した Brev インスタンス
- NeMo RL リポジトリ（
/home/ubuntu/RLに事前クローン済み） - Hugging Face / W&B の認証情報（認証が必要な場合）
Step 1〜3：インスタンス起動と Codex 接続
Brev の Launchable でインスタンスを起動し、VS Code の Remote SSH で接続します。Codex 拡張をインストールしたら、まずは Auto-Review モードで始めるのがおすすめです。サンドボックス内のコマンドは許可しつつ、権限昇格が必要な操作はレビューを挟めます。
# .env の例（コミット厳禁）
export WANDB_API_KEY=wandb_v1xxx
export HF_TOKEN=hf_mqyyy
Step 4〜5：スモークテストでスタックを検証
ここでのポイントは、/goal コマンドで持続的な目標を付与することです。Codex はこの目標を保持しながら、リポジトリ初期化、サブモジュールのクローン、モデルダウンロード、キャッシュパスのルーティングまで自律的に処理します。
/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 サブモジュールの初期化
- Qwen3-VL モデルを Hugging Face からダウンロード
- 大容量アセット（HF、Torch、Triton、uv、Ray、ログ、ワーカーキャッシュ）を
/ephemeralボリュームへルーティング - 依存関係・設定の問題を解決しながら学習ステップを1回完走
所要時間はおよそ40分〜1時間。目標は「最適化されたセットアップ」ではなく、エンドツーエンドの経路検証である点に注意してください。
Step 6：セッションメモリで状態を永続化
長時間セッションではコンテキスト圧縮（compaction）を何度も経るうちに、目標を忘れてしまうことがあります。そこで session-memory スキルを使い、目標・環境前提・ロード済みスキル・重要パス・直近のコマンド結果をディスクに残します。
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：ゴール駆動型 autoresearch キャンペーン
新しい環境を1つ作ります。ここでは VLM 向けの star count タスクを例にします。
/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
実際の実験結果は次のとおりでした。
| ステップ | 精度 | 備考 |
|---|---|---|
| ベースライン（64-example held-out） | 25.0% | mean reward 0.705 |
| 初回 LoRA スモーク | 78.125% | データパイプライン検証完了 |
| 2048-train / 160-step | 95.3125% | スケーリング効果を確認 |
| 4096-train / 320-step（best: step_240） | 96.875% | mean reward 0.992 |
合計 71.875%p の改善です。残ったエラーはフォーマット失敗ではなく、特定の色で1つずれる off-by-one のカウントミスでした。そこで次の実験提案は「密で視覚的に曖昧なシーンに対するハードケース拡張」でした。これこそが autoresearch ループの本質的な価値です — 単発のコマンド実行ではなく、ベースライン計測 → 環境構築 → 検証実験 → スケーリング → チェックポイント評価 → エラー分析 → 次の方向性提案までが一続きになります。
Step 9〜10：論文からコードへ
Paper-to-code は、論文を読み、実装計画を立て、コード作成・テスト・学習までを一気通貫で行う流れです。例として取り上げる論文は 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 読解 → アルゴリズム抽出 → NeMo RL フックポイントの確認 → 実装計画 → コード変換 → ユニットテスト → ドキュメント作成 → 検証キャンペーン。ただしこのプロンプトは意図的に攻めた内容です。実務では 読解・計画は人間レビュー下で、実装・テスト・ドキュメントは承認後、長期キャンペーンは最後に と段階を分けるのが安全です。
実行の結果、OAPL は DAPO より少ないステップで高い精度に到達しましたが、トークン使用量は大幅に増えました。ここから自然なフォローアップ研究課題が生まれます — 「OAPL はなぜ冗長になるのか、精度を犠牲にせず簡潔性を高めるにはどのようなアルゴリズム変更が必要か」。
注意点：エージェントも間違える
最新のフロンティアエージェントでも、以下の失敗モードは必ず経験します。
- コンテキストドリフト：長時間セッションで目標・ロード済みスキル・停止ルールを忘れる → セッションメモリで防御
- ローカルハウスキーピングの失敗：ログ・チェックポイント・データセットがファイルシステムに散乱 → マシン固有のエチケットスキルで防御
- ステアリングドリフト：途中の介入質問がキャンペーンを早期終了させる → 介入は明示的に行う
- 低シグナルループ：小さなバッチや短いステップだけを繰り返し、シグナルが得られない実験 → 人間が気づいて方向転換
実務で使えるプラクティス
- スキルは進化するドキュメントとして扱いましょう。 Codex 自身にスキルファイルを更新させると、組織のコンベンションが蓄積されます。
- 難しい研究課題には人間の判断が依然として必須です。エージェントは有能なインターンであり、PI ではありません。
- 長期実行の前に明示的なブレインストーミング・計画フェーズを挟みましょう。計画なしに10時間のキャンペーンを投げるのは浪費です。
- 予算制約を必ず明示してください — 時間、GPU 時間、最大実験回数。これがないと実験スイープが無限に広がります。
日本の開発エコシステムにおける適用文脈
日本では GPU インスタンスを常時確保しづらいケースが多く、Brev のようなオンデマンド GPU とセッションメモリによる状態永続化の組み合わせが特に実用的です。また社内ネットワークでは Hugging Face や W&B へのアウトバウンドが制限されることも多いため、.env のクレデンシャル管理とプロキシ設定をスキルドキュメントに事前に埋め込んでおくことを推奨します。チェックポイントを /ephemeral にルーティングする規則も、国内クラウドのボリューム課金体系に合わせて調整するとコスト効率が向上します。Qiita コミュニティでも「エージェントにどこまで任せるか」という議論が活発ですが、本記事のスタンスは「セットアップと反復実行は委譲、判断は人間」という現実的な落としどころです。
まとめ：エージェントは研究者を置き換えない
このワークフローの本質は役割分担です。エージェントはセットアップ・デバッグ・ロギング・実験ループを担い、研究者は ゴール定義・ドメイン判断・キャンペーンの舵取り・結果の解釈を担います。NeMo RL、NeMo Gym、Brev、Codex、そしていくつかの運用スキルがあれば、セットアップと反復実験に費やしていた時間とコンピュートを、「次にどの実験を行う価値があるか」を考えることに振り向けられます。
次のステップ学習の方向性
- NeMo RL レシピ構造の理解：GRPO、DPO、SFT、reward model 学習レシピがどう構成されているかを確認しましょう。
- NeMo Gym 環境の書き方：カスタム環境を1つ自作すると、エージェントが環境をどう扱うかが掴めます。
- スキルドキュメントの設計：チームのコンベンションをスキルとしてエンコードする練習が、長期的に最も大きなレバレッジになります。
- クロスチェックパターン：別のフロンティアエージェントに論文・実装・テスト・結果をレビューさせる自己一貫性検証も試してみてください。
根拠資料：NVIDIA Developer Blog - How to run an autoresearch workflow with RL agent skills and NVIDIA NeMo