技術要約: EvoOtter

問題提起

バグ再現テスト（BRT）の生成は、ソフトウェアエンジニアリングにおいて極切なステップであり、修正が適用される前にバグの存在を確認する役割を果たす。従来のテスト生成が「パスすること」を目的としているのに対し、BRTは「Fail-to-Pass (F2P)」でなければならない。すなわち、現在のバグのあるコード（$c_{old}$）では失敗し、将来の解決されたコード（$c_{new}$）ではパスする必要がある。

BRT生成における主な課題は、信頼できるフィードバックの欠如である。生成中に解決済みのコード（$c_{new}$）が利用できないため、候補となるテストが正しい理由で失敗しているのか、あるいは多くの候補の中から最適なものを選別することが困難である。従来のアプローチは「推論スケーリング（inference scaling）」、つまり多くの候補を生成し、LLMや実行フィードバックを用いてそれらを精査・改善することに依存してきた。しかし、これらの手法はLLMの呼び出し回数が多く高コストであり、フィードバックが不安定であったり、テストのオーバーフィッティング（過学習）が生じたりすることが多い。

手法: EvoOtter

EvoOtterは、進化型プログラミングとLLMを組み合わせ、コストを削減しフィードバック信号を鋭敏化するように特別に設計された手法によって、これらの課題に対処する。ワークフローは、候補テストの集団とコード変異体の集団上で動作する。

1. コア進化ループ

システムは2つの集団を維持する：

• 捕食者 (Predators): 候補となるBRT。
• 獲物 (Prey): コードのバグを含む変異体（ミュータント）。

進化ループは以下のように進行する：

1. 初期化: ベースとなるジェネレータが、問題の説明やコンテキストを変化させるためのヘテロジニアスなプロンプティングを用いて、$n$ 個の多様な初期テスト（通常は8個）を作成する。
2. 変異体生成: ルールベースのジェネレータが、バグが含まれていると疑われる局所的なフォーカル関数に対して、特定の変異オペレータ（例：算術演算子の入れ替え、定数の置換、強制的な失敗の発生）を適用することで、$m$ 個のコード変異体を作成する。このステップではLLMは使用されない。
3. 適応度評価: 各テストは、現在の変異体集団に対して実行される。適応度スコアは、テストによって「殺された（killed）」変異体の数として定義される。
   • 「殺す」定義の新規性: 元のコード自体がすでにバグを含んでいるため、テストが変異体を殺すことは、単なるテストの失敗とは定義されない。代わりに、システムは実行ログを分析する。テストが、元のコードで失敗した時とは「異なる理由」で変異体に対して失敗した場合、その変異体は「殺された」とみなされる（ログ出力の変化によって示される）。
4. 選択 (逐次分割法 / Successive Halving): テストは適応度順にソートされ、下位半分が破棄される。強力なフィードバック信号を維持しつつ実行コストを一定に保つため、次の世代では変異体の数を倍増させ（事前に生成されたプールからサンプリング）、テストの集団を半分にする。このプロセスは、単一のテストが残るまで繰り返される。
5. 交叉 (バッチ修復 / Batched Repair): 生き残ったテストが親として使用される。単一のLLM呼び出しを使用して、次世代の全オフスプリング（子）を生成する。LLMには、親テストとその実行ログの間でステートメントを入れ替え、追加、または削除するようにプロンプトが与えられ、テストを改善させる。この「バッチ交叉」により、個々のテストごとにLLMを呼び出す高コストな処理を回避する。

2. コスト制御メカニズム

