技術要約：TrajSpec – 軌跡に基づいたバグレポート仕様の洗練

問題提起

リポジトリレベルの自動プログラム修正（APR）エージェントは、タスク仕様の主要なものとしてバグレポートに依存しています。しかし、標準的なバグレポートは、観察された失敗の症状のみを記述しており、根本的な失敗メカニズム、特定の振る舞いの要件、および完全な実装範囲といった、修正に不可欠な情報を欠いていることがよくあります。その結果、APRエージェントは無関係なコードを調査したり、誤った要件を推論したり、報告された症状に対処するだけで、意図されたリポジトリの振る舞いを復元しないパッチを生成したりすることがあります。これまでの研究は、エージェントの探索戦略、ローカライズ、またはプロンプトエンジニアリングの改善に焦 heavy してきましたが、これらのアプローチは、入力されたレポートが十分な仕様を提供していることを前提としています。ダウンストリームの修正プロセスが始まる前に、リポジトリから欠落している仕様の詳細を収集することで、レポートを明示的に洗練させる手法には空白が存在します。

手法：TrajSpec

著者らは、リポジトリに裏付けられた仕様の洗練のための軌跡誘導型アプローチである TrajSpec を提案しています。このシステムは、元のバグレポート ($b$) と修正前のリポジトリのスナップショット ($R_c$) を通じて、以下のパイプラインで動作します。

1. 未検証の軌跡収集:
   TrajSpecは、$b$ と $R_c$ のみを使用して軌跡収集エージェントを実行します。このエージェントはリポジトリを探索し、コードを調査し、問題について推論します。極めて重要な点として、この実行は 未検証（unverified） です。TrajSpecはこのフェーズで生成された候補パッチを検証しません。いかなる候補パッチも破棄され、実行軌跡 ($\tau$) — 思考・行動・観察のタプルからなる一連のシーケンス — のみが保持されます。この軌跡は、たとえエージェントの最終的なパッチが誤っていたとしても、リポジトリに裏付けられた証拠のソースとして機能します。

2. 階層的証拠の抽象化:
   生の軌跡はしばしばノイズが多く、長大です。TrajSpecは、$b$ と $\tau$ から、以下の3つの次元に焦点を当てて候補となる知見を抽出します。

   • 失敗メカニズム: 症状を説明するソースコードの振る舞い。
   • 振る舞いの要件: 維持されるべき振る舞い。
   • 実装範囲: 関与するコードの場所。

   これらの知見は、各次元について3つの詳細レベルを持つ階層的表現 ($M$) に整理されます。

   • ハイレベル: 候補となる仕様の結論。
   • ミドルレベル: 診断的な推論と関係性（例：コードパス、依存関係）。
   • ローレベル: 具体的なリポジトリの観察事項（例：特定のファイル、関数、変数）。

3. ドラフト生成とリポジトリに基づくレビュー:
   $b$ と $M$ を使用して、LLMは固定されたスキーマ（タイトル、説明、根本原因、再現手順、期待される振る舞い、観察された振る舞い）に従って、ドラフトとしての洗練されたレポート ($\hat{b}$) を生成します。

   次に、リポジトリに基づくレビュー ステップが、$R_c$ に対して $\hat{b}$ を検証します。レビュアーエージェントは、ドラフト内の主張が $M$ の証拠および実際のソースコードによって支持されているかどうかを評価します。エージェントは、支持されていない主張を削除し、不確かな記述を修正し、リポジトリに裏付けられた詳細な情報を追加し、実装範囲が適切に限定されていることを確認します。出力されるのは、最終的な洗練されたレポート ($\hat{b}_f$) であり、これがダウンストリームの修正エージェントのタスク仕様となります。

主な貢献

