動いているAIエージェントを、コード書き換えゼロで賢く育てる — Microsoftが出したAgent Lightning

AIエージェントを賢くする手段は、だいたいプロンプトの調整に偏っている。もう一段踏み込んで、モデルそのものを強化学習（RL）で鍛えたい——そう思っても、実際にやろうとすると学習用にエージェントを丸ごと書き直す羽目になり、多くの人がそこで諦める。

Microsoftが2026年8月17日に公開したAgent Lightning v1.0は、その「書き直し」をほぼ消しにきたオープンソースのフレームワークだ。既に動いているエージェントに、コード変更ほぼゼロでRLの学習ループを後付けできる。

「実行」と「学習」を切り離した

肝は設計思想にある。Agent Lightningは、エージェントがタスクを実行する部分と、モデルを学習する部分を完全に分離した。

普通、RLをやろうとすると、エージェントの制御フロー・ツール・コンテキストの持ち方まで学習フレームワークの都合に合わせて作り替える必要が出てくる。Agent Lightningはここを逆にした。エージェントは本番で使っているそのままの姿で走らせ、その実行の軌跡（どんな入力に対してどう動いたか）を外から観測して学習に回す。

だからLangChain、OpenAI Agents SDK、AutoGenといった既存の作り方で組んだエージェントを、ほとんど手を入れずにそのまま学習対象にできる。開発チームが積み上げてきたコードやツール構成を捨てなくていい、というのが実務的に効く。

中身: MDPとLightningRL

技術的には、エージェントの実行を強化学習の枠組みであるMDP（マルコフ決定過程）として定式化し、統一されたデータインターフェースを定義している。

その上で「LightningRL」という階層型のRLアルゴリズムを載せる。ここには**クレジット割り当て（credit assignment）**のモジュールが含まれていて、任意のエージェントが生成した長い軌跡を、学習に使える個々の遷移へと分解する。要は「どの判断が最終的な良し悪しにどれだけ効いたか」を切り分けて、モデルの更新信号に変える部分だ。複数ステップにわたって道具を呼び出すエージェントで、この切り分けは地味に難しい。そこを仕組みとして持っているのが特徴になる。

何が可能になるか

一番わかりやすいのは、本番で動いているエージェントを、そのエージェント自身の実運用ログから継続的に鍛えるという使い方だ。

たとえば社内で問い合わせ対応をこなしているエージェントがあるとする。日々のやり取りは全部軌跡として残っている。従来はそのログを人が眺めてプロンプトを手直しするくらいしかできなかった。Agent Lightningなら、同じログを学習信号に変えて、モデル側を直接強くしていける。プロンプトエンジニアリングの天井を超えて、エージェントが使われながら賢くなる回路が作れる。

もう少し広げると、フレームワークを問わず「RLを後から差せる」という性質は、エージェント開発の順番を変える可能性がある。まず動くものを普通に作り、価値が確認できてから学習で精度を詰める——PoCと本気の作り込みの間にあった大きな段差が、ここで一段低くなる。

ただし条件はある。RLが効くには、何を「良い結果」とみなすかの報酬設計と、それなりの計算資源が要る。ここはAgent Lightningが肩代わりしてくれる部分ではない。

正直な評価

「コード書き換えゼロ」というフレーズは魅力的だが、これは統合の手間がゼロという意味であって、RLそのものが簡単になるわけではない。報酬をどう定義するか、学習データをどう用意するか、どこまで計算を回すか——難所は依然として残っている。そこを取り違えると「繋いだけど賢くならない」で終わりかねない。

とはいえ、既存資産を捨てずにRLを試せる敷居の低さは本物だ。エージェントを本番投入していて、プロンプト調整では頭打ちを感じているチームにとっては、触ってみる価値がある。逆に、まだ動くエージェントすら持っていない段階なら、先にそこを作るのが順序として正しい。研究の詳細はarXiv論文「Agent Lightning: Train ANY AI Agents with Reinforcement Learning」にまとまっている。