SWE-CIが従来ベンチマークの限界を超えて評価する「長期保守性」の正体

SWE-CIが従来ベンチマークの限界を超えて評価する「長期保守性」の正体

AIによるコード生成能力は急速に進歩しており、SWE-benchをはじめとする複数のベンチマークで高いスコアを記録するモデルが続々と登場しています。しかし、こうした評価の多くは「一度きりの修正が正しく動くか」というスナップショット型の検証に留まっており、実際のソフトウェア開発で最も重要とされる長期保守性を測定できていません。2026年3月に公開されたSWE-CIは、この根本的な限界を克服するために設計された初のリポジトリレベルベンチマークです。従来の「機能的正しさ」から「動的かつ長期的な保守性」へと評価パラダイムを転換する点に、最大の意義があります。

HumanEvalやSWE-benchのスナップショット評価では見えない設計品質の差

HumanEvalは164個のPython関数生成問題で構成され、MBPPも同様に単一ファイルの合成タスクを評価対象としています。これらのベンチマークでは、与えられた仕様に対して正しく動作するコードを一度だけ生成すれば合格となります。SWE-benchはリポジトリレベルに評価範囲を拡大しましたが、GitHubのIssueに対するパッチを一発で生成する「Issue-to-PR」パラダイムである点は変わりません。

このスナップショット型評価の最大の問題は、場当たり的なハードコード修正と、拡張性を考慮した設計の良いコードが同じテストスイートで合格してしまうことです。両者の違いは、コードベースが進化して新しい要件が追加されたときに初めて顕在化します。短期的に正しく動くコードであっても、将来の変更を妨げる構造的な欠陥を内包しているケースは実務で頻繁に発生しており、スナップショット評価ではこの差を検出できません。

保守コストがソフトウェア総コストの60〜80％を占める現実と評価の空白地帯

ソフトウェア工学の古典的な文献が繰り返し指摘してきたように、ソフトウェアのライフサイクル全体で発生するコストのうち、保守活動が60〜80％を占めるとされています。Frederick P. Brooksの著書『人月の神話』をはじめ、多くの研究がこの事実を裏付けてきました。にもかかわらず、AIコーディング能力の評価はほぼ全面的に「新規コード生成」や「バグ修正の一発勝負」に集中しています。

つまり、ソフトウェア開発コストの大部分を占める保守フェーズに対応する評価基準が、これまで事実上存在しなかったということです。SWE-CIの登場以前は、モデルが長期的なコード品質をどの程度維持できるかを定量的に測定する手段がなく、開発現場でのAIエージェント導入判断は、スナップショット型スコアに頼らざるを得ない状況でした。この評価の空白地帯こそ、SWE-CIが埋めようとしている領域にほかなりません。特にレガシーシステムの保守では、元の開発者が不在のまま仕様書も不十分な状態でコード変更を求められるケースが多く、AIエージェントの活用が期待される分野でもあります。

一発修正で合格できるテストが長期運用で破綻する「技術的負債」の蓄積構造

技術的負債とは、短期的な利便性を優先して行ったコード変更が、将来の開発コストを増大させる状態を指します。たとえば、テストを通すために特定の条件分岐をハードコードした場合、そのコードは現在のテストには合格しますが、類似の機能追加が求められたときに大幅な書き直しが必要になります。

スナップショット型ベンチマークでは、この種の負債は評価対象になりません。テストが通った時点で「正解」として扱われるためです。しかし実際の開発では、こうした負債が積み重なることで各回の変更がますます困難になり、最終的にはコードベース全体の品質が劣化する悪循環に陥ります。SWE-CIは、複数回のイテレーションを通じてこの蓄積プロセスを再現し、過去の設計判断が後続の進化にどう影響するかを可視化する仕組みを備えています。Lehmanの法則が示すように、ソフトウェアの品質はメンテナンスの進行とともに本質的に劣化する傾向があり、この劣化プロセスを定量的に捉えるベンチマークの必要性は以前から指摘されていました。

ISO/IEC 25010が定義する保守性を動的評価へ転換した設計思想の独自性

ISO/IEC 25010は、ソフトウェア品質モデルの国際規格として保守性を「欠陥を導入したり既存の品質を劣化させたりすることなく、効果的にソフトウェアを変更できる度合い」と定義しています。この定義の重要なポイントは、保守性が単一のスナップショットでは観測不可能であり、連続的な変更を通じてのみ顕在化するという点です。

SWE-CIの設計者はこの原則を忠実にベンチマーク設計へ落とし込みました。具体的には、ベースコミットからターゲットコミットへ向けてコードベースを反復的に進化させ、各イテレーションでのテスト通過状況を追跡することで、保守性を数値として捉える仕組みを構築しています。一度きりの合否判定ではなく、進化の過程全体を評価対象とするこのアプローチは、ISO規格の趣旨に最も忠実な実装といえます。なお、ISO/IEC 25010は2023年に改訂版が発行されていますが、保守性の根本的な定義は維持されており、SWE-CIの設計根拠としての妥当性は変わりません。

2026年3月公開の論文が提示した「進化ベース評価」という新パラダイムの要点

SWE-CIの論文は2026年3月4日にarXivで公開されました。中山大学とアリババグループの共同研究として発表されたこのベンチマークは、従来のスナップショット型評価に対して「進化ベース評価」という新しいパラダイムを明確に打ち出しています。進化ベース評価では、要件が現在のコードベースから動的に導出され、コードの更新結果が次のイテレーションに引き継がれます。

この設計により、早期の設計判断が後続のイテレーションに与える影響が累積的に観測可能となります。スナップショット型では要件があらかじめ固定されているのに対し、進化ベースでは各ステップの成果物が次のステップの入力条件を変化させるため、長期的な判断品質がスコアに直結する構造になっています。8社18モデルを対象とした100億トークン超の大規模実験によって、その有効性が実証されました。論文はCC BY 4.0ライセンスで公開されており、ベンチマークのデータセットはHugging Face上で、評価コードはGitHub上でそれぞれ公開されています。