• 定式化: 本論文は、リポジトリレベルのAPRにおけるバグレポートの強化を、「リポジトリに裏付けられた仕様の洗練」として定式化し、失敗メカニズム、振る舞いの要件、および実装範囲を明示することを目的としています。
• TrajSpecフレームワーク: 未検証の軌跡収集実行から仕様の証拠を抽出し、それらを階層的に整理し、候補パッチが正しいことを前提とせずに、ソースコードに対して証拠をレビューする手法を導入しました。
• 包括的な評価: Mini-SWE-Agent V2を用いて全300件のSWE-Bench Liteインスタンスで評価を行い、大幅な性能向上を示しました。
• 汎用性: TrajSpecの恩恵が、異なるダウンストリーム修正エージェント（AgentlessおよびAutoCodeRover）にわたって汎用されることを実証しました。
• コンポーネント分析: 階層的な証拠表現とリポジトリに基づくレビューの両方が性能向上に不可欠であることを確認するアブレーション研究を実施しました。

評価結果

著者らは、300件のSWE-Bench Liteインスタンスに対してTrajSpecを評価しました。

• 主要な修正エージェント (Mini-SWE-Agent V2):

  • GPT-5-mini 使用時、Pass@1 は 41.00%（元のレポート）から 59.67% に向上しました。
  • MiniMax M2.5 使用時、Pass@1 は 54.67% から 64.33% に向上しました。
  • TrajSpecは、両方の設定において「Agentic-Base」（軌跡データを使用するが、階層的抽象化とリポジトリレビューを欠くベースライン）を上回りました。
  • 改善は12のリポジトリに広く分布しており、TrajSpecは元のレポートによって以前に修正されていたほぼすべてのインスタンスを維持しつつ、修正範囲を拡大しました。

• クロスエージェントの汎用性 (100インスタンスの層化抽出サンプル):

  • Agentless: Pass@1 は 41.00% から 71.00% に向上しました。
  • AutoCodeRover: Pass@1 は 47.00% から 72.00% に向上しました。

• アブレーション研究:

  • リポジトリに基づくレビュー を削除すると、Pass@1 は 59.67% から 48.00% に低下しました。
  • 階層的証拠表現 を削除すると、Pass@1 は 47.67% に低下しました。
  • これにより、証拠を構造化することと、リポジトリに対して主張を検証することの両方が不可欠であることが確認されました。

• コスト分析:

  • TrajSpecはレポート生成のために追加のコストが発生しますが（GPT-5-mini使用時で1インスタンスあたり約$0.083）、ダウンストリームの修正における入力トークン使用量を約24%削減し、修正実行自体の金銭的コストを下げます。エンドツーエンドの総コストは、大幅な成功率の向上と比較して控えめな水準に留まっています。

意義と主張

本論文は、不十分なバグレポートに内在する「仕様の問題」に対処することで、リポジトリレベルの修正を向上させるための有望な方向性をTrajSpecが提供していると主張しています。著者らは以下の点を強調しています。

1. 軌跡はパッチ生成を超えて再利用可能である: 未検証の軌跡であっても、失敗メカニズムやコードスコープに関する貴重な証拠を含んでおり、それらを抽象化・構造化することでタスク仕様を改善できます。
2. 検証は極めて重要である: 単に軌跡データを使用するだけでは不十分であり、ノイズをフィルタリングし、主張が修正前のコードに根ざしていることを保証するためには、階層構造とリポジトリに基づくレビューステップが必要です。
3. タスク仕様が重要である: 入力仕様（バグレポート）を改善することは、修正エージェント自体を改善することと同じくらい重要です。TrajSpecは、エージェントに実行可能でリポジトリに裏付けられたコンテキストを提供することが、異なるモデルやエージェントアーキテクチャにおいて一貫して修正性能を向上させることを示しています。

著者らは、評価がSWE-Bench LiteのPythonリポジトリに限定されていること、および他の言語やベンチマークに対する有効性は今後の課題であることを述べ、控えめな立場をとっています。また、洗練されたレポートが自動修正の指標を向上させる一方で、本研究は人間が感じるレポートの品質ではなく、APRへの有用性に焦点を当てていることも認めています。