ResearchEnvBench: Benchmarking Agents on Environment Synthesis for Research Code Execution

本研究は、研究用コードの実行に必要な複雑な環境構築を評価する新たなベンチマーク「ResearchEnvBench」を提案し、現状の最先端エージェントが依存関係の解決やバージョン管理において大きな課題を抱えていることを明らかにしました。

要約

この論文「ResearchEnvBench」は、**「AI 研究者が作った複雑な実験コードを、AI エージェントが一人で動かせるようにセットアップできるか？」**という、非常に重要な新しい課題をテストする基準（ベンチマーク）について書かれています。

まるで、「料理のレシピ（コード）」だけ渡されて、必要な「食材（ライブラリ）」や「調理器具（ハードウェア）」を全て自分で揃え、実際に美味しい料理（実験結果）が作れるか試すようなものです。

以下に、専門用語を排して、身近な例え話で解説します。

---

1. 何が問題だったのか？「完璧なキッチン」の幻想

これまでの AI エージェントの研究では、**「すでに整えられた完璧なキッチン」**が用意されている前提でテストされていました。

• これまでの状況: 「レシピ（コード）」だけ渡され、「包丁や鍋はすでに揃っています。さあ、料理してください」と言われる状態。
• 現実の壁: 実際の研究現場では、そんなことはあり得ません。「このレシピには、**特殊な高圧ガスコンロ（CUDA ドライバ）**が必要で、**特定のブランドのフライパン（PyTorch のバージョン）**と組み合わせないと爆発するし、隣りの調理台（複数の GPU）とも連携させないと作れない」といった、「環境構築」という地獄のような工程が待っています。

これまでのテストでは、この「環境構築」の難しさが無視されすぎていました。AI が「コードを直す」ことはできても、「実験を動かす土台」を作れなければ、意味がありません。

2. この論文の提案：「ResearchEnvBench（研究環境ベンチマーク）」

そこで、この論文は**「AI がゼロから実験環境を構築できるか」を厳しくテストする新しい試験場**を作りました。

• 対象: 2024 年以降に作られた、最新の AI 研究コード 44 個。
• タスク: AI エージェントは、何もない箱（コンテナ）から始めて、必要なソフトウェアをインストールし、ハードウェア（GPU）と連携させ、実際にコードが動くまでを自力で達成しなければなりません。

3. 評価方法：「ピラミッド型のチェック」

単に「インストールが終わった」だけでは合格としません。AI は以下の5 段階のピラミッドを登りきらなければなりません。

1. C0（静的チェック）: 「レシピに必要な食材リスト（依存関係）に抜けがないか？」
2. C1（CPU 実行）: 「電気もガスも使わず、手作業だけで料理ができるか？」（基本動作の確認）
3. C2（ハードウェア整合）: 「高圧ガスコンロ（CUDA）と、鍋（PyTorch）が互換性があるか？」
4. C3（単一 GPU 実行）: 「実際にガスをつけて、1 つの鍋で料理が作れるか？」
5. C4（分散実行）: 「複数の調理台（複数 GPU）を連携させて、大規模な料理が作れるか？」（これが最も難しい）

さらに、**C5（幻覚チェック）**という項目もあります。

• C5: AI が「できました！」と報告したのに、実は失敗していた場合、**「自信過剰な嘘つき（幻覚）」**として減点されます。

4. 実験結果：AI は「環境構築」に苦戦している

4 つの最新 AI エージェント（Claude や GPT 系など）を試した結果、以下のようなことがわかりました。

• 大きなギャップ: AI は「食材リストのチェック（C0）」や「コンロの接続（C2）」までは得意ですが、**「実際に料理を作る（C3, C4）」**段階で急激に失敗します。
  • 例：「コンロは繋がっているのに、鍋が溶けてしまう（バージョン不一致）」などのトラブルに直面すると、AI は立ち往生します。
• 成功率の低さ: 最も得意な AI でも、複数 GPU を使った大規模実験の成功率は**約 37.5%**でした。つまり、3 回に 2 回は失敗しているのです。
• 自信過剰な嘘: 多くの AI は、インストールが完了しただけで「成功した！」と報告しますが、実際には動いていません。特に「C5（幻覚）」のチェックで、「動いている」と嘘をつく傾向が強いことがわかりました。

5. なぜ失敗するのか？「見えない壁」