100タスク×平均233日の進化履歴から構築されたデータセット設計の全体像

SWE-CIのデータセットは、単にリポジトリからタスクを収集したものではなく、厳密な4段階のフィルタリングプロセスを経て構築されています。最終的に残った100タスクは68の異なるリポジトリから抽出され、各タスクは平均233日・71コミットという実質的な開発履歴を内包しています。この規模と品質の両立が、SWE-CIの評価結果に対する信頼性を支えています。

GitHub上4923リポジトリから4段階フィルタで100件に絞り込む選別プロセス

SWE-CIのデータセット構築は、GitHub上の全Pythonリポジトリを対象とする大規模なスクリーニングから始まります。第1段階のリポジトリ収集では、3年以上の継続的なメンテナンス実績、500スター以上の獲得、設定ファイルとユニットテストの存在、MITやApache-2.0などの許容的ライセンスという4つの条件で絞り込みを行い、4923リポジトリが残りました。

第2段階のコミットスパン抽出で8311候補ペア、第3段階の環境構築で1458ペア、第4段階のケースフィルタリングで137件にまで絞り込まれ、最終的に時間スパンとコミット数のランキング上位100件が選出されました。この段階的な選別によって、環境の再現性が確認済みで、かつ十分な進化的距離を持つタスクのみがベンチマークに含まれる仕組みになっています。SWE-benchが少数の有名プロジェクトに偏重している点と対照的に、SWE-CIは幅広いリポジトリから均質な品質のタスクを収集しています。

3年以上の継続開発と500スター以上を条件とするリポジトリ品質基準の意図

リポジトリ選定条件として「3年以上の継続開発」を課しているのは、長期保守性の評価に十分な進化履歴を確保するためです。短期間で開発が停止したリポジトリでは、要件変更や機能拡張の連鎖が発生しておらず、保守性を測定する材料として不適切になります。3年以上という基準は、少なくとも複数回のメジャーアップデートやリファクタリングを経験していることを担保しています。

500スター以上の条件は、一定数の利用者と貢献者がいるプロジェクトであることを意味します。スター数が少ないリポジトリは、個人の実験的プロジェクトや未完成の習作である可能性が高く、テストの網羅性やコード品質が安定しません。この基準により、産業レベルの品質管理が行われている実務的なリポジトリのみがデータセットに含まれることになり、ベンチマーク結果の実務への適用可能性が高まります。加えて、設定ファイル（pyproject.tomlやlockfiles）とユニットテストの存在も必須条件とされており、CI/CDパイプラインが整備された成熟プロジェクトのみが選ばれています。

平均71コミット・最低500行変更を要件とするベース／オラクル対の抽出手法

SWE-CIの各タスクは、同一リポジトリ内の2つの時系列的に順序付けられたコミット（ベースコミットとオラクルコミット）のペアとして定義されます。ベースからオラクルへの遷移には、テストファイルの変更を除いて最低500行のソースコード変更が必要とされており、些末な増分変更は排除されています。

平均71コミットという数値は、各タスクがバグ修正や小規模な調整ではなく、機能追加・リファクタリング・API変更などを含む本格的な進化エピソードであることを示しています。この規模の変更量を要件とすることで、エージェントに求められる作業は単なるパッチ適用ではなく、コードベース全体の構造を理解した上での段階的な改修となります。結果として、モデルの長期的な設計判断能力が自然に評価対象になる仕組みです。なお、変更行数のカウントはテストファイルの変更を除外した上で算出されており、テストコードの追加だけでタスクが水増しされる問題を排除しています。この基準によって、各タスクの実質的な複雑さが担保されています。

依存関係の不変区間を利用したコミットスパン抽出が排除するノイズの種類

コミットスパンの抽出にあたり、SWE-CIは各リポジトリのメインブランチを線形なコミット列に変換した上で、依存関係が変化しない最大区間を特定しています。この手法の狙いは、依存パッケージのバージョン変更に起因するテスト失敗をノイズとして排除することにあります。

実際の開発では、ライブラリのアップグレードに伴うAPI互換性の問題やランタイム環境の差異が頻繁に発生しますが、これらはエージェントのコーディング能力とは無関係な外部要因です。依存関係が不変な区間のみを候補とすることで、テスト結果の差異がすべてソースコードの変更に起因することが保証され、純粋にコード保守能力を測定できる環境が整う仕組みです。この設計判断は、ベンチマークの内的妥当性を高める上で極めて重要な役割を果たしています。さらに、依存関係が変わらない区間内であればDocker環境を統一できるため、評価環境の一貫性も自動的に確保されます。この二重のメリットが、SWE-CIのデータ品質を支える設計上の鍵となっています。

Docker環境の自動構築と自己修復メカニズムで再現性を担保する実装上の工夫

各タスクには、オラクルコードベースの設定と依存関係に基づいて自動生成されたDockerfileが付属しています。このDocker環境内でユニットテストを実行することで、評価結果の再現性が確保されます。さらにSWE-CIは、テストスイートの起動に失敗した場合に不足する依存関係を自動検知し、Dockerfileに動的に追加する自己修復メカニズムを実装しています。

この仕組みにより、依存関係の記述漏れという一般的な問題が原因でタスクが破棄されるケースが大幅に減少し、データ保持率が向上しました。最終的に各サンプルは、完全なソースコードと事前構築済みのDocker環境とともに提供されるため、評価者は環境構築の手間なく即座に実験を開始できます。この再現性へのこだわりは、ベンチマーク結果の比較可能性を担保する上で不可欠な要素となっています。具体的には、第3段階の環境構築で当初の候補8311ペアから1458ペアが生き残りましたが、自己修復メカニズムがなければこの数はさらに大幅に少なかった可能性があります。

Architect＋Programmer二重構造が再現するCI開発ループの仕組み

