初評価で判明:AI によるコード修正は「悪化させる」可能性が大多数、プログラマーは職を失う心配は無用か?

画像

近年、AI 大規模言語モデル(以下、LLM)のプログラミング能力は飛躍的に向上しており、主要な AI 企業各社はプログラミングベンチマークにおいて熾烈な競争を繰り広げ、記録を次々と更新しています。これにより、多くのプログラマーの間で「AI は間もなく自分たちの仕事を奪うのではないか」との懸念が広がっていました。

しかし、中山大学と阿里巴巴(アリババ)グループが共同で発表した最新の研究結果により、プログラマーたちはひとまず安心材料を得ることになりました。

3 月 4 日、両機関は共同で評価結果を発表しました。このテストは「SWE-CI:継続的インテグレーションを通じたエージェントのコードベース維持能力の評価(SWE-CI: Evaluating Agent Capabilities in Maintaining Codebases via Continuous Integration)」と名付けられ、Anthropic、OpenAI、Kimi、DeepSeek など主要 8 社が提供する 18 種類の AI 大規模モデルを対象に、長期的なコード維持能力に対する厳格かつ体系的な評価テストを初めて実施したものです。

テストは 100 項目のタスクで構成され、消費されたトークン数は合計 100 億を超えました。その結果、Claude Opus シリーズが総合的にトップの成績を収めました。

パフォーマンス劣化の抑制という点では、千問(Qwen)、DeepSeek、MiniMax、Kimi、豆包(Doubao)など、大多数の AI 大規模モデルの出来は明らかに芳しくありませんでした。つまり、AI は長期的なコード維持の過程で、コードを「修正すればするほど悪くする」可能性があるのです。

画像

中国チームが世界初、AI 大規模モデルの
長期的コード維持能力を評価するシステムを開発

従来、AI のプログラミング能力を測る主流のベンチマークに共通していたのは、スナップショット型の評価方式でした。これは「要求を一度受け取り、解決策を一度きりで出力する」ことを中核とするものです。

しかし、この評価方式では大規模モデルが機能的に正しいコードを書けるかどうかしか検証できず、実際のソフトウェア開発において中核となる「継続的なイテレーション」や「長期的なメンテナンス」という需要を反映することはできません。

現実には、成熟したソフトウェアが一朝一夕で完成することは稀で、長期的なメンテナンスの積み重ねによる結果です。レマンの法則が示すように、ソフトウェアの品質はメンテナンスが進むにつれて自然と低下する傾向にあります。そして、メンテナンス作業はソフトウェアライフサイクルのコスト全体の 60% から 80% を占めています。

AI の長期的なコード維持におけるパフォーマンスを評価するため、中山大学と阿里巴巴のチームは共同で「SWE-CI」ベンチマークを策定しました。これは AI エージェントの長期的コード維持パフォーマンスを専門的に評価する世界初のシステムであり、AI プログラミングの「一度きりの正解」を問うことに留まらず、AI が本物のソフトウェアエンジニアのように、数ヶ月から数年に及ぶ開発プロセスを通じて、一貫してコード品質を維持できるかどうかを評価するものです。

SWE-CI ベンチマークの構築には 4 段階の厳格な選考プロセスが経られ、最終的に高品質な評価セットが完成しました。

研究チームはまず、GitHub 上の全 Python コードリポジトリから、3 年以上メンテナンスされ、スター数が 500 を超え、依存関係ファイルと完全なユニットテストスイートを含み、かつ MIT や Apache-2.0 などの寛容なライセンスを採用している 4,923 のコードリポジトリを選別。次に、依存関係が安定しており、コード変更量が 1,000 行を超えるコミットペアを抽出して 8,311 の候補サンプルを取得。さらに、Docker 環境の自動構築と自己修復メカニズムにより依存関係を修復し、実行可能な 1,458 組の候補ペアに絞り込みました。最後に、テスト起動の検証、パス率の差異による選別、時間跨度とコミット数のソートを経て、最終的に 100 項目のタスクを確定させました。

