📄 論文解説: SWE-bench — 実世界GitHubイシューでLLMのソフトウェアエンジニアリング能力を評価する

論文概要（Abstract）

SWE-benchは、Princeton大学のCarlos E. Jimenezらが2023年に提案した、LLMのソフトウェアエンジニアリング能力を評価するベンチマークです。12のPythonリポジトリ（Django, scikit-learn, sympy等）から収集した2,294の実際のGitHub Pull Requestを基にタスクを構成し、エージェントに「イシュー説明文からバグ修正パッチを生成する」能力を問います。既存のユニットテストを用いた完全自動評価が可能であり、ICLR 2024にOral論文として採択されました。

この記事は Zenn記事: LLMエージェント評価ベンチマーク完全ガイド：SWE-bench・GAIA・τ-benchの選び方と実践 の深掘りです。

情報源

• arXiv ID: 2310.06770
• URL: https://arxiv.org/abs/2310.06770
• 著者: Carlos E. Jimenez, John Yang, Alexander Wettig, Shunyu Yao, Kexin Pei, Ofir Press, Karthik Narasimhan
• 発表年: 2023（ICLR 2024 Oral採択）
• 分野: cs.SE, cs.AI, cs.CL

背景と動機（Background & Motivation）

LLMのコード生成能力を測るベンチマークとして、HumanEval（164問のPython関数生成）やMBPP（974問のプログラミング問題）が広く使われてきました。しかし、これらのベンチマークは「短い関数を1つ生成する」タスクに限定されており、実際のソフトウェアエンジニアリングで要求される数千行のコードベースの理解、複数ファイルにまたがる変更、既存テストとの整合性維持といった能力を測定できません。

SWE-benchの著者らは、「LLMは実世界のGitHubイシューを解決できるか？」という問いに直接答えるベンチマークが必要だと考えました。GitHubのPull Requestは、イシュー記述→コード変更→テストによる検証という一連のプロセスを自然に含んでおり、ソフトウェアエンジニアリング能力の評価に最適な素材です。

主要な貢献（Key Contributions）

• 貢献1: 12のPythonリポジトリから2,294の実GitHubイシューを収集し、自動評価可能なベンチマークを構築。テスト駆動の正否判定により、人手による評価が不要
• 貢献2: タスク難易度の自然な分布を実現。簡単な1行修正からアーキテクチャ変更を伴う複雑なバグ修正まで幅広くカバー
• 貢献3: BM25ベースのファイル検索、Claude/GPTによるパッチ生成など複数のベースライン手法を提供し、初期性能の基準点を確立

技術的詳細（Technical Details）

データセット構築パイプライン

SWE-benchのタスクインスタンス構築は、以下の4ステップで行われます。

ステップ1: Pull Request収集

対象リポジトリから、マージ済みのPull Requestを収集します。収集条件は以下の通りです。

• テストファイルへの変更を含むPR（テストベースの評価に必要）
• 対応するGitHubイシューへのリンクが存在するPR
• CIが通過しているPR

ステップ2: テスト分離

PRのdiffから「テストの変更」と「ソースコードの変更」を分離します。

\[\text{diff}_{\text{PR}} = \text{diff}_{\text{test}} \cup \text{diff}_{\text{source}}\]

ここで、$\text{diff}{\text{test}}$はテストファイルの変更、$\text{diff}{\text{source}}$は非テストファイルの変更です。テスト変更はゴールドスタンダード（正解判定用）として使用し、ソースコード変更が生成すべきパッチとなります。

ステップ3: 環境再現

各タスクインスタンスについて、PR作成時点のリポジトリ状態を再現します。

# タスクインスタンスの構造
@dataclass
class TaskInstance:
    """SWE-benchの1タスクを表すデータ構造"""
    instance_id: str          # 例: "django__django-11099"
    repo: str                 # 例: "django/django"
    base_commit: str          # PRのベースコミットハッシュ
    problem_statement: str    # GitHubイシューの説明文
    hints_text: str           # PRコメントからのヒント（オプション）
    patch: str                # 正解パッチ（diff形式）
    test_patch: str           # テスト変更（評価用）
    environment_setup_commit: str  # 環境セットアップ用コミット
    version: str              # リポジトリバージョン

