💻 computer science

Heterogeneous Prompting and Execution Feedback for SWE Issue Test Generation and Selection

本論文は、異種プロンプティングと実行フィードバックを活用することで、ソフトウェアエンジニアリングにおける課題であるコードの欠落や誤りの問題を克服し、TDD-Bench Verifiedベンチマークにおいて63%という最先端のfail-to-pass率を達成する、再現テストを自動生成する新しいテストジェネレータであるe-Otter++を紹介するものである。

原著者： Toufique Ahmed, Jatin Ganhotra, Avraham Shinnar, Martin Hirzel

公開日 2026-01-26

📖 1 分で読めます☕ さくっと読める

CC BY 4.0

原著者： Toufique Ahmed, Jatin Ganhotra, Avraham Shinnar, Martin Hirzel

原論文は CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) でライセンスされています。 ✨ これは以下の論文のAI生成解説です。著者が執筆または承認したものではありません。技術的な正確性については原論文を参照してください。免責事項の全文を読む

あなたは、巨大で散らかった図書室（ソフトウェアコード）の中で謎を解こうとしている探偵だと想像してください。ある利用者（開発者）がやってきて、「この本に何か問題があるのですが、正確には何がどう悪いのか説明できず、間違いが起きている具体的な例も手元にありません」と言います。

ソフトウェアの世界では、これをSWE Issueと呼びます。通常、バグを修正するには「再現テスト」が必要です。つまり、「もしXを行えば、ライブラリがクラッシュする」という特定のスクリプトです。これがバグの存在を証明します。しかし、多くの場合、そのようなスクリプトはまだ存在しません。

この論文では、新しい探偵ツールである**e-Otter++**を紹介しています。その役割は、実際の修正が行われる前であっても、問題の乱雑な記述を読み取るだけで、その「クラッシュ用スクリプト（テスト）」を自動的に書き出すことです。

e-Otter++の仕組みを、簡単な比喩を用いて説明します。

1. 問題点：「盲目の」探偵

通常、賢いAI（大規模言語モデル）にテストを書くよう頼むと、AIは推測しようとします。もし一度だけ頼んだとしても、間違えるかもしれません。もし全く同じ指示で10回聞いたとしても、AIは単に少しずつ異なるバージョンの「同じ間違った推測」を出すだけかもしれません。それは、一度しか見ていない映画の内容を友人に説明してもらうようなものです。10回聞いても、その人は同じ間違いを繰り返すだけでしょう。

2. 第一のトリック：「ヘテロジニアス・プロンプティング」（仮装パーティー）

より良い推測を得るために、e-Otter++は単にAIに同じ質問を10回繰り返すのではありません。代わりに、AIに異なるコスチュームを着せたり、異なる視点を与えたりするように、質問の「仕方」を変えます。

「マスク（仮面）」： AIがパズルを見ている場面を想像してください。時として、e-Otter++はパズルの一部（コードのコンテキスト）を隠し、AIがより少ない情報に基づいて推測するように仕向けます。またある時は、特定のピースだけを見せます。これにより、AIに問題を異なる角度から見させます。
「モーフ（変形）」： バグレポートが混乱した専門用語で書かれている場合、e-Otter++はAIに対し、異なるスタイルでレポートを書き直すよう命じます。
- 「標準化（Standardizer）」： 乱雑なメモを、形式的で構造化されたレポートに変換します。
- 「単純化（Simplifier）」： 混乱を招く技術的な専門用語を取り除き、理解しやすくします。
- 「削除（Dropper）」： 誤解を招く可能性のある特定のコードスニペット（例えば、そのライブラリには実際には存在しないツールを使うように指示するなど）を取り除きます。
- 「事前思考（Pre-Thinker）」： AIにまず解決策を推測させ、その推測を利用してテストを書かせます。

これらの「マスク」と「モーフ」を組み合わせることで、e-Otter++は多様性に富んだ潜在的なテストのプールを生成します。これは、10人の異なる人々に犯罪現場の描写をさせるようなものですが、それぞれの人に異なる手がかりを与え、異なる話し方をさせるのです。これにより、少なくとも一人が正解に辿り着く確率が高まります。

3. 第二のトリック：「実行フィードバック」（試運転）

AIがテストを生成した後、e-Otter++はそれをそのまま信用することはありません。生成されたテストを、古いコード（バグのあるバージョン）に対して実行します。

目的： テストは失敗しなければなりません。しかし、それは正しい理由で失敗する必要があります。
問題： 時として、テストは（実際のバグではなく）単純なミス（タイポなど）によって失敗することがあります。
解決策： e-Otter++には「批評家（Critic）」となる別のAIが備わっています。この批評家は失敗の内容を分析します。もしテストが間違った理由で失敗していた場合、批評家は「それはバグではありません。ここが間違っています。そして、ここにある追加のコードも確認してください」と伝えます。そして、システムはこの新しい情報を用いてテストを書き直します。テストが、まさにバグレポートの記述通りに失敗するまで、このループを繰り返します。

