このサーベイは、ソフトウェアイシュー解決 ― 開発者の自然言語による記述をもとに、実際のコード リポジトリにおけるイシューを理解し、特定し、解決すること ― のための LLM ベースのエージェント型 システムをレビューする。このタスクを独自の観点から扱う理由として述べられているのは、既存のサーベイが イシュー解決の研究を自動プログラム修復のような既存の領域に分けてしまっているのに対し、イシュー解決は 効率の最適化や機能追加を含むより多様な保守活動を対象とし、しかもバグ修正のイシューであっても、バグを 引き起こせるテストの存在を前提としない、という点である。著者らはまた、既存のサーベイが、プロンプト エンジニアリングに基づくスキャフォールドの設計から専用モデルの訓練へという最近のパラダイムシフトを 見落としていると論じている。
コーパスは、公開リーダーボードに提出された論文から検索文字列の種を作り、ソフトウェアエンジニアリングの 用語と AI の用語を組み合わせた 4 つのクエリの組み合わせで IEEE Xplore、ACM Digital Library、arXiv、 DBLP を検索して構築された。これにより 5,176 件の生のヒットが得られ、重複排除と発表先によるフィルタ リングで 1,238 件に、2 人の著者が独立に適用し保守的な和集合ルールでまとめた包含・除外基準で 278 件に、 種類に応じた品質評価で 235 件に絞り込まれた。後方・前方のスノーボーリングでさらに 7 件が加わり、 最終的に 2023 年 10 月から 2026 年 5 月にわたる 242 本の論文のセットとなった。分類体系はオープン コーディングによって構築され、それぞれ関連論文の 70% から導出したうえで残りを独立にラベル付けし、 ベンチマーク、手法、実証研究の分類体系について評定者間一致度はそれぞれ 0.87、0.90、0.91 と報告 されている。
サーベイの整理の軸となるのは、タスクの 5 フェーズモデル ― リポジトリの前処理、ローカライゼーション、 修復、パッチの検証、パッチの選択 ― である。サーベイはこれらを固定の実行順序ではなく論理的な機能として 説明しており、システムはこれらを順次実行することも、動的に交互に実行することもできる。そのうえで、 各手法は自らが対処するフェーズに位置づけられる。
要点
- サーベイは、エージェント型システムを制御フローの設計方法によって分ける。パイプライン では、人間の 設計者が制御フローを段階的なステップやステートマシンのようなワークフローとしてあらかじめ定義し、 モデルは各段階で割り当てられたサブタスクを実行する。エージェント では、モデルが実行中に環境から のフィードバックに基づいて次のアクションを決定するため、制御フローは動的に立ち現れる。パイプラインは 決定性と制御可能性を重視し、エージェントはより大きな自律性と柔軟性を提供する。
- コストについては、条件をそろえた設定 ― 同じベンチマーク、同じバックボーン ― の下では、パイプライン ベースの手法が同等の有効性をより低く予測しやすいコストで実現すると報告している。パイプラインは フェーズごとのモデル呼び出し回数を制限するのに対し、エージェントの軌跡は複数回のツールとのやり取りを 通じてコンテキストを蓄積するためである。ただし、報告されている最高の解決率は、最も強力で最新の バックボーンも採用しているエージェントベースのスキャフォールドによるものであり、それらの数値では スキャフォールドの種類とバックボーンの能力が交絡していると注意を促している。
- 訓練主導のパラダイムシフトを 2 つの数字で記録している。訓練に関する研究の数は 2025 年 2 月以降で 11.4 倍に増えたのに対し、スキャフォールド設計の研究は 3.1 倍であった。また、2025 年 2 月より前に リリースされた代表的な 4 つのモデルはいずれも強化学習を用いていないが、それ以降 2026 年 5 月までに リリースされた 39 モデルのうち 24 が強化学習を用いている。
- 強化学習のアプローチを報酬の種類によって区別している。結果報酬モデル は、ロールアウトのパッチを fail-to-pass テストと pass-to-pass テストに対して実行し、その二値の結果を軌跡全体の報酬として用いる。 結果が自動的に検証可能であるためスケールするが、信頼性は根底にあるテストオラクルの信頼性を超えない。 過程報酬モデル は中間の状態やアクションに報酬を与え、より細かな信用割り当てを可能にするが、 中間段階の正しさには実行によるオラクルがなく、それ自体をルールや学習された批評器で近似しなければ ならないため、その採用は大きく遅れているとサーベイは指摘する。
- ベンチマークの妥当性は第一級の関心事として扱われる。サーベイは、フィルタリングされていない プルリクエストから構築された生のベンチマーク ― 実際の開発により近いが、イシューの記述が自らの解答を 漏らしていたり、過度に広いテストスイートが誤ったパッチを合格させたりする可能性がある ― と、人手で フィルタリングされたベンチマーク ― この問題を緩和するが、より難しく曖昧なインスタンスを捨ててしまう ― を区別する。頑健性の評価には生のベンチマークを、モデルや手法をまたいだ信頼できる比較には フィルタリングされたベンチマークを推奨し、また安定したプロトコルの下での手法比較には静的な ベンチマークを、汚染が主要な懸念となる最新モデルの評価には動的なベンチマークを推奨している。
- 調査対象の論文における評価はほぼすべて自動的であり、エンドツーエンドの評価は完全に実行ベースで、 論文の 76.4% が解決率の指標を報告しており、これがこのタスクで最も一般的な単一の尺度となっていると 報告している。ローカライゼーションはもっぱらマッチングベースの指標で評価され、トークン数、コスト、 時間といった統計ベースの指標は補助的な役割にとどまる。サーベイはこれを、現在の実践が効率よりも 有効性を優先していることの表れと読んでいる。
- 実証研究の統合から、報告されている解決率は統制された比較を支えるものの実用的な能力を保証するもの ではないと結論づけている。弱いテスト、汚染、非現実的なタスク設定、信頼できない軌跡のいずれもが、 解決済みとされたインスタンスに実際の能力を過大に示させうるためである。また、性能のばらつきは バックボーンモデル単独よりも、情報へのアクセス、制御の設計、そして繰り返し発生する過程レベルの失敗に よってより大きく左右されるとしている。
- サーベイは、242 本の論文のうちいくつがそれぞれを明示的に取り上げているかによって未解決の課題を順位 づけている。ドメイン特化モデルの訓練（65 本、26.9%）、リポジトリ知識の表現（60 本、24.8%）、 テストによる検証（49 本、20.2%）が上位を占め、評価に関連する 2 つの課題を取り上げているのは 37 本と 25 本である。著者らは、限られた注目と基盤的な重要性とのこのギャップをそれ自体ひとつの知見として 扱っている。評価が信頼できなければ、他の課題における進展を評価することが難しくなるからである。
注記
著者らは妥当性への 2 つの脅威を挙げている。内的には、手動でのスクリーニングと分類には主観的な判断が 伴うため、2 人の著者による基準の独立した適用、独立した各段階での Cohen のカッパの報告、3 人目の著者に よる裁定、そして各フィルタリング段階の論文リストの公開によってそれを緩和している。外的には、収集した 論文の 50.8% が査読を経ていない arXiv のプレプリントであることを指摘し、査読済みのサブセットのみから 分類体系を再構築しても最上位の分類体系は変わらないと報告している。また、この分野の動きの速さを踏まえ、 自らの結論を収集締め切り時点のスナップショットとして扱っている。
サーベイが提案する方向性の中には、エージェント型システムのためのソフトウェアエンジニアリング が ある。これは、テスト、デバッグ、バージョン管理、継続的インテグレーションをエージェントのライフサイクル に拡張し、古典的なデバッグ手法をエージェントの軌跡に移植することである。具体的には、デルタデバッグの 精神で単一のステップに介入して残りを再実行する反事実的リプレイ、スペクトラムベースの故障箇所特定に 倣って、成功した軌跡と失敗した軌跡の大規模な集合に対する統計によって疑わしいアクションパターンを順位 づけること、そして正常な実行からマイニングされ、実行時に監視して異常な実行を早期に中止できる過程の 不変条件が挙げられている。