中山大学とアリババグループによる長期評価研究は、AIコーディングエージェントの多くが継続開発で回帰バグを生み、既存機能を壊してしまう現実を示しました。本記事では、研究で示された差分を整理し、実務で再現できる対策まで落とし込みます。
▼関連動画▼
▼執筆者のYouTubeチャンネル▼
AIコーディング実況 / 三森一輝（@mimo_claudecode）
研究で使われたSWE-CIベンチマークは、短期のバグ修正コンテストではありません。233日間、平均71コミットという長期の開発プロセスで、AIが継続的に品質を維持できるかを測定しています。
この条件下で示されたのが、約75%のモデルが長期的なコード整合性を維持できないという結果です。つまり、4回に3回のペースで既存機能を壊すリスクがある、ということです。
回帰とは、新機能Bを実装した際に既存機能Aが壊れる現象です。短期的には「新機能が動いた」ように見えても、保守フェーズで障害対応が連鎖し、開発速度そのものを失います。
この状態が続くと、修正のための修正が増え、仕様変更に弱いコードベースへ変質します。AIで速く書いたはずのコードが、最終的には負債として跳ね返ってくるのです。
動画で紹介された比較では、18モデルのうち、壊さない確率（ゼロリグレッション率）が50%を超えたのはClaude（Opus/Sonnet系）のみでした。
特にClaude Opus系は約55%の水準を示し、他モデルを明確に上回ります。GPT系、DeepSeek、GLM系の多くは、長期評価で回帰を避けきれない場面が目立ちました。
動画の分析では、性能差の本質は生成速度ではなく、初期設計と品質意識にあります。とにかく書き切るモデルは短期スコアが高くても、変更耐性の低い実装を残しがちです。
一方で、設計と整合性チェックを重視するモデルは、コミットを重ねても崩れにくい傾向があります。AI時代のモデル選定は、便利さではなく壊しにくさで決めるべき段階に入っています。
動画では、スタンフォード大学の研究にも触れ、AI支援下では安全でないコードを書きやすく、しかも開発者自身がそれを安全だと誤認しやすい点が指摘されました。
これは技術課題であると同時に、運用課題です。出力の検証責任を人間が手放した瞬間、AIの誤りはプロジェクトの誤りになります。
1体のAIに要件整理、設計、実装、テストまで担わせると、自己レビューが甘くなります。人間開発でも「自分のミスは見えにくい」のと同じです。
その結果、見た目は速く進んでも、リリース直前や運用段階で不具合が噴出します。回帰の本質は、モデル性能だけでなく、検証構造の欠如にあります。
現時点では、長期整合性の実績を持つモデルを選ぶことが第一条件です。動画内の結論は明確で、AI駆動開発の成功は「どのモデルを土台にするか」で大きく分かれます。
導入時は、既存リポジトリで小さな連続改修を回し、回帰発生率を計測して選定するのが現実的です。デモの印象より、連続コミットの実測値を優先してください。
運用フローは、次の順序を固定します。
変更前にテストケースを定義する
AIに実装させる
回帰テストを自動実行する
失敗時は修正と再実行を完了するまでマージしない
重要なのは、AIの出力品質に期待することではなく、壊れたら通さないゲートを先に作ることです。
動画で推奨されるのが、アーキテクト、コーダー、テスターの役割分担です。単一AIではなく複数AIを協調させることで、見落としを構造的に減らせます。
人間チームと同様に、設計者は原則コードを書かず、実装者は設計根拠を参照し、テスターは独立した観点で検証します。この分業だけでも回帰の発生確率は大きく下げられます。
AIコーディングは強力ですが、100%安全なモデルは存在しません。だからこそ、壊れにくいモデルを選び、テスト駆動を徹底し、役割分担で相互監査する体制が必要です。
これからの開発現場で重要なのは、AIに書かせる技術だけではありません。AIが壊しても被害を最小化できる設計こそ、長期で成果を出すための必須条件です。
AI駆動開発の導入設計や、マルチエージェント体制の構築を進めたい方は、AI駆動研究所の研修サービスをご活用ください。現場の開発フローに合わせて、段階的な実装支援が可能です。
AIは、文章を書くだけの道具ではなくなりつつあります。プログラムを書いたり、いくつかの作業を自分で続けたりする「エージェント」型の使い方が増えています。 その流れのなかで、Anthropicの最新モデルとされる「Claude Mythos（クロード・マイソス）」が大きな注目を集めています。私の理解では、性能があまりに高く、いまは誰でもが使える形での一般公開には至っていない、というのが大きな論点です。