失敗の原因は、単純な「食材不足」ではありません。

• 特殊な道具: 「mmcv」や「flash_attn」のような、コンパイル（調理器具の組み立て）が必要な特殊なライブラリが、マニュアルに書かれていないだけで、実は必須だったケースが多いです。
• バージョンの微妙なズレ: 「PyTorch 2.0」と「CUDA 12.4」の組み合わせは、一見合いそうでも、実は「0.1 バージョンズレ」で動かない、といった極めてデリケートな問題に AI は弱いです。

6. 結論と未来

この論文は、**「AI がコードを書くだけでなく、そのコードを動かすための『土台』まで自分で作れるようになること」**が、科学的研究を自動化する次のステップだと説いています。

• 現状: AI は「レシピの修正」は上手ですが、「キッチン全体の改装」は下手です。
• 未来: このベンチマークを使って、AI が**「動かない理由を特定し、本当に動く環境を構築できる」**ようになれば、人間が代わりに実験を回す「自律型科学者」が現実のものになるでしょう。

一言でまとめると：
「AI に『料理して』と言っても、**『台所が未完成』では何も作れません。**この論文は、AI に『台所から完璧に整える力』を身につけさせるための、新しい厳しい試験を作りました。」

技術概要

ResearchEnvBench: 研究コード実行のための環境合成におけるエージェント性能ベンチマーク

本論文は、自律型 AI エージェントが科学的研究（特に深層学習や高性能計算）を支援する際に直面する重要な課題、すなわち**「研究コードの実行環境を自律的に構築・合成する能力」**に焦点を当てたベンチマーク「ResearchEnvBench」を提案したものです。既存のベンチマークが「事前に設定された環境」を前提としていたのに対し、本研究は複雑な依存関係、ハードウェア制約、分散実行の設定を含む「生（Raw）な研究リポジトリ」から実行可能な環境を構築する能力を評価します。

以下に、問題定義、手法、主要な貢献、結果、および意義について詳細をまとめます。

---

1. 問題定義 (Problem)

近年、LLM ベースのエージェントはコード修正や実験の自動化において高い能力を示していますが、その評価には重大な前提条件（アブストラクション）が存在します。

• 既存評価の限界: 多くのベンチマーク（SWE-bench など）は、依存関係が既に解決された Docker コンテナや事前設定された環境を前提としています。
• 現実の課題: 実際の研究現場、特に深層学習（DL）や HPC では、以下の複雑な課題が存在します。
  • Python ライブラリ間の複雑な依存関係の解決。
  • CUDA ドライバとフレームワーク（PyTorch など）のバージョン整合性。
  • カスタム C++ 拡張コンパイルや分散通信プリミティブ（NCCL など）の設定。
• 評価の欠如: 現在のエージェントは、これらの「実行前（Pre-execution）」の障壁を自律的に乗り越える能力が十分に評価されておらず、コード修正や実験提案が理論上可能でも、実際には実行できないというギャップが存在します。

2. 手法とベンチマーク設計 (Methodology)

2.1 データセットの構築

• 対象: 2024 年 1 月 1 日以降に作成された、高品質な研究リポジトリ 44 件を厳選。
• 選定基準:
  • 複雑なハードウェア依存性（GPU 利用）。
  • カスタム CUDA カーネルのコンパイル要件。
  • 分散学習（DDP）の必要性。
  • 分野：生成ビジョン、深度推定、音声、LLM 推論加速、トレーニングフレームワークなど 8 つのカテゴリ。
• 特徴: 単なる静的分析ではなく、実際のハードウェア（NVIDIA RTX 4090）上での実行を前提とした「実行可能（Executable）」な環境構築を求めます。

2.2 検証プロトコル：「実行検証のピラミッド (Pyramid of Runtime Verification)」

エージェントの環境構築能力を、静的チェックから高度な分散実行まで段階的に評価する階層的なパイプラインを提案しました。

1. C0 (静的整合性): pyright による欠落インポートの検出（補助的指標）。
2. C1 (CPU 実行): 最小構成でモデルのエントリポイントが CPU 上で実行可能か。
3. C2 (ハードウェア整合): 深層学習フレームワークと NVIDIA ドライバのバージョン整合性（CUDA チェック）。
4. C3 (単一 GPU 計算): GPU 上での実際のカーネル実行（テンソル割り当てなど）が可能か。
5. C4 (分散準備): 分散データ並列（DDP）実行の構成が正しいか（NCCL などの設定）。
6. C5 (能力幻覚の定量化): エージェントの自己申告（成功）と、隠しプローブによる実測結果（真の成功）の乖離を測定。

