SWE-bench
読み: エスダブリューイーベンチ
SWEベンチとはAI開発力の指標
SWE-benchは、LLMがソフトウェアエンジニアリングの実務タスクをどの程度こなせるかを評価するベンチマークである。プリンストン大学の研究チームが2023年に公開した。HumanEvalのようなコード生成ベンチマークとは異なり、実在するGitHubリポジトリのイシューを解決させるという実践的な設計が特徴。
かんたんに言うと
AIに「このバグを直せ」と実際のソフトウェアプロジェクトの修正依頼を渡して、テストが通るコードを書けるかどうかを測る試験である。
関数レベルの宿題では測れない実務力を問うSWE-benchの設計
従来のコード生成ベンチマークであるHumanEvalは、関数レベルの小さなプログラミング問題を解かせるものだった。「フィボナッチ数列を返す関数を書け」といった問題で、プログラミングの授業の宿題に近い。
SWE-benchが突き付けるのは、それとはまるで別の課題である。数万行のコードベースから問題の箇所を特定し、既存のアーキテクチャを壊さないように修正し、テストスイートを通過させる。人間のソフトウェアエンジニアが日常的にやっている作業そのものである。
2023年の論文発表時点では、当時最高性能だったGPT-4でも解決率は1.7%にとどまった。関数を書くのは得意でも、プロジェクト全体を理解して修正する能力は圧倒的に不足していたということである。
評価の仕組みと問題の難易度
SWE-benchのデータセットは、DjangoやScikit-learnといった有名なPythonプロジェクトのGitHubイシューとそのプルリクエストから構成されている。各問題は「イシューの説明文」「修正前のコードベース」「修正後に通るべきテスト」の3点セットである。
AIに渡されるのはイシューの説明文とコードベースだけ。テストの内容は伏せられたまま、修正パッチを生成させる。テストが全て通れば正解、1つでも落ちれば不正解。この白黒がはっきりした評価方式がSWE-benchの信頼性を支えている。
後に公開されたSWE-bench Liteは、より厳選された300問のサブセットである。評価コストを下げつつ識別力を維持する設計で、多くの研究チームや企業がこちらをスコア報告に使っている。
エージェント型アプローチの台頭
SWE-benchのスコアが急上昇した転機は、LLM単体ではなくエージェント型のシステムが登場したことにある。
CognitionのDevin、OpenAIのSWE-agent、AnthropicのClaude。いずれもLLMにツール使用能力を与え、コードの検索、ファイルの編集、テストの実行を自律的に繰り返させる方式を採用した。2024年後半にはSWE-bench Liteで50%を超えるスコアを記録するシステムが複数登場している。
ただ、この数字をそのまま「AIがエンジニアの半分の仕事をこなせる」と読み替えるのは早計である。SWE-benchの問題は事前にフィルタされた「修正可能なバグ」であり、要件定義の曖昧さや人間同士のコミュニケーションといった実務の泥臭い部分は含まれていない。
Chatbot Arenaとの位置づけの違い
AIのベンチマークで頻繁に名前が挙がるChatbot Arenaは、人間の評価者が2つのモデルの出力を比較して勝敗をつけるEloレーティング方式である。会話の自然さや指示への忠実さを測るのに向いている。
SWE-benchはそれとは正反対のアプローチをとる。人間の主観は一切入らない。テストが通るか通らないか。この客観性が、コーディング能力を評価する際の信頼性につながっている。
一方で、SWE-benchでスコアが高いモデルがChatbot Arenaでも高いとは限らない。コードを書く能力と人間と自然に対話する能力は別物である。AIモデルを評価する際は、何を測っているベンチマークなのかを把握した上で数字を見る必要がある。
ベンチマークの限界と今後の方向性
SWE-benchにも弱点はある。
まず、Pythonプロジェクトに偏っている。Java、Go、TypeScriptといった他の主要言語はカバーされていない。SWE-bench Multilingual等の派生ベンチマークが登場しつつあるが、まだ標準化には至っていない。
次に、データ汚染の問題がある。ベンチマークの問題がGitHub上に公開されている以上、LLMの学習データに含まれている可能性を完全には排除できない。スコアが上がった要因が、真の推論能力の向上なのか暗記なのか、判別が難しくなる。
それでもSWE-benchが業界に与えたインパクトは大きい。「AIにコードを書かせる」から「AIにソフトウェアを直させる」へ、評価軸そのものを引き上げた。次に来るのは、設計判断やアーキテクチャ選定を含む、さらに上流の工程を評価するベンチマークだろう。
当社の見解
技術の選定で最も避けるべきは「流行っているから」という理由で導入することだ。当社は複数のAIツール・フレームワークを実際に検証した上で、自社の用途に合うものだけを採用している。検証せずに導入したツールは、ほぼ例外なく3か月以内に使わなくなった。実装指示した人間側が実装したことも忘れて、気が付けば動いていない機能があった、ということも起きる。さらに、MCPやフックやルールを増やしすぎてAIが情報過多で機能しなくなった経験もある。どんなにルールや機能を付け足しても機能しなければ意味がない。足し算より引き算。1週間の検証期間が、3か月の手戻りを防ぐ。
同じ失敗を二度としないAIエージェント
今のAIは、聞けば何でも答えてくれます。
でも、セッションが切れた瞬間に前回の失敗を忘れます。
当社が開発しているAIは、過去の経緯を念頭に置いて、
聞かれる前に「それは前回うまくいきませんでした」と声をかけます。
人間にも同じ失敗をさせず、AI自身も繰り返しません。
古参の社員が横にいるように、黙っていても気づいてくれる。
それが、当社が考える本当のAI社員です。