AIDE ML を採用前に読む: 木探索エージェントの実装と運用コスト
AIDE: an LLM agent for machine learning engineering - the research Weco grew out of. Referenced in OpenAI MLE-bench.
ひと目でわかる
- これは何？
- AIDE ML は、LLM がコードを書き、評価指標で枝を刈りながら解を探す「木探索エージェント」の参照実装である。研究用途には向くが、本番運用や非決定的な出力を前提にしたワークフローには注意が必要だ。
- 誰に向いている？
- AIDE ML は、エージェント設計そのものを研究対象にしている人、あるいはデータセットと指標がすでに固まっていて探索の挙動を観察したい人に向く。逆に、決定的な出力や監査可能な再現手順を求める本番パイプラインの担当者には向かない。
- 商用利用できる？
- できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 12 日前です。
- 何の言語で書かれている？
- 主に Python です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
AIDE ML が埋める穴: 手書きのパイプライン試行錯誤を探索に置き換える
機械学習のパイプライン構築は、特徴量の作り方、前処理、モデル選択、ハイパーパラメータの組み合わせを試す作業の連続である。AIDE ML はこの試行錯誤を、LLM が生成した Python スクリプトと評価指標のフィードバックで駆動する探索問題として扱う。README は、これを「ユーザー定義の指標が最大化（または最小化）されるまでコードを起草、デバッグ、ベンチマークする木探索エージェント」と説明している。
対象読者として README が挙げるのは2種類だ。エージェントアーキテクチャの研究者は、探索ヒューリスティクスや評価器、LLM バックエンドを差し替える対象として使える。ML 実務者は、データセットを与えて高性能なパイプラインを素早く組み立てる用途を想定している。README の表現を借りれば、このリポジトリは「リファレンスビルド」であり、論文の再現、新しいアイデアの検証、ML パイプラインのプロトタイピングのための研究向けパッケージだと位置づけられている。商用プラットフォームとしての Weco とは別レイヤーである点も README が明示している。
解の木をどう育て、どう刈るか
中心にあるのは、コードの空間に対する LLM 誘導の木探索である。README の説明では、生成された各 Python スクリプトが解の木のノードになり、LLM が生成したパッチが子ノードを生む。評価指標のフィードバックが探索を刈り込み、方向づけする。つまり探索の単位は「コード全体の書き直し」ではなく差分パッチであり、ノードごとに実行結果のスコアが付く構造だ。
この設計の帰結として、探索の予算はステップ数とドラフト数という2つのつまみで決まる。agent.steps は改善イテレーションの回数、agent.search.num_drafts は1ステップあたりのドラフト数で、デフォルトはそれぞれ 20 と 5 と README の表に記載されている。単純に掛け算すれば1回の実行でかなりの数のコード候補が評価されることになり、その分だけ実行時間と LLM 呼び出しが増える。木構造の可視化は logs/<id>/tree_plot.html として出力され、どのノードがどのパッチから生まれたかを後から確認できる。探索の過程を追えるようにしてある点は、研究用途を想定した作りだと言える。
導入: pip install から最初の実行まで
インストールは pip install -U aideml の1行である。Python 3.10 以上が必要だと README のバッジが示している。LLM のキーは環境変数で渡す。README の例では export OPENAI_API_KEY=<your-key> を設定し、その後 aide コマンドで最適化を開始する。
aide data_dir="example_tasks/house_prices" goal="Predict the sales price for each house" eval="RMSE between log-prices"
タスク指定は自然言語で、goal と eval に加えてデータディレクトリを渡すだけだ。YAML のグリッドや専用のラッパーを書く必要はないと README は述べている。実行後は logs/<id>/best_solution.py に最良のコード、logs/<id>/tree_plot.html に解の木が残る。
モデルを差し替える場合は agent.code.model を指定する。README の例では claude-4-sonnet を選び、同時に agent.steps=50 へ増やしている。デフォルトのコード生成モデルは gpt-4-turbo と表に記載されている。OpenAI、Anthropic、Gemini、および OpenAI API 互換のローカル LLM を扱えると README は説明しており、モデル選択は設定値の差し替えで済む構造になっている。
CLI 以外の入口: Python API と Streamlit UI
CLI を経由せず、Python から直接 Experiment を組み立てることもできる。README の例では aide.Experiment に data_dir、goal、eval を渡し、exp.run(steps=2) で実行、戻り値の best_solution から valid_metric と code を取り出している。ロギングは標準の logging モジュールで設定し、"aide" というロガー名に対してレベルを指定する形だ。ノートブックや既存の実験スクリプトに組み込みたい場合、この経路のほうが扱いやすい。
もうひとつの入口が Streamlit 製の Web UI である。こちらは pip では入らず、リポジトリを clone して pip install -e . を実行し、aide/webui ディレクトリで streamlit run app.py を起動する手順が README に示されている。サイドバーに API キーを貼り、データをアップロードし、Goal と Metric を設定して Run AIDE を押す。実行ログ、解の木、最良コードが画面に表示される。UI を使うにはソースからのインストールが必要で、pip install aideml だけでは完結しない点は覚えておきたい。
向かない場面: 非決定性と検証コスト
最大の制約は、これが LLM の生成と評価のループである以上、同じ入力から同じ出力が得られる保証がないことだ。README は決定性やシード固定について何も述べていない。生成された best_solution.py が期待通りに動くかは、結局人間が読んで確認する必要がある。評価指標が良かったという事実は、そのコードが業務上の制約（データ漏洩の回避、前処理の妥当性、計算資源の上限）を満たしていることを意味しない。
もう一点、探索の予算設計を誤ると費用が読めなくなる。agent.steps と agent.search.num_drafts を増やせば候補数が増え、LLM 呼び出しとコード実行の両方が比例して増える。README には1回の実行あたりの所要時間やトークン消費量の目安が示されていないため、初回は小さな steps で挙動とコストを測ってから本番データに近いタスクへ進むのが現実的だ。データセットが巨大な場合や、1回の学習に数時間かかるタスクでは、木探索の反復そのものが成立しにくい。
比較の軸: 線形エージェントとの違いと、Weco 製品との関係
README が対比として挙げるのは、OpenHands に代表される線形エージェントである。OpenAI の MLE-bench（75 の Kaggle コンペ）において、AIDE の木探索は最良の線形エージェントより4倍多くのメダルを獲得したと README は述べている。これは README が引用する評価結果であり、この記事で独自に検証したものではない。重要なのは結果の数字そのものより、アプローチの差だ。線形エージェントは1本の履歴を伸ばしていくのに対し、AIDE は複数の候補を並行して育て、指標で枝を選別する。行き詰まった探索経路を捨てて別の枝に資源を移せる点が構造上の違いである。
もうひとつの比較対象は同じ開発元の Weco 製品だ。README は Weco を、AIDE の能力をより広いコード最適化に一般化し、実験トラッキングとユーザー制御を加えたプラットフォームと説明している。aideml はその参照実装であり、実験と拡張のための簡素な実装だと位置づけられている。研究目的でアルゴリズムを触りたいなら aideml、実験管理や制御を求めるなら Weco、という住み分けが README の記述から読み取れる。
ライセンスと保守の見通し
ライセンスは MIT で、リポジトリのバッジにも明記されている。MIT は商用利用を含む幅広い利用を許す条件だが、生成されたコードの権利や、利用する LLM プロバイダの規約は別問題である。ここは法的助言ではなく、確認先の整理として読んでほしい。
保守の面では、リポジトリはアーカイブされておらず、最終 push は 2026-09-03 と記録されている。リリースは v0.1.4（2024-04-29）、v0.2.0（2025-01-23）、v0.2.2（2025-11-05）と続いており、メジャー番号が 0 の段階にある。0.x 系である以上、設定キーや API の変更が破壊的に入る可能性は残る。依存を固定して使うなら、リリースタグを指定してインストールし、アップグレード時は agent.code.model や agent.steps といった設定キーの互換性をリリースノートで確認する作業が必要になる。
採用判断のチェックリスト
最初に確認すべきは、解の木の出力を誰が読むかである。logs/<id>/tree_plot.html と best_solution.py を人間がレビューできる体制がないなら、探索の結果をそのまま本番に流すことになり、この道具の利点は活きない。次に、評価指標を eval に一文で書ける粒度まで具体化できるか。指標が曖昧なまま agent.steps を増やしても、探索は曖昧さをそのまま増幅するだけだ。
予算の見積もりは小さく始める。example_tasks/house_prices のような同梱の例で agent.steps を小さく設定して実行し、1ステップあたりの時間と API 消費を測る。その数字を基に本番タスクの steps と num_drafts を決める。モデルを切り替える場合は agent.code.model の変更が探索の質と費用の両方に効くため、同じタスクで比較してから固定する。これらはすべて README に記載された設定キーと出力パスで完結する作業である。
編集部の結論
AIDE ML は、エージェント設計そのものを研究対象にしている人、あるいはデータセットと指標がすでに固まっていて探索の挙動を観察したい人に向く。逆に、決定的な出力や監査可能な再現手順を求める本番パイプラインの担当者には向かない。導入前に確認すべきは、agent.steps と agent.search.num_drafts を実行時間と API 課金の上限にどう収めるか、そして logs/<id>/best_solution.py を人間が読んで受け入れられる状態かどうかである。この2点が確認できないなら、木探索の利点はコストに見合わない。
コミュニティノート