技術要約：Prefactory – ライブラリ採用リファクタリングの自動発見と適用

問題提起

ライブラリ採用リファクタリングとは、手書きのコード実装を既存のライブラリAPI呼び出しに置き換える作業である。この手法は、コードサイズを縮小し、慣用的な品質を向上させ、十分にテストされた実装を活用できる。しかし、以下の理由により、このプロセスを自動化することは困難である：

1. 明示的な手がかりの欠如： 元の手書きコードは、ターゲットとなるライブラリや特定のAPIに言及していないことが多く、インポート文や直接的な参照に依存するツールでは、機会を見つけるのが難しい。
2. 構文の多様性： 開発者は、多様な方法（異なる変数名、制御フロー、またはヘルパー関数）で同じ機能を実装するため、固定された構文パターンやリンターのルールでは汎用化できない。
3. 既存のアプローチの限界：
   • 静的ツール： RuffやPylintなどのリンターやモダナイザーは、手動で指定された精密なパターンに対してのみ効果的である。
   • LLMエージェント： 大規模言語モデル（LLM）は多様なパターンに汎用化できるが、繰り返しのプロンプティングを通じてコードベース全体をスキャンさせることは、コストが高く、再現が困難であり、大規模なスケールでの系統的な制御も難しい。

核心となるボトルネックは検出である。すなわち、ライブラリへの明示的な言及がない状況で関連するコード領域を見つけ出し、固定されたテンプレートを超えて汎用化し、その上で振る舞いを維持したまま置き換えを行うことである。

手法：Prefactoryパイプライン

Prefactoryは、LLMのセマンティックな知識を決定論的で再利用可能な検索メカニズムに変換するために設計された、4段階の自動パイプラインである。これはターゲットプロジェクトとターゲットライブラリ名に対して動作する。

ステージ1：検出器の生成（Detector Generation）

LLMにコードを直接スキャンさせるのではなく、PrefactoryはLLMを使用して実行可能な検出器を合成する。

• 入力： ターゲットライブラリのメタデータ（PyPI、ドキュメント、および過去のリファクタリングからマイニングされた例）と、プロジェクトの語彙（ターゲットプロジェクトにおける頻出名称）。
• 出力： 2種類の検出器ファミリー：
  1. レキシカル検出器（Lexical Detectors）： ドメイン用語、API関連の名称、および手書きの実装に関連するテキストパターンに一致する正規表現。
  2. 構造的検出器（Structural Detectors）： 特定の変数名に関わらず、アルゴリズムの形状（例：値のループ、算術的なインデックス計算、データ構造への蓄積）を特定するAST（抽象構文木）マッチャー。
• 検証： 生成された検出器は、コンパイル可能であり、クラッシュせず、かつ過度に広範な一致（例：20%以上のファイルを一致させる）を生成しないようにフィルタリングされる。

ステージ2：プロジェクトスキャン（Project Scanning）

このステージは決定論的であり、LLMを使用しない。

• Prefactoryは、非ソースファイル（例：ベンダーコード、テスト、ドキュメント）を除外する。
• 検証済みのレキシカルおよび構造的検出器を、残りのソースファイルに対して実行する。
• 一致箇所を記録し、候補となるファイルと関数、およびフラグを立てる原因となった特定の検出器の一致を特定する。

ステージ3：候補のランキングとフィルタリング（Candidate Ranking and Filtering）

LLMのコストを管理するため、Prefactoryは候補をランク付けし、書き換えのための小さなサブセットを選択する。

• ランキング指標： 各候補 $c$ に対して、タプル $(D(c), B(c), -S(c))$ が計算される：
  • $D(c)$: 検出器の一致強度（構造的一致を優先した加重和）。
  • $B(c)$: 手書きのロジックを示す基本的なPython実装パターン（ループ、算術、分岐）の密度。
  • $S(c)$: 候補のサイズ（小さい方が好ましい）。
• 選択： 上位5つのファイルが選択され、その中の上位10個の関数が次のステージのために選ばれる。

