🤖 AI

AgentForge: Execution-Grounded Multi-Agent LLM Framework for Autonomous Software Engineering

LLM によるコード生成の信頼性を高めるため、すべての変更をサンドボックス環境での実行で検証することを原則としたマルチエージェントフレームワーク「AgentForge」を提案し、SWE-Bench Lite で単一エージェント基線より大幅に高い 40.0% の解決率を達成したことを報告する論文です。

原著者： Rajesh Kumar, Waqar Ali, Junaid Ahmed, Najma Imtiaz Ali, Shaban Usman

公開日 2026-04-16

📖 1 分で読めます☕ さくっと読める

CC BY 4.0

原著者： Rajesh Kumar, Waqar Ali, Junaid Ahmed, Najma Imtiaz Ali, Shaban Usman

原論文は CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) でライセンスされています。 ✨ これは以下の論文のAI生成解説です。著者が執筆または承認したものではありません。技術的な正確性については原論文を参照してください。免責事項の全文を読む

この論文は、**「AgentForge（エージェント・フォージ）」**という新しいシステムについて書かれています。

一言で言うと、**「AI にコードを書かせる際、ただ『できそう』という直感だけで終わらせず、必ず『実際に動かしてテスト』させるルールを作った」**という画期的な仕組みです。

これを、日常の生活に例えてわかりやすく解説しますね。

🏗️ 従来の AI との違い：「料理のレシピ」vs「実際に食べてみる」

1. 従来の AI（独りよがりの料理人）

これまでの AI は、とても優秀な料理人でしたが、**「レシピ（コード）を書いただけで満足」**してしまう傾向がありました。

「この材料で美味しい料理ができるはず！」と自信満々にレシピを書きます。
しかし、実際に火を通したり、味見（テスト）をしないまま「完成！」と宣言してしまいます。
結果、お客様に渡すと「味が変だ」や「食べられない」という失敗が起きがちでした。

2. AgentForge の仕組み：「完璧な料理チーム」

AgentForge は、1 人の料理人ではなく、5 人の専門家からなるチームで構成されています。そして、最も重要なルールは**「どんな料理も、実際に食べて（実行して）美味しいか確認するまで、完成させない」**という点です。

このチームのメンバーは以下の通りです：

プランナー（司令塔）
- 「何をどう作るか」の全体計画を立てます。「まず野菜を切り、次に肉を焼く」という手順書を作ります。
コーダー（料理人）
- 計画に従って、実際に料理（コード）を作ります。
テスター（味見係）
- 作った料理を、実際に口に入れて（実行して）チェックします。「塩味が足りない」「焦げている」といった不具合を見つけます。
デバッガー（リカバリー係）
- テスターから「まずい！」という報告が来たら、すぐに味を調整して修正します。これを「味が良くなるまで」繰り返します。
クリティク（審査員）
- 最終的に、この料理は本当に完璧か？と厳しく審査し、OK が出たら「完成」とします。

🛡️ 最大の武器：「安全な実験室（サンドボックス）」

このチームのすごいところは、**「絶対に失敗しても大丈夫な安全な実験室」**で作業するところです。

従来のシステムは、失敗したコードが本物のサーバーを壊すリスクがありました。
AgentForge は、**「隔離された箱（Docker サンドボックス）」**の中でだけ料理を作ります。
もし料理が爆発しても（コードがバグっても）、箱の中だけで終わるので、外の世界（ユーザーのパソコン）には何の影響もありません。
この「安全な箱」で実際に動かしてテストするからこそ、**「本当に動くコード」**しか世に出さないことができます。

📊 結果：どれくらいすごいのか？

このシステムを実験（SWE-bench という有名なテスト）で試したところ、驚異的な結果が出ました。

従来の AI 単体： 100 問中 14 問しか正解できなかった。
AgentForge： 100 問中40 問正解できた！

