技術要約: SWE-Refactor

問題提起

大規模言語モデル（LLM）はコード生成において顕著な能力を示しているが、コードのリファクタリングは特有の課題を提示する。リファクタリングには、プログラムの振る舞いを変えることなく構造を改善するために、正確かつ意味を保存する編集が求められる。このタスクは、リポジトリレベルの推論、複雑な依存関係の理解、および反復的な検証を必要とするが、これらは現在のモデルにとって評価が困難であり、しばしばその能力を超えている。

既存のリファクタリング用ベンチマークは、以下の4つの決定的な欠点に苦しんでいる：

1. シナリオの網羅性の限定: これらは主にアトミックなリファクタリング型（単一の変換）に焦点を当てており、現実の開発で一般的な複合リファクタリング（複数の調整された変換）には対応していない。
2. 自動構築の欠如: 多くのベンチマークは手動によるキュレーションやLLMによって生成されたグラウンドトゥルース（正解）に依存しており、バイアスやスケーラビリティの問題を引き起こしている。
3. リポジトリレベルのコンテキストの不足: 既存のデータセットは、現実的な評価に必要な構造的情報（例：クラス階層、コーラー/カレの関係）を欠いていることが多い。
4. ノイズの多いデータ: 多くのベンチマークには、リファクタリングがバグ修正や機能追加と混在している「不純な」コミットが含まれており、モデルのリファクタリング能力を分離して評価することを困難にしている。

さらに、この分野はプログラミング言語の多様性の欠如にも直面しており、最近のベンチマークの多くは、Javaがエンタープライズシステムにおいて支配的な言語であるにもかかわらず、Pythonのみに焦点を当てている。

手法: SWE-Refactor

これらのギャップに対処するため、著者らは実世界のJavaプロジェクトから構築されたリポジトリレベルのベンチマークであるSWE-Refactorを導入する。このベンチマークは、完全に自動化された4ステップのパイプラインを使用して構築されている：

1. 静的解析によるマイニング: 著者らは、ASTベースのツールであるRefactoringMinerを活用し、18の広く使用されているJavaプロジェクトからリファクタリングを含むコミットを抽出する。
2. 純粋なリファクタリングのキュレーション: PurityChecker（RefactoringMinerの拡張）を使用して、不純な変更（例：バグ修正）をフィルタリングし、「純粋な」リファクタリングのみを保持する。著者らは、検出器の信頼性を確認するために、ランダムに選ばれた200のインスタンスを手動で検証した。
3. マルチレベル情報の付加: リポジトリレベルの推論をサポートするため、パイプラインはEclipse JDTを使用して、プロジェクト構造、完全なクラス本体、メソッドのコーラー/カレ、およびビルド構成を含む包括的なコンテキストを抽出する。
4. 検証: パイプラインは、適切なJDKバージョンでプロジェクトをコンパイルし、フルテストスイート（JaCoCoを使用）を実行して、リファクタリングが振る舞いを保持していることを確認することで、機能的な正当性を保証する。

データセットの構成:

• 規模: 1,099の開発者による記述された、振る舞いを保存するリファクタリング。
• ソース: 18の多様なJavaプロジェクト。
• タイプ: 922のアトミックなインスタンスと177の複合的なインスタンスを含む。
• リファクタリング型: 3つのアトミックな型（Extract Method, Move Method, Inline Method）と、3つの複合的な型（Extract and Move, Move and Inline, Move and Rename）をカバー。

評価指標:
本ベンチマークは、以下の2つの次元でLLMの性能を評価する：

1. 機能的正当性: コンパイルの成功、テスト通過率、およびASTベースのリファクタリング検証（意図した変換が行われ、予期しない副作用が発生していないことを確認するためにRefactoringMinerを使用）によって測定される。
2. 人間らしさ: 開発者が記述したグラウンドトゥルースとの類似性を評価するために、CodeBLEUを用いて測定される。

