論文概要（Abstract）
本記事は arXiv:2407.01203 Agentless の解説記事です。
Agentlessは、複雑なエージェントアーキテクチャ（長いアクショントラジェクトリ、意思決定ループ、多数のツール使用）を排除し、局所化（localization）→修正（repair）の2段階のみでGitHub issueを自動解決するアプローチである。著者らは、SWE-bench LiteベンチマークにおいてGPT-4oを使用して27.33%の解決率を達成し、これは当時の全オープンソースエージェントを上回る結果であったと報告している。さらに、1件あたりのコストは$0.34、処理時間は4.0分と、既存エージェントと比較して大幅に効率的であるとされている。
この記事は Zenn記事: Claude API×LangGraphで自律コーディングエージェントを構築する実装ガイド の深掘りです。
情報源
- arXiv ID: 2407.01203
- URL: https://arxiv.org/abs/2407.01203
- 著者: Chunqiu Steven Xia, Yinlin Deng, Soren Dunn, Lingming Zhang
- 発表年: 2024（最終更新2025年2月）
- 分野: cs.SE, cs.AI, cs.LG
- コード: https://github.com/OpenAutoCoder/Agentless（MITライセンス）
背景と動機（Background & Motivation）
LLMベースのコーディングエージェント（SWE-agent、OpenHands等）は、ツール使用、長い意思決定トラジェクトリ、複雑なアクション空間を特徴としている。しかし著者らは、このような複雑さには以下の問題があると指摘している：
- 不透明性: エージェントの意思決定過程が理解・分析しにくい
- 制御困難: 長いトラジェクトリの中での誤った判断が累積する
- 最適化困難: 多くのコンポーネントの相互作用により、個別の改善が全体に反映されにくい
- 高コスト: 多数のLLM呼び出しと長いコンテキストにより、APIコストと処理時間が増大する
著者らは「より複雑なエージェントが常に必要なのか？」という問いを立て、シンプルな2段階アプローチでも十分な性能が得られることを実証している。
Zenn記事のLangGraphエージェントは5ノード構成（plan→generate→execute→test→fix）のエージェント的設計であるが、Agentlessはこれとは対照的な設計哲学を提示しており、両者の比較はコーディングエージェント設計の選択肢を理解する上で有益である。
主要な貢献（Key Contributions）
- 貢献1: エージェントアーキテクチャを使わない2段階アプローチ（局所化→修正）でGitHub issueを自動解決する手法の提案。SWE-bench Liteで当時のオープンソースエージェントを上回る27.33%を達成
- 貢献2: 階層的バグ局所化（ファイル→関数→行レベル）の手法。LLMの推論能力を段階的に活用することで、精度の高い局所化を実現
- 貢献3: 複数候補パッチ生成と投票選択のアプローチ。10個の候補パッチを生成し、テスト通過率によるランキングで最良パッチを選択
技術的詳細（Technical Details）
ステージ1: 階層的バグ局所化
Agentlessのバグ局所化は3段階の階層的アプローチで行われる：
ステップ1: ファイルレベル局所化
Issue記述とリポジトリの構造情報（ディレクトリツリー、ファイル名一覧）をLLMに入力し、関連するファイルを特定する。
1
2
入力: Issue記述 + リポジトリ構造
出力: 関連ファイルのリスト（例: src/parser.py, src/utils.py）
ステップ2: 関数レベル局所化
特定されたファイルの内容をLLMに入力し、修正が必要な関数を特定する。
1
2
入力: Issue記述 + ファイル内容
出力: 関連関数のリスト（例: parse_input(), validate_schema()）
ステップ3: 行レベル局所化
特定された関数の内容をLLMに入力し、修正が必要な具体的な行を特定する。
1
2
入力: Issue記述 + 関数コード
出力: 修正対象の行番号（例: L42-L45）
この階層的アプローチにより、LLMが一度に処理する情報量を制限し、各ステップで高精度な局所化を実現している。著者らは、全リポジトリを一度に入力する単一ステップ局所化と比較して、階層的アプローチが大幅に精度を向上させることを確認したと報告している。
ステージ2: パッチ生成と検証
局所化された箇所に対し、複数の候補パッチを生成して最良のものを選択する：
パッチ生成
$N = 10$個の候補パッチを生成する。各パッチは、Issue記述、局所化されたコード、および修正指示をLLMに入力して生成される。
\[\{p_1, p_2, \ldots, p_N\} = \text{Generate}(\mathcal{M}, \text{issue}, \text{code}, \text{localization})\]パッチ検証と選択
各パッチに対して以下の検証を行う：
- 構文チェック: パッチの形式が正しいか
- 適用可能性: パッチがコードベースに正しく適用できるか
- 回帰テスト: 既存のテストスイートが通過するか
最終的なパッチ選択は投票メカニズムで行われる：
\[p^* = \arg\max_{p_i} \sum_{t \in \mathcal{T}} \mathbb{1}[\text{pass}(t, p_i)]\]ここで、
- $p^*$: 選択されるパッチ
- $\mathcal{T}$: テストスイート
- $\text{pass}(t, p_i)$: テスト$t$がパッチ$p_i$適用後に通過するか
この設計は、On the Design and Analysis of LLM-Based Algorithms (2407.13168) が理論的に示したアンサンブル定理の実践的な実装例である。個々のパッチの成功率が50%を超える場合、候補数$N$を増やすことで全体の成功率を向上させることができる。
Agentlessとエージェント型の比較
| 特性 | Agentless | エージェント型（LangGraph等） |
|---|---|---|
| アーキテクチャ | 2段階パイプライン | 状態機械グラフ |
| LLM呼び出し回数 | 3-5回（固定） | 5-20回（可変） |
| ツール使用 | なし | あり（bash、検索等） |
| コスト | $0.34/issue | $1-5/issue |
| 処理時間 | 4分/issue | 10-30分/issue |
| 最大性能（2025年2月時点） | ~33%（更新版） | ~68%（Nemotron-CORTEXA） |
| 拡張性 | 限定的 | 高い |
著者らはAgentlessの設計を「必要十分な複雑さ」として提示しているが、最新のエージェント型アプローチ（Nemotron-CORTEXA等）がSWE-bench Verifiedで68.2%を達成していることから、複雑なタスクにはエージェント型のアプローチが依然として優位であると考えられる。
実装のポイント（Implementation）
Agentlessの実装パターン（Python）
Agentlessの核心的な処理フローをPythonで示す：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
import anthropic
from pathlib import Path
client = anthropic.Anthropic()
def agentless_resolve(issue: str, repo_path: str) -> str:
"""Agentless方式でissueを解決する
Args:
issue: GitHub issueの記述
repo_path: リポジトリのパス
Returns:
最良のパッチ（unified diff形式）
"""
# Stage 1: 階層的局所化
repo_structure = get_repo_structure(repo_path)
files = localize_files(issue, repo_structure)
functions = localize_functions(issue, files)
lines = localize_lines(issue, functions)
# Stage 2: 複数パッチ生成
patches = []
for i in range(10): # N=10候補
patch = generate_patch(
issue=issue,
code_context=lines,
temperature=0.7,
)
patches.append(patch)
# Stage 3: テスト通過率で投票選択
best_patch = select_best_patch(patches, repo_path)
return best_patch
def localize_files(issue: str, structure: str) -> list[str]:
"""ファイルレベルの局所化"""
response = client.messages.create(
model="claude-sonnet-4-6",
max_tokens=1024,
messages=[{
"role": "user",
"content": f"以下のissueに関連するファイルを特定してください。\n\n"
f"Issue:\n{issue}\n\n"
f"Repository structure:\n{structure}",
}],
)
return parse_file_list(response.content[0].text)
LangGraphエージェントとの使い分け
Zenn記事のLangGraph + Claude APIアプローチとAgentlessの使い分けガイドライン：
| 条件 | 推奨アプローチ |
|---|---|
| コスト最優先 | Agentless |
| 処理速度最優先 | Agentless |
| 複雑なバグ修正 | LangGraphエージェント |
| 新機能追加 | LangGraphエージェント |
| リファクタリング | LangGraphエージェント |
| 大量のissue一括処理 | Agentless |
| 単一の重要なissue | LangGraphエージェント |
実験結果（Results）
著者らが報告したSWE-bench Liteでの結果（論文Table 1より）：
| 手法 | 解決率 | コスト/issue | 時間/issue |
|---|---|---|---|
| Agentless | 27.33% | $0.34 | 4.0分 |
| AutoCodeRover | 22.7% | 非公開 | 非公開 |
| SWE-agent | 18.0% | $1.50+ | 15分+ |
| ChatUniTest | 6.0% | 非公開 | 非公開 |
コスト効率分析
Agentlessの$0.34/issueというコストは、SWE-agentの$1.50+と比較して約4.4倍の効率である。これはLLM呼び出し回数の少なさ（3-5回 vs 20回+）に起因する。
制約と限界
著者らは以下の制約を明記している：
- 局所化精度への依存: ステージ1の局所化が失敗すると、ステージ2のパッチ生成は有効に機能しない。著者らの分析では、解決失敗の約60%が局所化の誤りに起因
- 複数ファイル修正の困難: 現在の設計では複数ファイルにまたがる修正が困難。エージェント型はこの点で優位
- 投票メカニズムの限界: テスト通過率による投票は、テストスイートがバグを十分にカバーしていない場合に最良のパッチを選択できない
実運用への応用（Practical Applications）
Agentlessの設計は、以下の実務シナリオで有効である：
- CI/CDパイプラインへの組み込み: シンプルな2段階パイプラインはCI/CDに組み込みやすく、GitHub ActionsやGitLab CIとの統合が容易
- コスト予測可能なバッチ処理: 固定回数のLLM呼び出しにより、大量のissue処理時のコストが予測可能
- ベースラインとしての活用: エージェント型アプローチの評価において、Agentlessをベースラインとして使用し、追加の複雑さが性能向上に見合うかを判断する基準として活用
関連研究（Related Work）
- SWE-RL (Wei et al., 2025): RL訓練によるコーディングエージェント強化。Agentlessの「シンプルさ」とは対照的な「訓練による高度化」アプローチ
- MASAI (Saha et al., 2024): モジュール型アーキテクチャのエージェント。Agentlessよりも複雑だが、サブゴール分解による性能向上を実現
- CodeR (Chen et al., 2024): マルチエージェント＋タスクグラフ。5つのエージェント役割（manager、reproducer、fault localizer、editor、verifier）による協調
まとめと今後の展望
Agentlessは、「エージェントアーキテクチャは常に必要なのか？」という問いに対し、シンプルな2段階パイプラインでも実用的な性能が得られることを実証した研究である。階層的局所化と複数候補パッチの投票選択という設計は、コーディングエージェント設計の基本パターンとして広く参照されている。
ただし、最新のエージェント型アプローチ（SWE-bench Verified 60%+）との性能差は拡大傾向にあり、複雑なタスクにはエージェント型のアプローチが引き続き有効であると考えられる。実務では、タスクの複雑さとコスト要件に応じてAgentlessとエージェント型を使い分けるハイブリッド戦略が推奨される。
参考文献
- arXiv: https://arxiv.org/abs/2407.01203
- Code: https://github.com/OpenAutoCoder/Agentless（MITライセンス）
- Related Zenn article: https://zenn.dev/0h_n0/articles/a4a602b25afd3d