今回の論文
今回取り上げるのは、Zhiyuan He、Siwei Zhang、Zhiwen Zhou、Yuqing Yang、Yu Kang、Yuge Zhang、Luna K. Qiu、Tin Yan Tsui、Jiahang Xu、Chong Luo による論文「Agent Lightning v1.0: Towards Harnessed Agentic RL」です。2026年8月18日に arXiv で公開されました。公開元は arXiv、URL は https://arxiv.org/abs/2608.17528、DOI は https://doi.org/10.48550/arXiv.2608.17528 です。研究分野は、AIエージェント、強化学習、LLMポストトレーニング、コーディングエージェントです。
この論文を選んだ理由は、AIエージェントを「プロンプトやツール設計で動かすもの」から一歩進めて、「実際に動いているエージェントの実行環境ごと強化学習で改善するもの」として扱っているからです。特に、コーディングエージェントや検索エージェントのように、ツール実行、コンテキスト管理、サブエージェント、リトライ処理が絡むシステムをどう学習対象にするかは、今後のAI開発基盤で重要になるテーマです。
どんな技術か
Agent Lightning v1.0は、既存のAIエージェントをほぼそのまま使いながら、強化学習でLLMを改善するためのフレームワークです。
ここで重要なのは、論文が「エージェントの中身を訓練フレームワークに移植する」方法ではなく、「実運用と同じエージェントハーネスを通して学習する」方法を扱っている点です。エージェントハーネスとは、ツール呼び出し、コンテキスト構築、実行環境、制御フロー、サブエージェント呼び出しなどを管理する外側の仕組みです。
従来のエージェント強化学習では、訓練エンジンが環境とのやり取りを直接管理する前提になりがちでした。しかし、実際のAIエージェントはLangChain、OpenAI Agents SDK、AutoGen、コーディングエージェント用ハーネスなど、複雑な実行基盤の上で動きます。Agent Lightning v1.0は、この現実に合わせて、LLM APIの入口をプロキシし、そこで観測した「モデルへのリクエスト」と「モデルの応答」を訓練データとして扱います。
論文では、この枠組みを Harnessed Agentic RL と呼んでいます。つまり、デプロイ時に使うハーネスがそのまま学習ループに参加するエージェント向け強化学習です。
課題
AIエージェントを強化学習で改善したい場合、難しいのは「モデル単体の出力」だけを見ればよいわけではないことです。エージェントは、モデルの応答を受け取り、ツールを呼び出し、結果を整形し、必要ならコンテキストを要約し、次のモデル呼び出しを作ります。つまり、実際の性能はモデルとハーネスの共同作業で決まります。
既存の方法では、強化学習フレームワークの中にエージェントループを実装し直すことが多くありました。この方法は研究用途では扱いやすい一方で、実運用のエージェントとはずれが出ます。ツール仕様、メッセージテンプレート、例外処理、リトライ、ファイル操作、サブエージェントの分岐などを完全に再現するのは簡単ではありません。
Agent Lightning v1.0が扱う課題は、まさにこのずれです。実運用のハーネスをそのまま使えば、エージェントの本当の挙動に近いデータが得られます。しかし、訓練エンジンから見ると、環境状態やハーネス内部状態は直接見えません。見えるのは、LLM API境界を通った複数のリクエストと応答だけです。
このとき、実際のAIシステムではいくつかの問題が起きます。まず、連続した会話がトークン列としてきれいにつながるとは限りません。次に、1つのタスク実行が複数の訓練サンプルへ分裂するため、報酬やadvantageをどう割り当てるかが難しくなります。さらに、サンプル数が実行後までわからないので、GPU上のミニバッチ構成や損失正規化も不安定になりえます。
用語解説
- エージェントハーネス
- LLMの周辺で、ツール実行、コンテキスト構築、状態管理、例外処理、サブエージェント呼び出しなどを担う実行基盤です。この論文では、モデルだけでなくハーネス込みの実行を学習対象にするため、最重要の前提になります。
- Harnessed Agentic RL
- デプロイ時と同じエージェントハーネスを使い、そのハーネスが作るLLMリクエストと応答から強化学習する考え方です。訓練用に簡略化したエージェントループではなく、実運用に近い挙動を学習に反映できる点が重要です。
- rollout
- 強化学習で、1つのタスクをエージェントが実行して得られる一連の行動と結果です。Agent Lightning v1.0では、1つのrolloutが複数のLLM呼び出しや複数の訓練サンプルに分かれるため、報酬の扱いが難しくなります。
- retokenization
- 一度生成されたテキストを再びトークン化すると、元のトークン列と一致しないことがある現象です。エージェントの会話履歴を次のプロンプトに入れるときに起きやすく、訓練サンプルを安全に結合できるかを左右します。
- advantage
- 強化学習で、ある行動が平均的な期待値よりどれだけ良かったかを表す量です。この論文では、advantageをサンプル単位で計算するかrollout単位で計算するかが、学習の安定性に関わる重要な論点になります。
技術の仕組み
Agent Lightning v1.0の基本アイデアは、エージェントの実行と学習を疎結合にし、LLM APIの境界で学習に必要な情報を集めることです。ハーネスは従来どおりタスクを実行し、ツールを呼び、次のプロンプトを組み立てます。一方、訓練側は各LLM呼び出しを観測し、強化学習用のサンプルへ変換します。
LLMエンドポイントを学習用の観測点にする
通常のエージェントは、モデルAPIへプロンプトを送り、応答を受け取り、その応答をもとに次の処理を進めます。Agent Lightning v1.0では、このモデルAPIの手前にプロキシを置きます。ハーネスから見ると通常のLLMエンドポイントにアクセスしているように見えますが、プロキシは各呼び出しのプロンプト、応答、トークン列、ログ確率などを記録します。
この構成により、エージェント実装を訓練フレームワークへ大きく書き換えなくても、実行ログを強化学習の材料にできます。論文では、ハーネス側が環境との相互作用ループを持ち、訓練側はリクエストとレスポンスの列を観測する、という役割分担を明確にしています。
従来のエージェント強化学習では、プロンプト履歴が 前のプロンプト、前の応答、環境観測 のように連続したトークン列として伸びていく前提を置きやすくなります。しかし、Harnessed Agentic RLでは、各LLM呼び出しのプロンプトはハーネスが都度作ります。サブエージェントが呼ばれたり、コンテキストが要約されたり、ツール結果が整形されたりするため、単純な1本のトークン列にはなりません。
retokenizationとサンプル結合
論文が特に丁寧に扱っているのが、retokenizationによるトークン列のずれです。
たとえば、ある応答が生成時には特定のトークン分割で出力されたとしても、その応答テキストが会話履歴に入って次のプロンプトとして再トークン化されると、別のトークン分割になることがあります。また、チャットテンプレートがメッセージ境界に特殊トークンや改行を挿入したり、ツール呼び出しのJSONを正規化したりすることで、テキストそのものが少し変わる場合もあります。
これは、複数のLLM呼び出しを1つの長い訓練サンプルとして結合できるかに直結します。もし本来モデルが見ていないトークン列を「見たことにして」訓練すると、off-policyなずれが入ります。Agent Lightning v1.0は、連続する呼び出しがトークンレベルで正確にprefix関係を満たす場合だけ結合し、そうでない場合は新しいサンプルとして分ける best-effort sequence merging を採用します。
この設計は、計算効率と正しさの妥協点です。全呼び出しを独立に訓練すれば正確ですが、共通プロンプトの再計算が多くなります。木構造のprefix共有を実装すれば効率は上がりますが、専用のattention maskや分散学習バックエンドが必要になります。Agent Lightning v1.0は、標準的なdense causal attentionを使いやすい範囲で、トークンレベルの正しさを優先しています。
rollout単位のadvantageと損失正規化
もう1つの重要な工夫は、学習の重みづけをrollout単位で考えることです。
Harnessed Agentic RLでは、1つのタスク実行が何個の訓練サンプルに分かれるかは、retokenization、サブエージェント、コンテキスト要約などによって変わります。もしサンプル単位でadvantageや損失を平均すると、たまたま多くのサンプルに分裂したrolloutが、学習上大きな重みを持ってしまいます。
論文では、これは望ましくないと整理しています。サンプル数はエージェント内部の実装都合やトークン化の偶然で変わることがあるため、タスクとしての成功・失敗を表す報酬の基準はrollout単位で扱うべきだ、という考え方です。
Agent Lightning v1.0では、advantageをrollout単位で計算し、損失正規化にもrollout-level token-meanを使う設計を採っています。これは、各rolloutの中では応答トークンの損失をまとめつつ、バッチ全体ではrolloutごとに均等に扱う方法です。結果として、サンプル数のばらつきが学習の重みを不自然に変えることを避けます。
システム設計
システム面では、Agent Lightning v1.0は約3,500行の軽量なフレームワークとして設計されています。論文では、Training-Agent Disaggregation、API Gateway、rollout controller、trainer、Kubernetes統合、監視機能などが説明されています。
ポイントは、エージェント実行と訓練を同じプロセスに押し込まないことです。エージェントはハーネスの都合に合わせて動き、訓練側は観測された呼び出しをサンプルへ変換し、GPU上で最適化します。ネットワーク越しのLLM APIを使うため、重複リクエストや再試行に対するidempotentな処理も必要になります。
この設計は、実務のAIエージェントにも近いです。開発現場では、エージェントのツール群、認証、ファイルシステム、ブラウザ操作、検索API、サンドボックス環境がすでに存在します。それらを訓練用に作り直すのではなく、API境界で観測して改善サイクルに入れる発想が、この論文の実用的な価値です。
実験と結果
論文では、Agent Lightning v1.0を検索エージェント、一般的な指示追従エージェント、コーディングエージェントで評価しています。単にフレームワークを提案するだけでなく、ハーネス付きエージェント強化学習で問題になる設計選択が、実際の性能や安定性に影響することを確認しています。
検証したこと
主な検証点は、Harnessed Agentic RLの設計が実際に機能するか、そしてrollout単位のadvantage計算と損失正規化が学習を安定させるかです。
特にコーディングエージェントでは、タスク実行の軌跡が長く、ツール呼び出しやコンテキスト更新も多いため、1つのrolloutが複数の訓練サンプルに分かれやすくなります。論文では、コーディングエージェント訓練において、平均するとrolloutの36%だけが単一サンプルとして残り、1 rolloutあたり平均2.41個の訓練サンプルになったと報告されています。
これは、サンプル単位で単純に平均する設計が危険であることを示しています。サンプル数の違いが、タスクの重要度ではなくハーネス内部の都合から生まれているためです。
データセットと評価指標
コーディングエージェントの評価では、SWE-smithをもとにしたデータ処理パイプラインと、Qwen3.5-9Bを使った訓練が示されています。最終的な評価にはSWE-bench Verifiedが使われています。SWE-bench Verifiedは、実際のソフトウェアリポジトリのissue修正能力を測るベンチマークで、コーディングエージェントの実用性能を見るうえで重要です。
検索エージェントや一般指示追従エージェントについても、既存のエージェント訓練設定を使い、ハーネス経由で強化学習できることを確認しています。論文の主眼は「特定タスクで最高性能を出す」ことよりも、「実運用に近いエージェントハーネスを通したRLで、どの設計が安定するか」を明らかにすることにあります。
結果から言えること
コーディングエージェントでは、rollout-level advantageとrollout-level normalizationを組み合わせた設定が、比較した設定の中で最も高い検証報酬を示しました。論文では、step 128で検証報酬38.2%に到達し、sample-level advantageの35.0%、rollout-level advantageのみの33.1%を上回ったと報告されています。
さらに、SWE-bench Verifiedでは、Qwen3.5-9Bが41.8%から56.4%へ改善しました。絶対値で14.6ポイントの向上です。論文は、この改善が約6K件の訓練例と比較的控えめな計算資源で得られたと説明しています。
この結果から言えるのは、エージェント強化学習では、報酬関数やモデルサイズだけでなく、「実行軌跡をどう訓練サンプルに変換するか」が性能に大きく影響するということです。特に、サンプル分裂が多いコーディングエージェントでは、rollout単位の正規化が実用上かなり重要になります。
何に使える？
Agent Lightning v1.0の考え方は、AIエージェントをプロダクトとして運用する場面で応用しやすいです。すぐに大規模RLを回せる組織は限られますが、「どの境界でログを取り、どの単位で成功を評価するか」という設計思想は、小規模なAIアプリにも参考になります。
コーディングエージェントの改善
最も直接的な用途は、コード修正エージェントの訓練です。実際の開発タスクでは、ファイル検索、編集、テスト実行、エラー確認、再修正という長いループが発生します。このループを簡略化した環境で訓練すると、実運用とのずれが出ます。
Agent Lightning v1.0のように、実際のハーネスを通してLLM呼び出しを記録すれば、モデルは本番に近いコンテキスト構築やツール結果を前提に改善できます。社内コードベース向けの修正支援、CI失敗の自動修正、依存関係更新の補助などに応用できそうです。
検索・RAGエージェントの学習
検索エージェントやRAGエージェントでは、検索クエリ生成、検索結果の読み取り、再検索、回答生成という複数ステップの判断が必要です。単発の回答品質だけを教師あり学習しても、「いつ検索し直すか」「どの結果を読むか」「不要な文脈を捨てるか」は学びにくいです。
Harnessed Agentic RLを使えば、最終回答の正誤やユーザー評価をrollout報酬として扱い、その過程にあるモデル呼び出しを改善できます。特に、業務文書検索、問い合わせ対応、技術調査エージェントでは、検索ツールの使い方そのものを学習対象にできる可能性があります。
業務自動化エージェント
経費処理、CRM更新、メール下書き、社内申請、データ集計のような業務自動化エージェントにも使い道があります。これらは、単に正しい文章を生成するだけでなく、どのツールをどの順番で呼ぶか、途中でどの情報を確認するかが重要です。
ただし、この用途では報酬設計が難しくなります。最終的に業務が完了したかだけでなく、誤更新を避けたか、確認すべき情報を確認したか、余計なAPI操作をしなかったかを評価する必要があります。Agent Lightning v1.0の論文は、こうした複雑なハーネスを前提に訓練するための土台として参考になります。
開発や事業へのヒント
この論文から得られる大きなヒントは、AIエージェントの改善対象を「プロンプト」や「モデル」だけに閉じないことです。エージェントは、ハーネス、ツール、コンテキスト方針、ログ、評価、訓練データ変換まで含めたシステムとして性能が決まります。
まずAPI境界のログ設計が重要になる
自分でAIエージェントを作るなら、最初からLLM呼び出しのログを学習可能な形で残しておくとよいです。プロンプト、応答、ツール呼び出し前後の状態、最終結果、ユーザー評価、テスト結果などを紐づけておけば、あとから教師あり学習や選好学習、強化学習へ発展させやすくなります。
この論文の観点では、単なるテキストログでは不十分です。どのプロンプトでどの応答が実際にサンプリングされたか、トークン化やテンプレート変換でずれが起きていないか、1つのタスクが何個のモデル呼び出しに分かれたかを追えることが重要です。
評価単位はタスク単位に寄せる
小規模なプロダクトでも、評価を「1メッセージの良し悪し」だけでなく「1タスクが完了したか」に寄せる考え方は有効です。たとえば、コード修正ならテストが通ったか、RAGなら根拠付きで正答できたか、業務エージェントなら意図したレコードだけを更新できたか、という単位です。
Agent Lightning v1.0がrollout単位のadvantageと正規化を重視するのも、タスク単位の評価をサンプル分裂の偶然から守るためです。これは、オンライン評価やA/Bテストを設計するときにも参考になります。
ハーネスを訓練可能な製品資産として扱う
エージェントハーネスは、単なる実行ラッパーではありません。何を文脈に入れるか、ツール結果をどう整形するか、失敗時にどうリトライするかが、モデルの学習データそのものを決めます。
事業面では、優れたエージェント製品ほど、ハーネスの設計と評価ログが競争力になりそうです。モデルを差し替えるだけではなく、実際の業務フローから得たrolloutを継続的に改善へ使えるかが重要になります。
限界
Agent Lightning v1.0は実用的な方向性を示していますが、導入にはいくつか注意点があります。
まず、計算コストがあります。論文では比較的控えめな計算資源で成果を示していますが、それでもRL訓練、rollout生成、評価環境の実行、GPU訓練基盤が必要です。特にコーディングエージェントでは、サンドボックス環境でリポジトリをセットアップし、テストを実行するコストが大きくなります。
次に、データ依存性があります。良いrolloutを得るには、現実的なタスク、信頼できる報酬、失敗例を含む実行ログが必要です。SWE-benchのように評価が明確な領域では扱いやすい一方で、業務自動化や顧客対応のように正解が曖昧な領域では報酬設計が難しくなります。
また、精度や再現性にも注意が必要です。エージェントは外部ツール、ネットワーク、ファイルシステム、実行環境に依存します。ツールの状態が変わると同じプロンプトでも結果が変わるため、再現可能なrollout環境を用意する必要があります。
実装面では、retokenization、サンプル結合、重複リクエストの排除、分散学習のスケジューリングなど、地味ですが重要な部分が多くあります。論文は約3,500行の軽量実装を強調していますが、実サービスに組み込む場合は、監査ログ、権限管理、データ保護、失敗時の復旧なども別途必要になります。
最後に、まだ検証範囲は限られています。論文は検索、指示追従、コーディングで評価していますが、GUI操作、長期記憶を持つエージェント、複数ユーザーが絡む業務フロー、リアルタイム音声エージェントなどでは、さらに別の課題が出る可能性があります。
よくある質問
Q. Agent Lightning v1.0は普通のRLHFと何が違いますか？
A. RLHFは主にモデルの応答品質を報酬モデルや人間評価で改善する枠組みとして使われます。一方、Agent Lightning v1.0は、ツール実行やコンテキスト管理を含むエージェントハーネスを通してrolloutを作り、その中の複数のLLM呼び出しを強化学習に使います。モデル単体ではなく、実運用のエージェント実行に近い単位で学習する点が違います。
Q. なぜエージェントハーネスをそのまま使う必要があるのですか？
A. 実際のエージェント性能は、モデルだけでなく、ハーネスが作るプロンプト、ツール結果の整形、リトライ、サブエージェント、コンテキスト要約に左右されるからです。訓練用に別の簡略化したループを作ると、本番でモデルが見る入力や失敗パターンとずれる可能性があります。
Q. retokenizationは実務でも問題になりますか？
A. 問題になります。チャットテンプレート、JSON整形、ツール呼び出しの正規化、メッセージ履歴の再構築によって、見た目は同じテキストでもトークン列が変わることがあります。強化学習では、どのトークン列を条件に応答が生成されたかが重要なので、安易に会話履歴を結合すると訓練上のずれが入ります。
Q. 小規模なAIアプリでもこの論文から学べることはありますか？
A. あります。すぐにRL訓練を実装しなくても、タスク単位の評価ログを残す、LLM呼び出しと最終結果を紐づける、ツール実行の成功・失敗を記録する、といった設計は応用できます。将来的にファインチューニングや評価改善を行うときの土台になります。
Q. 導入時に一番難しい部分は何ですか？
A. 報酬設計と実行環境の再現性です。コード修正のようにテストで成否を判定できるタスクは比較的扱いやすいですが、業務判断や顧客対応では成功条件が曖昧です。また、外部ツールやデータベース状態が変わるとrolloutの再現性が落ちるため、訓練用の安全なサンドボックスと評価設計が必要になります。
今日の学び
この論文は、AIエージェントを強化学習で改善するときに、実運用のハーネスと訓練フレームワークの間に生まれるずれを扱った論文です。
提案されたAgent Lightning v1.0は、LLM API境界でリクエストと応答を観測し、retokenization、サンプル結合、advantage計算、損失正規化を慎重に扱うことで、ハーネス付きエージェントを現実的に訓練できるようにします。
開発へのヒントは、エージェントの改善をモデル単体で考えず、ハーネス、ログ、評価単位、訓練データ変換まで含めたシステムとして設計することです。AIエージェントを継続的に良くするには、実行ログをただ保存するだけでなく、将来の学習に使える形で観測し、タスク単位で評価する発想が重要になります。