熟練開発者はAIで速くなったと感じたが、実測では遅くなった――本当の発見と、AIコーディングへの最終判決ではない理由

熟練開発者はAIで速くなったと感じたが、実測では遅くなった――本当の発見と、AIコーディングへの最終判決ではない理由

経験豊富なプログラマーに「AIコーディング支援でどれくらい速くなる？」と聞けば、たいてい数字が返ってくる。20%、30%は時間を節約できる、と。経済学者や機械学習研究者に聞けば、数字はさらに大きくなる。2025年初頭、METRのチームは、時間もお金もかかる地味な方法で実際に確かめた。熟練したオープンソース開発者16人に、彼らがよく知る大規模コードベースから246件の実務タスクを渡し、タスクごとにコイントスのように無作為で、AIツールを使える条件と使えない条件へ割り当てた。そして作業時間を測った。

開発者たちは、AIなら作業時間を約24%減らせると予測していた。結果は逆だった。AIを使ったタスクは19%長くかかった。そして、ここがじっくり考える価値のある部分だ。作業を終えた後も、同じ開発者たちはAIによって約20%速くなったと信じていた。実際には遅くなり、本人は速くなったと感じた。この二つの数字の距離こそ、研究で最も興味深い発見である。

これは本物で、丁寧に測られた結果だ。同時に、対象は16人で、自分たちが非常によく知るリポジトリを使い、2025年初頭のツールで作業した結果でもある。「AIは開発者を遅くする」という平らな一文ではない。同じチームの後続データは、すでに反対方向を指し始めている。

著者らが行ったこと

• ランダム化比較試験を行った（METR: Joel Becker、Nate Rush、Beth Barnes、David Rein）。熟練オープンソース開発者16人が、それぞれ日常的に貢献し、よく知る大規模リポジトリで作業した。特定プロジェクトへの経験は平均5年だった。
• 246件の実務タスク――各プロジェクトの実際のissue trackerから取ったバグ修正、機能追加、リファクタリング――を使った。各タスクは無作為に「AI可」または「AI不可」へ割り当てられた。
• 「AI可」で使えたのは2025年初頭のツール、Cursor Pro + Claude 3.5/3.7 Sonnet。主要指標は各タスクの実際の完了時間だった。加えて、開発者の事前予測と事後推定、経済学・機械学習専門家の予測も集めた。

分かったこと

• AIを使うとタスクは19%長くかかった。 速くではなく、遅くなった。95%信頼区間はおよそ+2%～+39%で、正確な大きさには幅があるが、方向はかなり堅い。
• 全員が逆を予測していた。 開発者は24%の高速化、機械学習専門家は約38%、経済学者は約39%を予測した。三群とも大きな時間節約を期待したが、ストップウォッチは時間増加を示した。
• 認知ギャップ。 実際には遅くなった後でも、開発者はAIによって約20%速くなったと推定した。本人の感覚と時計の記録の間に、およそ40ポイントの差があった。
• 理由の候補は比較したが、証明はしていない。 著者らはいくつかの要因を挙げる。開発者が自分のコードベースを深く知っているため支援が追加できる余地が小さいこと、成熟プロジェクトには明文化されていないことも多い高い品質基準があること、リポジトリが大きくモデルの知らない文脈が多いこと、プロンプト作成に加えAI出力のレビューや修正にも実時間がかかること。これらは手掛かりであって、確定原因ではない。

この研究からは言えないこと

• AIが大多数の開発者を速くできないとは示していない。著者ら自身が明記している。コードを知り尽くした16人の専門家は、平均的な開発者が平均的なタスクをする状況ではない。
• AIが役に立たない、あるいは他の状況でも遅くするとは示していない。コードベースに新しく入った人、ゼロから作る仕事、知らない言語、まったく別分野では結果が違い得る。
• ツールが固定されたままとも仮定できない。使ったのは2025年初頭のCursorとClaude 3.5/3.7 Sonnet。より良いツール、あるいは同じツールをより上手く使う方法でも、このまったく同じ状況の結果さえ変わり得ると著者らは明記する。
• これはプレプリント（2025年7月公開、未査読）であり、著者らは実験アーティファクトを完全には排除できないとする。ただし、複数の解析で減速結果は維持された。
• 「時間以外で何かを得たのでは」と安心する読み方――学習が増えた、気分が良かった、コード品質が上がった――を裏付ける研究でもない。ここで本人が測ったと感じていた「高速化」こそ、実測データが否定した対象だ。

証拠をどう評価するか

• 設計は異例に誠実だ。 無作為化、実際のタスク、実際のリポジトリ、実時間の計測。AIコーディングについての主張が通常頼る自己申告やベンチマークリーダーボードから、大きく一歩進んでいる。19%の減速は著者らの頑健性チェックでも残った。
• 最も持ち運べる結果は認知ギャップ。 AIによる自分の高速化についての専門家の直感が、およそ40ポイント、楽観方向へ外れた。これはAIによるあらゆる自己申告の生産性向上を読む際の注意になる――この研究自身の自己申告も含めて。
• これは一時点のスナップショットで、傾向そのものではない。 METRが2026年2月に行った、同種の開発者と新しいツールを使う追跡では、高速化の方向を示している。ごく大ざっぱに、再参加開発者で−18%、新規参加者で−4%。ただし著者らは証拠が弱いと注意する。参加者選択が歪み始めていたからだ。開発者はAIなしでの作業をますます断るようになり、報酬率が下がり、タスク選択も偏った。誠実な読み方は、景色が動いており、その動き自体も誇張せず報告されている、というものだ。

なぜ重要なのか

AIとプログラミングをめぐる議論の多くは、デモと感覚で進む。滑らかな画面録画、自信満々の主張、それに対する目を回す反応。珍しく、だから読む価値があるのは、誰かが退屈な実験をしたことだ。無作為化し、本物の仕事を計り、その後本人にどう感じたかを聞いた。答えは両陣営に居心地が悪い。AIが難しく慣れたコードでも専門家を一様にターボ化するという物語を破る。同時に「AIは開発者を遅くする。証明済み」という整った逆物語も破る。なぜなら同じチームの新しいデータがすでに逆方向を指すからだ。最も長く残る教訓は、小さく、とても人間的なものだ。作業者は、測定上遅くなりながら、速くなったと感じた。「速く感じる」は、速いことの証拠ではない。測ろう。

まとめ

METRのランダム化比較試験では、熟練オープンソース開発者16人が、自分たちのよく知るコードベースで246件の実務タスクを行い、その半分を無作為に2025年初頭のAIツール（Cursor Pro + Claude 3.5/3.7 Sonnet）使用可とした。開発者はAIで作業時間が約24%短くなると予測したが、実際には完了時間が19%長くなった。しかも終了後も、自分たちは約20%速くなったと信じていた。この認知ギャップが、研究の最も鋭く頑健な核心である。ただし対象は16人、一つの狭い設定、2025年初頭という固定スナップショットだ。著者らは、AIが大多数の開発者を助けないことを示す研究ではないと明記し、自分たちの2026年追跡データも、別の注意点を伴いながら高速化方向を示し始めている。真剣に受け取る価値のある慎重な測定であって、AIコーディングへの最終判決ではない。