ソフトウェアイシュー解決とは、開発者が自然言語で記述した内容に基づいて、実世界のコードリポジトリにおけるイシューを理解し、その箇所を特定し、解決するタスクである。自動化されたエンドツーエンドの形態では、イシューの記述とコードリポジトリを入力として受け取り、そのイシューを解決するリポジトリレベルのパッチを出力する。バグ修正、機能追加、効率の最適化を含む多様な保守作業を対象とし、ソフトウェア保守の一部をなす。大規模言語モデルによるエージェント型ソフトウェアイシュー解決：サーベイ は、ソフトウェア保守がソフトウェアのライフサイクルコストの約 3 分の 2 を占めると報告している。
用法
この用語は、タスクの境界を画定するために使われる。同サーベイは、イシュー解決を自動プログラム修正の一部として扱うべきではないと主張し、その根拠を二つ挙げている。一つは、イシュー解決は修正よりも多様な保守作業を包含すること、もう一つは、バグ修正のイシューであっても、そのバグを引き起こせるテストの存在を前提としないことである。二つ目の点はシステムの作り方に影響を及ぼす。報告された挙動を再現するテストを生成することが、所与の前提ではなく作業の一部になるからである。
同サーベイは、自動化されたタスクを五つの論理的なフェーズに抽象化している。これらは固定された実行順序ではなく機能を表すものだと強調されており、システムはそれらを逐次実行することも、推論時に動的に織り交ぜることもできる。
- リポジトリの前処理（Repo preprocessing） — リポジトリについて、アクセスしやすく理解しやすい知識表現を構築する。たとえば、ファイル、クラス、関数からなるツリーや、それに加えて呼び出し、継承、インポート、参照を符号化したグラフである。
- 局所化（Localization） — 報告されたイシューの原因である可能性が最も高いコード片を特定し、後続のフェーズのための探索空間を絞り込む。
- 修正（Repair） — 特定されたコードに対する候補パッチを生成する。正しい修正を生み出す可能性を最大化するために、通常は複数を生成する。
- パッチ検証（Patch validation） — イシューのシナリオを模擬する再現テストを生成するか、候補パッチが既存の挙動を壊していないかを確認するリグレッションテストを選択し、失敗したパッチを除外する。
- パッチ選択（Patch selection） — 正規化したパッチに対する自己一貫性投票によって、あるいはモデルに各候補をイシューに照らして評価させることによって、提出する最も有望な候補を選ぶ。
同サーベイは、これらのフェーズが十分条件ではなく診断のためのものであることを明言している。専用の局所化手法は、下流のパッチ生成に入力することでエンドツーエンドの解決率を高めることが示されており、生成された再現テストは候補の絞り込みと再順位付けに広く使われている。しかし、正しい局所化は正しいパッチを保証せず、弱い再現テストは、もっともらしいが挙動としては誤ったパッチを受け入れてしまう可能性がある。
ソフトウェアエンジニアリングにおける LLM ベースのイシュー解決の進展と最前線：包括的サーベイ は、このタスクにフェーズ分解ではなく形式的な定式化を与えており、両者は矛盾しない。インスタンスは I = (D, C, T)、すなわちイシューの記述、コードベース、対応するテストとして書かれ、そのうち解決の過程で観測可能なのは D と C だけであり、これに加えて探索可能な環境 E がある。手法はパッチ P = M(D, C, E) を生成することが期待され、そのパッチが適用されたうえで T を実行して評価される。同サーベイが用いる集計指標は Resolved Rate であり、データセット全体にわたるインスタンスごとの二値の結果の平均である。
同サーベイは、手法に関する文献を学習不要のものと学習ベースのものの二つに分けて整理している。学習不要の手法は、フレームワーク（シングルエージェント、マルチエージェント、固定ワークフローの設計）、プラグアンドプレイのモジュール（リポジトリとのやり取りのためのツール、経験を蓄積するためのメモリ）、推論時スケーリング（モデルのパラメータを変えずに、探索や並列化によって成功率を高めるもの）によって分類され、学習ベースの手法は教師ありファインチューニングと強化学習に分かれる。同サーベイ自身の統計によれば、強化学習のロールアウトで最も広く使われているスキャフォールドは OpenHands であり、それにワークフローベースの手法、とりわけ Agentless と 2 段階のワークフローが続く。また R2E-Gym や SWE-Gym のような環境ネイティブのフレームワークも、学習データと整合するため頻繁に採用されている。
同サーベイは、このタスクのエビデンス基盤について手厳しい。エージェントの成功率は、解答リーク、曖昧なイシューの記述、誤ったパッチを検出できない弱いテストスイートによって水増しされていることが多く、手作業によるクリーンアップは大規模に行うにはコストが高すぎ一貫性にも欠けるため、この分野では有効な修正を偽陽性から見分けるために、モデルベースの合意を用いた自動検証へと移行しつつあると報告している。同サーベイが挙げる未解決の問題には、効率を考慮した評価がないこと（解決率は測定されるが API コストや推論時間は測定されず、高性能な手法の計算的・経済的な負担が見えにくくなっている）や、成果レベルの報酬（通常はテストの合否という二値）への依存がある。後者について同サーベイは、マルチターンのタスクに必要な多数の行動ステップにわたって、貢献度の割り当てが曖昧になると論じている。
ある手法がリポジトリの前処理と局所化のフェーズに大きく投資すると、それらのフェーズがどのようなものになるかを示すシステムがある。Alibaba LingmaAgent：包括的なリポジトリ探索による自動イシュー解決の改善 は、リポジトリ全体を包括的に理解することが、このタスクを自動化するための最も重要な道筋だと主張する。一つの機能を構成するコードは通常、複数のフォルダやファイルに散らばっており、そのすべてをモデルのコンテキストに入れることはできないからである。そのエージェントは、ファイル、クラス、関数、関数呼び出しからなるナレッジグラフを構築し、修正を試みる前にモンテカルロ木探索でそれを探索する。そして、比較対象としたエージェントのベースラインよりも高い障害箇所特定の精度を報告している。同じ論文は、自動化がどこまで届くかについて産業界のデータポイントも示している。Alibaba Cloud 自身のリポジトリから取られたイシューでは、そのエージェントは単独で 16.9% を解決し、30 件のイシューのサブセットでは、エンジニアがその計画、探索、障害箇所特定を調整できるようにすると解決率は 43.3% に上昇した。著者らはこれを、このシステムが人間の問題解決を置き換えるのではなく拡張するものであることを示すと読んでいる。
関連用語
- AI コーディングエージェント — 現在このタスクに主に用いられている種類のシステム
- リポジトリレベルのコーディング — このタスクが行われるより広い設定
- SWE-Bench — そのベンチマークを導入した論文が、このタスクを開拓したとサーベイが評価しているベンチマーク
- ソフトウェアエンジニアリングにおける LLM ベースのイシュー解決の進展と最前線：包括的サーベイ — このタスクのデータ、手法、分析に関する文献のサーベイ
- Alibaba LingmaAgent：包括的なリポジトリ探索による自動イシュー解決の改善 — リポジトリ全体の探索を中心に構築されたエージェント