Echo: Graph-Enhanced Retrieval and Execution Feedback for Issue Reproduction Test Generation

本論文は、コードグラフと自動クエリ改良、そして生成されたテストの実行フィードバックを活用してバグ再現テストを生成するエージェント「Echo」を提案し、SWT-Bench Verified においてオープンソース手法として最高水準の 66.28% の成功率を達成したことを報告しています。

要約

この論文は、**「Echo（エコー）」**という新しい AI アシスタントの紹介です。

一言で言うと、**「バグ（不具合）の報告書だけを見て、そのバグを再現する『テスト用プログラム』を自動で作ってくれる、超優秀な新人エンジニア」**のような存在です。

開発者が「このコードが壊れている！」と報告しても、なぜ壊れているのか、どう直せばいいかがすぐにわからないことが多いです。Echo は、その「壊れている状態」を再現するテストコードを自動で作ることで、バグの特定と修正を劇的に助けます。

この仕組みを、日常の比喩を使ってわかりやすく解説します。

---

🕵️‍♂️ Echo の正体：探偵と職人の合体

Echo は、単なる「コードを書く AI」ではありません。3 つの特別な能力を持った「探偵兼職人」です。

1. 迷路を解く「地図読み」能力（グラフ強化検索）

• 問題点: 従来の AI は、巨大なコードの山から必要な情報を探すとき、ただ「キーワード検索」をするだけでした。それは、図書館で本を探すのに「タイトル」しか言わずに、本棚を無造作に漁るようなものです。
• Echo の解決策: Echo は、コードの構造を**「巨大な都市の地図（グラフ）」**として理解しています。
  • 「A という機能は、B というファイルと C という関数につながっている」という関係性まで把握します。
  • さらに、AI 自身が「この情報じゃ足りないな」と感じたら、**「もっと詳しい場所を聞いてみよう」**と自分で検索クエリ（質問）を修正し、必要な情報だけをピンポイントで集めてきます。
  • 比喩: 普通の探偵が「犯人は赤い服を着ている」という情報だけで街中を彷徨うのに対し、Echo は「犯人は赤い服を着て、A 地区の B 通りの C 店にいる可能性が高い」という精密な地図を持って現場へ向かうようなものです。

2. 自動運転の「テスト運転手」能力（自動実行とフィードバック）

• 問題点: 以前は、AI が作ったテストコードが実際に動くかどうか、人間が手動で確認する必要がありました。また、「バグが再現できたか？」を判断する基準（オラクル）が曖昧でした。
• Echo の解決策: Echo は**「自分でテストを実行する」**ことができます。
  • 作ったコードを自動で走らせ、「エラーが出たか？」「バグの報告書と一致するか？」を確認します。
  • もし失敗したら、そのエラーログを見て**「あ、ここが間違っていたんだ！」**と自分で気づき、コードを修正して再挑戦します。
  • 比喩: 料理人がレシピ（コード）を作った後、味見（テスト実行）をして「塩が足りない！」と気づき、自分で味を調整し直すまで繰り返すようなものです。

3. 「バグの証明」能力（パッチによる検証）

• 問題点: 「バグが再現できた」と言っても、本当にそのバグなのか、単なる別のエラーなのか、判断が難しいことがあります。
• Echo の解決策: Echo は、バグを直すための**「仮の修正パッチ（治し方）」**も同時に考えます。
  • 「バグ版（壊れた状態）」でテストが失敗し、「修正版（直った状態）」でテストが成功すれば、それは完璧なバグ再現テストだと判断します。
  • 比喩: 「この薬が効くか」を試すために、「病気の状態」と「治った状態」の 2 つの体で同じ薬を試し、反応の違いを確認する二重盲検テストのような厳密さを持っています。

---

🏆 なぜ Echo はすごいのか？

これまでの AI は、「100 個のテストコードを作って、その中から一番良さそうなものを選ぶ」という方法をとっていました。これはコストが高く、時間がかかります。

Echo は、**「1 つのテストコードを、何度も改良して完璧にする」**という戦略をとります。