ステップ4: 実行可能性検証

各インスタンスについて、以下の条件を自動検証します。

1. ベースコミットでリポジトリがビルドできること
2. パッチ適用前にテストが失敗すること（FAILからPASSへの遷移を確認）
3. 正解パッチ適用後にテストが通過すること

評価メトリクス

SWE-benchの主要評価指標は解決率（% Resolved）です。

\[\text{Resolved}(\%) = \frac{|\{i \in \mathcal{T} : \text{tests\_pass}(\text{apply}(p_i, \text{repo}_i))\}|}{|\mathcal{T}|} \times 100\]

ここで、

• $\mathcal{T}$: タスクインスタンスの集合
• $p_i$: エージェントが生成したパッチ
• $\text{repo}_i$: タスク$i$のベースリポジトリ状態
• $\text{apply}(p, r)$: リポジトリ$r$にパッチ$p$を適用した状態
• $\text{tests_pass}(s)$: 状態$s$でテストスイートが全パスするか

重要な点として、この評価はテストスイートの品質に依存します。テストカバレッジが不十分な場合、バグを含むパッチでもテストをパスしてしまう可能性があります。

Dockerベース評価インフラ

2024年6月以降、SWE-benchは完全にコンテナ化された評価ハーネスに移行しました。

# 評価実行の基本フロー
from swebench.harness.run_evaluation import main as run_evaluation

# 評価設定
config = {
    "dataset_name": "princeton-nlp/SWE-bench_Verified",
    "predictions_path": "predictions.json",  # エージェントの予測結果
    "max_workers": 8,                        # 並列実行ワーカー数
    "run_id": "my_evaluation",
    "timeout": 1800,                         # タスクあたり30分
}

# predictions.jsonの形式
# [
#   {
#     "instance_id": "django__django-11099",
#     "model_patch": "--- a/django/db/models/sql/query.py\n+++ ...",
#     "model_name_or_path": "my-agent-v1"
#   },
#   ...
# ]

各タスクは独立したDockerコンテナ内で実行されるため、環境の干渉がなく再現性が保証されます。

ベースライン手法

論文では、以下のベースライン手法を評価しています。

BM25 Retrieval + 直接生成:

1. イシュー説明文をクエリとして、BM25でソースファイルを検索
2. 上位$k$ファイルをコンテキストとしてLLMに与え、パッチを生成

\[\text{score}_{\text{BM25}}(q, d) = \sum_{t \in q} \text{IDF}(t) \cdot \frac{f(t, d) \cdot (k_1 + 1)}{f(t, d) + k_1 \cdot (1 - b + b \cdot \frac{|d|}{\text{avgdl}})}\]

ここで、$q$はクエリ（イシュー説明文）、$d$はソースファイル、$f(t, d)$はファイル$d$内の語$t$の出現頻度、$k_1 = 1.2$, $b = 0.75$がデフォルトパラメータです。

Oracle Retrieval + 生成:

• 正解パッチが変更するファイルを直接与える（上限性能の推定）

初期の結果では、Claude 2が1.96%、GPT-4が1.74%の解決率を達成しました。

実装のポイント（Implementation）

SWE-benchでエージェントを評価する際の実装上の注意点を解説します。

コンテキスト長の制約: 大規模リポジトリ（Django: 約50万行）では、関連ファイルをすべてコンテキストに含めることが不可能です。効果的なファイル特定（localization）がスコアを大きく左右します。

パッチ形式の正確性: 生成されるパッチはUnified Diff形式で、行番号とコンテキスト行が正確でなければgit applyが失敗します。

