【個人検証】SWE-bench Verified 500問でCodex単独と自作AI Agent Harnessを比較した：73.8% vs 81.0%

Posted at 2026-11-01

【個人検証】SWE-bench Verified 500問でCodex単独と自作AI Agent Harnessを比較した：73.8% vs 81.0%

はじめに

2026年10月、SWE-bench Verifiedの全500問を対象に、Codex CLI単独の実行と、自作Coding-Agent Harness「AIVP v2」を組み合わせたワークフローの比較実験を行いました。

本記事では、実験環境、評価方法、結果、トークン消費量、公開データの検証方法を紹介します。

まず結果です。

指標	Vanilla Codex	AIVP v2 Shadow
評価対象	500問	500問
Resolved	369	405
Unresolved	131	95
解決率	73.80%	81.00%
記録されたInput + Output Tokens	147,255,946	285,460,411
平均生成時間	122.55秒	186.13秒

観測された解決率の差は+7.2ポイント、解決件数では+36問でした。

ただし、AIVP側では追加のモデル呼び出しやレビュー工程が行われており、両条件の計算資源は同一ではありません。

したがって、今回の実験はHarness単体の因果効果を証明するものではなく、異なる二つのAIコーディングワークフローの比較です。

本研究はSWE-bench公式リーダーボードへの提出ではなく、独立した個人実験です。

1. 実験の目的

実験で検証したかったのは、次の問いです。

Coding Agentの周辺に検証・レビュー・実行制御を追加した場合、実際のソフトウェア修正結果はどのように変化するのか？

比較する実験条件を以下のように定義しました。

Vanilla Codex

Codex CLIを使用し、独自のAIVP制御を追加せずに修正パッチを生成します。

Codex自体が持つコード探索やツール実行などの機能は使用しますが、追加のClaude ReviewerやAIVP Harness Panelは導入しません。

AIVP v2 Shadow

Codexによるコード生成と、Claudeによるレビューなどを組み合わせた実験用ワークフローです。

AIVP v2は、AIによる変更を外部から管理するためのCoding-Agent Harnessとして開発しました。

設計上、以下のような機能を持っています。

Durable Execution / Checkpoint / Resume
Context Compiler / Cache
Worktree / Docker Sandbox
Verification / Review
Risk-aware Routing
Token / Latency Telemetry
Human Escalation

ただし、これら全機能の個別効果が今回の500問比較で証明されたわけではありません。

また、Shadow評価では生成された500件のPredictionを対象にしており、AUTO_FINISHEDとなった変更だけを抽出したわけではありません。

2. SWE-bench Verifiedとは

SWE-bench は、実在するGitHubリポジトリのIssueをもとに、AIエージェントによるソフトウェア修正能力を評価するベンチマークです。

今回使用したSWE-bench Verifiedには500問が収録されています。

評価するのは、AIがもっともらしいコードを生成できるかではありません。

生成されたパッチを適用し、評価環境で問題が解決されたかどうかです。

そのため、パッチ生成と評価を別工程として扱いました。

SWE-bench Verified
        |
        v
   500 Issues
        |
        +--------------------+
        |                    |
        v                    v
  Vanilla Codex       AIVP v2 Shadow
        |                    |
        v                    v
  Patch Generation    Patch Generation
        |                    |
        v                    v
  Predictions.jsonl   Predictions.jsonl
        |                    |
        +----------+---------+
                   |
                   v
          SWE-bench Evaluation
                   |
                   v
             Resolved / Unresolved

3. 実験環境

3.1 Vanilla Codexのパッチ生成環境

2026年10月14日の実験記録では、以下の構成を使用しています。

項目	構成
Local Machine	MacBook Air M5 / 24GB RAM
OS	macOS
Coding Agent	Codex CLI 0.162.1
Runner Model Label	`gpt-5.6-terra`
Reasoning Effort	medium
並列実行数	最大10
1タスクのTimeout	1800秒
出力形式	SWE-bench Prediction JSONL

