TL;DR
EvoCodeAgentは、プロジェクト全体のコード生成を「進化する状態」で支える手法です。アーキテクチャ由来の予測依存関係と、生成コードから抽出した実現依存関係を照合しながら、骨格生成とコード実装を進めます。ツール検証の証拠で状態を更新し、過去の修復試行から再利用可能な経験を抽出して次の生成に活かします。DevBenchとCodeProjectEvalのGPT-5設定で単体テスト通過率60.48%・27.73%、最強ベースライン比最大53.5%相対改善を報告しています。強みはアーキテクチャとコードのずれを継続的に補正できる点、限界は評価ベンチマークとモデル設定が限られる点です。
既存手法との違い
原論文は、パイプライン型のCodeSやSRLCG、エージェント型のMetaGPT、ChatDev、AgileCoder、ZeroRepo、ProjectGenなどと比較しています。既存手法の課題として、静的アーキテクチャによる実装とのずれ、反復フィードバックにおける修復経験の再利用不足、LLM単独判定の信頼性・透明性の限界を挙げています。EvoCodeAgentは、プロジェクト状態を継続更新し、予測関係と実現関係を照合し、ツール接地の検証証拠と修復経験を生成に使う点が異なります。評価はDevBenchとCodeProjectEvalのGPT-5設定で行われ、単体テスト通過率60.48%と27.73%、最強ベースライン比で最大53.5%の相対改善を報告しています。最強ベースラインの具体名は提示本文では明示されていません。
使える条件
プロジェクト全体のコード生成、すなわち高水準の要求から複数ファイル・モジュールからなるリポジトリを生成する用途を対象としています。入力には製品要求文書、UML図、アーキテクチャ設計文書などを想定しています。生成エージェントと判定エージェント、構造・インタフェース・実行チェック用のツール、テスト実行環境が使えることが前提です。原論文の評価はDevBench（小規模）とCodeProjectEval（大規模、18の実行可能リポジトリ）で確認されています。他モデル、他言語、他ドメイン、実運用規模、計算コストや遅延の条件は提示本文からは確認できません。
限界と未検証の範囲
評価はDevBenchとCodeProjectEval、特にGPT-5設定の報告が中心で、他のLLMや他ベンチマークへの一般化は提示本文からは確認できません。修復経験の抽象化アルゴリズム、経験メモリの増加、計算コスト、遅延の詳細も提示本文からは確認できません。ツール検証が利用できる環境が前提であり、ツールなし条件での性能は不明です。判定はツール接地の証拠を使う設計ですが、LLMベースの判定を併用するため完全な検証保証ではありません。本記事は原論文の提示内容に基づく整理であり、実装や追試を行ったものではありません。
解説
ねえ智也くん、EvoCodeAgentって聞いたことある？プロジェクト全体のコード生成を、アーキテクチャとコードを共進化させながらやるって話らしいんだけど。
あるよ。高水準の要求から複数ファイルのリポジトリを作るタスクで、既存手法の弱点を状態更新で補う枠組みだね。
既存手法の弱点って、どんな感じなの？
原論文では大きく三つ。静的アーキテクチャのままだと実装とのずれが増えること、反復修復の経験を再利用しにくいこと、LLM単独の判定が中間成果物の検証として透明性も信頼性も限られること。
なるほど。設計図が固定で、コード側で新しい依存が出ても設計図が更新されないとズレるんだね。
そう。EvoCodeAgentはプロジェクト状態を進化させ続ける。構造ノード、予測関係、実現関係、成果物スナップショット、検証フィードバックを持つ。
予測関係と実現関係って？
予測関係はアーキテクチャや骨格から見込んだ依存。実現関係は生成コードから抽出したimportやcallやsignatureやinterface。それを照合して状態を更新する。
つまり設計と実装のズレを、生成しながら直していく感じだね。
その通り。アーキテクチャ設計、骨格生成、コード実装の三段階を、生成エージェントと判定エージェントのペアで回す。判定はツール検証の証拠に接地させる。
ツール検証って、構造チェックやインタフェースチェックや実行チェック？
そう。あと過去の修復試行から再利用可能な経験を抽象化して、次の生成に使う。原論文ではexperience-guided repairと呼んでいる。
評価はどうだったの？
原論文の報告では、DevBenchとCodeProjectEvalのGPT-5設定で単体テスト通過率が60.48%と27.73%。最強ベースライン比で最大53.5%の相対改善。
比較対象は？
パイプライン型のCodeSやSRLCG、エージェント型のMetaGPT、ChatDev、AgileCoder、ZeroRepo、ProjectGenなど。ただ最強ベースラインの具体名は提示本文では明示されていない。
使う前提は？
製品要求文書、UML図、アーキテクチャ設計文書を入力に想定。生成エージェントと判定エージェント、構造・インタフェース・実行チェック用のツール、テスト実行環境が使える前提だね。
いいとこは、設計とコードのずれを継続的に補正できることと、修復経験をためて使えることだね。
そう。ただし原論文の評価はDevBenchとCodeProjectEval、特にGPT-5設定が中心。他のLLM、他言語、他ドメイン、実運用規模、計算コストや遅延は提示本文からは確認できない。
ツールなしの条件や、経験メモリが増えたときの詳細も不明なんだ。
うん。あとツール接地の証拠を使う設計でもLLMベースの判定を併用するから、完全な検証保証ではない。ここは原論文の整理であって、実装や追試をした話ではない。
じゃあ私のレポートも、アーキテクチャと本文を共進化させれば強くなるかな？
まずアーキテクチャを作れ。今は共進化の前に崩壊してる。