# パッチ生成時のよくあるバグと対策
def validate_patch(patch_text: str) -> bool:
    """生成パッチの基本的な妥当性チェック

    Args:
        patch_text: unified diff形式のパッチ文字列

    Returns:
        パッチが構文的に妥当かどうか
    """
    lines = patch_text.split('\n')
    has_header = any(l.startswith('---') for l in lines)
    has_additions = any(l.startswith('+') and not l.startswith('+++') for l in lines)
    has_deletions = any(l.startswith('-') and not l.startswith('---') for l in lines)

    # 最低限: ヘッダと変更行が存在すること
    return has_header and (has_additions or has_deletions)

2段階アプローチの有効性: 最新のエージェント（SWE-agent, Agentless等）は、(1) 問題のあるファイル・関数を特定 → (2) パッチを生成、という2段階アプローチを採用しており、直接パッチ生成より大幅に高いスコアを達成しています。

Production Deployment Guide

AWS実装パターン（コスト最適化重視）

SWE-benchの評価インフラをAWS上で構築する場合のトラフィック量別推奨構成です。

規模	月間評価回数	推奨構成	月額コスト	主要サービス
Small	~10回	Serverless	$100-300	Lambda + ECR + S3
Medium	~50回	Hybrid	$500-1,500	ECS Fargate + ECR + S3
Large	200回+	Container	$3,000-8,000	EKS + EC2 Spot + ECR

Small構成の詳細（月額$100-300）:

• Lambda: Docker イメージ実行（最大15分タイムアウト）、短時間タスク向け ($30/月)
• ECR: Docker イメージ保存 ($10/月)
• S3: 評価結果・ログ保存 ($5/月)
• CodeBuild: 長時間タスクの実行（30分上限） ($50/月)
• CloudWatch: ログ・メトリクス ($10/月)

Medium構成の詳細（月額$500-1,500）:

• ECS Fargate: 4 vCPU, 16GB RAM × 4タスク並列 ($400/月)
• ECR: Docker イメージ保存 ($10/月)
• S3: 評価結果保存 ($10/月)
• Step Functions: 評価パイプラインオーケストレーション ($20/月)
• CloudWatch: 詳細監視 ($30/月)

Large構成の詳細（月額$3,000-8,000）:

• EKS: コントロールプレーン ($72/月)
• EC2 Spot: c5.4xlarge × 4-8台（最大90%削減、平均$800/月）
• ECR: Docker イメージ保存 ($20/月)
• S3: 大量の評価結果保存 ($50/月)
• CloudWatch + X-Ray: 詳細監視・トレーシング ($100/月)

コスト削減テクニック:

• Spot Instances使用で最大90%削減（EKS + Karpenter）
• 評価ジョブの夜間バッチ実行でオンデマンド利用を最小化
• ECRライフサイクルポリシーで古いイメージを自動削除
• S3 Intelligent-Tieringで評価結果のストレージコスト最適化

コスト試算の注意事項:

• 上記は2026年2月時点のAWS ap-northeast-1（東京）リージョン料金に基づく概算値です
• 実際のコストはタスク数、並列度、実行時間により変動します
• 最新料金は AWS料金計算ツール で確認してください

Terraformインフラコード

Small構成（Serverless）: Lambda + CodeBuild + S3

# --- VPC基盤 ---
module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "~> 5.0"

  name = "swe-bench-vpc"
  cidr = "10.0.0.0/16"
  azs  = ["ap-northeast-1a", "ap-northeast-1c"]
  private_subnets = ["10.0.1.0/24", "10.0.2.0/24"]

  enable_nat_gateway   = false
  enable_dns_hostnames = true
}

# --- IAMロール（最小権限） ---
resource "aws_iam_role" "swe_bench_executor" {
  name = "swe-bench-executor"

  assume_role_policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Action = "sts:AssumeRole"
      Effect = "Allow"
      Principal = { Service = "codebuild.amazonaws.com" }
    }]
  })
}

resource "aws_iam_role_policy" "executor_policy" {
  role = aws_iam_role.swe_bench_executor.id
  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Effect = "Allow"
        Action = ["s3:PutObject", "s3:GetObject"]
        Resource = "${aws_s3_bucket.results.arn}/*"
      },
      {
        Effect   = "Allow"
        Action   = ["ecr:GetDownloadUrlForLayer", "ecr:BatchGetImage"]
        Resource = aws_ecr_repository.swe_bench.arn
      }
    ]
  })
}

