--- arxiv_id: 2604.13018 title: "Toward Autonomous Long-Horizon Engineering for ML Research" authors: - Guoxin Chen - Jie Chen - Lei Chen - Jiale Zhao - Fanzhe Meng - Wayne Xin Zhao - Ruihua Song - Cheng Chen - Ji-Rong Wen - Kai Jia difficulty: Advanced tags: - Agent - Reasoning - Benchmark published_at: 2026-04-15 flecto_url: https://flecto.zer0ai.dev/ja/papers/2604.13018/ lang: ja --- ## Abstract 概要 自律型AI研究は急速に進歩していますが、長期間にわたる機械学習の研究開発は依然として困難です。エージェントは、タスクの理解、環境設定、実装、実験、デバッグにおいて、数時間から数日間にわたって一貫した進歩を維持する必要があります。私たちは、単純な原則に基づいたシステムであるAiScientistを紹介します。その原則とは、「優れた長期間のパフォーマンスには、構造化されたオーケストレーションと、持続可能な状態の連続性が不可欠である」ということです。AiScientistは、階層的なオーケストレーションと、権限範囲が設定されたFile-as-Busワークスペースを組み合わせたものです。上位レベルのオーケストレーターは、簡潔な要約とワークスペースマップを通じて、ステージレベルの制御を維持し、特殊なエージェントは、分析、計画、コード、実験データなどの持続可能な成果物に繰り返し再帰的に基づき、主に会話による情報伝達に依存するのではなく、「薄い制御で厚い状態を管理する」ことを実現します。2つの補完的なベンチマークにおいて、AiScientistは、最高の既存のベースラインと比較して、PaperBenchのスコアを平均10.54ポイント向上させ、MLE-Bench Liteでは81.82%のAny Medal%を達成しました。アブレーション研究により、File-as-Busプロトコルがパフォーマンスの重要な要因であることがさらに示されました。このプロトコルを取り除くと、PaperBenchのスコアが6.41ポイント、MLE-Bench Liteのスコアが31.82ポイント低下します。これらの結果は、長期間にわたる機械学習の研究開発は、局所的な推論の問題ではなく、専門的な作業を耐久的なプロジェクトの状態と連携させるシステムの問題であることを示唆しています。 ## Three Ideas at a Glance 概要：3つのアイデア Thin Control over Thick State Orchestratorは、ステージ間の移行においても、わずかながら安定したコンテキストのみを保持します。プロジェクトの重要な状態情報（ペーパー分析、計画、コード、ログ、実験記録など）は、会話の範囲外にある、アクセス権限が設定された共有ワークスペースに保存されます。 File-as-Bus Coordination エージェントは、チャットではなく、役割に合わせたアーティファクト領域（`paper_analysis/`, `submission/`, 追記専用ログ）を読み書きすることで連携します。 この機能を削除すると、MLE-Bench Lite Any メダルのスコアが 31.82 ポイント低下します。 ベンチマークで裏付け PaperBenchは、最も優れた既存モデルと比較して、平均で10.54ポイントの改善が見られました。MLE-Bench Liteは、81.82%の「あらゆるメダル」を獲得しました。これらの改善は、Gemini-3-FlashとGLM-5の両方の基盤構造で確認されました。 ## Introduction 1. 導入 科学研究の自動化は、人工知能における最も野心的な目標の一つとして浮上しています。特に機械学習（ML）においては、この進歩は、研究の発見を大幅に加速させ、再現性を向上させ、高品質な研究システムへのアクセスを広げる可能性があります。 このより広範な目標の中で、私たちはより実践的な課題に取り組んでいます。機械学習研究のための自律的な長期的なエンジニアリング。エージェントは、機械学習研究システムの構築、実行、そして数時間から数日かけて反復的に改善するという、エンドツーエンドの技術的な作業を自律的に行う必要があります。具体的には、問題は、仕様の不備、システム構築の負担、実験からのフィードバックの遅延と、しばしば誤った情報、そして反復処理を通して状態の一貫性を維持する必要性から生じます。 この課題に対し、私たちはAiScientistというソリューションを提供します。私たちの中心的な設計原則は、長期的なパフォーマンスを、オーケストレーションと状態の連続性の複合的な問題として捉えることです。エージェントは、異なる段階で作業を調整するだけでなく、プロジェクトの状態を十分に忠実に維持し、後続の意思決定がそれを安全に活用できるようにする必要があります。 私たちの貢献 ここでは、AiScientistをご紹介します。これは、研究仕様の解釈から実行可能なシステムの構築、実験、そして反復的な改善まで、機械学習研究の全プロセスを自動化するシステムです。 我々は、階層的なオーケストレーションと、アクセス権限に基づいた共有ワークスペースを組み合わせた、アーティファクト媒介型連携のデザインを提案します。ファイルバスプロトコルを通じて、システムは永続的なアーティファクトによって状態の一貫性を維持し、同時に上位レベルの制御を軽量に保ちます。 AiScientistをPaperBenchとMLE-Bench Liteで評価し、強力なベースラインと比較して大幅な改善が見られ、長期的な機械学習研究におけるエンジニアリング、特に持続可能な状態の連続性の重要性に関する実証的な洞察が得られました。 ## Task Formulation 2. タスクの定式化 我々は、PaperBenchを通じて、長期的な機械学習研究エンジニアリングタスクを定義します。与えられた研究論文P、GPUアクセス可能なシンプルなDocker環境E、および時間予算Tに対し、エージェントは、論文のターゲットメトリクスを再現する実行可能な成果物を生成する必要があります。 このことが難しい理由となる4つの課題： Underspecification 研究仕様は、通常、完全な設計図というよりも不完全なものです。重要な実装に関する詳細は、しばしば暗黙のものであり、セクションのあちこちに散らばっていたり、完全に省略されていたりするため、エージェントは限られた情報からそれらを推測する必要があります。 System Setup Burden 成功は、アルゴリズムの実装だけでなく、広範な準備作業にかかっています。具体的には、環境の構築、許可されたソースからデータセットとモデルの取得、そしてこれらのリソースを動作可能なシステムに統合することが必要です。 Delayed Feedback 実験が実施されて初めて、意味のある証拠が得られます。矛盾は、解釈、実装、データ処理、またはインフラストラクチャに起因する可能性があります。したがって、エージェントは、遅延し、しばしば誤った情報を含む信号に基づいて推論する必要があります。 State Continuity 各ラウンドでは、コード、設定ファイル、ログ、結果、および診断データが生成され、これらの情報は、その後の判断を下す際に正しく解釈され、活用されなければなりません。進捗は、イテレーション（反復）を通じて一貫性を維持することにかかっています。 ## System Overview 3. AiScientist: アーティファクトを活用した研究ラボ AiScientistは、長期的な機械学習研究エンジニアリングにおけるシンプルなシステム観に基づいて構築されています。優れたパフォーマンスは、作業を適切な段階に分解することだけでなく、プロジェクトの状態を十分に忠実に維持することで実現されます。これにより、後続の決定が安全にそれに基づいて行えるようになります。Tier-0のオーケストレーターは、簡潔な概要とワークスペースマップを通じて、ステージレベルの制御を維持し、Tier-1の専門家と、オプションのTier-2のサブエージェントは、共有され、アクセス権が設定されたワークスペース上で動作します。 図2. AiScientistのアーキテクチャ。これは、成果物を利用した研究ラボです。Tier-0のオーケストレーターは、ステージレベルの指示、簡潔な概要、およびワークスペースマップを通じて、制御を維持します。一方、Tier-1の専門家と、必要に応じて利用できるTier-2のサブエージェントは、権限範囲が設定されたワークスペースに成果物を読み書きすることで、作業を調整します。 ## Thin Control over Thick State 3.1. Thin Control over Thick State AiScientistの中核となるシステム原則は、制御は最小限に、状態は最大限にです。ここで、thinとは、ルーチンな制御判断を行うために必要な、小さく安定したコンテキストを指し、thickとは、反復処理を通じて一貫性を保つ必要のある、はるかに大きな外部化されたプロジェクトの状態を指します。 ステップtにおける作業領域をW_tと表記します。軽量な作業領域マップm_tは、主要な成果物領域とその役割をテキスト形式で索引としたものです。 定式化 作業領域マップ：これは、アーティファクト領域のテキストによる索引であり、作業領域へのナビゲーションインターフェースです。情報が失われたり、置き換えられたりするものではありません。 オーケストレーターのアクション選択：上位レベルのコントローラーは、ステージレベルのコンテキストとワークスペースマップを使用して、次のアクションを選択します。必要に応じて、ワークスペースをオンデマンドで検査することも可能です。 専門家による呼び出し: 専門家は独自のローカルループを実行し、簡潔な概要とワークスペースの更新情報のみを返します。 この設計は、制御と引き継ぎのレベルにおいて、段階的な情報開示を実現しています。Orchestratorは、ステージ間の移行に関わらず、わずかながら安定した制御インターフェースを提供し、蓄積されたチャット履歴ではなく、概要や地図に基づいて判断を行います。 ## File-as-Bus Coordination 3.2. ファイルをバスとして連携させる方法 AiScientistは、File-as-Busプロトコルによるアーティファクトを介した連携を実現します。長期間にわたる機械学習研究開発において、重要な中間状態は、すでにファイルとして扱われるものが多く存在します。具体的には、論文の分析、環境構築スクリプト、リソースダウンロードのマニフェスト、トレーニングコード、チェックポイント、評価指標、および追記専用の実行ログなどです。ワークスペースは、単なる保存場所ではなく、システム・オブ・レコードとして扱われます。 3 つの役割別アーティファクト領域 構造化された論文理解：論文理解スペシャリストによって生成される、ターゲット指標、曖昧さ、および実装に関連する詳細。 動作する再現用のリポジトリ：コード、トレーニングスクリプト、設定ファイル、および `reproduce.sh` という実行ファイルが含まれており、これは Implementation and Experimentation の専門家によって作成されました。 変更できない実行履歴。すべての試行（失敗、部分的な成功、メトリクスの欠落など）は記録され、後で意思決定を行う際に、継承された会話コンテキストに頼るのではなく、正確な履歴を調査することができます。 状態が共有チャットではなく、永続的な成果物に記録されているため、エージェントは現在のワークスペースの状態からプロジェクトを再開し、タスクに関連する領域を読み取り、完全な過去のやり取りを必要とせずに操作することができます。 ## Hierarchical Orchestration 3.3. Agent-as-Tool による階層オーケストレーション File-as-Bus連携が状態の基盤を提供するのに対し、階層的なオーケストレーションが制御メカニズムを提供します。 Orchestratorは、理解から計画、実行、実験、デバッグに至るまで、適切な専門知識を適切な段階に振り分けます。一方、専門家はそれぞれのローカルなサイクルを実行し、Tier-2のサブエージェントが、特定の、より細かなタスクを担当します。 主要な設計思想はAgent-as-Toolです。各スペシャリストは、シェル実行、ファイル検査、ウェブ検索といった通常のツールと同様の呼び出し可能インターフェースを通じて、Orchestratorに接続します。委任は、Orchestratorの通常のツール利用フロー内のアクションであり、各スペシャリストのプライベートなコンテキストは、各呼び出しごとに再初期化されるため、詳細な推論が上位レベルに累積されることはありません。 Tier-1 Specialists Paper Comprehension この論文の内容を、実装の詳細、目標とする指標、および不確実性に関する記述に変換します。複数のサブエージェントを連携させ、独立した分析軸を並行して処理し、その後で統合することができます。 Prioritization 論文の内容を理解し、それに基づいて実行可能な契約を策定します。具体的には、依存関係を特定し、マイルストーンを重要度と実現可能性に基づいてランク付けし、その計画を`prioritized_tasks.md`というファイルに記述します。 Implementation 計画や問題報告をコードに変換します。フルモードでは、分析データと優先順位付けされた計画に基づいて、再現可能なリポジトリを構築します。修正モードでは、指示に基づいて既存のコードベースを修正します。 Experimentation エンドツーエンドのパイプラインを実行し、生成されたメトリクスを論文の目標値と比較し、結果と未解決の問題を`exp_log.md`に記録します。 Generic Helper 補助的なタスク、例えば探索、計画、または特定の状況下での一時的な作業などを行うための、軽量なヘルパー機能を生成します。これらのタスクは、専門家による専用のワークフローを必要としない場合に役立ちます。 Tier-2 サブエージェントは、専門家のローカルな範囲内で作成される、特定の機能に特化した基盤となるワーカーです。これには、構造抽出、アルゴリズムとベースラインの分析、環境構築、リソースのダウンロード、および予備調査が含まれます。 ## Evidence-Driven Loop 3.4. データに基づいた研究・開発サイクル AiScientistは、固定された一方向のパイプラインではなく、進化し続ける作業領域全体にわたる、エビデンスに基づいた研究・エンジニアリングのサイクルを運用します。 プロジェクトの初期段階では、Orchestratorは論文の理解と優先順位付けを重視し、明確でランク付けされた計画に基づいて実装を進めます。 一度、基本的なフレームワークが構築されると、主要なパターンは実装と実験の反復的な交互になります。 このループは、実行可能な証拠によって駆動されます。実験的な実行では、失敗トレース、部分的な成功、メトリックの欠落、およびリソースのボトルネックが発生し、次に何を構築、修正、またはテストすべきかを決定します。これらの出力は、永続的な成果物として記録され、将来の反復処理でそれらを正確に分析できるようにします。 図1. ティーザー。単一のPaperBenchタスクにおける約80個の自律実験において、AiScientistは、DistilBERT、Ridgeメタ学習器、マルチシードスタッキング、アイソトニックキャリブレーションを用いたCatBoost、および疑似ラベル拡張といった段階的な選択を通じて、検証AUCを約0.91から約0.98へと着実に向上させています。これは、単一の偶然による大きな改善ではありません。 ## Experimental Setup 4.1. 実験装置 ベンチマーク 最先端の学会論文を、完全にゼロから再現します。エージェントが、未知の論文から、シンプルなDocker環境内で動作する再現結果を得られるかどうかを評価します。 Kaggleのような機械学習コンペティションは、継続的な実験による改善を重視します。成功には、単一の提出物だけでなく、多くの反復的な改善のプロセスが必要です。 ベースライン PaperBenchでは、同じ評価プロトコルに基づいて、BasicAgent および IterativeAgent との比較を行っています。MLE-Bench Liteでは、高度な自律型機械学習エンジニアリングシステム（AIDE, LoongNow, ML-Master）との制御された比較結果を報告し、さらに、公式のランキング結果を参考情報として追加しています。 実装詳細 `AiScientist` は、2つのバックボーン LLM である `Gemini-3-Flash` と `GLM-5` を使用してインスタンス化されます。両方のベンチマークにおいて、各実行には 1 つの H20 GPU と、タスクごとに 24 時間の予算が割り当てられます。 ## PaperBench Results 4.2. PaperBenchに関する主な結果 両方のバックボーンにおいて、AiScientistは、最も優れたベースラインと比較して、それぞれ9.92ポイントと11.15ポイントの改善が見られました。また、48時間の努力の後、報告されている人間のベースラインである41%との差を縮めることができました。 IterativeAgentと比較して、AiScientistは、はるかに低いコストでタスクあたり、大幅に高い平均スコアを達成します。Gemini-3-Flash環境下では、$15.67 vs $27.44、GLM-5環境下では、$12.20 vs $54.90です。この改善は、単にインタラクション時間を増やすことによって得られたものではありません。 表1. PaperBenchに関する主要な結果。Δは、各バックボーンにおけるAiScientistが、最良のベースラインと比較して得られた改善値を示します。太字で下線が引かれた値は、各LLMにおける最良および次善の値を示します。 ## MLE-Bench Lite Results 4.3. MLE-Bench Lite に関する主要な結果 MLE-Bench Liteは、PaperBenchを補完するものであり、競争形式の機械学習タスクにおける継続的な実験改善に焦点を当てています。この種のタスクでは、成功は単一回の再現性だけでなく、エージェントがパイプラインを反復的に改善できるかどうかに大きく依存します。 制御された評価において、AiScientistは、どちらの基盤モデルにおいても最も優れた総合パフォーマンスを発揮しました。Gemini-3-FlashとGLM-5の両方で、同じ81.82のAny Medal%を達成し、最も優れた対照モデルと比較して、それぞれ4.55ポイントと18.18ポイントの改善が見られました。これは、表2に記載されているすべてのレポートされたリーダーボードのAny Medalの値よりも高い数値です。 表2. MLE-Bench Liteにおける主要な結果（%）。上部のブロック：コンテキスト参照として使用される公式ランキング。下部のブロック：マッチングされた制御された評価。 ## Mechanism Analysis 4.4. 動作原理の分析 私たちは、AiScientistがもたらす成果を説明するメカニズムを分析します。主に2つの問いに焦点を当てます。それは、持続可能な成果に基づく継続性が主要な要因であるかどうか、そして、より単純で階層構造を持たない組織構造で十分であるかどうか、ということです。 図3. GLM-5におけるメカニズム分析。左：AiScientistは、より単純なエージェントのベースラインや、File-as-Bus機能を持たないバリアントと比較して、PaperBenchにおいて優れた性能を発揮します。右：File-as-Busは、特にMLE-Bench Liteの後半ラウンドにおける改善（平均値以上、シルバー、ゴールド、いずれかのメダル取得）において、重要な役割を果たします。 File-as-Bus アブレーション `File-as-Bus`の機能を削除すると、`PaperBench`のスコアが6.41ポイント低下し、`MLE-Bench Lite Any Medal`のスコアが31.82ポイント低下します。`Valid Submission`と`Bronze`のスコアはほぼ変化しませんが、スコアの低下は主に、中央値より高い、`Silver`、`Gold`といった、より高いパフォーマンスを示す指標に集中しています。耐久性のある成果物は、最初の提出物よりも、後続のラウンドでの改善において重要です。 より単純な Agent 構成との比較 この効果は、単にインタラクションの量を増やすだけのものではありません。`IterativeAgent` はすでに `BasicAgent` よりも多くのインタラクションを提供していますが、それでも `AiScientist`（`File-as-Bus` を使用しない場合）に劣っています。これは、階層的なオーケストレーションが、単に会話の時間を長くすること以上の価値をもたらすことを示しています。 ## Related Work 5. 関連研究 5.1. 科学研究の自動化 最近の研究は、科学研究の自動化を以下の3つの主要な方向で急速に進歩させています。(1) 自動化された科学的発見：エージェントがアイデアを生成し、文献を分析し、特定の実験を実行します。(2) 自動化された実験パイプライン：計画、実行、評価を組み合わせたシステム。(3) 自動化された再現システム：論文に掲載されている既存の研究を再現するシステム。AiScientistは、これらの研究をさらに発展させ、数時間にわたる自律的な作業を通じて、再現と改良を繰り返すような、長期的なエンジニアリングへの応用を目指しています。 5.2. マルチエージェント連携と長期継続性 マルチエージェント連携は、中心的なパラダイムとなっています。CAMEL、MetaGPT、ChatDevは、ロールプレイング、標準化された手順、および構造化されたコミュニケーションが、協調的な問題解決をどのように向上させるかを示しました。最近の分析では、マルチエージェントシステムの利点は、多くの場合、局所的な推論の質ではなく、長期的な軌道における連携の失敗、不一致、および検証の失敗によって制限されることが示唆されています。AiScientistは、この問題を、チャットではなく、作業スペース自体を記録システムとして機能させることで解決します。 ## Conclusion 6. 結論 自律的な長期的な機械学習研究エンジニアリングは困難です。なぜなら、失敗が後になって顕在化し、その原因が解釈、実装、およびインフラストラクチャにわたって複雑に絡み合っている場合があり、また、進捗が繰り返される実装・実験サイクルを通じて一貫性を保つ必要があるからです。AiScientistは、これをシステムの問題として捉え直しました。これは、持続可能なプロジェクトの状態において、専門的な作業を調整することを意味します。そして、階層的なオーケストレーションとFile-as-Busによる連携を組み合わせることで、PaperBenchとMLE-Bench Liteの両方で大幅な改善が得られることを示しました。我々は、この「薄い制御による厚い状態の管理」という原則が、将来の長期的な自律的な研究システムにとって有用な視点を提供すると期待しています。