バグ再現テストを書かせると目標がズレる「Goal Drift」──DPIAgentが分業で対処した81.76%という数字

バグ報告を渡して「まず失敗し、修正後は成功するテストを書いて」と指示するタスクは、自動化されたソフトウェア工学における重要な一歩とされる。だがこの作業を1つの連続したループでエージェントにやらせると、途中で目標がズレていく現象があると、arXivで2026年8月24日に公開された論文（arXiv:2608.23341）が指摘している。著者は11名で、筆頭著者はHao Liu氏。所属はMicrosoftとTsinghua University（清華大学）。

3行まとめ

• バグ再現テスト生成は「根本原因の診断」と「fail-to-passテストの作成」という性質の異なる2つのサブタスクからなるが、既存のエージェント手法はこれを単一の複合目標として扱い、目標のズレ（Goal Drift）を招きやすいと指摘
• SWT-Bench Verified（SWE-Benchから構築された433インスタンス）で、GPT-5-Mini・GPT-5・Claude-Opus-4.5の3基盤LLM×7ベースラインと比較。GPT-5-Miniでは最高スコアのベースラインに+11.88ポイントの差をつけたが、Claude-Opus-4.5ではその差はわずか+1.38ポイントまで縮む
• 論文全文のTable 1（Performance results on SWT-Bench Verified）を読むと、GPT-5ではOpenHands（79.80%）がDPIAgent（81.76%）に肉薄しており、要旨だけでは見えない「基盤モデルが強くなるほど手法間の差が縮む」傾向が数字から読み取れる

「Goal Drift」とは何を指しているか

論文のアブストラクトは、問題の所在をこう説明している。

Without explicit separation, the agent faces a compound objective with underspecified intermediate goals, leading to goal drift.

（明示的な分離がない場合、エージェントは中間目標が不明確な複合目的に直面し、目標のズレ（goal drift）につながる）

つまり「原因を突き止める」と「テストを書く」という別々の性質のタスクを、区切りのないまま1つのループでエージェントにやらせると、どちらの目標も中途半端になりやすいという指摘だ。これに対しDPIAgentは、3つの原則で構造化している。

• Divide（分割）：タスクを「欠陥の探索」と「テスト生成」という単一目的のフェーズに分ける
• Protocol（プロトコル）：フェーズ間の引き継ぎで、診断結果とテスト計画を記録するプロトコルを強制し、文脈の喪失を防ぐ
• Isolate（分離）：各フェーズのツールセットをそのタスクに合わせて絞り込み、無関係なツールが実行を誤らせないようにする

ベンチマークの数字

評価に使われているのは「SWT-Bench Verified」というベンチマークで、7つのベースライン・3つの基盤LLMを横断してDPIAgentを比較している。論文が報告する主な数字は次の通りだ。

• DPI単体（テスト選択なし）：GPT-5使用時に成功率**81.76%**を達成。オープンソース手法の中で最高値と主張
• GPT-5-Miniでは、最も強いベースラインに対して最大11.88ポイントの改善
• テスト選択機能を追加すると成功率は**86.17%**まで向上

論文は「アーキテクチャの構造とベースLLMの能力は代替可能な軸ではなく、補完的な軸である」とも主張しており、モデルを強くするだけでなく、タスクの構造化そのものに改善余地があるという含意を持たせている。

論文全文のTable 1（Performance results on SWT-Bench Verified）には、基盤LLMごとにDPIAgent（Ours）と主要ベースラインの成功率（S、%）が並んでいる。抜粋すると次の通りだ。

（出典：DPIAgent論文全文 Table 1。7ベースラインはSWE-Agent・Mini-SWE-Agent・OpenHands・Claude Code・Aider・Terminus-2・TraeAgent）

この表から読み取れるのは、要旨で強調される「81.76%・GPT-5で最高値」という数字だけでは見えない構図だ。基盤モデルが弱いGPT-5-Miniでは、タスクを分割・分離するDPIの設計が11.88ポイントという大きな差を生んでいる一方、基盤モデルがGPT-5・Claude-Opus-4.5と強くなるにつれて、その差は2ポイント前後まで縮んでいる。「アーキテクチャと基盤モデル能力は補完的な軸」という論文の主張は、裏を返せば「基盤モデルが十分強ければ、この構造化の効果は相対的に小さくなる」とも読める。

どの原則が効いているか（Table 3のablation）

論文6章のablation studyは、DPIから3原則（Divide／Protocol／Isolate）を1つずつ取り除いた場合の成功率(S)・テストカバレッジ関連指標(Cov.)を、GPT-5-Mini・Claude-Opus-4.5の両方で計測している。