# --- S3バケット（評価結果保存） ---
resource "aws_s3_bucket" "results" {
  bucket = "swe-bench-evaluation-results"
}

resource "aws_s3_bucket_lifecycle_configuration" "results_lifecycle" {
  bucket = aws_s3_bucket.results.id
  rule {
    id     = "archive-old-results"
    status = "Enabled"
    transition {
      days          = 30
      storage_class = "INTELLIGENT_TIERING"
    }
  }
}

# --- ECR（Docker イメージ） ---
resource "aws_ecr_repository" "swe_bench" {
  name = "swe-bench-evaluator"
}

# --- CodeBuild（評価ジョブ実行） ---
resource "aws_codebuild_project" "evaluator" {
  name         = "swe-bench-evaluator"
  service_role = aws_iam_role.swe_bench_executor.arn

  artifacts { type = "NO_ARTIFACTS" }

  environment {
    compute_type    = "BUILD_GENERAL1_LARGE"  # 8 vCPU, 16GB RAM
    image           = "${aws_ecr_repository.swe_bench.repository_url}:latest"
    type            = "LINUX_CONTAINER"
    privileged_mode = true  # Docker-in-Docker対応
  }

  source {
    type      = "NO_SOURCE"
    buildspec = "buildspec.yml"
  }
}

# --- CloudWatchアラーム ---
resource "aws_cloudwatch_metric_alarm" "build_failures" {
  alarm_name          = "swe-bench-build-failures"
  comparison_operator = "GreaterThanThreshold"
  evaluation_periods  = 1
  metric_name         = "FailedBuilds"
  namespace           = "AWS/CodeBuild"
  period              = 3600
  statistic           = "Sum"
  threshold           = 3
  alarm_description   = "SWE-bench評価ジョブの連続失敗検知"
}

セキュリティベストプラクティス

• IAMロール: 最小権限の原則。S3とECRへのアクセスのみ許可
• Docker: privileged modeは評価ジョブ内のDocker-in-Dockerに必要だが、ネットワーク隔離で補完
• シークレット: GitHub APIトークンはSecrets Manager経由で管理
• 暗号化: S3バケットはKMS暗号化、ECRイメージスキャン有効化

運用・監視設定

CloudWatch Logs Insights クエリ:

-- 評価ジョブの成功率推移
fields @timestamp, status, duration_ms
| stats count(*) as total,
        sum(case when status = 'SUCCEEDED' then 1 else 0 end) as succeeded
        by bin(1d)
| sort @timestamp desc

-- タスクあたりの実行時間分析
fields @timestamp, task_id, execution_time_seconds
| stats avg(execution_time_seconds) as avg_time,
        pct(execution_time_seconds, 95) as p95
        by bin(1h)

Cost Explorer自動レポート:

import boto3
from datetime import datetime, timedelta

ce = boto3.client('ce')

response = ce.get_cost_and_usage(
    TimePeriod={
        'Start': (datetime.now() - timedelta(days=7)).strftime('%Y-%m-%d'),
        'End': datetime.now().strftime('%Y-%m-%d')
    },
    Granularity='DAILY',
    Metrics=['UnblendedCost'],
    Filter={
        'Tags': {
            'Key': 'Project',
            'Values': ['swe-bench']
        }
    }
)

コスト最適化チェックリスト

アーキテクチャ選択:

• ~10回/月 → CodeBuild + Lambda（Serverless）- $100-300/月
• ~50回/月 → ECS Fargate（Hybrid）- $500-1,500/月
• 200回+/月 → EKS + Spot（Container）- $3,000-8,000/月

リソース最適化:

• Spot Instances優先（最大90%削減）
• 夜間バッチ実行で日中リソースを解放
• ECRライフサイクルポリシーで古いイメージ削除
• S3 Intelligent-Tieringでストレージコスト削減
• CodeBuildのcompute_typeを適切に選択

監視・アラート:

