テンセントの「CEO/総裁オフィス」首席AI科学者の姚順雨氏は、「The Second Half」という題のブログで、実際のプログラミング作業は連続して依存しており、独立並行ではないと述べています。しかし現状、学界にはこの状況でAIに必要とされる能力を評価するようなベンチマークがなく、さらにタスク間の相互独立という仮定を打ち破る勇気すら欠けているのです——長年にわたり広く受け入れられ、問題を単純化するために使われてきました。
結果は次の通りです。最上位のAIは独立評価タスクでは優秀な成績を示します（スコア 80%+）。しかし長期の実環境に入ると、総合スコア最高の Claude Opus 4.6 でも 38.03% の得点にとどまりました。これは、自由度の高いタスクの実行ではAIが軌道から逸れやすく、長期にわたる連続的なソフトウェア進化作業を本当に処理できる距離には、依然として大きなギャップがあることを意味します。
研究チームは Claude Code、OpenHands などの複数のフレームワークとモデルの組み合わせをテストしました。結果は次の通りです。独立評価ではスコアが概ね 80%-90% のトップモデルが、EvoClaw ベンチマークのテストを行うと集団で急落しました。最高得点の Claude Opus 4.6 でさえ 38.03% しか得点できません。
研究は否定的な答えを示しました。開発ウィンドウの長さにかかわらず、すべてのモデルの性能は最終的に「天井（トップ）」にぶつかります。タスクの実行順が後ろになるほど、また DAG 上でより深い層にあるほど、スコアと解決率は低下します。飽和関数の外挿結果は、最適な Opus 4.6 でさえ、累積スコアは 45% 前後の漸近線に頭打ちされることを示しています。
断崖式下跌！最強AIでも長期開発は手に負えない：コードが増えれば増えるほどシステムは崩壊しやすくなる
（出所：DeepTech深科技）
関数を書け——AIはほぼ無敵；しかしシステムを維持するのはなぜ崩れ始めるのか？
現在、人工知能は「後半戦」に入っています。AIのプログラミング能力が不断に向上するにつれて、OpenClaw などの製品が徐々に台頭し、「CLI everything」が現実になりつつあります。つまりAIはコンピュータを操作する必要がなく、すべてのインターフェースをコマンドライン・インターフェース（CLI）に置き換え、1つ1つのスキルがソフトウェア機能の集合へと変わっていくのです。
しかし、Agent はもはや単発タスクを実行するための会話ツールにとどまらず、長期運用のための、現実世界と相互作用し複雑なタスクを実行するシステムへと進化しています。とはいえ、新たな問題も出てきました。継続的な進化の過程で、AIは新しい環境に適応しつつ、開発能力を安定して維持できるのでしょうか？
テンセントの「CEO/総裁オフィス」首席AI科学者の姚順雨氏は、「The Second Half」という題のブログで、実際のプログラミング作業は連続して依存しており、独立並行ではないと述べています。しかし現状、学界にはこの状況でAIに必要とされる能力を評価するようなベンチマークがなく、さらにタスク間の相互独立という仮定を打ち破る勇気すら欠けているのです——長年にわたり広く受け入れられ、問題を単純化するために使われてきました。
最近、米国南カリフォルニア大学、カリフォルニア大学リバーサイド校、スタンフォード大学、プリンストン大学、OpenHands などの合同チームが、新しい評価ベンチマーク EvoClaw を発表し、上記の問題に対して新しい解決策を提示しました。研究チームはオープンソースプロジェクトから高品質なコード進化の履歴を抽出し、Agent が同一コードベース上で、数十の相互に依存する機能の反復を連続して完遂できるようにしたのです。
結果は次の通りです。最上位のAIは独立評価タスクでは優秀な成績を示します（スコア 80%+）。しかし長期の実環境に入ると、総合スコア最高の Claude Opus 4.6 でも 38.03% の得点にとどまりました。これは、自由度の高いタスクの実行ではAIが軌道から逸れやすく、長期にわたる連続的なソフトウェア進化作業を本当に処理できる距離には、依然として大きなギャップがあることを意味します。
（出所：arXiv）
この研究は、AIが長期進化の過程で、雪だるま式に技術的負債へ陥りやすいことを明らかにしています。新機能を継続的に追加することはできても、誤りの累積への回帰を制御できず、最終的にシステムが制御不能に陥ります。これはまた、AIのプログラミングが「コードを書く」ことから「システムのガバナンス」へと転換していることも意味します。
関連論文は『EvoClaw：継続的ソフトウェア進化におけるAIエージェントの評価』（EvoClaw: Evaluating AI Agents on Continuous Software Evolution）という題で、最近プレプリントサイト arXiv[1] に掲載されました。
図｜関連論文（出所：arXiv）
既存のAIプログラミング評価と実際の体験がずれているのは、どこに問題があるのか？
なぜ独立した測定で高得点を取る最上位モデルが、EvoClaw の評価では集団で失敗したのでしょうか。根本原因は、評価のパラダイムが変わったことにあります。
これまでの研究では、主流のプログラミング評価ベンチマーク（benchmark）の多くが独立タスクに焦点を当てていました。つまり、ある論点（issue）やプルリクエスト（PR、Pull Request）を与えた上で、モデルは静的なコードのスナップショット上で修正を行い、検証が通ればそこで評価が完了するのです。
しかし、従来のベンチマークの結果と、現実の開発能力の間には、見過ごせない隔たりがあります。静的環境は相対的に理想的な状態であり、現実の環境はそれよりも複雑で動的です。時間が経つにつれ、数か月前の些細なバグでも、バージョン反復の中で雪だるま式にますます大きくなり、最終的にシステムが崩壊する可能性があります。
（出所：arXiv）
この論文の筆頭著者であり、南カリフォルニア大学の博士学生である鄧港大氏は DeepTech に対して次のように述べています。「既存の commit や release の粒度は、どちらかといえば細かすぎる、または粗すぎる。だから、これらの開発履歴はソフトウェア進化のプロセスを反映していません。」
図｜鄧港大（出所：取材対象者）
研究チームは初めて、AIのプログラミング能力の評価体系に時間の次元を導入し、まったく新しい階層——マイルストーン（Milestone）——を採用してソフトウェア進化の履歴を再構築しました。これは、意味の一貫性と進化上の依存関係を保持できる機能単位を兼ね備えることができます。要求されるのは、AIが同一コードベース上で複数の機能単位を順序立てて完遂することです。これにより、各段階の成果を保持するだけでなく、次の段階の起点にもなるのです。
（出所：arXiv）
大量のオープンソースコードベースから高品質なソフトウェア進化履歴を抽出することを支えるため、研究者はトップクラスのAIの強力な能力を基に、Agent 駆動の自動化パイプライン DeepCommit を提案しました。これにより初めて、ノイズの多い Git の開発記録を、検証可能で機能的にまとまったマイルストーンタスク依存グラフ（Milestone DAG）へと再構築し、さらに各マイルストーンに対して評価環境を構築することが実現されました。主な内容は3つの段階です。Git 履歴の前処理、Agent 駆動の DAG 構築、そしてマイルストーン環境の設定と検証です。
実際、Milestone によって Agent の履歴進化を再構築するのは簡単ではありません。それは、静的で純粋に観測可能な DAG を作るだけではなく、一連の「実行できる」評価環境を作る必要があり、さらに進化依存の変更が起きる中でも正確性を保証しなければならないからです。
つまり、commit の全体の順序を崩し、それを再クラスタリングして接続すると、commit が適用できない、インターフェースが噛み合わない、コンパイルで広範囲にエラーが出るといった問題に直面する可能性があります。この問題に対処するため、研究者は反復型の修復ループを設計しました。Agent がエラーのログを能動的に分析し、Dockerfile を動的に修正して実行可能にします。
さらに重要なのは、既存の DAG に基づいて、見落とされた暗黙の依存関係を補完することです。Milestone の先後の制約関係を調整することで、インターフェースの衝突問題を適切に解決できるようにします。何度も反復した結果、最終的に元のテスト用ケースの 87.1% を正しく収集することに成功しました。
「単一のプログラミングタスクのシナリオと比べて、安定して信頼でき、効果的な長期の自律プログラミングは、より最先端の研究ホットスポットです。たとえば Anthropic や OpenAI は、重点を長期のプログラミング能力の学習へ移したことを明確に示しています。」と鄧港大氏は述べています。
図｜DeepCommit パイプラインのアーキテクチャ図（出所：arXiv）
研究者は DeepCommit が自動生成した進化グラフと、人間の専門家による手動の注釈を比較しました。そこで意外だったのは、両者が異なる組織ロジックを採用しており、それがお互いを補完し合っていたことです。
具体的には、人間の専門家の Milestone は通常、局所的な時間窓の中で、まず論点を定めてからコミットをまとめ直します。これは上から下への意味分割の一種です。一方、DeepCommit は絶対的な正確性を保証するために、コミット間の依存関係から出発して、自下而上でソフトウェア進化の筋道を再構築します。こちらはトポロジ構造と実行上の制約をより重視します。
評価の観点では、これは DeepCommit の核心がコード開発履歴から、実行可能で検証可能なマイルストーン構造を抽出するところにあることを示しています。結果を見ると、DeepCommit は高品質で評価に適した Milestone タスクを選別でき、さらに実環境で実行可能で検証可能であるため、評価の信頼性に保証を与えています。
実開発に入ると、なぜモデルの成績が集団で「半減」するのか？
EvoClaw は Python、Java、Go、Rust、TypeScript の5つの主要言語をカバーし、選ばれたプロジェクトは最長の実開発期間が 750 日に及びます。
評価指標の面で、研究チームは単純な合格率は採用せず、より核となる2つの次元——リコール（Recall）と精度（Precision）のF1加重——を導入し、各 Milestone のスコアとしています。リコールは機能実装の完備性を測り、精度は新機能を追加するときに既存コードをどれだけ壊してしまうかを捉えます。
研究チームは Claude Code、OpenHands などの複数のフレームワークとモデルの組み合わせをテストしました。結果は次の通りです。独立評価ではスコアが概ね 80%-90% のトップモデルが、EvoClaw ベンチマークのテストを行うと集団で急落しました。最高得点の Claude Opus 4.6 でさえ 38.03% しか得点できません。
図｜EvoClaw の主要実験結果（出所：arXiv）
GPT 5.3 Codex は総合得点 28.88% で Opus4.6 に次ぎ2位です。リポジトリ別に見ると、GPT 5.3 Codex は2つの Rust プロジェクト（Nushell、ripgrep）で弱く、それ以外のリポジトリでは Opus4.6 に近づくか、さらには超えることもあります。完全解決率では、得点最高の Gemini 3 Pro でも 13.37% であり、さらに大部分が正しく実装できたのは前置依存がないタスクでした。
研究によれば、全体のコストは妥当な範囲に抑えています。たとえば Claude Opus 4.5 を例にすると、完全な評価を1回行うコストは約 500 ドルです。Kimi K2.5 と Gemini 3 Flash は 50 ドル以内で、小型モデルのコストはさらに低くなります。
（出所：arXiv）
では、もしモデルにもっと長い開発ウィンドウを与えれば、最終的にプロジェクトを 100% 片付けられるのでしょうか？
研究は否定的な答えを示しました。開発ウィンドウの長さにかかわらず、すべてのモデルの性能は最終的に「天井（トップ）」にぶつかります。タスクの実行順が後ろになるほど、また DAG 上でより深い層にあるほど、スコアと解決率は低下します。飽和関数の外挿結果は、最適な Opus 4.6 でさえ、累積スコアは 45% 前後の漸近線に頭打ちされることを示しています。
「Opus 4.6 は Anthropic 公式サイトで、4.5 より長周期タスクでの表現が良いと述べていますが、詳細な評価指標は提示されていません。EvoClaw は別の角度から、その主張を検証したものです。」と鄧港大氏は述べています。
また、実験からはモデルのファミリー間に明確な違いも見られました。具体的には、Claude と GPT の持続的進化シナリオでの性能は、バージョン更新に伴って着実に向上しています。その中でも Opus 4.6 は長周期のプログラミングで、システム維持性能が最も優れていることを証明しました。GPT 5.3 は Rust のデータセットでの性能が良くなかったためスコアを引き下げ、2位に位置しています。
（出所：arXiv）
比較して意外だったのは、Gemini ファミリーがまったく異なる傾向を示したことです。3 Flash から 3 Pro、そして 3.1 Pro へと世代を重ねるごとに、初期の立ち上がりが速く前半の性能が良くなりますが、その一方で長距離の性能はほとんど顕著な向上がありません。鄧港大氏は次のように説明しています。「Gemini の長周期実行での明確な低下は、それが指示遵守の悪化だけでなく、ますますソフトウェア仕様（SRS）の要求を無視するようになっていることを示しているだけでなく、構築したソフトウェアシステムのメンテナンスにも欠けていることを意味します。」
研究者が全体スコアをさらにリコールと精度に分解すると、もう一つより面白い現象が現れました。リコールはほぼ一貫して上昇し、線形に近い増加を示すのです。これは、たとえコードベースがますます混乱し、ますます脆くなっても、Agent は与えられた新しい目標機能を実装することに関しては依然として得意であることを意味します。
本当のボトルネックは精度（Precision）です。Agent は既存システムの維持が難しく、回帰エラーの蓄積が、それらの問題を修正する能力の速度を上回ってしまい、そしてそれこそが長期開発が最終的に停滞する根本原因なのです。
図｜左：エラーチェーンの模式図；右：エラーチェーンの分布（出所：arXiv）
AI Harness のデバッグに向けた汎用評価
最近、「Harness Engineering」という非常にホットな概念があり、ソフトウェア開発の全プロセスを Agent が参加しやすい環境として構成したいと考えています。EvoClaw ベンチマークのテストは、長期のコード進化を評価するための汎用的でデバッグに適した playground を提供し、AI Harness フレームワークの調整に役立ちます。
たとえば今回の研究で言及された失敗事例で、Agent が突然非常に積極的に反復を行ったり、編集と検証を繰り返し続けたりする場合、それは Agent が困難に遭遇している可能性が高いです。このとき、該当箇所にガードレール（護栏）を構築することで、問題をより早く発見し、適時に人手を介入させることができ、それによって効率を高められます。
では、モデルのアーキテクチャが Agent に対して「新機能の実装が、長期の旧機能のメンテナンスよりも強い」という汎用的な性質を与えている以上、将来、新しいソフトウェアの形態や開発モードが生まれるのでしょうか？
たとえば、ソフトウェアは柔軟性や互換性をより重視し、より信頼性の高い大規模な改変の再編成を行うようになるかもしれません。あるいは、より一回限りのものになり、具体的なビジネスロジックはリアルタイムに生成され、保守の必要はなく、再利用可能なコンポーネントや基盤（インフラ）を強化することに重点が置かれる可能性もあります。
研究チームは、開発モードにおいてソフトウェア品質への要求を適度に緩めれば、人間の介入回数を減らして、引き換えにより大きなスループットを得られ、最終的にソフトウェアの反復を加速できると考えています。
鄧港大氏は、「この研究は、私たちは正しい道を歩んでおり、AI の長期プログラミング能力はまだボトルネックに突き当たっておらず、時間とともに安定して向上していくことを示しています。可能性として、ある突然の一日には、ランキングの点数の“量の変化”が、世界を変える“質の変化”につながるかもしれません。」と指摘しました。
技術の発展に伴い、将来的には AI が人間のソフトウェア開発への関与を次第に減らすところから進んで、AI が自主的に新しい要求を提示してコードベースを進化させるようになり、最終的に AI が人間を完全に超え、人間を捨てることで、自己進化を絶え間なく続けるようになる可能性があります。
参考文献：
関連論文：
プロジェクトのホームページ：
レイアウト：劉雅坤
大量の情報、精密な解釈は、新浪财经APPの中にあります