MLE-Dojo：
LLMエージェントのための
機械学習エンジニアリング環境

01 — 問題設定

なぜ「インタラクティブな実行環境」が要るのか

事実MLE（機械学習エンジニアリング）は、その本質的な複雑さ・専門知識・反復的な実験の必要性から、コーディング一般とは異なる難しさを持つ。著者は、自律的なMLEエージェントの開発が「まだ揺籃期にある」原因を、包括的なベンチマーク・実行可能な学習環境・標準化された評価枠組みの欠如に帰している。

既存ベンチマークの限界

• 事実多くは孤立したタスク（データ分析・可視化など）や、対話性のない狭いコンペ設定に留まる（DS-1000・等）。
• 事実MLE-Bench・DSBenchはタスク多様性を広げた（それぞれ75・74コンペ）が、反復実験・ファインチューニング・RLを支える対話的環境を欠く。
• 事実SWE（ソフトウェア工学）タスクはGitHub issue等から容易に調達できるが、MLEは体系的にキュレートされたデータと標準化された学習データを必要とし、これが既存環境に欠けている。

02 — フレームワーク全体像

POMDPとしてのエージェント–環境ループ

事実エージェントから見ると、環境はタスク空間 𝒫 からサンプルされた問題 p ∈ 𝒫 を中心に構成される。各ステップの相互作用は部分観測マルコフ決定過程（POMDP）として定式化される。

事実各タスク環境は、データセット・評価指標・分析結果・コード実行結果・エラーメッセージ・相互作用履歴といった必須情報を保持する。エージェントは典型的に、タスク情報の要求・コードの記述と実行・生成コードの評価・履歴の取得・リセットといった行動でタスクを解く。

03 — モジュラーインターフェース

4つの中核モジュールと単一の env.step()

事実各コンポーネントは独立かつ協調的に動作し、完全に疎結合で、統一された登録（register）機構を通じて拡張できる。論文は以下の4モジュールを中核と定義する。

# 自作モジュールでの拡張も、既製環境の直接利用も可能
obs, reward, done, info = env.step(action_type, action_args)

事実論文は、エージェントのカスタマイズ／開発の障壁を下げるため、相互作用が env.step(action_type, action_args) への単一呼び出しで済むと述べる。引数名・戻り値の正確なシグネチャは本文では完全には定義されていない（不明）。

04 — 拡張可能なタスク空間 𝒫

Docker隔離 ＋ サンドボックス実行

• 事実各タスクは個別のDockerコンテナで実行され、再現性とタスク間の独立性を担保する。
• 事実コンテナ内にサンドボックスを実装し、時間制限・GPU/CPUメモリ制約などの実験設定を構成可能にして、制御された安全で統一的な環境を提供する。
• 事実環境をprivate／publicのセグメントに分離し、一部ディレクトリはアクセス不可（private）、他は共有（public）とすることで、安全で信頼できるテスト空間を作る。

プラグアンドプレイのタスク追加

事実新規タスクのために統一フォーマットを定め、(1) 基本情報（コンペ説明・サンプル提出）、(2) prepare.py による整形済みデータ分割、(3) コンペ固有指標で評価されるpublic/privateリーダーボード、を維持する。これに従えば利用者は自前コンペを容易に組み込める。

competition/
├─ data/
│  ├─ private/   # test_answer.csv, *_leaderboard.csv
│  └─ public/    # train/test, description.txt,
│                #   sample_submission.csv
├─ utils/
│  ├─ prepare.py # データ整形・分割
│  └─ metric.py  # コンペ固有の評価指標
└─ info/ (任意)  # web_url.txt, raw_description.txt 等

05 — タスク・データセット構築

~600候補から200リリースへ

事実初期に約600のKaggleコンペから出発し、説明の明確さ・データ可用性・評価指標の妥当性で手動審査。過大・扱いにくいデータを除外し、挑戦性と計算的実現可能性のバランスをとって第1リリースの200コンペを得た。

出所の内訳

事実出典：本文 §3.2。単純合計（68+74+75=217）から重複を除いて「200超」としている。

タスクの広がり

• 事実4大ドメイン：テーブルデータ・コンピュータビジョン（CV）・自然言語処理（NLP）・MLE-Lite。合計15種の具体的タスク型を含む。
• 事実MLE-Lite はMLE-Benchの軽量サブセット（22コンペ）で、CV・NLP・Tabular・Audioを含む（評価スイートへの取り込み容易性を重視）。
• 事実各タスクは MLE-Bench に倣い統一構造へ標準化：(1) 説明、(2) train/test分割した元データ、(3) ローカル評価クラス、(4) リーダーボードのスナップショット。
• 解釈4大ドメインに「Audio」は集計上含まれないが、MLE-Liteの内訳としては音声タスクも存在する点に注意（評価表の列はMLE-Lite/Tabular/NLP/CVの4分類）。

06 — 観測空間 𝒪

5つの観測コンポーネント

事実MLE-Dojoはリッチな観測空間を5要素で提供する。

07 — 拡張可能な行動空間 𝒜

5つの基本アクション ＋ ユーザー定義ポータル

