Resolving Java Code Repository Issues with iSWE Agent

本論文は、ルールベースの静的解析と変換ツールを活用した2段階のアプローチにより、Java における自動課題解決の最先端性能を達成する「iSWE Agent」を提案し、企業向けソフトウェア開発の効率化に貢献するものである。

要約

この論文は、**「Java というプログラミング言語で書かれたソフトウェアのバグ（不具合）を、AI が自動で直す新しい仕組み『iSWE アージェント』」**を紹介するものです。

これまでの AI によるバグ修正研究は、主に「Python」という言語に特化しており、その分野では AI が非常に上手にバグを直せるようになっていました。しかし、企業のシステムで最も多く使われている「Java」では、まだ AI の性能が低く、研究も進んでいませんでした。

この論文は、**「Java 専用の『道具』を持たせた AI なら、もっと上手に直せるはずだ！」**という仮説を検証し、見事に成功させたことを報告しています。

以下に、専門用語を排し、身近な例え話を使って解説します。

---

🏗️ 物語：大工と職人のチーム

このシステムは、**「2 人の職人（エージェント）」**で構成されたチームとして考えると分かりやすいです。

1. 探偵役（ローカライゼーション・エージェント）

• 役割: 「どこにバグがあるか」を見つけること。
• 特徴: この職人は、**「読んではいけない（書き換え禁止）」**というルールを持っています。
  • 彼らは巨大な図書館（コードベース）を歩き回り、Java 特有の「本棚の配置ルール（静的解析ツール）」を使って、バグの場所を特定します。
  • 「あ、この本（ファイル）の 3 行目と、向かいの棚の 5 行目に問題がありそうだ！」と、**「直すべき場所のリスト」**だけを作成して、次の職人に渡します。
  • ポイント: 彼らは実際に本を触ったり書き換えたりはしません。だから、間違った場所を触って本を破損するリスクがありません。

2. 修理職人（エディティング・エージェント）

• 役割: 「探偵が見つけた場所」を実際に直すこと。
• 特徴: この職人は、**「作業場（コンテナ）」**という安全な部屋で働きます。
  • 探偵から渡された「直すべき場所リスト」を見て、その部分だけを切り取り、新しい部品に交換します。
  • 作業が終わると、その部屋で「完成品が壊れていないか」を即座にチェックします（Java コンパイラによるチェック）。もし失敗したら、部屋の中でやり直し。
  • ポイント: 彼らは「安全な部屋」の中でしか作業しないため、元の図書館（サーバー）に悪影響を与えることがありません。

---

🛠️ なぜ「Java 専用」なの？（Python との違い）

これまでの AI は、Python 向けの「万能な道具」を使っていました。しかし、Java は Python とは全く違う性質を持っています。

• Python の場合: 「文法チェック（リンター）」という道具を使えば、多くの間違いがすぐにバレます。
• Java の場合: 文法チェックだけでは不十分です。Java は「型（データの形）」が厳格で、複雑な「クラス（部品）」の関係性を持っています。
  • 例え話: Python のバグ修正が「簡単なパズル」だとしたら、Java のバグ修正は「複雑な機械の組み立て」です。
  • 従来の AI は、この「複雑な機械」の仕組みを知らないので、間違った場所を触ってしまったり、必要な部品を見逃したりしていました。

iSWE の工夫:
このシステムは、Java の構造を深く理解できる**「Java 専用の道具」**（例：「このクラスは誰に呼ばれているか？」「このメソッドの親は誰か？」を瞬時に調べる道具）を使っています。これにより、Python 向けに作られた AI よりも、はるかに正確にバグの場所を特定し、修正できるようになりました。

---

📊 結果：どんなにすごいのか？

実験では、2 つの有名なテスト（Multi-SWE-bench と SWE-PolyBench）の「Java 版」で iSWE を試しました。

