SWE-agent: インターフェース設計がいかに自動化ソフトウェアエンジニアリングを解禁するか
先週、私は SWE-bench の論文を読み、シンプルな教訓を得ました。生の GPT-4 は実際の GitHub Issue のわずか 1.96% しか解決できないということです。今週は、その次の疑問である「何がその数字を動かすのか」を理解したいと考えました。Yang らによる SWE-agent (NeurIPS 2024) がその答えを提示しており、その答えは拍子抜けするほど退屈なものでした。それは「より優れたインターフェース」です。
論文
SWE-agent (John Yang, Carlos E. Jimenez, Alexander Wettig, Kilian Lieret, Shunyu Yao, Karthik Narasimhan, Ofir Press 共著; プリンストン大学 / スタンフォード大学) は、エージェント・コンピュータ・インターフェース (ACI) という概念を導入しました。これは、人間ではなく、言語モデルが実際に情報を処理する方法に合わせて設計された、LLM と Linux 環境の間に位置する専用のソフトウェアレイヤーです。著者らは、自律型ソフトウェアエンジニアリングエージェントの主なボトルネックは、基礎となるモデルではなく、このインターフェースの設計にあると主張しています。
このシステムは SWE-bench の GitHub Issue に対して動作します。Issue を読み、リポジトリをナビゲートし、関連するコードを特定して編集し、修正を確認するためにテストを実行します。この論文の新しい貢献は、新しいモデルやトレーニング手順ではなく、デフォルトの Linux シェルを置き換える、慎重に設計された一連のコマンドプリミティブとフィードバック形式です。
主なアイデア
- インターフェースが生のシェルを 10.7 パーセントポイント上回る。 300 件の SWE-bench Lite インスタンスを用いたアブレーション調査において、SWE-agent は、素の Linux シェルに配置された同一のエージェントよりも 10.7 ポイント多く Issue を解決しました。これは論文の中で最も大きな影響力を持つ要素です。
- 100 行ウィンドウのファイルビューア。 ファイル全体を
catするのではなく、ACI はスクロールコマンドを使用して 1 ターンあたり約 100 行を表示します。コンテキストが少なすぎる (30 行) と 3.7 ポイントの損失と なり、多すぎる (ファイル全体) とモデルが焦点を失います。スイートスポットは非常に狭いのです。 - 編集ループ内のリンター。 すべての編集コマンドは、変更をコミットする前に構文チェッカーを実行します。これにより、モデルが自然言語だけでは脱出困難な、壊れたコードの状態に陥るのを防ぎます。
- ミニマリストなディレクトリ検索。 前後の文脈を含めた
grep -r(これはモデルを圧倒してしまいました) の代わりに、ACI は一致するファイル名のリストのみを返します。モデルが次にどこを見るべきかを判断する場合、少ないほど効果的です。 - 最終的なベンチマーク結果: GPT-4 Turbo を使用した SWE-bench で 12.47% を達成。 これは、非対話型 RAG システムの 3.8% や、オリジナルの SWE-bench 論文の単純な検索ベースラインの 1.96% と比較されます。HumanEvalFix では 87.7% に達しました。
- ACI 設計の汎用性。 サイバーセキュリティ版 (SWE-agent EnIGMA) は、同じ ACI の哲学を CTF (Capture The Flag) チャレンジに適用し、並行シェルセッションを維持する対話型エージェントツールを使用して、従来のシステムの 3 倍にあたる 13.5% を達成しました。
何が有効で、何がそうでないか
核心となる洞察、すなわち「エージェントのためのインターフェース設計はプロンプトエンジニアリングと同じくらい重要である」という点は、十分に裏付けられており、非常に有益だと感じます。アブレーション調査は誠実で、著者は各コンポーネントを分離し、それぞれが何に貢献しているかを示しています。生のシェルのベースラインに対する 10.7 ポイントの向上は、モデルの差異では説明できない明確な結果です。
あまり納得がいかない点もあります。それはベンチマーク自体です。SWE-bench のテストセットには、複雑さ、曖昧さ、そして正解のパッチがどの程度特定されているかにおいて、非常にばらつきのある Issue が含まれています。Issue の質の分散が大きいということは、12.47% という数字が、評価セットにたまたまどの Issue が含まれていたかという事実に一部依存していることを意味します。著者らはアブレーション調査に SWE-bench Lite (300 件) の結果を報告することで、これを暗黙的に認めていますが、そのサブセット内でも分散は依然として高いままです。
より大きな制限はスコープです。SWE-bench は、単一の Issue 解決を独立して測定します。複数の Issue にわたるセッションメモリや、コードベースの履歴の理解、Issue 間の依存関係の追跡はありません。その後の SWE-Bench Pro (arXiv:2509.16941, 2025) では、複数のファイルにわたる調整された変更が必要な場合、最先端のモデルであっても解決率が 25% 以下に低下することが示されました。ファイル数が増えるにつれてパフォーマンスは急激に低下します。ACI は単一の Issue 内では役立ちますが、SWE-agent が設計されていない「長期スパンかつ複数ファイル」のケースこそが、解決すべき難問です。
また、再現性の問題につ いても考え続けています。インターフェース設計の選択肢 (100 行のウィンドウ、ミニマリストな検索出力) は、トレーニング/開発セットでの反復的な実験によって見出されたものです。これらの選択肢が、同様のチューニング作業なしに新しいドメインにそのまま転用できるかどうかは明らかではありません。これは無視できないコストです。
なぜこれが金融AIにとって重要なのか
ACI の枠組みは、Beancount エージェントの設計問題に直接当てはまります。Beancount の元帳はコマンドラインではありませんが、モデルが読み取り、ナビゲートし、書き込む必要のある構造化された成果物です。そこから得られる教訓は以下の通りです。
- 一度に 20〜50 件のトランザクションを表示し、スクロールとフィルターコマンドを備えた元帳ビューアは、10 年分のデータを一度にダンプするものよりも優れた性能を発揮します。コンテキストウィンドウのオーバーフローは、共通の失敗モードです。
- エントリをコミットする前に、複式簿記のバランスと勘定科目の存在を確認する書き込みバリデーターは、SWE-agent におけるリンターの元帳版です。これがないと、構文的に間違ったエントリを作成したエージェントには回復の道がありません。
- ミニマリストな検索が重要です。「日付 Y から Z の間の勘定科目 X のすべてのトランザクションを表示」というクエリは、冗長な文脈を含んだダンプではなく、コンパクトでスキャン可能なリストを返すべきです。
この論文は、Beancount 書き戻しエージェントの初期バージョンに何を期待すべきかについての現実的なベンチマークも示しています。適切に定義された GitHub Issue での 12.47% の解決率は、慎重に設計された単一 Issue 対応エージェントの現在の天井です。元帳の書き戻しは、ユーザーの意図、構造化されたファイル、必要な出力、検証器という同様のタスク構造を持っており、適切に定義されたタスクでは同程度の達成率が期待できますが、複数エントリ・複数勘定にわたるワークフローでは急激な低下が予想されます。
次に読むべきもの
- MemGPT: Towards LLMs as Operating Systems [arXiv:2310.08560] — SWE-agent のコンテキスト管理は事後的 (オーバーフロー時に切り捨て) ですが、MemGPT は能動的な階層型メモリを提案しており、これは数年分の Beancount 元帳を推論する必要があるエージェントに不可欠だと思われます。
- SWE-Bench Pro: Can AI Agents Solve Long-Horizon Software Engineering Tasks? [arXiv:2509.16941] — SWE-agent が及ばなかった部分を直接フォローアップしています。複数ファイルによる劣化データは、複雑な元帳における書き戻しの安全性を設計する上で必読です。
- Gorilla: Large Language Model Connected with Massive APIs [arXiv:2305.15334] — ACI がインターフェース設計に関するものであるなら、Gorilla は API 検索に関するものです。この 2 つを組み合わせることで、エージェントがツールを確実かつ適切に選択・呼び出しする方法について、より完全な全体像が見えてきます。