主な貢献

1. SWE-Refactor ベンチマーク: 18のJavaプロジェクトから得られた1,099の高品質な純粋リファクタリングを含む新しいデータセット。アトミックおよび複合的な変換の両方をカバーしている。これは、Javaのための包括的なリポジトリレベルのコンテキストと自動検証を提供する初めての試みである。
2. 自動構築パイプライン: 実世界の、リファクタリングを抽出し、純粋性をフィルタリングし、構造データを付加し、手動の注釈やLLM生成のグラウンドトゥルースなしに正当性を検証する、再現可能な4ステップのパイプライン。
3. 包括的な評価: さまざまなリファクタリング型とプロンプティング戦略（Simple Prompting, RAG, Multi-Agentワークフロー）にわたって、9つの広く使用されているLLM（GPT-4o-mini、DeepSeek-V3、および各種CodeLLaMa/Qwenバリアントを含む）に対する広範な評価。

実験結果

著者らは9つのLLMを1,099のインスタンスに対して評価した。主な知見は以下の通りである：

• 全体的なパフォーマンス: 汎用モデルは、オープンソースのコード特化型モデルを上回った。DeepSeek-V3が最も高い成功率（41.58%）を達成し、次いでGPT-4o-mini（39.85%）となった。CodeLLaMa-7Bのようなオープンソースモデルの成功率はわずか1.10%であった。
• アトミック vs 複合: モデルは、複合リファクタリング（クロスファイル、マルチステップの変換）よりも、アトミックなリファクタリング（ローカルな編集）において大幅に高い性能を示した。
  • DeepSeek-V3はExtract Methodにおいて優れた性能を発揮した（301件の成功）。
  • GPT-4o-miniは、Move Methodのようなクロスファイルタスクにおいてより広い汎用性を示した（92件の成功）。
  • オープンソースモデルは、複合型に対してほぼ完全に苦戦した。
• 高度な手法の影響:
  • マルチエージェント・ワークフロー: 開発エージェント（Developer Agent）とレビューエージェント（Reviewer Agent、GPT-4o-miniを使用）を用いたワークフローは、最も高い全体的な成功（579インスタンス）を達成し、特に複雑な複合リファタリングにおいて、単純なプロンプティングや検索拡張生成（RAG）を大幅に上回った。
  • エージェンティック・スキャフォールディング (OpenAI Codex): 強力なエージェント（GPT-5.1-Codex）であっても、複合インスタンスに対してはわずか39.4%の成功率しか達成できず、アトミックなインスタンスの82.6%と比較して、マルチステップで厳格な制約のある変換がいかに困難であるかを浮き彫りにした。

意義と主張

本論文は、SWE-Refactorをソフトウェアエンジニアリングのベンチマークにおける必然的な進化として位置づけている。その意義は以下の点にある：

• リアリズム: 実プロジェクトの開発者によるコミットを使用することで、合成データやLLM生成のベンチマークに関連するバイアスやハルシネーションを回避している。
• 複雑性: アトミックなリファクタリングと複合的なリファクタリングの間のギャップを明示的にターゲットとしており、リポジトリレベルの推論能力に対する厳格なテストを提供している。
• 言語の多様性: 強固なJavaベンチマークを提供することで、現在のPython中心の文献におけるバイアスに対処しており、大規模なエンタープライズシステムで使用される言語を反映している。
• 信頼性: 自動化されたパイプラインにより、グラウンドトゥルースが振る舞いを保存しており、かつ構造的に正しいことが保証されており、将来の研究のための信頼できる標準を提供している。

著者らは、LLMはコード生成において有望な兆しを見せているものの、複雑な複合リファクタリングタスクにおいては依然として大きな課題に直面していると結論付けており、現在のエージェンティックなフレームワークは、人間の監視なしではマルチステップのソフトウェア保守においてまだ信頼できるレベルには達していないことを示唆している。