技術的概要：EVIACT – エージェント型プログラム修復のためのエビデンスからアクションへのフレームワーク

問題定義

自動プログラム修復（APR）は、固定コンテキストのパッチ生成から、大規模言語モデル（LLM）エージェントを用いた対話的・リポジトリレベルの修復へと進化してきた。既存のエージェント型 APR システムは柔軟性を提供しているが、修復プロセスを導くために実行エビデンスを効果的に活用することに苦慮している。本論文は、ワークフローベースのエージェント型 APR システムにおいて、決定的な「エビデンスからアクションへのギャップ」を特定している。

現在のワークフローベースのシステムでは、修復は局所化、パッチ生成、検証などの段階に分解されるが、これらの段階間の境界は十分に定義されていない。この厳密な制御の欠如は、図 1 に示される「誤った局所化の連鎖」として描かれる 3 つの主要な失敗モードをもたらす：

1. 誤った局所化：弱い失敗エビデンスが誤った疑わしいコードセットを導き、エージェントが無関係なコードを編集させる。
2. 無効なパッチ試行：エージェントが、検証段階に到達する前に、不正な形式、適用不可能、またはコンパイル不可能なパッチを生成する。
3. 高い検証コスト：システムが、意味的に無関係または実行不可能なパッチを繰り返しテストし、計算リソースを浪費する。

核心的な問題は、実行エビデンスが観測されるものの、何を取得し、何を編集し、いつ検証するかを制御するために信頼性高く利用されていない点にある。

手法：EVIACT フレームワーク

このギャップに対処するため、著者は標準的な 4 段階パイプライン（セットアップ、局所化、パッチ、検証）全体にわたって 3 つのエビデンス駆動型「ガードレール」を調整するエージェント型 APR フレームワークであるEVIACT（エビデンスからアクションへ）を提案する。

1. パイプライン

• セットアップ：クリーンなワークスペースを初期化し、構造的コードグラフ（AST スパンとコードグラフを使用）を用いて構造を保持する検索インデックスを構築し、対象の失敗を再現してREDエビデンス（失敗したテストログ、スタックトレース）を取得する。
• 局所化：RED エビデンスを失敗に基づいたクエリに変換し、疑わしいコード位置をランク付けする。
• パッチ：局所化された疑わしいセットに基づいて候補編集を合成する。
• 検証：対象テストとフル回帰スイートを再実行してパッチを承認する。

2. 3 つのガードレール

EVIACT は、段階の遷移において具体的な制御を導入し、エビデンスを実行可能な制約に変換する：

• 検索足場（セットアップ $\to$ 局所化）：
  制約のないキーワード検索の代わりに、この足場は RED 失敗エビデンスを構造的コードグラフを用いて焦点を絞った疑わしいセットにマッピングする。これは、失敗シグナル（スタックフレーム、エラーメッセージ）を AST スパンおよび構造的記述子（ファイルパス、シンボル、呼び出しグラフ）と照合することにより、決定論的な検索を行う。候補は、正確なトレース - シンボル一致、ファイルの近接性、およびグラフ距離に基づいてランク付けされ、トップ K 個の疑わしい候補（デフォルト $K=3$）のコンパクトなセットを出力する。

• コンパイルゲート（パッチ段階）：
  任意のテスト検証の前に、このゲートは候補パッチをフィルタリングする。パッチが well-formed な diff であるか、クリーンに適用されるか、構文またはビルドチェックをパスするかを確認する。パッチが失敗した場合、構造化された診断情報（失敗タイプ、影響を受けたファイル、ビルド出力）がエージェントに返され、精緻化のために返される。これにより、無効な候補が高価なテストスイートに到達するのを防ぐ。

• テスト駆動（TD）ゲート（セットアップ $\to$ 検証）：
  このゲートは、フル回帰の前にRED-GREENフローを強制する。

  • RED：元々失敗した対象テストは、局所化を固定するために、バグのあるリビジョン上で失敗しなければならない。
  • GREEN：パッチ適用後、同じ対象テストがフル回帰テストに進む前に合格しなければならない。
    これにより、フル検証のコストを発生させる前に、パッチが観測された失敗に特に対処していることを保証する。

