SWE-CIとは？AIエージェントのコード長期保守性を測るCI型ベンチマーク

SWE-benchやHumanEvalで高得点を出すAIコーディングエージェントが、実際の開発現場で「直したはずのコードが別の機能を壊す」問題を起こす——この落差を数値で捉えるために2026年3月に公開されたのがSWE-CI（arXiv:2603.03823）です。一度きりの修正が通るかではなく、長期の機能追加のなかでコード品質を保てるかを測る、CI（継続的インテグレーション）ループ型のベンチマークです。本記事は論文本文をもとに、SWE-CIが何を評価し、どの指標をどう読み、実務のCI/CDにどう活かすかを整理します。

まとめ：SWE-CIの要点

• 目的：スナップショット型（HumanEval/SWE-bench Verified）では見えない「長期保守性」を、機能的正しさの時間変化で測る。ISO/IEC 25010の保守性を動的評価に置き換えた発想。
• データセット：実在Pythonリポジトリ4,923件から4段階フィルタで100タスクを選定。各タスクは平均233日・71コミットの進化履歴を持つ。
• 評価方式：要件定義役のArchitectと実装役のProgrammerによる二重エージェントが、最大20イテレーションのCIループを回す。
• 指標：Normalized Change（−1〜＋1）、それをγで将来重み付けするEvoScore、そしてゼロ回帰率。
• 結果：8プロバイダ18モデルの実測でClaude Opusシリーズが首位、GLM-5も上位帯。だが大半のモデルはゼロ回帰率0.25未満で、リグレッション制御が最大の課題として残る。

以下、各項目を論文の実数とともに掘り下げます。

SWE-CIとは何か：HumanEval・SWE-benchでは測れない「保守性」を評価する

SWE-CIは、AIエージェントがコードベースをCIワークフローの中で保守できるかを評価する、リポジトリ単位のベンチマークです。従来の主要ベンチマークとの決定的な違いは「時間軸」を評価に組み込んだ点にあります。

スナップショット型ベンチマークの限界

HumanEvalは単一関数の生成、SWE-bench Verifiedは1つのIssueに対する一発修正を評価します。いずれも「その瞬間にテストが通るか」を見るスナップショット型で、修正が将来の機能追加で破綻しないか——保守性——は測定範囲外です。論文はこの評価の空白を、SWE-benchで70%超を出すモデルがSWE-CIでは大きくスコアを落とす現象として示しています。実務ではソフトウェア総コストの多くを保守が占めるため、この空白は評価指標として無視できません。

ISO/IEC 25010の保守性を「時間軸」で動的評価する発想

ISO/IEC 25010は保守性を「既存の品質を損なわずに効果的に変更できる度合い」と定義します。SWE-CIの着想は単純で、「機能的正しさが時間とともにどう変化するかを追えば保守性が見える」というものです。ベース時点のコミットから開始し、ターゲット時点のテスト群を全て通すまで反復させることで、静的な合否ではなく品質の推移そのものを評価対象にしました。

ベンチマークの構造：100タスクのデータセットとArchitect＋Programmer二重エージェント

SWE-CIの独自性は、評価データと評価プロトコルの両方が実際のCI開発を模している点にあります。ここは検索意図としても「swe ci benchmark」に対応する中核です。

4,923リポジトリから100タスクを選ぶデータセット構築

データセットは4段階で構築されます。(1)リポジトリ収集、(2)コミットスパン抽出、(3)実行環境の自動構築、(4)ケースフィルタリング（3サブラウンド）です。リポジトリ収集では、3年以上継続開発され500スター超の実在Pythonリポジトリに絞り込み、フィルタ後に4,923件が残ります。そこから環境を自動構築できた1,458候補ペアに対し、ベース／オラクル対のテストコードを除く総変更行数が1,000行を下回るものを除外するなどの条件で、最終的に100タスクへ絞り込みます。各タスクが平均233日・71コミットという長い履歴を持つのは、短期修正では現れない技術的負債の蓄積を再現するためです。

CIループを再現するArchitect＋Programmer二重エージェント

評価は役割を分けた二重エージェントで進みます。Architectはテスト失敗の根本原因を分析し、要件文書を生成します。このとき1回あたりの要件は最も緊急な5件までに制限され、大規模な作り直しではなく段階的な設計変更を促します。Programmerは要件文書だけを受け取って本番コードを修正し、テスト結果を直接は参照しません。この分離が、人間のレビュアーと実装者が分かれた実際の開発体制に対応します。ループは最大20イテレーションまで反復し、全テスト通過を目指します。

評価指標：Normalized Change・EvoScore・ゼロ回帰率の読み方

SWE-CIは合否の二値ではなく、品質の推移を3つの指標で数値化します。指標の意味を取り違えるとモデル選定を誤るため、ここは丁寧に押さえます。

EvoScoreとγパラメータ：短期成果か長期安定か

Normalized Changeは、各イテレーションでの改善／回帰をベースとオラクルの端点を基準に−1〜＋1の連続値で表します。EvoScoreは、このNormalized Changeをイテレーション全体でγにより将来重み付けした平均です。γが1に近いほど各時点を均等に平均し、γを1より大きくするほど後半のイテレーションに重みが移ります。つまりγを上げると、序盤にテストを通しても後で品質を崩すエージェントが不利になり、最後まで品質を保つエージェントが評価されます。単一の合否では見えない「品質劣化の傾き」を可視化できるのがEvoScoreの狙いです。

ゼロ回帰率が示す「壊しながら直す」問題

