論文解説: SWE-bench Science — コーディングエージェントは「科学のコード」を直せるか
科学ソフトウェアの修理をコーディングエージェントに解かせるベンチマーク SWE-bench Science（119タスク・98リポジトリ・20分野）の解説。最良のエージェントでも pass@1 は50%未満で、4つの失敗機構と「科学知識は必ずしも効かない」というアブレーション結果を読み解く。
SWE-bench Science: Can Coding Agents Resolve Engineering Tasks in Science?
一次資料 — この記事の根拠
論文の発表 2026-08-20→この解説の公開 2026-08-27同月
SWE-bench Science: Can Coding Agents Resolve Engineering Tasks in Science?Zhipeng Xu, Jiahao Lu, Yining Zheng ほか · 2026-08-20 · v1arXiv:2608.19799論文ページ·PDF原文の要旨（Abstract）を読む
Software increasingly functions as part of the scientific instrument itself, making failures in scientific code capable of compromising not only program behavior but also the evidence underlying scientific conclusions. Yet existing evaluations of coding agents largely emphasize aggregate task success, providing limited insight into why agents fail when repairing scientific software. We introduce \textbf{SWE-bench Science}, a repository-level benchmark for scientific software engineering comprising 119 tasks from 98 GitHub repositories across 20 scientific domains. Each task is organized into one of three paradigms: Issue-driven, Expert-exploratory, and Engineering-integration. Even the best-performing agent, \textbf{Claude Code with Opus-5 (max), achieves a pass@1 below 50\%}, highlighting the substantial challenges posed by scientific software engineering. We identify four recurring failure mechanisms: deficits in scientific knowledge or abstraction, misguided exploration or surface-level repair, incomplete repair coverage or system integration, and failures to generalize scientific knowledge beyond observed cases in our analysis. We further conduct a paired ablation that removes explicit scientific guidance while preserving the repository and executable engineering context. The results show that scientific knowledge is not uniformly beneficial: well-grounded information can constrain repair and improve average performance and token efficiency, whereas poorly aligned guidance can induce anchoring and does not necessarily improve exact repair success. Together, SWE-bench Science provides a broad testbed for studying both the capabilities and failure mechanisms of coding agents in scientific software engineering.
望遠鏡のレンズにヒビが入っていたら
天文台が出した観測データを、いちいち疑う人はあまりいません。けれど、そのデータを吐き出した望遠鏡のレンズに髪の毛ほどのヒビが入っていたらどうでしょう。観測記録そのものが静かに歪みます。しかも厄介なことに、歪んだデータは「エラー」の顔をして出てきません。もっともらしい数値として出てきます。
現代の科学では、ソフトウェアがこのレンズの役割を担っています。地震波の解析、タンパク質の構造推定、気候モデルの積分 — どれも「装置で測る」の後半分がコードです。この論文の出発点はまさにそこにあります。曰く、ソフトウェアはますます科学装置そのものの一部として機能しており、科学コードの不具合はプログラムの挙動を壊すだけでなく、科学的結論の根拠となる証拠まで損ないうる（要旨）。
Webアプリのバグなら画面が真っ白になって誰かが気づきます。科学コードのバグは、論文の図の傾きが少し変わるだけで通ってしまう。この「静かに間違う」性質が、科学ソフトウェアの修理を特別な問題にしています。
既存のエージェント評価に足りなかったもの
AIコーディングエージェントの評価はこの数年で一気に整備されました。リポジトリ全体を渡して「このIssueを直すパッチを書け」と命じ、隠されたテストが通るかで採点する — SWE-bench系の枠組みです（系統の広がりはSWE-bench Pro Max の解説でも扱っています）。
ただし、と論文は言います。既存の評価は全体の成功率（aggregate task success）を強調するものが大半で、エージェントが科学ソフトウェアを修理するときになぜ失敗するのかをほとんど教えてくれない（要旨）。
これは評価設計として本質的な指摘です。「45%通りました」という一行からは、残り55%が「問題を読み違えた」のか「読み違えてはいないが直し切れなかった」のかが分かりません。前者と後者では、次に打つ手がまったく違います。
SWE-bench Science とは何か
そこで著者らが作ったのが SWE-bench Science です。要旨によれば、その構成は次のとおりです。
- 119タスク
- 98のGitHubリポジトリから採取
- 20の科学分野にまたがる
- リポジトリ単位（repository-level）のベンチマーク
比率に注目してください。119タスクを98リポジトリから集めている、つまり1リポジトリあたり平均1.2タスクです。同じプロジェクトから大量に採るのではなく、広く薄く集めている。「あるOSSの流儀を1つ覚えたから連続で解けた」という当たり方をしにくい設計だと読み取れます。
「リポジトリ単位」は想像より重い条件です。関数を1つ書かせるのではなく、数万行のコードベースを丸ごと渡し、どのファイルのどの関数が原因かを自分で見つけ、直し、既存のテストを壊さずに通すところまでを求めます。仕事の比重は「書く」より「調べる」にあり、これはLLMエージェントの基礎で扱った探索ループそのものです。
3つのパラダイム
各タスクは3つのパラダイムのいずれかに整理されています（要旨）。
1. Issue-driven（課題駆動） 既存のIssueが出発点になる型。「この入力でクラッシュする」「この結果が理論値と合わない」という報告から原因にたどり着きます。従来のSWE-benchに一番近い形です。
2. Expert-exploratory（専門家的探索） 明示された不具合報告に頼らず、専門知識を使って自分で探しにいく型。何が壊れているかが最初から言語化されていない状況を想定しています。
3. Engineering-integration（工学的統合） 単一の修理ではなく、システムとして噛み合わせる型。部品を直すだけでなく、周辺と整合させる工程が問われます。
この3分割自体が主張です。科学ソフトウェアの仕事は「バグ報告 → 修正」の単線ではなく、探索が要る仕事と統合が要る仕事が別種の難しさとして存在する、という見立てになっています。
pass@1 という物差し
結果を読む前に、指標を押さえておきます。以下は指標そのものの一般的な定義で、論文の主張ではありません。
記号を1つずつ。 はタスクの総数（ここでは119）。 は中身が成り立てば1、成り立たなければ0になる箱です。総和して で割っているので、この式が言っているのは一言、「1発で直せたタスクの割合」です。
「1発で」が効いています。何度も試して1回当たればよい指標なら数字は上がりますが、現実の運用で人間がレビューするのは最初に出てきた1本のパッチです。pass@1 は運用の実感に近い、厳しい物差しだと思ってください。
コメント
コメントにはログインが必要です