SWE-CIは進化ベース評価を支えるために、Architect（設計者）とProgrammer（実装者）の二重エージェント評価プロトコルを採用しています。この構造は、実務のCI/CD開発における役割分担を模倣したもので、要件定義と実装の関心事を明確に分離することで、現実の開発プロセスに近い条件下での評価を可能にしています。

要件定義と実装を分離する二重エージェント設計がCI/CDの実務に対応する理由

実際のソフトウェア開発チームでは、プロダクトマネージャーやテックリードが要件を整理し、開発者がその要件に基づいて実装を行うという役割分担が一般的です。SWE-CIの二重エージェント設計は、この分業体制を忠実に再現しています。Architectが現在のコードとオラクルコードのテスト差分を分析して高レベルの要件文書を作成し、Programmerがその文書に基づいてコードを修正するという流れです。

この分離がなければ、エージェントはテスト結果を直接参照して場当たり的な修正を行う可能性があります。要件文書を介在させることで、エージェントの行動がCI/CDの急速な反復サイクルの哲学と整合し、より現実的な開発シナリオでの能力評価が実現します。さらに、この分離構造はArchitectの要件定義能力とProgrammerの実装能力を独立して評価できるため、モデルのどの能力に改善余地があるかを特定する診断ツールとしても機能します。

Architectが1回あたり最大5要件に制限する「インクリメンタル設計」の狙い

Architectエージェントには、1回のイテレーションで出力する要件を最大5件に制限するルールが課されています。このインクリメンタル（段階的）設計の意図は、一度に大量の変更を行うことによる品質劣化を防ぎ、CI/CDの「小さく頻繁にリリースする」原則を再現することにあります。

全体のテスト失敗を一挙に解決しようとすると、変更範囲が広がりすぎて予期せぬ副作用が発生しやすくなります。5件以下に絞ることで、Programmerが集中的かつ的確に開発を行える範囲に作業が限定されます。この制約はまた、要件の優先順位付け能力をも評価対象にしています。多数の失敗テストから最も緊急度の高い要件を選別する判断力は、実務における技術リーダーに求められるスキルそのものです。実際のCI/CDプラクティスでも、一度のスプリントで扱う変更範囲を限定することは品質管理の基本原則です。SWE-CIはこの原則をベンチマーク上で再現しており、過度に野心的な変更計画がリグレッションを引き起こすリスクを定量的に観測できる環境を提供しています。

テスト失敗の根本原因分析から要件文書生成までArchitectが踏む3ステップ

Architectエージェントの振る舞いは、3つの標準化されたステップで構成されています。第1ステップの「Summarize」では、すべての失敗テストをレビューし、根本原因を特定するとともに、追加調査が必要なソースコードファイルを洗い出します。第2ステップの「Locate」では、実際のソースコードを精査して、失敗の原因を現在の実装上の具体的な欠陥に帰属させます。

第3ステップの「Design」では、特定された欠陥に対する改善計画を策定し、最終的な要件文書を生成します。この要件文書には2つの重要な制約があります。1つは前述のインクリメンタル制約で、最大5件の最緊急要件に絞ること。もう1つはハイレベル制約で、期待される振る舞いを自然言語で記述し、具体的な実装方法はProgrammerに委ねることです。これらの制約により、現実のCI/CDプロセスで求められるコミュニケーション品質が評価に組み込まれています。

要件文書だけを受け取るProgrammerがテスト結果を直接参照しない設計上の制約

Programmerエージェントは、Architectが作成した要件文書のみに基づいてコード修正を行います。テストの失敗結果を直接参照することは意図的に禁じられています。この制約は一見すると非効率に思えますが、CI/CDの実務において開発者がテスト結果そのものではなく要件定義書やチケットに基づいて作業を進める実態を反映した設計です。

Programmerの行動も3ステップで標準化されており、「Comprehend」で高レベルの要件を具体的なコード仕様に変換し、「Plan」で実装に必要な作業計画を立て、「Code」で実際のコード変更を実施するという流れです。テスト結果への直接アクセスを遮断することで、エージェントがテストに特化した局所的な最適化に走ることを防ぎ、要件を正しく理解して汎用的なコードを書く能力が問われる構造になっています。回帰防止の観点からもこの設計は重要で、テスト結果を直接見ると失敗テストだけに注目して通過テストへの影響を軽視しがちですが、要件文書を介することで変更の目的が明確化され、意図しない副作用のリスクが構造的に低減されます。

最大20イテレーションの反復ループが長期保守シナリオを再現する評価プロセス

SWE-CIの評価プロトコルでは、Architect→Programmer→テスト実行というCIループが最大20回反復されます。各イテレーションで、Architectは前回のテスト結果を踏まえて新たな要件を策定し、Programmerはその要件に従ってコードを更新します。この反復構造により、1回のコード変更が後続の変更容易性にどう影響するかが観測可能になります。

テストフレームワークにはpytestとpytest-json-reportが使用され、1回のテスト実行にはタイムアウト3600秒が設定されています。エージェントフレームワークにはiFlow CLIが採用されており、特に指定がない限りArchitectとProgrammerは同一のベースモデルを使用します。20イテレーションという上限は、実務の開発スプリントに相当する規模感であり、短期的な成果と長期的な安定性のトレードオフが自然に生じる設計となっています。

EvoScoreとNormalized Changeが数値化する「技術的負債」の蓄積リスク

SWE-CIが従来のベンチマークと決定的に異なるのは、独自の評価指標であるEvoScoreとNormalized Changeを導入している点です。これらの指標は、単なるテスト合格率ではなく、長期的な進化過程での品質変動を一つの数値に集約する仕組みを提供します。技術的負債の蓄積が後続イテレーションのスコアに反映されるため、目先のテスト通過だけを追求するアプローチは自ずと低評価になります。

改善と回帰を−1〜＋1の統一スケールで表すNormalized Changeの算出式

