SWE-Bench解剖：LLMエージェント自動修復の最前線

紹介論文

今回紹介する論文はDissecting the SWE-Bench Leaderboards: Profiling Submitters and
Architectures of LLM- and Agent-Based Repair Systemsという論文です。

この論文を一言でまとめると

本記事では、SWE-Benchリーダーボードの分析を通じて、LLMとエージェントベースの自動プログラム修復システムの現状を解き明かします。アーキテクチャ、提出者、利用LLMなどの詳細なプロファイルから、APR研究の新たな方向性と実践的な活用方法を探ります。

はじめに：SWE-Benchリーダーボード解剖の意義

自動プログラム修復（APR）は、ソフトウェア開発における長年の課題に対し、自動でコードの欠陥を修正する技術です。初期のAPRは、検索や制約ベースの手法に頼っていましたが、近年、AI、特に深層学習とトランスフォーマーアーキテクチャの進化によって大きな変革を遂げています。

大規模言語モデル（LLM）とエージェント技術は、この変革をさらに加速させています。これらの技術により、システムは問題の理解からパッチの生成・検証まで、修復プロセス全体を自律的に処理できるようになりました。まさに、ソフトウェア開発の自動化の最前線と言えるでしょう。

そんな中、SWE-Benchという新しいベンチマークが登場しました。SWE-Benchは、実際の問題とpull requestを利用してLLMベースの修復システムを評価するために設計されたもので、12の一般的なオープンソースPythonリポジトリから収集された2,294のインスタンスを含んでいます。中でも、SWE-Bench Lite（300インスタンス）とSWE-Bench Verified（500インスタンス、OpenAIが検証）の2つの主要なリーダーボードは、注目を集めています。

これらのリーダーボードは、進捗状況の追跡やソリューションの比較において中心的なプラットフォームとなっていますが、提出プロセスでは詳細なドキュメントが必須ではないため、多くのソリューションのアーキテクチャ設計と起源は不明確なままです。そこで、本記事では、SWE-Benchリーダーボードの解剖を通じて、これらのソリューションを深掘りしていきます。

本記事では、以下の点を明らかにしていきます。

* 提出者の種類（個人開発者、企業、学術機関など）
* 製品の可用性
* 使用されているLLMの種類
* システムアーキテクチャ

これらの分析を通じて、自動プログラム修復の進歩を推進するアーキテクチャの選択肢と機能をより深く理解し、ソフトウェア開発の未来を垣間見ていきましょう。

調査方法：リーダーボードデータの深堀り

SWE-Benchリーダーボードの解剖は、自動プログラム修復（APR）技術の現状を把握するための重要なステップです。このセクションでは、論文で採用された調査方法論を詳細に解説し、データ収集から分析、分類に至るプロセスを明確にすることで、研究の信頼性を担保します。

1. データ収集：正確性と網羅性を追求

データ収集は、リーダーボード分析の基盤となる工程です。論文では、以下の手順で、SWE-Bench LiteとSWE-Bench Verifiedの両リーダーボードからデータを収集しています。

• リーダーボードの精査：各リーダーボードのページを詳細に確認し、各提出物の基本情報（提出名、解決率、サイトURL）を取得します。
• 関連サイトの探索：各提出物に関連付けられたサイトを訪問し、アーキテクチャや設計に関する情報、SWE-Benchでの実験に関する参考文献を探します。ブログや論文など、目標に役立つ外部リンクも丁寧にたどります。
• Google検索の活用：リーダーボードに直接リンクされていない情報も捕捉するため、Google検索（"<Name_Entry> + SWE-Bench"）を実行します。
• 提出データの詳細な分析：各提出物に含まれるREADME.mdやmetadata.yamlファイルを精査し、アーキテクチャの詳細や使用LLMなどの情報を確認します。
• LinkedInでの情報収集：提出者のLinkedInプロフィールを調査し、実験に関する議論や洞察を探します。

2. データ分類：体系的な分析を支える

収集されたデータは、体系的な分析を可能にするために、いくつかの属性に基づいて分類されます。論文では、演繹的コーディングと帰納的コーディングを組み合わせたコンテンツ分析の手法を採用しています。

