技術要約: REFINE – エビデンスに基づいたコード・リファクタリングのためのマルチエージェントLLMアプローチ

問題提起

大規模言語モデル（LLM）は、コード生成や変換において強力な能力を示しているが、そのソフトウェア・リファクタリングへの適用には重大な課題が伴う。効果的なリファクタリングには、コードの品質問題（コードの臭い／code smells）を軽減するためにコードを修正するだけでなく、変更によって新たな欠陥が導入されたり、外部の振る舞いが変化したり、あるいは重要な構造要素（例：パブリックAPI、アサーション）が削除されたりしないことを保証する必要がある。

現在のLLM支援型リファクタリングのアプローチは、厳格な検証に欠けることが多く、その結果、幻覚（ハルシネーション）による提案、一貫性のない変換、あるいは振る舞いに関連するコード構造の削除といったリスクを招いている。したがって、以下の事項を実現する体系的なアプローチが求められている：

1. 静的解析からのエビデンスを用いてLLMを導くこと。
2. 計画、生成、および検証を管理するマルチエージェント・ワークフローをオーケストレートすること。
3. 何が変更され、どのようなリスクが残り、出力が自動的に受け入れられるべき解決策ではなく、実行可能なリファクタリング候補であるかどうかについて、追跡可能なエビデンスを提供すること。

メソドロジー: REFINE ワークフロー

著者らは、Javaのファイルレベルのリファクタリング用に設計された、ツールに依存しないエビデンス認識型のマルチエージェント・フレームワークである REFINE (Refactoring with Evidence-aware Flow for Integrated ageNtic Execution) を導入する。本システムは、Next.jsインターフェース、静的解析（PMD 7.x）用のJava Spring Bootバックエンド、およびオーケストレーション用のPythonエージェントサービス（LangGraph v1.1を使用）を用いた研究用プロトタイプとして実装されている。

ワークフローは、主に以下の3つのステージを通じて動作する：

1. タスクの特性化 (Task Characterization)

• 入力: オープンソースプロジェクトから抽出された単一のJavaファイル。
• エビデンス収集: 静的解析（PMD）により、ファイルレベルのコードの臭いとルールレベルのエビデンスを特定する。
• コンテキスト化: システムはパブリックAPIのシグネチャ、ワークスペースのコンテキストを抽出し、検出されたコードの臭いを優先順位付けすることで、境界の定められたリファクタリング・タスクを形成する。

2. リファクタリングのオーケストレーション (Refactoring Orchestration)

ワークフローは、プロセスを管理するために11の異なる役割（エージェント）を調整する：

• プランニング・エージェント (Planning Agent): 決定論的なルールベースのガイダンスと、オプションのLLMによる洗練を組み合わせ、臭いに焦点を当てたリファクタリング計画を作成する。
• リファクタリング・エージェント (Refactoring Agent): プラン、元のソース、および制約（例：パブリックAPIの保持）に基づいて、候補となる変換を生成するためにLLMを呼び出す。
• 検証エージェント (Verification Agent): 生成された候補が保持される前に、構成されたエビデンス・チェックに対して候補を分析する。

3. 検証トレースと分析 (Verification Trace & Analysis)

REFINEは、LLMの出力を最終的なものとして扱わない。代わりに、変換されたファイルを再分析して以下を算出する：

• コードの臭いの減少: 絶対的な減少量 ($\Delta_{smell} = B - A$) および検出されたコードの臭いの相対的な改善。
• 静的保存プロキシ (Static Preservation Proxies): パブリックAPIの保存、例外処理、フレームワークの契約、条件ロジック、および重要なassert/fail呼び出しのチェック。
• 失敗の診断: 拒絶の具体的な理由（例：パブリックメソッドの削除）を記録する。
• トレーサビリティ: 元のソース、生成された候補、エージェントのステップ、メトリクス、および検証結果を永続化し、すべての決定をそのエビデンスに紐付ける。

実験設計

• データセット: コードの臭いの数と行数（LOC）に基づいた層化無作為抽出により選択された、15のオープンソースシステム（JHotDraw, Apache Ant, Guava, JabRefなど）からの450のJavaファイル。
• LLM構成: 以下の3つの最先端モデルを評価した：OpenAI GPT-5.5、Google Gemini 3.1 Pro Preview、Anthropic Claude Opus 4.8。
• 規模: これにより、1,350のモデル・パス出力が得られた。
• ベースライン: シンプルなプロンプティングに対するマルチエージェント・ワークフローを比較するため、150ファイルのサブセットに対して一致させた直接プロンプティング・ベースラインを実施した。
• メトリクス: コードの臭いの減少、品質指標（循環的複雑度、保守性指数など）、構造的変更、および保存リスク。

