技術要約: SWE-INTERACT

問題提起

現在の最先端ソフトウェアエンジニアリング（SWE）ベンチマークは、主に単発（single-turn）の自律的な実装タスクにおけるコーディングエージェントの評価に焦点を当てています。これらの設定では、エージェントは事前に完全かつ詳細に規定された要件を受け取り、独立してソリューションを実行する能力に基づいて評価されます。しかし、実際の開発者とエージェントの相互作用（例：SWE-chat）に関する大規模な研究は、現実のワークフローが単発的なものではないことを明らかにしています。実際には、ユーザーが曖昧または不完全な初期指示を提供し、エージェントのワークスペースを検査し、ターゲットを絞ったフィードバックや修正を通じて段階的に要件を明らかにしていく、反復的なマルチターン・ループが含まれます。

ユーザーがループ内に介在する相互作用をシミュレートしようとする既存のベンチマークは、詳細なプロンプトから開始したり、コードの検査やコマンドの実行ができない静的で非エージェント的な「ユーザー」を使用したりすることで、問題を簡略化してしまう傾向があります。これにより、ベンチマークのパフォーマンスと、エージェントが意図を推論し、進化する制約に適応し、開始時に完全な仕様がない状態で自身の先行作業を洗練させなければならない**インタラクティブな目標発見（interactive goal discovery）**という現実との間に乖離が生じています。

手法: SWE-INTERACT

著者らは、SWEベンチマークをユーザー主導の長期的なコーディングセッションとして再定義するために設計された、新しいテストベッドであるSWE-INTERACTを導入しています。この手法は、以下の3つのコアコンポーネントで構成されています。

1. タスクの適応（Task Adaptation）

著者らは、3つの既存の最先端ベンチマーク（SWE-bench Pro、SWE Atlas、DeepSWE）から75のタスクを適応させました。これらは元々、完全な仕様を持つ単発のタスクでした。これらを、詳細な要件を削ぎ落とし、高レベルで曖昧な記述のみを残すことで、マルチターン型のタスクへと変換しました。

2. ユーザーシミュレータ

重要な革新は、実際のコーディングセッション（SWE-chat）のデータに基づいたペルソナ条件付きユーザーシミュレータです。

• ペルソナ: 「エキスパート・ニッティピッカー（Expert Nitpicker）」ペルソナをモデルとしており、短く直接的で反復的なコミュニケーションを特徴とします。このユーザーはコードを書きませんが、実装を批判し、特定のAPIの詳細を求め、要件を一つずつ明らかにしていきます。
• エージェント機能: 従来の静的なシミュレータとは異なり、このユーザーエージェントはエージェントのワークスペースへのシェルアクセス権を持っています。ユーザーは、差分（diff）を検査したり、コードベースを検索したり、エージェントの作業を検証したりするために、コマンド（例：git, grep, sed）を実行できます。
• 相互作用フロー: ワークフローは、GOAL-DISCOVERY（目標発見） → PLAN（計画） → APPROVAL（承認） → IMPLEMENT（実装） → REVISE（修正） → SUBMIT（提出）のループに従います。ユーザーは曖昧な要求から開始し、エージェントの計画をレビューし、ワークスペースを検査し、タスクが完全に引き渡されるまで、潜在的な要件を段階的に表面化させます。

3. 評価フレームワーク

タスクは、コンテナ化されたサンドボックス内のHarborフレームワークで実行されます。

• 検証: 成功の判定は、ユーザーシミュレータによる承認ではなく、ソースベンチマークからの元のタスク検証器（ユニットテストおよびルーブリック）によって行われます。これにより、相互作用の難易度と実装の難易度を分離しています。
• 指標: 研究では、解決率、相互作用ステップ数、トークン使用量、コスト、および特定の失敗モード（例：要件の失念、技術的バグ）を追跡します。

主な貢献

1. 新しいテストベッド: 静的なベンチマークを動的なユーザー主導のワークフローに変換するハーネスを備えた、75のマルチターン・タスク・スイート。
2. エージェント型ユーザーシミュレータ: 静的なAPIコールを超え、ワークスペースの検査や反復的な批判を含む、現実的な開発者の振る舞いを模倣する、現実的なユーザーエージェントを作成するためのフレームワーク。
3. 包括的な分析: トラジェクタリ分析、目標発見スコアリング、失敗モードの分類を含む、マルチターン設定におけるエージェント能力の詳細な分解。