これは、**「1 人の天才に任せるより、5 人の専門家チームで、実際に試行錯誤しながら作る方が、遥かに上手い」**ことを証明しています。

💡 なぜこれが重要なの？

嘘をつかない： AI は「できているふり」をすることがありますが、実際に動かしてテストするルールがあるため、嘘はつきにくくなります。
失敗を恐れない： 安全な箱の中で何度も失敗して修正できるため、より複雑で難しい問題にも挑戦できます。
コストパフォーマンス： 最初は手間がかかっても、最終的に「失敗してやり直す」コストを考えると、結果的に安上がりで高品質なものが作れます。

まとめ

AgentForge は、**「AI にコードを書かせる」のを「AI に『作って、試して、直す』という作業をさせる」**ことに成功したシステムです。

まるで、「独りよがりの天才」を「厳格なチームワークと安全な実験室を持つプロ集団」に変えたようなもので、これからのソフトウェア開発のあり方を大きく変える可能性を秘めています。

AgentForge: 自律型ソフトウェアエンジニアリングのための実行基盤型マルチエージェント LLM フレームワーク

技術的サマリー（日本語）

本論文は、大規模言語モデル（LLM）を用いたコード生成の信頼性向上を目的とした新しいフレームワーク**「AgentForge」を提案しています。既存の手法がコード生成を単一の予測タスクとして扱い、実行検証を省略またはシミュレーションに依存しているのに対し、AgentForge は「すべてのコード変更がサンドボックス環境での実行を通過することを必須とする」**という原則を初めて導入しました。

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

1. 背景と問題定義

現状の課題: 現在の LLM ベースのコード生成システムは、単一のステップで自然言語からコードを生成するアプローチが主流です。しかし、実世界のソフトウェアエンジニアリング（既存コードベースの理解、マルチファイルの依存関係、回帰テストの回避など）には不十分です。
検証の欠如: 既存のマルチエージェントシステムは、役割分担（プランナー、コーダーなど）を導入していますが、生成されたコードの正しさを検証する際、実際のプログラム実行を強制せず、シミュレーションされた実行結果やモデルの内部確率（next-token likelihood）に依存しています。
根本的な限界: バグ修正には「計画→実装→実行→テスト→修正」というフィードバックループが不可欠です。実際の実行信号（Grounded Feedback）なしにモデルは正確性を検証できず、シミュレーションされた実行は体系的な誤差を生み出し、パイプライン全体に伝播します。

2. 手法：AgentForge のアーキテクチャ

AgentForge は、ソフトウェアエンジニアリングを**「実行基盤型の反復的改善問題」**として定式化し、5 つの専門化されたエージェントと強制されたサンドボックス実行を統合したフレームワークです。

A. 5 つの専門エージェント

システムは以下の 5 つの役割を持つエージェントで構成され、共有メモリとオーケストレーターを介して協調します。

Planner (計画): 構造化された実行計画（JSON 形式）を生成し、どのエージェントがどのファイルを変更するかを決定します。
Coder (コーディング): 計画に基づき、最小限の修正（unified diff）または新規実装を生成します。既存ファイルへの修正時は、差分編集によりエラー表面とトークンコストを削減します。
Tester (テスト): 生成されたコードに対して、pytest 形式のテストケース（通常使用、エッジケース、例外パス）を合成します。
Debugger (デバッグ): テスト実行が失敗した場合、エラー出力（stdout/stderr）を受け取り、コードを修正します。このループは最大 3 回（ $N_{retry}=3$ ）繰り返されます。
Critic (批評): 最終結果をレビューし、PASS/FAIL の判定を下します。PASS だった場合のみ、タスクと修正コードがエピソードメモリに保存されます。

B. 実行基盤と環境