ステージ4：リファクタリングの生成と検証（Refactoring Generation and Validation）

• 生成： LLMに対し、候補となる関数、周囲のコンテキスト、ターゲットライブラリAPIのヒント、および特定の検出器の一致内容をプロンプトとして与える。LLMはターゲットライブラリを使用して関数を書き換えることを試みる。
• 関連性フィルタリング： ASTベースのチェックにより、編集が実際にターゲットライブラリを呼び出しているか、また単なる外見上の変更ではないかを確認する。
• 検証：
  1. 差分テスト（Differential Tests）： LLMは、生成された入力を用いて、元の関数をオラクル（正解）として比較するスタンドアロンのテストスクリプトを生成する。テストが失敗した場合、LLMは編集の修正を試みる（最大3回まで）。
  2. プロジェクトテスト： 差分テストが通過した場合、リファクタリングされたコードをプロジェクトの既存のテストスイートに対して実行し、退行（リグレッション）がないことを確認する。

主な貢献

1. PrefactoryBench： 61のオープンソースPythonプロジェクトと18のライブラリから抽出された、100の現実世界のライブラリ採用リファクタリングのベンチマーク。これには、検出と変換の両方を評価するための、参照実行環境、プロジェクトテスト、およびホールドアウトテストが含まれる。
2. Prefactoryシステム： 再利用可能な実行可能な検出器（レキシカルおよび構造的）をLLMの知識から合成する自動化されたアプローチ。これにより、検索フェーズにおける繰り返しのLLM呼び出しなしに、効率的で決定論的なスキャンが可能になる。
3. 実証的エビデンス： 検出精度とコスト効率の両面において、検出器の合成が直接的なLLMプロンプティング、エージェンティックな探索、およびルールベースのツールよりも優れていることを示す制御された比較。

結果

PrefactoryBenchによる評価において、Prefactoryは以下の成果を達成した：

• 検出： ファイルレベルで75件、関数レベルで56件を検出した。
• リファクタリング： 検出された56個の関数のうち、40個の検証済みリファクタリング（差分テストとプロジェクトテストの両方に合格）を生成した。
• 比較： 最も強力なベースラインであるCodex CLI（35個のファイルと32個の関数を検出し、22個の検証済みリファクタリングを生成）や、リンター、バニラのLLMプロンプティング、およびSemgrep+LLMを上回った。
• 効率性：
  • スキャン時間： プロジェクトあたり平均1.3秒（LLMフリー）。
  • コスト： エンドツーエンドのコストは1インスタンスあたり0.05ドル未満であり、Codex CLIベースラインの約3分の1である。
  • 再利用性： 検出器はプロジェクトとライブラリのペアごとに一度だけ生成され、スキャンのために再利用されるため、繰り返しのスキャンは安価である。
• 実世界への適用： 5つのベンチマークプロジェクトの現行バージョンに関する研究において、Prefactoryは実行可能な機会を提示し、2つのプルリクエストがメンテナーによって受理された。

意義と主張

本論文は、**検出器の合成（detector synthesis）**が、ライブラリ採用リファクタリングのための実用的かつスケーラブルなワークフローであることを主張している。LLMのセマンティックな知識を決定論的な検索メカニズムに変換することで、Prefactoryは、直接的なエージェンティックな探索に伴う高いコストと再現性の問題を回避している。

著者らは、このアプローチは、ライブラリの機会が語彙と認識可能な実装構造の両方を露出している場合に最も効果的であると述べている。大規模でヘテロジニアスなライブラリ（例：numpy, pandas）において、機会が多くのAPIファミリーにまたがる場合や、複雑なI/Oまたは分散型の振る舞いを含むコードにおいて、差分検証が困難になるという制限は残る。本研究は、LLMの推論を繰り返しの広範なクエリを通じて適用するよりも、LLMの知識を再利用可能な実行可能な検出器として捉える方が、より効果的かつ安価であることを示している。