# SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering
> [!abstract] 概要
> 言語モデル（LM）エージェントは、デジタル環境における複雑なタスクを自動化するためにますます活用されるようになっている。人間がソフトウェアエンジニアリングのような複雑なタスクにおいて、統合開発環境などの強力なソフトウェアアプリケーションの恩恵を受けているのと同様に、著者らはLMエージェントが独自のニーズと能力を持つ新しいカテゴリのエンドユーザーを代表しており、自身が使用するソフトウェアへの特別に構築されたインターフェースから恩恵を受けると仮定する。著者らは、インターフェースの設計が言語モデルエージェントの性能にどのように影響するかを調査する。この探求の結果として、LMエージェントがコンピュータを自律的に操作してソフトウェアエンジニアリングタスクを解決することを可能にするシステムであるSWE-agentを導入する。SWE-agentのカスタムエージェント・コンピュータ・インターフェース（ACI: agent-computer interface）は、コードファイルの作成と編集、リポジトリ全体のナビゲーション、テストやその他のプログラムの実行を行うエージェントの能力を大幅に強化する。SWE-benchおよびHumanEvalFixにおいてSWE-agentを評価したところ、それぞれ12.5%および87.7%のpass@1率を達成し、双方で最先端（SOTA）の性能を達成し、非対話型LMで達成された従来の最先端を大幅に上回った。最後に、ACIの設計がエージェントの振る舞いと性能にどのように影響を与え得るかについての洞察を提供する。
## 論文情報
- **タイトル**: SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering
- **著者**: John Yang*, Carlos E. Jimenez*, Alexander Wettig, Kilian Lieret, Shunyu Yao, Karthik Narasimhan, Ofir Press (*等貢献)
- **所属**: Princeton Language and Intelligence (PLI), Princeton University
- **採択会議**: NeurIPS 2024 (38th Conference on Neural Information Processing Systems)
- **リンク**: [arXiv:2405.15793](https://arxiv.org/abs/2405.15793) | [プロジェクト・コード](https://swe-agent.com)
## 概要
本論文は、大規模言語モデル（LLM）が自律的にソフトウェアエンジニアリング（SE）タスクを遂行するためのシステム**SWE-agent**と、その中核となる概念**Agent-Computer Interface（ACI）**を提案した画期的な研究である。従来の自律型エージェント研究では、人間向けに作られたLinuxシェルやCLIツールをそのままエージェントに操作させることが通例であった。しかし人間とLMでは認知的制約や入出力特性が根本的に異なる。人間向けGUIやCLIをそのまま与えても、冗長な出力によるコンテキストウィンドウの枯渇、状態追跡の喪失、構文エラーの連鎖による破綻が発生する。
これに対し著者らは、HCI（ヒューマンコンピュータインタラクション）の知見に着想を得て、「LMエージェントを独自のニーズと限界を持つ新たなエンドユーザー」と定義した。そして、LMの特性に合わせて特別に設計された専用インターフェース（ACI）を提供することで、モデルの重みを一切ファインチューニングすることなく、実世界の大規模リポジトリにおける課題解決能力を劇的に引き上げることに成功した。
*Figure 1: SWE-agentの全体像。LMエージェントはACIを介してコンピュータ（ターミナルおよびファイルシステム）と対話する。ACIはLMフレンドリーなコマンド群（リポジトリ移動・ファイル検索・ファイル閲覧・行編集）と、環境からの簡潔かつ高情報密度のフィードバックを提供する。*
## 問題設定
### 背景と課題
実世界のソフトウェア開発タスク（バグ修正、機能追加、リファクタリング）は、数行〜数十行の自己完結型コード生成（HumanEvalやMBPP等）とは質的に異なる。
1. **リポジトリ全体の広大な探索空間**: 数万〜数十万行に及ぶコードベースから、関連するファイル・関数・クラスを特定（バグ局所化）しなければならない。
2. **多段階の対話的サイクル**: 問題の再現スクリプトの作成、バグ原因の特定、コード編集、テスト実行、リグレッション確認という複数の推論・実行フェーズを長期間にわたって維持する必要がある。
3. **人間向けインターフェースとの不整合**:
- **冗長性**: 標準の`cat`や`grep`、`find`は数百〜数千行の出力を吐き出すことがあり、LMのコンテキストウィンドウを瞬時に圧迫する。
- **状態把握の困難さ**: `cd`や`ls`、`sed`などの標準コマンドは、実行後のファイル状態や行番号の変化を明示的にフィードバックしないため、モデルがコードの現在状態を見失いやすい。
- **エラー連鎖（Cascading Errors）**: エージェントが一度インデントミスや括弧の閉じ忘れなどの構文エラーを起こすと、何が起きたか理解できず、同じ壊れた編集を繰り返して暴走・脱落する。
*Figure 2: 人間にはVSCodeやPyCharmなどのリッチなGUI（UI）が不可欠であるのと同様に、LMエージェントにも専用のファイル閲覧・編集・検索機能を提供するACIが必要である。*
## 提案手法
SWE-agentの中核は、ReActパラダイム（推論 Thought と行動 Action の交互生成）に基づきつつ、LMの認知的特性に適合させた**Agent-Computer Interface（ACI）**の設計である。
### 1. ACIの4大設計原則
著者らは開発セット上での定性分析とパラメータ探索を通じて、以下の4原則を確立した：
1. **単純で理解しやすいアクション（Simple and easy to understand）**: オプションが過多なコマンド（何十もの引数を持つBashユーティリティ）を排し、少数の明確な引数を持つ専用コマンドを定義する。
2. **コンパクトで高効率な操作（Compact and efficient）**: 複数ターンに跨る定型操作（検索、ファイル開示、行特定、置換）を1アクションに集約し、1ステップで実質的な進捗を生む。
3. **簡潔かつ実質的な環境フィードバック（Informative but concise feedback）**: 冗長な装飾やノイズを排除し、現在の環境状態と直前アクションの影響（変更後のファイルプレビュー等）を正確に伝える。出力がない場合は「正常終了し出力なし」と明示する。
4. **エラー連鎖を防ぐガードレール（Guardrails for error recovery）**: 構文リンター（Flake8）等を組み込み、構文エラーを伴う編集を即座にブロックして適用前の状態を保ち、修正の手がかりを返す。
### 2. ACIの主要コンポーネントとコマンド体系
SWE-agentはLinuxシェル環境の上で動作し、以下の専用コマンド群を提供する（Table 4参照）：
| カテゴリ | コマンド | 引数 | 動作と特徴 |
|---|---|---|---|
| **File viewer** | `open` | `<path> [<line_number>]` | 指定パスのファイルを開き、指定行（既定は先頭）を中心とするウィンドウ（100行）を表示。 |
| | `goto` | `<line_number>` | 開いているファイルの指定行へウィンドウを移動。 |
| | `scroll_down` | なし | ウィンドウを100行下（進む方向）へスクロール。 |
| | `scroll_up` | なし | ウィンドウを100行上（戻る方向）へスクロール。 |
| **Search tools** | `search_file` | `<search_term> [<file>]` | ファイル内から文字列を検索（ファイル未指定時は現在開いているファイル）。 |
| | `search_dir` | `<search_term> [<dir>]` | ディレクトリ内の全ファイルから文字列を検索（未指定時はカレントディレクトリ）。 |
| | `find_file` | `<file_name> [<dir>]` | 指定名のファイルを検索。 |
| **File editing** | `edit` | `<n>:<m>\n<replacement>\nend_of_edit` | 開いているファイルのn行〜m行（両端含む）を置換。直後にリンター検証を実行。 |
| | `create` | `<filename>` | 新規ファイルを作成してエディタで開く。 |
| **Task control** | `submit` | なし | 全変更からパッチファイルを生成して提出し、対話セッションを終了する。 |
*Figure 3: (a) ファイルビューアによる観測（Figure 3a）。全体の行数、上部の省略行数、行番号付きのコードスニペット（最大100行）、下部の省略行数が明確に提示される。(b) 編集インターフェースによるアクション（Figure 3b）。`edit 404:407`で指定行範囲を一括置換する。適用後は自動的に更新後のファイル状態がビューアに再描画される。*
*Figure 10: ACIにおけるファイル閲覧（`open atmosphere.py`）および各種検索コマンド（`find_file`, `search_dir`, `search_file`）の具体的な標準出力フォーマット。検索結果が50件を超える場合は出力を抑制し、より具体的なクエリへの洗練を促す。*
### 3. エディタと構文リンターガードレール
エージェントがファイル編集に失敗する最大の要因は、インデントの乱れや閉じ括弧の欠落といった初歩的な構文エラーである。SWE-agentでは`edit`コマンド実行直後に**Flake8**による静的構文チェック（SyntaxError, IndentationError等のE999系エラー）を自動実行する。
- エラーが検知された場合：変更は**破棄（ロールバック）**され、ファイルには適用されない。
- フィードバック：編集適用前後のコード比較とリンターのエラーメッセージがエージェントに提示され、再試行を促す（Figure 6参照）。
### 4. コンテキスト管理機構
長期間の対話においてコンテキストを最適に維持するため、以下の3つの工夫を導入している：
1. **過去観測の折りたたみ（Observation Collapsing）**: 最新5ターンの観測結果のみを完全に保持し、それ以前の過去の観測は1行の要約テンプレートに圧縮・折りたたむ（Figure 31参照）。これによりコンテキスト長を節約し、古いファイル表示による幻覚を防ぐ。
2. **フォーマットエラーの自己修復**: ThoughtとActionの出力形式に違反した場合、Figure 32のエラーメッセージを返し、再試行させる（成功後は最初のエラー以外を履歴から削除）。
3. **明示的な無出力通知**: コマンドの標準出力が空だった場合、`Your command ran successfully and did not produce any output`というテンプレート（Figure 30参照）を返し、エージェントが「失敗したのか成功したのか分からない」状態に陥ることを防ぐ。
*Figure 30: コマンド実行後にエージェントへ提示される標準プロンプトテンプレート。*
*Figure 31: 5ターン以上前の古い観測は単一行に折りたたまれ、トークン消費を抑制する。*
*Figure 32: モデルの生成がThought/Action形式に従わなかった場合に環境が返すエラープロンプト。*
## 新規性
1. **概念的転換（HCIからACIへ）**: LLMエージェントを「デジタル環境の新しいエンドユーザー」として捉え直し、モデル重みの訓練ではなくインターフェース抽象層の設計によって能力を引き出すという新しい研究領域「Agent-Computer Interface（ACI）」を定義・体系化した点。
2. **ソフトウェアエンジニアリング（SE）への初のエンドツーエンド適用**: 単なるコード補完や関数生成ではなく、大規模リポジトリにおけるバグ再現・局所化・編集・検証・パッチ提出を完全自律化した初のシステム。
3. **大幅な性能ブレークスルー**: SWE-benchにおいて従来のSOTA（非対話型RAG: 3.8%）を3倍以上引き離す12.5%を達成し、自律型コーディングエージェントの実用可能性を証明した点。
## 実験設定
### 評価ベンチマーク
- **SWE-bench (Full)**: 人気のオープンソースPythonリポジトリ12件から収集された実世界GitHub課題2,294件。ユニットテスト実行による厳密な成否判定（Fail-to-Pass, Pass-to-Pass）。
- **SWE-bench Lite**: 自己完結したバグ修正に焦点を当てた選定サブセット300件。アブレーション検証や定性分析に主に使用。
- **HumanEvalFix**: 短編コードのデバッグ性能を測るベンチマーク（Python, JavaScript, Java）。
### ベースライン
1. **RAG（Retrieval-Augmented Generation）**: BM25で関連ファイルを検索し、モデルに直接パッチを生成させる非対話型手法（Jimenez et al., 2023）。
2. **Shell-only**: 標準のLinux Bashシェル環境をそのままエージェントに与え、対話的に操作させる設定（InterCodeベース）。
### 評価モデルと予算
- **モデル**: GPT-4 Turbo (`gpt-4-1106-preview`, 128kコンテキスト)、Claude 3 Opus (`claude-3-opus-20240229`, 200kコンテキスト)。
- **コスト上限**: 1タスクあたり最大$4.00に設定。上限に達した場合はその時点の変更を強制提出（Submit）。
## 実験結果
### 1. SWE-bench 主要結果
Table 1に示す通り、SWE-agentはすべての設定において圧倒的な性能を達成した。
*Table 1: SWE-bench FullおよびLiteにおける解決率（% Resolved）と平均コスト（$ Avg. Cost）。*
主要な結果の要約：
- **SWE-bench Full**:
- SWE-agent w/ GPT-4 Turbo: **12.47%**（286 / 2,294件解決）、平均コスト $1.59
- SWE-agent w/ Claude 3 Opus: **10.46%**、平均コスト $2.59
- RAG w/ GPT-4 Turbo: 1.31%
- RAG w/ Claude 3 Opus: 3.79%
- **SWE-bench Lite**:
- SWE-agent w/ GPT-4 Turbo: **18.00%**（54 / 300件解決）、平均コスト $1.67
- Shell-only agent w/ GPT-4 Turbo: **11.00%**（デモなし時は7.33%）
- RAG w/ GPT-4 Turbo: 2.67%
- Shell-onlyと比較して、同じGPT-4 Turboを用いながら解決率が**11.0%から18.0%へ64%相対向上**したことは、ACIというインターフェース抽象の絶大な効果を実証している。
### 2. HumanEvalFix 結果と多言語汎用性
Table 2に示す通り、SWE-agentは短編デバッグタスクにおいても従来のコードモデルを大幅に凌駕した。
*Table 2: HumanEvalFixにおける各言語のpass@1結果。SWE-agent w/ GPT-4 TurboはPython 87.7%、JS 89.7%、Java 87.9%と全言語で87%以上の高いデバッグ性能を記録した。*
*Figure 4: SWE-bench Liteにおける6回の独立試行によるpass@k性能曲線。k=1の18.0%から、k=6では30%近くまで解決率が上昇し、試行の多様化によるサンプリング効果が確認できる。*
### 3. ACI設計コンポーネントのアブレーション実験
Table 3に、SWE-agent（18.0%）の各要素を差し引いたアブレーション結果を示す。
*Table 3: SWE-bench Liteにおけるエディタ、検索、ビューアウィンドウ幅、コンテキスト管理の各要素に関するアブレーション結果。*
1. **エディタ（Editor）**:
- `edit` + リンター（SWE-agent既定）: **18.0%**
- リンターなしの`edit`: **15.0%**（↓3.0ポイント）
- 専用エディタなし（Shell-onlyの`cat`/`echo`/`sed`）: **10.3%**（↓7.7ポイント）
2. **検索（Search）**:
- 要約検索（Summarized, SWE-agent既定）: **18.0%**
- 対話的1件表示検索（Iterative, `next`/`prev`でめくる方式）: **12.0%**（↓6.0ポイント）
- 専用検索なし（No search）: **15.7%**（↓2.3ポイント）
- **重要知見**: 人間向けUIに倣った「Iterative search」は、エージェントが全検索結果を律儀にめくり続けて予算を食いつぶすため、**検索ツールが全くない場合よりも性能が悪化する**という逆転現象が発生した。
3. **ファイルビューア（File Viewer）**:
- 100行表示（既定）: **18.0%**
- 30行表示（狭すぎる）: **14.3%**（↓3.7ポイント）
- ファイル全体表示（コンテキスト圧迫）: **12.7%**（↓5.3ポイント）
4. **コンテキスト管理（Context）**:
- 直近5観測を保持し過去を折りたたむ（既定）: **18.0%**
- 全履歴をそのまま保持（Full history）: **15.0%**（↓3.0ポイント）
- デモンストレーションなし（w/o demo）: **16.3%**（↓1.7ポイント）
*Figure 5: 3種類の検索インターフェース。Vanilla CLI（左）は不毛なls/cdを繰り返し、Iterative Search（中央）はnextを乱発してステップを浪費する。一方Summarized Search（右）は1回の問い合わせで必要なファイルと行を特定できる。*
*Figure 6: 3種類のエディタ比較。No edit（左）ではsedの無出力により混乱が生じる。edit w/o Linting（中央）では構文エラーがファイルに混入して回復不能になる。edit w/ Linting（右）ではエラー変更が弾かれ、直前の正常コードとエラー理由が明示されるため即座に自己修正できる。*
## 考察
### 1. エージェントの行動パターンと遷移確率
解決に成功した286本の軌跡を分析したところ、明確な定型フェーズの遷移が観察された（Figure 7, Table 8, Figure 22）。
*Figure 7: 解決タスク（286件）におけるターンごとのアクション頻度。初期ターン（0〜4）は`create`（再現テスト作成）と`search_dir`/`find_file`（バグ局所化）が占め、第5ターン以降は`edit`と`python`（実行検証）の密なループへと移行する。提出（`submit`）は第10ターン以降に正規分布する。*
*Table 8: ターンごとの頻出アクショントリプル。最も代表的なパターンは `create` → `edit` → `python`（再現スクリプトの作成とテスト実行）である。*
*Figure 22: アクションペアの実行後に呼び出される次アクションの遷移確率ヒートマップ。バグ局所化シーケンス（`python`, `find_file`）や（`search_dir`, `open`）の後は`search_file`や`goto`が高確率で続き、広域探索から特定行への「ズームイン」が自律的に行われている。*
### 2. 「素早く成功し、遅く失敗する」（Succeed Quickly, Fail Slowly）
エージェントの成否と所要ステップ・コストには顕著な相関がある：
- **解決成功インスタンス**: 中央値**12ステップ**・コスト**$1.21**で迅速に終了。解決されたインスタンスの**93.0%**は予算上限（$4）に達する前に自発的に`submit`を行っている。
- **未解決インスタンス**: 平均**21ステップ**・コスト**$2.52**を費やし、堂々巡りの末に予算枯渇または時間切れで終了。
- この事実は、コンテキスト長や実行予算を単に2倍・3倍に増やしても、解決率はほとんど伸びないことを示唆している（迷走したエージェントが追加ステップで正気に戻る確率は極めて低い）。なお著者は Table 15（本文中の言及。実体は付録Table 13/14に集計）にて、予算を使い切らなかったインスタンスに限定しても成功セッションの方が圧倒的に安価かつ早期に完了している分布を示している。
### 3. 未解決インスタンスの失敗モード分析
未解決インスタンス（SWE-bench Lite, n=248）をGPT-4oを用いて9つのカテゴリに自動分類した（Figure 8, Table 9）。
*Figure 8: 未解決インスタンスの失敗モード分布。全体の半分以上（52.0%）が実装内容の誤り（不正確な実装 39.9%、過度に限定的な実装 12.1%）であり、次いで編集エラーからの回復失敗（23.4%）が続く。*
*Table 9: 失敗モードの9カテゴリの定義（Incorrect Implementation, Overly Specific Implementation, Failed to Recover from Edit, Failed to Find Edit Location, Failed to Find Relevant File, Gave Up Prematurely, Can't Reproduce, Ran Out of Time等）。*
- **実装の不備（52.0%）**: `Incorrect Implementation`（39.9%）および`Overly Specific Implementation`（12.1%）が過半数を占める。修正箇所は特定できたものの、論理的に正しくないパッチを書いたり、特定テストケースに過剰適合したパッチを書いてしまい、全体テストを通せない。
- **編集回復の失敗（23.4%）**: 編集時に発生したエラーから立ち直れずにループに陥る現象。編集の試み自体は初回90.5%が最終的に成功するが、一度編集に失敗するとその後の回復成功率は**57.2%**まで急落する。
## 強み / 弱点・課題
### 強み
1. **重み不変で劇的な性能向上**: モデルのファインチューニングや追加学習を必要とせず、プロンプトとツールインターフェース（ACI）の工夫のみでSOTAを樹立。
2. **高い可搬性（Portability）**: GPT-4 Turbo向けに最適化されたACIが、Claude 3 Opus（10.46%）に対してもそのまま有効に機能し、特定のモデルアーキテクチャに依存しない普遍的な有用性を証明。
3. **徹底した実践性**: 構文リンターによる安全策、観測の折りたたみ、出力フォーマットの厳格な制御など、実運用のコーディングエージェントに必要な堅牢化技術を確立。
### 弱点・課題
1. **絶対的な解決率の限界**: 12.5%というSOTA性能は達成したものの、依然として約87%の実世界課題は未解決のままであり、人間の代替には遠い。
2. **深い仕様理解と汎化能力の不足**: 失敗の52%が実装の論理的誤りや過剰適合に起因しており、複数ファイルにまたがる複雑な設計意図や暗黙の仕様を捉える推論能力はACI単体では補いきれない。
3. **言語・環境の偏り**: 評価はPythonリポジトリ（SWE-bench）が主であり、静的型付け言語（C++, Rust, Java等）や複雑なビルドシステム（CMake, Gradle等）を持つ環境への適用性・ACI設計の一般化は今後の課題。
## 関連
- システム: [[SWE-agent]]
- 中核概念: [[Agent-Computer Interface]]
- 関連ベンチマーク: [[SWE-Bench-Verified]] / [[SWE-bench Pro]]
- 横断概念: [[SWEエージェントの情報信号]]
- 著者: [[John Yang]] / [[Carlos E. Jimenez]] / [[Alexander Wettig]] / [[Kilian Lieret]] / [[Shunyu Yao]] / [[Karthik Narasimhan]] / [[Ofir Press]]
- 所属機関: [[Princeton University]]
- 先行枠組み: [[@2023__ICLR__ReAct Synergizing Reasoning and Acting in Language Models]]
## 出典
- Yang, J.*, Jimenez, C. E.*, Wettig, A., Lieret, K., Yao, S., Narasimhan, K., & Press, O. (2024). SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering. *Thirty-eighth Conference on Neural Information Processing Systems (NeurIPS 2024)*. arXiv:2405.15793.