ニュースレター
強化学習環境についてのFAQ
原題:An FAQ on Reinforcement Learning Environments
Gradient Updates は著者個人の見解を述べるニュースレターで、Epoch AI 全体の見解とは限りません。
この記事は、ゲスト著者の Chris Barber と Epoch AI の JS Denain の共同執筆である。
強化学習(RL)環境は、フロンティアAIラボがモデルを学習させるうえで中心的な存在になった。2025年9月、The Information は、Anthropic が翌年にかけてRL環境に10億ドル超を費やすことを検討していたと報じた。Andrej Karpathy が2025年の振り返りで述べたように、さまざまな環境で検証可能な幅広いタスクを使ってLLMを学習させると、「LLMは、人間から見て『推論』のように見える戦略を自発的に身につける」。
能力向上のためのRLというこの潮流は、OpenAI の o1 から始まった。o1 は、答えを検証できる数学とコーディングの問題で学習された。それ以来、ラボは学習に使うタスクの範囲を広げ、同時にRLの学習に費やす計算資源の量も拡大してきた。
多様で質の高い環境とタスクがなければ、RLにいくら計算資源をつぎ込んでも、その多くを無駄にするおそれがある。そのため、こうしたタスクや環境の作成は能力を拡大するうえでの重要なボトルネックとなり、成長しつつも大部分が非公開のまま動く市場になっている。
ラボがモデルのRL学習に使う環境やタスクを作る、この新興産業を理解するため、RL環境のスタートアップ、ネオラボ(新興のAI研究企業)、フロンティアラボの18人に話を聞いた。1 RL環境とタスクとはどんなものか、ラボはそれをどう使っているのか、何が良い環境・タスクの条件なのか、そしてこの分野はどこへ向かっているのかを尋ねた。
主な結論:
- 企業の業務フローが大きな成長分野である。最初に来たのは数学とコーディングのタスクだったが、今では企業の業務フロー、つまり Salesforce の操作、報告書の提出、スプレッドシートの操作といったタスクが大きく伸びている。
- 報酬ハッキングが最大の懸念である。インタビューした人々は一貫して、報酬ハッキングへの耐性を品質の重要な基準に挙げた。モデルは採点器を出し抜く方法を見つけるので、それを防ぐには環境とタスクの両方で何度も改良を重ねる必要がある。
- 品質を落とさずに規模を拡大するのは難しい。大きな課題は、品質を犠牲にせずに環境とタスクの量を増やすことである。難しいのは管理(増え続けるタスク作成者を取りまとめること)と、良い品質評価の工程を保つことである。
Epoch AI の最新情報を受け取る 購読する
RL環境とタスクとは何か?
言語モデルのための現代の強化学習では、モデルに達成すべきタスクと、取りうる行動の集合が与えられる。モデルはタスクに挑み、採点器(通常は自動化されたもので、単体テストや、評価基準に照らして判定するLLMなど)がその試行に点数を付ける。こうして点数の付いた試行を使ってモデルの重みを更新し、うまくいった戦略を強化する。
RL環境は、モデルが取りうる行動の集合(コードの実行、考えを書き出すこと、ボタンのクリック、文書の検索)と、それらの行動の効果を決める周囲の状況(環境変数、ファイルシステム、模擬アプリケーションの状態)によって定義される。実際には、環境は Docker コンテナとして提供されることが多いが、いつもそうとは限らない2。
各タスクは、ある目標の達成をモデルに指示するプロンプトと、その目標が達成されたかどうか(あるいはどの程度達成されたか)を判定する採点器からなる。この分野の用語は完全には標準化されておらず、「環境」と「タスク」の境界はややあいまいである3。環境とタスクは一緒に作られ、一緒に売られることが多いので、この記事では両方を扱う。

