MLGym：AI研究エージェントのための
フレームワークとベンチマーク

読み方

出典バッジの凡例

本レポートは、論文の全文抽出テキスト（抄録〜本文・付録・プロンプト）に直接裏付けられた事実と、著者の主張、レポート側の解釈、原論文でも確定していない点を、文単位でバッジ分離します。引用・意思決定の際は、数値の桁・図表番号を必ず原論文 PDF で確認してください。

本版で引用する数値は、論文の Table 1〜10 と本文（第3〜8章・第12章付録）に基づきます。図（Figure 2〜12）の細部のみ原論文を参照してください。AUPスコア・生スコア・計算コスト・トークン課金・失敗モード・行動分析の各データは原論文に存在し、本文に直接引用しています。

動機

なぜ「エージェントを動かすループ設計」に効くのか

MLGym は単なるベンチマークではなく、エージェント＝環境＝タスク＝ツール＝評価を一つのループに束ねる「ハーネス」そのものを提示している。ループを設計する側にとって、これは設計判断の生きた事例集として読める。

• 出典事実論文の Table 1 は、MLGym を MLE-Bench／SWE-Bench・SWE-Agent／MLAgentBench／RE-Bench／ScienceAgentBench と 5つの軸——Gym インターフェース・アルゴリズム的タスク・オープンエンド研究・柔軟な成果物・エージェント的ハーネス——で比較し、5軸すべてに ✓ が付くのは MLGym のみだと整理する。
• 出典事実既存フレームワークは RL・カリキュラム学習・オープンエンド学習といった学習アルゴリズムの研究を想定していない。MLGym は Gymnasium インターフェースを備えることで、これらの訓練アルゴリズム研究を可能にすると主張する。
• 出典事実MLGym は柔軟な評価成果物を許す——CSV 提出（MLE-Bench）やユニットテスト（SWE-Bench）に縛られず、モデルチェックポイント・RL アルゴリズム・ゲーム戦略コードなどを「エージェントが呼べる Python 評価スクリプト」で採点できる。
• 出典事実MLGym は標準のエージェント・ハーネス（scaffold）を同梱し、任意のベースモデルを「同一ハーネスのまま」公平に比較できる。著者は、ハーネスとモデルを両方差し替えてしまう既存研究との違いとしてこれを強調する。
• 解釈つまり MLGym の差別化点は「ループ自体を実験対象にできる」こと。エージェントを固定してタスクを測るのではなく、ループのパーツ（行動空間・報酬・反復回数）を差し替えて研究できる構造になっている。

フレーミング

AI研究エージェントの「能力レベル」という枠組み

出典事実論文 §1.1 は、AI研究エージェントの能力を6段階（Level 0〜5）で捉える階層的フレームワークを提案する。各レベルは自律性と科学的貢献の度合いで定義される。

• 出典事実著者は明確に「MLGym-Bench は Level 1（Baseline Improvement）に焦点を当てる」と述べる。本論文の結果は、フロンティアモデルが Level 1 で何ができるかの測定だと位置づけられる。
• 出典事実長期ビジョンとして、研究エージェントは文献調査・仮説生成・実験設計・新手法の実装・結果分析・論文執筆までを担い、完全自律でも人間の監督下でも動作できる存在とされる。
• 解釈この6段階は「ハーネスが何を引き出せるか」の目盛りとして使える。現状の評価は Level 1 に留まり、Level 2 以上（新規性）はまだ測定対象ですらない、というのが暗黙のメッセージと読める。

アーキテクチャ

MLGym フレームワークの構成（第3章）

出典事実MLGym は Gymnasium（gym）環境として実装され、ローカル Docker マシンのシェルでコマンドを実行する。セキュリティ上、root ではなく非 root ユーザ agent を作り、作業ディレクトリに適切な権限を設定する。フレームワークは Agents・Environment・Datasets・Tasks の4コア要素＋ Tools/ACI を提供し、モジュール設計で拡張容易だとされる。

研究ループの形（本文 §3 冒頭）