事実基底の行動空間は生の実行可能Pythonコード。エージェントは情報を要求し、コードを生成し、サンドボックス内のインタプリタへ接続する。既定で拡張可能な5アクションを提供する。

事実出典：本文 §4.5。execute_code の呼び出し回数に制限を設けることで、方法論・実験設計の柔軟な要件に対応できる。

08 — 報酬空間とフィードバック

HumanRank Score：人間リーダーボード上の相対位置

事実コンペごとに指標（accuracy・F1など）も範囲も異なるため、絶対性能をそのまま報酬にするのは不正確。著者は、既存ベンチの粗いメダルではなく人間リーダーボード上の相対順位を、連続的で細粒度な報酬として用いることを提案する。

s = 1 − p / N        # p: 提出の順位, N: 総提出数
# s は「上回った人間参加者の割合」を表す（高いほど良い）
# public/private 各リーダーボードで独立に算出し、その平均を最終報酬とする

• 事実元の性能指標と整合：生スコアが高いほどHumanRankも高い（指標に依らず狭義に正の相関）。
• 事実[0,1]に正規化され、タスク間のスコア桁差を解消し、統一的で情報量のある報酬として機能する。
• 事実public/private間のバイアスを避けるため、各リーダーボードで独立に相対スコアを算出し平均する。

09 — インタラクションループ

1セッションの流れ（概念図）

事実論文はFigure 5で「理論モデル（左）と具体的なPython API（右）」としてループを提示している。以下は本文記述から再構成した概念的な擬似コードであり、正確な実装シグネチャではない（解釈）。

obs = env.reset(task=p)              # p ∈ 𝒫 をサンプル
while not done and steps < 15:        # 最大15ステップ
    a = agent.act(obs, history)      # request_info / validate_code /
                                     #   execute_code / get_history / reset
    obs, reward, done, info = env.step(a.type, a.args)
    # reward = HumanRank ∈ [0,1]（execute_code 成功時のみ）

10 — 学習・評価フロー

SFT・RLの軌跡サンプリングと評価設定

事実完全実行可能な環境が、教師ありファインチューニング（SFT）とRLの両方での包括的なエージェント学習を支える。150タスクの学習セットが軌跡サンプリングを提供し、リアルなデータサンプリングとリアルタイムの結果検証を可能にする。

評価の環境設定（§5.1）

評価指標（§5.1, Appendix E）

• 事実AUP（Area Under the Performance Profile）：ML-Gym由来。性能プロファイルを積分しロバスト性を1スカラーに集約。実行不能な解には最悪実行性能に対するペナルティを付与。
• 事実HumanRank Score（H-Rank, %）：人間リーダーボード上の相対順位（絶対的な性能の物差し）。
• 事実Elo ranking：Chatbot Arena方式。各コンペを2モデルの「対戦」と見なし勝敗から算出。スケール S=400・初期 R₀=1000・ブートストラップ R=100回（固定シード）で中央値を報告。

11 — 評価結果（ハイレベル）

8モデル × 4ドメインの傾向

事実以下は Table 2 から抽出した HumanRank（%） の値。読みやすさのため4ドメインのH-Rankのみを掲載（AUP・Eloは本文・別記）。横スクロールで全列を確認できる。

事実出典：arXiv HTML版 Table 2（H-Rank列）。各セルの正確な転記。AUP・Eloの全列は割愛。

読み取れる傾向

• 事実推論・コーディング系（o3-mini・DeepSeek-r1・Gemini-2.5-Pro）が全指標で一貫して高位。Gemini-2.5-Proは全4ドメインのH-Rankで最高。
• 事実CVが最難：平均HumanRankが60を超えるCVタスクは皆無で、半数超が30未満（Figure 7記述）。MLE-Liteは多くが30超。
• 事実EloではGemini-2.5-Proが各ドメインで上位（例：NLP 1266・MLE-Lite 1257・CV 1177・Tabular 1150）。Eloは相対的強弱を示すが性能差の絶対量は示さない。
• 事実行動戦略の差：o3-miniは検証を経ず実行へ直行する傾向（execute比率90%超）。gpt-4o系は保守的で実行は約20%、検証に依存。
• 事実ステップ動態：o3-miniは初期5ステップ程度で高性能に到達し安定。DeepSeek-r1・Gemini-2.5-Proは中〜後半で漸進的に改善。非推論モデルは後半の伸びが乏しい。

コスト・エラーの観察

• 事実推論モデル（例：DeepSeek-r1）は価格と長い出力により総コストが高くなりがち。ただしDeepSeek-r1は少ないトークンで競争力ある性能を出す場合があり、コスト効率の余地を示唆。
• 事実CV・深層学習パイプラインのタスクは、CPU上の古典的MLより一貫して長いコードを生成。
• 事実失敗率：Gemini-2.5-Proが最低。DeepSeek-r1は高性能だが実行・検証の失敗率が比較的高い。Gemini-2.0-Flashは積極実行と低失敗率を両立。
• 事実実行エラー型は「Execution Failed／Submission Not Created／Submission Invalid」に分類。強いモデルほど長く複雑なコードゆえ「Execution Failed」を起こしやすいが、成功時は有効提出・高性能に至りやすい。
• 事実チャット履歴長と最良解の長さは正の相関で、ともに性能と正相関。解釈長さ自体は良さを保証しないが、より高い能力のモデルが複雑な解空間を探索できている代理指標と読める。
• 不明コスト分析からGemini-2.0-Pro/2.5-Proは（無料利用のため）除外されており、これらの絶対コストは本文では不明。