環境と、それが扱えるタスクの例をいくつか挙げる。
- git リポジトリ。SWE-bench Verified のようなベンチマークと同様に、単体テストが通るようにバグを修正する、といったタスクがある。タスクは、テストが失敗する特定のコミット時点の git リポジトリを指定する。環境は、リポジトリを操作するためのオペレーティングシステムとツールを提供する。採点器はテストを実行し、通ることを確認する。
- Airbnb のクローン。特定の日程で、ある都市の寝室2部屋の物件のうち最も安いものを探す、といったタスクがある。環境は、本物らしい物件・価格・絞り込み条件を備えた模擬ウェブサイトである。エージェントはページの構造化された表現(DOM やアクセシビリティツリーなど)を見て、要素のクリックや入力欄への入力といった行動を出力する。採点器は最終的な答えを検証する。
- Bloomberg 端末のクローン。企業の一覧について5年間の年平均成長率を求める、といったタスクがある。環境は端末の画面とデータを模擬する。採点器は、返された数値が正しい値と一致するかを確かめる。
- Excel のクローン。生のデータセットから地域別の売上高を示すピボットテーブルを作る、といったタスクがある。環境は、本物らしい機能を備えたスプレッドシートのアプリケーションを提供する。採点器は、出力を模範解答と比べる。
Excel のクローンのようなコンピュータ操作の環境では、1つの環境で何百もの異なるタスクを扱えることがある。コーディングの環境では、リポジトリの状態を用意するのが比較的安いので、各環境にタスクが1つだけ入っていることのほうが一般的である(いつもそうとは限らないが)4。
ラボはRL環境をどう使っているのか?
各環境とタスクには、主に3つの使い道がある。強化学習、ベンチマーク評価、そしてタスクを解いた軌跡を使った教師ありファインチューニングである。
主な用途は今も強化学習である。あるRL環境スタートアップの社員はこう話す。「主な用途はRLです。ベンチマーク用に環境を作ってほしいという依頼もいくらかあります。前者は後者のおそらく10〜20倍でしょう」。違いの一つは、ベンチマークは通常1ターンの評価のために作られるのに対し、エージェントとユーザーの複数ターンにわたるやり取りを捉えるRL環境への関心が高まっていることである。
環境は、教師あり学習のためのデータを生成するのにも使われる。中間学習(ミッドトレーニング)の際に、RLでうまくいった軌跡を学習例として使うのである。あるインタビュー相手はこう述べた。「今のところ購入の動機にはなっていないかもしれませんが、うまく設計された環境は、合成データを生成する効果的な仕組みとして使えます。環境開発が成熟し、設計者がこの用途を狙うようになるにつれて、これはますます重要になると感じています」。
あるインタビュー相手は、特に思考とツール呼び出しを交互に行う用途で、教師ありファインチューニング(SFT)が伸びてきたと指摘した。SFTでは良い軌跡を1つ選んでそれで学習させられるが、RLでは、学習のシグナルを得るのに十分な差のある複数の軌跡が必要になる。そのため、良い軌跡を作るのは比較的簡単だが、信頼できる採点器や試行間の十分なばらつきを得るのが難しい場合には、SFTのほうが実用的である。
使い方はラボによっても異なる。あるRL環境スタートアップの創業者は、後発のラボはRLよりSFTに関心をもつ傾向があると指摘した。「本当に大規模なRLのパイプラインを用意するのはかなり難しく、SFTのデータの組み合わせに何かを放り込むのは簡単なのです」。
RL環境の企業は、自社の製品が最終的にどう使われているかを必ずしもすべて把握しているわけではなく、ラボの学習パイプラインが変わるにつれて、使い方もおそらく変わっていく。ある創業者は、顧客が自社の作った環境をどう使っているかと尋ねられて、こう答えた。「ゴールド軌跡5の生成にどの程度使っていて、RLにどの程度使っているのか。それに答えるのはかなり難しいと思います」。
どんな企業がRL環境を作っているのか?
RL環境の構築に特化した専門のスタートアップが増えている。対象分野は、ソフトウェアエンジニアリングのタスクからコンピュータ操作、数学、金融まで幅広い。Chris はこの分野のスタートアップの一覧をこちらにまとめている。
Mercor、Surge、Handshake、Turing のような従来のデータ提供企業は、以前は主に人手でラベル付けしたデータを提供していたが、今ではRL環境も販売している。支払う対価の一部は品質保証の工程や監督の仕組みに対するものだが、ある創業者が言うように、主な付加価値は「人手を抱えている」ことである。タスク作成を急いで拡大する必要があるなら、社内で採用するより早く、こうした企業がプロジェクトに人員を割り当ててくれる。
モデル開発企業の社内チームも環境を作っている(xAI や Anthropic の求人を参照)。これにはフロンティアラボと、Cursor のようなネオラボの両方が含まれる。後者はユーザーデータを活用して学習用のタスクを作れる。ある創業者は、ラボが自前のデータチームを整えるにつれて、最近は「内製化がかなり進んでいる」と指摘した。内製する理由には、外部業者に払う利ざやを避けること、学習の優先事項を秘密にしておくこと、AI研究のような一部の分野では社内に直接の専門知識があることなどがある。
最後に、製品企業は自社のソフトウェアを中心に環境を作るうえで自然な協力相手である。Salesforce や Slack であれば、自社製品の画面や例外的なケースを誰よりもよく理解している。ラボと製品企業の提携が相次いでいる。生物学の業務フローでの Benchling と Anthropic、ショッピングでの OpenAI と Shopify や Stripe、OpenAI の最近の医療関連の連携などである。こうした提携が具体的にどう機能しているのかはわからないが、製品企業が少なくとも環境やタスクの作成に協力していることが多いと考えてよさそうだ。ただし、エージェントによるアクセスに敵対的な企業もある。Amazon は Perplexity をそのエージェント型ショッピングツールをめぐって提訴し、ほとんどのAIエージェントによる自社サイトへのアクセスを遮断した。
環境とタスクにはどれくらいの費用がかかるのか?
費用は分野、複雑さ、タスクの数によって大きく異なる。
契約の規模は、四半期あたり数十万〜数百万ドルであることが多い。たとえば、あるRL環境の創業者は、契約は四半期あたり数百万ドル以上になることが多いと述べた。あるネオラボの研究者は、30万〜50万ドルの範囲の契約を見たことがあると話し、タスクの数によって大きく変わると付け加えた。
環境の費用は再現度によって決まる。SemiAnalysis の報告によれば、ウェブサイトのレプリカ(「UIジム」)は1つ約2万ドルである。しかし、Slack のような複雑な製品をより高い品質で再現したものはかなり高くなりうる。あるインタビュー相手は、そうしたものについて約30万ドルという数字を挙げた。
タスクの費用もまちまちだが、複数のインタビュー相手が、タスク1件あたり200〜2,000ドルという目安で一致した。あるRL環境の創業者はこう述べた。「たいていは200ドルから2,000ドルですね。タスク1件2万ドルというのはまれですが、ありえます」。あるネオラボの研究者も、この範囲は自分の経験と合うと認めた。2万ドルという数字は特に複雑なソフトウェアエンジニアリングのタスクで出てくるが、まれである。タスクの費用を比較のために示すと、Mechanize の推定では、RLの学習中にタスク1件あたり約2,400ドル分の計算資源が費やされている。つまり、安くて質の低いタスクは、その計算資源を無駄にしてしまうおそれがある。
独占性は価格に大きく影響する。環境とタスクは、1社の顧客に独占的に売られることもあれば、複数のラボに非独占的に売られることもある。2人のRL環境の創業者がそれぞれ独立に、独占契約は非独占契約のおよそ4〜5倍高いと述べた。
この分野への支出全体は急速に伸びている。前述のとおり、The Information は、Anthropic が翌年にかけてRL環境に10億ドル超を費やすことを検討していたと報じた。とはいえ、これは計算資源の費用のごく一部にすぎない。OpenAI の2026年の研究開発向け計算資源への支出は約190億ドルと見込まれており、2025年のおよそ2倍である。Anthropic が OpenAI より規模が小さいことを考慮しても、計算資源への支出はRL環境への支出をなお大きく上回るだろう。
RL環境はどんな分野を扱っているのか?
当初、主な分野は数学とコーディングだった6。あるネオラボの研究者はこう述べた。「RL環境の探究はすべて、コーディングと、ある意味では数学から始まりました。だからコードと数学が最も豊富なのです」。
数学のタスクは比較的作りやすい。複雑な環境を作る必要はなく、答えを検証できるタスクがあればよいからだ。ただし、最近は数学の比重が下がっているかもしれない。あるインタビュー相手は「数学は縮小しているかもしれない」と指摘し、あるRL環境の創業者は、数学のタスクは作るのは簡単だが、他の能力にはあまり転移しないと述べた。
コーディングは今も需要の大きな源である。市場は巨大で、コードのタスクで学習させることによる能力の向上もすでに示されている。また、コーディングの環境が SWE-bench 型のタスクを超えつつあることもわかってきた。あるRL環境の創業者はこう述べた。「コードの環境が、PASS_TO_PASS や FAIL_TO_PASS7 のような、より単純な SWE-bench Verified 型のタスクから、実際の業務に近いものへと移っていくのを見てきました。ソフトウェアエンジニアは実際にどんな環境で働いているのか。GitHub があり、Linear があり、コードのIDEがあります」。大きな課題は、多くのタスクには「単体テストに通る」こと以外にきれいな検証基準がないことである。あるネオラボの研究者はこう指摘した。「単体テストに通る解はおそらくたくさんあります。でも、エンジニアリング上の設計判断の点で、より良いトレードオフをとった、よりすっきりした解もあるのです」。これは採点の面での課題になる。
大きな成長分野の一つが、企業の業務フローである。経費報告書の提出、スプレッドシートでのピボットテーブルの作成、概要からのスライドの作成、CRMを操作して顧客記録を更新することなどのタスクだ。あるRL環境の創業者はこう話した。「企業の業務フローは今年爆発的に伸びると思います。ラボは、何に価値があって何が定量化できるかを非常に重視していて、企業の業務フローはそれにぴったりです。ここで言う企業の業務フローとは、コンピュータ操作を伴う場合(たとえばバックエンドのない特定のERP8)もあれば、エージェントに公開でき、コンピュータ操作なしで使えるAPIを伴う場合もあります」。
企業の業務フローのための環境には、さまざまな形がある。MCP 型のツール連携、Playwright 型のブラウザ操作、スクリーンショットにもとづくコンピュータ操作などである。多くは、Slack や SAP のようなウェブサイトやアプリのクローンに頼っている。あるラボの研究者はこう注意を促した。「ウェブサイトのクローンを使う正当な理由はたくさんありますが、みんながやっているのは、バグだらけのウェブサイトをバイブコーディングで(雰囲気任せに)作ることで、それは役に立ちません。そのせいで、役に立たない粗悪な環境が世の中に大量にあるのです」。
Prime Intellect の環境構築の懸賞を見ると、RL環境が扱う分野の一部と、それがどう作られているかがわかる。そこには、有名なベンチマークにもとづく環境、MCP サーバーとやり取りするための環境、nanoGPT Speedrunning のようなAI研究のタスク、教科書から集めた問題にもとづくタスクなどが含まれる。
全体として、近い将来の主な方向性はコーディングと企業の業務フローである。そのどちらでも、より長い期間にわたるタスクへの関心が高まっている。あるRL環境の創業者はこう述べた。「長期的なタスクが今後の方向性だと思います。複数のタブやブラウザをまたいで操作し、多段階の手順を経て何かを提出するような、始めから終わりまで一貫したタスクをエージェントにやらせるのです」。
インタビューでは、ほかにもいくつかの方向性が挙がった。1ターンの性能だけでなく、ユーザーとの複数ターンのやり取りのための学習、複数の目標を同時に最適化する環境、そして研究者が軌跡を調べて変更し、フィードバックを与えられるツールを備えた環境である。
最優先事項と課題は何か?
インタビューした人々は一貫して、報酬ハッキングへの耐性を最も重要な品質基準に挙げた。あるネオラボの研究者はこう述べた。「報酬ハッキングは大問題です。モデルは解答を検索したり、リポジトリのスクリプトの書き方に気をつけていないと、未来のコミットをチェックアウトしたりしてずるをするかもしれません9。頑健でなければなりません。それが最低限です」。別の人も同様の言い方をした。「何より大事なのは健全性です。高い報酬は、タスクがハックされたのではなく、実際に解かれたことを意味しなければなりません」。頑健な採点器が一度でうまくできることはまれである。あるRL環境の創業者が指摘したように、「報酬ハッキングを確認するには、何度も何度も繰り返しが必要」になる。モデルがこの1年で報酬ハッキングをしにくくなったのに、これが依然として最優先事項であることは注目に値する。
難易度の調整も重要である。合格率が0%や100%ではモデルは学習しないので、タスクは難しくても不可能であってはならない10。さらに、あるRL環境の創業者が指摘したように、「0%にはしたくありません。別のアノテーターが答えを見ずに解いて成功したのでない限り、そのタスクが実行不可能である可能性があるからです」。複数のインタビュー相手が、合格率は最低でも2〜3%程度、あるいは64回か128回のロールアウトのうち少なくとも1回は成功してほしいと述べた。
個々のタスクの難易度だけでなく、全体の分布も重要である。あるネオラボの研究者はこう述べた。「RL環境のとても重要な特徴は、なだらかな勾配、つまりタスクの難易度に多様性があることです」。ある人は、組み合わせが望ましいかもしれないと指摘した。0%のタスク、5%のタスク、30%のタスクを混ぜておくのである。学習を何ステップか進めると、0%だったタスクも学習できるようになる。タスクの合格率が70%程度に達したら、そのタスクは捨てて、より難しいタスクに移ってもよい。
それとは別に、タスクは組み合わせがきくものであるべきだ。あるネオラボの研究者はこう指摘した。「スキルはばらばらのタスクであってはならず、互いに似ていて、共通のスキルを活用するものであるべきです」。
品質を保ちながら規模を拡大することが、運用上の中心的なボトルネックである。Kevin Lu が論じたように、RL環境の規模拡大は、AIが進歩を続けるための重要な課題の一つである。しかし、品質を保ちながらタスク作成の規模を拡大するのは非常に難しい。あるRL環境の創業者はこう指摘した。「規模を拡大しながら品質を保つことが、みんなが直面している一番のボトルネックです。専門家を見つけるのはそれほど難しくありませんが、彼らを管理し、品質管理を行うのが難しいのです」。あるネオラボの研究者は、管理の難しさを強調した。「このデータ構築、つまりRL環境の構築工程を監督する人を見つけるのは簡単ではありません。契約者たちには、やる気を出してもらう必要があります。もちろんお金は払っています。でも、彼らがただLLMを使っているだけではないと、どうやって確かめるのか。実際に検証されていると、どうやって確かめるのか。契約者のやる気を引き出し、品質管理を行うのは、地道な汗かき仕事です」。あるRL環境の創業者は、売上高をもっと伸ばすうえでの制約は、要求される品質水準でタスク作成の規模を拡大するのが難しいこと、ただそれだけだと述べた。
求められるスキルは、分野の専門知識、プロンプトを書く力、製品の感覚の組み合わせである。環境の構築には主にエンジニアリングのスキルが必要だが、良いタスクを作るには別のものが求められる。あるRL環境の創業者はこう述べた。「タスクを作るうえでは、MLのスキルより、分野の知識と専門家水準のプロンプトの技術のほうが重要です」。あるネオラボの研究者は、製品の感覚も重要だと付け加えた。「人々がこうしたツールを実際にどう使っているかを知っておきたいのです」。フロンティアモデルとやり取りした経験が豊富であることが鍵になる。あるネオラボの研究者はこう指摘した。「必ずしもAI研究者である必要はありません。むしろ Claude Code のヘビーユーザーや、Riley Goodside のようなプロンプトの達人のほうが、AI研究者よりも能力の最前線がどこにあるかを見極めるのがうまいかもしれません」。別の人は端的にこう述べた。「これがおそらく一番うまいのは、実際に使われるベンチマークを作っている人たちです」。
RL環境は、フロンティアAIの学習にとって主要な投入要素の一つに急速になった。主な課題は、報酬ハッキングを防ぐことと、品質を犠牲にせずに生産の規模を拡大することであり、その一方で、企業の業務フローやより長い期間にわたるタスクへの需要が伸びている。動きの速い分野であり、1年後にはこの状況はかなり違って見えるだろうと私たちは予想している。
インタビューに応じてくださったすべての方々と、この記事へのコメントと編集の手助けをいただいた Jaime Sevilla、Josh You、Lynette Bye に感謝する。
注
-
9人と通話で話し、さらに9人からテキストやメールで意見をもらった。ほかに4人には、意見はもらわず妥当性の確認だけをしてもらった。 ↩
-
たとえば、Prime Intellect の環境ハブにある環境は Docker を使わず、同社の verifiers ライブラリにもとづく、より軽量な方式を使っている。一部の分野、たとえばほとんどの数学の問題では、モデルがツールを使う必要がないので、環境すら要らない。 ↩
-
従来のRLの用語では、「環境」には状態遷移の力学(行動が状態にどう影響するか)、報酬関数、初期状態の分布が含まれる。その枠組みでは、「タスク」は単に特定の初期状態のことである。実際には、これらの用語の使い方は人によって異なる。 ↩
-
ここでも用語は完全には標準化されておらず、分野によって異なる。「環境」を、タスクが1つ入った単一の Docker コンテナの意味で使う人もいれば、多くのタスクを含むコンテナの集まりの意味で使う人もいる。 ↩
-
ゴールド軌跡とは、タスクを首尾よく完了した、人間が検証済みの例であり、教師ありファインチューニングの学習データとして使える。 ↩
-
ある意味では、RLHF や Constitutional AI は数学やコーディングの環境より前からあった(さらに範囲を広げれば、MuJoCo のような物理エンジンはもっと前からあった)。どちらもRLで言語モデルを学習させるものだが、通常はツールの使用や環境はそれほど重視されてこなかった。実際には、これらは別の区分と考えられることが多く、関わる顔ぶれも異なることが多い。 ↩
-
SWE-bench Verified では、PASS_TO_PASS はモデルが編集した後も通り続けるべきテストを指し、FAIL_TO_PASS は以前は失敗していて、修正後に通るべきテストを指す。 ↩
-
ERP は Enterprise Resource Planning(企業資源計画)の略で、企業が会計、調達、プロジェクト管理などの日常業務を管理するために使うソフトウェアである。SAP や Oracle などがある。 ↩
-
GRPO のようなRLアルゴリズムは、同じタスクへの異なる試行を比べることで改善する。ある試行が成功し、別の試行が失敗すれば、モデルは成功した戦略を選ぶよう学習する。しかし、すべての試行が同じ点数(すべて合格、またはすべて不合格)なら、どの方法がうまくいくのかについてのシグナルは得られない。 ↩