coding agentの性能は、モデルだけでは決まらない
SWE-agentは、GitHub Issueとrepositoryを受け取り、原因を探し、codeを修正するagent systemだ。論文が導入した中心概念はAgent-Computer Interface、略してACIである。人間向けのGUIやshellをそのまま渡すのではなく、language modelが迷いにくいcommandとfeedbackへ作り直す。
人間向けinterfaceでは、画面全体を見て必要な場所を選べる。agentでは、長すぎる出力がcontextを埋め、曖昧なcommandが誤操作を生み、silent failureが次の判断を壊す。SWE-agentはmodelを変える前に、search、view、editといった仕事場の設計を変え、その効果を測った。
ACIは、command・feedback・guardrailの組み合わせ
SWE-agentのACIは、repositoryを検索するcommand、fileの一部を表示するcommand、対象範囲を指定して編集するcommandなど、小さなtool setで構成される。出力は必要な行へ絞り、現在位置や変更結果を明示する。一般的なshellは残しつつ、頻出作業に専用の短いinterfaceを用意した。
編集commandにはguardrailもある。置換対象が一意でない、syntax errorを作る、といった問題を早く返し、壊れた状態のまま次へ進みにくくする。良いACIは操作を増やすのではなく、誤りをその場で観察可能にする。toolの説明文だけでなく、失敗時のfeedbackまでinterfaceの一部だ。
action: edit file.py lines 42-58
result: rejected
reason: replacement target matched 3 locations
evidence: matches at 42, 97, 131
next: narrow the range or include more surrounding textSWE-bench 12.47%をどう読むか
評価には、実在するPython repositoryのIssueと修正patchから作られたSWE-benchが使われた。GPT-4 Turboを使うSWE-agentは2,294件のtest setで12.47%を解決し、当時の既存最高3.8%を上回った。SWE-bench Liteでは、専用ACIが通常のLinux shellに対して10.7ポイントの改善を示した。
Claude 3 Opusでも10.5%となり、ACIの効果が一つのmodelだけへ閉じない可能性を示した。HumanEvalFixでは87.7%だったが、単一functionの修正と、未知のrepositoryでIssueを解く作業は難易度が違う。高いHumanEval値を、そのまま実repositoryの成功率として扱ってはいけない。
| 評価 | 構成 | 結果 | 意味 |
|---|---|---|---|
| SWE-bench test | GPT-4 Turbo + SWE-agent | 12.47% | 実Issueでは当時のSOTAでも大半は未解決 |
| 従来SOTA | 比較対象 | 3.8% | ACI込みのsystem設計が差を作った |
| SWE-bench Lite ablation | Custom ACI vs shell | +10.7pt | interface変更の寄与 |
| SWE-bench Lite | Claude 3 Opus + ACI | 10.5% | modelをまたぐ一定の移植性 |
| HumanEvalFix | SWE-agent | 87.7% | 狭い修正taskでは高いが別尺度 |
Issueからpatchまでのloop
agentはIssueを読み、repository全体をいきなり変更するのではなく、file検索、symbol検索、周辺行の表示で候補を狭める。編集後はtestやlintを走らせ、errorを次のObservationへ戻す。ReAct型のloopだが、行動空間をcoding向けに設計した点が違う。
重要なのは、正解patchを知っているbenchmarkでも、agentへ正解fileは与えないことだ。探索、理解、変更、検証のすべてが必要になる。実務のharnessも、最初から編集権限を渡すより、read-onlyの探索で影響範囲を作らせ、その後に狭いwrite scopeを与えるほうが安全で観察しやすい。
専用toolは、情報量を減らすために作る
agentへgrepやsedを教えれば済む場合もある。しかし一般commandのstdoutは、広すぎたり、formatが環境で変わったり、errorが分かりにくかったりする。専用toolは、modelの自由を増やすためではなく、必要な情報だけを安定したschemaで返すために作る。
たとえばfile viewerは総行数、表示範囲、切り詰めの有無を返す。edit toolは変更箇所、diff、syntax checkを返す。test runnerはexit code、失敗test名、artifact位置を返す。成功時より失敗時のcontractを詳しくすると、agentが同じ失敗を反復しにくい。
- 検索結果にはfile、line、match、件数、truncationを含める
- 編集は対象範囲を限定し、適用後のdiffを返す
- testはexit codeと最初の失敗を構造化する
- 出力上限へ達したら、黙って切らず続きを取る方法を示す
安全なharnessへ拡張する
論文の目的はbenchmark解決率であり、企業のproduction権限モデルを完成させることではない。実運用では、sandbox、network制限、secret mask、command allowlist、timeout、disk quotaをACIの外側に置く。modelへ『危険なことをしないで』と頼むだけでなく、実行環境で不可能にする。
変更操作はpreviewとapplyへ分け、削除、本番data、公開、課金、credential変更は人の承認を必要にする。外部IssueやREADMEも信頼できない入力なので、その中の命令をsystem指示として扱わない。agentが有能になるほど、許可した範囲を明示する重要性も上がる。
現在読むときは、数字と設計原則を分ける
論文のmodelとSWE-benchは2024年時点のsnapshotで、現在のcoding agentやbenchmark contamination、dataset更新を反映しない。後継実装やmini-SWE-agentも登場しており、最新製品の優劣をこの12.47%だけで判断できない。数字は当時の比較として扱い、現在のtoolを選ぶなら最新の評価と再現条件を確認する。
一方、『モデルに適した仕事場を作る』という設計原則は古くなりにくい。高性能modelへ切り替える前に、tool outputが長すぎないか、失敗理由が返るか、検証commandが一つに揃っているかを見る。agentの能力不足に見える問題が、実はinterface不足であることは多い。
導入前に確認する五つの問い
coding agentを評価するときは、demoのpatchではなく自分のrepositoryで測る。代表的なbug、docs修正、test追加を用意し、正しいfileへ到達したか、要求外の変更をしなかったか、検証まで通したか、失敗理由を残したかを見る。成功率だけでなく、人がreviewする時間も重要だ。
最初の目標は完全自律ではない。安全なsandboxで、read、edit、verifyの一連を再現できること。SWE-agentが示したのは、賢いmodelへshellを渡せば終わりではなく、software engineeringそのものと同じように、interfaceを設計・計測・改善する必要があるということだ。
- どの情報を読み取れ、どのdirectoryへ書けるか
- tool失敗が次の判断に十分な形で返るか
- 完了をtest・build・diffで外部判定できるか
- 同じ失敗を止めるbudgetと承認境界があるか
- 最終diffを人が短時間でreviewできるか