主要な貢献

1. エビデンスからアクションへのギャップの特定：本論文は、ワークフローベースのエージェント型 APR の非効率性を、実行エビデンスがその後の修復決定を制約できない段階境界の設計問題として枠組み化している。
2. EVIACT フレームワーク：3 つのガードレール（検索足場、コンパイルゲート、TD ゲート）を調整し、修復軌跡が観測された失敗、コンパイラフィードバック、および検証結果に結びついたままになることを保証する新規アーキテクチャ。
3. 包括的な評価：複数の LLM バックボーン（GPT-4o、GPT-5.2、DeepSeek-V3.2、Gemini-2.5-Pro）を使用して、4 つのベンチマーク（Defects4J 2.0、SWE-bench Verified、SWE-bench Lite、SWE-bench Live）全体で評価を行った。
4. 実証的証拠：調整されたエビデンス制御が、有効性（解決率）と効率性（API コスト、実行時間）の両方を向上させることを示す結果。

実験結果

GPT-4o バックボーン下で評価されたところ、EVIACT は 4 つのデータセット全体で報告された最も強力な比較ベースラインを上回った：

• 解決率：EVIACT はベースラインに対して1.6 から 6.0 パーセントポイントの改善を達成した（例：Defects4J 2.0 では 25.0% で RepairAgent の 19.6% に対し、SWE-bench Verified では 40.4% で Agentless の 38.8% に対し）。
• 効率性：ベースラインのコストが利用可能な場合、EVIACT はバグあたりの API コストを70.1–88.6% 削減している。
• モデルのスケーリング：GPT-5.2 のような強力なバックボーンを使用すると、解決率がさらに向上する（SWE-bench Verified で最大 70.2%）。一方、DeepSeek-V3.2 のようなコスト効果の高いモデルは、大幅に低いコスト（バグあたり$0.03–$0.05）で高いパフォーマンスを維持する。

アブレーション研究：
ガードレールを除去すると、パフォーマンスが著しく低下する。層化されたサンプルにおいて、完全な EVIACT システムは、ガードレールなしのベースラインに対して解決率を**+13.0 パーセントポイント**向上させ、トークン使用量を 84.1K 削減し、実行時間を 195.3 秒短縮した。本研究は、検索足場が局所化のドリフトを減少させ、コンパイルゲートが無効な候補をフィルタリングし、TD ゲートが早急なフル回帰を防ぐことを確認している。

失敗分析：
失敗した実行において、**46.5%**は誤った局所化に起因し、**38.5%**は誤った編集（正しいコンテキストだが間違った意味論的変更）に起因している。注目すべきは、不正な形式またはコンパイル不可能なパッチがコンパイルゲートによって効果的にフィルタリングされ、失敗の最前線が「実行不可能性」から「意味論的基盤」へとシフトしている点である。解決されたパッチの人手による分析によると、**78.0%**は意味論的に正しいが、**11.5%**は過剰適合（テストに合格するが一般的な修復を実装していない）であることが示された。

意義と主張

本論文は、EVIACT がエージェント型 APR に対する実用的なエビデンスからアクションへの制御メカニズムを提供すると主張している。修復アクションを追跡可能なエビデンス（失敗ログ、コンパイラ診断、テスト結果）に固定することにより、このフレームワークは修復決定をより効果的で信頼性の高いものにする。

著者は、EVIACT が検証コストを大幅に削減し、局所化を改善する一方で、残るボトルネックは意味論的基盤（編集が単に「機能する」修正ではなく、正しい修正であることを保証すること）と、複雑なリポジトリ構造における堅牢な検索であると控えめに指摘している。本論文は意味論的過剰適合を完全に解決すると主張するものではないが、構文/実行エラーから意味論的エラーへと失敗の最前線をシフトさせることが、より堅牢なエージェント型修復に向けた必要なステップであることを実証している。将来の作業として、蓄積された実行フィードバックに基づいて局所化と検証を精緻化する適応型システムへとこの設計を拡張することが提案されている。