1. 成功率: 現在、Java のバグ修正で最も高い成功率を記録しました（トップクラス）。
2. コスト: 従来の AI よりも、2〜3 倍安くバグを直すことができました。
   • 理由: 無駄な試行錯誤（AI が何度も考え直すこと）が減ったからです。Java 専用の道具があるおかげで、AI は「迷わずに」正しい場所へたどり着けるのです。
3. 安全性: 間違った修正をしてシステムを壊すリスクが極めて低いです。

---

💡 まとめ：何が新しいのか？

この論文の核心は、**「AI に『言語ごとの専門知識』と『安全な道具』を持たせること」**です。

• 従来の考え方: 「どんな言語でも、AI がコードを書けばいい（何でもできる万能 AI）」
• iSWE の考え方: 「Java には Java 特有のルールがある。だから、Java 専門の『探偵』と『修理職人』に、Java 専用の道具を持たせてあげよう」

このアプローチにより、企業の重要なシステム（多くは Java で作られています）のメンテナンスを、AI がより安全に、安く、効率的に行える未来が近づいたと言えます。

一言で言えば：
「Java という『難しい言語』のバグを直すために、AI に『専門知識』と『安全な道具』を与えたら、驚くほど上手に、安く直せるようになったよ！」というお話しです。

技術概要

論文「Resolving Java Code Repository Issues with iSWE Agent」の技術的サマリー

この論文は、大規模言語モデル（LLM）とエージェント技術を用いたコードリポジトリの課題解決（Issue Resolution）において、Python 中心の既存研究から脱却し、**Java 向けに特化した自動化システム「iSWE Agent」**を提案したものです。企業ソフトウェアの多くが Java で記述されているにもかかわらず、Java における自動課題解決の研究は未発展であったため、このギャップを埋めることを目的としています。

以下に、問題定義、手法、主要な貢献、結果、および意義について詳細にまとめます。

---

1. 問題定義 (Problem)

• 背景: 近年、LLM とエージェントを用いた自動課題解決システム（例：SWE-bench）は Python 分野で高い性能を示していますが、他の言語、特に Java への適用は限定的です。
• 課題:
  • 言語特性の違い: Java は Python と異なり、構文、型システム、オブジェクト指向の重視度において大きく異なります。また、コンパイル言語であるため、静的型チェックやライブラリ依存関係の管理が必須であり、Python のような単純なリント（Lint）ツールだけではエラー検出が不十分です。
  • 既存手法の限界: 既存のエージェントは汎用的なシェルコマンドや単純なファイル操作ツールに依存しており、Java 特有の複雑なコード構造（多ファイル編集、深いクラス階層など）やコンパイルエラーの検出に不向きです。
  • コストと安全性: 任意のコード実行をサンドボックス内で行うと、オーバーヘッド（時間、メモリ、コスト）が増大し、安全性も脅かされます。

2. 手法 (Methodology)

iSWE Agent は、**「ルールベースの静的解析」と「モデルベースの推論」**を組み合わせ、Java 固有の知識を活用した 2 段階のアプローチを採用しています。

2.1 アーキテクチャ：2 つのサブエージェント

課題解決プロセスを「局所化（Localization）」と「編集（Editing）」の 2 つの ReAct エージェントに分解しています。

1. ローカライゼーションエージェント (Localization Agent):
   • 役割: 課題記述（Issue Description）と既存コード（$c_{old}$）を分析し、修正が必要なコードの位置（ファイル、クラス、メソッドなど）を特定します。
   • ツール: Java 固有の静的解析ツール（CLDK, Tree-Sitter 基盤）を使用。
     • get_file_info, get_class_info, get_method_info など（ノード情報の取得）。
     • get_inheritance_hierarchy, get_function_callers など（エッジ情報の取得）。
   • 特徴: これらのツールは**読み取り専用（Read-only）**であり、システムへの副作用を排除しています。LLM はこれらのツールを呼び出して文脈を構築し、修正候補の位置を JSON 形式で出力します。