• 演繹的コーディング：事前に定義されたテーマ（分析対象の属性）に基づいてデータを分類します。
• 帰納的コーディング：各テーマについて、最初は空のコードセットから開始し、リーダーボードのコンテンツを処理するにつれて、徐々にコードを絞り込んでいきます。

主要な分類軸は以下の通りです。

• 提出者カテゴリ：学術機関、企業（規模別）、学術機関と企業の共同研究、オープンソースコミュニティ、個人開発者など、提出者の種類を分類します。
• 製品とアクセシビリティ：製品の目的（エージェントフレームワーク、コーディングアシスタントなど）、製品形態（クラウドプラットフォーム、コマンドラインツールなど）、製品の可用性（一般公開、リクエストに応じて提供、企業間取引など）を分類します。
• オープンソースソリューション：ソースコードが公開されているかどうかを判断します。
• 使用LLM：各ソリューションで使用されているLLMを特定します。

3. アーキテクチャ分析：多角的な視点

ソリューションのアーキテクチャを理解するために、以下の3つの次元で分析を行います。

• エージェント数：エージェントを使用していないソリューション、単一エージェント、複数エージェントの３つのカテゴリに分類します。
• ワークフローの作成：人間の手によってワークフローが定義されているか、エージェントが自律的にワークフローを生成するかを区別します。
• 制御フローの自律性：実行パスを決定する上でのシステムの自由度を評価し、Emergent Autonomy、Scaffolded Execution、Fixed Executionの３つのカテゴリに分類します。

4. ソフトウェアメンテナンスパイプラインの実装分析

ソフトウェアメンテナンスパイプラインの各段階（Preprocessing、Issue Reproduction、Issue Localization、Task Decomposition、Patch Generation、Patch Verification、Ranking）におけるソリューションの実装状況を分析することで、各アプローチの強みと弱みを明らかにします。この分析には、LLMベースのエージェントだけでなく、従来のアプローチも含まれます。

論文で採用された綿密な調査方法論は、SWE-Benchリーダーボードの多角的な分析を可能にし、APR技術の現状を詳細に把握するための強固な基盤を提供しています。次のセクションでは、この方法論に基づいて得られた分析結果を詳しく見ていきましょう。

RQ1：SWE-Benchリーダーボードの主要特性

SWE-Benchリーダーボードは、自動プログラム修復（APR）技術の進化を測る上で重要な指標です。本セクションでは、SWE-Bench LiteとVerified、2つのリーダーボードに掲載されたデータから、その主要な特性を深掘りします。

提出者の種類：業界主導、学術機関も存在感を示す

* SWE-Bench Lite: 学術機関からの提出が多く（25%）、中小企業も存在感を示します。基礎研究や実験的なアプローチが見られます。
* SWE-Bench Verified: 企業からの提出が大幅に増加（65%）。特に大規模公開企業からの提出が目立ち、より実践的なソリューションに焦点が当てられています。
* 両方のリーダーボード: 2つのリーダーボードに重複して提出しているのは学術機関が中心で、継続的な研究開発を示唆します。

このデータから、APR技術の開発は学術研究だけでなく、産業界でも活発に進められていることがわかります。

製品の種類と可用性：実用的なツールが中心

* Publicly Available Product (PAP): 最も一般的な製品の種類で、商用ツールやオープンソースツールが含まれます。
* 開発支援ツール、クラウドプラットフォーム、Issue Resolutionツールなど、様々な種類の製品が存在し、APR技術の多様な応用を示しています。
* Under Request (UR): 要求に応じて利用可能なソリューションは、一般に公開されているものよりも高い精度を示す傾向があり、特定のニーズに特化した高度な技術が利用されている可能性を示唆します。

使用LLM：プロプライエタリモデルが主流、オープンソースも存在感

* Claude 3.5 SonnetとGPT-40: 2つのモデルが最も一般的に使用されており、高い性能を示しています。
* プロプライエタリLLM: 優れた結果を達成する傾向がありますが、オープンソースLLMも競争力のあるパフォーマンスを示しています。
* ファインチューニング: ファインチューニングされたオープンソースモデルは、透明性、再現性、適応性において利点があり、特定のタスクに合わせて最適化できる可能性があります。

オープンソースの可用性：クローズドソースソリューションの増加