• 逐次分割法 (Successive Halving): 世代ごとにテスト集団を半分に減らし、同時に変異体集団を倍増させることで、各イテレーションにおける総テスト実行数を一定（$2m$）に保つ。
• バッチ交叉 (Batched Crossover): 世代全体のオフスプリングを、個別の呼び出しではなく、単一のLLM呼び出しで生成する。
• ルールベースの変異体: 変異体の生成にはLLMではなく決定論的なコード書き換えルールを使用し、LLMはテストの生成と進化に厳密に限定して使用する。
• シングルプロンプティング・オプション: デフォルトでは初期の多様性のためにヘテロジニアスなプロンプティングを使用するが、システムは「シングルプロンプト」モードもサポートしており、これによって1回のLLM呼び出しですべての初期候補を生成できる。これにより、Claude-Opus-4.7のような、より強力（かつ高価）な推論モデルの使用コストを大幅に削減できる。

主な貢献

1. EvoOtterワークフロー: 変異テストと逐次分割法を統合した、進化型プログラミングに基づく初のBRT生成ワークフロー。
2. 変異ベースの適応度スコア: ルールベースのコード変異体をテストによって殺す数をカウントする新しい適応度指標。これは、「バグのあるオリジナルコード」というシナリオを扱うためにログの差異を利用している。
3. バッチ交叉: 世代全体のテストを進化させるために、単一の呼び出しで現代的なLLMの能力を活用する技術。これにより、パフォーマンスとコストのバランスを実現している。

実験結果

著者らは、TDD-Bench-Verified、SWE-Rebench、SWT-Bench-Verifiedの3つのベンチマークでEvoOtterを評価した。

• パフォーマンス: Claude-Sonnet-4.5とヘテロジニアスなプロンプティングを使用した場合、EvoOtterはTDD-Bench-Verifiedで65.9%、SWE-Rebenchで**51.9%**のF2P率を達成し、選択や修復のみに依存する従来のベースライン（e-Otterなど）を上回った。
• 最先端性能 (SOTA): より強力な推論モデルであるClaude-Opus-4.7を用いたシングルプロンプティングを使用することで、EvoOtterはTDD-Bench-Verifiedで75.3%、SWE-Rebenchで**66.3%を達成した。SWT-Bench-Verifiedのリーダーボードでは77.8%**に達した。
• コスト効率: EvoOtterは、これら（SOTA）の結果を、従来の推論スケーリング手法のわずかなコストで達成している。標準的なワークフローにおけるインスタンスあたりの平均コストは約0.17ドル（初期生成を除く）であり、個別の修復ループを必要とする手法と比較して、高パフォーマンスなシングルプロンプト・バリアントでも0.88ドルと非常に低い。
• コンポーネント分析:
  • 選択 (Selection): 変異による選択は、進化の後半段階において、LLMベースの選択やランダムな選択よりも優れた結果を示したが、初期段階ではLLMが良好に機能した。
  • 交叉 (Crossover): 交叉を除去するとパフォーマンスが10%以上低下し、その決定的な役割が浮き彫りになった。
  • 多様性 (Diversity): シングルプロンプティングは多様性をわずかに低下させたが、進化オペレータがテストを選択・改善するプロセスを妨げることはなかった。

意義と主張

論文は、EvoOtterが、進化型プログラミングとLLMをソフトウェアエンジニアリングのタスクにいかに効率的かつ効果的に組み合わせることができるかを示していると主張している。その主な意義は以下の通りである：

• 堅牢性: 単なるノイズを含む可能性のあるLLMの判断や、バグのあるコードのみの実行に頼るのではなく、変異テストを通じて、より信頼性の高いフィードバック信号を提供すること。
• 効率性: バッチ操作や逐次分割法を通じてLLMの呼び出しを最小限に抑えることで、BRT生成のコストを劇的に削減し、スケーラビリティを実現すること。
• 実用性: 検証済みベンチマークで最先端の結果を達成しつつ、低い推論コストを維持しており、複雑なソフトウェアエンジニアリングタスクにおいて進化戦略が純粋な推論スケーリングの有力な代替手段となり得ることを示唆している。

著者らは、現在の知見がPythonリポジトリに限定されていること、および（シングルプロンプティングなどの）設計上の選択が最新のフロンティアモデルの能力に合わせて調整されていることを注記している。