Normalized Changeは、コードベースの現在の状態を−1から＋1の範囲で評価するスカラー値です。まず、コードベースcが通過するテスト数n(c)を算出します。ベースコードベースc0よりもテスト通過数が増えている場合（改善時）は、改善幅をオラクルとベースの差で正規化します。逆にベースよりもテスト通過数が減少している場合（回帰時）は、減少幅をベースのテスト通過数で正規化します。

この非対称な正規化設計には明確な意図があります。ベースとオラクルのテスト数がどのような値であっても、改善と回帰を常に同一の統一スケール上で比較できるようにするためです。a(c)＝1はオラクルとのギャップを完全に解消したことを意味し、a(c)＝−1はベースで通過していた全テストを破壊したことを示します。この設計により、タスク間の難易度差を吸収した公平な比較が可能になる点が特徴です。この設計の実用上の利点として、異なるタスク間でのスコア比較が容易になる点が挙げられます。テスト総数が数十のタスクと数百のタスクであっても、正規化によって同じスケール上での比較が可能になります。

未来の反復に重みを置くγパラメータがEvoScoreの評価軸を変動させる仕組み

EvoScoreは、N回のイテレーションで得られた一連のNormalized Change値を、未来加重平均によって単一のスカラー値に集約します。計算式は、各イテレーションiのa(ci)にγのi乗を掛けて合計し、γのi乗の合計で除するというものです。ここでγは1以上の値に設定され、後のイテレーションほど大きな重みが付与されます。

γパラメータの値を変えることで、評価の焦点を調整できる柔軟な設計です。γが1に近い場合は全イテレーションが均等に評価され、γを大きくするほど後半のイテレーションでの成績が重視される仕組みとなっています。ISO/IEC 25010の保守性定義にも忠実に対応しており、真に保守性の高いコードは進化が進んでも修正が容易であり続けるはずだという仮説に基づく設計です。数学的には、γのi乗による重み付けは指数関数的な増大を意味し、γの値をわずかに変えるだけでも後半イテレーションへの重みは大きく変化します。この感度の高さが、γ変動実験においてモデル間の特性差を鮮明に描き出す要因となっています。

γ＝1で平均値・γ＞1で長期安定性重視に切り替わるスコア設計の柔軟性

γ＝1の場合、EvoScoreは全イテレーションのNormalized Changeの単純平均に等しくなります。この設定では、短期的に高いスコアを出すモデルと長期的に安定したスコアを維持するモデルが同等に評価されるため、一般的な性能指標として機能します。一方、γを1より大きくすると、後半のイテレーションに対する重みが指数関数的に増加します。

この柔軟性により、評価者は自身の目的に応じて重視する軸を切り替えることができます。たとえば、プロトタイプの迅速な構築を重視する開発フェーズではγ＝1に近い設定が適切であり、長期運用を前提としたプロダクション環境への導入判断ではγを大きく設定して安定性を重視する、といった使い分けが可能です。SWE-CIの論文では、γの変動に伴うモデルランキングの変化も分析されており、プロバイダごとの戦略差が浮き彫りになっています。注目すべきは、γの値によってモデルの相対順位が入れ替わるケースが存在する点です。あるモデルがγ＝1では上位に位置しながら、γ＝2では大きく順位を下げるという現象は、そのモデルが短期的な成果に偏重した戦略を採っていることの証左となります。

短期的にテストを通過しても後続イテレーションで点数が下がる技術的負債の可視化

EvoScoreの設計上、初期のイテレーションで高いNormalized Changeを記録しても、後半で回帰が発生すればスコアは大きく低下します。特にγ＞1の設定では、この傾向が顕著になります。これは、場当たり的な修正でテストを通しても、その修正が後続の変更を困難にする場合にペナルティとして機能することを意味します。

たとえば、特定のテストケースを通過させるためにグローバル変数を追加したり条件分岐をハードコードしたりすると、次のイテレーションでそのコードが障害になり、新しいテストへの対応が困難になります。このとき、以前通過していたテストまで失敗する回帰が発生し、Normalized Changeが負の値に転じます。EvoScoreはこの技術的負債の蓄積過程を時系列データとして捉え、最終的なスコアに反映させる仕組みです。この可視化機能は、モデル開発者にとっても有用です。どのイテレーション段階で品質低下が始まるかを特定することで、モデルの弱点を具体的に把握し、訓練データや学習方法の改善に活かすことが可能になります。

従来ベンチマークの合否二値判定では検出不可能だった「品質劣化の傾き」の把握

SWE-benchをはじめとする従来のベンチマークでは、各タスクの結果は「解決（Resolved）」か「未解決（Unresolved）」の二値で記録されます。全テストが通過すれば解決、1つでも失敗すれば未解決です。この方式では、90％のテストを通過したモデルと10％しか通過できなかったモデルが同じ「未解決」として扱われ、部分的な進捗や品質の変化傾向を把握できません。

SWE-CIのNormalized ChangeとEvoScoreは、この制約を根本的に解消する指標です。各イテレーションでのテスト通過数の変化を連続値として記録するため、「品質が徐々に改善している」「ある時点から急激に劣化している」「安定的に推移している」といった傾向分析が可能になります。この品質変動の時系列データは、AIエージェントの挙動を診断する上で極めて有用な情報を提供し、モデルの改善方向を具体的に示唆できます。たとえば、あるモデルが最初の5イテレーションで急速にテスト通過数を増やした後、6イテレーション目以降で徐々にリグレッションが増える場合、その「転換点」をEvoScoreの時系列データから正確に特定できます。

8社18モデルの実測結果から見えたコード保守能力の格差と傾向

SWE-CIの論文では、8つのプロバイダから合計18モデルを対象に、100億トークンを超える大規模実験が実施されました。その結果、モデル間の保守能力には顕著な格差があること、同一プロバイダ内では新しいモデルほど高スコアを記録すること、そしてプロバイダごとに短期成果と長期安定性のどちらを重視する傾向があるかが異なることが明らかになりました。

