このサーベイは、大規模言語モデルの上に構築されたコード生成エージェントを概観するものである。その中心的な主張は、こうしたエージェントが従来のコード生成技術と 3 つの点で異なるというものである。1 つ目は自律性で、タスク分解からコーディング、デバッグに至るワークフロー全体を独立して管理する能力である。2 つ目はタスク範囲の拡大で、コードスニペットの生成を超えて、ソフトウェア開発ライフサイクル全体をカバーする。3 つ目はエンジニアリング上の実用性の向上で、研究の重点がアルゴリズム上の革新から、システムの信頼性、プロセス管理、ツール統合といった実践的なエンジニアリング上の課題へと移ったことである。著者らはこれを、開発者の役割がコードを書く人から、タスクを定義し、プロセスを監督し、最終結果をレビューする人へと変わることとして捉えている。

コーパスは、ACM Digital Library、IEEE Xplore、SpringerLink、Google Scholar、DBLP、中国知網(China National Knowledge Infrastructure)を検索して構築された。タイトル、要旨、キーワード、索引語に対して中国語と英語のバイリンガルなキーワード戦略を用い、検索期間は 2022 年から 2025 年 6 月まで、前方・後方スノーボーリングも行った。これにより 447 件の候補が得られ、5 つのスクリーニング規則 ── 重複や同一チームによるほぼ同一のバージョンの除去、プレプリントの影響力と革新性の手作業による精査、書籍・学位論文・ショートペーパーの除外、純粋な技術レポートやレビューではなく技術的革新を扱う論文への絞り込み、最後の関連性チェック ── によって 100 本の中核論文に絞り込まれた。

サーベイは、スキャフォールディング技術と応用という区分を軸に構成されている。シングルエージェントの手法を 3 つの見出し(計画と推論、ツール統合と検索による強化、リフレクションと自己改善)のもとで扱い、マルチエージェントシステムをさらに 3 つの見出し(ワークフロー、コンテキスト管理とメモリ、協調的最適化)のもとで扱う。そのうえで、ライフサイクル全体にわたる応用、評価ベンチマークと指標、実用ツール、未解決の課題を概観している。

主なポイント

  • このサーベイは、LLM と LLM ベースのエージェントを能力ではなくアーキテクチャによって区別している。LLM の動作は単一の受動的な応答プロセスであり、能動的な計画、状態の維持、外部環境との継続的な相互作用を欠く。一方エージェントは、自律性、対話性、反復性を備えた動的なワークフローを構築し、LLM を現在の環境状態から次の行動を決める推論エンジンとして用いる。
  • マルチエージェントのワークフローについて、繰り返し現れる 4 つの形を挙げている。各エージェントが 1 つの段階を担当して中間成果物を次に渡すパイプライン型の分業、上位のエージェントが分解し下位のエージェントが実装する階層的な計画・実行、複数ラウンドにわたる交渉、リフレクション、自己フィードバックを中心とする自己交渉型の循環的最適化、そして協調の効果と失敗のフィードバックに基づいてシステムが自らの通信経路と責任分担を再編成する自己進化型の構造更新である。
  • コンテキストについては、黒板モデル ── タスク記述、中間結果、修正記録を保持し、すべてのエージェントが読み書きできる明示的な共有メモリ空間 ── が、コード生成タスクに導入された最初のこの種の仕組みだったと報告している。後続のシステムはこれを拡張し、分離された命令レジスタとファイルストレージ、脳を模した短期・長期・進化的なメモリ階層、そして各エージェントのコンテキストウィンドウではなくエージェント数をスケールさせる自己組織化エージェントプールを導入している。
  • ベンチマークを 3 つの世代に分けている。独立したコードの機能的正しさに焦点を当てるメソッド・クラスレベルのベンチマーク、アルゴリズム的推論を試すプログラミングコンテストのベンチマーク、そしてエージェントがコードベース、コマンドラインインターフェース、デバッグツールと相互作用する完全な開発環境を提供し、実際のソフトウェア開発シナリオを模擬するベンチマークである。
  • 機能的正しさにとどまらず、評価はプロセスも測定すべきだと論じている。API 呼び出しのコストとトークン消費、レイテンシ、軌跡の効率(エージェントが何ステップを要するか)、そしてツール使用の正確さといった中間ステップの品質である。また、評価が非機能的な属性へと広がりつつあることにも触れている。セキュリティ、可読性と複雑さ、モジュール間の結合度による保守性、そしてエージェントがカバレッジを維持するために関連テストを更新するかどうかである。
  • 実用ツールを 3 つのカテゴリからなる進化の軌跡の上に位置づけている。プログラマーを支援する密接な人間と機械の協働である Co-pilot、コードベース全体のコンテキストを理解し深い対話的協働を行える Collaborator、そして開発プロセス全体の自動化を目指し、人間はむしろクライアントやマネージャーとして振る舞う Autonomous Team である。GitHub Copilot は 1 つ目、Cursor は 2 つ目、Devin と Claude Code は 3 つ目に置かれている。
  • コンテキストエンジニアリングは単なるプロンプト設計の延長ではなく、適切な情報とツールを適切なタイミングで適切な形式で届けるための動的な方法論だと論じ、コンテキストの欠陥を 4 種類に分類している。コンテキストポイズニング(誤った情報やハルシネーションされた情報が後の推論を汚染する)、コンテキストの注意散漫(冗長な情報が重要なシグナルを埋もれさせる)、コンテキストの混乱(形式の不一致が誤解釈を招く)、コンテキストの衝突(矛盾する情報が意思決定の誤りを招く)である。
  • 課題は 5 つの次元にわたる。エージェントの中核能力の限界(ドメイン固有のタスク、意図の理解、大規模コードベースとプロジェクトレベルの依存関係、マルチモーダル入力、コンテキストエンジニアリング)、堅牢性と更新可能性(協調の連鎖に沿ったエラーの連鎖、エージェント数の増加に伴う調整の複雑さ、知識の更新)、オープンな環境におけるツール統合とデプロイ(柔軟かつ安全なツール利用、高い運用コスト、軽量なエッジデプロイ)、信頼性・セキュリティ・倫理上のリスク(信頼性とデバッグ可能性、悪意あるコードの生成、著作権と所有権)、そして評価体系の完全性である。

補足

このサーベイは、ソフトウェアエンジニアリングのための LLM ベースのエージェントに関する既存の英語のサーベイと自らを対比させており、それらを応用の観点から技術を分類するものと特徴づけている。本サーベイが挙げる 2 つの違いは、基盤となる技術的手法は応用シナリオをまたいで共通であるという論拠に基づき、方法論の観点から分類していること、そして分野の進展の速さを踏まえて最新の研究成果の統合に注力していることである。

著者らは、この技術が 2023 年に登場して以来、この分野の論文数が年々増加しており、関連研究がソフトウェアエンジニアリングの会議だけでなく、主要な自然言語処理や人工知能の会議にも頻繁に現れていることを指摘し、これを複数の学問分野から注目を集めている証拠と解釈している。また、従来の査読サイクルに比べて分野の進展が速いため、多くの成果が arXiv プレプリントとして公開されており、そのうちいくつかは高い被引用数を得ていることも述べている。