※モデル名は実験Runnerに記録されたラベルです。初期バッチと後半バッチでは実行スクリプトやログ形式に違いがあります。

各Issueは独立したタスクとして処理しました。

ここでの「10並列」は、10個の異なるIssueを同時に処理するという意味です。1問を10個のAgentで共同解決する構成ではありません。

3.2 Docker評価環境

Vanilla実験のAWS評価工程では、次の環境を使用しました。

項目	構成
Cloud	AWS
Region	ap-northeast-1（東京）
EC2	Spot m7i.8xlarge
CPU	32 vCPU
Memory	128 GiB
OS	Ubuntu 24.04 / amd64
Storage	gp3 EBS 600 GiB
Evaluation Tool	SWE-bench CLI 5.0.2
並列評価	12

生成したPredictionをDockerベースの評価環境に渡して採点しました。

なお、この環境は初期のVanilla評価に関する記録です。後続の評価バッチを含めた全処理が、単一のEC2インスタンスで実行されたという意味ではありません。

AIVP側の最終評価記録では、500件について以下のContainer Imageを使用しています。

Image Method	件数
Published Image	83
Local Build	417
合計	500

最終的な評価結果は、2026年10月29日に監査・アーカイブしました。

4. Predictionと評価結果の保存

SWE-benchで使用するPredictionは、基本的に次のようなJSONL形式です。

{
  "instance_id": "example__repo-12345",
  "model_name_or_path": "example-model",
  "model_patch": "diff --git ..."
}

※上記は形式説明用のダミーデータです。

今回の公開アーカイブには、両構成の500件分のPredictionが保存されています。

swebench-baseline-results/
├── evaluation/
│   ├── vanilla-500/
│   │   ├── predictions.jsonl
│   │   └── manifest.json
│   │
│   ├── aivp-v2-shadow-500/
│   │   ├── predictions.jsonl
│   │   ├── results.json
│   │   └── summary.json
│   │
│   └── resource-telemetry-20261029/
│       ├── vanilla-500.jsonl
│       ├── aivp-base-500.jsonl
│       ├── aivp-model-calls.jsonl
│       ├── manifest.json
│       └── SHA256SUMS

Vanillaの500件のPredictionは、複数バッチからLossless Consolidationによって統合しました。パッチ本文は変更せず、1件1行の形式に整理しています。

これにより、後から実験単位のデータを確認できます。

5. 評価結果

最終的な解決率は以下のとおりです。

Vanilla Codex

Resolved    369
Unresolved  131
Total       500

Resolved Rate = 73.80%

AIVP v2 Shadow

Resolved    405
Unresolved   95
Total       500

Resolved Rate = 81.00%

差分は以下のようになります。

Resolved Difference:
405 - 369 = +36

Percentage Point Difference:
81.00 - 73.80 = +7.20pp

一方、AIVP側の評価結果には、追加検証が必要なAmbiguous Failureが9件存在します。

この9件は通常のResolved / Unresolved結果と区別して記録し、独立した再確認の対象としています。

現時点では、81.0%を全ての曖昧さが解消された最終的な性能値として扱うのではなく、保存された評価結果に基づく観測値として扱っています。

6. Token Usageと実行時間の比較

品質以外の重要な指標として、トークン消費量とタスク生成時間を計測しました。

指標	Vanilla	AIVP
記録されたInput Tokens	145,764,941	281,346,935
記録されたOutput Tokens	1,491,005	4,113,476
Input + Output	147,255,946	285,460,411
平均Task生成時間	122.55秒	186.13秒

観測値を比率にすると、おおよそ次のようになります。

Quality:
73.8% -> 81.0%
+7.2 percentage points

Recorded Token Usage:
147.26M -> 285.46M
1.94x

Mean Generation Time:
122.55s -> 186.13s
1.52x

ここでの計測上の注意点は3つあります。

第一に、Cached Input TokensはInput Tokensの内数なので、さらに足してはいけません。