（出典：DPIAgent論文全文 Table 3。S=成功率、Cov.=テストカバレッジ関連指標）

3原則のうち、取り除いたときに最も成績が落ちるのは**Divide（診断とテスト作成の分割）**だ。Claude-Opus-4.5ではSが78.98%→69.05%（-9.93pt）、Cov.も89.52→75.96（-13.56pt）と、3つの中で最大の下げ幅になっている。論文はこれを「Divideはリポジトリ理解とテスト生成を分離し、各フェーズが単一の目的に集中できるようにする。単一の反応的ループに統合すると、両バックボーンの全指標で大きく低下する」と説明している。

「ツールを足しただけ」では再現できない

論文はさらに、DPIの効果が「フェーズを分けるという構造」自体から来るのか、それとも「個々のツールの違い」から来るのかを切り分ける実験（Table 4）も行っている。素のSWE-Agentベースラインに、DPIが使う個々の要素（コード検索ツールの追加、構造化された要約プロンプトの追加、フェーズ移行ツールの追加）を1つずつ足していったが、いずれも単独ではDPI本体ほどの改善を再現できなかった（要約プロンプトを足しただけでは成功率が-5.16ptとむしろ悪化）。一方、DPIの「フェーズ構造」だけを標準的なSWE-Agentのツールセットに適用すると、個々のツール追加より大きな改善（成功率+12.85pt）が得られたという。論文はこれを「DPIの利得は、実装上のツールの違いではなく、実行可能なフェーズの境界そのものが主因である」とまとめている。

論文自身が書いている限界と、SWT-Benchの由来

論文の付録D「Limitations」には、著者自身による限界の記載がある。

Our evaluation focuses on Python repositories from SWT-Bench; while the DPI principles are language-agnostic, validating on additional languages remains future work. Additionally, like all LLM-based approaches, inference cost scales with repository size, and further efficiency improvements are possible through more selective context management strategies.

（評価はSWT-BenchのPythonリポジトリに限定されている。DPIの原則自体は言語に依存しないと考えられるが、他言語での検証は今後の課題として残されている。また、他のLLMベースの手法と同様、推論コストはリポジトリの規模に応じて増大し、より選択的なコンテキスト管理戦略によってさらなる効率化の余地がある）

「Pythonリポジトリに限定」という限界の背景には、SWT-Bench自体の成り立ちがある。SWT-Benchは、論文が引用するSWE-Bench原論文（実世界のGitHub issueとPRから構築された評価フレームワーク）をもとに構築されており、SWE-Bench原論文をあらためて確認すると、収録されているのは「12の著名なPythonリポジトリ」から集めた2,294件のソフトウェア工学タスクだと明記されている。つまりSWT-Bench Verifiedも、この12リポジトリを継承したPython限定のベンチマークであり、DPIAgentの81.76%という数字はこの範囲内でのものだ、という点は覚えておきたい。

コーディングエージェントを日常的に使う上での示唆

Goal Driftという現象自体は、バグ再現テスト生成に限らず「原因調査」と「成果物作成」が混在するあらゆるエージェントタスクに起こり得る一般的な失敗パターンだと読める。自分がClaude Codeやその他のコーディングエージェントに複雑な作業を任せるとき、「まず原因を調べさせてから、別のプロンプトで対処させる」という分割統治のアプローチは、この論文が挙げる問題への対症療法として理にかなっている。ただし、この論文自体はDPIAgentという特定の実装・評価環境での結果であり、汎用的なコーディングエージェントの使い方に一般化できると論文自身が主張しているわけではない。

コードは確認できず、公式プロジェクトページも要旨以上の詳細は無かった

論文全文を確認したことで、SWT-Bench Verified（433インスタンス、SWE-Benchから構築）・7ベースラインの名称・3基盤LLMの内訳までは判明した。一方、DPIAgentのソースコードを公開するGitHubリポジトリへのリンクは、論文本文にも公式プロジェクトページ（neverwinhao.github.io/DPIAgent）にも見当たらず、本記事の範囲では発見できなかった。そのため、DPIAgentを実際に動かして自分の手元で再現したわけではなく、論文が報告する数字をそのまま引いている。「Goal Drift」という現象が、バグ再現テスト生成以外のエージェントタスクにもどの程度一般的に当てはまるかについても、論文自身がSWT-Bench Verifiedという単一タスクの範囲で主張しているものであり、本記事もその範囲を超えた一般化はしていない。

関連記事: AIコーディングアシスタント比較 / Claude Codeがエラーで動かない時の切り分け手順 / AIエージェントとは

感想・指摘はコメント欄へ。