• 出典事実著者は、エージェントが「タスク記述・スターターコード・行動／観測履歴」を与えられ、アイデア生成→データ処理→新手法の実装→モデルの訓練と評価→結果分析→次に走らせる実験の推論、というシェルコマンド列で ML 研究を進める、と述べる。エージェントは前コマンドの実行フィードバックに基づき反復プロンプトされ、文脈内で解を自己改善する。
• 出典事実抄録も同様に「アイデア・仮説の生成 → データ作成・処理 → ML 手法の実装 → モデル訓練 → 実験実行 → 結果分析 → 反復改善」を必要スキルとして列挙する。

obs = env.reset(task)            # docker shell・read-only データ・評価スクリプトを用意
while step < 50 and not done:     # 既定の上限は 50 ステップ
    action = agent.act(history)  # ReAct: discussion + 単一コマンド
    obs, info = env.step(action) # bash / edit / view / validate ...
    history.append((action, obs))# 直近5往復をローリングウィンドウで保持
    score = env.validate()       # 終端でない検証。何度でも呼べる
agent.submit()                   # 終端アクション（未提出なら最終状態を自動提出）

擬似コードは本文 §3・§5.2 の記述（50ステップ上限・直近5往復のローリングウィンドウ・validate/submit の意味）を図式化したもので、実コードそのものではありません（解釈）。

行動空間

ツールと ACI（§3.5・Table 2）

出典事実ツールは SWE-Agent と同様、bash／python スクリプトとして定義され、bash コマンドとして提供される。全ツール文書はシステムプロンプトに載る。MLGym は SWE-Agent の ACI に権限管理を組み込み、文献検索とメモリモジュールを追加した。例えば read 権限のないファイルを開こうとすると、ビューアは黙って失敗せずテキストのフィードバックを返す。read-only の評価スクリプトを編集しようとした場合も同様。

• 出典事実validate と submit の使い分け：validate はテストセット上の現スコアを返す非終端アクションで、何度でも呼べる。submit は最終スコアを記録してトラジェクトリを終える終端アクション。validate の追加は、エージェントがテストセット上で継続的に性能を改善するのを助ける。
• 出典事実メモリモジュール（研究ログ）は memory_write/memory_read を持ち、テキスト＋埋め込み＋タグを JSON で保存、クエリと類似する上位 k 件を返す。タグは記録に最も近い 3-gram で抽出。メモリの状態（タグと件数）はシステムプロンプトにも反映される。著者は、メモリがあると最良の訓練設定を思い出して反復継続でき、無いとトラジェクトリが文脈長を超えて古い実験を「忘れる」と報告する（Figure 11・12）。
• 解釈「黙って失敗させず必ずテキストで返す」「read-only を構造的に守る」設計は、コーディングエージェントの ACI でもそのまま効く原則。失敗が観測可能であることがループの安定性を直接左右する。

ベンチマーク

MLGym-Bench の 13 タスク（第4章・Table 3）

出典事実MLGym-Bench は 13 個のオープンエンドな AI 研究タスクからなり、各タスクは標準の評価スクリプトとベースライン実装を伴う。以下は Table 3 と §4 本文に基づく完全な一覧。

• 出典事実ゲーム理論タスクでは、エージェントは相手の戦略コードを閲覧でき、コード理解と相手戦略の exploit 能力を測る。著者は将来、相手戦略を伏せ、複数相手と総当たり（Axelrod 流トーナメント）にする計画だと述べる。
• 出典事実評価成果物はタスクごとに異なる：RL は固定シードで訓練したモデル群の平均報酬、ゲーム理論は固定戦略群と対戦させる戦略関数の Python ファイル。CSV 提出に統一できないため、各タスクが評価スクリプトと提出物の指示を提供する。
• 解釈領域の幅（記号的な 3-SAT・ゲーム理論から、深層学習の CV/NLP、対話的な RL まで）は、単一ドメインへの過剰適合を避け、汎用的な研究遂行能力を測る意図と読める。

実験設定

エージェント・モデル・環境設定（第5章）

