RD-Agent を導入前に読む：MLE-bench の結果とシナリオ構造、その限界
Research and development (R&D) is crucial for the enhancement of industrial productivity, especially in the AI era, where the core aspects of R&D are mainly focused on data and models. We are committed to automating these high-value generic R&D processes through R&D-Agent, which lets AI drive data-driven AI. 🔗https://aka.ms/RD-Agent-Tech-Report
ひと目でわかる
- これは何？
- Microsoft の RD-Agent は、データ分析とモデル開発のループを LLM エージェントに回させる実験的フレームワークである。MLE-bench での成績は README に記載されているが、向き不向きはシナリオの実装状況に強く依存する。
- 誰に向いている？
- 採用を検討すべきなのは、Kaggle 型の表形式タスクやファクター探索のように、評価指標をコードで自動採点できるループをすでに持っているチームである。逆に、正解ラベルが存在しない探索的リサーチや、評価に人間の判断が不可欠な業務には向かない。
- 商用利用できる？
- できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。直近 1 日以内に新しいコミットがあります。
- 何の言語で書かれている？
- 主に Python です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
RD-Agent が自動化しようとしているのは「実験の反復」である
README は R&D の核心をデータとモデルに置き、その高価値な汎用プロセスを自動化すると述べている。ここで対象になっているのは、アイデアを書く、コードを書く、実行する、結果を評価する、次のアイデアに反映する、という反復そのものである。単発のコード生成ツールではない。
誰のためのものかは、リポジトリの構成からおおよそ見当がつく。scenarios ディレクトリ以下に用途別の実装が並び、その中に Kaggle 系のデータサイエンス、定量取引のファクター探索、LLM のファインチューニング、強化学習のポストトレーニングが含まれる。つまり利用者は、評価関数を自分で書けて、その評価を回す計算資源を持っている人である。評価が自動化できない領域にこのツールを持ち込んでも、ループが回らない。
ループの実体はシナリオごとに別物である
RD-Agent は単一のアルゴリズムではなく、シナリオごとに仮説生成、コード生成、実行、フィードバックの経路を組み替える枠組みとして提示されている。README のニュース欄には、定量取引向けの R&D-Agent-Quant、Kaggle 向けの Kaggle Agent、汎用の Data Science Agent、LLM ファインチューニング向けの FT-Agent が別々の項目として並ぶ。それぞれに個別の README とガイドが用意されている点が重要で、共通の抽象化があるにせよ、実際に動かす単位はシナリオである。
この構造は、成熟度がシナリオ間で均一でないことを意味する。あるシナリオでは論文とコードが揃っていても、別のシナリオでは README が最小限ということが起こりうる。導入判断は「RD-Agent が使えるか」ではなく「自分のタスクに近いシナリオがどこまで書かれているか」で下すべきである。
MLE-bench の数字は README に表として載っている
README は MLE-bench を、75 の Kaggle コンペのデータセットを使うベンチマークとして説明している。その表で R&D-Agent は、o3 を推論側、GPT-4.1 を開発側に置いた構成で All 30.22 ± 1.5、o1-preview 構成で All 22.4 ± 1.1 と記載されている。比較対象として AIDE の o1-preview 構成の行も同じ表にある。
注意したいのは、この数字がモデルの組み合わせに強く依存する点である。表の行はエージェント名とモデル名の組で定義されており、RD-Agent というソフトウェア単体の性能を示すものではない。また README は自らを「top-performing」と表現しているが、これはプロジェクト側の主張であり、著者が追試したわけではない。数値を採用判断の根拠にするなら、同じベンチマークを自分の環境で回す必要がある。
動かすための入口は rdagent コマンドと LiteLLM バックエンド
README が示す実行の入口は rdagent コマンドである。Web UI については、rdagent server_ui でビルドおよび配信できる新しいフロントエンドが用意され、リアルタイムの対話とトレース閲覧に使えると記載されている。ただしこの UI は data_science シナリオを現時点で対象外としている。
モデル接続は LiteLLM が既定のバックエンドとして採用され、複数の LLM プロバイダーを切り替えられる。設定は環境変数と設定ファイル経由で行う形になっており、どのキーをどこに書くかは readthedocs の各シナリオのガイドに分かれている。特定のシナリオの設定キーをこの記事で列挙することはしない。README からは確認できないためである。
実行環境として README は Linux をプラットフォームとして掲げ、PyPI に rdagent パッケージが公開されている。Python の対応バージョンもバッジで示されているが、具体的な下限は README の本文には書かれていない。
向かないケース：評価が自動化できないタスク
このツールの弱点は、性能ではなく前提にある。ループを回すには、生成されたコードを実行し、その結果を数値なりスコアなりで採点できる必要がある。採点ができない、あるいは採点に人間のレビューが挟まるタスクでは、エージェントは改善の方向を知る手段を持たない。
もう一点、README のニュース欄が研究発表とベンチマーク公開を中心に構成されていることも見ておきたい。ACL、ICML、NeurIPS といった採択の告知が並び、機能追加の告知も混在する。研究色の強いプロジェクトであり、破壊的な変更がバージョン間で入りうる。実際、リリースは v0.6.1、v0.7.0、v0.8.0 と短期間で進んでいる。長期の安定運用を前提にした依存は避けたほうがよい。
比較対象としての AIDE と、その違い
MLE-bench の表には AIDE の行があり、o1-preview 構成で Low == Lite 34.3 と記載されている。同じ表の R&D-Agent o1-preview 構成は Low == Lite 48.18 ± 2.49 である。同じベンチマーク上で並べられている以上、比較の出発点としては AIDE が最も素直な相手である。
両者の違いは、README から読み取れる範囲では、RD-Agent がシナリオという形で対象領域を明示的に分け、それぞれに専用のループとガイドを用意している点にある。定量取引のファクター探索や LLM ファインチューニングのように、評価の設計がドメイン固有になるタスクでは、汎用のコーディングエージェントをそのまま当てるより、専用ループのほうが噛み合いやすいという主張だと解釈できる。ただし、この違いが実測でどう出るかを本記事で示すことはできない。
ライセンスと更新コスト
ライセンスは MIT である。MIT は商用利用を含めて寛容な条件のライセンスとして広く知られているが、本記事は法的助言を行うものではない。自組織のポリシーに照らした確認は別途必要である。
更新コストの面で見ておくべきは、リリース間隔の短さと、シナリオごとに README が分かれている構成の組み合わせである。本体の更新に追随するだけでなく、使っているシナリオのガイドが更新のたびに変わっていないかを確認する必要がある。特に LLM バックエンドは LiteLLM 経由で外部プロバイダーに依存するため、モデル名やパラメータの変更がそのまま設定ファイルの修正につながる。導入時には、どのモデル名をどの設定キーに書いたかを記録しておくと、後で差分を追いやすい。
編集部の結論
採用を検討すべきなのは、Kaggle 型の表形式タスクやファクター探索のように、評価指標をコードで自動採点できるループをすでに持っているチームである。逆に、正解ラベルが存在しない探索的リサーチや、評価に人間の判断が不可欠な業務には向かない。最初に確認するのは、自分のタスクが README のシナリオ一覧のどれに近いか、そしてそのシナリオの README が Quick Start として何を要求しているかである。data_science シナリオは Web UI の対象外と明記されているため、UI 経由の運用を前提にするなら、そもそも候補から外れる。
コミュニティノート