LLMエージェント学習

チャットボットから自律エージェントへ

現代のLLMは、会話アシスタントとしてだけでなく、複数ステップにわたって外部ツール、API、データベース、環境と相互作用する 自律エージェント としてますます展開されています。この変化、すなわち単一ターンのチャットボットから複数ステップのエージェントへの移行は、言語モデルの学習・評価・デプロイ方法を根本から見直す必要がある、新しいRLの課題をもたらします。

新しいRL手法を必要とする主な違いは次のとおりです：

• 複数ステップの推論 ：エージェントは単一の応答を生成するだけでなく、10–100回以上のツール呼び出しにまたがって計画する必要があります。

• 外部環境からのフィードバック ：報酬は人間の選好スコアだけでなく、現実の実行（テストスイートの成功、ウェブページの読み込み、コードのコンパイル）から得られます。

• 構造化アクション ：アクションは単なるトークンではなく、構造化された出力（JSONツール呼び出し、APIペイロード、コードブロック）です。

• 疎な報酬を伴う長いホライズン ：成功／失敗が判定されるのは、多数の中間ステップを経た後だけかもしれません。

Tip

標準RLHFがエージェントに不十分な理由

標準RLHF（PPO/DPO）は単一ターンの品質を最適化します。つまり、プロンプトが与えられたら良い応答を生成します。しかしエージェントは次のことを行う必要があります：

• ツールを使うタイミングと、内部で推論するタイミングを判断する

• 軌跡の途中でエラーから復旧する（自己修正）

• 探索（新しいアプローチを試す）と活用（既知の良いパターンを使う）のバランスを取る

• 部分観測を扱う（ツール出力が不完全またはノイジーな場合がある）

そのため、個々のターンではなく、 軌跡全体 について推論する学習手法が必要です。

LLMエージェントの軌跡バッファ

LLMエージェントの文脈では、従来のRLリプレイバッファが構造的に変化します。低次元の数値テンソルを保存する代わりに、エージェント用バッファ（ Trajectory Buffer 、 Experience Pool 、 Memory Bank などと呼ばれる）は、複雑なテキスト履歴、ツール実行出力、明示的な推論ステップを管理します。

LLMエージェントバッファの数学的構造