• 出典事実エージェントは SWE-Agent ベースで MLGym 用に適応。ReAct 流の thought→action ループ（Yao et al., 2023）で、ACI 文書・タスク／データ記述・「ML 研究者として振る舞え」という軽量な汎用指示が与えられる。1ステップ1コマンドに制限され、対話セッション系コマンド（python REPL・vim）は禁止。
• 出典事実評価対象は 5 モデル：OpenAI o1-preview、Gemini-1.5-Pro、Claude-3.5-Sonnet（20241022）、Llama-3.1-405B-Instruct、GPT-4o。temperature=0.0・top-p=0.95（o1-preview のみデコードパラメータ変更不可で temperature=1.0）。
• 出典事実環境設定（§5.2）：ウィンドウ 1000 行・オーバーラップ 2 行。コンテキスト処理は直近5往復（行動＋観測）のローリングウィンドウを保持。1 ラン 50 ステップ上限で、超えるとエージェントを終了し最後のコード状態を自動提出。訓練コマンドにはタスク固有のタイムアウトを設け、パラメータ増しによる時間稼ぎを防ぐ。

SETTING: You are an autonomous machine learning researcher,
and you're working directly in the command line ...
- You should only include a *SINGLE* command ... then wait for a response.
- The environment does NOT support interactive session commands (e.g. python, vim).
- Your goal is to achieve the best possible score, not just to submit
  your first working solution. Consider ... validating with `validate`,
  building custom validation sets, comparing different algorithms.
(Current Step: 0, Remaining Steps: 50)

上記は論文 §13（Listing 1）のシステムプロンプト原文からの抜粋です。各アクションは1800秒以内に完了する必要があり、超過すると中断されます（同プロンプト IMPORTANT TIPS 7）。

評価方法論

評価の枠組み：AUP と性能プロファイル（第6章）

• 出典事実タスクごとに指標のスケールが違うため、平均スコアや平均順位は不公平になりうる。そこで著者は最適化／AutoML 由来の性能プロファイル曲線（Dolan & Moré, 2002）と、その曲線下面積である AUP スコア（AutoML Decathlon 由来）を採用する。性能プロファイルは閾値 τ に対し「各タスクで最良手法の τ 倍以内に入るタスクの割合」を与える。
• 出典事実指標の向きを揃える：精度・R² など高いほど良い指標は性能比を反転して扱う。ベースラインを下回る／有効解を出せない手法は Infeasible とし、スコアを (1+ε)×baseline（ε=0.05）に設定する。
• 出典事実各モデル×タスクで 4 シード。validate を使えるため、2 系統のプロファイルを保持する——Best Submission@4（最終提出の最良）と Best Attempt@4（validate を含む観測上の最良）。前者は「最良を最終解として残せるか（途中のミスから回復できるか）」、後者は「探索の上限（潜在能力）」を表す。
• 解釈この二本立ては設計上きわめて実践的。Best Attempt は「モデルが解に到達できたか」、Best Submission は「ハーネスがその到達を取りこぼさずに確定できたか」を分離する。後者はまさにループ・状態管理の問題で、ハーネス設計者が直接効ける領域だ。

主要な発見

結果：何ができ、何ができないか（第7章）

• 出典事実o1-preview が Best Attempt・Best Submission 双方で総合首位、Claude-3.5-Sonnet と Gemini-1.5-Pro が僅差で続く。o1 は全タスクで支配的なわけではない（Gemini・Claude・Llama が個別タスクで先行することもある）が、多くのタスクで常に上位に入るため総合首位になる。
• 出典事実生スコア（Table 5・6）の例：CIFAR-10 はベースライン 0.497 に対し Claude が 0.895（Best Attempt）まで改善。MNLI はベースライン 0.525 から各モデル 0.78〜0.84 へ。一方、Llama-3.1-405B は Language Modeling、GPT-4o は Breakout で有効解を1つも出せなかった（表中 ∞ 表記）。詳細値は原論文 Table 5・6 を参照。
• 出典事実BORDA 集計の総合順位（Table 9・10）は AUP と整合：Best Submission では o1 > Gemini > Claude > GPT-4o > Llama > Baseline。全タスクで全モデルがベースラインを上回るわけではない点に注意。

できること／できないこと（著者の評価）

• 著者主張現行モデルは与えられたベースラインを改善できる——ただし多くは「より良いハイパーパラメータの発見」によるもの。
• 著者主張現行モデルは新規の仮説・アルゴリズム・アーキテクチャ、あるいは本質的（substantial）な改善を生み出さない。

コスト

計算コストとコスト効率（§7.3・§12.1）

