技術的概要：RepoZero

問題提起

大規模言語モデル（LLM）はコード生成において顕著な進展を示してきたが、ゼロから完全なソフトウェアリポジトリを構築する能力については依然として十分に理解されていない。リポジトリレベルのコーディングに関する既存のベンチマークは、以下の決定的な限界に悩まされている：

1. 評価バイアス：多くのベンチマークは、人間によるループ内評価や「LLM をジャッジとして用いる」フレームワークに依存しており、主観性と信頼性の欠如をもたらしている。
2. データ漏洩：大規模な GitHub コーパスで事前学習されたモデルは、真の推論能力を示すのではなく、既存のリポジトリを記憶していることが多い。これを緩和するために「クリーン」または稀なリポジトリを使用することは、本質的にデータセットの規模を制限し、急速な汚染に対して脆弱である。
3. 検証の欠如：「ゼロから」の生成に関する現在のベンチマークは、特に既存の単体テストが乏しい新規生成プロジェクトにおいて、検証可能で実行ベースの正解（グラウンドトゥルース）を欠いていることが多い。

手法：RepoZero ベンチマーク

これらの課題に対処するため、著者らはゼロからのリポジトリレベル生成を完全に自動化された実行ベースで検証するために設計された、初のベンチマークであるRepoZeroを導入する。

中核概念：リポジトリの再現

RepoZero は、生成タスクをリポジトリの再現として再定義する。自然言語の説明からのみコードを生成するのではなく、エージェントには以下のものが提供される：

1. API 仕様：ソースリポジトリの API の機能仕様。
2. ホワイトボックステストケース：プロンプト内で提供される 4 つの例示的なテストケース（入力と正解出力）。
3. 制約：言語間埋め込みや直接 API 委任などの「ショートカット」解決策を防ぐための厳格なルール。

エージェントは、異なるプログラミング言語（例：Python から JavaScript、または C/C++ から Rust）でリポジトリ全体を再実装しなければならない。生成されたリポジトリは、隠されたテストスイートに対して実行され、元のソースリポジトリの出力とバイト単位で比較されることで評価される。

ベンチマーク構築

• データセット：2 つのサブセットが作成された。RepoZero-Py2JS（400 サンプル、Python から JavaScript）とRepoZero-C2Rust（200 サンプル、C/C++ から Rust）。
• ソース選択：リポジトリは、決定性、オープンソースとしての整合性、およびアーキテクチャ的複雑さ（複数ファイルの実装を必要とするもの）に基づいて手動で選択された。
• テスト生成：LLM がソース API を呼び出すテストファイルとケースを生成する。これらは、時間依存やメモリアドレス出力を除去して決定性を確保し、実行可能であることを保証するために厳格にフィルタリングされる。
• 評価プロトコル：
  • ブラックボックステスト：エージェントに可視化されるのは 4 つのホワイトボックスケースのみであり、残りのテストスイートは隠されており、過学習を防ぐ。
  • 環境の隔離：評価は、ファイルシステム権限が制限された隔離された Docker コンテナ内で実行される。
  • 言語間制約：エージェントは外部パッケージやブリッジコマンド（例：シェルラッパーから Python を呼び出すこと）の使用が禁止されており、真の言語間合成を強制する。

エージェント型コード - テスト進化（ACE）フレームワーク

本論文は、テスト時スケーリングのためのフレームワークであるACEを提案する。静的評価とは異なり、ACE は反復ループを採用する：

1. コーディングエージェントがターゲットリポジトリを生成する。
2. テストエージェントが新しいテストケースを生成し、ソースリポジトリを実行して正解出力を取得する。
3. ターゲットリポジトリが失敗した場合、エラーメッセージはコーディングエージェントにフィードバックされ、改善が行われる。
   このプロセスは、決定性オラクルとしてソースリポジトリを活用し、リポジトリがすべてのテストケースを合格するまで継続される。

主要な貢献

1. RepoZero ベンチマーク：単一ファイルコーディングと完全なソフトウェアエンジニアリングの間のギャップを埋める、ゼロからのリポジトリ生成のための最初のスケーラブルで検証可能なベンチマーク。これは、言語間制約と実行ベースの検証を独自に組み合わせている。
2. ACE フレームワーク：反復的なテスト生成とエラー駆動型改善を統合した新規のエージェントワークフローであり、複雑なリポジトリ合成に対する効果的なテスト時スケーリングを可能にする。
3. 包括的な評価：複数のエージェントスケラフォールド（OpenHands-bash および Mini-SWE-Agent）にわたる、最先端の LLM（Kimi、GLM、DeepSeek、Ernie、Minimax、Claude を含む）の広範なベンチマーク評価。

実験結果

著者らは、Easy、Medium、Hard の難易度レベルで多数のモデルを評価した。主要な知見は以下の通りである：

• 限られた成功率：最も強力なエージェントでさえ、 modest な成功率しか達成していない。最も性能の優れたモデルであるClaude-4.6-Sonnetは、OpenHands-bash スケラフォールドを使用して、Py2JS で約51.5%、C2Rust で**44.6%**の成功率を達成した。
• エージェントの性能：Mini-SWE-Agentは、より洗練されたコンテキストエンジニアリングに起因し、一般的にOpenHands-bashを上回った。
• テスト時スケーリングの影響：ACE フレームワークは性能を大幅に向上させた。OpenHands-bash 上の DeepSeek V3.1 において、コーディングのみの成功率**26.1%から、コーディング - テスト - 改善の 2 回反復により42.9%**に増加した。
• 失敗モード：分析により、ランタイムエラーは稀であったが、エージェントは以下の理由で頻繁に失敗することが明らかになった：
  • 文脈の逸脱：長い推論経路を通じて要件を見失うこと。
  • 実行可能性と正しさの乖離：実行可能なコードの約 40% がソースの決定性出力と一致しなかった。これは、実行されるコードと意味的に正しいコードの間にギャップがあることを浮き彫りにしている。

意義と主張

本論文は、RepoZero をエンドツーエンドのコード生成のための挑戦的かつスケーラブルで信頼性の高いテストベッドとして位置づけている。著者らは以下を主張する：

• 現在の LLM エージェントは、高度なスケラフォールドによって支援されていても、その能力と現実世界のソフトウェア開発要件との間に大きなギャップが存在し、成功率は 55% をめったに超えない。
• テスト生成による自己検証は、コーディングエージェントを進展させるための重要な方向性である。テスト駆動開発のために実行可能環境を活用する能力は、成功の根本的な決定要因として特定されている。
• このベンチマークは、言語間合成と厳格な実行制約を通じてデータ漏洩を効果的に緩和し、従来の「LLM をジャッジとして用いる」アプローチよりも厳格な評価を提供する。

この研究は、反復的な「コード - テスト」ループは有望であるが、将来の進展には、自律的で高品質なテストスイート合成のより堅牢な統合と、エージェントにおける長期コンテキスト保持の改善が必要であると結論づけている。