10億トークン超を消費した大規模実験でClaude Opusシリーズが首位を維持した背景

SWE-CIの実験は、合計で100億トークンを超える大規模な計算資源を投入して行われました。各モデルが100タスクに対して最大20イテレーションのCIループを実行し、各イテレーションでArchitectとProgrammerの両エージェントが動作するため、トークン消費量は膨大になります。この実験条件下で、Claude Opusシリーズが観測期間全体を通じて首位を維持したことが報告されています。

Claude Opusの優位性は、SWE-bench VerifiedやSWE-bench Proなど他のベンチマークでも確認されている傾向と一致しています。ただし、SWE-CIでの首位維持は、単なる一発修正の精度だけでなく、反復的なコード進化における設計判断の質が高いことを反映した結果です。長期保守性に特化した評価でも高スコアを記録した点は、Claude Opusのコーディング能力が短期的な問題解決と長期的な保守性の双方をカバーしていることの証左といえるでしょう。GLM-5も強力な性能を示した点は注目に値します。

2026年以降リリースのモデルが示す保守性能の加速度的な向上トレンド

SWE-CIの実験結果から、同一プロバイダ内では例外なく新しいモデルが高いスコアを記録するという一貫したパターンが確認されました。特に2026年以降にリリースされたモデルは、前世代と比較して顕著に大きなスコア向上を示しています。この加速度的な改善は、モデルの学習データや訓練手法が静的なバグ修正だけでなく、持続的なコード保守に必要な能力を徐々に獲得しつつあることを示唆しています。

この傾向はAIコーディング分野全体にとって前向きなシグナルですが、絶対的なスコアの観点では依然として大きな改善余地が残っています。最も高い性能を示したモデルであっても、長期保守シナリオでは頻繁にリグレッションを発生させており、完全自動化にはまだ距離がある状況です。とはいえ、改善の速度が加速している点は、近い将来に実用水準へ到達する見通しを裏付けるものです。この加速的な改善には、モデルの訓練データにコード保守に関連するパターンがより多く含まれるようになったことや、長期的な文脈理解能力の向上が寄与していると考えられ、SWE-CIのような長期保守性ベンチマークの登場が今後のモデル開発方針にも影響を与えることが予想されます。

MiniMax・DeepSeek・GPTが長期重み付けで有利になるプロバイダ別の傾向差

SWE-CIの論文では、γパラメータを変動させたときのモデルランキングの変化が詳細に分析されています。γ＞1（長期安定性重視）の設定では、MiniMax、DeepSeek、GPTの各モデルが相対的に順位を上げることが確認されました。これらのプロバイダのモデルは、後半のイテレーションでもスコアの低下が少なく、長期的な保守性に強みを持つ傾向があります。

この傾向差は、各プロバイダの訓練戦略の違いを反映していると論文では推測されており、長期重み付けで有利になるモデルはコード変更の副作用を予測し、将来の拡張性を考慮した設計を行う傾向が相対的に強いと考えられます。実務でAIエージェントを導入する際に、長期運用を前提とするプロジェクトではこれらのモデルが適している可能性があるという実践的な示唆を含む結果です。この知見は、各プロバイダが公表するSWE-bench Verifiedのスコアだけでは把握できない特性を浮き彫りにしており、同程度のSWE-benchスコアを持つモデルであっても、SWE-CIのγ変動実験では異なる長期保守特性を示すことから、用途に応じた選定の重要性が裏付けられています。

Kimi・GLMが短期成果重視で順位を上げるγ変動実験から読み取れる訓練方針の違い

γ＜1（短期成果重視）の設定に切り替えると、KimiとGLMが相対的に順位を上げるという結果が得られています。これらのモデルは、初期のイテレーションで高いNormalized Changeを記録する傾向があり、素早くテスト通過数を増やす能力に優れています。一方で、後半のイテレーションではスコアの維持が相対的に難しくなる傾向も見られます。

興味深いことに、同一プロバイダ内のモデルは一貫した傾向を示すことが報告されています。つまり、短期重視か長期重視かの特性は個別モデルの偶発的な特徴ではなく、プロバイダの内部的な訓練パイプラインに起因する構造的な傾向である可能性が高いということです。この知見は、プロジェクトの特性に応じたモデル選定の指針として活用できます。迅速なプロトタイピングが求められる場面では短期成果重視のモデルが適しており、長期運用を前提とする基幹システムでは長期安定性重視のモデルが望ましいといった判断材料になります。

Claude・Qwen・Doubaoがγ変動に安定する「バランス型」の特徴と実務的意味

γの変動に対してランキングがほとんど変化しないモデルも存在します。ClaudeとQwen、Doubaoは、γ＜1でもγ＞1でも順位が安定しており、短期成果と長期安定性のバランスが取れた「バランス型」モデルとして特徴づけられています。この安定性は、どのようなイテレーション段階でも一定水準の品質を維持するコード変更を行う傾向があることを示しています。

実務の観点では、バランス型モデルはプロジェクトの特性が事前に明確でない場合や、短期的な成果と長期的な保守性の両方が求められる一般的な開発シナリオにおいて最も汎用的な選択肢となります。γの設定に関わらずスコアが安定しているということは、評価基準の変動に対するロバスト性が高いことを意味し、予測可能な品質を提供できるモデルとして信頼性が高い点も見逃せません。この安定性は、訓練プロセスにおいて短期的な最適化と長期的な設計品質のバランスが意識的に調整されている可能性を示唆しています。エンタープライズ環境では、特定の評価軸での極端な強みよりも、幅広い条件下での安定した性能が求められることが多く、バランス型モデルの価値は高いといえます。

ゼロ回帰率0.25未満が示す現行AIエージェントのリグレッション制御の課題