第二に、Vanillaの時間データは490件がMonotonic Clockによる測定で、残る10件はFilesystem Timestampを使った推定値です。

第三に、AIVPの基本500件には1,731回のModel Callが記録されていますが、15回分のToken Usageが欠損しています。

欠損した値はゼロとして扱っていません。

また、AIVPではRetry / Recoveryに関する追加22レコードも別途保存しています。これらは15件のRetryレコードと7件のRecoveryレコードであり、22件のユニークな追加Issueではありません。

本記事の主要なトークン比較は、基本500件の記録を対象としています。

Provider Billingの完全なデータがないため、正確な実請求額やUSD単位のCost per Resolved Issueは報告しません。

7. GitHubの実験データを検証してみる

ここからは、公開済みのデータを使って集計を確認する方法です。

7.1 Repositoryの取得

git clone https://github.com/1716964609/swebench-baseline-results.git

cd swebench-baseline-results

7.2 SHA-256による整合性確認

テレメトリのディレクトリには SHA256SUMS が存在します。

cd evaluation/resource-telemetry-20261029

shasum -a 256 -c SHA256SUMS

このコマンドは、ローカルに取得したファイルが保存済みのチェックサムと一致するかを確認します。

チェックサムの一致は、公開アーカイブ内のファイル整合性を確認するためのものであり、実験結果そのものの正しさを独立に保証するわけではありません。

7.3 Pythonでトークンと時間を再集計

以下は、公開JSONLから主要指標を再集計するサンプルです。

Repositoryのルートディレクトリから実行することを想定しています。

import json
from pathlib import Path
from statistics import mean

ROOT = Path("evaluation/resource-telemetry-20261029")


def read_jsonl(path):
    with path.open(encoding="utf-8") as f:
        return [
            json.loads(line)
            for line in f
            if line.strip()
        ]


vanilla = read_jsonl(ROOT / "vanilla-500.jsonl")
aivp = read_jsonl(ROOT / "aivp-base-500.jsonl")

# 件数とInstance IDを検証
assert len(vanilla) == 500
assert len(aivp) == 500

vanilla_ids = {r["instance_id"] for r in vanilla}
aivp_ids = {r["instance_id"] for r in aivp}

assert len(vanilla_ids) == 500
assert len(aivp_ids) == 500
assert vanilla_ids == aivp_ids

# 記録済みトークンの合計
vanilla_tokens = sum(
    r["total_tokens"] for r in vanilla
)

aivp_tokens = sum(
    r["total_tokens_recorded"] for r in aivp
)

# 生成時間の平均
vanilla_mean = mean(
    r["elapsed_seconds"] for r in vanilla
)

aivp_mean = mean(
    r["elapsed_seconds"] for r in aivp
)

print(f"Vanilla Tokens: {vanilla_tokens:,}")
print(f"AIVP Tokens:    {aivp_tokens:,}")

print(f"Vanilla Mean: {vanilla_mean:.2f}s")
print(f"AIVP Mean:    {aivp_mean:.2f}s")

期待される出力は次のとおりです。

Vanilla Tokens: 147,255,946
AIVP Tokens:    285,460,411
Vanilla Mean: 122.55s
AIVP Mean:    186.13s

このコードでは、同一500問を比較していることもInstance IDの集合で確認しています。

なお、これらは生成時間であり、SWE-benchのDocker評価にかかった時間ではありません。

7.4 AIVPのResolved件数を再確認

AIVPの評価結果は results.json に保存されています。

import json
from pathlib import Path

path = Path(
    "evaluation/aivp-v2-shadow-500/results.json"
)

results = json.loads(
    path.read_text(encoding="utf-8")
)

assert len(results) == 500
assert len({r["instance_id"] for r in results}) == 500

resolved = sum(
    1 for r in results if r["resolved"]
)

ambiguous = sum(
    1 for r in results if r["ambiguous_failure"]
)