研究チームが丹念に構築した 100 項目のタスクは、それぞれが現実世界のソフトウェアプロジェクトの完全な進化の過程に対応しています。これらのプロジェクトは平均して 233 日間の開発期間を跨ぎ、71 回の連続したコードコミット記録を含んでいます。またチームは、巧みに「アーキテクト - プログラマー」という 2 つのエージェントによる協業メカニズムを設計しました。このデザインの着想源は、実際のソフトウェアチームで一般的な分業モードです。アーキテクトが需要分析と技術ソリューションの策定を担当し、プログラマーが具体的なコード開発を担当します。

長期的なイテレーション評価に適応するため、SWE-CI は「正規化された変化」と「EvoScore(進化スコア)」という 2 つの中核指標を提案しました。

「正規化された変化」はテストケースのパス数を基礎とし、コードの状態を [-1, 1] の区間にマッピングします。正の値は機能の向上を、負の値は機能の劣化を示します。

一方、EvoScore は、将来の修正タスクにおける AI 大規模モデルのパフォーマンス測定をより重視するものです。

画像

実測結果:Claude Opus が他を圧倒してトップ
大規模モデルの 75% は既存コードを破壊

研究チームは、月之暗面(Moonshot AI)、Anthropic、智譜 AI(Zhipu AI)、千問(Qwen)、MiniMax、DeepSeek、OpenAI、豆包(Doubao)という 8 社が提供する 18 の主要 AI 大規模モデルに対して体系的なテストを実施し、累計で 100 億トークン以上のテストデータを消費しました。この実験規模は、AI プログラミング評価の分野において前例のないものです。

研究結果によると、時間の経過という観点から見ると、AI 大規模モデルのコード維持能力の進化は明確な加速曲線を描いています。

下の図から、同一ベンダーの大規模モデルの新版は概して旧版より安定して高く、2026 年以降はその飛躍幅が著しく拡大し、EvoScore も高まっていることがわかります。これは、現在の大規模モデルのコード能力が、静的な欠陥修正から、継続的かつ長期的なコード維持へと急速に進化していることを示唆しています。

https://smcos.cdmgiml.com/tx/others/upload/ai_tool/doc_to_html/200/2254/2026-03/2026-03-17/0aae2a6a65c8840f39f3fab08c7d5aea.png

8 社ベンダーの主要大規模モデルにおける SWE-CI テストの EvoScore の推移。出典:論文スクリーンショット

評価対象となった全ての大規模モデルの中で、Claude Opus シリーズが最も突出したパフォーマンスを見せました。Claude-opus-4.5 から Claude-opus-4.6 へと進化し、その EvoScore は約 0.9 という高水準まで急上昇。他全ての競合他社との間に明確な差をつけました。

中国の AI 大規模モデルでは、智譜の GLM シリーズの進歩が顕著で、第 2 グループの中で最も競争力のあるプレイヤーとなりました。その後を Qwen と MiniMax が続き、全体的なトレンドは上向きです。一方、Kimi と豆包は向上が見られるものの、決定的なブレークスルーには至っていません。

また研究により、各ベンダー間で大規模モデルのトレーニング戦略の選好に明確な分化が見られることも判明しました。

具体的には、MiniMax、DeepSeek、OpenAI の GPT シリーズ各モデルは長期的な利益をより好む傾向にあり、長期的なコード維持タスクにおける優位性を示しています。これは、これらの大規模モデルがコード生成を行う際、短期的な修正の最適解を追求するのではなく、長期的な進化と安定性に有利な戦略を採用する傾向があることを意味します。

対照的に、Kimi と智譜 GLM シリーズは、短期的に効果が出る最適化パスをより好む傾向にありました。

一方、千問(Qwen)、豆包(Doubao)、そして Claude シリーズ各モデルは、短期的効果と長期的維持との間で一定のバランスを取るという別の特徴を示しました。

https://smcos.cdmgiml.com/tx/others/upload/ai_tool/doc_to_html/200/2254/2026-03/2026-03-17/f7e132f52a01eaa73e7a05637c50fb33.png

重みパラメータγの変化に伴い、各モデルのランキングも著しく変動しました。γ>1 の場合、大規模モデルのランキングが高いほど、コードベースの維持能力が高いことを示します。出典:論文スクリーンショット

