CodeTeam: An LLM-Powered Multi-Agent Framework for Repository-Level Code Generation
CodeTeamは、計画、意思決定、および実装を調整されたステージに分離することで、自然言語からリポジトリ生成における課題に対処するLLM搭載型マルチエージェントフレームワークであり、ベンチマークテストにおいて設計品質と機能的正確性の両面で最先端の性能を実現しています。
原論文は CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) でライセンスされています。 これは以下の論文のAI生成解説です。著者が執筆または承認したものではありません。技術的な正確性については原論文を参照してください。 免責事項の全文を読む
大きな問題：スケッチから都市全体を築き上げる
想像してみてください。あなたは、非常に賢いけれど少し散漫な建築家（AI）に、たった一文の指示で都市全体を建てるよう頼みました。「靴を買える場所が必要だ」と。
もしあなたがAIに単に「コードを書いて」と頼んだら、AIは美しい靴屋を作るかもしれませんが、道路や発電所、あるいは下水道を作ることを忘れてしまうかもしれません。あるいは、AIが「道路建設担当」のAIと会話していなかったために、ドアを開けるとレンガの壁に突き当たっているような靴屋を作ってしまうかもしれません。
これが NL2Repo (Natural Language to Repository) の課題です。これは単に一つの関数（一つの部屋のようなもの）を書くことではなく、互いに完璧に連携しなければならない多くのファイルを含む、ソフトウェアプロジェクト全体（一つの都市全体）を生成することなのです。現在のAIモデルはしばしば細部に迷い込み、大局的な視点を忘れたり、ファイルAが期待しているものをファイルBが作っていないといった「ファイル間の不整合」を引き起こしたりします。
解決策：CodeTeam（建設チーム）
著者らは、一人の孤独な天才AIに頼るのではなく、役割分担された専門の建設チームとして機能するシステム CodeTeam を提案しています。彼らは作業を、計画（Planning）、意思決定（Decision Making）、構築（Building） という3つの明確なフェーズに分解します。
チームの仕組みは以下の通りです。
1. アーキテクト（夢想家たち）
一人の人間が設計図を描く代わりに、このシステムは4人の異なるアーキテクト・エージェントを雇います。
- 彼らの仕事: 各アーキテクトは、ソフトウェアに対して異なる設計案をスケッチします。ある者は「モジュール型の設計にしよう！」と言い、別の者は「いや、シンプルでフラットな設計にしよう！」と言うかもしれません。
- 秘密兵器: これらのアーキテクトは、過去の成功したプロジェクトのライブラリ（検索拡張生成：RAG）を覗き見ることが許可されています。これにより、他の人々が同様の問題をどのように解決したかを確認できます。これは、車輪の再発明を避けるのに役立ちます。
- ゴール: 多様な「ソフトウェア設計スケッチ（SDS）」を作成することです。これは、すべての部屋、すべての配管、そして誰が何を建てる責任があるかをリストアップした詳細な設計図のようなものです。
2. CTO（最高意思決定者）
4人のアーキテクトが設計図を提示した後、最高技術責任者（CTO） エージェントが登場します。
- 彼らの仕事: CTOはすべてのスケッチをレビューし、最適なものを選び出し、それを**マシンチェック可能な契約（Machine-Checkable Contract）**へと変換します。
- 契約書: これは単なる図面ではなく、コンピュータのための厳格な法的文書です。「ファイルAにはこの特定の関数がなければならない。ファイルBはファイルAに依存しなければならない。開発者1はキッチンを担当し、開発者2は寝室を担当する」といった内容です。
- なぜ重要か: この契約によって、ビルダーたちが迷走して、キッチンがあるべき場所にガレージを作ってしまうような事態を防ぎます。レンガを一つも積む前に、ルールを定めるのです。
3. デベロッパー（建設作業員）
ここで実際のコーディングが始まります。システムは、CTOの契約に基づいて、特定の数のデベロッパー・エージェントを雇います。
- 専門化: 何でもこなそうとする汎用的なAIとは異なり、これらのデベロッパーには特定のファイルが割り当てられます。デベロッパー1は「ログインページ」のみを構築し、デベロッパー2は「データベース」のみを構築します。
- Gitによる調整（現場監督）: 建設を進める際、彼らは変更を追跡するためのツールである Git の軽量版を使用します。デベロッパー1がログインページを変更すると、「パスワードボタンを変更しました」という「コミットメッセージ（メモ）」を残します。デベロッパー2はそのメモを読み、自分のコードをそれに合わせて更新します。
- 依存関係の把握: 壁を塗る前にフレームを組まなければならないことを、システムは理解しています。そのため、正しい順序でファイルが構築されるように作業をスケジュールします。
4. QAエージェント（検査官）
チームが建設を進める間、品質保証（QA） エージェントが建築検査官として機能します。
- 彼らの仕事: 彼らはテストを実行し、建物が自立しているかを確認します。もしドアが開かなかったり、配管から水が漏れたりした場合、QAエージェントは単に「エラー」と言うだけではありません。彼らは「誰が」それを壊したのかを特定し、その特定のデベロッパーに修理チケットを送り返します。
- ループ: デベロッパーは問題を修正し、検査官が再度チェックします。建物が完璧になるまで、このプロセスを繰り返します。
何が分かったのか？（結果）
研究者たちは、CodeTeamを他の手法（単一のAIがすべてを行おうとする方法や、他のマルチエージェント・チームなど）と比較するために、2つの主要な「試験」を用いました。
設計図試験（SketchEval）: 生成されたコードが、現実世界の例と比較して構造的に正しいかどうかをチェックしました。
- 結果: CodeTeamが勝利しました。CodeTeamは、より現実のソフトウェアに近い構造を構築しました。「アーキテクト」と「CTO」のステップがレイアウトを正しくさせ、「QA」のステップが小さな亀裂を修正しました。
- 重要な洞察: 「動的なデベロッパー割り当て（ジョブに合わせて適切な数の作業員を雇うこと）」が、成功の最大の要因でした。人数が少なすぎたり多すぎたりした場合、あるいは間違った人に間違った部屋を割り当てた場合、建設は失敗します。
実地テスト（NL2Repo-Bench）: 彼らは実際に生成されたソフトウェアを実行し、それが機能するかどうかを試しました。
- 結果: CodeTeamが最も高い成功率を記録しました。単に見た目が良いだけでなく、実際に機能していました。
- 重要な洞察: 構造的なエラー（ファイルの欠落や接続の切断など）を早い段階で修正することで、最終製品が「ライブ」テストに合格する可能性が大幅に高まりました。
まとめ
この論文は、ソフトウェアを一から構築することは、単なる「執筆」タスクではなく、**「管理」**タスクであると主張しています。
- 従来の方法: 一人のAIに本を一冊丸ごと書かせる。すると、AIはプロットを忘れたり、キャラクターの設定が矛盾したりすることがよくあります。
- CodeTeamの方法: チームを雇う。一人がプロットを計画し、一人が章を編集し、一人が誤字脱字をチェックするようにします。
計画（アーキテクト/CTO）を実行（デベロッパー）から切り離し、さらにチェック（QA）を加えることで、CodeTeamはよりスマートで、かつ信頼性の高いソフトウェアを生み出します。複雑なタスクにおいては、単独で働く超優秀なAIよりも、調整されたAIエージェントのチームの方がはるかに優れていることを、CodeTeamは証明しています。
自分の分野の論文に埋もれていませんか？
研究キーワードに一致する最新の論文のダイジェストを毎日受け取りましょう——技術要約付き、あなたの言語で。