強制サンドボックス実行: 生成されたすべてのパッチは、リソース制約（512MB メモリ、0.5 CPU、ネットワーク遮断）のある Docker コンテナ内で実行されます。
真のフィードバック: シミュレーションではなく、実際のインタプリタとテストランナーによる実行結果に基づいて報酬（テスト通過/失敗）が決定されます。
二重検索機構 (Dual Retrieval):
- エピソードメモリ: 過去に解決されたタスクのベクトルデータベース（ChromaDB）から類似タスクを参照。
- ライブリポジトリインデックス: 現在のコードベースのファイルと関数の意味的検索を行い、既存のインターフェースを正確に把握させます。

C. 数学的定式化

ソフトウェアエンジニアリングをマルコフ決定過程（MDP）としてモデル化しています。

状態 ( $S_t$ ): リポジトリ状態、エピソードメモリ、実行履歴。
行動 ( $A_t$ ): コードパッチ（unified diff）。
遷移関数: Docker サンドボックス内でのパッチ適用と実行結果の取得。
報酬: 全テスト（FAIL_TO_PASS の通過と PASS_TO_PASS の回帰防止）が成功した場合のみ 1、それ以外は 0。

3. 主要な貢献

実行基盤の定式化: LLM ベースのソフトウェアエンジニアリングを、モデル内部の尤度ではなく「外部プログラム実行」によって正しさが定義される反復的改善問題として定式化しました。
分解による誤差低減: 生成、テスト、デバッグを分離したマルチエージェント構造が、単一モデルによる自己修復（Self-repair）よりも誤差蓄積を抑制し、成功率を向上させることを理論的・実験的に示しました。
AgentForge フレームワークの構築: 5 つのエージェント、二重検索、強制 Docker 実行を統合したオープンソースフレームワークを実装しました。
実行フィードバックの優位性: 実行フィードバックは、モデルの尤度信号よりも機能の正しさを評価する強力な教師信号であることを実証しました。

4. 実験結果

ベンチマーク: SWE-Bench Lite（300 の実 GitHub 課題、Django, Flask, scikit-learn 等を含む Python リポジトリ）。

解決率 (Resolution Rate):
- AgentForge: 40.0%
- 単一エージェント (GPT-4o): 14.0%
- ReAct (GPT-4o): 12.0%
- 既存の SWE-agent: 18.1%
- 結果: 単一エージェントベースラインを26 ポイント以上上回る性能を達成しました。
アブレーション研究（構成要素の重要性）:
- 全パイプライン（42.0%）から各エージェントを除去した実験では、すべてのエージェントが性能向上に寄与していることが確認されました。
- 特にTester と Debugger のループが最大の性能向上要因であり、Planner を除去すると単一エージェントレベル（19.0%）まで性能が低下しました。
- 実行フィードバック（デバッグループ）と役割分解の両方が独立して性能を駆動していることが確認されました。
コスト分析:
- 単一エージェントに比べトークン使用量とコストは約 2.7 倍ですが、解決率の大幅な向上により、タスクあたりのコスト効率（解決率/コスト）は優れています。
エラー分析:
- 主な失敗要因は「誤った局所化（40.0%）」（正しいファイルや行の特定ミス）と「非効率的なパッチ生成（26.7%）」でした。これはモデルのコード合成能力よりも、リポジトリ全体の依存関係理解がボトルネックであることを示唆しています。

5. 意義と結論

パラダイムシフト: 本論文は、LLM によるソフトウェアエンジニアリングにおいて、「モデルの規模」よりも「検証された実行フィードバック」と「構造化されたパイプライン設計」の方が重要であることを示しました。
実用性: 強制サンドボックス実行により、生成されたコードの安全性と再現性が保証され、実世界での適用リスクを低減します。
将来展望: 今後の課題としては、マルチファイル対応の原子性パッチ、より詳細な検索機構、およびより小さなモデルの役割特化への展開が挙げられています。

AgentForge は、自律型ソフトウェアエンジニアリングにおける新しい基準（Baseline）を提供し、実行基盤型のアプローチが複雑なバグ修正タスクにおいて単一モデルやシミュレーションベースの手法を凌駕することを証明しました。