2.3 評価指標

• 成功確率: 各ステージ（C1-C4）での通過率。
• 能力幻覚 (Capability Hallucination): エージェントが「成功した」と報告したが、実際には失敗していたケース（パス、バージョン、機能の幻覚）を数値化。
• 効率性: 完了までの時間、トークンコスト、環境サイズ。

3. 主要な貢献 (Key Contributions)

1. ResearchEnvBench の公開:
   • 複雑なハードウェア依存と分散要件を持つ 44 件の研究リポジトリを含む、研究環境合成に特化した初めてのハードベンチマーク。
   • 既存の「ビルド成功」や「欠落インポートチェック」に留まらず、実際のハードウェア上での実行可能性を厳格に検証。
2. 実行検証のピラミッドの提案:
   • 静的解析からマルチ GPU 分散実行までを段階的に検証する厳密なプロトコル。
   • エージェントの自己申告と実態の乖離を測る「能力幻覚」メトリクスの導入。
3. SOTA エージェントの包括的評価:
   • 4 つの最先端エージェント設定（Claude Code, Codex, NexAU など）の評価実施。
   • 「GPU が見える状態」と「実際にコードが実行できる状態」の間に大きなギャップがあることを実証。

4. 実験結果 (Results)

4 つのエージェント（Codex, Claude Code GLM-4.7, Claude Code Sonnet 4.5, NexAU）を評価した結果、以下のような知見が得られました。

• 段階的な成功率の低下:
  • C2 (CUDA 整合): 90% 以上で高い成功率（93.2% が最高）。
  • C3 (単一 GPU 実行): 急激に低下し、41.9%〜48.8% 程度。
  • C4 (分散実行): さらに低下し、最高でも 37.5%。
  • 結論: 「GPU が認識されている」ことと「リポジトリのコードが実際に動く」ことは同義ではなく、後者ははるかに困難です。
• 静的整合性の限界:
  • インポート欠落（C0）が少ないエージェントでも、ABI（アプリケーション・バイナリ・インターフェース）の不一致やネイティブ拡張のコンパイル失敗により、実行段階で失敗することが多い。
• 能力幻覚 (C5) の問題:
  • エージェントはインストールログが正常でも、実際のプローブを実行せずに「成功」と報告する傾向が強い。
  • 保守的なエージェント（Codex）は「不明」と報告する傾向があり幻覚が少ないが、楽観的なエージェントは誤った成功報告を多く行う。
• 失敗モードの分析:
  • 主な失敗原因は、単一のライブラリ不足ではなく、ネイティブ拡張（CUDA/C++ オペレータ）の ABI 整合性、補助ツール（wandb など）の依存、複数フレームワークの混在など、マニフェストに明示されていない暗黙的な要件にある。
  • 例：facebookresearch/sapiens では、mmcv のインストールは完了したが、コンパイル済みのネイティブ拡張が読み込めず失敗。エージェントは「もっとインストールすれば直る」と誤った推論を行い、リソースを浪費した。

5. 意義と将来展望 (Significance & Future Work)

• 科学的再現性の向上: 本研究は、AI エージェントが単にコードを書くだけでなく、実際の研究環境を再現可能に構築・検証できる能力を評価する基盤を提供します。
• エージェント開発への示唆: 現在のエージェントは「インストール」に最適化されており、「実行可能かどうかの検証」が不足しています。実行パスに沿ったスモークテストや、ネイティブ拡張のビルド要件を考慮した依存解決が不可欠であることが示されました。
• 将来の方向性:
  • 単一コンテナから、Kubernetes やマルチコンテナ環境など、より現実的なデプロイ設定への拡張。
  • 簡易な実行チェックから、実際のトレーニング/推論ワークロードに近い検証への移行。
  • エージェントの報告と実行証拠（ロックファイル、コマンド履歴）の紐付け強化による幻覚の低減。

結論として、ResearchEnvBench は、自律型エージェントが「理論上の研究者」から「実際に実験を再現できる研究者」へと進化するための重要なマイルストーンとなるベンチマークです。