• AWS Budgets: 月額予算設定（80%で警告）
• CloudWatch: ビルド失敗率アラーム
• Cost Anomaly Detection: 自動異常検知
• 週次コストレポート: SNS送信

リソース管理:

• タグ戦略: Project=swe-bench, Environment=dev/prod
• 未使用EC2インスタンス自動停止
• EBSスナップショットのライフサイクル設定
• CloudWatch Logsの保持期間設定（90日推奨）

実験結果（Results）

初期ベースライン（2023年）

モデル	検索方式	SWE-bench Full	SWE-bench Lite
Claude 2	BM25	1.96%	4.33%
GPT-4	BM25	1.74%	3.00%
Claude 2	Oracle	4.80%	-
GPT-4	Oracle	3.60%	-

2024年以降の進展

モデル/エージェント	SWE-bench Verified	備考
SWE-agent (GPT-4)	18.0%	Agent-Computer Interface
Agentless (GPT-4o)	27.3%	エージェントレス手法
Claude 3.5 Sonnet	49.0%	2024年6月時点
Claude Opus 4.5	80.9%	2026年2月時点トップ

2023年の初期ベースラインから約2年で、解決率は1.96%から80.9%へと40倍以上の改善を達成しています。この急速な進歩は、モデル性能の向上だけでなく、Agent-Computer Interface（SWE-agent）やStructured localization（Agentless）など、エージェントアーキテクチャの革新によるものです。

拡張ベンチマーク

• SWE-bench Verified（2024年8月）: OpenAI資金で人間エンジニアが500問を検証。信頼性の高い評価サブセットとして業界標準に
• SWE-bench Multilingual（2025年）: 9言語、42リポジトリの300タスク。Python以外の評価が可能に
• SWE-bench Pro（2025年）: Scale AIによるより厳格な評価。トップモデルでも45%未満

実運用への応用（Practical Applications）

SWE-benchで高スコアを達成するエージェントの技術は、実運用の開発支援ツールに直接応用されています。

GitHub Copilot Workspace: リポジトリ全体を理解し、イシューからPRを自動生成する機能は、SWE-bench的タスクの製品化

Claude Code: Anthropicのコーディングエージェントは、SWE-bench Verifiedで80%超を達成する技術をIDEツールに統合

課題: 本番環境では以下の点でベンチマークと乖離があります。

• テストスイートが存在しないプロジェクトでの品質保証
• 人間との対話を含むイシューの解決（曖昧な仕様の明確化）
• セキュリティ要件を考慮したパッチ生成

関連研究（Related Work）

• HumanEval（Chen et al., 2021）: 164問のPython関数生成ベンチマーク。SWE-benchと異なり単一関数スケールの評価に限定
• MBPP（Austin et al., 2021）: 974問のプログラミング問題。教育レベルのプログラミング能力を測定
• CodeContests（Li et al., 2022）: 競技プログラミング問題。アルゴリズム設計能力を測定するが、実世界のソフトウェアエンジニアリングとは性質が異なる
• SWE-agent（Yang et al., 2024）: SWE-bench上で初めてエージェントベースのアプローチを体系化。Agent-Computer Interface（ACI）の概念を提案

まとめと今後の展望

SWE-benchは、LLMのソフトウェアエンジニアリング能力評価の事実上の標準として、2023年の公開以来急速に普及しました。初期の2%未満から2026年の80%超まで、わずか2年での劇的な性能向上はLLMとエージェント技術の進歩を如実に示しています。

今後の課題として、Python以外の言語対応（SWE-bench Multilingual）、テストスイートに依存しない評価手法、およびコストを含む多面的な評価指標の確立が挙げられます。ベンチマークスコアが飽和するにつれ、SWE-bench Proのようなより厳格な評価基準や、実運用に近い評価環境の構築が重要になるでしょう。

参考文献

• arXiv: https://arxiv.org/abs/2310.06770
• Code: https://github.com/princeton-nlp/SWE-bench
• Leaderboard: https://www.swebench.com/
• Related Zenn article: https://zenn.dev/0h_n0/articles/cdb9712312bdbf