• 結果: 有名なテストベンチマーク（SWT-Bench）で、66.28% という過去最高（SOTA）の成功率を達成しました。
• コスト: 多くの候補を作るのではなく、1 つを丁寧に磨き上げるため、無駄な計算コストも抑えられています。

📝 まとめ：Echo がもたらす未来

Echo は、**「バグ報告書という曖昧なメモ」**を受け取ると、

1. 必要なコードを地図から探し出し、
2. 自分でテストを実行して失敗させ、
3. 失敗の原因を分析してコードを修正し、
4. 最終的に「バグを再現し、修正で直る」完璧なテストコードを 1 つ完成させる、自律的なエンジニアです。

これにより、開発者は「なぜ動かないのか？」を自分で探す時間から解放され、より重要な「どう直せばいいか」や「新しい機能を作る」ことに集中できるようになります。

**「Echo は、バグという『幽霊』を捕まえるための、最も賢いトラップを作ってくれる存在」**と言えるでしょう。

技術概要

Echo: 問題再現テスト生成のためのグラフ強化検索と実行フィードバック

技術的サマリー（日本語）

本論文は、ソフトウェア開発におけるバグの根本原因特定を支援するため、GitHub のイシュー（問題報告）から**バグを再現するテストケースを自動的に生成するエージェント「Echo」**を提案するものです。従来の手法が抱える文脈取得の精度不足や実行環境の複雑さ、検証の信頼性といった課題を解決し、オープンソースアプローチとして新たな最先端（SOTA）を確立しました。

以下に、問題定義、手法、主要な貢献、実験結果、および意義について詳述します。

---

1. 背景と課題 (Problem)

バグ報告から再現テストを生成することは、バグの特定や修正を加速し、CI/CD の品質保証を強化する上で不可欠です。しかし、開発者が手動でこれを行うのは時間と労力がかかります。近年、大規模言語モデル（LLM）を用いた自動化が進んでいますが、以下の重大な課題が残っていました。

1. 文脈取得の限界: 既存手法の多くは、単純な階層的なファイル検索（Agentless フレームワーク等）に依存しており、大規模コードベースにおける構造的な関係性や長距離のセマンティクスを捉えきれず、ノイズの多い不完全な文脈を提供しがちです。
2. 実行環境の非明示性: 実世界のレポジトリでは、テスト実行コマンドや設定が複数のファイルに散在しており、標準化されたハarnessが存在しないため、生成されたテストを実行することが困難です。
3. 検証の信頼性不足: 生成されたテストが本当に報告されたバグを再現しているか（失敗するか）、かつ修正版では通るか（パスするか）を判断する「オラクル（判定基準）」が不足しています。イシュー記述だけでは、失敗の理由がバグによるものか、単なる実装ミスによるものかを LLM が正確に判断するのは困難です。
4. コストと効率: 多数の候補テストを生成してランキングする手法が多く、計算コストが高く、実用的なワークフローへの統合が難しい傾向があります。

2. 手法 (Methodology)

Echo は、コードグラフの活用、自動実行、および双バージョン検証を組み合わせた 6 つのフェーズから構成されるエージェントです。

2.1 コードグラフ強化検索 (Graph-Enhanced Retrieval)

• コードグラフ構築: コードベースを Neo4j に保存する異種有向グラフとしてモデル化します。ノードは「リソース（ファイル/ディレクトリ）」「パースツリーノード（構文木）」「テキストスパン（ドキュメント/コメント）」で構成され、エッジはファイル構造や構文関係、テキストの連続性を表現します。
• 自動クエリ改善: 初期クエリを LLM が評価し、取得した文脈が不十分な場合はクエリを自動改善（Refinement）して再検索を行います。これにより、イシューの特定部分（Focal Code）と関連する回帰テストを高精度に抽出します。

2.2 パッチ生成とテスト生成