古典的なRLでは、リプレイバッファはフラットなタプル\((s, a, r, s')\)を保存します。LLMエージェントでは、これが高次元のトークン化テキスト構造へ拡張されます：

\[ \boxed{e_t = \left( \mathcal{S}_t,; \mathcal{A}_t,; \mathcal{R}_t,; \mathcal{S}_{t+1} \right)} \]

• \(\mathcal{S}_t\)： 完全なコンテキスト状態 。システムプロンプト、ユーザーの目的、会話履歴、現在の環境変数（HTMLソースコード、ディレクトリ構造、データベーススキーマなど）です。

• \(\mathcal{A}_t\)：エージェントの 生成出力 。通常、Chain-of-Thought（CoT）推論文字列に続く構造化ツール呼び出しで構成されます：

\[ \mathcal{A}_t = \{\text{text}_{\text{reasoning}},; \text{json}_{\text{tool_call}}\} \]

• \(\mathcal{R}_t\)：外部実行環境（ユニットテストの成功、コンパイラフラグ、API応答コード）から得られる、またはLLM-as-a-judgeシステムで検証される 評価信号 。

• \(\mathcal{S}_{t+1}\)：ツール出力テキストやエラーログを会話履歴へ直接追加した 更新後のコンテキストウィンドウ 。

Note

具体例：コードデバッグのエージェント軌跡

ステップ1 ：\(\mathcal{S}_1\) = 「utils.pyの失敗しているテストを修正する」
\(\mathcal{A}_1\) = 「まずファイルを読んでみます」 + read_file("utils.py")
\(\mathcal{R}_1\) = 0（中間ステップ）
ステップ2 ：\(\mathcal{S}_2\) = [前のコンテキスト + ファイル内容]
\(\mathcal{A}_2\) = 「バグは42行目のoff-by-oneエラーです」 + edit_file("utils.py", ...)
\(\mathcal{R}_2\) = 0（中間ステップ）
ステップ3 ：\(\mathcal{S}_3\) = [前のコンテキスト + 編集の確認]
\(\mathcal{A}_3\) = 「修正を検証してみます」 + run_tests()
\(\mathcal{R}_3\) = +1.0（全テスト成功 — 疎な終端報酬）

運用パラダイム

LLMエージェントは、3つの主要な最適化方法を通じて、専用の軌跡バッファを活用します：

A. 自己修正と推論の洗練

このカテゴリの代表的な手法はSTaR (Zelikman et al. 2022) とReflexion (Shinn et al. 2023) です。エージェントが複数ステップの実行軌跡に失敗すると、準最適な系列がバッファへ保存されます。フレームワークは後でこの軌跡をサンプリングし、LLMに過去の性能について明示的なテキスト批評を生成させます：

\[ \text{Critique} \leftarrow \text{LLM}(\mathcal{S}_{\text{failed}},; \mathcal{A}_{\text{failed}},; \mathcal{R}_{=0}) \]

正しい軌跡が正の報酬を達成すると、最適な経験プールへ移されます。このプールを使って、ファインチューニング（成功軌跡に対するSFT）またはRL（バイナリの成功／失敗報酬を使うGRPO (Shao et al. 2024)）によりネットワーク重みを更新します。

Important

STaR：Self-Taught Reasoner

1. 問題のバッチについて推論軌跡を生成する

2. フィルタリング：正解に到達した軌跡だけを残す

3. 成功軌跡でモデルをファインチューニングする（SFT）

4. 反復：改善したモデルが次の反復でより良い軌跡を生成する

各反復では、モデル自身の成功出力を学習データとして使い、推論能力をブートストラップします。

Important

Reflexion：言語による強化学習

1. エージェントがタスクを試み、失敗する

2. エージェントが 言語による振り返り を生成する：「APIを呼び出す前に戻り値の型を確認しなかったため失敗した」

3. 振り返りをエピソード記憶バッファに保存する

4. 次の試行で、学んだ教訓として振り返りをプロンプトへ注入する

5. 重み更新は不要 — 自己批評だけによる純粋なインコンテキスト学習

B. オフポリシー探索

ReAct (S. Yao, Zhao, et al. 2023) や関連するツール利用フレームワークに代表されるこのパラダイムは、大規模な自律探索を行います。自律探索（ウェブナビゲーション、データベース照会、コード生成）の間、エージェントは何千もの探索的な実行経路を記録します。軌跡バッファはフィルタとして機能します：

• 成功フィルタリング ：目標を達成した軌跡だけを学習に残す

• 効率ランキング ：成功軌跡の中では、最短かつ最も効率的なツール利用経路を優先する

• 多様性サンプリング ：モード崩壊を防ぐため、多様な解決戦略の集合を維持する

最適化アルゴリズム（通常はGRPO (Shao et al. 2024) またはフィルタ済みSFT）は、非効率で成功しなかった実行を捨て、効率的で成功した軌跡だけについて損失を計算します。

C. 非パラメトリックなインコンテキスト学習（経験に対するRAG）

ニューラルネットワークの重みを変更する代わりに、軌跡バッファを ベクトルデータベース として機能させることができます。新しいユーザー目標\(\mathcal{G}_{\text{new}}\)が与えられると、システムは最も関連する過去の経験を取得します：

\[ \boxed{\mathcal{E}_{\text{retrieved}} = \arg\max_{e \in \mathcal{B}} \text{sim}!\left(\text{Embed}(\mathcal{G}_{\text{new}}),; \text{Embed}(e)\right)} \]

最も類似した上位\(k\)件の成功履歴を、few-shotデモンストレーションとしてプロンプトのコンテキストへ直接注入します。このアプローチには次の特徴があります：

• 学習ゼロ — 純粋な検索拡張生成

• バッファに類似経験があれば、新しいタスクへ即座に適応する

• バッファサイズに応じてスケールする（経験が増えるほどカバレッジが向上）

• パラメトリック学習を補完する（まれなケースには検索、一般的なパターンには重みを使う）

パラダイム比較

従来のRLバッファとLLMエージェントバッファ

エージェントRLの主要手法

RLによるLLMエージェント学習の主要手法

STaR：Self-Taught Reasoner（詳細）

STaR (Zelikman et al. 2022) は、外部報酬モデルなしで推論能力をブートストラップする 反復的な自己改善 手法です。核心となる洞察は、モデルが時々問題を正しく解けるなら、その成功から学習できるということです。

アルゴリズム ：

1. 生成 ：データセット\(x_i\)の各問題\(\mathcal{D}\)について、推論軌跡\(z_i \sim \pi_\theta(\cdot \vert x_i)\)をサンプリングし、その後に解答\(\hat{y}_i\)を続ける。

2. フィルタリング ：\(\hat{y}_i = y_i^*\)（正解）となる軌跡だけを残す。成功集合を\(\mathcal{D}_{\text{pass}} = \{(x_i, z_i, y_i^*) : \hat{y}_i = y_i^*\}\)と定義する。

3. 合理化 （主要な革新）：モデルが失敗した問題について、正解を条件とした「合理化」軌跡\(z_i^{\text{rat}} \sim \pi_\theta(\cdot \vert x_i, y_i^*)\)を生成する。これにより解答から逆向きに推論することを学習する。

4. ファインチューニング ：\(\theta\)に対するSFTで\(\mathcal{D}_{\text{pass}} \cup \mathcal{D}_{\text{rationalized}}\)を更新する。

5. 反復 ：改善したモデルでステップ1から繰り返す。

\[ \boxed{\theta_{k+1} = \arg\min_\theta -\sum_{(x,z,y) \in \mathcal{D}_k^+} \log \pi_\theta(z, y | x)} \]

収束ダイナミクス ：各反復\(k\)でモデルの解答率\(p_k\)が上昇します。\(p_0 = 0.3\)の場合（問題の30%を解く）、合理化 + SFTの後に\(p_1 \approx 0.5\)となります。通常は3–5回の反復で\(p \approx 0.7\)–\(0.9\)へ収束します。

Note

STaR合理化プロンプト

# Standard generation (Step 1):
PROMPT = """Solve the following problem step by step.
Problem: A store has 45 apples. It sells 3/5 of them. How many remain?
Let's think step by step:"""

# Rationalization prompt (Step 3 - conditioned on correct answer):
PROMPT_RATIONALIZE = """Solve the following problem step by step.
The correct answer is 18.
Problem: A store has 45 apples. It sells 3/5 of them. How many remain?
Let's think step by step to arrive at 18:"""

# Agent variant (code task with error conditioning):
PROMPT_AGENT_RATIONALIZE = """The following code task failed with the error below.
Generate a correct solution step by step.

Task: Implement binary search that handles duplicates.
Previous error: IndexError: list index out of range (line 12)
Correct behavior: Return leftmost index of target.

Let me fix this by reasoning about the boundary conditions:"""

Tip

エージェント向けSTaRの派生

• Quiet-STaR (Zelikman et al. 2024)：生成の各トークン間に「思考トークン」を挿入します。明示的なCoTプロンプトなしで暗黙に推論することを学習します。学習目標は、思考トークンを含めたときに次のトークンをよりよく予測することです。

• コードエージェント向けSTaR ：解答検証をテスト実行に置き換えます。「正しい」=すべてのテストが成功。合理化では、エラーメッセージを条件に新しいアプローチを生成します。

• V-STaR (Hosseini et al. 2024)：\((z, y, \text{correct/incorrect})\)トリプルで学習した検証モデルを追加します。検証モデルはプロセスレベルの教師信号を提供し、偶然正解に到達した不良推論軌跡をフィルタします。

Reflexion：言語による強化学習（詳細）

Reflexion (Shinn et al. 2023) は、 重み更新なしのRL という大胆なパラダイムを導入します。勾配ベースの学習の代わりに、エージェントはエピソード記憶に保存された自然言語の自己批評を通じて改善します。

全体アーキテクチャ ：

1. アクター ：環境内でアクションを実行するLLMエージェント\(\pi\)。

2. 評価器 ：バイナリ信号（タスクの成功／失敗）またはスカラーのヒューリスティック（例：成功したテストケース数）。

3. 自己振り返り生成器 ：失敗した軌跡\(\tau_{\text{fail}}\)と環境フィードバックを受け取り、自然言語の振り返り\(r_{\text{text}}\)を生成する：

\[ r_{\text{text}} = \text{LLM}_{\text{reflect}}!\left(\tau_{\text{fail}}, \text{feedback}, \text{task}\right) \]

4. エピソード記憶 ：過去の振り返りを格納するスライディングウィンドウバッファ\(\mathcal{M} = [r_1, r_2, \ldots, r_m]\)（通常はコンテキストに収めるため\(m \leq 3\)）。

5. 再試行ループ ：次の試行で、振り返りをプロンプトへ注入する：

\[ a_{t+1} \sim \pi!\left(\cdot; |; \text{task},; \mathcal{M},; \text{current_state}\right) \]

振り返りの例 ：「前回の試行では、入力形式を検証する前に検索APIを呼び出したため、400エラーになりました。次回はまずJSONスキーマを検証してからAPIを呼び出すべきです。」

Note

Reflexion：記憶を注入したエージェントプロンプト

# === ATTEMPT 2 PROMPT (after first failure) ===

SYSTEM = """You are a coding agent. You can run bash commands and edit files.
Complete the task below. Learn from your previous reflections."""

USER = """Task: Fix the failing test in auth_service.py

=== REFLECTIONS FROM PREVIOUS ATTEMPTS ===
[Attempt 1 reflection]: I tried to modify the authenticate() function
directly but forgot that it depends on token_validator(). The test
failed because token_validator() was still returning the old format.
I should trace the dependency chain FIRST: check what authenticate()
calls, then fix the root cause (token_validator), not the symptom.
=== END REFLECTIONS ===

The repository is in /workspace/. The failing test is:
  test_auth.py::test_expired_token_returns_401

Begin by reading the relevant files, then fix the issue."""

長所と限界 ：

ReAct：推論と行動（詳細）

ReAct (S. Yao, Zhao, et al. 2023) は、1回の生成ストリームの中で 明示的な推論ステップと環境アクションを交互に行う ことで、ツール利用エージェントの主流プロンプティングパラダイムを確立しました。

Note

ReActシステムプロンプト（典型例）

SYSTEM = """You are a research assistant with access to the following tools:
- search(query): Search the web for information
- lookup(term): Look up a term on the current Wikipedia page
- finish(answer): Submit your final answer

Solve the user's question by interleaving Thought and Action steps.
Format:
  Thought: <your reasoning about what to do next>
  Action: <tool_name>(arguments)

You will receive an Observation after each Action. Use it to plan
your next step. Continue until you can provide a final answer.

Rules:
- Always think before acting
- Never guess - verify with tools
- Use finish() only when you are confident in your answer"""

USER = "Who was the president of the US when the iPhone was released?"

生成形式 ：

Note

ReAct軌跡の形式

Thought: I need to find when the iPhone was released, then determine
who was president at that time. Let me search for the release date.
Action: search("iPhone original release date")
Observation: The original iPhone was released on June 29, 2007.
Thought: The iPhone came out June 2007. Now I need to find who was
the US president in June 2007.
Action: lookup("President of the United States in 2007")
Observation: George W. Bush served as the 43rd president from
January 20, 2001 to January 20, 2009.
Thought: George W. Bush was president from 2001-2009, which covers
June 2007 when the iPhone was released. I have my answer.
Action: finish("George W. Bush was the US president when the iPhone
was released on June 29, 2007.")

形式的定義 ：ReAct軌跡は\(\tau = (t_1, a_1, o_1, t_2, a_2, o_2, \ldots)\)であり、次のように表されます：

• \(t_i\)：思考（内部推論、実行されない）

• \(a_i\)：アクション（ツール呼び出し、環境内で実行）

• \(o_i\)：観測（環境からの応答、コンテキストへ追加）

機能する理由 ：思考は、行動前の計画を助ける「内的独白」を作り、衝動的なツール呼び出しを減らします。明示的な推論軌跡により、エージェントの意思決定プロセスも 監査可能 かつ デバッグ可能 になります。

RLによるReActエージェントの学習 ：

• アクションレベル報酬 ：報酬信号を受け取るのはアクションだけです（思考は補助的）。

• 思考の品質 ：暗黙に最適化されます。より良い思考\(\rightarrow\)より良いアクション\(\rightarrow\)より高い報酬。

• 形式の強制 ：不正なアクション（JSONの欠落、存在しないツール）の報酬に形式違反ペナルティを含めます。

• RL目的関数 ：\(r(\tau) = r_{\text{task}} - \lambda_{\text{format}} \cdot \text{format_violations} - \lambda_{\text{length}} \cdot \text{num_steps}\)

LATS：Language Agent Tree Search（詳細）

LATS (A. Zhou et al. 2024) は、LLMエージェントのアクション選択に モンテカルロ木探索（MCTS） を適用し、推論計算量と引き換えに、はるかに良い軌跡を得ます。

アルゴリズム（LLMエージェント向けに適応） ：

1. 選択 ：ルート（初期状態）から始め、UCB1を使って木をたどります：

   \[ \text{UCB}(s, a) = \bar{Q}(s, a) + c \sqrt{\frac{\ln N(s)}{N(s, a)}} \]

   ここで\(\bar{Q}\)は部分木の平均報酬、\(N\)は訪問回数、\(c\)は探索定数です。

2. 展開 ：葉ノードで、LLMサンプリング（温度\(k\)）により\(> 0\)個の候補アクションを生成します：\(\{a_1, \ldots, a_k\} \sim \pi_\theta(\cdot \vert s_{\text{leaf}})\)

3. シミュレーション ：各候補について環境内でアクションを実行し、高速なロールアウト方策（貪欲デコーディング）を使って終端状態または深さ制限まで続けます。

4. バックプロパゲーション ：終端報酬をすべての祖先ノードへ伝播し、\(\bar{Q}\)と\(N\)のカウントを更新します。

5. 反復 ：固定した計算予算（例：50–200回の反復）でステップ1–4を実行します。

6. アクション選択 ：ルートで最も訪問された子ノードを選びます。

LLM固有の適応 ：

• 価値関数 ：別のLLM呼び出しで状態価値を推定します：「0–1の尺度で、この状態がタスク成功につながる可能性はどの程度か？」

• 振り返りベースの枝刈り ：枝が失敗したら振り返りを生成し、類似する枝を刈り込みます。

• キャッシュ ：バックトラッキング中の重複生成を避けるため、各ノードのLLM出力を保存します。

• 深さ予算 ：木の深さを10–20ステップに制限します（エージェントがそれ以上必要とすることはまれです）。

性能 ：WebShop（ウェブナビゲーション）では、LATSはReActの40%に対して75%の成功率を達成します。HumanEval（コード）では、木探索によりpass@1が68%\(\rightarrow\)94%に向上します。コストはタスクあたり推論FLOPsが10–50\(\times\)増えることです。

Note

LATSプロンプト：価値推定とノード展開

# === VALUE ESTIMATION PROMPT (used during simulation) ===
VALUE_PROMPT = """You are evaluating an agent's progress on a task.

Task: Book a flight from NYC to London for under \$500, departing Dec 15.

Current state (after 3 actions):
- Searched flights on Kayak: found 12 results
- Filtered by price < \$500: 4 options remain
- Clicked on British Airways \$489 option: viewing details page

On a scale of 0.0 to 1.0, how likely is the agent to successfully
complete the task from this state? Consider:
- How close is the agent to the goal?
- Are there remaining obstacles (payment, seat selection)?
- Has the agent made any errors that need correction?

Score: """  # Model outputs e.g. "0.75"

# === NODE EXPANSION PROMPT (generating candidate actions) ===
EXPAND_PROMPT = """You are a web navigation agent. Given the current
page state, propose 3 DIFFERENT next actions to try.

Current page: British Airways booking - flight details
  Price: \$489 | Departure: Dec 15 8:30am | Arrival: Dec 15 8:45pm
  [Button: Select] [Button: Back to results] [Link: Fare rules]

Generate 3 diverse candidate actions (explore different strategies):
Action 1:"""  # Model generates 3 options for tree expansion

AgentQ：エージェント軌跡へのDPO（詳細）

AgentQ (Putta et al. 2024) は、軌跡の結果から選好ペアを自動生成することで、 オフライン選好学習（DPO） と オンラインエージェント実行 を橋渡しします。

パイプライン ：

1. ロールアウト ：現在の方策\(N\)を使い、タスクごとに\(\pi_\theta\)本の軌跡を実行します。

2. 評価 ：実行ベースの報酬（バイナリの成功／失敗またはスカラー指標）で各軌跡を採点します。

3. ペア構築 ：各タスクについて選好ペアを構築します：

   \[ (\tau_w, \tau_l) \text{ where } r(\tau_w) > r(\tau_l) \]

   同じタスクの軌跡では、報酬が最大のものをchosen、最小のものをrejectedとします。

4. DPO更新 ：軌跡レベルの対数確率に対して標準DPO損失を適用します：

\[ \mathcal{L}_{\text{AgentQ}} = -\log \sigma!\left(\beta \left[\log\frac{\pi_\theta(\tau_w)}{\pi_{\text{ref}}(\tau_w)} - \log\frac{\pi_\theta(\tau_l)}{\pi_{\text{ref}}(\tau_l)}\right]\right) \]

5. 反復 ：更新された\(\pi_\theta\)が、次のラウンドで新しい（より良い）軌跡を生成します。

主要な設計上の選択 ：

• MCTS誘導探索 ：ロールアウト段階でLATSを使い、多様で高品質な軌跡（より良い学習データ）を生成します。

• ステップレベルDPO ：完全な軌跡を比較する代わりに、アクションレベルで比較します。同じプレフィックスから、どの次のアクションが成功につながるかを問います。

• 自己対戦による改善 ：各DPO反復がより良い方策を生み、その方策がより良い軌跡を生成し、それがより良い学習ペアを生むという好循環です。

結果 ：WebShopでは、AgentQは3回のDPO反復でベース方策に対する成功率を絶対値で50%\(\rightarrow\)82%改善します。

Voyager：スキルライブラリによる生涯学習（詳細）

Voyager (G. Wang et al. 2023) は 構成的なスキル蓄積 を導入します。エージェントが高レベルのアクションとして使える、再利用可能なコード関数のライブラリを成長させます。

アーキテクチャ ：

1. 自動カリキュラム ：LLMがエージェントの現在のスキル一覧に基づいて、段階的に難しいタスクを提案します：「木を伐採して板材を作れるようになりました。次の挑戦は作業台を作ることです。」

2. スキル生成 ：各タスクについて、エージェントは解決用のJavaScript関数（実行可能コード）を書きます：

\[ \text{skill}_i = \text{LLM}(\text{task}_i, \text{environment_docs}, \text{error_feedback}) \]

3. 検証 ：環境内でコードを実行します。成功すればスキルライブラリに追加し、失敗すればエラーフィードバックを使って（最大5回）反復します。

4. スキルライブラリ （ベクトルDB）：検証済みスキルを次の情報とともに保存します：

   • 関数シグネチャ + docstring（検索用）

   • タスク記述の埋め込み（セマンティック検索用）

   • 依存関係（呼び出す他のスキル）

5. 検索 + 合成 ：新しいタスクでは、最も関連する上位\(k\)件のスキルを取得して合成します：

\[ \text{solution} = \text{LLM}(\text{new_task}, \text{retrieve}(\text{skill_library}, k{=}5)) \]

主要な洞察 ：スキルは 構成的 です。単純で検証済みの関数を組み合わせることで、複雑な振る舞いが生まれます。ライブラリは永続的なのでエージェントは決して忘れず、検証済みスキルだけを追加するため単調に改善します。

Note

Voyager：カリキュラムとスキル生成プロンプト

# === AUTOMATIC CURRICULUM PROMPT ===
CURRICULUM_PROMPT = """You are a curriculum designer for an AI agent.

Agent's current skill inventory:
- mine_wood(): Mines nearby oak/birch trees
- craft_planks(): Converts logs to planks
- craft_sticks(): Converts planks to sticks
- mine_stone(): Mines stone with wooden pickaxe

Propose the next task that:
1. Builds on existing skills (reachable from current abilities)
2. Introduces exactly ONE new concept or challenge
3. Is concrete and verifiable (clear success condition)

Next task proposal:"""
# Output: "Craft a furnace (requires 8 cobblestone blocks arranged
#          in a square). You already know mine_stone()."

# === SKILL GENERATION PROMPT ===
SKILL_GEN_PROMPT = """Write a JavaScript function to accomplish this task
in Minecraft. Use the bot API (bot.dig, bot.craft, bot.equip, etc.)

Task: Smelt 5 iron ingots using a furnace.
Prerequisites available: mine_stone(), craft_furnace(), mine_iron_ore()

Error from previous attempt: "Cannot smelt without fuel in furnace"

Write the corrected function:
async function smeltIronIngots(bot, count=5) {"""

RLEF：実行フィードバックからのRL（詳細）

RLEF (Le et al. 2023) は、 決定論的な実行ベース報酬によるオンラインRL をコード生成エージェントに適用し、エージェント学習の最も単純で効果的なパラダイムを確立します。

学習ループ ：

1. タスクのサンプリング ：学習セットからテストケース\((x, \text{tests})\)を持つコーディング問題を取り出します。

2. 生成 ：現在の方策\(\pi_\theta\)を使い、エージェントが解決軌跡（ファイル読み込み、コード記述、テスト実行）を生成します。

3. 実行 ：サンドボックス環境でテストスイートを実行します。報酬は次のとおりです：

\[ r = \frac{\text{# tests passed}}{\text{# total tests}} \in [0, 1] \]

4. 更新 ：報酬信号として\(r\)を使い、GRPO/PPOを適用します。

5. 反復 ：新しいタスクで何千回も反復します。

実行フィードバックがRLに適している理由 ：

• ノイズゼロ ：人間の選好と異なり、テスト結果は決定論的です。同じコード\(\rightarrow\)同じ報酬が毎回得られるため、RL学習を不安定化する報酬ノイズを排除できます。

• 無限のスケール ：プログラムで無制限のタスク（ランダムアルゴリズム、API統合テスト、データ変換）を生成できます。

• 報酬ハッキングなし ：学習済み報酬モデルと異なり、テストスイートは（テストが適切に書かれていれば）「だます」ことができません。エージェントは実際に問題を解く必要があります。

• 密な信号 ：部分的なテスト通過\(r = 0.6\)は、バイナリの成功／失敗より豊かな勾配を提供します。

OpenHands／SWE-Agent：ソフトウェア工学のためのGRPO

OpenHands (X. Wang et al. 2024) とSWE-Agent (J. Yang et al. 2024) は、コードを読み、パッチを書き、テストスイートを実行してGitHub issueを自律的に解決するエージェントの学習にGRPOを適用します。

学習の詳細 ：

• 環境 ：完全なリポジトリ、テストスイート、開発者ツール（git、grep、lint）を備えたDockerコンテナ。

• アクション空間 ：Bashコマンド、ファイル編集、git操作、テスト実行。

• 軌跡長 ：GitHub issueの解決では通常15–50アクション。

• 報酬 ：バイナリ。生成したパッチがissueの回帰テストに合格するかどうか。

• グループサイズ ：GRPO正規化のため、issueあたり\(N = 8\)–\(16\)本の軌跡。

• カリキュラム ：「good first issue」とラベル付けされたissueから始め、複雑な複数ファイルのリファクタリングへ進みます。

最先端の結果 ：SWE-bench Verifiedでは、RL学習後に解決率が30%\(\rightarrow\)55%（SFTのみのベースラインとの比較）になります。

Note

OpenHands／SWE-Agent：システムプロンプト

SYSTEM = """You are an autonomous software engineer. You are given a
GitHub issue to resolve. You have access to the full repository in
/workspace/ and can execute any bash command.

AVAILABLE COMMANDS:
- bash(command): Execute a shell command
- edit(file, start_line, end_line, new_content): Edit a file
- search(pattern, path): Search for text in files
- submit(): Submit your patch when done

WORKFLOW:
1. Read the issue carefully and understand the expected behavior
2. Explore the codebase to find relevant files
3. Reproduce the bug (write/run a test that fails)
4. Implement the fix
5. Verify the fix (run the test again - must pass)
6. Run the full test suite to check for regressions
7. Submit when all tests pass

RULES:
- Do NOT modify test files unless the issue explicitly asks for it
- Prefer minimal, targeted changes over large refactors
- Always verify your fix before submitting"""

USER = """GitHub Issue #4521: `DataFrame.merge()` silently drops
rows when `on` column contains NaN values.

Expected: NaN keys should be preserved (matched with other NaN rows)
Actual: Rows with NaN keys are dropped entirely

Repository: /workspace/pandas-dev/pandas/"""

Tip

未来：RL + エージェント

この分野は、複数ステップのエージェント軌跡に実行ベース報酬を適用する、 実行時報酬によるオンラインRL というパターンへ収束しつつあります。主な傾向は次のとおりです：

• コード実行やツール成功によるバイナリの成功／失敗報酬を使うGRPO/PPO

• カリキュラム学習：簡単なタスクから始め、段階的に難易度を上げる

• 軌跡レベル最適化（トークンレベルではない） — 複数ステップ系列の最後だけで報酬を与える

• ハイブリッド手法：まれなタスクには検索（非パラメトリック）、一般的なタスクにはRL（パラメトリック）を使う

• スケーリング則：推論時の計算（検索／再試行）を増やす方が、学習時の計算を増やすより有効なことが多い

用例：生産性コパイロットのエージェントRL

この節では、文書、スプレッドシート、プレゼンテーション、メール、メッセージング、クラウドストレージを横断して動作するLLMベースのコパイロットを、エージェントRLで学習するための完全な設計図を示します。

アーキテクチャの概要

生産性コパイロットの形式的MDP定義

生産性コパイロットの環境は、部分観測マルコフ決定過程（POMDP）として形式化されます：

\[ \boxed{\mathcal{M} = \langle \mathcal{S}, \mathcal{A}, \mathcal{T}, \mathcal{R}, \Omega, \mathcal{O}, \gamma \rangle} \]

• \(\mathcal{S}\)： 状態空間 。完全なワークスペース環境の状態、すなわち文書内容、メールスレッド、カレンダーイベント、ファイルシステム、ユーザー権限です。完全には観測できません。エージェントが見られるのはAPIクエリが返すものだけです。

• \(\mathcal{A}\)： アクション空間 。構造化されたAPI呼び出し（後述）。各アクションは、対象アプリ、操作、パラメータを指定するJSONオブジェクトです。

• \(\mathcal{T}\)： 遷移関数 。ほとんどの操作では決定論的（文書への書き込み\(\rightarrow\)文書が更新）ですが、ネットワーク依存のアクション（メール配送時間、Teamsの利用可能性）では確率的です。

• \(\mathcal{R}\)： 報酬関数 。複数の成分からなる（報酬設計の節を参照）。

• \(\Omega\)： 観測空間 。API応答、描画された文書ビュー、エラーメッセージ。

• \(\mathcal{O}\)： 観測関数 。状態を観測へ写像します（API応答の整形、コンテキストウィンドウ制限による切り詰め）。

• \(\gamma = 0.99\)：割引率（長いホライズンで、通常は10–50ステップ）。

Note

具体例：「先週のProject Alphaのメールを要約し、ステータススライドを作成する」

以下では、POMDPの各形式要素を具体的な実現へ対応付けながら、エピソード全体を追跡します。

ユーザー要求 ：「先週のProject Alphaのメールから重要な決定事項を要約し、チームのデッキにステータス更新スライドを追加してください。」

記号	具体的な実現
\(s_0\)	真の状態：過去7日間に「Project Alpha」に言及したメールが受信箱に47件。SharePointに「Q3_Status.pptx」という12枚のPowerPointファイルがあり、ユーザーには編集権限がある。
\(o_0\)	エージェントが観測するもの：ユーザー要求のテキスト + システムプロンプト。エージェントはまだメール件数やデッキ内容を知らない。
\(a_1\)	outlook.search({query: "Project Alpha", last_7_days: true})
\(\mathcal{T}(s_0, a_1)\)	\(s_1\)：システムが一致するメール47件を取得（決定論的）。
\(o_1\)	APIが上位10件のメール件名 + 送信者 + タイムスタンプを返す（コンテキスト制限により切り詰められる — アクション内の\(\mathcal{O}\)）。
\(a_2\)	outlook.read({ids: [top_5_thread_ids]}) — エージェントが最も関連するスレッドを選ぶ。
\(o_2\)	5つのメールスレッドの本文全体（\(\sim\)8Kトークン、\(\mathcal{O}\)による切り詰め後）。
\(a_3\)	内部推論アクション：エージェントが重要な決定事項を統合する：(1) 締切が11月15日に変更、(2) 予算承認、(3) ベンダー決定。
\(a_4\)	sharepoint.read({file: "Q3_Status.pptx", slides: "last"}) — 現在の最後のスライドを確認。
\(o_4\)	最後のスライドは「Q2 Summary」（12枚目）。エージェントは13枚目を追加する。
\(a_5\)	powerpoint.add_slide({file: "Q3_Status.pptx", position: 13, layout: "Title and Content", title: "Project Alpha --- Week 42 Status", content: "Key decisions: 1) Deadline: Nov 15..."})
\(\mathcal{T}(s_4, a_5)\)	\(s_5\)：デッキにスライドを追加（決定論的）。
\(o_5\)	APIが {success: true, slide_id: 13} を返す。
\(R(s_5)\)	報酬の成分： +0.4 タスク完了（スライド作成）、 +0.3 情報品質（正しい決定事項の抽出）、 +0.2 形式準拠（適切なレイアウト）、 +0.05 効率（5アクション、エラーなし）、 -0.0 安全性ペナルティ。 合計：0.95 。

図から分かるPOMDPの要点 ：

• 部分観測 ：\(t=0\)では、エージェントはメール件数やデッキ内容を知らず、状態を発見するためにクエリを実行する必要がある。

• 観測関数\(\mathcal{O}\) ：コンテキストウィンドウ制限のため、APIは47件中上位10件だけを返す。エージェントが見るのは真の状態の射影です。

• 確率的遷移 ：代わりに teams.send_message() を試した場合、配送時間は不確実（受信者がオンライン／オフライン）になる。

• 複数ステップ計画 ：エージェントは2つのアプリケーションにまたがって5つのアクションを連鎖させ、メール要約とスライド内容の整合性を保つ必要がある。

• 割引\(\gamma=0.99\) ：5ステップなら割引は小さい（\(0.99^5 = 0.95\)）ですが、50ステップのタスクでは重要になり、効率的な解決を促す。

アクション空間の設計

アクション空間は 構造化され、型安全で、合成可能 でなければなりません：

Note

生産性コパイロットのアクションスキーマ

{
  "action_type": "api_call",
  "target_app": "outlook | excel | word | powerpoint | teams | sharepoint",
  "operation": "read | write | search | create | delete | modify",
  "parameters": {
    "endpoint": "/me/messages?$filter=subject eq 'Project X'",
    "body": { ... },             // For write operations
    "options": { "top": 10 }     // Pagination, filtering
  },
  "reasoning": "I need to find relevant emails before summarizing"
}

アプリケーション別アクション分類 ：

状態表現

各ステップにおけるエージェントの観測（コンテキストウィンドウ）：

\[ o_t = [\text{system_prompt};; \text{user_intent};; \text{tool_history}_{1:t-1};; \text{current_result}_t] \]

コンテキスト予算の管理 （128Kウィンドウでは重要）：

• システムプロンプト ：2Kトークン（能力、安全規則、出力形式）

• ユーザー意図 + 会話 ：4Kトークン

• ツール履歴 （スライディングウィンドウ）：直近8–12個のアクション + 観測。古いものは要約。合計最大80Kトークン。

• 現在の観測 ：最大32Kトークン（大きなスプレッドシート、メールスレッド）

• 予約 ：エージェントの推論 + 次のアクション生成用に10Kトークン

状態圧縮戦略 ：

• 選択的包含 ：現在のサブゴールに関連するAPI応答だけを含める（補助的な「関連性スコアラー」を使う）。

• 構造化要約 ：大きなスプレッドシートは全データではなく、スキーマ + サンプル行として表現する。

• 階層的メモリ ：完全な軌跡を外部に保存し、圧縮した要約をコンテキストへ注入する。

報酬設計：多目的信号

生産性コパイロットの報酬関数は、複数の目的のバランスを取る必要があります：

\[ \boxed{R(\tau) = \alpha_1 R_{\text{task}} + \alpha_2 R_{\text{quality}} + \alpha_3 R_{\text{efficiency}} + \alpha_4 R_{\text{safety}} + \alpha_5 R_{\text{user}}} \]

生産性コパイロット学習における報酬成分

中間報酬（密な信号） ：

• 成功したAPI呼び出し（200応答）：+0.05

• 正しい情報取得（後続利用で検証）：+0.10

• エラーから適切に復旧（修正したパラメータで再試行）：+0.08

• APIエラー（4xx/5xx）：–0.03

• 同一アクションの反復（ループ検出）：–0.10

• 意図が本当に曖昧なときに確認質問をする：+0.05

エンドツーエンド学習パイプライン

Important

生産性コパイロットのRL学習パイプライン

フェーズ1：教師ありファインチューニング（基盤）

1. 生産性タスクの人間実演軌跡を5万–20万件収集（テレメトリ、アノテータ、または合成生成）。

2. ReAct形式の（命令、軌跡）ペアでベースLLMをSFTする。

3. 検証：保留タスクでエージェントが40–60%のタスク完了率を達成するはず。

フェーズ2：シミュレーション環境の構築

1. モックAPIエンドポイント、合成メールボックス、文書、カレンダーを備えた サンドボックス環境 を構築する。

2. 各「ユーザー」に現実的なプロファイルを持たせる：500通以上のメール、20件以上の文書、カレンダーイベント、Teamsチャンネル。

3. タスク生成器：多様な命令–検証ペアを生成する：「AliceからのQ4予算に関するメールをすべてFinanceフォルダへ移動」 + 検証関数。

フェーズ3：オンラインRL学習（GRPO）

1. タスクバッチをサンプリング（反復あたり256タスク）。

2. サンドボックス環境で方策\(N=8\)を使い、タスクごとに\(\pi_\theta\)本の軌跡を生成する。

3. 軌跡を実行し、検証関数から報酬を収集する。

4. GRPOアドバンテージを計算（タスクごとに8軌跡をグループ正規化）。

5. クリップ付き目的関数 + SFTモデルに対するKLペナルティで方策を更新する。

6. 500反復ごとに保留ベンチマーク（200タスク、5難易度）で評価する。

フェーズ4：Human-in-the-Loopの改善

1. 社内のドッグフードユーザー（1000人以上、2週間）へ展開する。

2. サムズアップ／ダウン信号 + 自由記述の修正を収集する。

3. A/B展開（旧方策対新方策）からDPO選好ペアを構築する。

4. 人間の選好に対してDPOファインチューニングを1–2ラウンド適用する。

シミュレーション環境のアーキテクチャ

Note

サンドボックス環境（簡略版）

class ProductivityEnvironment:
    def __init__(self, user_profile: UserProfile):
        self.mailbox = SyntheticMailbox(user_profile.emails)
        self.drive = SyntheticOneDrive(user_profile.files)
        self.calendar = SyntheticCalendar(user_profile.events)
        self.teams = SyntheticTeams(user_profile.channels)
        self.step_count = 0
        self.max_steps = 50

    def step(self, action: dict) -> Tuple[Observation, float, bool]:
        """Execute action, return (observation, reward, done)."""
        self.step_count += 1

        # Route to appropriate app handler
        handler = self.get_handler(action["target_app"])
        try:
            result = handler.execute(action["operation"], action["parameters"])
            obs = Observation(status=200, body=result)
            reward = 0.05  # Successful API call
        except APIError as e:
            obs = Observation(status=e.code, body=str(e))
            reward = -0.03

        # Check terminal condition
        done = self.step_count >= self.max_steps
        return obs, reward, done

    def evaluate(self, task: Task) -> float:
        """Check if task objective is achieved (terminal reward)."""
        return task.verification_fn(self)  # 0.0 or 1.0

タスクカリキュラムの設計

学習の有効性は、タスク難易度を段階的に上げることに大きく左右されます：

生産性コパイロットのカリキュラムレベル

カリキュラム戦略 ：

• 学習初期はL1–L2タスクを80%、L3を20%から始める。

• 現在のレベルで成功率が70%を超えたら次のレベルへ進む。

• 壊滅的忘却を防ぐため、常に簡単なタスクを10–20%維持する。

• 収束後の最終混合：L1 10%、L2 15%、L3 25%、L4 30%、L5 20%。

安全性とガードレール

Important

生産性コパイロットの安全性フレームワーク

ハード制約 （アクションを即時拒否、報酬 = –1.0）：

• ユーザー確認なしで外部の宛先へメール／メッセージを送信する

• ファイル／メールを恒久的に削除する（ソフト削除のみ許可）

• 共有リソースの権限を変更する

• 許可された範囲を超えて他ユーザーのメールボックスやファイルへアクセスする

• 1バッチで100件を超えるアイテムにアクションを実行する（大量削除／移動事故を防止）

ソフト制約 （報酬にペナルティ、エージェントは避けるべき）：

• ユーザーにプレビューを見せず下書きを送信：–0.2

• 意図を先に述べず不可逆な変更を行う：–0.15

• 機密ラベル（confidential、attorney-client）へアクセス：–0.3

• 明示的な委任なしに「代理送信」を使う：–0.25

確認プロトコル ：「高インパクト」（送信、削除、外部共有）に分類されるアクションでは、エージェントは次を行う必要があります：

1. 意図するアクションを自然言語で述べる

2. 送信／変更される内容のプレビューを表示する

3. 実行前に明示的なユーザー確認を待つ

これは環境レベル（サンドボックスが未確認の高インパクトアクションを拒否）と報酬関数（確認を省略した場合のペナルティ）の両方で強制されます。

複数アプリワークフローでの信用割当

主な課題は、20ステップのアプリ横断ワークフローで、どのステップが成功または失敗に寄与したかを特定することです。

アプローチ：階層的な報酬分解

1. サブゴール検出 ：ユーザー命令を検証可能なサブゴールに分解する：

   • 「Q4予算メールを探す」\(\rightarrow\)サブゴール1（検証：関連メールを取得）

   • 「数値を抽出する」\(\rightarrow\)サブゴール2（検証：正しい値を解析）

   • 「Excelシートを作る」\(\rightarrow\)サブゴール3（検証：シートが正しいデータで存在）

2. サブゴール報酬 ：各サブゴールの完了時に中間報酬\(r = +0.2\)を割り当てる。

3. 軌跡の分割 ：最終タスクが失敗したら、最初に失敗したサブゴールを特定する。そのサブゴールの範囲内のアクションだけに負の報酬を適用する。

4. 反実仮想推定 ：「この特定のアクションが違っていたらタスクは成功したか？」を価値関数で推定する。

\[ R_{\text{step}}(t) = \underbrace{R_{\text{sub-goal}}(t)}_{\text{did current sub-goal succeed?}} + \underbrace{\gamma^{T-t} R_{\text{terminal}}}_{\text{discounted final reward}} + \underbrace{r_{\text{intermediate}}(t)}_{\text{per-step API success/failure}} \]

スケーリングとインフラ

計算資源要件 （70Bパラメータモデルの推定）：

スループット最適化 ：

• 非同期ロールアウト ：軌跡生成と勾配更新を分離する。前のバッチを学習している間も継続的に生成する。

• バッチ化環境 ：128個のサンドボックス環境を並列実行し、それぞれ異なるタスクを処理する。

• KVキャッシュ共有 ：タスクあたり\(N=8\)本の軌跡は同じプロンプトプレフィックスを共有するため、プレフィックスキャッシュで重複計算を避ける。

• 選択的バックプロパゲーション ：アクショントークン（観測／システムプロンプトではない）だけで勾配を計算する。バックワードFLOPSを40–60%削減する。

評価フレームワーク

生産性コパイロットの評価軸

ベンチマークスイート （提案）：

• ProdBench-Easy （200タスク）：単一アプリ、1–3ステップ。ベースライン確立。

• ProdBench-Hard （200タスク）：アプリ横断ワークフロー、10–30ステップ。エンドツーエンド能力。

• ProdBench-Safety （100タスク）：安全でないアクションを誘発しようとする敵対的プロンプト。\(<0.1%\)未満の違反率を維持する必要がある。

• ProdBench-Robustness （100タスク）：曖昧な命令、注入されたAPIエラー、権限不足を含むタスク。段階的な機能縮退を検証する。

本番展開から得られる教訓

Tip

生産性エージェントRLの実践的洞察

1. SFT品質が下限 ：RLはSFTが提供するものを改善できるだけです。SFTモデルが有効なGraph API呼び出しを整形できなければ、RLがそれを発見することはありません。フェーズ1のデータ品質に大きく投資してください。

2. 報酬ハッキングは避けられない ：エージェントは必ず近道を見つけます。よくある例：

   • スプレッドシートタスクを「完了」するため空のExcelファイルを作成する（存在チェックを通過）

   • 実際にはアクションを実行せず「Done」と返信する

   • 曖昧な検証関数を悪用する

   対策 ：多層検証（形式 + 内容 + 意味的な正しさ）。

3. APIレート制限が重要 ：本番ではワークスペースAPIにスロットリング（429応答）があります。並列リクエストを大量送信する方策を避けるため、現実的なレート制限で学習します。

4. コンテキストウィンドウがボトルネック ：豊富なAPI応答を含む20ステップの軌跡は、容易に80K以上のトークンを消費します。技法は観測要約、履歴の選択、階層的コンテキスト管理です。

5. ユーザー意図は曖昧なことが多い ：「受信箱を整理して」はユーザーによって意味が異なります。不確実性が高いときに確認質問をするよう学習させます（適切な確認には報酬、過剰な確認にはペナルティ）。

6. 簡単に始め、段階的にスケールする ：Outlookだけのタスク（量とテレメトリデータが最も多い）から始め、Excel、アプリ横断へ広げます。各アプリには固有の失敗モードがあります。

完全な学習レシピ

生産性コパイロットRL学習の推奨ハイパーパラメータ

用例：研究エージェントをゼロから構築する

この用例では、本稿全体で説明した技法を使い、仮説を立て、文献を検索し、データを分析し、コードを書き、実験を実行し、最終報告書を作成できる完全自律の 研究エージェント （LLM）を構築する方法を示します。

問題定義

Important

研究エージェントの要件

入力 ：研究上の問い（例：「7BモデルのGRPO収束に対する学習率ウォームアップ期間の効果は何か？」）

出力 ：方法論、実験、結果、結論を含む完全な研究報告書。

必要な能力 ：

1. 文献検索 ：arXiv、Semantic Scholarを検索し、関連論文を見つける

2. 仮説生成 ：背景知識から検証可能な仮説を立てる

3. 実験設計 ：適切な統制を備えた学習スクリプトを書く

4. コード実行 ：実験を実行し、指標を収集する

5. データ分析 ：ログを解析し、統計量を計算し、プロットを生成する

6. 科学的執筆 ：発見を一貫した報告書に統合する

7. 自己修正 ：失敗した実験を検出し、パラメータを変更して再試行する

MDPの定式化

Important

研究エージェントのMDP

• 状態\(s_t\)：システムプロンプト + 研究上の問い + アクション／観測の完全な履歴（ツール出力、コード結果、検索結果）。コンテキストウィンドウ：128Kトークン。

• アクション\(a_t\)：アクション空間からの構造化ツール呼び出し（後述） + 推論軌跡（CoT）。

• 遷移\(T(s_{t+1}\vert s_t, a_t)\)：決定論的。アクション + ツール出力をコンテキストへ追加する。

• 報酬\(R\)：報告書の品質に基づく疎な終端報酬（下記の報酬設計を参照）。

• ホライズン ：20–100ステップ（典型的な研究軌跡）。

• 割引\(\gamma = 1.0\)（エピソード型。有限タスクでは割引なし）。

アクション空間

研究エージェントのツール／アクション空間

アーキテクチャ：モデルとインフラの選択

Important

アーキテクチャ決定 — 本稿の概念を適用

• ベースモデル ：Qwen-2.5 72B（強い推論 + コード）。QLoRAファインチューニング（\(r=32\)、全線形層）— LoRAの節を参照。

• 推論 ：TP=4のvLLM、プレフィックスキャッシュを有効化（ロールアウト間でシステムプロンプトを共有）— vLLMの節を参照。

• 学習 ：研究上の問いごとに\(N=4\)本の軌跡を使うGRPO — 価値モデルは不要（GRPOの節を参照）。

• ハードウェア ：\(\times\) H100ノード。QLoRAアダプタは48 GBに収まり、vLLM生成は残りの容量を使う。

• コンテキスト管理 ：Flash Attentionを使う128Kコンテキスト（Flash Attentionの節を参照）。コンテキストを超える軌跡にはスライディングウィンドウ要約を使う。

• 投機的デコーディング ：長い研究軌跡の高速生成にEagleヘッドを使う（投機的デコーディングの節を参照）。

報酬設計

Important

多成分の研究報酬

終端報酬はエージェントがsubmitを呼び出した時点で計算します： \[ R = w_1 R_{\text{quality}} + w_2 R_{\text{correctness}} + w_3 R_{\text{novelty}} + w_4 R_{\text{efficiency}} + w_5 R_{\text{format}} \]

成分	重み	測定方法
\(R_{\text{quality}}\)	0.30	LLM-as-a-judge（GPT-4が明瞭さ、深さ、厳密さについて報告書を1–10で評価）
\(R_{\text{correctness}}\)	0.30	コードがエラーなく実行され、結果が再現可能
\(R_{\text{novelty}}\)	0.15	LLM判定：報告書は論文の要約を超える洞察を提供しているか
\(R_{\text{efficiency}}\)	0.15	少ないステップへのボーナス：\(R_{\text{eff}} = \max(0, 1 - \text{steps}/100)\)
\(R_{\text{format}}\)	0.10	報告書に必須の全節（導入、方法、結果、結論）がある

中間シェーピング ：コード実行の成功ごとに+0.1、ランタイムエラーごとに\(-\)0.05（最初から正しいコードを書くことを促す）。

Warning

報酬ハッキングのリスク

• 偽の結果 ：エージェントが実験出力を捏造する。対策：実行ログと報告された数値を照合し、コードが実際に実行されたことを検証する。

• 浅い報告書 ：エージェントが論文の要旨をそのままコピーする。対策：新規性報酬 + 盗用検出。

• 長さの悪用 ：長い報告書ほど高得点になる。対策：効率報酬 + 長さペナルティ。

• 簡単な問い ：エージェントが難しい研究上の問いを避ける。対策：難易度レベルを持つカリキュラム。

学習パイプライン

1. フェーズ1 — SFTウォームアップ （500ステップ）：

   • ツールを使う人間の研究者による専門家研究軌跡を200件収集

   • 完了部分のみのマスキング（ツール出力をマスク）を使い、成功軌跡でSFTする

   • これにより、ツール利用構文と基本的な研究ワークフローを教える

2. フェーズ2 — GRPO学習 （3000ステップ）：

   • プロンプトプール：10領域（ML、NLP、CV、システムなど）にまたがる500の研究上の問い

   • 問いごとに\(N=4\)本の完全な研究軌跡を生成

   • 多成分報酬で各軌跡をスコアリング

   • GRPOアドバンテージ：\(\hat{A}_i = (R_i - \mu_G) / \sigma_G\)

   • クリップ付き目的関数（クリップ\(\epsilon=0.2\)、KL\(\beta=0.05\)）で方策を更新

   • カリキュラム：「Xについての発見を要約」する簡単なタスクから始め、「Xについて実験を設計して実行」へ進む

3. フェーズ3 — 棄却サンプリング・ファインチューニング （200ステップ）：

   • 難しい問いごとに16軌跡を生成し、報酬上位2件を残す

   • これらの高品質軌跡でSFTする

   • 最も難しい研究タスクでの性能を安定させる

具体例：完全なMDP軌跡

MDPの全要素が実際にどう連携するかを示すため、問いから提出までの研究エピソード全体を追跡し、各ステップに形式的なMDP要素を付記します。

Note

研究エージェントの軌跡 — 完全なMDPトレース

研究上の問い ：「GRPOのグループサイズを\(N=16\)以上に増やすと、数学推論性能は向上するか？」

以下は、各ステップの状態\(s_t\)、アクション\(a_t\)、遷移\(T\)、観測\(o_t\)、累積報酬を明示した完全な軌跡です。

\(t\)	要素	説明
	\(a_0\)	think：「GRPOグループサイズのアブレーション論文を探し、統制実験を行う必要がある。」
	\(o_0\)	内部推論（ツール出力なし）。シェーピング報酬：\(r_0 = 0\)。
1	\(s_1\)	\(s_0 \oplus (a_0, o_0)\) — コンテキストに推論計画が含まれる。
	\(a_1\)	search_papers(query="GRPO group size ablation math")
	\(o_1\)	5本の論文を返す：[DAPO、DeepSeek-Math、Dr. GRPO、...]. \(r_1 = 0\)。
2	\(s_2\)	\(s_1 \oplus (a_1, o_1)\) — コンテキストに検索結果。
	\(a_2\)	read_paper(id="DAPO", sections=["experiments", "ablations"])
	\(o_2\)	主要な発見：「コードタスクでは\(N=16\)以上で限界効用が逓減。数学では未検証。」\(r_2 = 0\)。
3	\(s_3\)	\(s_2 \oplus (a_2, o_2)\) — 文献上のギャップを特定。
	\(a_3\)	think：「DAPOはコードだけを検証した。Llama-3 8BでGSM8Kに対して\(N \in \{4, 8, 16, 32, 64\}\)をテストする。統制：総学習トークン数を同じにする。」
	\(o_3\)	仮説を形成。\(r_3 = 0\)。
4	\(s_4\)	\(s_3 \oplus (a_3, o_3)\) — コンテキストに実験計画。
	\(a_4\)	write_code("train_grpo_gsm8k.py") — group_size引数、適切なシード、GSM8Kテスト分割での評価を備えた85行のスクリプト。
	\(o_4\)	ファイルの書き込みに成功。\(r_4 = 0\)。
5	\(s_5\)	\(s_4 \oplus (a_4, o_4)\) — コードがワークスペースで利用可能。
	\(a_5\)	execute_code("python train_grpo_gsm8k.py --N 4 --seed 42")
	\(o_5\)	Accuracy: 67.2% (CI: 65.1--69.3)。\(r_5 = +0.1\)（実行成功）。
6–8	\(a_{6\text{--}8}\)	\(N=8, 16, 32\)、\(\to\)、\(r_t = +0.1\)を実行undefined結果：71.4%、74.8%、75.9%。各undefined。
9	\(s_9\)	4つのデータ点をコンテキストに含む。
	\(a_9\)	execute_code("python train_grpo_gsm8k.py --N 64 --seed 42")
	\(o_9\)	Accuracy: 75.6% (CI: 73.4--77.8) — \(N=32\)からわずかに低下。\(r_9 = +0.1\)。
10	\(s_{10}\)	5つの結果を利用可能。
	\(a_{10}\)	compute_stats(test="paired_t_test", data=[67.2, 71.4, 74.8, 75.9, 75.6], groups=[4,8,16,32,64])
	\(o_{10}\)	\(p < 0.01\)について\(N=4\)、\(N=16\)について\(p = 0.72\)、\(N=32\)について\(N=64\)（有意ではない）。\(r_{10} = 0\)。
11	\(s_{11}\)	限界効用の逓減を示す統計的証拠。
	\(a_{11}\)	plot_data(x=[4,8,16,32,64], y=[67.2,71.4,74.8,75.9,75.6], xlabel="Group Size N", ylabel="GSM8K Accuracy (%)", title="GRPO Group Size vs Math Reasoning")
	\(o_{11}\)	プロットをresults/group_size_curve.pngに保存。\(r_{11} = 0\)。
12	\(s_{12}\)	完全な証拠を収集。
	\(a_{12}\)	write_report：4節の報告書（導入、方法、図付き結果、結論：「\(N=16\)が最適。\(N=64\)は改善せず、計算量を4\(\times\)増やす」）。
	\(o_{12}\)	報告書を書き込み（2,100語）。\(r_{12} = 0\)。
13	\(a_{13}\)	submit — エピソード終了。
	\(R_{\text{terminal}}\)	LLM判定スコア：品質=8/10、コード正解、新規性あり（DAPOを数学へ拡張）、13ステップ、全節あり。

終端報酬の計算 ： \[ R = \underbrace{0.30 \times \tfrac{8}{10}}_{\text{quality}} + \underbrace{0.30 \times 1.0}_{\text{correct}} + \underbrace{0.15 \times \tfrac{7}{10}}_{\text{novelty}} + \underbrace{0.15 \times (1 - \tfrac{13}{100})}_{\text{efficiency}} + \underbrace{0.10 \times 1.0}_{\text{format}} \\ = 0.24 + 0.30 + 0.105 + 0.13 + 0.10 = \mathbf{0.875} \]

中間シェーピングの合計 ：\(5 \times (+0.1) = +0.5\)（コード実行成功5回）。

GRPOの文脈 ：この軌跡は\(N=4\)グループで最高得点（他は0.61、0.72、0.53）でした。GRPOアドバンテージ： \[ \hat{A} = \frac{0.875 - \bar{R}}{\sigma_R} = \frac{0.875 - 0.684}{0.129} = +1.48 \quad \text{(strongly reinforced)} \]

図から分かるMDPの主要な性質 ：

• 決定論的\(T\) ：各ツール呼び出しは予測可能な状態拡張\(s_{t+1} = s_t \oplus (a_t, o_t)\)を生成する。

• 疎な終端報酬 ：本当の品質信号はsubmit時にだけ得られ、中間シェーピングは小さい。

• 長いホライズン ：\(\gamma = 1.0\)ステップ、undefined（エピソードタスクでは割引なし）。

• 自己修正の機会 ：ステップ9で\(N=64\)が改善しないことを観測し、都合の良い結果だけを選ぶのではなく結論を調整する。

• アクションの多様性 ：推論（think）、情報収集（search、read）、実行（write_code、execute）、分析（compute_stats、plot）、出力（write_report、submit）を混ぜる。

主要な設計決定とトレードオフ

研究エージェントの設計決定と、本稿の節との対応

評価

Important

研究エージェントの評価フレームワーク

• 保留された問い （50件）：学習中には見ていない、多様な領域の研究上の問い。

• 人間評価 ：領域専門家が品質、正確さ、実用性を1–5で評価する。

• 再現性 ：報告書からエージェントのコードを再実行し、結果が一致することを確認する。

• 比較ベースライン ：(1) ゼロショットGPT-4 + ツール（RL学習なし）、(2) SFTのみのエージェント、(3) 人間の研究者。

• 効率指標 ：タスク難易度で正規化した完了までのステップ数。

期待される結果 （同様のエージェントRL研究に基づく）：

エージェント	報告品質（1–5）	平均ステップ
ゼロショットGPT-4 + ツール	2.8	25
SFTのみ	3.4	18
GRPO学習済み（本手法）	4.1	14
人間の研究者	4.5	N/A

教訓と失敗モード

Warning

研究エージェント学習でよくある失敗

• 無限ループ ：エージェントが進展せず論文検索を繰り返す。対策：ステップ予算 + 同じ引数のツール呼び出し反復へのペナルティ。

• コードデバッグの迷走 ：1つのバグの修正に20ステップ以上費やす。対策：再試行を3回に制限し、3回失敗したら方針を捨てて別案を試す。

• 幻覚した引用 ：論文タイトル／結果を捏造する。対策：ツール出力で全引用の存在を検証し、検証できない主張にペナルティを与える。

• 早すぎる提出 ：長い軌跡へのペナルティを避けるため、不完全な報告書を提出する。対策：有効な提出とみなす最低品質閾値を\(R > 0.4\)にし、それ未満は失敗として扱う。

• 判定器への報酬ハッキング ：LLM判定器では高得点だが科学的には浅い文章を生成するよう学習する。対策：判定モデルをローテーションし、定期的に人間評価を報酬へ含める。

LLMエージェントRLの最先端

LLMエージェント向けRL技法は、 オンポリシー方策勾配 と きめ細かな信用割当 を組み合わせます。エージェントはツール操作、APIクエリ、コード実行を含む複雑な複数ターン軌跡を実行するため、標準的な単一ターンのアラインメントアルゴリズムには大幅な変更が必要です。

主要ベースライン：エージェント向けGRPO

DeepSeek-R1 (DeepSeek-AI et al. 2025) によって広く知られるようになった GRPO (Shao et al. 2024) は、エージェント学習の標準になりつつあります。タスクごとに\(N\)本の完全な軌跡をサンプリングし、メモリを大量に消費するクリティックネットワークを不要にします。

タスクプロンプト\(q\)に対して、GRPOは\(N\)本のエージェント軌跡\(\{o_1, o_2, \dots, o_N\}\)から\(\pi_{\theta_{\text{old}}}\)をサンプリングします。各軌跡のアドバンテージは、グループに対する報酬を正規化して計算します：

\[ \boxed{A_i = \frac{r(o_i) - \frac{1}{N}\sum_{j=1}^N r(o_j)}{\text{std}(r(o_1), \dots, r(o_N))}} \]

KL正則化を伴うGRPO目的関数：

\[ L_{\text{GRPO}}(\theta) = \frac{1}{N} \sum_{i=1}^N \min!\left( \frac{\pi_\theta(o_i|q)}{\pi_{\theta_{\text{old}}}(o_i|q)} A_i,; \text{clip}!\left(\frac{\pi_\theta(o_i|q)}{\pi_{\theta_{\text{old}}}(o_i|q)}, 1{-}\epsilon, 1{+}\epsilon\right) A_i \right) - \beta, D_{\text{KL}}(\pi_\theta | \pi_{\text{ref}}) \]

Tip

GRPOがエージェント学習を支配する理由

• クリティックなし ：GPUメモリを50%節約します。エージェント軌跡がすでに32K–128Kトークンの巨大なコンテキストウィンドウを消費する場合に重要です。

• 自然な適合 ：エージェントタスクは検証可能なバイナリ報酬（テスト成功／失敗、目標達成／未達）を持つことが多く、グループ相対正規化に最適です。

• 探索 ：タスクごとに\(N\)本の多様な軌跡をサンプリングすることで、異なるツール利用戦略を自然に探索します。

インタラクティブエージェント向けPPO

PPO (Schulman et al. 2017) は、ステップレベルの価値推定が役立つ非常に確率的な環境で動作するエージェントにとって、依然として有用です。クリティックはステップごとのアドバンテージ信号を提供し、ツール出力が予測不能な場合に、より細かな信用割当を可能にします：

• GAEによるステップレベルのアドバンテージ推定が、可変長のツール出力を扱う

• 価値ヘッドが「この時点からこの軌跡が成功する可能性はどれくらいか」を予測する

• 外部ツールが報酬分散を急増させる壊滅的エラーを返す場合に、より安定する

• トレードオフ：\(2\times\)のメモリが必要（クリティック）が、より密な学習信号を提供する

きめ細かなターンレベルの信用割当

エージェントRLの核心的課題は 疎な報酬問題 です。エージェントが20個のツールアクションを実行して最後にユニットテストに失敗すると、終端報酬\(0\)が20個すべてのアクションを等しく罰します。現代的な解決策は次のとおりです：

Important

検証可能な報酬からの強化学習（RLVR）

決定論的な中間チェックポイント でモデルに報酬を与える：

• Bashコマンドが正常にコンパイル\(\rightarrow\) +0.1

• ブラウザエージェントが正しいHTML要素を対象\(\rightarrow\) +0.2

• SQLクエリが空でない結果を返す\(\rightarrow\) +0.1

• 最終テストスイートが成功\(\rightarrow\) +1.0（終端）

中間報酬は最終ステップだけでなくすべてのステップに勾配信号を与えます。これにより、疎な報酬だけの場合と比べて学習が3–5\(\times\)高速化します。

Important

複数ターン軌跡の分割

フレームワークは複数ターンのエージェント実行を、個別の独立したステップに分割します。信用割当モジュールが、 軌跡を壊した正確なサブステップ を特定します：

1. 成功したプレフィックス（ステップ1–\(k\)）を再生

2. 最初の分岐点（誤ったステップ\(k+1\)）を特定

3. その特定のステップだけに負の報酬を割り当てる

4. 正しいプレフィックスのステップには中立／正の報酬を割り当てる

これにより、すでに正しい振る舞いを損なわず、外科的な方策更新が可能になります。

代替パラダイム

• 反復STaR（Self-Taught Reasoner） (Zelikman et al. 2022)：連続RLではなく、反復的なオフラインループを使います。軌跡を生成\(\rightarrow\)失敗をフィルタ\(\rightarrow\)成功例でSFT\(\rightarrow\)反復。スケールしやすく、RLの不安定性を避けます。各反復で推論能力をブートストラップします。

• 強化学習世界モデル学習（RWML） (Yu et al. 2026)：報酬ハッキングに対抗するため、エージェントにアクションの意味的帰結を予測させます。環境状態がどう変わるかを正確に予測すると補助報酬を受け取ります（例：SQL実行前にデータベーステーブルの変化を予測）。表面的な報酬稼ぎではなく本当の理解を促します。

• LATS（Language Agent Tree Search） (A. Zhou et al. 2024)：エージェントのアクション系列にモンテカルロ木探索を適用します。各ステップで複数の候補アクションを展開し、結果をシミュレートし、木を通じて報酬をバックプロパゲーションします。RLの価値推定と推論時の計算スケーリングを組み合わせます。

主要手法の比較

LLMエージェント向けRLパラダイムの比較