@2026__arXiv__SWE-Together - Evaluating Coding Agents in Interactive User Sessions

# SWE-Together: Evaluating Coding Agents in Interactive User Sessions > [!abstract] 概要 > 大半のコーディングエージェントベンチマークは静的である。すなわち、エージェントは冒頭で完全なタスク記述を受け取り、最終的なコードのみによって判定される。現実のコーディング支援は対話的であり、ユーザーは複数ターンにわたり目標を明確化し、制約を追加し、誤りを修正する。我々は、実際のユーザーとエージェント間のコーディングセッションから再構成されたマルチターンベンチマークである SWE-Together を導入する。現実のインタラクションを検証可能にするため、我々は11,260件の記録されたセッションから、復元可能なリポジトリ状態、明確なユーザー目標、および観察可能な成果物を持つセッションを選択し、109件のリポジトリレベルタスクを精選した。これらのインタラクションを異なるエージェント間でリプレイ可能にするため、我々は元のユーザーの意図を保持し、コーディングエージェントの進捗状況が要求したときにフィードバックを提供する、リアクティブなLLMベースのユーザーシミュレータを構築した。協働者としてのエージェントを評価するため、我々は最終的なリポジトリの正しさと、対話中に必要とされた修正フィードバックのターン数の双方を測定する。フロンティアコーディングエージェントを用いた実験により、より強力なエージェントは一般に、より少ない介入回数でより高い最終成功率を達成することが示され、ユーザー体験の向上が示唆される。 ## 論文情報 - **タイトル**: SWE-Together: Evaluating Coding Agents in Interactive User Sessions - **著者**: Yifan Wu\*, Zhuokai Zhao, Songlin Li, Ho Hin Lee, Jiacheng Zhu, Shirley Wu, Tianhe Yu, Serena Li, Lizhu Zhang, Xiangjun Fan, Shengzhi Li\* (\* Project Co-Lead) - **所属**: [[Meta]] - **公開日**: 2026-06-30 (arXiv:2606.29957v1, 2026-06-29) - **リンク**: [arXiv:2606.29957](https://arxiv.org/abs/2606.29957), [コード(GitHub)](https://github.com/Togetherbench/SWE-Together), [ウェブサイト](https://togetherbench.com) ## 概要 [[SWE-Together]] は、実開発者のコーディングセッションログ（11,260 件）から精選された 109 件のリポジトリレベルタスクを用い、対話型コーディングエージェントを評価するマルチターンベンチマークである。エージェントの推論・行動軌跡に応動する状態条件付き LLM ユーザーシミュレータを導入し、最終成果物の正しさ（Rubric Judge）と人間側が強いられる修正負担（User Correction）の二軸でエージェントを多面的に評価する。フロンティアモデル 7 種の評価実験により、モデル能力（pass@1）とユーザー修正回数に強い負の相関（Pearson $r = -0.92$）が確認され、優れたモデルほど少ない人間の介入で正解に到達することを実証した。 ## 問題設定従来のコーディングエージェントベンチマーク（[[SWE-Bench-Verified]]、[[SWE-bench Pro]]、Terminal-Bench 等）は静的プロトコルに依存している。すなわち、冒頭で完全なタスク記述を与え、エージェントが提出したコードに対するテスト実行のみで成否を判定する。しかし、このプロトコルには現実のソフトウェア開発現場との間に二重の乖離が存在する。 1. **タスク設計の乖離**: 現実のコーディング支援は本質的に対話的（interactive）である。開発者は初期プロンプトで粗い要求を出し、複数ターンにわたって意図を小出しに開示し、制約を追加し、エージェントの中間生成物の誤りを修正する。 2. **評価設計の乖離**: 従来の評価は最終タスクの成否（outcome correctness）のみを測定し、対話の質やユーザーが要した労力（human effort）を考慮しない。同一の最終スコアであっても、「粗い指示だけで完遂したエージェント」と「度重なる修正や誘導を必要としたエージェント」では開発者体験が根本的に異なる。この問題に対処する際の核心的課題は、「現実の対話の再現性と検証可能性（verifiability）の両立」にある。生のセッションログはリポジトリの復元性欠如や外部依存（PR 作成、デプロイ、非公開認証情報など）を含み、さらに過去のユーザー発言をそのまま固定リプレイすると、評価対象エージェントの行動差によって対話が破綻・漂流（drift）する。したがって、検証可能なタスク構築と、エージェント軌跡に応動する制御されたリプレイ機構の双方が不可欠となる。 ![[fig01-benchmark-workflow-comparison.png]] 図 1 (Figure 1): SWE-Together の概念と既存ベンチマークとの比較。上段の静的ベンチマーク（固定課題記述→一括コード生成→テスト判定）に対し、下段の SWE-Together は対話セッションからタスクを構築し、エージェントの進行に応じてユーザーシミュレータが介入する。また正解率だけでなく User Correction（平均修正回数）を重ね合わせて評価する。 ## 提案手法 SWE-Together は以下の 3 つの中核コンポーネントから構成される。 ### 1. セッションからタスクへの構築パイプラインアップストリームの 4 つの実セッションコーパス（表 1 (Table 1)）から、3 段階のファンネル（図 2 (Figure 2)）を経て検証可能タスクを構築する。 | ソース | データセット概要 | 生セッション数 | 最終タスク数 | |---|---|---|---| | DataClaw (2026) | コミュニティ寄贈の 32 データセット | 2,228 | 29 | | Pi-staging (2026) | Pi staging パイプライン由来の 29 データセット | 2,397 | 23 | | Hyperswitch (2026) | 本番決済コードベースからのトレース | 784 | 9 | | SWE-chat (2026) | 複数エージェントハーネスにまたがるセッション | 5,851 | 48 | | **合計** | | **11,260** | **109** | 表 1 (Table 1): SWE-Together を構築するために使用された実セッションデータセット。最終タスク化率は 0.97%（109/11,260）と極めて高精度に絞り込まれている。 ![[fig02-task-construction-funnel.png]] 図 2 (Figure 2): セッションからタスクへの構築パイプライン。決定論的フィルタリング（Step 1）、実現可能性スクリーニング（Step 2）、サンドボックス内タスク生成（Step 3）の 3 段階ファンネル。 - **Step 1（決定論的適格性フィルタリング）**: ルールベース処理。複数回のユーザー発言、具体的なコード変更アクション、特定可能なリポジトリコンテキスト、成熟した公開 GitHub リポジトリを要求。最終コードが人間によって書かれたセッションを除外し、エージェントが実質的な実装を行ったセッションのみを保持する。 - **Step 2（実現可能性スクリーニング）**: LLM 判定。PR 管理、イシュートリアージ、外部デプロイ、認証情報、ライブサービス状態などの外部依存を排除し、ローカル環境で完結・再現可能な成果物を持つセッションを選別する。 - **Step 3（タスク構築）**: ホストオーケストレータが隔離サンドボックスを起動し、タスク生成エージェントが固定コミットでクローン、検証コマンド特定、テスト作成、シミュレータプロンプト生成、監査を実施（図 3 (Figure 3)）。 ![[fig03-task-construction-workflow.png]] 図 3 (Figure 3): タスク構築ワークフロー。ホストオーケストレータがサンドボックスを起動し、エージェントが検証コマンド特定・テスト作成・シミュレータプロンプト生成・タスク監査を実行してタスクパッケージを出力する。 ### 2. 状態条件付き LLM ユーザーシミュレータエージェントの各ターン終了時に、シミュレータが 1 回呼び出され、構造化された 5 つのアクション（`no-op`, `question`, `redirect`, `new-requirement`, `check-external`）から 1 つを選択する。 - 既定行動は `no-op` であり、エージェントの自律的な進行を妨げず、元の追加メッセージを無駄に消費しない。 - コンテキスト設計（図 4 (Figure 4)）は「固定セッションアンカー（ペルソナ、元の意図、メッセージマップ）」、「現ターンのサマリー（直近エージェント行動、出力、差分、経過時間）」、「シミュレータメモリ（過去の決定履歴、発言カウンタ）」の 3 要素を統合する。 - スケジュール固定ではなくエージェント軌跡に応動し、かつ自由ロールプレイではなく元セッションの意図・トリガー条件に厳密に接地（anchored）させることで、対話の漂流を防ぐ。 ![[fig04-user-simulator-context.png]] 図 4 (Figure 4): ユーザーシミュレータが参照するコンテキスト構造。固定セッションアンカー、現ターンのサマリー、シミュレータメモリを統合し、構造化された単一アクションを出力する。 ### 3. 正解性と対話診断の二次元評価プロトコル評価は成果物の正しさとリプレイ過程の診断に明確に分離される（図 5 (Figure 5)）。 ![[fig05-correctness-plus-interaction-diagnostics.png]] 図 5 (Figure 5): 正しさ指標とインタラクション診断の分離構造。最終正しさは提出リポジトリ状態を評価し、インタラクション診断はリプレイ過程を評価する。 - **Task Correctness（タスク正解性）**: 単一テスト実行の限界（過度に狭いテストによる正当な別解の拒否や、過度に広いテストによる未要求動作の強制）を避けるため、決定論的ベリファイアと二段階のエージェント型 Rubric Judge を併用。 - Phase 1 でタスクごとにオフラインで実装非依存の行動目標群 $g$ と正規化重み $w_g$（$\sum w_g = 1$）を固定定義。 - Phase 2 で提出状態が各目標を満たしたか二値判定し、スコアを算出: $\text{score} = \text{round}\left(\sum_g w_g I[g\ \text{met}], 2\right)$ - **User Simulation Behavior（対話診断）**: - **Intent Coverage（シミュレータ忠実度）**: 元セッションの意図再現率 $I_{\text{recall}}$ とスコープ適合率 $I_{\text{precision}}$ を結合: $\text{IntentCoverage} = \text{round}(0.70 I_{\text{recall}} + 0.30 I_{\text{precision}}, 2)$ - **User Correction（修正負担）**: シミュレータ発話のマルチラベル分類に基づき、明示的誤り指摘 $N_{\text{correction}}$（重み 1.0）と疑念・誘導 $N_{\text{nudge}}$（重み 0.2）を合算: $\text{UserCorrection} = N_{\text{correction}} + 0.2 N_{\text{nudge}}$ ## 新規性 SWE-Together は、コーディングエージェント評価において以下の先駆的な新規性を持つ（表 3 (Table 3) に位置づけを総括）。 | ベンチマーク | リポジトリレベル | 環境マルチターン | 対話リプレイ | 実タスクソース | 実ユーザーセッション | |---|---|---|---|---|---| | SWE-bench 系列 (2024–2026) | ✓ | ✓ | ✗ | ✓ | ✗ | | Terminal-Bench (2026) | ✗ | ✓ | ✗ | ✗ | ✗ | | MINT / ConvCodeWorld (2024–2025) | ✗ | ▲ | ✓ | ✗ | ✗ | | CodeAssistBench (2025) | ✓ | ✓ | ✓ | ✓ | ✗ | | RECODE-H / FronTalk (2025–2026) | ▲ | ▲ | ✓ | ▲ | ✗ | | BigCodeArena / CodeChat (2025) | ♦ | ♦ | ▲ | ✓ | ✓ | | SWE-chat (2026) | ✓ | ✓ | ✗ | ✓ | ✓ | | **SWE-Together (本書)** | **✓** | **✓** | **✓** | **✓** | **✓** | 表 3 (Table 3): 代表的コーディングエージェントベンチマークにおける SWE-Together の位置づけ。✓=対応、✗=非対応、▲=部分的、♦=混在。 1. **実セッション由来のリポジトリレベル対話評価**: 従来の対話型ベンチマークが合成課題や issue から生成されたロールプレイに頼っていたのに対し、11,260 件の現実の開発者対話から検証可能タスクを構築した初のベンチマーク。 2. **状態条件付きアンカー型シミュレータ**: `no-op` を基軸とする構造化アクションとメモリ管理により、エージェント行動に応動しつつも元の課題スコープから逸脱しないリプレイを実現。 3. **能力と人間介入コストの同時測定**: 最終パッチの正当性だけでなく、ユーザーが支払った修正コスト（User Correction）を定式化。 ## 実験設定 - **タスク数**: 109 タスク（全タスクで共通ハーネス `opencode` を使用、試行回数 $k = 2$ レプリケート）。 - **評価対象モデル**: Claude Opus 4.8、GPT-5.5、Claude Opus 4.6、GLM-5.2、GLM-5.1、DeepSeek-V4-Pro、MiniMax-2.7 のフロンティア 7 種、および参照パッチ（Reference）。 - **主要評価指標（成功閾値 $\tau = 0.85$）**: - pass@1: 1 試行あたりの平均成功率（マージナル確率）。 - SSR (Stable Solve Rate): タスク内のスコア平均値 $\bar{j}_t \geq \tau$ となる割合（安定解決率）。 - pass2: 2 回連続で成功したタスクの割合（最も厳格な一貫性指標）。 - MeanJudge: 連続スコア（0〜1）の平均値。 - U-Corr (User Correction): 試行あたりの平均修正ターン数（低いほど良い）。 - 効率: タスクあたりの平均出力・推論トークン数、壁時計時間（分）。 ## 実験結果表 2 (Table 2) に 109 タスク全件における実験結果を示す。 | 順位 | モデル | pass@1↑ | SSR↑ | pass2↑ | Mean judge↑ | U-Corr↓ | トークン/タスク | 時間(分)/タスク | |---|---|---|---|---|---|---|---|---| | ⋆ | Reference (Oracle) | ∼78% | ∼78% | ∼78% | 0.90 | — | — | — | | 1 | **Claude Opus 4.8** | **63%** | **59%** | **52%** | **0.801** | **1.38** | 74.0k | 23.3 | | 2 | GPT-5.5 | 58% | 55% | 48% | 0.763 | 1.59 | **29.9k** | **10.7** | | 3 | Claude Opus 4.6 | 58% | 58% | 46% | 0.755 | 1.59 | 42.0k | 23.2 | | 4 | GLM-5.2 | 55% | 48% | 42% | 0.735 | 1.53 | 41.7k | 24.5 | | 5 | GLM-5.1 | 52% | 49% | 35% | 0.729 | 1.54 | 41.6k | 38.8 | | 6 | DeepSeek-V4-Pro | 48% | 38% | 29% | 0.679 | 1.76 | 49.8k | 21.0 | | 7 | MiniMax-2.7 | 40% | 34% | 26% | 0.630 | 2.17 | 43.4k | 36.2 | 表 2 (Table 2): SWE-Together 109 タスクにおけるフロンティアモデルの評価結果（$k=2$ レプリケート）。Mean judge スコア順にソート。太字は最良値を示す。 ### 1. モデル性能とランキング - **Claude Opus 4.8** が全正解性指標（pass@1 63%, SSR 59%, pass2 52%, Mean judge 0.801）および最小修正回数（U-Corr 1.38）で首位を達成。ただし参照パッチ（~78%）に対しては約 15 ポイントの改善余地が残る。 - **GPT-5.5** は 2 位（Mean judge 0.763）で Opus 4.6 と拮抗。特筆すべきは圧倒的な効率性であり、Opus 4.8 の半分以下のトークン数（29.9k）かつ最短の実行時間（10.7 分/タスク）を記録。 - **GLM-5.2** と **GLM-5.1** は中位群を形成。GLM-5.2 は pass2（42% vs 35%）で優れ、実行間の安定性が向上。 - **DeepSeek-V4-Pro**（pass@1 48%）と **MiniMax-2.7**（pass@1 40%）が下位となり、MiniMax は修正回数も最多（2.17 回）。 ### 2. モデル能力と修正負担の逆相関 User Correction はエージェント能力と強い負の相関を示す（図 6 (Figure 6)）。 - pass@1 との相関: Pearson $r = -0.92$ - SSR との相関: Pearson $r = -0.84$ - Mean judge との相関: Pearson $r = -0.93$ 修正発生サブセット（active subset）や高難度サブセット（hard subset）においても同様の傾向が維持され、「優秀なモデルほど人間側の修正フィードバックを必要としない」という仮説が実証された。 ![[fig06-capability-vs-user-correction.png]] 図 6 (Figure 6): モデル能力（左: pass@1、右: SSR）と試行あたり User Correction の関係。全 109 タスク、修正発生サブセット、高難度サブセットのいずれにおいても強い負の相関（Pearson -0.92, -0.84）が確認できる。 ### 3. コストと効率の分析図 7 (Figure 7) は安定解決率（SSR）に対する壁時計時間とトークン数の関係を示す。効率と能力は緩やかにしか結合しておらず、GPT-5.5 が高効率・高能力の最良バランス（左上）に位置する一方、Opus 4.8 は最大トークン消費（74.0k）により最高精度を達成している。 ![[fig07-solve-rate-vs-cost.png]] 図 7 (Figure 7): 7 モデルの Stable Solve Rate とコストの関係。所要時間（左）および出力＋推論トークン数（右）。左上が高能力・低コストの理想領域。 ### 4. シミュレータの一貫性と品質検証 - **Intent Coverage**: 7 モデル中 6 モデルで 0.70〜0.72（Recall 0.72〜0.74、Precision 0.66〜0.72）の極めて狭い範囲に収束。エージェントの違いによらずシミュレータが元意図を一貫して再現している。GPT-5.5 の 0.68 は、エージェントが自律的に問題を即座に解決したことで追加発言の余地が減少したことに起因。 - **チューリングテスト（人間評価）**: 4 名の評価者が実ユーザーとシミュレータの対話軌跡 156 ペア（312 判定）を識別する二者択一実験を行った結果、シミュレータが本物と判定された割合（Turing pass rate）は **46%**（95% 信頼区間 [40.5, 51.6]%）であった。信頼区間に 50%（偶然水準）が含まれており、人間評価者にはシミュレータと本物の人間が統計的に区別不可能であることが実証された。 ## 考察 ### 参照パッチ（Oracle）が 100% に達しない要因参照パッチは 93 タスクで Mean judge 0.90、pass rate ~78%（57 タスクで満点 1.0、73 タスクで合格）にとどまり、20 タスクで閾値 0.85 を下回った。この理由として以下の 3 点が特定されている。 1. **プロセス要件の存在（約 35%）**: ルーブリックが元セッションから継承した「修正前に原因を診断する」「ユーザーの追加質問に回答する」「修正内容を説明する」などの対話プロセス要件は、最終的なコードパッチ単体では表現できないため減点対象となる。 2. **抽出パイプラインのノイズ**: 複数コミットや複数セッションにまたがる修正の一部が欠落したケース。 3. **人間による不完全な修正**: 元セッションの開発者が主要なバグを残したまま終了したケースを、Judge が正当に検知して減点した例。これらは全評価エージェントにも同一のルーブリックで適用されるため、公平な比較基準として機能している。 ### 開発者体験（DevEx）における「修正負担」の定式化本研究が投じた最大の洞察は、「正解率（Outcome）だけでなく、そこに到達するまでの人間側の認知的・対話的負担（Process Cost）を測らなければ、実用的なエージェント評価にならない」という点である。同一の pass@1 を持つモデルであっても、自律的に文脈を汲み取れるエージェントと、逐一誤りを指摘しなければならないエージェントの価値差を User Correction 指標によって初めて客観的に弁別可能となった。 ## 強み / 弱点・課題 ### 強み - **実務接地の高さ**: 11,260 件の実開発者セッションから厳選されたリアルなコード修正課題。 - **自律的リプレイ**: `no-op` を備えた状態条件付きシミュレータにより、エージェントの自由度を奪わずに意図のドリフトを防止。 - **人間識別不能な自然さ**: チューリング合格率 46% を達成し、本物の開発者に極めて近い対話挙動を実現。 - **二次元評価**: 成果物の正しさと人間の修正負担を分離測定する包括的プロトコル。 - **実装非依存のルーブリック評価**: 単一の機械テストの脆弱性を克服し、別解や対話要件を適切に評価。 ### 弱点・課題 - **ターンの途中割り込みが不可**: エージェントが実行中のターンにリアルタイムで口を挟むことはできず、ターン完了時のみ介入可能。 - **非視覚的・テキスト限定**: GUI や視覚的レンダリング結果に基づく対話・修正には非対応。 - **曖昧な課題への適応限界**: 明確なゴールと具体的コード修正を持つタスクに限定されており、設計議論や要件探索といったオープンエンドな対話タスクは対象外。 - **歩留まりの低さ**: 検証可能性の担保のために生セッションの 0.97% しかタスク化できておらず、構築コストが高い。 ## 関連 - 概念: - [[コーディングエージェント評価]] - [[エージェント軌跡評価]] - [[本番接地型ベンチマーク]] - [[エージェント型コーディング]] - [[LLM評価]] - エンティティ: - [[SWE-Together]] - [[SWE-bench Pro]] - [[SWE-Bench-Verified]] - [[Meta]] - [[Yifan Wu]] - [[Shengzhi Li]] ## 出典 - [[.raw/papers/arxiv-2606.29957.pdf]] - [[.raw/papers/arxiv-2606.29957.txt]] - [[.raw/papers/arxiv-2606.29957/images/images.json]]