主な結果

1. コードの臭いの減少 (RQ1)

REFINEは、3つのLLM構成すべてにおいて、検出されたコードの臭いの大幅な減少を達成した：

• 総減少量: GPT-5.5で68.26%、Gemini 3.1で72.79%、Opus 4.8で68.49%。
• 主要な臭い: 主要なコードの臭いにおいて最も顕著な改善が見られた（86.51%から91.60%の減少）。
• 品質指標: 品質指標における改善は一様ではなかった。Gemini 3.1は循環的複雑度とLCOMの顕著な減少を示したが、他のメトリクス（保守性、テスト容易性、ハルステッドの労力）は、モデルに応じて混合または逆転した変化を示した。

2. 保存とリスク (RQ2)

• 高い合格率: ほとんどの静的保存インジケータ（パブリックメソッドのシグネチャ、例外処理、フレームワークの契約）は、高い割合（81.8%から94.2%）でパスした。
• 決定的なリスク:
  • Assert/Fail呼び出し: すべてのモデルを通じて、決定的なassert/fail呼び出しを保持できた出力はわずか57.1%であり、系統的なリスクを示している。
  • パブリックメソッドの削除: これが最も具体的な診断上の失敗であった。Gemini 3.1が最も高いパブリックメソッド削除率（71ケース）を示し、次いでGPT-5.5（41）、Opus 4.8（34）となった。

3. リファクタリングの振る舞い (RQ3)

異なるモデルは、異なる編集プロファイルを通じて臭いの減少を実現した：

• GPT-5.5: 最もコンパクトな編集を行った。
• Gemini 3.1: 「削除重視」のプロファイルを示し、最も多くの行とメソッドを削除した。
• Opus 4.8: 最も多くのメソッド抽出を行った「抽出重視」のプロファイルを示した。
• 相関関係: 編集ボリュームが大きいほど、絶対的なコードの臭いの減少量は大きかったが、必ずしも相対的な減少量が高くなるわけではなかった。

4. 直接プロンプティングとの比較

一致させた150ファイルのサブセットにおいて、REFINEは直接プロンプティングと比較して以下の点で優れていた：

• コードの臭いの減少: 中央値の総減少量は、REFINEが100.0%に対し、直接プロンプティングは20.8%であった。
• 編集フットプリント: 中央値のチャーン（変更量）が小さかった（14 LOC vs. 65 LOC）。
• APIの安全性: パブリックメソッドの削除が少なかった（46ケース vs. 112ケース）。
• トレードオフ: 直接プロンプティングの方が、決定的なassert/fail構成をより多く保持していた（100% vs. 58%）。

意義と主張

本論文は、REFINEを、振る舞いを保存するリファクタリングツールの代替としてではなく、追跡可能でエビデンスを認識した、リファクタリング候補を生成および評価するためのメカニズムとして位置付けている。

• エビデンス認識: 主要な貢献は、生成されたコードを、その変更を動機付けた特定の静的エビデンス（臭い）および、それがパスしたか失敗したかの検証チェックに紐付けることである。
• 制御された生成: マルチエージェント・ワークフローは、直接プロンプティングよりも制御された候補生成を提供し、その結果、編集量は小さくなり、偶発的なAPI削除も少なくなっている。ただし、すべての振る舞いのリスクを排除できるわけではない。
• 限界: 著者らは、生成された出力はあくまで候補であり、本番環境で使用可能なリファクタリングではないことを明示している。静的保存チェックはプロキシ（代理指標）であり、振る舞いの等価性を証明するものではない。
• 実用的な意味合い: 生成された候補は、特に依存関係が豊富な環境やシステムレベルの設定においては、採用前にコンパイル、テスト、依存関係分析、および人間によるレビューを必要とする。

本研究は結論として、エビデンス認識型のマルチエージェント・ワークフローは、ターゲットを絞ったファイルレベルのコードの臭い軽減において有望であるが、直接プロンプティングもマルチエージェント・アプローチも、複雑なソフトウェアエコシステムにおいて自律的に動作するために十分な、完全な振る舞いの保存に関するエビデンスを現在提供できていないとしている。