• 出典事実o1-preview は最高性能だが断トツで最も高価。対して Gemini-1.5-Pro が最もコスト効率が良く、o1 の約 1/9 のコストで AUP の約 99% に達する。Claude-3.5-Sonnet も高性能かつ比較的低コスト。GPT-4o は最安級だが性能は上位群に大きく劣る。
• 出典事実コスト差の主因はトラジェクトリ長とトークン消費。Table 8 によれば o1 は平均出力 60,704 トークン（課金 $15/$60 per 1M in/out）と突出。Claude は入力 707,704／出力 12,415（$3/$15）、Gemini は 282,613／1,633（$1.25/$5）、GPT-4o は 266,886／2,429（$2.5/$10）、Llama は 304,348／2,512（Together AI の FP8、$3.5/$3.5）。
• 出典事実計算資源（Table 7）：タスクごとに訓練タイムアウト 30〜40 分、GPU 0〜2 基、平均エージェント実行時間は 30 分〜4 時間（CIFAR-10・Language Modeling が約 4 時間と最長）。
• 解釈「性能×コストのパレート」を評価の一部にする姿勢（Kapoor et al. を引用）は、ハーネス運用で直に効く。Gemini の優位は短いトラジェクトリ＝少ない往復から来ており、ループ長そのものがコストドライバーであることを示す。

挙動・失敗分析

エージェント挙動と失敗モード（§7.4・§12.2–12.3）

出典事実分析は 11 タスク×5 モデル×4 シード＝220 トラジェクトリに基づく。観点は (1) 終了エラー分布、(2) 失敗／不完全ラン率、(3) タスク別失敗パターン、(4) 行動分布。

失敗モード（Failure Mode Analysis）

• 出典事実終了エラーは context length exceeded / evaluation error / file permission error / cost limit exceeded / format error / runtime error に分類される。「Evaluation Error」が全終了エラーの 75% を占め最頻——その多くは最終ステップ／submit 時に提出物が欠落、または提出形式が不正なことで発火する。
• 出典事実Gemini-1.5-Pro は不正解を一度も提出しない唯一のモデル（次点が o1・Claude）。一方で Cost Limit エラーは Claude・Gemini・o1 で 2 番目に多く、予算を増やせばさらに改善余地があることを示す。Gemini は最もコスト効率が良いのに Cost Limit に最も多く当たる、という逆説的観察もある。
• 出典事実GPT-4o は失敗率が最高。Gemini と o1 は完了率が最良。Claude は上位性能ながら failed 率が高い。o1 は incomplete 率が高いが全タスクで必ず1つは有効解を出す。タスク別では Language Modeling と全 RL タスク（MetaMaze・MountainCar・Breakout）が最難、Fashion-MNIST と Prisoner's Dilemma が最も失敗が少ない（§12.2）。

行動分析（Action Analysis）

• 出典事実行動は Edit / View / Search / Validate / Submit ＋ Python / Bash に分類。Edit が全行動の 50% と最多、View も高頻度で、Search はわずか 1%。モデルは「編集→閲覧」の反復開発サイクルに多くの時間を費やす。
• 出典事実ステップ推移（Figure 8）：序盤は ls/pwd/cd 等の Bash で環境把握、中盤は Edit が支配的、Python と Validate は通して安定的に使われる。Submit は終盤に集中する一方、早ければステップ5で submit するモデルもあり、早すぎる提出が最適解到達を逃す一因になっている。
• 出典事実モデル別では GPT-4o の行動数が最少（早期エラー／早期提出と整合）。上位群では Claude と o1 が最多、Gemini が最少——これが Gemini の低コストに直結する。
• 解釈「Search が 1% しか使われない」「早すぎる submit が頻発」は、いずれもハーネス側で矯正できる failure。提出前ゲート（必須アーティファクト検査）と探索の促進（検索の可視化・残ステップに応じた提出抑制）は、そのまま改善レバーになる。

実践

コーディング／研究エージェントのハーネス設計への教訓

以下は MLGym の構造と実測から導いた設計上の示唆。論文の事実に紐づくものはその旨を記し、接続部分は解釈として示す。

チェックリスト

再実装・適応チェックリスト