4. 第三のトリック：「サロゲート・パッチ」（ダミーの修正）

ここが最も難しい部分です。あるテストが「良い」ものであると判断するには、そのテストが新しいコード（修正後）でパスする必要があります。しかし、修正自体がまだ存在しません！では、どうやって最高のテストを選べばよいのでしょうか？

e-Otлоtter++は、巧妙な回避策を用います：

e-Otter++は、別のAIシステム（Agentlessと呼ばれます）に、一連の偽の修正（サロゲート・パッチ）を生成させます。これらは完璧ではありませんが、惜しいところまで行っています。
すべての候補テストを、これらの偽の修正に対して実行します。
もしテストが偽の修正上でパスした場合、それは優れたテストである可能性が高いと言えます。
最終的に、どのテストがコードの最も重要な部分を最も多くカバーしているかに基づいて、単一の最高のテストを選び出します。

結果：大きな飛躍

このシステムは、2つの主要なベンチマーク（TDD-BenchとSWT-bench）でテストされました。

従来の最高水準： 既存のトップシステムは、動作するテストを生成できる成功率が**37%から38%**程度でした。
e-Otter++： これらの新しいトリック（質問の仕方を変えることや、偽の修正を使って回答をフィルタリングすること）を用いることで、e-Otter++は一つのベンチマークで63%、もう一つのベンチマークで**52.5%**まで成功率を引き上げました。

なぜこれが重要なのか

著者らは、これが主に2つの方法で役立つと述べています。

人間にとって： 「テスト駆動開発（バグを修正する前にテストを書くこと）」の退屈な部分を自動化し、開発者がバグを確認し修正することを容易にします。
AIエージェントにとって： 多くのAIコーディングエージェントは、バグを修正したかどうかを知るためにこれらのテストに依存しています。より良いテストを提供することで、e-Otter++は他のAIエージェントがより良く仕事をこなすための助けにもなります。

要約すると、e-Otter++は、人間が先にその証明を書くことなく、ソフトウェアのバグが存在し、かつそれが修正されたことを示す「証明」をAIに書かせるための、よりスマートで、より創造的で、より厳格な方法なのです。

技術要約：SWEイシューのテスト生成と選択のためのヘテロジニアス・プロンプティングおよび実行フィードバック

問題提起
バグや機能不足を記述するソフトウェアエンジニアリング（SWE）のイシューは、多くの場合、自動化された再現テストを欠いた非形式的な記述を伴います。このようなテストの不在は、イシューの検証およびコードパッチの受理を妨げます。本論文が取り組む具体的な課題は、解決策となるコードパッチ（ $c_{new}$ ）にアクセスすることなく、イシューの記述と既存の（パッチ適用前の）コードベース（ $c_{old}$ ）から直接、「失敗から成功へ（ $F \to P$ ）」至る再現テストを自動生成することです。有効な $F \to P$ テストは、 $c_{old}$ で実行した際に失敗し（イシューを再現）、かつ $c_{new}$ で実行した際に成功（修正を確認）しなければなりません。このタスクが困難である理由は、イシューの記述が非形式的であり、かつテストが成功すべき対象となるコードがまだ存在しないためです。

手法：e-Otter++
著者らは、先行研究である Otter++ フレームワークを拡張したシステムである e-Otter++ を導入しています。このシステムは、テスト生成器、コードパッチ生成器、およびテストセレクターという3つの主要コンポーネントで構成されています。

ヘテロジニアス・プロンプティングによるテスト生成：
多様な候補を生成するために、単にLLMのデコーディング温度（temperature）を上げる手法（多様性に欠けることが多い一般的な手法）に頼るのではなく、e-Otter++ は**ヘテロジニアス・プロンプティング（異種混合プロンプティング）**を採用しています。これには、以下の2つの系統的なバリエーションが含まれます。
- イシュー記述のモーフィング（変形）： LLMは、テスト生成の前に元のイシュー記述を5つの異なる形式（standard（整形済み）、simple（専門用語の簡略化）、dropCode（誤解を招く可能性のあるコードスニペットの削除）、initTest（初期テストの組み込み）、initPatch（初期パッチ案の組み込み））に書き換えます。
- コンテキスト・マスク： テスト生成プロンプトを修正し、特定のローカライゼーション・コンテキスト（例：プランナーの出力、テストのローカライゼーション、パッチのローカライゼーション）を含める、あるいは除外することで、5つの異なるプロンプトのバリエーションを作成します。
  これらを組み合わせることで、システムはイシューごとに10個の候補テストを生成します。
