AIがコードを書いて納品する時代に、熟練の開発者が19%遅くなる理由

Devin、Claude Code、GitHub Copilot Workspaceといったソフトウェアエージェントは、タスクの説明を受け取り、コードベースを読み込み、それに対応するコードを書き、テストがパスするまで実行し、プルリクエストを開く——開発者が一行もコードを書くことなく、である。Cognition AIが開発したDevinは、分離されたクラウド環境内でこれを行う。そのプロダクションユーザーベース全体で、Devinが自律的に開くプルリクエストの67%がマージされている。Claude Codeはリポジトリ全体を読み込み、複数ファイルにまたがる変更を計画し、テストスイートを実行し、各ステップ間で指示なしに反復処理を行う。これらのツールは研究プレビューではなく、本番環境で使用されている。

これらを従来のコード生成ツールと区別するのは、フィードバックループである。提案エンジンはテキストを生成して停止する。自律型エージェントはコードを生成し、実行し、返ってきた結果を読み、再試行する。基盤となる構造はツール間で共通している。大規模言語モデルがコンテキスト（コードベース、課題の説明、エラーログ）を読み込み、計画を生成し、シェルコマンド、ファイル編集、git操作などのツールを通じて実行し、結果を読み、修正する。このループは、エージェントが成功するか、リソース予算を使い果たすまで続く。

エディターを置き換えたループ

利用可能なツールの自律性の範囲は、3つのレベルにわたる。支援型の端では、GitHub Copilotが開発者の入力に応じて次の数行を提案する。一段上のレベルでは、Cursorのような複数ファイルエディタが開発者の指示に従ってコードベース全体を書き換え、開発者が指定した変更を行う。自律型の端では、Devinおよび同等のシステムが長時間独立して動作し、何を読み、何を変更し、何をテストするかについて逐次的な決定を行い、システムだけでは処理できない承認のみを人間に委ねる。

これらのツールの進歩を測定する評価フレームワークは、PrincetonとStanfordの研究者によって作成されたSWE-benchである。これは、Django、Flask、scikit-learnといったオープンソースPythonリポジトリの実際のバグレポートを使用してエージェントをテストし、エージェントが正しく修正できる割合を測定する。厳選されたVerifiedサブセットにおける現在の最高公開スコアは96%で、Claude Opus 5が保持している。この数字は、実際のソフトウェアバグを診断し、修正を書き、プロジェクト自身のテストをパスすることを確認する能力という、真の能力を表している。

ベンチマークが隠すもの

96%のスコアには重要な注釈が付く。SWE-bench Verifiedは、厳選された500のタスクから抽出されている。研究者が汚染耐性のあるバリアント（いずれのモデルのトレーニングデータにも含まれ得ない問題を使用して設計されたSWE-bench Pro）を適用したところ、Verifiedで80%以上を記録していた以前のモデルがProでは50%を下回った。ベンチマークのパフォーマンスの一部は、評価セットへの熟知度を反映しており、一般化された問題解決能力ではない。このギャップは既知の研究課題であり、特定のツールへの批判ではない。

別の研究では、説明が難しい何かが見つかった。AI安全性研究機関であるMETRは、経験豊富なオープンソース開発者が自身のリポジトリで作業するランダム化比較試験を実施した。現在のAIコーディングツールを使用している開発者は、それらを使用していない開発者よりも19%遅かった——独立した推定では20%速いと判断していたにもかかわらずである。原因は具体的だった。エージェントが誤った結果を生成した際の再プロンプトにかかる時間、マージ前の出力検証にかかる時間、そしてエージェントへの指示とエージェントが行った作業の追跡の切り替えによる認知負荷である。ベンチマークは、エージェントが明確に定義されたバグを単独で修正できるかどうかをテストする。ランダム化試験は、開発者が実際の1日の作業でより速く作業できるかどうかをテストする。それらは異なるものを測定している。

93%の導入がわずか10%のスループット向上しかもたらさなかった理由

コード自律性は、境界が明確で明確に定義されたタスクで最もよく機能する。再現可能なバグ（明確な入力と出力を持つ）、正確な仕様を持つ関数、定義された動作を持つモジュールのテストスイートなどである。範囲が、暗黙のアーキテクチャ知識、文書化されていないチームの慣習、または製品方向性に関する判断を必要とするタスクに拡大すると、信頼性は低下する。モデルに能力が不足しているからではなく、それらの判断に必要なコンテキストがシステムに収まらず、コードベースファイルだけから導き出すことができないからである。

実際の変化は、作業に求められるものにある。自律型エージェントと共に作業する開発者は、エージェントが実行できるほど正確な仕様を書くことに多くの時間を費やす。詳細な課題の説明、明確なテスト契約、明示的な受け入れ基準などである。また、自分が書いていないコードのレビューにより多くの時間を費やす。これはコードを書くのとは異なる種類の注意を必要とする。ロジックエラー、セキュリティのギャップ、エージェントが自ら指摘しないアーキテクチャのずれを探すのである。2026年の12万1000人の開発者を対象とした調査では、93%がAIコーディングツールを定期的に使用しており、同じグループのプルリクエストスループットは約10%上昇した。ボトルネックはコードを書くことから、コードをレビューすることへと移行した。

現在活発に開発されている次の段階は、自身のタスクキューを管理するエージェントである。プロジェクト仕様を受け取り、サブタスクに分割し、専門モデル間で委任し、人間の判断を必要とする決定のみを表面化する。2026年には、マルチエージェントコードオーケストレーションのためのいくつかのオープンソースフレームワークが出荷された。本番環境でのエンタープライズ導入は依然として限定的である。Gartnerは、今年開始されたエージェンティックソフトウェアプロジェクトのかなりの割合が、管理されたデモが示すものと、信頼性の高いスケール展開に必要なものとの間の隔たりをチームが発見した後、2028年までに中止されると予測している。

タグ: 人工知能, プログラミング, AI coding agents, コード自律化, ソフトウェア開発