Each language version is independently generated for its own context, not a direct translation.
この論文は、**「SWE-Adept（ソフトウェア・エーデプト）」**という、人工知能（AI）がソフトウェアのバグ（不具合）を見つけて直すための新しい仕組みについて紹介しています。
従来の AI は、短いコードを書くのは得意ですが、何千ものファイルからなる巨大なプロジェクト（例：Twitter や Amazon のような大規模なシステム）の「どこに問題があるか」を見つけたり、複雑な修正を加えたりするのは苦手でした。
SWE-Adept は、この問題を解決するために、**「2 人の専門家のチーム」**として働くように設計されています。
🕵️♂️ 1. 問題の場所を探す「探偵（ローカライゼーション・エージェント）」
まず、巨大な図書館（コードベース）の中で、どこに「壊れた本」があるかを探す必要があります。
- 従来の AI の問題点:
従来の AI は、図書館のすべての本を一度に読み始めようとして、パンクしてしまったり、関係のない本まで読みすぎて「どこに問題があるか」を見失ったりしていました。
- SWE-Adept のアプローチ（エージェント主導の深さ優先探索）:
SWE-Adept の「探偵」は、「必要な本だけ、必要な順番で」探すという戦略を使います。
- アナロジー: 図書館の図書を検索する際、いきなりすべての本を棚から出すのではなく、「この本には『A』という章があり、その章には『B』という関連本がリンクされている」という**「本の目次とリンク」**を頼りに、問題に関連しそうな本だけを選んで深く掘り下げていきます。
- 2 段階のフィルタリング:
- まず目次だけ見る: 本の中身（全テキスト）を読む前に、表紙と目次（コードの構造）だけを見て、「これっぽい」という候補を絞り込みます。
- 中身を詳しく読む: 絞り込んだ候補だけの中身を詳しく読み、本当にそこが原因かを確認します。
- 効果: これにより、AI の記憶容量（コンテキスト）を無駄に使わず、正確に「バグの場所」を特定します。
🔧 2. 問題を直す「職人（リゾルーション・エージェント）」
場所が特定できたら、次は実際に修理をする番です。
- 従来の AI の問題点:
従来の AI は、ひたすら「考えて、直して、テストして、失敗したらまた直して…」を繰り返すのですが、**「どこまで直したか」「失敗した修正をどう元に戻すか」**の管理が雑でした。そのため、修正を重ねるほどにコードがぐちゃぐちゃになり、元の状態に戻れなくなることがありました。
- SWE-Adept のアプローチ（構造化された解決とチェックポイント）:
SWE-Adept の「職人」は、**「作業メモ」と「バージョン管理」**を徹底します。
- アナロジー（修理屋さんの作業）:
- 仮説を立てる: 「A という部品が壊れているから、B に交換しよう」という**仮説（Hypothesis）**を立てます。
- 作業リスト（To-Do）: 「部品を外す」「新しい部品を付ける」「テストする」といった作業リストを作成します。
- チェックポイント（Git）: 作業を一つ終わるたびに、**「今の状態を写真に撮って保存（チェックポイント）」**します。
- 分岐と戻り: もし「B に交換したら、別の部品が壊れてしまった！」という失敗をしたら、**「前の写真（チェックポイント）に戻って、別の修理方法（別の仮説）を試す」**ことができます。
- 効果: 失敗しても「元に戻せる」ため、AI は恐れずに大胆に試行錯誤できます。また、複数の修理方法を並行して試して、最も良いものを選ぶことができます。
🏆 結果：なぜこれがすごいのか？
この「探偵」と「職人」のチームワークにより、SWE-Adept は以下の成果を上げました。
- 正確な場所特定: 従来の方法より、バグの場所を特定する精度が大幅に向上しました（最大 5.4% の改善）。
- 成功する修理: 最終的に問題を解決できる割合も上がり、最大 4.7% 向上しました。
- 効率化: 無駄な情報を読み飛ばすため、AI が使う計算リソース（トークン数）も抑えられています。
📝 まとめ
この論文が言いたいことは、**「AI に『巨大なプロジェクトのバグを直す』という仕事を任せるなら、ただ『考えて直す』だけではダメだ。『場所を慎重に探す探偵』と『失敗しても元に戻せるように管理する職人』という、役割を分けたチームが必要だ」**ということです。
SWE-Adept は、この 2 つの役割を明確に分け、それぞれに最適なツール（検索方法やバージョン管理）を与えることで、AI が人間のように複雑なソフトウェア開発を支援できる可能性を大きく広げました。
Each language version is independently generated for its own context, not a direct translation.
SWE-Adept: 大規模言語モデル（LLM）に基づく自律的エージェントフレームワークによる深層コードベース分析と構造化問題解決
本論文は、大規模なソフトウェアリポジトリにおける課題（Issue）の特定から修正までのエンドツーエンドな解決を目的とした、LLM ベースの新しいエージェントフレームワーク「SWE-Adept」を提案しています。既存の手法が抱える「コンテキスト管理の非効率性」と「体系的な問題解決戦略の欠如」という課題に対し、2 つの専門化されたエージェントと、高度なバージョン管理メカニズムを導入することで、大幅な性能向上を実現しています。
以下に、論文の主要な内容を技術的に要約します。
1. 背景と課題 (Problem)
大規模言語モデル（LLM）は単独の関数やファイルレベルのプログラミングタスクでは高い性能を示しますが、実世界のソフトウェアエンジニアリング（SWE）課題、特に大規模リポジトリレベルのデバッグにおいては以下の 2 つの主要な課題に直面しています。
- コードベースの深層ナビゲーションとコンテキスト管理の難しさ
- リポジトリは数千ファイルに及ぶことが多く、LLM のコンテキストウィンドウ制限を超えます。
- 既存の手法は、問題に関連しないコードを過剰にコンテキストに読み込んでしまい、局所化（Localization）の精度を低下させます。
- 依存関係の追跡において、広範囲な探索（BFS 的アプローチ）を行うことで、無関係なパスが混入し、非効率になっています。
- 体系的な問題解決と状態管理の欠如
- 既存のエージェントは「思考と編集（Think-and-Edit）」のループに依存しており、計画性や進捗管理が不十分です。
- 反復的な修正を行う際、中間状態（チェックポイント）を体系的に記録・管理するメカニズムが不足しています。
- 失敗した修正を元に戻したり、代替案を並行して探索したりするバージョン管理操作が、エージェントにとって信頼性高く実行できません。
2. 提案手法：SWE-Adept (Methodology)
SWE-Adept は、**「局所化エージェント（Localization Agent）」と「解決エージェント（Resolution Agent）」**という 2 つの専門化されたエージェントで構成される 2 段階のフレームワークです。両者は独立したコンテキストウィンドウとツールセットを持ち、連携して動作します。
2.1 コードベースの表現とインデックス化
- 定義レベルのインデックス化: Tree-sitter を使用して、関数やクラス定義を最小単位（Code Unit）として抽出します。残りのコードは固定長（200 行）でチャンク化します。
- コード構造ツリーの構築: 各コードユニット間の「含む（Contains）」や「呼び出す（Invokes）」関係を有向エッジとして定義し、依存関係に敏感な探索を可能にする木構造を構築します。
- 軽量なメタデータ: 各ノードに軽量な隣接リスト（子ユニットの識別子）を保持し、探索時にフルファイルを読み込まずに構造情報のみを取得できるように設計されています。
2.2 局所化エージェント (Issue Localization)
問題の根本原因となるコード位置を特定する役割です。
- エージェント主導の深さ優先探索 (Agent-directed DFS):
- 問題記述から抽出したエントリポイントから開始し、
find_child_unit ツールを用いて依存関係ツリーを深さ優先で探索します。
- 探索中は、フルコードではなく「コードスケルトン/プレビュー」と「位置メタデータ」のみを取得し、コンテキスト消費を最小化します。
- エージェントが問題に関連ないと判断したパスは即時に停止し、他の候補パスへ移動します。
- 2 段階フィルタリング:
- 第 1 段階: スケルトン情報と位置ヒューリスティクスを用いて候補を絞り込み、ランク付けします。
- 第 2 段階: 絞り込まれた候補のみに対してフルコードを読み込み、実装内容に基づいて再評価・再ランク付けを行い、最終的な局所化結果を出力します。
2.3 解決エージェント (Issue Resolution)
特定されたコード位置に基づき、修正を実装し検証する役割です。
- 構造化された問題解決:
- 複数の仮説（Hypothesis）を立て、それぞれに対して微細な「To-Do リスト」を動的に計画します。
- テスト失敗などのフィードバックに基づき、To-Do リストを適応的に拡張します。
- ツールとメモリインターフェース:
hypothesis_plan: 仮説、To-Do リスト、実行ステータス、洞察（Insights）を管理します。hypothesis_git: Git ベースのバージョン管理を抽象化した CLI ツール群です。
- チェックポイント管理: 各 To-Do の完了後にコード状態をコミットし、そのメタデータ（Git ハッシュ）を共有ワークメモリに格納します。
- 分岐（Branching）: 異なる仮説を並行して探索するために、独立したブランチを作成します。
- ロールバック（Reverting）: 失敗した仮説の後のステップを、適切な過去のチェックポイント（To-Do 単位）に戻して巻き戻し、新しいブランチで探索を継続できます。
- 最終統合: 全ての仮説を評価し、最も成功したブランチを元のコードベースにマージしてパッチを提出します。
3. 主要な貢献 (Key Contributions)
- SWE-Adept フレームワークの提案:
- 正確な局所化と体系的な解決を統合した、自律的なリポジトリレベルのソフトウェア問題解決フレームワーク。
- エージェント主導の探索と 2 段階フィルタリング:
- 依存関係に誘導された深さ優先探索と、コンテキスト効率を重視した 2 段階フィルタリングにより、問題に関連するコードを高精度に特定します。
- ツール - メモリインターフェースによるバージョン管理:
- 共有ワークメモリと Git ベースのツールを連携させることで、エージェントが自律的にチェックポイントを管理し、長期にわたる体系的な問題解決（分岐、ロールバック、代替案の比較）を可能にしました。
4. 実験結果 (Results)
SWE-Bench Lite および SWE-Bench Pro（より複雑な課題を含む）のベンチマークで評価されました。
- 局所化精度:
- 関数レベルの局所化精度（Func Acc@5）において、最良のベースライン（OrcaLoca など）を 5.4%（GPT-5.2 使用時）上回りました。
- 不要なコンテキストを排除しているため、グラフベースの手法と比較してトークン消費量も削減されています。
- エンドツーエンドの解決率:
- SWE-Bench Pro において、解決率（Resolve Rate）を最大 4.7% 向上させました。
- 複雑な課題（多数の仮説探索が必要なケース）においても、他の手法よりも高いロバスト性を示しました。
- アブレーション研究:
- 局所化エージェントと解決エージェントの両方が性能向上に寄与していることが確認されました。
- 生（Raw）の Git コマンドを直接使用する設定では、長期タスクにおけるエラー発生率が高く、提案する
hypothesis_git ツールによる抽象化とメモリ管理の重要性が示されました。
5. 意義と結論 (Significance)
SWE-Adept は、単なるコード生成や修正を超えて、**「深いコード理解」と「体系的な状態管理」**を両立させることで、自律的なソフトウェアエンジニアリングの新たな基準を示しました。
- コンテキスト管理の革新: 大規模リポジトリにおいて、LLM のコンテキスト制限を克服しつつ、必要な情報のみを効率的に取得する手法を実証しました。
- 自律的なバージョン制御: エージェントが失敗から回復し、複数の解決策を体系的に比較・評価するためのメカニズムを提供し、長期的なタスク遂行能力を大幅に向上させました。
- 将来展望: 現在は Python コードベースに限定されていますが、フレームワーク自体は言語非依存であり、他の言語への拡張やオープンソースモデルへの適用が今後の課題として挙げられています。
本論文は、LLM を活用したソフトウェア開発の自動化において、単発的なタスク処理から、複雑なリポジトリ全体を扱う自律的なエージェントシステムへの進化を促す重要な一歩となっています。