実行増強型テスト修復：
生成された候補テストは $c_{old}$ 上で実行されます。これらは失敗することが期待されますが、特定のイシューを再現しているのではなく、誤った理由（例：構文エラーや無関係な例外）で失敗する可能性があります。e-Otter++ は**クリティック（批評家）**メカニメントを導入しています。
- LLMがイシューの記述と実行ログを分析し、テストが「正しい理由」で失敗しているかどうかを判断します。
- 失敗が不適切な理由によるものである場合、クリティックは必要なコンテキスト（例：特定のバグのある行、関連するコードスニペット、または関数シグネチャ）を特定し、修復用プロンプトを拡張します。
- システムは、テストが正しい理由で失敗するか、あるいは反復回数の上限に達するまで、この強化されたコンテキストを用いてテストを反復的に修復します（最大10回）。
サロゲート・パッチによるテスト選択：
$c_{new}$ は利用できないため、e-Otter++ は真の修正に対してテストが成功するかどうかを直接検証することができません。これを解決するため、システムは Agentless を使用して40個の候補コードパッチ（ $c_{new}$ の代用となるサロゲート）を生成し、それらを最も頻出する5個に絞り込みます。
- テストセレクターは、これらのサロゲート・パッチ上で候補テストを実行します。
- サロゲート・パッチにおいて $F \to P$ となるテストが優先されます。
- ルールベースのセレクターは、失敗の種類（アサーション失敗かエラーか）を分類し、最終的な1つのテストを選択するためのタイブレーク（同点決勝）としてコードカバレッジ（パッチによって追加または削除された行の割合）を使用します。

主な貢献
本論文は、以下の3つの新規な貢献を行っています。

実行増強型テスト修復： 実行フィードバックを用いて関連するコードを取得し、修復プロンプトを拡張することで、テストがイシューで指定された理由で失敗するようにし、テストの正確性を高める手法。
多様性のためのヘテロジニアス・プロンプティング： 高温サンプリングのみに頼るのではなく、イシュー記述のモーフィングとコンテキスト・マスクを通じて、テスト候補の多様性を高める手法。
サロゲート・パッチによる選択： 不完全な生成コードパッチからの実行フィードバックを、グラウンドトゥルース（正解）の修正のプロキシ（代理）として使用して、最終的なテストを選択する技術。

結果
システムは、SWE-bench から派生した TDD-Bench Verified（449サンプル）および SWT-bench Lite（276サンプル）で評価されました。

パフォーマンス： e-Otter++ は、Claude-3.7-Sonnet モデルを使用し、TDD-Bench Verified で 63.0%、SWT-bench Lite で 52.5% という最先端の Fail-to-Pass ( $F \to P$ ) 率を達成しました。これは、従来の最高水準の結果（Otter++ のそれぞれ 37.0% および 29.0%）を大幅に上回っています。
コンポーネントの有効性：
- 実行増強型修復により、異なる構成において $F \to P$ 率が 11.1% から 74.3% まで向上しました。
- ヘテロジニアス・プロンプティング（モーフィング + マスク）は、マスクのみを使用した場合と比較して、 $F \to P@N$ （ $N$ 個の候補のうち少なくとも1つの成功率）を 13% 以上向上させました。
- 生成されたコードパッチをテスト選択の事前フィルタとして使用することで、大幅な性能向上が得られました（例：TDD-Bench Verified において $F \to P$ が 32.9% 向上）。
汎用性： コンタミネーション（データ汚染）のないベンチマークである SWE-rebench においても検証されており、ベースとなる Otter システムに対して $F \to P$ 率を相対的に 75% 向上させており、データ汚染に対する堅牢性を示しています。
検証の有用性： 生成されたテストは、他の SWE エージェントのコードパッチを効果的に検証できることが示されており、トップリーダーボードのシステムの提案するソリューションの精度を大幅に向上させています。

意義と主張
著者らは、e-Otter++ が SWE イシューからの再現テスト生成における最先端技術の大きな飛躍を象徴していると主張しています。本論文は、ヘテロジニアス・プロンプティングと実行フィードバック（特に、選択のためのサロゲート・パッチの斬新な使用とコンテキスト増強型修復）の組み合わせが、テストの多様性と検証のためのターゲット・コードベースの欠如という、従来の手法が直面していた限界を克服することを論じています。

本研究の目的は、再現テストの作成という退屈な作業を自動化することで、テスト駆動開発（TDD）の実践を定着させ、イシュー解決および長期的な品質保証における人間および自動化された SWE エージェントの両方を支援することにあります。著者らは、現在のシステムは単一のテストファイルしか扱えず、主に Python で評価されているという範囲の限定性については謙虚な姿勢を保ちつつも、相対的な改善が、これらの手法が非汚染で多様なデータセットにおいても効果的であることを示唆していると強調しています。