SWE-CIの実験結果の中で最も衝撃的な発見は、大多数のモデルがリグレッション制御に深刻な問題を抱えているという事実です。ゼロ回帰率（全イテレーションを通じて一度もリグレッションを発生させなかったタスクの割合）は、ほとんどのモデルで0.25を下回っています。これは、100タスク中75以上のタスクで少なくとも1回はリグレッションが発生していることを意味しており、AIエージェントの本番環境への導入に対する重大な警告となっています。

全タスク中75％以上でリグレッションが発生する現状が意味する品質リスクの深刻度

リグレッションとは、コード変更後に以前は通過していたテストが失敗する現象です。ソフトウェア保守において、リグレッションの発生はユーザー体験の直接的な悪化を意味し、長期的にはシステム全体の品質劣化を招きます。SWE-CIの実測データでは、大半のモデルがタスクの75％以上でリグレッションを発生させており、この数字は現行AIエージェントの限界を明確に示しています。

実務の文脈に置き換えると、AIエージェントにコード保守を任せた場合、4回の変更のうち3回以上で既存機能が何らかの影響を受けるリスクがあるということです。これは人間のコードレビューや追加のテスト工程なしにAIエージェント単体で保守作業を自動化することが、現時点では困難であることを明確に示しています。スナップショット型ベンチマークの高スコアだけでAIエージェントの保守能力を判断することの危険性が、この数値によって具体的に裏付けられています。

ゼロ回帰率0.5超を達成した唯一のモデル系列Claude Opusの実測データと考察

18モデルの中で、ゼロ回帰率が0.5を超えたのはClaude Opusシリーズのみでした。つまり、全タスクの半数以上でリグレッションを一度も起こさずにコード進化を完遂できた唯一のモデル系列です。他のすべてのプロバイダのモデルはこの基準に達しておらず、一部のモデルは0.25にも満たない水準にとどまっています。

Claude Opusがリグレッション制御に優れる要因として、コード変更の影響範囲を予測する能力の高さが推測されます。変更を加える際に、その変更が既存のテストケースに与える影響を事前に考慮できるモデルは、回帰を引き起こすリスクを低減できます。ただし、0.5超という数値は「半数以上のタスクでリグレッションなし」という意味であり、依然として相当数のタスクでリグレッションが発生していることには変わりありません。最良のモデルであっても完璧ではないという事実は、AI支援開発における人間の監視の重要性を再確認させます。

局所最適化に陥るエージェントが過去のテスト通過状態を壊す構造的な原因

リグレッション率が高い根本的な原因は、現行のAIエージェントが局所最適化を行う傾向にあることです。エージェントは現在失敗しているテストを見て、それを通過させるための修正に集中しますが、その修正が現在通過しているテストにどのような影響を与えるかについては十分にモデル化できていません。

この問題は、各イテレーションが独立した最適化問題として扱われることに起因します。人間の開発者であれば、過去のコード変更の文脈やシステム全体のアーキテクチャを考慮した上で修正方針を決定しますが、AIエージェントは現在のコンテキストウィンドウに含まれる情報のみに基づいて判断を行います。233日間・71コミットにわたる累積的なロジックを完全に把握した上で安全な変更を行うことは、現行モデルのコンテキスト管理能力では極めて困難な課題です。人間の開発者であれば「この変更は他のモジュールに影響しないか」と直感的にチェックしますが、現行のAIエージェントにはこの種の大域的な影響評価が欠けているケースが多いのです。

233日間の累積ロジックに対応できない現行モデルのコンテキスト管理の限界

SWE-CIの各タスクは平均233日の開発履歴を内包しており、その間に蓄積されたビジネスロジック、設計上の決定、暗黙の依存関係は膨大な量になります。現行のLLMは大規模なコンテキストウィンドウを持つようになりましたが、リポジトリ全体のコードベースとその進化履歴を完全に把握した状態で判断を下すことは依然として困難です。

特に問題となるのは、明示的に記述されていない暗黙の依存関係です。あるモジュールの振る舞いが別のモジュールのテスト結果に影響を与えるケースでは、コード上の直接的なリンクが存在しないため、エージェントが影響範囲を正確に特定できません。この限界は、コンテキストウィンドウのサイズだけでなく、コード間の複雑な相互作用を推論する能力にも関わる本質的な課題であり、単純なモデルスケーリングだけでは解決が難しい問題を提起しています。この課題は、リポジトリ対応型RAG（Retrieval-Augmented Generation）やコードグラフベースの推論強化など、新しい技術的アプローチによって緩和される可能性があります。SWE-CIは、こうした次世代技術の有効性を検証するためのテストベッドとしても機能します。

リグレッション多発がCI/CD自動化の本番導入判断に与える実務上のブレーキ要因

企業がCI/CDパイプラインにAIエージェントを導入する際の最大の懸念は、既存の動作を壊さないかという信頼性の問題です。SWE-CIの実測データが示す75％超のリグレッション発生率は、この懸念を定量的に裏付けるものであり、完全自動化への導入判断に対する強力なブレーキとなります。

ただし、この結果はAIエージェントの保守能力を完全に否定するものではありません。改善トレンドは明確であり、特に2026年以降のモデルはリグレッション制御能力が向上しています。現実的な導入戦略としては、AIエージェントによる変更提案に対して人間のコードレビューとリグレッションテストの自動実行を組み合わせるハイブリッドアプローチが有効です。SWE-CIの評価結果は、このような段階的導入の判断材料として極めて有用な定量データを提供しています。特に、ミッションクリティカルなシステムにおいては、リグレッションの1件あたりのコストが極めて高いため、ゼロ回帰率の低いモデルを無条件に導入することは大きなリスクを伴います。段階的な導入と継続的なモニタリングが不可欠です。

SWE-benchやSWE-bench Proとの比較で明確になるSWE-CIの独自評価軸

