今回の論文
今回取り上げるのは、Chunqiu Steven Xiaらによる論文「Agentless: Demystifying LLM-based Software Engineering Agents」です。2024年7月にarXivで公開された、LLMによるリポジトリ規模の自動プログラム修正を扱う研究です。URLは https://arxiv.org/abs/2407.01489 、研究分野はAIコーディング、ソフトウェア工学、LLMエージェントです。
選んだ理由は、AIコーディングを成功させるために、必ずしも複雑な自律エージェントは必要ではない、と具体的な実験で問い直しているからです。問題箇所を狭め、複数の修正案を作り、テストで選ぶという構成は、既存の開発フローにも取り入れやすい技術的な発想です。
どんな技術か
Agentlessは、Issue文と既存リポジトリを受け取り、LLMに自由なツール操作や次行動の計画を任せず、特定（localization）、修正（repair）、パッチ検証（validation）という固定手順で修正案を作る仕組みです。
ポイントは、コード全体を一度にLLMへ渡さないことです。まず怪しいファイル、次に関係する関数・クラス、最後に編集すべき行付近へと段階的に候補を絞ります。その限定された文脈から複数のSearch/Replace形式パッチを生成し、既存の回帰テストと生成した再現テストで候補を選びます。エージェントらしい長い探索軌跡より、文脈選択と検証を明示的に設計する技術です。
課題
リポジトリ規模のバグ修正では、コードを書けるだけでは十分ではありません。Issueの説明は曖昧で、修正対象は多数のファイルに散らばり、関連しそうなコードを全て渡すとコンテキストが膨らみます。場所を間違えれば、どれほど自然なパッチでも直りません。
既存のAIコーディングエージェントは、検索、ファイル閲覧、コマンド実行、計画の更新をLLMが繰り返す構成になりがちです。しかし、各ループはトークン・実行時間・失敗経路を増やします。ツール呼び出しを誤る、無関係なファイルを読み続ける、テスト失敗を正しく解釈できない、といった問題が積み重なります。
実際にこの問題は、GitHub Issueから修正PRを作る開発支援、社内コードベースの保守、障害チケットの一次対応で起きます。重要なのは「LLMが何回考えたか」ではなく、正しい編集箇所に十分な根拠を渡し、候補を安全に選べるかです。
用語解説
- リポジトリ規模のソフトウェア修正
- 単独関数の穴埋めではなく、既存プロジェクトのIssueを読み、適切なファイルを探して変更する作業です。本論文では、生成能力よりも場所特定と検証が成否を左右します。
- Localization（問題箇所特定）
- Issueを直すために編集すべきファイル、関数、行付近を絞る処理です。Agentlessはこれを階層化し、LLMへ渡すコード量を減らします。
- Skeleton format
- ファイル本文を丸ごと渡さず、クラス名、関数シグネチャ、モジュール・クラスコメントなどの骨格を示す表現です。構造を保ちながら文脈予算を節約するために使います。
- Search/Replaceパッチ
- 変更前のコード断片と変更後の断片を対にして出力する差分形式です。LLMが曖昧な説明文ではなく、適用可能な編集を返せるようにする本論文の重要な出力制約です。
- 回帰テストと再現テスト
- 回帰テストは既存機能を壊していないかを調べ、再現テストは元のIssueの不具合が直ったかを調べます。両者を分けることで「既存テストを通るだけ」のパッチを採用しにくくします。
技術の仕組み
Agentlessの全体像は、LLMを万能な操作者として扱う代わりに、入力・出力・選抜方法を工程ごとに固定するものです。各工程は前工程の候補を受け取るため、広いコードベースから狭い編集コンテキストへ段階的に情報を圧縮します。
3段階で編集候補を絞る
最初に、リポジトリをディレクトリとファイルの木としてLLMへ示し、Issueに関係しそうなファイルを選ばせます。実装ではLLMによるファイル候補に、埋め込み検索で得た候補を加え、上位3ファイルを後段へ渡します。LLMの意味理解だけに依存せず、検索の再現率を補助的に使う設計です。
次に、候補ファイルをSkeleton formatにして、関係するクラス・関数を選びます。本文を全部読むのではなく、定義、シグネチャ、コメントを先に見るため、少ないトークンで構造を把握できます。最後に、その要素の中で具体的な編集位置を複数サンプルします。
論文のSWE-bench Liteでの分析では、正解パッチのファイルを含む割合はファイル段階で77.7%、さらに関数・クラス、編集位置へ進むと50.8%でした。一方でLLMへ渡す平均コード量は3,305行から813行、246行へ減っています。完全な正解位置だけを追うのではなく、修正に必要な文脈と費用のバランスを取った結果です。
限定された文脈から複数パッチを作る
各編集位置の前後のコードを与え、LLMにSearch/Replace形式のパッチを出させます。位置候補は4セット、各セットでは最大10サンプルを生成し、合計40候補を作る構成です。生成のばらつきを、探索ループではなく並列の候補生成に使っています。
Search/Replaceでは、変更前断片が元ファイルに一致したときだけ置換できます。そのため、構文がもっともらしいだけの自由形式回答より、機械的に適用・失敗判定しやすくなります。位置特定の誤差と生成の確率性を、複数候補で吸収する考え方です。
テストを候補選択器として使う
候補パッチは多数あるため、単純な多数決だけでは選び切れません。Agentlessは、元のコードで通る既存テストを回帰テストとして選び、パッチ適用後にも通る候補を優先します。さらにIssueを再現するテストをLLMに複数生成し、元コードで失敗するものを選んだうえで、パッチ後に成功するかを確認します。
ここでテストは「修正後の採点」だけでなく、生成候補を再順位付けする信号になります。もっとも、LLMが作る再現テスト自体が不完全な場合もあるため、実務ではCI、静的解析、人間のレビューを置き換えるものではなく、候補を絞る層として扱うのが安全です。
実験と結果
論文は、実際のGitHub Issueと修正コミットからなるSWE-bench Liteの300件で評価しました。対象はIssue説明と修正前リポジトリからパッチを作り、隠されたテストで問題が解決したかを測る設定です。比較対象にはSWE-agentなどのエージェント方式、検索ベースのagentlessベースラインを含めています。
修正成功率とコスト
論文本文の主要評価では、Agentlessは300件中82件を解決し、成功率27.33%でした。論文公開時点のオープンソース手法では最高で、1 Issueあたりの平均APIコストは0.34ドルと報告されています。この値は当時のモデル・価格・実装に依存するため、現在のAPI費用の見積もりにはそのまま使えません。しかし、長い自律軌跡を減らしても競争力を得られる、という比較の意味は残ります。
位置特定でも、階層方式はオープンソース比較で関数レベル首位、ファイル・行レベルでも上位でした。特に、修正の成否は正解位置を含む割合と強く相関したため、修正モデルだけを替えるより、文脈を渡す前段を改善する重要性が示されています。
どの工程が寄与したか
アブレーションでは、1サンプルのパッチ生成だけで70件（23.33%）、複数サンプルと多数決で78件（26.00%）、回帰テストによる選択を加えた完全構成で82件（27.33%）でした。複数の候補を作ることと、テストで選ぶことの両方が寄与しています。
一方で、SWE-bench LiteのIssueには説明が不足するもの、解法や正解パッチに近い情報を含むものがあると論文は手作業で分類しています。したがって27.33%を一般的な実案件の解決率と読むべきではありません。評価セットの品質と、自社タスクに近い回帰ケースを用意することが重要です。
何に使える？
Agentlessの価値は、完全自律のコーディングエージェントを導入できない場面でも、修正支援を工程として組み込める点にあります。
Issueからの修正PR下書き
バグチケットを入力し、まず候補ファイルと該当関数を開発者へ提示し、その承認後にパッチ候補を生成するフローに使えます。最初から自動マージを目指さないため、チーム固有の判断を残しつつ、調査と定型修正を短縮できます。
大規模コードベースの障害一次切り分け
ログやスタックトレースをIssue文へ加え、階層的なLocalizationで関係ファイルを絞る用途です。パッチを作らなくても、246行程度まで文脈を小さくできる発想は、担当者へ渡す調査メモやレビュー支援に応用できます。コード検索だけでは見落とす意味的な関係をLLMが補えます。
CIに接続した修正候補のランキング
修正案を複数生成し、既存のユニットテスト、型検査、lint、脆弱性検査の結果で順位付けできます。Agentlessの再現テスト生成をそのまま信頼するのではなく、既存CIを強い判定器として使えば、候補をレビューしやすい順に並べられます。
開発や事業へのヒント
この論文から得られるのは、エージェントを「自由に動くLLM」と捉えるより、失敗しやすい工程を明示的な入出力でつなぐほうが、プロダクト化しやすいというヒントです。
最初にLocalizationを計測する
AI修正機能を作る場合は、最終的な修正成功率だけでなく、「提案した上位3ファイルに正解ファイルが含まれた率」「提示コード行数」「1件あたりのトークン」を記録するとよいです。ここが低ければ、より大きいモデルや長いエージェントループを足しても、誤った文脈でパッチを作り続けます。
候補生成と採用判断を分離する
小規模な開発ツールでも、1案を即採用する代わりに、温度や位置候補を変えた数案を生成し、テスト・lint・差分サイズで並べ替えられます。生成器の自信を信頼するより、外部の検証信号を使うほうが監査しやすく、モデル交換にも強い設計になります。
自社のテスト資産をAI導入の基盤にする
この方式では、良いテストが良い選別器になります。修正を自動化する前に、障害の再現ケース、重要な回帰テスト、実行時間が短い検査セットを整える投資が効果的です。これは論文の結果からの実務的な推論ですが、テストが弱い領域では誤ったパッチを上位にしてしまうためです。
限界
Agentlessは、固定された手順であることが強みである一方、Issueに位置の手掛かりがない複雑な問題には弱くなります。論文でも、位置情報が全くない問題では、より自由に検索ツールを使える商用エージェントが優位な傾向でした。原因究明に実行・観測・仮説更新が何度も必要な障害には、固定3段階だけでは足りない場合があります。
また、SWE-bench LiteはPython中心の公開Issueに基づくベンチマークです。社内の複数サービス、非決定的な障害、秘密情報を含む設定、UI確認が必要な変更へ同じ成功率を期待できません。Issue品質、テスト環境、依存関係の再現性にも大きく依存します。
運用面では、候補パッチの実行に隔離環境が必要です。テスト実行や依存関係セットアップをLLM生成コードと同じ環境で無制限に行わず、権限、ネットワーク、シークレット、実行時間を制限してください。テスト通過は正しさの必要条件であって、レビューやセキュリティ確認を省略できる根拠ではありません。
よくある質問
Q. AgentlessはAIエージェントではないのですか？
A. LLMを用いてコード修正を自動化しますが、次に何をするかをLLMが自由に決め続ける自律エージェントではありません。論文では、特定・修正・検証の手順を固定し、必要なLLM呼び出しを工程ごとに限定しています。
Q. 自分のリポジトリへ導入するなら、どこから始めるべきですか？
A. まず過去のバグ修正を20〜50件集め、Issue、修正前コード、正解テストを用意してください。上位候補ファイルに正解が含まれる率を測り、次にパッチ生成とCI順位付けを加える順序が、問題を切り分けやすいです。
Q. Search/Replace形式にする利点は何ですか？
A. 変更前の断片が元コードに一致するかを確認でき、適用できない回答を早く除外できます。また、行番号だけを頼りにするより、コードが少し動いた場合にも意図を確認しやすく、差分レビューにもつながります。
Q. 複数パッチを生成するとコストが増えませんか？
A. 増えます。論文でも1サンプルから複数サンプルへ増やすと費用は上がります。ただし、無制限に探索する代わりに、位置を絞った短い文脈で候補数の上限を決め、テストで選ぶため、予算と品質のトレードオフを管理しやすい設計です。
Q. テストがないプロジェクトでも使えますか？
A. 位置特定やパッチの下書きには使えますが、候補の信頼できる選別が難しくなります。少なくとも対象Issueを再現する最小テスト、型検査、静的解析、開発者レビューのいずれかを用意し、自動適用は避けるべきです。
今日の学び
この論文は、LLMによるリポジトリ規模のバグ修正で、正しいコード位置を見つけ、生成候補を検証する難しさを扱いました。Agentlessは、階層的なLocalization、複数のSearch/Replaceパッチ、テストによる再順位付けでこの問題を解こうとします。
得られるヒントは、AIコーディングを大きな自律ループとして一括導入せず、文脈選択・候補生成・検証という測定可能な部品に分けることです。自社のテストと修正履歴を整えれば、小規模な開発支援でもこの考え方を活かせます。