OpenRLとは？CNCF寄贈で注目のエージェント向けRL基盤を解説
AI新規事業
AI新規事業のPoC・立ち上げ、何から始めるべきかご相談ください
要件定義からリリースまで、Mojiがワンチームで伴走します。
OpenRLは、LLMやAIエージェントを強化学習（RL）でポストトレーニングする際の、学習・サンプリング基盤です。利用者はPythonで学習ループ、報酬、データ、環境を記述し、OpenRLはKubernetes上で学習・サンプリング処理やアクセラレータの共有を扱う構成を目指します。
OpenRL自体は、エージェントを隔離実行するサンドボックスでも、汎用の本番推論サーバーでもありません。Google Cloudは2026年11月5日、OpenRL、Agent Substrate、gVisorをCNCFへ寄贈し、3プロジェクトがCNCF Sandboxへ受け入れられたと発表しました。OpenRLは2026年2月に研究プレビューとして始まった新しいプロジェクトです。導入時には、完成済みのマネージド製品としてではなく、エージェント向けRLの設計と運用を検証するOSSとして扱う必要があります。Google CloudのCNCF寄贈発表
AIエージェントそのものの役割や、固定ワークフローとの使い分けは、AIエージェントとは？生成AI・チャットボット・RPAとの違いと導入判断・実践手順も参照してください。
OpenRLとは：RLの学習ループと基盤運用を分けるAPI
LLMを使うエージェントのRLでは、モデルに回答・行動を生成させるロールアウト、ツール実行や採点による報酬計算、その報酬を使った重み更新を繰り返します。たとえばSQL生成エージェントなら「SQLが実行できたか」「期待する結果と一致したか」、コーディングエージェントなら「テストが通るか」を、報酬設計の候補にできます。
OpenRLは、こうした業務要件や評価基準まで自動化するフレームワークではありません。公式リポジトリでは、Tinker互換APIを通じ、利用者が自分のインフラ上でLLMのファインチューニングを実行できるプロジェクトと説明されています。CNCF Sandbox申請資料では、研究者が学習レシピ、データ、環境、報酬、損失を保持し、プラットフォームが容量、スケジューリング、重み同期、サービス運用を担う分担が示されています。主な操作として、sample、forward_backward、optim_step、save_weightsが挙げられています。OpenRL公式リポジトリ、CNCF Sandbox申請資料
担当 | OpenRLが担う範囲 | 利用組織が設計する範囲 |
|---|---|---|
研究・アプリ開発 | API経由のサンプル生成、勾配計算、更新要求 | タスク、データ、エージェント環境、報酬、評価、停止条件 |
プラットフォーム運用 | Trainer／Samplerの起動、アクセラレータ割り当て、重み同期、共有基盤 | クラスタ容量、アクセス制御、監視、ストレージ、コスト上限 |
OpenRLの対象外 | 汎用の本番推論配信、エージェント実行用サンドボックスそのもの | llm-d、Agent Substrate、または別の推論・隔離実行基盤との組み合わせ |
RLを採用しても、エージェントの品質が自動的に改善するわけではありません。報酬が業務上の正しさを十分に表していなければ、モデルが採点を通る行動へ偏り、実際に求める成果とずれるおそれがあります。OpenRLを評価する前に、「成功」「危険な失敗」「人へ戻すべき失敗」を区別できる評価セットを作ることが重要です。評価設計の基本は、LLM評価の進め方｜モデル選定を導入判断につなげる比較基準・手順・チェックリストで整理しています。
CNCF寄贈で何が変わったのか
今回の発表は、OpenRLが完成した商用基盤になったことを意味しません。CNCFのライフサイクルでは、Sandboxは初期段階の実験的・革新的なプロジェクトの位置付けです。機能の大きな変更を含め、継続的に進化する段階と案内されています。CNCFのプロジェクトライフサイクル
そのため、「CNCF案件だから本番利用に十分成熟している」とは判断できません。PoCでは、選定したOpenRLリリース、依存コンポーネント、モデル、評価データ、実行設定を記録し、更新前後に同じ評価を再実行できる状態を作ります。公開後に変化し得るmainブランチの導入ガイドを、恒久的な要件表として転載しないことも大切です。
Agent Substrate・llm-dとの違いと連携
OpenRLを理解する近道は、学習、隔離実行、推論配信を別の層として捉えることです。
プロジェクト | 主な役割 | OpenRLとの関係 |
|---|---|---|
OpenRL | RLポストトレーニングの学習・サンプリングをKubernetesへ配置し、共有アクセラレータを扱う | 利用者のRLループを支える学習・実行基盤 |
Agent Substrate | 状態を持つエージェントの実行環境を、Actor、Worker、Gatewayへ分けて扱う | エージェントのロールアウトを隔離環境で実行する選択肢 |
llm-d | Kubernetesネイティブな分散LLM推論を担い、推論スケジューリング、ルーティング、KVキャッシュ、prefill／decode分離などを扱う | ロールアウトの推論や、学習・サンプリング間のアクセラレータ共有に関与する構成要素 |
Google Cloudの説明では、OpenRLがPythonのRLループをKubernetes上で動かし、Agent Substrateのサンドボックスでエピソードを実行し、llm-dがロールアウトのルーティングと学習・サンプリング間のGPU時間分割を担う構成が示されています。つまり、OpenRLだけを導入しても、危険なコード実行を隔離する仕組みや、大規模な推論配信まで一括で得られるわけではありません。Google Cloudによる構成説明
llm-dは、vLLMおよびKubernetes Gateway API Inference Extensionを基盤とする、Kubernetesネイティブの分散LLM推論フレームワークです。OpenRLの導入可否と、llm-d単体で推論基盤を整備するかは分けて評価してください。CNCFのllm-dプロジェクトページ
構成を選ぶときの判断表
やりたいこと | 最初に検討する対象 | OpenRLの優先度 |
|---|---|---|
社内文書を検索して回答するエージェントを作る | RAG、権限設計、回答評価 | 低い。まず報酬学習なしで品質を測る |
生成コードを隔離環境でテストする | サンドボックス、ネットワーク制御、秘密情報の分離 | 低い。Agent Substrateまたは別の隔離実行基盤を先に評価する |
同じ業務で大量のロールアウトを行い、実行成否を採点できる | 報酬関数、GPU共有、学習後評価 | 高い。OpenRLのPoC候補 |
複数チームでGPUを共有し、学習とサンプリングの待ち時間を抑えたい | キュー、クォータ、監視、推論基盤 | 高い。ただしKubernetes運用体制が前提 |
この表はMojiによる設計上の目安です。結論は、モデル、入力品質、ロールアウト環境、報酬の妥当性、安全性の許容誤差、GPU利用状況の実測で変わります。
費用の考え方：OpenRLの利用料ではなくセルフホスト運用費を見る
OpenRLはセルフホスト型のOSSであり、料金を考える際はソフトウェアの月額料金ではなく、自組織が負担する実行・運用コストを対象にします。Google Open Source Blogは2026年6月11日、OpenRLを「セルフホストであり、マネージドサービスではない」と明示しています。公式リポジトリも、Apache-2.0ライセンスで、自前のマシンまたはKubernetesクラスタで実行できるTinker互換APIとして案内しています。Google Open Source BlogのOpenRL発表、OpenRL公式リポジトリ
費用項目 | 確認する内容 |
|---|---|
アクセラレータ | TrainerとSamplerのGPUまたはTPU利用時間、待機時間、他ジョブへの影響 |
ストレージ | モデル、アダプタ、チェックポイント、ロールアウト結果、評価ログの保存量と保持期間 |
Kubernetes運用 | クラスタ管理、DRA、監視、障害対応、アップデート検証の担当と工数 |
ネットワーク・セキュリティ | ロールアウト環境の外部接続、秘密情報、アクセス制御、監査ログ |
評価・人員 | 報酬関数、評価セット、人手レビュー、実験結果を判断する担当者 |
2026年11月6日に本記事で確認したGoogle Open Source Blog、Google Cloud Blog、OpenRL公式リポジトリ、CNCF Sandbox申請資料には、OpenRLそのもののマネージド料金表、日本リージョン別料金、または日本向けマネージド提供条件の掲載を確認できませんでした。この記述は、確認した一次資料の範囲に限定したものです。クラウド利用費やリージョンの可用性は、実際に使うクラウド事業者・契約プラン・アクセラレータ構成ごとに確認してください。
OpenRLを試す前に確認すること
OpenRLの導入要件やデプロイ手順は、選ぶリリースと構成によって変わります。本記事では、更新され得るmainブランチのガイドに記載されるKubernetesバージョン、GPU台数、ストレージ種別を、すべての環境へ当てはまる固定要件としては扱いません。
PoCの開始時には、採用するリリースタグまたはコミットSHAを固定し、その版のマニフェスト、対応アクセラレータ、ドライバー、ストレージ、権限、ネットワーク要件を検証環境で確認してください。これは導入推奨版を示すものではなく、再現可能な検証では参照先も固定する、という運用上の原則です。
導入前チェックリスト
- 報酬：「テスト成功」「SQLの実行結果一致」など、機械的またはレビュー可能な採点基準があるか。
- 評価：学習用報酬とは別に、固定したホールドアウト評価セットと危険ケースがあるか。
- 環境：ロールアウト中に使うツール、ネットワーク到達先、書き込み権限、秘密情報を最小化できるか。
- GPU：TrainerとSamplerをどのように配置し、他ジョブとのクォータ競合をどう扱うかを説明できるか。
- データ：プロンプト、実行ログ、報酬、チェックポイントの保存先・保持期間・閲覧権限が決まっているか。
- 更新：採用版の固定、ロールバック、更新後の再評価手順があるか。
- 停止：不正な外部操作、コスト超過、評価悪化が起きたときに、誰がどの操作で学習ジョブを止めるか決めたか。
エージェントに外部ツールの実行を任せる場合は、学習基盤とは別に、権限、承認、停止、監査ログを設計する必要があります。具体的な委任レベルは、AIエージェントのガードレール設計｜権限・承認・停止・監視の実務ガイドを確認してください。
始め方：本番導入ではなく4段階のPoCから始める
以下はMojiによる提案です。公式チュートリアルの手順をそのまま本番環境へ適用するのではなく、学習の有効性と運用負荷を分けて確かめます。
- 対象業務を1つに絞る：報酬を自動採点しやすい業務を選びます。例として「テストが通るコード修正案」「正解結果と一致するText-to-SQL」などがあります。顧客メールのように正しさを一意に採点しにくい業務は、最初の候補にしません。
- 学習前の基準値を取る：固定した評価ケースで、成功率、危険な失敗件数、平均ロールアウト数、処理時間、GPU時間、1成功あたりの費用を記録します。
- 隔離した環境で小さく実行する：書き込み不要のテスト用ツール、ダミーまたは匿名化済みデータ、上限付きGPUクォータで動かします。本番の認証情報を渡さない設計から始めます。
- 学習後を同条件で比較する：報酬の上昇だけでは合格にしません。ホールドアウト評価で改善しているか、危険な操作が増えていないか、成功1件あたりの総コストが許容範囲かを確認します。
PoCの判定テンプレート
指標 | 測定方法 | 合格条件の決め方 |
|---|---|---|
業務成功率 | 未学習時と学習後で同じホールドアウトケースを比較 | 業務責任者が許容する最低成功率と改善幅を事前に設定 |
危険な失敗率 | 権限逸脱、禁止ツール呼び出し、誤更新などを別集計 | 重要操作では人の承認を残すなど、影響に応じて基準を定める |
報酬と実品質の乖離 | 高報酬の出力を人または独立評価で抜き取り確認 | 報酬の上昇だけで合格にしない |
GPU効率 | GPU稼働率、待機時間、キュー滞留、他ジョブ影響を確認 | 単体ジョブ速度だけでなく、共有基盤全体への影響で判断 |
再現性 | 同じコード・データ・固定版で再実行 | 結果のばらつきが業務上の許容範囲に収まるか確認 |
数値の閾値は一律に決められません。モデル、入力品質、評価指標、許容誤差、誤りが起きたときの影響で変わります。たとえば社内の候補検索と、顧客向けの契約変更を伴うエージェントでは、同じ成功率でも許容可否は異なります。
既存のRLフレームワークとの違い
OpenRLは、名前が似た別プロジェクトや、RLHF・LLM RLのフレームワークと混同しやすい点に注意が必要です。今回CNCFに寄贈された対象は、gke-labs/open-rlです。一方で、OpenRL-Lab/openrlは、単一・マルチエージェントを含む広いRL研究を対象とする別プロジェクトです。
OpenRLのCNCF Sandbox申請資料は、verl、OpenRLHF、SkyRL、NeMo-RL、TRLなどを、学習ループや分散ランタイムを担うフレームワークとして整理しています。これに対してOpenRLは、利用者が保持する学習ループの下で、KubernetesネイティブなAPIサービスとして動く位置付けです。既存フレームワークを採用済みなら、置き換えを前提にせず、現在の学習レシピ・データ・評価を保ったまま、GPU共有やKubernetes運用を分離できるかを比較してください。CNCF Sandbox申請の比較説明
まとめ：OpenRLを選ぶべきチーム
OpenRLがPoC候補になりやすいのは、自前で管理するKubernetesとアクセラレータ環境があり、実行結果から品質を採点できるエージェントを、繰り返しRLポストトレーニングしたいチームです。特に、複数の実験・利用者でアクセラレータを共有し、研究者が学習ループを保持したまま基盤運用を分けたい場合に検討余地があります。
一方、エージェントを初めて導入する段階、報酬を定義できない段階、隔離実行や権限管理が未整備の段階では、OpenRLから始める必要はありません。まずは通常のプロンプト、RAG、固定ワークフロー、隔離実行、評価を整えたうえで、「学習で改善する余地があり、報酬で安全に測れるか」を確かめる順序が現実的です。