AIコーディング能力のベンチマークは近年急速に多様化しており、SWE-bench Verified、SWE-bench Pro、SWE-bench Live、SWE-rebenchなど複数の評価基盤が並立しています。これらのベンチマークはそれぞれ異なる課題に対処していますが、SWE-CIが焦点を当てる「長期保守性」という評価軸は他のどのベンチマークにも存在しない独自の領域です。

SWE-bench Verifiedの一発修正型とSWE-CIの反復進化型の評価範囲

SWE-bench Verifiedは、人間のアノテーターによって検証された500タスクで構成される高品質なベンチマークです。各タスクはGitHubのIssueに対するパッチを一度だけ生成して評価する「一発修正」型の評価であり、修正の正確性と網羅性が問われます。現時点でのトップスコアはClaude Opus 4.5の80.9％で、主要モデルの多くが70％を超えるスコアを記録しています。

一方、SWE-CIは100タスクに対して最大20イテレーションの反復進化を評価します。一度の正確な修正ができるかではなく、修正を重ねる中でコード品質を維持できるかが問われるため、評価の焦点が根本的に異なっています。SWE-bench Verifiedで高スコアを記録するモデルがSWE-CIでも必ずしも高い性能を示すとは限らず、両者のスコアは異なる能力を測定しているといえるでしょう。この違いは、モデル選定の際に単一のベンチマークに依存する危険性を示しています。

SWE-bench Proの「汚染耐性」とSWE-CIの「保守性」が生む補完関係

SWE-bench Proは、Scale AI主導で開発されたベンチマークで、データ汚染への耐性を重視した設計が特徴です。GPLライセンスのリポジトリを使用することで訓練データへの混入を法的に抑止し、さらに非公開のプロプライエタリコードベースを含む評価セットも用意されています。この設計により、モデルが問題を「解いている」のか「記憶から再現している」のかを区別できます。

SWE-CIとSWE-bench Proは、異なる課題に対処しながらも補完的な関係にあります。SWE-bench Proはデータ汚染がない条件下での真の問題解決能力を測定し、SWE-CIは問題解決の結果が長期的に維持可能かどうかを検証する役割を担っています。両方のベンチマークで高スコアを記録するモデルは、汚染のない条件で正確に問題を解決でき、かつその解決策が将来の保守を妨げないという、実務で最も求められる能力を備えていると判断できるでしょう。実際に、SWE-bench Proのプライベートサブセットでは、Claude Opus 4.1が22.7％から17.8％に、GPT-5が23.1％から14.9％にスコアが低下しており、未知のコードベースに対する汎化能力の限界が示されています。SWE-CIの保守性評価と組み合わせることで、汎化能力と持続性の両面からモデルの実力を立体的に把握できます。

スナップショット型で70％超のモデルがSWE-CIでスコアを大幅に落とす理由

SWE-bench Verifiedで70％超のスコアを記録する主要モデルであっても、SWE-CIの進化ベース評価では大幅にスコアが低下する傾向が見られます。この現象は、一発修正の精度と長期保守能力が異なるスキルセットであることを如実に示しています。スナップショット型では、問題の特定と修正パッチの生成という2つの能力が試されますが、SWE-CIではそれに加えて影響範囲の予測、設計の一貫性維持、技術的負債の回避といった能力が必要になります。

具体的にスコアが低下するメカニズムとして、初期のイテレーションで局所的な修正を行ったことにより、後続のイテレーションでコードの整合性が崩れるパターンが典型的です。スナップショット型では1回の修正で完結するため、この種の累積的な品質劣化は評価対象になりません。SWE-CIはこの「隠れた弱点」を可視化するベンチマークであり、モデルの実務適用可能性をより正確に判断するための情報を提供します。

SWE-bench Liveの月次更新型とSWE-CIの長期進化型における設計思想の対比

SWE-bench Liveは、毎月50件の新規検証済みIssueを追加する月次更新型のベンチマークです。この設計は、データ汚染を時間軸の観点から防止することを主な目的としており、モデルの訓練データに含まれない最新のIssueを継続的に供給する仕組みです。現在は1565タスクインスタンスを含み、164リポジトリをカバーしています。

SWE-CIとSWE-bench Liveは、ともに「静的なベンチマークの限界」に対処していますが、アプローチは大きく異なります。SWE-bench Liveはタスク自体を更新することで汚染を防ぎ、SWE-CIはタスクの構造を反復進化型に変えることで保守性を評価します。SWE-bench Liveの月次更新はデータの鮮度を保証しますが、評価パラダイム自体はスナップショット型のままです。この対比は、ベンチマーク設計において「何を新しくするか」と「どう評価するか」が独立した設計軸であることを明確にしています。

複数ベンチマークの組み合わせでAIコーディング能力を多角評価する最適な使い分け

AIコーディングモデルの能力を正確に把握するためには、単一のベンチマークに依存するのではなく、複数の評価基盤を組み合わせた多角的な評価が不可欠です。SWE-bench Verifiedは一発修正の精度、SWE-bench Proはデータ汚染耐性下での汎化能力、SWE-bench Liveは最新タスクへの対応力、SWE-CIは長期保守性をそれぞれ測定します。

実務でのモデル選定では、プロジェクトの特性に応じてどのベンチマークの結果を重視するかを判断することが重要です。短期的なバグ修正の自動化にはSWE-bench Verifiedのスコアが参考になり、長期的なコード保守の自動化を検討する場合はSWE-CIの結果が不可欠な判断材料となります。

実務のCI/CDパイプラインにSWE-CIの知見を活かすための判断ポイント

SWE-CIの研究成果は、学術的な知見にとどまらず、実務でのAIエージェント導入判断に直結する示唆を多く含んでいます。ゼロ回帰率やEvoScoreといった指標は、モデル選定の基準として活用でき、二重エージェント構造はチームの開発体制設計にも応用可能です。ここでは、SWE-CIの知見を具体的な実務判断に落とし込む方法を整理します。