• パッチ生成: 既存の自動修正ツール（Prometheus）を用いて、イシューに対する候補パッチ（修正コード）を生成します。
• テスト生成: 取得した文脈（焦点コード、回帰テスト、パッチ）とイシュー記述を基に、LLM が単一のテストケースを生成します。生成されたテストは、プロジェクトのテストフレームワークに準拠し、独立したファイルとして作成されます。

2.3 自律的テスト実行 (Autonomous Execution)

• LLM がレポジトリの README や設定ファイルから適切な実行コマンドを推論し、コンテナ内でテストを実行します。
• 安全性制約: LLM が環境を改変したり、全テストスイートを実行したりするのを防ぐため、「ファイル存在チェックの禁止」「全テスト実行の禁止」「ファイル編集の禁止」などの厳格な制約をプロンプトに組み込んでいます。

2.4 検証と双バージョンチェック (Verification & Dual-Version Check)

• 実行フィードバックループ: 実行結果（ログ）を LLM に提示し、失敗がイシュー記述と意味的に一致するかを判定します。不一致の場合は、ログをフィードバックとしてテスト生成に反映し、改善を繰り返します。
• Fail-to-Pass 基準の検証: 既存手法が LLM の推論に依存するのに対し、Echo は**「修正版（パッチ適用後）でテストが通り、元のバージョンでテストが失敗する」**という厳密な条件を、ルールベースで検証します。これにより、生成されたテストが真のバグ再現テストであるかを客観的に保証します。

3. 主要な貢献 (Key Contributions)

1. Echo の提案: コードグラフによる文脈検索、実行フィードバックによる反復改善、および自動実行機能を統合した、問題再現テスト生成エージェント。
2. SOTA の確立: 広く利用されているベンチマーク「SWT-Bench Verified」において、66.28% の成功率を達成し、既存のオープンソース手法（e-Otter++, OpenHands など）を凌駕する新たな最先端性能を確立しました。
3. 効率性とコストパフォーマンス: 多数の候補を生成して選別するのではなく、1 つのイシューあたり 1 つの高品質なテストを反復的に生成・改善するアプローチを採用。これにより、コストと性能のバランスを最適化しました。
4. オープンソース化: コード、実行ログ、実験結果を GitHub で公開し、再現性と将来の研究を支援しています。

4. 実験結果 (Results)

• 成功率: SWT-Bench Verified（433 インスタンス）において、**66.28%**の成功率を達成。
  • 2 位以下の e-Otter++ (62.1%) や OpenHands (62.4%) を上回りました。
  • 他手法が解決できなかった 33 のインスタンスを Echo 独自に解決しました。
• リファインメントの効果: 実行フィードバックによる改善機能（Refinement）を無効化した場合、成功率は 59.12% に低下しました。これにより、実行フィードバックと双バージョンチェックが性能向上に寄与していることが実証されました。
• コスト分析:
  • 1 インスタンスあたりの平均コストは $1.54（Gemini 2.5 Pro 使用）。
  • 既存の高性能エージェント（e-Otter++ の Claude 版など）と比較して、同等以上の性能をより低いコストで達成しています。
  • コストの大部分（約 70%）は「テスト生成と改善（Gen & Refine）」フェーズで発生しており、特に複雑なプロジェクト（Django など）ではトークン消費が増大します。

5. 意義と結論 (Significance)

Echo は、バグ再現テスト生成の分野において以下の点で画期的です。

• 実用性の向上: 自動実行と厳密な Fail-to-Pass 検証を統合することで、開発者が実際に信頼して使用できるテストを生成します。
• 技術的ブレイクスルー: コードグラフを活用した文脈取得と、パッチをオラクルとした検証メカニズムは、LLM の推論限界を補完する効果的なアプローチであることを示しました。
• 研究への貢献: 生成されたテストが「なぜ失敗したか」を詳細に分析し、エラー分布（AssertionError, ModuleNotFoundError など）を明らかにすることで、今後のツール開発における課題を浮き彫りにしました。

今後は、取得する文脈の最適化（トークンコスト削減）、より堅牢な実行環境の構築、およびバグ報告の正確な意味を捉えるための新しいオラクルの探求が今後の課題として挙げられています。