print("Total:", len(results))
print("Resolved:", resolved)
print("Unresolved:", len(results) - resolved)
print("Ambiguous:", ambiguous)

出力は以下になります。

Total: 500
Resolved: 405
Unresolved: 95
Ambiguous: 9

Vanilla側の評価結果は、初期のバッチ別評価レポートと、残り130件の評価結果に分かれています。

そのため、AIVP側と同じ単一の results.json が存在するわけではありません。

Vanillaの369件という値は、アーカイブされた複数の評価結果を統合した最終集計です。

7.5 テレメトリの再構築について

アーカイブには、以下のスクリプトも保存しています。

evaluation/resource-telemetry-20261029/rebuild_telemetry.py

ただし、このスクリプトは元のMacに保存された実行ログを参照するため、公開RepositoryをCloneしただけで完全な再構築ができるわけではありません。

公開済みの正規化データの集計と、元ログからの再抽出は区別する必要があります。

8. 考察：Harnessは有効だったのか？

今回の比較で、AIVP v2 ShadowはVanilla Codexより高い解決率を記録しました。

ただし、この結果からすぐに「Harnessを追加すると7.2ポイント改善する」と結論することはできません。

理由は、比較条件が複数の点で異なるためです。

例えば、AIVP側では追加モデルによるレビューと修正工程が存在します。

これらは、次のどの要素が結果に寄与したのかを分離しにくくします。

Additional Reviewer
Additional Model Calls
Prompt / Context Differences
Verification and Repair Workflow
Orchestration Logic

また、ベンチマーク自体へのモデルの事前接触や、推論の非決定性といった問題も残ります。

厳密な効果測定を行うなら、同じモデル・同じ問題・同じ評価条件を用いて、特定の仕組みだけを変更するAblation Studyが必要です。

今回の段階で言えることは、追加のレビュー等を含むAIVPの複合ワークフローが、より多くの計算資源を消費しながら、観測上はより高い解決率を達成したということです。

このQuality / Cost Trade-offこそ、今後さらに検証したいテーマです。

9. 今後の検証課題

次に取り組みたいのは、単純なResolved Rate比較から、問題単位の分析へ進むことです。

例えば、500問を次の4種類に分類できます。

Vanilla	AIVP	分類
Resolved	Resolved	両方成功
Resolved	Unresolved	AIVP側の回帰
Unresolved	Resolved	AIVP側で改善
Unresolved	Unresolved	両方失敗

この4分類を作れば、どの種類の問題で差が生まれたのかを分析できます。

また、対応のある二値結果としてMcNemar検定などを利用し、観測された解決率の差について統計的な検討を進めることも可能です。

さらに、Reviewerの有無、追加モデルの呼び出し回数、リトライ戦略などを個別に変更して、改善要因を切り分けていきたいと考えています。

10. まとめ

今回の500問比較では、以下の結果が得られました。

Vanilla Codex：369/500（73.8%）
AIVP v2 Shadow：405/500（81.0%）
解決率差：+7.2ポイント
記録されたトークン消費量：約1.94倍
平均生成時間：約1.52倍

実験結果は、生成パッチ、評価レポート、テレメトリ、チェックサムとともにGitHubに保存しています。

もちろん、この結果だけでAIVPの各機能の有効性や、任意の開発環境における性能を証明できるわけではありません。

しかし、Coding Agentを単体モデルとしてだけでなく、Verification、Review、Execution Control、Observabilityを含めたシステムとして比較評価するための一つの実験になりました。

個人的には、AIエージェントの性能向上そのものだけでなく、その性能をどのようなEngineering Controlのもとで利用するかという問題に、引き続き取り組んでいきたいと考えています。

参考資料・ソースコード

SWE-bench Verified 比較実験

AIVP v2 Source / Architecture

SWE-bench

※本記事の実験値は2026年10月29日時点の公開研究アーカイブに基づきます。公式Leaderboard Scoreではなく、個人による実験結果です。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up