論文解説: RealSWE — 「バグ直して」だけの依頼でコーディングエージェントを測り直す
SWE-benchの問題文は現実のユーザー依頼と別物だ、という主張を実データで測り、同じタスクの情報構成と文体だけを入れ替えられる381のタスク族を作った論文。正解率は平均6.4pt落ち、順位まで入れ替わる。
要点
- RealSWE は、SWE-bench Verified / Pro から派生させた381の多変種タスク族で、情報の構成と言語スタイルだけが変種ごとに違う。
- 「問題の記述だけ、またはそれに限られた補足が付いた程度」の依頼は現実のプロンプトの88%を占めるが、ベンチマーク問題では7%しかなかった。
- 現実のプロンプトの87%はくだけた書き方だが、ベンチマーク問題の94%は形式ばっていた。
- 7つのLLMを評価すると、現実的な入力では正解率が平均6.4ポイント下がり、モデルの順位が入れ替わることもあった。
- Desired Behavior と Motivation は性能に有意に効き、Environment Information と Reproduction Steps は測れる効果がなかった。
RealSWE: A Compositional Evaluation of Coding Agents under Realistic User Requests
一次資料 — この記事の根拠
論文の発表 2026-08-28→この解説の公開 2026-09-09同月
RealSWE: A Compositional Evaluation of Coding Agents under Realistic User RequestsGyuhyeong Kim, Hyojung Gwon, Jeonghyeon Kim ほか · 2026-08-28 · v2arXiv:2608.27831論文ページ·PDF原文の要旨（Abstract）を読む
Coding agents are now commonly evaluated on the SWE-bench family of benchmarks, whose tasks are built from curated GitHub issues: long, structured, and information-rich. Real user requests, however, are typically far shorter and less structured. To characterize this gap, we define a six-category information taxonomy and four dimensions of linguistic style, and apply them to real user prompts from SWE-chat and problem statements from SWE-bench Verified and Pro. We find that requests carrying only a problem statement, alone or with limited additional context, account for 88% of real prompts but just 7% of benchmark problems. Furthermore, 87% of real prompts are casually written whereas 94% of benchmark problems are formal. Guided by these observations, we introduce RealSWE, 381 multi-variant task families derived from SWE-bench Verified and Pro. Variants within each family share the same underlying task and gold patch while differing only in information composition and linguistic style. Evaluating seven contemporary LLMs with RealSWE, we find that i) realistic inputs reduce resolution rates by 6.4 pp on average and can change model rankings. Controlled analysis further shows that ii) including Desired Behavior and Motivation significantly affects performance, whereas Environment Information and Reproduction Steps merely add tokens without measurable benefit; iii) linguistic style has only small, model-dependent effects. These findings provide actionable guidance for users and agents: explicitly stating the desired behavior and motivation, which most real prompts omit, substantially improves the LLM's software engineering performance.
この論文の主張を先に
原題は "RealSWE: A Compositional Evaluation of Coding Agents under Realistic User Requests"（arXiv:2608.27831、2026年8月28日公開・8月31日改訂）。
要旨を日本語でまとめると、こうなります。コーディングエージェントの評価は SWE-bench 系列が事実上の標準になっているが、その問題文は GitHub の課題票（issue）から作られていて、長く・構造化され・情報が濃い。一方で現実のユーザーの依頼はずっと短く、構造化されていない。論文はこの差を測るために、情報の6分類と言語スタイルの4次元を定義し、実ユーザーのプロンプト（SWE-chat）と SWE-bench Verified / Pro の問題文の両方に当てはめた。結果、「問題の記述だけ、またはそれに限られた補足が付いた程度」の依頼は現実のプロンプトの88%を占めるのに、ベンチマーク問題では7%しかなかった。さらに現実のプロンプトの87%はくだけた書き方なのに、ベンチマーク問題の94%は形式ばっていた。この観察をもとに著者らは、SWE-bench Verified / Pro から派生させた381の「多変種タスク族」= RealSWE を作る。同じ族の変種はタスクも正解パッチも共有し、情報の構成と言語スタイルだけが違う。7つのLLMを評価すると、現実的な入力では正解率が平均6.4ポイント下がり、モデルの順位が入れ替わることもあった。統制実験では Desired Behavior（望ましい挙動）と Motivation（動機）が性能に有意に効き、Environment Information（環境情報）と Reproduction Steps（再現手順）はトークンを増やすだけで測れる効果がなかった。言語スタイルの効果は小さく、モデル依存だった。
比喩: 同じ故障を、整備士に2通りで伝える
車が止まった状況を、整備士に2通りで伝えてみます。
片方は整備記録です。「走行中、時速60kmを超えると異音が出る。冷間時には再現しない。前回のオイル交換は3か月前。期待する状態は、全速度域で異音が出ないこと」。もう片方は電話口の一言です。「車が変な音するんだけど、直して」。
故障そのものは同じで、正解の修理も同じです。違うのは伝え方だけ。それでも、後者を渡された整備士は、まず「どこから聞こえるのか」「いつからか」「直ったと判断する基準は何か」を自分で埋めなければなりません。
論文がやったのは、この2通りを同じ故障について作り分け、同じ整備士に順番に渡して、直せた率がどれだけ変わるかを測ることです。従来のベンチマークは前者しか渡していなかった、というのが出発点です（§1）。
論文の測り方: 依頼を「情報」と「文体」に分解する
まず、依頼を2つの直交する軸で記述します（§3.1）。
1つ目は情報タクソノミー。GitHub の既定の issue テンプレートを根拠に、依頼をタスク種別ごとの情報カテゴリに分けます。
- バグ修正:
[P]問題の記述（観測された不具合） /[D]望ましい挙動 /[R]再現手順 /[E]環境情報 /[A]補足情報 - 機能要望:
[P]問題の記述（要望された機能） /[M]動機 /[A]補足情報
[A] は他のどれにも入らないもの、たとえば参照URL・投稿者のメタ情報・日付などを受けます。ある依頼は、含む情報カテゴリの集合として [P]、[PA]、[PDR] のように表されます。
2つ目は言語スタイルで、Formality（形式ばっているか）、Sentence type（文の種類）、Certainty（断定の度合い）、Perspective（視点）の4次元です。
論文はこの物差しを、SWE-chat から取った718件の実ユーザープロンプトと、SWE-bench Verified / Pro の1,229件の問題文に当てました。SWE-chat は6,000超の開発者–エージェントの実セッションを含む公開データで、SWE-bench が単発の問題文で評価する設定に合わせて、各セッションの最初の依頼だけを残しています（§3.1）。分類には GPT-5.4 を使っています（§3.2）。
測って出てきた「ずれ」
情報の構成では、両者は鋭く食い違いました（§3.2）。
- 実ユーザー:
[P]と[PA]だけで88%（バグ修正85.5%、機能要望91.1%） - ベンチマーク:
[P]/[PA]は7%（バグ修正8.0%、機能要望3.9%）
言語面では、実ユーザーの86.8%がくだけた文体、51.3%が命令文。対して SWE-bench Verified は84.8%、Pro は100%が形式ばった文体で、どちらも約89%が平叙文でした。一方 Certainty と Perspective には一貫した差が出ませんでした。つまり差が出たのは主に「情報の濃さ」と「形式ばり具合」の2点であって、4次元すべてがずれていたわけではありません。
なぜ「情報の集合」という表し方が要るのか。バグ修正の5カテゴリのうち [P] を必ず含むとすると、残り4つの有無で
通りの組み合わせが生じます。ここは論文の数値ではなく、論文が「組み合わせの数が組み合わせ論的に増える」（§4.3）と述べていることの内訳を筆者が書き下したものです。モデル数と反復回数を掛ければ実行回数はすぐ手に負えなくなる。だから論文は全組み合わせを回さず、後述の「1つずつ削る」経路を主分析に選んでいます。
RealSWE の作り方
ずれが分かったので、次は同じタスクを別の伝え方で用意します。手順は3段（§3.3、詳細は Appendix H にプロンプト全文）。
- タスク種別の分類: GPT-5.4 が各問題をバグ修正か機能要望かに振り分ける。SWE-bench Verified / Pro の1,231件のうち、どちらにも当てはまらなかったのは2件だけで、以降の処理から除外
- 情報の分解: issue テンプレート由来の Markdown 見出しや HTML タグを剥がした上で、問題文を文単位に切り、各文をタクソノミーのカテゴリへ割り当てる。書き換えず、並べ替えるだけにして、分解が情報量を変えないようにしている
- 実ユーザー風への言い換え: §3.2 で測った各言語次元の多数派カテゴリに合わせて GPT-5.4 が書き換える。コードブロック・エラーメッセージ・トレースバック・ファイルパスといった技術的な字面は保存する
任意の組み合わせを組み立てるには、元の問題文に全カテゴリが揃っている必要があります。1,229件のうち条件を満たしたのは403件でした。
コメント
コメントにはログインが必要です