CodeMidas、ソースコードそのものからRL訓練タスクを抽出

実際に仕事をこなせるコーディングエージェントを訓練するのに必要なのは、より大きなモデルやより多くのGPUだけではない。強化学習が必要とするのは、エージェントの出力が自動的かつ信頼できる形で正解か不正解かを判定できるタスク、つまり検証器を伴うタスクである。

検証器がなければ、どれだけ訓練軌跡を積んでもノイズにしかならない。新論文『CodeMidas: Scaling Agentic Coding RL Environments from Code Itself』(arXiv:2609.22068)が狙う核心のボトルネックはまさにここにある。計算資源の不足ではなく、検証可能なコーディングタスクという資源そのものが不足しているのだ。

issueやcommitだけでは足りない理由

CodeMidas以前、オープンソースのコードベースをRL訓練タスクに変換する標準的な方法は、issue・commit・PRといった開発過程の痕跡を掘り起こすことだった。バグ報告とそれを修正したcommitをペアにしてタスクと検証条件を作る、という具合である。この方法は機能するが天井が低い。世の中に存在する実際に動く実装済みコードの圧倒的多数には、そもそも紐づくissueやPRが存在しないからだ。

開発者が残したメタデータだけに頼るのは、鉱山にある鉱石の大部分を掘る前から捨てているに等しい。CodeMidasはこれを逆転させる。issue・commit・PRに一切依存せず、ソースコードそのものだけを入力として使う。すでに何らかの機能を実装しているコードであれば原理的にすべてタスクとして抽出できるため、対象となるタスクの候補プールは「記録が残っている一部のリポジトリ」から「動作するほぼすべてのオープンソースコードベース」へと拡大する。

構築のすべての段階にエージェント計算を投じる

CodeMidasは訓練時だけでなく、環境構築のパイプライン全体にエージェント計算を投じている。まずエージェントがコードベース内に実装済みの機能を探索し、そのコードが何をすべきかを記述する振る舞い仕様を組み立てる。

次に、根拠のない推測ではなく、元のコードの実際の実行結果に基づいたテストケースを構築する。最後に、候補タスクは実行チェックと繰り返しの解答ロールアウトによる検証・フィルタリングを通過し、仕様が曖昧なもの、テストが信頼できないもの、安定して再現できないものが除外される。実行そのものを使ってタスクの信頼性を検証するというこの姿勢こそが、品質を落とさずにパイプライン全体を規模拡大できる鍵となっている。

広さが汎化の鍵になる理由

最終的なデータセットは3,185のオープンソースコードベースから抽出された5,545の訓練タスクからなり、23のプログラミング言語と15の技術領域にまたがる。この広さは装飾的な要素ではなく、狭いベンチマーク上でだけ有能に見えるエージェントと、真に転用可能なコーディング能力を身につけたエージェントとを分ける決定的な違いである。

言語やプロジェクト構造の狭い範囲だけで訓練すると、特定の構文やバグパターン、特定のリポジトリの慣習に過学習しやすい。23言語・15領域にタスクを分散させることで、モデルが学ぶべき能力は「特定のコーパスへのパターンマッチ」ではなく、「見知らぬコードベースの中で状況を把握し、自分の作業を検証する」というより一般的なものにならざるを得ない。

ベンチマークの向上が本当に示すもの

研究チームはGRPOを用いてMiMo-V2.5モデルをこれらのタスクで訓練し、5つのベンチマークで評価した。具体的な数値が報告されたのは3つで、issue修復ベンチマークのDeepSWEが11.7%、プログラム全体構築ベンチマークのProgramBenchが17%、ターミナル操作を扱うTerminal-Bench v2.1が8.5%それぞれ向上した。最も伸び幅が大きいのはProgramBenchであり、これはCodeMidasのタスク構築方法そのものと綺麗に一致する。

パイプラインが局所的なバグ修正ではなく、実装済み機能全体の理解と再現を中心に構築されているため、結果として得られるエージェントが狭い修復作業よりもゼロから何かを作る作業で最も伸びるのは自然な結果と言える。アブレーション実験では、高品質な訓練タスクの数を増やすほど性能が向上し続けることも示され、この「コードそのものから検証器を規模拡大して生産する」というアプローチにまだ伸びしろがあることを示唆している。軌跡分析でも、RL訓練を経たエージェントはより多くのコードベース探索とより多様な自己検証行動を示すことが分かった。つまりモデルが身につけたのは単に正解を出すことだけでなく、行動する前に状況を把握し、行動した後に確認するという、エンジニアの習慣に近いものだったのである。