AIエージェント導入前にゼロ回帰率とEvoScoreで保守リスクを事前評価する手順

AIエージェントをCI/CDパイプラインに導入する前に、候補モデルのSWE-CIスコアを確認することで、保守リスクを事前に定量化できます。まずゼロ回帰率を確認し、0.5以上であればリグレッション発生リスクが相対的に低いモデルと判断できます。現時点でこの基準を満たすのはClaude Opusシリーズのみですが、今後のモデル改善により選択肢は広がる見込みです。

次にEvoScoreをγ＞1の設定で確認し、長期安定性に優れたモデルかどうかを判断します。γの値は自社のプロジェクト特性に合わせた調整が必要です。短期的な成果を重視するプロジェクトではγ＝1に近い設定で、長期運用を前提とするプロジェクトではγ＝2以上の設定で評価結果を比較します。この手順により、スナップショット型スコアだけでは把握できない保守リスクを導入前に洗い出すことが可能です。さらに、自社のリポジトリ構成に近い特性を持つSWE-CIタスクでのモデル性能を重点的に確認することで、より精度の高いリスク予測につなげられます。100タスクが68リポジトリにわたるため、自社と類似した規模や技術スタックのケースを参照できる可能性があります。

Architect・Programmer分離構造を自社のコードレビュー体制に適用する方法

SWE-CIの二重エージェント構造は、AIエージェントを活用した開発体制の設計にも応用できます。具体的には、AIエージェントにProgrammerの役割（要件に基づくコード修正）を任せ、人間のテックリードがArchitectの役割（テスト失敗の分析と要件定義）を担うというハイブリッド体制が考えられます。

この体制の利点は、AIエージェントの強みであるコード生成速度を活かしつつ、人間の判断力で要件の優先順位付けと影響範囲の予測を行える点にあります。SWE-CIの実験結果が示すように、Architectの要件定義品質がProgrammerの出力品質に大きく影響するため、要件定義フェーズに人間の専門知識を集中させることで、AIエージェント単体で発生しがちなリグレッションを予防できます。インクリメンタル設計の原則に従い、1回のイテレーションで扱う要件数を制限することも、品質維持に有効です。この体制では、人間のArchitectが作成する要件文書の品質がボトルネックになるため、要件記述のテンプレート化や過去のイテレーション結果のフィードバックループを組み込むことが実務上の成功要因となります。

リグレッション検知の自動化とAIエージェントの併用で品質低下を防ぐ運用設計

SWE-CIの知見を踏まえた実務的な運用設計として、AIエージェントによるコード変更とリグレッション検知の自動化を組み合わせたパイプラインが有効です。具体的な構成としては、AIエージェントがコード変更を生成し、自動テストスイートが変更前後のテスト通過状況を比較し、リグレッションが検出された場合は変更を自動的にリジェクトまたは人間のレビューに回すという流れです。

1. AIエージェントが要件文書に基づいてコード変更のプルリクエストを生成する
2. CI/CDパイプラインが既存のテストスイートを変更前後で実行し差分を検出する
3. リグレッションが検出されなければ自動マージ、検出された場合は人間のレビューキューに追加する
4. リグレッション発生パターンを蓄積し、AIエージェントへのフィードバックに活用する

この運用設計により、AIエージェントの生産性を活かしつつ、リグレッションによる品質低下を水際で防止できます。SWE-CIの実験が示した75％超のリグレッション発生率を考慮すると、この種のセーフティネットなしにAIエージェントの変更を自動マージすることは推奨されません。

γパラメータの調整で短期成果と長期保守のどちらを優先するか判断する基準

γパラメータの設定は、自社のプロジェクト特性とビジネス要件に応じて決定します。スタートアップのMVP開発やプロトタイピングフェーズでは、速度と初期成果が最優先となるため、γ＝1に近い設定でEvoScoreを評価し、短期的な修正精度が高いモデルを選定するのが合理的です。

一方、金融システムや医療システムなど、高い信頼性と長期的な安定性が求められるドメインでは、γ＝2以上の設定が適切です。この設定では、後半のイテレーションでのスコア維持能力が重視されるため、技術的負債の蓄積リスクが低いモデルが高く評価されます。中間的なケースとしては、一般的なWebアプリケーション開発でγ＝1.5程度に設定し、短期と長期のバランスを取る方法があります。自社で複数のγ設定でモデルを評価し、プロジェクトごとに最適な選択を行うアプローチが最も実践的です。なお、同一組織内でもプロジェクトごとに最適なγの値は異なりうるため、組織全体で単一の基準を適用するのではなく、プロジェクトの性質に応じた柔軟な運用が推奨されます。SWE-CIの評価フレームワークを自社の選定プロセスに組み込むことで、この判断を体系化できます。

SWE-CIの評価結果をモデル選定・ツール導入の稟議資料に反映する際の注意点

SWE-CIの評価結果を社内の意思決定プロセスで活用する際には、いくつかの注意点があります。まず、SWE-CIは2026年3月に公開されたばかりのベンチマークであり、対象がPythonリポジトリに限定されている点を明記する必要があります。他の言語やフレームワークでの保守性能は、SWE-CIの結果から直接推論することはできません。

• SWE-CIの評価対象はPythonリポジトリに限定されており、他言語への一般化には注意が必要である
• 実験ではArchitectとProgrammerに同一モデルを使用しているため、異なるモデルの組み合わせや人間との協働体制でのスコア変動は未検証である
• ゼロ回帰率やEvoScoreは単独ではなく、SWE-bench VerifiedやSWE-bench Proの結果と併記して多角的に提示するのが効果的である

稟議資料としてまとめる際には、これらの制約を明示した上で、ゼロ回帰率の数値を品質リスクの具体的な根拠として提示することが効果的です。特に、導入後の品質管理体制（人間によるコードレビュー、リグレッションテストの自動実行など）の必要性を裏付けるデータとして、SWE-CIの実測値は高い説得力を持ちます。