実験結果

著者らは、いくつかの最先端モデル（GPT 5.5, Opus 4.8, Kimi K2.6, Gemini 3.5 Flash, Sonnet 4.6）を、単発のベースラインと新しいマルチターンSWE-INTERACTタスクの両方で評価しました。

パフォーマンスの乖離

• 解決率: 強力な単発のパフォーマンスは、マルチターン設定に必ずしも転移しません。トップモデルは単発のベースラインで約**50%の解決率を達成しましたが、マルチターンの設定では約25〜27%**に低下しました。
• リソース消費: マルチターン・タスクは大幅に多くのリソースを必要としました。エージェントは単発のベースラインと比較して、3〜4倍のステップを要し、2〜4倍のトークンを使用し、試行あたりのコストが2〜3.5倍高くなりました。
• モデル間の差異:
  • トップパフォーマー: GPT 5.5とOpus 4.8は、曖昧な指示に対しても強力に開始し、曖昧さに耐え抜き、要件をうまく統合しましたが、依然として技術的バグや要件の失念に悩まされました。
  • 弱めのモデル: Kimi K2.6やSonnet 4.6のようなモデルは、曖昧さの下で著しく苦戦し、早期に諦めたり、指示を無視したり、コードを効果的に洗練させることに失敗したりすることがよくありました。

目標発見 vs 実装

• 計画: 強力なモデル（例：GPT 5.5）は、初期の計画フェーズにおいて高い割合（>80%）の潜在的な目標を特定しました。
• 実装時の低下: 計画から最初の実装チェックポイントへ移行する際に、技術的なエラーや仕様の漏れにより、目標カバー率が大幅に低下しました。
• 回復: ほとんどのモデルは、ユーザーが漏れた要件を明らかにするにつれて、その後のターンで目標カバー率を回復しましたが、最終的な実装は技術的バグやデグレ（退行）のために、依然として検証器に失敗することが多くありました。

失敗モード

287件の失敗したトラジェトリの監査により、主な失敗原因が明らかになりました。

• 技術的な実装バグ（~34%）: エージェントは要件を理解していましたが、コードエラーを導入しました。
• 要件の失念（~34%）: 前のターンで導入された要件の実装に失敗しました。
• 誤解/不適切な仮定（~14%）: エージェントが要件を誤解したか、明確化することなく誤った仮定を立てました。
• 不足しているユーザー要件（~12%）: シミュレータが必要な要件を提示できなかったケース（ベンチマークの偽陰性）。

アブレーション研究

• ペルソナの影響: 「エキスパート・ニッティピッカー」ペルソナの使用（中立的なベースラインと比較して）は、タスクをより困難かつ長くし、相互作用ステップを30〜50%増加させ、ほとんどのモデルの解決率を低下させました。これは、理想化された相互作用と現実的な相互作用の間のギャップを浮き彫りにしました。
• シミュレータモデル: 使用するユーザーシミュレータのモデル（GPT 5.5 vs Opus 4.7）は、リアリズムに大きく影響しました。GPT 5.5はより厳格な批評家として機能し、より多くのターンにわたって要件を明らかにし、ワークスペースをより深く検査しました。これにより、エージェントの最終的なパフォーマンスは向上しましたが、トラジェトリは長くなりました。

意義と主張

本論文は、SWE-INTERACTが、最先端モデルの開発における直交する能力軸である「ユーザーが介在する中でのインタラクティブな目標発見と反復的な洗練」を測定するものであると主張しています。

著者らは、ユーザーと効果的に協力することは、単に自律的なコーディングを長くしたものなのではなく、明確に異なるスキルセットであると論じています。結果は、最先端モデルは曖昧さの中でも粘り強く、修正を通じてほとんどの意図された目標を回復できる一方で、フィードバックが蓄積するにつれて正しい実装を維持することには依然として苦慮していることを示唆しています。本論文は、SWE-INTERACTを、この特定の能力を研究するためのより鋭利な道具として位置づけ、現実的なソフトウェアエンジニアリングのワークフローにおいて、より信頼性の高いコラボレーションができるコーディングエージェントの開発を導くことを目的としています。