エージェント技術の習得：AI エージェント強化学習

[Reinforcement learning](https://www.nvidia.com/en-us/glossary/reinforcement-learning/)（強化学習）は、AI アシスタント内の人間フィードバックによる強化学習（RLHF）から、推論やエージェントタスク向けの新しい検証可能報酬による強化学習（RLVR）ワークフローに至るまで、[言語モデル](https://www.nvidia.com/en-us/glossary/large-language-models/)の整合性を図る上で中心的な役割を果たしています。 現在、強化学習は、企業がドメイン固有のワークフローに対してより正確なエージェントを必要とする [専門特化型 AI](https://www.nvidia.com/en-us/glossary/specialized-ai/) において、実用的な技術として普及しつつあります。オープンモデルはデータ、知的財産、および展開における制御性を高めますが、強化学習はドメイン固有の成功基準をトレーニングシグナルへと変換します。 フロンティア研究所では、強化学習が汎用モデルの能力を向上させることができることが示されています。[OpenAI](https://openai.com/index/learning-to-reason-with-llms/) は大規模な強化学習を用いて o シリーズモデルを訓練し、[DeepSeek-R1](https://arxiv.org/abs/2501.12948) は、グループ相対ポリシー最適化（GRPO）と検証可能報酬が数学、コード、および推論行動をどのように改善するかを示しました。 NVIDIA [Nemotron 3 Super](https://developer.nvidia.com/blog/introducing-nemotron-3-super-an-open-hybrid-mamba-transformer-moe-for-agentic-reasoning/) は、21 の NVIDIA NeMo Gym ベリファイアと 37 のデータセットにわたるマルチ環境強化学習を用いてポストトレーニングされ、約 120 万の環境ロールアウトを生成しました。 このガイドは、モデル構築者、研究チーム、およびエージェント開発者が、いつ強化学習（RL）を使用すべきかを判断し、長時間実行される [agents](https://www.nvidia.com/en-us/glossary/ai-agents/) に対して最初の検証可能な RL トレーニングループを実行する方法を学ぶために役立ちます。 ## エージェントにとっての RL の重要性 組織は、セキュリティのトリアージ、科学的発見、CLI オートメーション、カスタマーサポート、データ分析、および内部ツールの利用などのワークフローに特化したエージェントを必要としています。[Nemotron](https://developer.nvidia.com/topics/ai/nemotron) などのオープンモデルをカスタマイズすることで、これが現実的なものになります。チームは、データ、知的財産（IP）、およびデプロイメントに対するコントロールを保ちながら、精度と速度のために特化することができます。 プロンプティング、[RAG](https://www.nvidia.com/en-us/glossary/retrieval-augmented-generation/)（検索拡張生成）、およびツールを使用すれば、ある程度の成果は得られます。モデルをエージェントの脳、エージェントハネスをその体、そしてツールが作用する作業領域と考えるとよいでしょう。ハネスを改善したりツールを追加したりすることは役立ちますが、必ずしもモデルの行動を変えるわけではありません。もしエージェントがツールの呼び出しミスを繰り返す場合や、長時間のワークフローで失敗する場合、出力形式が正しくない場合、あるいは間違った戦略を選択する場合、トレーニングシグナルが必要です。そこが強化学習（RL）の出番です。 RL（強化学習）を用いることで、成功の定義を設定し、試行を生成し、それらを採点してモデルの重みを更新することで、成功した行動がより起こりやすくなります。エージェントシステムにおいては、この報酬は検証者から得られます：テストやツール実行、スキーマ検証、シミュレーター、報酬モデル、LLM-as-judge（大規模言語モデルによる審査）、人間の選好ラベル、またはその他のタスク固有のフィードバックを用いて出力や軌跡を採点するコードです。 ![image](https://developer-blogs.nvidia.com/wp-content/uploads/2026/07/image3.webp)*図 1. 環境ファーストの RL 学習ワークフロー* [Nemotron](https://developer.nvidia.com/nemotron)、NVIDIA [NeMo RL](https://github.com/nvidia-nemo/rl)、および NVIDIA [NeMo Gym](https://github.com/NVIDIA-NeMo/gym) は、OpenRLHF、PrimeIntellect、SGLang、Unsloth、veRL、vLLM などのエコシステムツールと連携するオープンモデル、ポストトレーニングのワークフロー、環境インフラストラクチャを提供しています。 ## RAG、プロンプト、SFT、および RL：いつ何を使うべきか 「どのアルゴリズムを使うべきか？」から始めるのは避けてください。 「どのような行動を増やしたいのか、またそれをどのように測定するのか？」から始めてください。 以下に意思決定マトリックスの例を示します： **問題****最初に試すべき技術** モデルがドメインの事実を欠いているRAG またはデータ注入 モデルがフォーマットに従わないプロンプト、その後 SFT（教師あり微調整） モデルが例を模倣する必要があるSFT *(LoRA や QLoRA を用いた効率的な適応)* 好ましい出力と拒否された出力があるDPO（直接最適化による差分学習） 成功をアルゴリズム的に検証できるRLVR（強化学習による検証）と GRPO 微妙な人間の選好の整合性が必要であるRLHF または報酬モデリング エージェントは、複数のツール呼び出し、状態更新、または会話ターンを伴う長期ワークフロー全体で失敗します。環境ベースの強化学習における軌道レベル報酬** ## SFT と DPO と RLVR と RLHF の比較 **SFT を使用するのは**、指示の遵守、多回対話、出力スキーマ、ツール呼び出し形式、またはドメインワークフローなど、望ましい行動の実演データがある場合です。 **DPO を使用するのは**、ある回答が別の回答よりも優れているという好意的なペア（preference pairs）がある場合です。 **RLHF を使用するのは**、微妙な人間の嗜好をルールで捉えきれず、好意データや報酬モデル、慎重なトレーニングインフラストラクチャをサポートできる場合です。 **RLVR を使用するのは**、有効な JSON、正しい CLI コマンド、テストの合格、正確な数学的答え、成功したツール呼び出し、またはシミュレータの結果など、正しさがアルゴリズムによって検証可能な場合です。 最適な方法は、利用可能な信号（signal）に依存します。検証可能なツール使用やエージェントワークフローにおいては、一般的な初期アプローチは以下の通りです：必要に応じて SFT → 検証可能な報酬を用いた GRPO → 評価 → 失敗の分析 → 繰り返し。 ## RLVR や検証可能タスクには GRPO がデフォルトとして適している RLVR ワークフローにおいて、GRPO は開始する際に実用的な選択肢となることが多いです。これはプロンプトごとに複数の完成文を生成し、検証器（verifier）で採点し、グループ内の相対的なパフォーマンスに基づいてモデルを更新します。[PPO スタイルの RLHF](https://arxiv.org/abs/2402.03300) と比較して、GRPO は構成要素が少なく、ルールベースの報酬と自然に適合するため、多くのエージェント型強化学習の例においてデフォルトとなっています。 RL 訓練システムが成熟するにつれて、より新しいバリアントも次々と登場しています。例えば、ダイナミック・サンプリング・ポリシー最適化（[DAPO](https://arxiv.org/abs/2503.14476)）は、GRPO を基盤としつつ、有用な学習シグナルと探索の多様性を維持するために動的サンプリングと非対称クリッピングを採用しています。一方、グループ・シーケンス・ポリシー最適化（[GSPO](https://arxiv.org/abs/2507.18071)）はトークンレベルではなくシーケンスレベルで最適化を行うことで、特に [Mixture-of-Experts](https://www.nvidia.com/en-us/glossary/mixture-of-experts/)（MoE）モデルにおいて訓練の安定性を向上させます。 本ガイドの後半では、GRPO と環境ベースの評価を用いた実用的な RLVR ワークフローに焦点を当てます。 ## 最小限の RL ループ LLM やエージェント向けの RL 訓練ランには、以下の 7 つの部分があります： - ポリシーモデル：訓練対象となるモデル - タスク：モデルが入力として受け取るもの - アクション：モデルの出力、ツール呼び出し、コードパッチ、コマンド、または多段階の軌跡 - 環境：アクションを実行しフィードバックを提供するシステム - バリファイア：成功をスコアリングするか、報酬を生成するシグナル - ロールアウト：現在のモデルからサンプリングされた試行 - ポリシー更新：より良い出力の確率を増加させる訓練ステップ この [RL 101 ギャラリー](https://www.nvidia.com/en-us/glossary/reinforcement-learning/) は、各コンポーネントの詳細な理解と、それらがどのように連携して動作するかを解説しています。 トレーニング前に評価から始めましょう。保持されたタスクセット上で現在のモデルを実行し、失敗箇所を検証し、重みを更新する前に検証器または報酬関数のプロファイルを取得してください。RL は、モデルが時折正しい振る舞いを生成できるが、それを確実に行えない場合に最も効果的です。報酬が間違っている場合、RL は間違った行動を最適化してしまいます。 開発者が RL で直面する一般的な課題は、データ、環境設計、報酬設計、および計算リソースの判断に関するものです。 ## タスクとトレーニングデータ SFT（Supervised Fine-Tuning：教師あり微調整）では、モデルに望ましい振る舞いを教えるための入力 - 出力例が必要です。RLVR（Reinforcement Learning with Verifiable Rewards：検証可能な報酬による強化学習）では、タスクと、出力をスコアリングできる検証器やツールを備えた環境ロジックが必要です。[Synthetic data generation](https://www.nvidia.com/en-us/glossary/synthetic-data-generation/)（合成データ生成）は、実例が不足している場合にカバレッジを拡大するのに役立ちます：タスクのバリエーション、エッジケース、ツール呼び出しシナリオ、および期待される出力を生成し、バリデーター、報酬モデル、または LLM-as-judge によるレビューでフィルタリングします。 [NVIDIA NeMo Data Designer](https://github.com/NVIDIA-NeMo/DataDesigner) は、ゼロから構造化されたタスクデータセットを生成したり、シードデータから開始したりし、フィールド間の関係を制御し、バッチ処理で生成し、仕様に対して出力を検証するのに役立ちます。その後、NeMo Gym を使用して、これらのタスクを環境を通じて実行し、モデルや教師エージェントからのスコア付き軌道（trajectories）を生成できます。これらは SFT のデモンストレーション、好ましいペアの作成、または RL のロールアウトに使用できます。 合成データは真の正解ではありません。人間による高品質なシードセットを少量保持し、重複を徹底的に排除し、評価タスクを保留し、トレーニングデータとして使用する前に失敗事例を検査してください。 ## エージェント型 RL には環境が必要であり、単なるデータセットだけでは不十分です 単純なシングルターンタスクの場合、静的なデータセットで十分な場合があります: {"prompt": "このコマンドに対して有効な JSON を返してください...", "answer": "..."} シングルステップ/ターン、マルチステップ、そしてマルチターンワークフローにわたるエージェント型 RL には、以下の要素を定義する環境が必要です: - データセット - エージェントハネス (Agent Harness) - 検証器 (Verifier) - 状態 (State) 例えば、長時間実行されるコーディングエージェントは、テストが合格するまでに多くのツール呼び出しが必要になるかもしれません。データ分析エージェントはファイルの検査、クエリの実行、チャートの生成、結果の検証を必要とする可能性があります。科学分野のエージェントは文献検索、シミュレータの呼び出し、仮説の見直しを必要とするかもしれません。 環境は単純なものから複雑なものまで様々です。数学ではパーサーと回答チェッカー、コード生成ではユニットテスト、長時間実行されるエージェントにはツールやファイル、ターン制限、タスク固有の成功基準を備えたサンドボックスなどが挙げられます。 評価 (Evals) と環境は、同じシステムの二面性です。優れた評価はモデルが成功したかどうかを示し、優れた RL 環境はその信号をトレーニングデータに変換します。 NeMo Gym は、エージェント、モデル、外部システム、ツール、検証器を接続する環境を構築するためのスケーラブルで再現性の高い方法を提供しており、シングルステップ、マルチステップ、状態保持型、リアルワールド、LLM-as-judge 環境向けのチュートリアルも用意されています。 ![image](https://developer-blogs.nvidia.com/wp-content/uploads/2026/07/image2.webp)*図 2. NeMo Gym ライブラリのコンポーネント* ## リワードと検証器の設計：シンプルに始める リワード（報酬）設計は、多くの強化学習（Reinforcement Learning: RL）プロジェクトが過度に複雑化してしまう箇所です。 まずはループが機能することを証明する最もシンプルなリワードから始めましょう。RLVR の場合、これは二値（binary）で開始できます：検証器を通過すれば +1、そうでなければ 0 です。 実際の進捗を測定する場合のみ、中間シグナルを追加します。コーディングエージェントの場合、以下のようなものが考えられます。 +0.1 適切なツールを選択した +0.2 有効な中間成果物を生成した +0.3 部分的なテストに合格した +1.0 タスクを完了した -1.0 不安全な行動を行った リワードの調整（shaping）をやりすぎると、モデルがタスクそのものではなくチェックリストの最適化を学習してしまうことになります。優れたリワード関数には以下の三つの特性が必要です。 - 実際のタスクを測定するものであること。 - ゲーム（不正行為）やハッキングが困難であること。 - 誤っている場合に明確に失敗すること。 トレーニング前に、50〜100 のモデル出力に対してリワード関数を実行し、スコアを手動で確認してください。リワードの判断とあなたの評価が一致しない場合は、リワードを修正してください。 ## コンピューティング：トレーニングとロールアウトのための予算 RL のコストは、二つのワークロードに由来します：ロールアウト（推論実行）とトレーニングです。両方ともバッチサイズ、モデルサイズ、シーケンス長の影響を受けます。特にロールアウトのコストは、ツール呼び出しの数、会話のターン数、環境ステップ数に応じてスケーリングします。[vLLM](https://github.com/vllm-project/vllm) などの推論ソフトウェアはロールアウトのレイテンシを改善し、[NeMo Gym](https://github.com/NVIDIA-NeMo/Gym) はツール呼び出しのオーケストレーションを改善します。 あるいは、トレーニングコストはデータセットのサイズとポリシー更新の数に比例して増大します。[Megatron](https://github.com/nvidia/megatron-lm) や [NeMo Automodel](https://github.com/NVIDIA-NeMo/Automodel) などのトレーニングソフトウェアはスループットを向上させます。[NeMo RL](https://github.com/NVIDIA-NeMo/RL) などの強化学習（Reinforcement Learning: RL）フレームワークはこれらの推論およびトレーニングソフトウェアの上に構築され、最適なモデル学習のための効率的なループを実現します。 GPU の要件はワークロードによって異なります。アダプターベースの約 1B〜8B の小規模実験であれば、単一の現代 GPU または小規模なマルチ GPU ノードから開始できます。大規模モデル、フルファインチューニング、長文コンテキストタスク、高いロールアウト数、または多ステップエージェント環境では複数の GPU が必要です。計算リソースが限られている場合は、まずモデルサイズ、最大トークン数、プロンプトあたりの生成数、並列環境数を削減してください。 初期実験では小さく始めるのが良いでしょう。小規模なモデルは、データのデバッグ、検証器（verifiers）、環境、トレーニングループにおいて特に優れています。複雑なタスクでは、報酬曲線や保留評価で意味のある改善が示されるまで、より能力の高いモデルが必要です。 ## 実践的な最初の RL トレーニング実行は小規模で、検証可能かつ検査可能であるべきです 自然言語の要求から正しい JSON ツール呼び出しを生成する職場アシスタント型エージェントを構築しましょう： まず、[NeMo RL の入門](https://github.com/NVIDIA-NeMo/RL#grpo-single-node) 例を使用してセットアップをクリーンに整えましょう。 次に、プロジェクト管理ワークフロー全体にわたるツール呼び出しのために GRPO で [Nemotron Nano 9B v2](https://huggingface.co/nvidia/NVIDIA-Nemotron-Nano-9B-v2) をトレーニングする NeMo RL や NeMo Gym の[職場アシスタントチュートリアル](https://docs.nvidia.com/nemo/gym/main/training-tutorials/nemo-rl-grpo/)のような多段階の例に移りましょう。まずは、多段階環境にも拡張可能な単純な 1 ステップのツール使用タスクから始めます。 ## ステップ 1: 評価対象の行動を 1 つ選択する 自動評価用の行動を 1 つ選びます。 例：自然言語によるリクエストを受け取り、内部 CLI または API に対する正しい JSON ツール呼び出しを生成します。 { "prompt": "来週の火曜日の午後 2 時にアレックスのためのカレンダーイベントを作成してください。", "expected_tool": "calendar.create_event", "expected_args": { "attendee": "Alex", "day": "Tuesday", "time": "14:00" } } ## ステップ 2: ベースライン評価を実行し、失敗を分類する トレーニング前に、トレーニング用と検証用のタスクファイルを別々に用意します。検証セット上でベースラインモデルを実行し、有効な JSON の割合、正しいツールまたはコマンドの割合、正しい引数の割合、実行成功率、および不安全なアクションの割合を測定します。 次に出力を検査し、失敗をタイプ別にグループ化します：フォーマットエラー、間違ったツールまたはコマンド、一貫性のない成功、不安全なアクション、あるいは長期ホライズンの失敗です。トレーニング前にモデルに測定可能な失敗パターンがあることを確認してください。 これにより、使用するトレーニング手法が決定されます。 ## ステップ 3: SFT の必要性を判断する もしモデルが期待される形式やツールファミリーをほとんど守らない場合は、SFT から始めましょう。時々成功するが不安定な場合は、GRPO を用いた RLVR へ移行します。 実践的なアプローチは以下の通りです： - 形式とタスク理解のための SFT - 信頼性向上のための GRPO を用いた RLVR - デプロイ前のホールドアウト評価（Held-out evals） ## ステップ 4: 検証器または報酬関数の構築 RL が次の適切なステップであることが確定したら、評価ロジックを報酬関数に変換します。最初はシンプルで決定論的なものから始めましょう。 def reward(output, expected): if not is_valid_json(output): return -1.0 parsed = json.loads(output) score = 0.0 if parsed["tool"] == expected["expected_tool"]: score += 0.4 score += 0.4 * argument_match( parsed["args"], expected["expected_args"] ) if executes_safely(parsed): score += 0.2 return score トレーニング前にサンプル出力に対してこの検証器を実行してください。報酬があなたが正しいと考える内容と一致しない場合は、まず検証器を修正します。 ## ステップ 5: 小規模な GRPO ジョブの実行 小規模モデルまたはアダプターベースのランから始めます。最初のランは意図的に範囲を狭く保ちましょう。 model: nvidia/Nemotron-Nano-9B-v2 algorithm: grpo adapter: lora num_generations_per_prompt: 8 reward: tool_call_verifier eval_interval: 10 held_out_eval: tool_call_eval ## ステップ 6: 適切な指標の追跡 トレーニング報酬だけでなく、検証用報酬、成功率、無効な出力、不安全なアクション、レイテンシ、コストも追跡してください。モデルが訓練していないタスクにおいて、検証用報酬や精度がベースラインに対して改善されているか確認してください。 ## ステップ 7: 失敗の調査と慎重なリリース 各チェックポイントでサンプル出力を確認してください。報酬ハッキング、フォーマットの後退、不安全なアクション、あるいは報酬は向上しているものの実際の品質が悪化しているケースがないか探します。安全、レイテンシ、または一般的な能力チェックにおいて後退することなく、未使用の評価セット（held-out evals）上でチューニング済みモデルがベースラインを上回った場合にのみリリースしてください。 ## 長時間稼働するエージェントのための継続的改善 長時間稼働するエージェントはソフトウェアシステムのように改善されるべきです。RL を実践的なループとして用い、本番環境向けのエージェントワークフローを継続的に改善します： - 実際の軌跡（trajectories）のログ記録：プロンプト、ツール呼び出し、観測結果、出力、失敗事例、人間の介入、および最終結果を記録する。 - 失敗の評価セットへの変換：本番環境でのすべての失敗は、回帰テストまたは環境タスクとして扱うべきである。 - 失敗モードの分類：フォーマットエラー、誤ったツールの選択、不適切な計画、不安全なアクション、検索失敗、ハルシネーション（幻覚）された API、および不完全な実行を分離する。 - 最も軽量な修正の選択：まずプロンプトまたはツールの変更を行う。繰り返し発生するフォーマットやドメイン固有の動作には SFT を使用し、選好品質の向上には DPO を使用する。成功を検証できる場合は RLVR/GRPO を適用する。 - 未使用タスクでのトレーニング：モデルが決して訓練しない固定の評価セットを維持し、新しいタスクを継続的に追加する。 - 行動の改善がある場合のみ推進する 成功確率、安全性の失敗、コスト、レイテンシ、回帰テストにおいて、ベースラインと調整済みモデルを比較してください。 - 調整済みモデルはバージョン管理する エージェントの専門化のために、各調整済みチェックポイントまたはアダプターにバージョンを割り当てて、行動を比較し、安全にロールバックし、基本モデルを上書きしないようにします。 このループの出力は、エージェントのフライホイールです。生産環境での失敗が評価データとなり、評価データが環境となり、環境が報酬を生成し、報酬がモデルを改善し、次のモデルは展開前にテストされます。 ## LLM とエージェントのための強化学習の始め方 有用な RL 実行への最短経路は、明確なタスク、信頼できる検証者、小さなベースラインモデル、そしてモデルが実際に向上したかどうかを示す保持された評価セットです。 ご自身のモデルやエージェントに RL を適用する準備はできましたか？NVIDIA NeMo と Nemotron で開発を加速しましょう： - Nemotron によるオープンモデル、レシピ、およびアジェンティック AI の例 - NeMo RL によるスケーラブルなポストトレーニング - NeMo Gym による検証可能な報酬環境、ロールアウト、および評価 - NeMo Data Designer による合成データ生成 - カスタムエージェントの異なる手法に関する詳細ガイド これらのツールは、開発者がゼロから完全な RL スタックを再構築することなく、タスク定義とデータ生成からトレーニング、評価、最適化へと移行できるよう支援します。

エージェント技術の習得：AI エージェント強化学習

背景や根拠まで確認しますか？

関連記事

調べる

選ぶ

サイト