* SWE-Bench Lite: オープンソースソリューションが多数を占めていますが、SWE-Bench Verifiedではクローズドソースソリューションが増加しています。
* 業界からの貢献: これは、業界がAPR技術の知的財産を保護しようとしていることを示唆している可能性があります。

数値データで見るリーダーボードの特性

* SWE-Bench Liteのエントリ数: 68
* SWE-Bench Verifiedのエントリ数: 79
* SWE-Bench Liteの中央値の解決率: 30.5%
* SWE-Bench Liteの最大解決率: 55.0%
* SWE-Bench Verifiedの中央値の解決率: 44.2%
* SWE-Bench Verifiedの最大解決率: 68.2%

これらの数値は、SWE-Bench Verifiedがより困難な問題セットを対象としていることを示唆しています。

RQ2：ソリューションアーキテクチャの詳細分析

ここでは、提出されたソリューションのアーキテクチャを深掘り、その設計思想を解き明かします。分析は、以下の3つの主要な側面から行われます。

1. ワークフローの作成方法

ソリューションがどのように問題を解決するかの手順（ワークフロー）に着目します。大きく分けて、以下の2つのカテゴリが存在します。

• 人間が設計したワークフロー: 開発者があらかじめ定義した手順に従って処理が進められます。伝統的な自動プログラム修復(APR)システムに多く見られます。
• 創発的なワークフロー: 特に定義された手順はなく、エージェントが自律的に行動し、状況に応じてタスクを実行します。

例えば、初期のSWE-Benchでは、研究者があらかじめ定義した手順でパッチを生成する

が主流でした。一方、最新のアーキテクチャでは、エージェントが自律的に行動する

も増加しています。

2. 制御フローの自律性

タスク実行におけるシステムの自由度を評価します。ここでは、以下の3つのタイプに分類されます。

• 創発的な自律性: システムが環境からのフィードバックと内部推論に基づいて、どのステップを実行するかを自律的に決定。
• Scaffolded実行: 人間が段階と段階間の移行を定義し、システムはそれらの範囲内で自由に決定。
• 固定された実行: 制御フローが完全に人間によって定義され、決定論的に実行される。

初期のシステムは

が多く、近年では

を持つシステムが増加傾向にあります。しかし、興味深いことに、

も一定の成果を上げており、人間の知識とAIの自律性のバランスが重要であることを示唆しています。

3. エージェント数

ソリューションを構成するエージェントの数に着目します。エージェント数に応じて、以下の3つのカテゴリに分類されます。

• エージェントなし: LLMに直接プロンプトを入力するソリューション。
• 単一エージェント: 1つのエージェントがすべてのタスクを実行。
• 複数エージェント: 複数のエージェントが連携してタスクを実行。

複数エージェントを使用するシステムは、複雑なタスクを分担できるため、より高度な問題解決に役立つ可能性があります。しかし、単一エージェントでも優れた結果を出している事例もあり、エージェントの数だけでなく、個々のエージェントの能力も重要であることがわかります。

アーキテクチャ分類とSWE-Benchの成果

上記の3つの側面を組み合わせることで、SWE-Benchに提出されたソリューションを以下の8つのアーキテクチャグループに分類しました。

1. Human-Workflow with Fixed execution – No Agent (G1)
2. Human-Workflow with Fixed execution – with Single Agent (G2)
3. Human-Workflow with Fixed execution – with Multiple Agents (G3)
4. Human-Workflow with Scaffolded Execution – Single Agent (G4)
5. Human-Workflow with Scaffolded Execution – Multiple Agents (G5)
6. Workflow Emergent and Emergent Autonomy – Single Agent (G6)
7. Workflow Emergent and Emergent Autonomy – Multiple Agents (G7)
8. Unclassified Submissions Due to Limited Evidence on Architectural Aspects (G8)

これらのアーキテクチャグループを分析した結果、

が高い精度を達成する傾向があることがわかりました。一方、

は精度が低い傾向にありますが、依然として多くの貢献があります（表9参照）。これは、APRシステム開発において、アーキテクチャの選択が重要な要素であることを示唆しています。

SWE-Benchリーダーボードは、APR研究におけるアーキテクチャ設計の多様性と、それぞれの設計がもたらす影響を理解するための貴重な情報源です。今後は、これらの知見を基に、より効果的なAPRシステムを開発していくことが期待されます。

RQ3：ソフトウェアメンテナンスパイプラインの実装状況

