今回の論文
今回取り上げるのは、John Yangらの「SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering」です。2024年5月にarXivで公開された論文で、公開元はarXiv、URLは https://arxiv.org/abs/2405.15793 です。研究分野は、LLMエージェント、ソフトウェア工学、エージェント向けツール設計です。
選んだ理由は、コーディングエージェントの性能を「より大きなモデル」や「より長いプロンプト」だけで改善するのではなく、モデルがコンピュータを操作する境界そのものを設計対象にしたためです。自社のコード修正ボットや業務エージェントを作る際にも、ツールの粒度、返すログ、失敗時の保護策をどう決めるかという形で応用できます。
どんな技術か
SWE-agentは、LLMがリポジトリ内の不具合を調査し、コードを編集し、テストを実行して修正を作るためのエージェントです。中心となる考え方は、LLMに汎用シェルをそのまま渡す代わりに、**Agent-Computer Interface（ACI）**というエージェント専用の操作面を用意することです。
ACIは、検索、ファイル閲覧、行範囲の編集、実行結果の提示、履歴の圧縮をまとめて設計します。人間向けのCLIは柔軟ですが、LLMには選択肢が多すぎたり、出力が長すぎたりします。SWE-agentは操作を少数かつ明確にし、編集後には更新結果と構文エラーをすぐ返すことで、LLMが次の行動を判断しやすくします。
これは「LLMにコードを書かせる技術」というより、「LLMが反復して作業する環境を設計する技術」です。モデルの重みを追加学習しなくても、入力と行動空間を整えるだけで、実務に近いリポジトリ修正の成功率を上げられることを示しました。
課題
リポジトリ単位のバグ修正は、関数を一つ補完する問題より難しい作業です。課題文から関連ファイルを絞り、既存の設計やテストを読み、最小限の変更を加え、実行結果から直すべき点を判断しなければなりません。
- 汎用シェルでは、
cd、ls、cat、grepなどを何手も組み合わせる必要があります。LLMは冗長な探索を続けたり、長大な検索結果に埋もれたりしやすくなります。 sedやリダイレクトによる複数行編集は、意図しない置換やインデント崩れを起こしても、直後には気付きにくい操作です。一度の編集ミスが以後の推論を誤らせます。- エージェントの会話履歴には、古いファイル内容や失敗ログが蓄積します。人間なら不要な情報を読み飛ばせますが、LLMではコンテキスト長と注意資源を消費し、現在の状態と矛盾する情報にも影響されます。
- 事前に関連ファイルをRAGで取得して一度にパッチを生成するだけでは、実行・失敗・再修正というソフトウェア開発のフィードバックループを十分に使えません。
この問題は、Issueからの自動修正だけではありません。社内スクリプトの保守、設定ファイルの更新、データ変換ジョブの障害対応など、LLMが状態を持つ環境で複数ステップの操作をする場面全般で起きます。
用語解説
- Agent-Computer Interface（ACI）
- LLMエージェントがコンピュータへ命令を出し、結果を受け取るための操作仕様です。SWE-agentでは単なるツール一覧ではなく、コマンドの形、観測の表示、履歴の扱いまでを含むため、エージェントの判断品質に直接影響します。
- アクション空間
- エージェントが選べる操作の集合です。汎用CLIは強力ですが候補が広すぎます。SWE-agentは検索・閲覧・編集を目的別の少数の操作へ寄せ、LLMが誤った手順を選ぶ余地を減らします。
- 観測（observation）
- コマンド実行後にエージェントへ返す出力です。操作が成功したか、何が変わったかを短く具体的に返すことが、次の推論を正しくする鍵になります。
- ガードレール
- 誤操作を検出・阻止し、回復可能な状態に保つ仕組みです。この論文では編集直後にリンタを動かし、重大な構文エラーを生む変更を破棄します。自己修正を待つだけでなく、誤りを早く局所化する役割があります。
- SWE-bench
- 実在するPythonプロジェクトのGitHub Issueとテストを基にしたソフトウェア修正ベンチマークです。生成したパッチを実際に適用してテストを通すため、文章としてもっともらしいコードではなく、動く修正を評価できます。
技術の仕組み
SWE-agentはReAct形式で、LLMが「考え」と一つの操作を出し、その結果を次のターンへ渡すループで動きます。提案の本質は、このループに渡す操作と観測をACIとして整備した点です。
少数で目的の明確な操作へ絞る
リポジトリ探索には、ファイル名を探すfind_file、ファイル内を探すsearch_file、ディレクトリ横断で探すsearch_dirを用意します。検索結果は最大50件に制限し、多すぎる場合は結果を羅列せず、検索語を具体化するよう促します。これは、全候補を1件ずつ見続ける探索ループを防ぐための設計です。
ファイルを開くopenは一度に最大100行を、行番号・全行数・前後の省略量とともに表示します。scroll_up、scroll_down、gotoで位置を移せるため、モデルは「どのファイルの何行目を見ているか」を保ちやすくなります。情報量を最小化するのではなく、局所的な判断に必要な位置情報を残すことが重要です。
閲覧と結び付いた行範囲編集
editは、現在開いているファイルの開始行、終了行、置換テキストを受け取って、複数行を一操作で差し替えます。編集後は自動的に更新済みのファイル表示を返します。LLMは別の確認コマンドを打たずに、自分の変更が反映された文脈で次の判断をできます。
さらに、編集関数にリンタを統合します。重大なエラーが出る編集は適用せず、エラー箇所と編集前後の抜粋を返します。単に「失敗」と返すのではなく、変更によって生じた問題を結び付けるため、誤った編集を繰り返す連鎖を抑えます。
履歴を現在の作業へ合わせて圧縮する
エージェントにはコマンド仕様、例示の軌跡、Issue本文、操作結果が順に渡されます。形式が不正な出力には、正しい形式で再試行するようエラーを返します。実行結果が空の場合も「成功したが標準出力はない」と明示し、状態が不明なために余計な確認操作をすることを避けます。
過去の観測は直近5件を詳細のまま残し、それ以前は一行の要約へ畳み込みます。古いファイル内容をそのまま保持すると、すでに編集済みのコードと混ざるためです。この処理は長いコンテキストを単に切るのではなく、計画と行動履歴は残しながら、古くなった環境状態を薄くする設計といえます。
実行によるフィードバックループ
一般的なシェルコマンドやテスト実行も必要に応じて使えます。典型的な流れは、Issueの語からディレクトリを検索し、ファイルと行を絞り、再現コードやテストを実行し、editで修正し、テスト結果で検証するものです。論文中の軌跡分析でも、最初に再現または局所化を行い、広い検索からファイル・行へ段階的にズームインする行動が観察されています。
実験と結果
論文は実在のIssueに基づくSWE-benchと、短いデバッグ問題であるHumanEvalFixで評価しました。主なモデルはGPT-4 Turboで、Claude 3 OpusにもACIの移植性を確認しています。SWE-benchは12個のPythonリポジトリから集めた2,294件、SWE-bench Liteは自己完結した修正へ絞った300件です。
実行テストを通る修正の割合
評価指標の% Resolved（pass@1）は、生成パッチを適用した後に必要なテストが全て通ったIssueの割合です。GPT-4 Turboを使ったSWE-agentは、SWE-bench全体で12.47%（286/2,294件）、Liteで18.00%（54/300件）を解決しました。
比較すると、同じGPT-4 Turboで関連ファイルをBM25検索して一度にパッチを出すRAG方式はLiteで2.67%、シェルだけを使う対話エージェントは11.00%でした。したがって、対話そのものだけでなく、ACIを加えることでShell-onlyから相対64%の改善となりました。LiteではRAGより6.7倍高い解決率ですが、成功件当たりの平均API費用はRAGの0.13ドルに対し1.67ドルであり、反復操作にはコストが伴います。
ACIのどの要素が効いたか
SWE-bench Liteでのアブレーションでは、完全なACIは18.0%でした。リンタを外すと15.0%、専用の編集機能をなくすと10.3%へ下がりました。要約付きの検索を、1件ずつ送る反復検索に替えると12.0%、検索機能をなくすと15.7%でした。候補を順番に全確認させる検索は、むしろ作業を停滞させることが分かります。
ファイル閲覧は100行の窓が18.0%で最良で、30行では14.3%、ファイル全体を渡すと12.7%でした。履歴も全量を残すと15.0%で、直近5観測を残す圧縮方式に届きません。ここから、エージェントには「情報が多いほど良い」のではなく、現在の判断に合った粒度の観測が必要だと読めます。
小さな修正タスクでの確認
HumanEvalFixでは、GPT-4 Turbo版SWE-agentはPythonで87.7%、JavaScriptで89.7%、Javaで87.9%のpass@1を報告しました。これは短い問題だけでの強さを示す結果ですが、SWE-benchのようなリポジトリ横断タスクでは成功率が大きく下がります。実運用では、単発のコード生成評価をそのまま大規模保守の成功率と見なさないことが重要です。
何に使える？
Issueからの修正案作成
テストと再現環境が整ったリポジトリなら、Issueを入力として、関連箇所の探索、最小パッチ、テスト結果を含む修正案を作るワークフローへ使えます。特にACIの検索上限、行番号付き閲覧、編集後の差分提示は、レビュー担当者がエージェントの作業根拠を追う際にも役立ちます。
社内運用スクリプトの障害切り分け
ログの検索、設定ファイルの閲覧、dry-run、限定的な変更という操作を専用ツール化すれば、ETLやバッチ処理の運用支援にも考え方を移せます。この場合は任意のシェルを渡すのではなく、読み取り・検証・提案・承認済み反映を分けたACIにすることで、操作可能範囲を絞れます。
データ分析・RAG品質調査エージェント
ACIはコード専用ではありません。たとえばRAGの失敗分析なら、「検索ログを要約表示する」「指定質問の根拠チャンクを開く」「評価を実行する」「設定案を作る」といった少数の操作を設けられます。大量の生ログを渡すより、各操作の成功・失敗と次の判断材料を短く返す設計が有効そうです。
開発や事業へのヒント
モデル選定の前に操作契約を設計する
エージェント開発ではモデル名やプロンプトが注目されがちですが、ユーザー価値は「何を安全に、何手で、どんな根拠とともに完了できるか」で決まります。まず実務を探索、閲覧、変更、検証、提出へ分解し、それぞれを一つか二つの明確な操作へ落とすと、モデル差の評価も安定します。
観測をプロダクトのAPI仕様として扱う
ツールの戻り値は単なるログではありません。操作対象、変更した範囲、検証結果、次に試すべき制約を返すと、エージェントの再試行が意味のあるものになります。エラーも生のスタックトレースを全量で返すのではなく、原因候補と位置情報を持つ短い構造にすると、トークン費用と誤行動を減らせます。
失敗を早く止めて評価可能にする
小規模なプロダクトでも、構文チェック、差分サイズ制限、許可ディレクトリ、テスト必須化などは導入できます。これは安全対策であると同時に、誤った状態を次ターンのコンテキストへ持ち越さない品質対策です。導入時は「タスク完了率」だけでなく、操作回数、再試行回数、検証失敗率、1件当たりの推論費用を記録すると改善点を探しやすくなります。
限界
論文の結果は2024年時点のGPT-4 TurboとClaude 3 Opus、および特定のPythonリポジトリ中心のベンチマークに基づきます。現在のモデル、別の言語、大規模モノレポ、GUIやクラウド運用を伴う環境で、同じ数値が得られることを保証するものではありません。
また、SWE-agentはRAG方式より高い解決率を得た一方、反復実行のためAPI費用は増えます。テスト実行、依存関係のセットアップ、長いログも待ち時間と計算資源を使います。ACIの操作を絞り過ぎると、想定外の問題を解くために必要な自由度を失う可能性もあります。
リンタや構文検査は誤編集を抑えますが、意味的に誤った変更、脆弱性、性能劣化、テストの抜けを防ぐ十分条件ではありません。書き込み・デプロイ・外部サービス操作を伴う実運用では、権限分離、サンドボックス、変更レビュー、ロールバックをACIの外側にも設ける必要があります。
よくある質問
Q. SWE-agentは単なるコード生成モデルと何が違いますか？
A. コードを一度生成して終えるのではなく、検索、閲覧、編集、テストの結果を受け取りながら反復します。さらにSWE-agentの中心はLLMそのものではなく、その反復を行いやすくするACIです。同じモデルでも、与える操作と観測の設計によって結果が変わります。
Q. 自分のエージェントでSWE-agentと同じツールを作る必要がありますか？
A. そのまま再現する必要はありません。対象業務で頻出する作業を、少数の目的別操作へまとめることが本質です。たとえばデータ運用なら、ファイル編集の代わりに「クエリのdry-run」「集計結果の要約」「承認済みジョブ実行」を用意する方が適しています。
Q. コンテキストウィンドウが大きければ履歴圧縮は不要ですか？
A. 不要にはなりません。古い観測には編集前のコードや既に解決したエラーが混ざるため、容量だけでなく情報の鮮度が問題になります。直近の詳細を残し、過去は行動要約へ変える設計は、大きなコンテキストでも検証する価値があります。
Q. RAGとACIはどちらを優先すべきですか？
A. 役割が異なります。RAGは最初に関連する知識やファイル候補を渡すのに向き、ACIは探索・変更・検証の反復を扱います。論文では一回限りのRAGパッチ生成よりACI付きの対話方式が強かったため、複雑なタスクでは両者を組み合わせる設計が現実的です。
Q. 実運用で最初に入れるべきガードレールは何ですか？
A. まず、書き込み可能な対象を限定し、変更前後の差分を必ず保存し、検証コマンドが成功しなければ自動提出しないようにします。コード編集なら構文チェックやテスト、データ操作ならdry-runや行数上限を、各アクションの直後に返すのが有効です。
今日の学び
この論文は、LLMが実在リポジトリを修正するとき、汎用CLIの細かすぎる操作と長すぎる観測が作業を難しくする課題を扱いました。SWE-agentは検索・閲覧・編集・履歴管理をエージェント向けACIとして設計し、実行結果で反復することで解こうとしました。
得られるヒントは、エージェントの能力をモデルの賢さだけで判断しないことです。目的別の少数操作、現在の状態を示す短い観測、失敗を早期に止めるガードレールを設計し、実行可能な完了率と費用を一緒に測ることが、開発へ応用する第一歩になります。