12 — エージェントハーネス設計への示唆

MLE-Dojoから持ち帰れる設計原則

解釈以下は原典の設計選択から、エージェントハーネス（足場）一般へ一般化した本レポートの読み筋であり、論文が明示的に主張する設計指針とは限らない。

13 — 再実装チェックリスト

同等環境を組むための要点

解釈原典の記述から、最小限同等の環境を再構成する際に押さえるべき項目を整理（一部は実装詳細が原典で完全には開示されておらず、リポジトリ参照が必要）。

• タスク標準化：data/{private,public} ＋ utils/{prepare.py,metric.py} ＋ 任意の info/ の統一ディレクトリへ整形（事実）。
• データ分割：test正解が無いKaggleタスクは prepare.py でtrainを新train/testに分割（事実）。
• 評価クラス：汎用Metric基底クラスを継承し、コンペ固有指標と提出フォーマット検証を実装（事実）。
• HumanRank報酬：s = 1 − p/N を public/private 各リーダーボードで算出し平均（事実）。
• 4モジュール：Error / Interface / Feedback / Metric を疎結合に実装し register 機構で接続（事実）。
• 5アクション：request_info / validate_code / execute_code / get_history / reset ＋ ユーザー定義ポータル（事実）。
• 実行隔離：タスク単位Docker＋サンドボックス（時間・GPU/CPUメモリ制約、private/public分離）（事実）。
• 観測：データセット情報・評価スコア（生＋HumanRank）・実行結果・エラー・履歴（会話／環境記録）の5要素（事実）。
• プロンプト規約：厳格JSON応答、可視化禁止、自己完結コード、output_dir へtestと同長で提出（事実, Appendix G）。
• 評価指標：AUP（ML-Gym式）・H-Rank・Elo（S=400, R₀=1000, R=100ブートストラップ）（事実）。
• セッション制約：15ステップ・12時間・GPU 32GB・入力50k/出力8,192トークン・提出無制限（事実）。
• 不明SFT/RLの具体的アルゴリズム・損失・学習ハイパーパラメータは本文に定量記載がなく、公式リポジトリの参照が必要。

14 — 限界と懐疑的注記

原典の限界 ＋ 本レポートの留保

論文自身が挙げる限界（Appendix A）

• 事実資源負荷：数百タスクで完全なMLEパイプライン（前処理・学習・デバッグ）を回すには、APIクレジット・CPU/GPU・大規模ディスクが必要。
• 事実データのライセンス／プライバシー：各Kaggleコンペのライセンスは異なる。フレームワークは独自データを再配布せず、Kaggle APIで取得。利用者にライセンス順守の責任がある。
• 事実タスク選定の偏り：公開コンペの可用性に制約され、全ドメイン・全人口統計的文脈を代表するとは限らない。LLMはバイアスを継承・増幅しうる。

本レポートの懐疑的注記

• 解釈「学習対応」と「学習実績」のギャップ：SFT/RLを支援すると述べる一方、本文の主要結果は既製モデルの推論時評価。学習済みエージェントの性能向上は本文では実証されていない。
• 著者主張「uniquely」「new standard」等の表現：独自性・新規性の主張は著者の評価であり、相対比較（Table 1）の自己申告に基づく。第三者検証は本稿の範囲外。
• 解釈HumanRank報酬の前提：人間リーダーボードのスナップショット品質・時点・参加者数Nに依存。Nが小さい／古いタスクでは報酬の安定性が下がりうる。
• 解釈「best of 2 runs」：各タスク2回の最良を採るため、報告値は分散の上側を反映する。単発運用時の挙動とは乖離しうる。
• 不明図に依存する詳細：Figure 1/6〜14の正確な数値・分布は画像を読んでおらず、本文記述の範囲でのみ言及している。
• 不明ライセンス種別：本文は「permissive licenseでのOSS維持」を約束するが、具体的なライセンス名は抽出テキストに明記がない。

15 — ソースと注記

出典・抽出範囲・再現性

• 事実一次情報源：MLE-Dojo 論文 arXiv:2505.07782v1（2025-05-12公開, cs.LG）。本レポートは原典の本文・表・付録テキストのみに基づく。
• 事実抽出方法：arXiv HTML版（arxiv.org/html/2505.07782v1）から抽出したテキスト。図の画像内容は読み取っていない。
• 事実公式資源：コード github.com/MLE-Dojo/MLE-Dojo、ページ mle-dojo.github.io、リーダーボード HuggingFace Spaces。
• 解釈本レポートの性質：手法・パイプラインの整理が目的。数値・引用は原典に忠実だが、見出しや一般化（特に §12 示唆）は編集上の解釈を含む。