自動プログラム修復（APR）システムが、ソフトウェアメンテナンスの各段階をどのように実装しているかを深掘りします。特に、SWE-Bench LiteとVerifiedリーダーボードに提出されたソリューションを対象に、各段階でのアプローチを分析し、改善点と今後の展望を示唆します。

1. Preprocessing（前処理）

多くのシステムは、コードベースを解析し、グラフやインデックスなどの形式で表現します。これにより、コードの構造や依存関係を把握し、効率的な解析を可能にします。例：MarsCode Agentはコードとドキュメントから知識グラフを構築、OrcalocaはCodeGraphを使用してコードリポジトリをインデックス化します。

2. Issue Reproduction（問題の再現）

SWE-Benchはバグを再現するためのテストケースを提供しないため、多くのシステムはテストを生成するか、手動で作成します。LLMを活用してテストを生成するアプローチ（SWE-Agentなど）や、エージェントを使用してスクリプトを作成するアプローチが存在します。

3. Issue Localization（問題の特定）

問題のあるコード箇所を特定します。検索ベース、ナビゲーションベース、スペクトラムベースなど、様々な戦略が存在します。Aiderはリポジトリマップを使用し、LLMが編集すべきファイルを特定します。

4. Task Decomposition – Planning（タスクの分解と計画）

複雑な問題をより小さなサブタスクに分割します。LingmaAgentは、コードの要約と解決策の計画を行うエージェントを使用します。AppMap Navieは問題記述とコンテキストを組み合わせて、構造化された計画を生成します。

5. Patch Generation（パッチの生成）

特定されたコード要素に基づいて修正候補を生成します。Editor Agent（Globant Code Fixer Agentなど）やPatching Agent（SpecRoverなど）といった、パッチ生成を専門とするエージェントが活用されます。複数の候補パッチを生成し、後で評価・ランク付けを行うシステムも存在します。

6. Patch Verification（パッチの検証）

生成されたパッチの構文的・意味的な正確さを検証します。構文チェッカー（Flake8など）、リンター、テストケースなどが使用されます。SWE-agentはリンターを統合し、編集時のミスを自動的に検出します。

7. Ranking – Patch selection（ランク付けとパッチの選択）

複数の候補パッチの中から、最適なものを選択します。多数決、類似性測定、LLMのプロンプト、品質スコアリングなど、様々な戦略が用いられます。Agentlessは候補パッチを正規化し、最も頻度の高いものを選択します。

まとめ：リーダーボード分析から得られた知見と今後の展望

本記事では、SWE-Benchリーダーボードの詳細な分析を通じて、LLMとエージェントベースの自動プログラム修復（APR）システムの現状を明らかにしました。最後に、得られた主要な知見をまとめ、今後のAPR研究への貢献、そして読者の皆さまが今日から活用できる具体的なアクションについてご紹介します。

主要な知見のまとめ

• SWE-Benchリーダーボードは、APR技術の進歩を追跡する上で非常に貴重な情報源です。
• プロプライエタリLLM（特にClaude 3.5/3.7）は依然として優位ですが、オープンソースモデルも競争力を高めています。
• スクリプト化されたワークフロー（特に単一エージェント）は、高い精度を達成する傾向があります。
• 業界からの貢献がますます重要になっており、APRの実用化が進んでいることを示唆しています。

今後のAPR研究への貢献

• より厳密な評価方法を開発し、オーバーフィッティングのリスクを軽減します。
• オープンソースLLMのファインチューニングと、特定のタスクへのカスタマイズを検討します。
• エージェント間の協調性とコミュニケーションを改善する方法を研究します。
• より複雑な問題に対処できる、高度な問題ローカリゼーション技術を開発します。

読者の皆さんへのアクション

• SWE-Benchリーダーボードを定期的にチェックして、最新のAPR技術を把握しましょう。
• オープンソースAPRプロジェクトに貢献しましょう。
• APR技術を自身の開発ワークフローに統合する方法を検討しましょう。
• APR研究コミュニティに参加しましょう！

SWE-Benchは、自動修復技術の最前線を理解し、未来を形作るための貴重なツールです。リーダーボードを活用し、APR研究コミュニティに貢献することで、よりスマートで信頼性の高いソフトウェア開発の未来を共に創造していきましょう。