2. 編集エージェント (Editing Agent):
   • 役割: 局所化エージェントが特定した位置に基づき、実際にコードを修正し、新しいバージョン（$c_{new}$）を生成します。
   • ツール: 検索 - 置換（Search-Replace）形式の編集ツールを使用。
   • 検証プロセス:
     1. 編集コマンドの構文チェック（マージコンフリクト形式）。
     2. 簡易的な Java リントチェック（副作用なし）。
     3. コンテナ化された環境でのコンパイル: 依存関係を含む Java コンパイラを実行し、構文エラーや型エラーを検出。この部分のみサンドボックス内で実行され、ホスト環境への影響を隔離します。

2.2 実装技術

• PDL (Prompt Description Language): プロンプトテンプレートと制御ロジックを宣言的に記述する言語を使用し、コンテキストの蓄積や型チェックを自動化。
• モデル非依存性: 特定の LLM に依存せず、設定変数としてモデルを切り替え可能。
• インライン処理: 思考（Chain-of-Thought）やツール呼び出しを API 応答フィールドではなく、メインコンテンツ内に生成させる方式を採用し、異なるモデル間での堅牢性を確保。

3. 主要な貢献 (Key Contributions)

1. Java 特化型エージェントの初出: 課題解決に特化した最初の Java 専用エージェント「iSWE」の導入。
2. 言語意識型ツールの有効性の証明: 汎用的なツールではなく、Java の静的解析に基づいた高度なツールを使用することで、エージェントの性能向上とコスト削減が可能であることを示した。
3. 包括的な評価: 以前はあまり研究されていなかった Java 向けベンチマーク（Multi-SWE-bench と SWE-PolyBench）を用いた大規模な実験と、ベンチマーク自体の特性に関する洞察の提供。

4. 結果 (Results)

Multi-SWE-bench (Java) と SWE-PolyBench (Java) における評価結果は以下の通りです。

• 解決率 (Resolution Rate):
  • Frontier Models (Claude-4.5-Sonnet など): 両ベンチマークで最高レベルの解決率を達成（Multi-SWE-bench で 43%、SWE-PolyBench で 55%）。
  • オープンソースモデル: DeepSeek-V3-2 や Llama-4-maverick 等でも、Python 向けエージェントに匹敵する、あるいはそれ以上の性能を発揮。
• コスト効率:
  • 同じ LLM（例：Claude-3.7-Sonnet）を使用した場合、iSWE は他のトップエージェント（InfCode, MSWE-agent など）と比較して、モデル推論 API コストを 2〜3 倍削減しました。
  • これは、高度なツールにより LLM のターン数（会話回数）とトークン消費を大幅に減らしているためです。
• 局所化精度:
  • ファイルレベルの検索精度は高く、ノードレベル（クラス/メソッド）でも良好な結果を示しました。
  • 局所化の精度が最終的な解決率と強く相関していることが確認されました。
• ツール比較:
  • Bash コマンドや既存の低レベルツール（SWE-Agent のツール等）と比較し、iSWE の Java 特化ツールを使用した場合、ターン数が少なく、不要なトークンも少ないため、コストと精度のバランスが最適でした。

5. 意義と結論 (Significance & Conclusion)

• 企業ソフトウェア開発への貢献: Python 中心の研究から、実世界で広く使われている Java などの企業向け言語への知見の拡張に寄与しました。
• ハイブリッドアプローチの優位性: 大規模言語モデルの推論能力と、言語固有のルールベース解析（静的解析）を組み合わせることで、安全性（副作用の排除）、コスト効率、精度を同時に達成できることを実証しました。
• 今後の展望: 現在はテスト実行フィードバックやモデルのファインチューニングを行っていませんが、これらを将来的に統合することで、さらに解決率を向上させる余地があると結論付けています。

総じて、iSWE Agent は、言語固有の知識をツールとして取り込むことで、LLM エージェントの限界を克服し、実用的なソフトウェア工学タスクにおいて高い効率と精度を実現する新しいパラダイムを示した重要な研究です。