さらに、研究にはもう一つの重要な発見がありました。長期的なコード維持において、全ての大規模モデルがパフォーマンス劣化(リグレッション)を効果的に抑制するという点で不十分だったのです。

パフォーマンス劣化は、ソフトウェア品質の安定性を測る中核指標です。あるユニットテストがコード更新前にはパスしていたのに、更新後に失敗した場合、その変更がパフォーマンス劣化をトリガーしたと判定されます。一度パフォーマンス劣化が起きると、ユーザー体験に直接的な悪影響を及ぼすだけでなく、長期的な維持プロセスにおいて修正回数が蓄積するにつれ、システム品質の体系的な劣化を招く恐れがあります。

研究チームは「ゼロ劣化率(Zero Regression Rate)」を測定しました。これは、維持プロセス全体を通じて、既存の機能を一切破壊しなかったタスクの割合を指します。ゼロ劣化率が高いほど、維持されるシステムは安定しています。

研究結果によれば、テストに参加した 18 の大規模モデル全ての中で、Anthropic 社の Claude Opus モデルのみが 50% 超のゼロ劣化率を維持し、他の大多数のモデルのゼロ劣化率は 25% を下回っていました。

https://smcos.cdmgiml.com/tx/others/upload/ai_tool/doc_to_html/200/2254/2026-03/2026-03-17/d76d7af19df0009887985206a95ce77f.png

18 の大規模モデルのゼロ劣化率(低い順から高い順にソート)。出典:論文スクリーンショット

具体的には、Claude-opus-4.6 が 76% のゼロ劣化率で圧倒的なトップに立ちました。これは、テストシナリオの大多数において、そのパフォーマンスが安定していたことを意味します。2 位は 51% の Claude-opus-4.5 でした。対照的に、Kimi-K2.5(37%)と GLM-5(36%)は互角の成績で第 2 グループを形成しましたが、一定の安定性は持っているものの、トップモデルとは依然として大きな隔たりがあります。

GPT-5.2、Qwen3.5-plus、MiniMax-M2.5、DeepSeek-V3.2 を含む残りの 14 の AI 大規模モデルは、ゼロ劣化率が 25% 未満でした。これはつまり、長期的なコード維持プロセスにおいて、これらの大規模モデルは 75% を超えるタスクで、本来正常に動作していたコード機能を破壊し、パフォーマンス劣化の問題を引き起こす可能性があることを意味します。

ただし、バージョンのイテレーションという観点から見れば、トップベンダーの AI 大規模モデルは急速に進歩しています。例えば、Claude-opus シリーズの「ゼロ劣化率」は 4.5 バージョンの 51% から 4.6 バージョンでは 76% へ向上。智譜 GLM シリーズも GLM-4.6 および GLM-4.7 の 14% から GLM-5 では 36% へと飛躍しました。

しかし、それでもなお、大多数の大規模モデルは長期的なコード維持においてパフォーマンス劣化の問題を根絶することができず、信頼できる自動的な長期開発の実現までは、依然として明確な隔たりがあります。

SWE-CI ベンチマークテスト結果の発表により、業界は「コードを書くこと」と「コードを維持すること」が全く異なる能力であることを再認識させられました。大規模モデルベンダー各社にとって、維持可能性、パフォーマンス劣化の制御、アーキテクチャ設計能力を継続的に最適化することが、次なる競争を制する鍵となるでしょう。

(免責事項:本記事の内容およびデータは参考情報であり、投資助言を構成するものではありません。利用の際は事実確認をお願いします。本情報に基づく運用は自己責任で行ってください。)

記者 | 蘭素英、常宋資燊(インターン)

編集 | 何小桃、王嘉琦、杜恒峰

校正 | 段錬

表紙画像提供:毎経メディア資産ライブラリ

|毎経新聞(NBD) nbdnews  独占記事|
無断転載・抜粋・複製・ミラーリング等を禁じます
転載をご希望の場合は、当公式アカウントのバックステージより申請し、許可を得てください

画像


分享網址
AINews·AI 新聞聚合平台
© 2026 AINews. All rights reserved.