MLGym 風のハーネスを自分の領域に立ち上げる際の最小チェックリスト（論文の事実に基づく実務指針）。

• タスク定義を設定ファイル化（データ・read-only 評価スクリプト・環境・スターター・訓練タイムアウト）。
• Gymnasium 風の環境 API（reset / step / observation）に載せ、Docker の非 root ユーザで隔離する。
• データと評価スクリプトを read-only コピーにし、改変・カンニングを構造的に防ぐ。
• ACI は権限違反・構文エラーを必ずテキストで返す（黙って失敗させない）。
• 非終端 validate と終端 submit を分け、Best Attempt と Best Submission を両方記録する。
• submit 直前に必須アーティファクト・提出形式を機械検査するゲートを置く（Evaluation Error 対策）。
• ステップ上限と残ステップをプロンプトに出し、早すぎる提出を抑制する。
• 柔軟な成果物（モデル／予測／戦略コード）を受け取れる評価器を用意する。
• 性能プロファイル＋AUP で複数タスクを横断比較し、Infeasible にベースライン基準のペナルティを課す。
• 行動ログ・失敗モードを計装し（Edit/View/Search/Validate/Submit）、定期的に分布を集計する。
• 長尺タスク向けに、最良試行を退避・再注入する構造化メモリを入れる。
• 「チューニングで届く改善」と「新規性が要る改善」を分けて評価設計する（Level 1 と Level 2+ の区別）。

このチェックリストは論文の設計と実測から導いた実装ガイドであり、論文が明文化した手順そのものではありません（解釈を含む）。

限界

限界・倫理・未解明点（第8〜9章）

論文が挙げる限界（§8 Discussion and Limitations）

• 著者主張ML 以外への拡張：大規模ドメイン固有データやより複雑なタスク、AI 以外の領域へ評価枠組みを広げる必要がある。
• 著者主張学際的アブレーションと汎化：新手法（例：Mamba）を DNA・化学分子・音楽生成など異領域へ自動適用し、汎化を体系的に検証すべき。
• 著者主張科学的新規性の扱い：「novelty／discovery」をエージェント向けに形式的に定義・自動化できるかは未解明。学際的な手法外挿はその一側面にすぎない。
• 著者主張データ開放性：再現可能なコード・科学的成果物・領域データの公開が科学加速に不可欠で、一度公開されたものを引き上げると進歩に回復不能な影響を与えうる。

倫理的考察（§9 Ethical Considerations）

• 出典事実著者は MLGym-Bench が各社の安全枠組みの指標になりうると述べる——OpenAI の Preparedness Framework のモデル自律性、Anthropic の Responsible Scaling Policy の自律能力、Google DeepMind の Frontier Safety Framework の ML R&D。
• 著者主張自律的に AI 研究を行うエージェント（例：自分の訓練コードを改良するもの）は能力を人間より速く押し上げうるため、理解・整合・制御の進展を伴わなければ危険。透明性のためにオープンソース化したとする。

本レポート上の注意

• 出典事実本論文の定量結果は Level 1（ベースライン改善）に限定された測定であり、SOTA 達成や新規性（Level 2+）の評価ではない。
• 解釈図（Figure 2〜12）の細部・正確な曲線形状は本テキスト抽出では数値化しきれないため、グラフ依存の主張は原論文の図を直接参照のこと。

出典

ソースノートとリンク

• 論文（HTML）：arxiv.org/html/2502.14499v1
• 論文（PDF）：arxiv.org/pdf/2502.14499v1
• コード（公式）：github.com/facebookresearch/MLGym
• 関連タスク repo：modded-nanogpt（Language Modeling、v8 を起点）／gymnax・gymnax-blines（RL タスク・PPO ベースライン）

著者：Deepak Nathani, Lovish Madaan, Nicholas Roberts, Nikolay Bashlykov, Ajay Menon, Vincent Moens, Amar Budhiraja, Despoina Magka, Vladislav Vorotilov, Gaurav Chaurasia, Dieuwke Hupkes, Ricardo Silveira Cabral, Tatiana Shavrina, Jakob Foerster, Yoram Bachrach, William Yang Wang, Roberta Raileanu（UCSB / UCL / UW–Madison / Oxford / Meta：FAIR・GenAI・PyTorch Core Libraries）。