ゼロ回帰率は、一度通したテストを後続のイテレーションで壊さなかった割合を示します。論文の実測では大半のモデルがゼロ回帰率0.25未満、つまり全タスクの75%以上でどこかにリグレッションを起こしています。0.5を超えたのはClaude Opusシリーズの2モデルのみでした。局所的にテストを通すことに最適化したエージェントほど、過去に通したテスト状態を壊しやすい構造的な傾向が読み取れます。

18モデル実測：Claude Opus首位とプロバイダ別のγ傾向

論文は8プロバイダ18モデルを、10億トークン超を消費する大規模実験で評価しました。全体としてClaude Opusシリーズが観測期間を通じて首位を維持し、GLM-5も上位帯に位置します。2026年以降にリリースされたモデルほど旧世代より大きくスコアを伸ばしており、静的なバグ修正から長期保守へと能力の重心が移りつつあることを示します。γを変動させる実験では、プロバイダごとに訓練方針の違いが表れます。

この傾向差は、モデル選定時に「短期の一発修正で使うのか、長期の継続保守を任せるのか」という用途とγ設定を対応させて読むべきことを意味します。GLM-5.1のスペックや料金を検討する際も、短期成果に強い一方で長期重み付けでは順位を落とし得る点を踏まえると判断がぶれません。

SWE-benchシリーズとの違いと使い分け

SWE-CIはSWE-benchを置き換えるものではなく、評価軸が異なる補完関係にあります。既存ベンチマークとの住み分けを押さえると、モデル比較の解像度が上がります。

実務では、スナップショット性能をSWE-bench Verifiedで、汚染耐性をSWE-bench Proで確認し、長期保守リスクをSWE-CIのゼロ回帰率で補う、という多角評価が有効です。Claude Mythos PreviewのSWE-bench Pro実測のようなモデル個別のベンチマーク値と、SWE-CIの保守性スコアを併記すると、稟議資料としての説得力が増します。

実務のCI/CDへのSWE-CI活用：無人運用の回避と3つの組み込み

SWE-CIの結果は、AIエージェントを本番のCI/CDに組み込む判断へ直接使えます。ここは論文が示さない実務適用の視点で、立場を明確にして整理します。

結論から言えば、現時点でAIエージェントに保守を無人で任せるのは避けるべきです。大半のモデルが75%以上のタスクでリグレッションを起こす以上、エージェントの変更をレビューなしで自動マージする運用は、既存機能を壊すリスクが高すぎます。導入するなら、次の3点を運用に組み込むのが現実的です。

• 導入前評価：候補モデルのゼロ回帰率とEvoScoreを、自社の用途（短期修正か長期保守か）に対応するγで確認する。長期保守を任せるならγを高めた評価を重視する。
• 体制への写像：ArchitectとProgrammerの分離を、要件レビューと実装レビューを分けた自社のコードレビュー体制へそのまま対応させる。エージェントの実装は必ず人間のリグレッションテストで受ける。
• 回帰の自動検知：CIにリグレッションテストの自動実行を組み込み、エージェントが通した状態を後続変更が壊していないかを機械的に監視する。

なお、SWE-CIの評価対象はPythonリポジトリに限定され、実験ではArchitectとProgrammerに同一モデルを使っています。他言語や人間との協働体制でのスコアはこの結果から直接は推論できない点を、社内資料には明記しておくべきです。AIコーディングエージェント全般の選び方はCoding Agentの種類と比較も併せて参照すると、SWE-CIの数値を選定基準へ落とし込みやすくなります。

よくある質問

SWE-CIとSWE-benchの違いは何ですか？

SWE-benchは1つのIssueに対する一発修正が通るかを見るスナップショット型、SWE-CIは平均233日・71コミットの進化履歴を反復して長期保守性を見る進化型です。SWE-benchで70%超を出すモデルもSWE-CIでは大きくスコアを落とすことがあり、評価軸が異なります。

SWE-CIはどのモデルが最も高性能でしたか？

8プロバイダ18モデルの実測で、Claude Opusシリーズが首位を維持しました。GLM-5も上位帯に位置します。ゼロ回帰率0.5を超えたのはClaude Opusシリーズの2モデルのみでした。

EvoScoreのγパラメータは何を調整しますか？

各イテレーションへの重み付けを調整します。γが1に近いと均等平均、1より大きいと後半のイテレーションを重視し、長期的に品質を保つエージェントが高く評価されます。短期成果を重視するか長期安定を重視するかを、γの設定で切り替えられます。

ゼロ回帰率が低いと実務では何が問題ですか？

ゼロ回帰率0.25未満は、全タスクの75%以上で「直した一方で別のテストを壊す」ことを意味します。エージェントの変更をレビューなしで自動マージすると既存機能を壊すリスクが高く、人間のレビューとリグレッションテストの自動実行を併用する運用が前提になります。

SWE-CIはどこで公開されていますか？

論文はarXiv:2603.03823として2026年3月に公開され、実装はGitHubのSKYLENAGE-AI/SWE-CIで確認できます。評価対象はPythonリポジトリに限定されています。

関連記事

• Coding Agentとは｜種類・主要ツール比較と選び方【2026】
• Claude Mythos Preview（クロード・ミトス）とは？性能ベンチマーク・脆弱性発見・Bedrock提供と一般非公開の理由
• GLM-5.1とは？744B MoEのスペック・VRAM要件とGGUF量子化ローカル実行、Coding Plan料金を解説
• Devstral 2とは？Mistral AIが公開した次世代コーディングAIモデルの概要と特徴を解説