AI技術(cursor pro, claude3.5/3.7)によってコーディング開発が19%遅くなっている？！
2025/7/10に公開されたMETR論文：Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity の詳説記事です。
執筆にはLLMの助けも借りていますが、著者はちゃんと論文を読んだ上で適宜修正して投稿しています。
0. TL;DR
-
熟練 OSS 開発者 16 名 × 246 件のリアル Issue を対象に RCT を実施。
- 注：RCT（Randomized Controlled Trial）: 介入（AI 使用可）と対照（AI 不可）を無作為に割り当て、因果効果を推定する実験手法。
-
AI （Cursor Pro ＋ Claude 3.5/3.7）の使用を許可すると平均 19 % 遅延。開発者自身は 24 % の時短を予測していたため、認知と現実が真逆だった。
-
開発が遅くなっているのは外れ値ではなく分布全域で一貫。「大規模コード・暗黙知不足・生成品質の低さ」など 5 要因を有力視。
1. 研究の目的と背景
- コーディング系ベンチマークは「自己完結タスク」「自動採点」のため 実務適合性を犠牲 にしている可能性がある。
- 現場では「AI で速くなる」という 体感的・逸話的な報告 が多数。これらがどの程度信頼できるかを検証するのが本研究の目的。
2. 実験デザイン
| 項目 | 詳細 |
|---|---|
| 対象開発者 | ⭐22 k 以上／100 万行超の OSS に複数年コミットする 16 名(時給$150で協力してもらった) |
| タスク | バグ修正・機能追加など 246 件（平均 2 h） |
| 割り付け | Issue 単位で AI 使用可／不可 をコイントス決定 → AI allowed 136 件 / AI disallowed 110 件 |
| AI ツール | 主に Cursor Pro＋Claude 3.5/3.7（frontier 当時） |
| 測定 | 画面録画＋自己申告時間＋PR 承認までを計測 |
3. 主な結果
3-1．平均的には 19 % 遅い
-
16 人 × 246 件 の Issue を無作為に AI 使用可 / 使用不可 に割り付けたところ、
AI 使用可 の方が 平均 19 % 時間が長く なった。 - この 19 % は「タスクの難しさ（開発者が事前に申告した予想時間）」を統計モデル(回帰補足)で調整した 主要推定値 です。
- 同じ Issue でも「バグ修正」より「機能追加」の方が難しい――みたいな差が少し残ってしまうと、生の平均時間だけでは不公平。「難しさ」を説明変数に入れて、“もし同じ難易度だったら何分違うか” を推計し直している。
3-2．開発者も専門家も 完全に読み違えた
実測で**+19 % 遅延** しているが下記のように予測を間違えている。
特に実験後も開発者が早くなったと錯覚しているので、体感と計測は別物だと示している。
| 予測主体 | 事前の期待 |
|---|---|
| 開発者 | –24 % 短縮するはず |
| 開発者（終了後の自己評価） | –20 % 短縮したと思い込む |
| 経済学の専門家 34 名 | –39 % 短縮を予測 |
| ML の専門家 54 名 | –38 % 短縮を予測 |
3-3． 短いタスクでも長いタスクでも一様に遅くなっている
- 下記のグラフ は「ECDF（累積分布）」というグラフ。横軸が“タスク完了までの分数”、縦軸が“その時間までに終わったタスクの割合”。
- たとえば、50パーセンタイルのところを見ると、AI使用可のとき50%のタスクが1.6h以内に完了する。
- 橙線（AI あり）が 全パーセンタイルで青線（AI なし）より右──つまり 短いタスクも長いタスクも一様に遅い。
3-4．生の平均 だけを見ると＋34 % 遅い
- AI ありの生平均時間は +34 %。
- ただし AI あり側に少し難しめの Issue が入った影響を差し引くと +19 % に落ち着く。
3-5．何に時間を使ったのか？
AIの使用が許可されている開発者はコーディングや検索などに使う時間は減ったが、プロンプト作成やAIの出力まち、レビューに新たに時間がかかるようになっている。
| 活動カテゴリ | AI なし | AI あり | 主な差分 |
|---|---|---|---|
| コーディング | 36% | 25% | –11 ポイント |
| 検索／解読 | 25% | 17% | –8 ポイント |
| プロンプト作成 | 0 | 8 % | +8 ポイント |
| AI 出力待ち | 0 | 4 % | +4 ポイント |
| AI 出力レビュー | 0 | 9 % | +9 ポイント |
| アイドル | 6 % | 10 % | +4 ポイント |
3-6．遅延に寄与したと考えられる 5 要因
| 要因 | 主な観察事実 |
|---|---|
| AI の有用性を楽観視 | ・開発者は「実装時間が 24 % 減る」と予測し、作業後も 20 % 減ったと回答 |
| 開発者がリポジトリに精通しすぎ | ・慣れた Issue ほど遅延が大きい ・平均 5 年開発経験・1 500 コミット |
| 巨大かつ複雑なリポジトリ | ・AI は大規模環境で性能低下 ・平均 10 年超のリポジトリ、110 万行超のコード |
| AI の信頼性が低い | ・生成コードの受入率 <44 % ・大半が大幅修正を報告 ・総時間の 9 % をレビュー／清掃に費やす |
| 暗黙の文脈不足 | ・開発者いわく「AI は 暗黙知は文脈 を理解してくれない」 |
3-7．効果がはっきりしない 9 要因
| 要因 | 主な観察事実 |
|---|---|
| 実験が誘発した AI の“使いすぎ” | 通常利用と似た遅延／「過使用」との自己報告あり |
| タスク分布の偏り | Issue は「標準だが短め」との評価；非プログラミング作業を除外 |
| AI によるスコープ拡大 | 「スコープ膨張しない」開発者は遅延が小さい；AI あり Issue は行数 +47 % |
| Issue 実施順バイアス | 割付後の順番は開発者が任意決定 |
| 速さより“楽さ”を選択 | 「手間が減るなら遅くても可」という声；Cursor 継続率が高い |
| 初回 PR の質が低い | レビュー後の修正時間は両条件で大差なし |
| AI ツール熟練度不足 | Cursor 経験者でも同等遅延；学習曲線の影響は不明瞭 |
| AI 生成レイテンシ | 待機が重要との声と否定意見が混在；待機は総時間の 4 % |
| プロンプト最適化不足 | 多くが Cursor エージェントで少トークン生成；未使用の手法で改善余地あり |
3-8．遅延に寄与しないと考えられる 6 要因
| 要因 | 主な観察事実 |
|---|---|
| 不慣れな開発環境 | 両群ともほぼ同じ IDE を使用し、Cursor を 30–50 時間使っても学習効果は確認できず。それでも 24 % の遅延が残った。 |
| AI の未使用・不正利用 | ラベル付き 54 本の録画中、AI 未使用は 16.4 %、不正使用はわずか 3 件。影響はごく小さい。 |
| Issue の途中放棄 | 偶発的なドロップはなし。意図的に除外した Issue でも遅延パターンは変わらず、バイアスは見当たらない。 |
| アウトカム指標の脆弱性 | 実装時間以外の代替指標を用いても、同程度のスローダウンが再現された。 |
| 推定方法の脆弱性 | 別の統計推定器を試しても、遅延の大きさはほぼ同じだった。 |
| 旧世代モデルの使用 | 参加者のほとんどが当時のフロンティアモデルを使用しており、モデル世代の差は影響せず。 |
4. 著者が述べる制約
-
対象者の偏り
大規模 OSS で長年活動している熟練コントリビューター 16 名のみを対象としているため、
新人開発者・企業内プロジェクト・小規模リポジトリにそのまま適用できるとは限らない。 -
タスク粒度の制約
研究では Issue を平均 2 時間程度に細分化して実施した。
数日～数週に及ぶ長期開発やマルチイテレーションのワークフローには効果を検証していない。 -
モデル世代とツール依存
評価対象は 2025 年前半時点のフロンティアモデル（Claude 3.5／3.7）＋ Cursor Pro。
より高性能な後継モデルや別 IDE・別 LLM を使った場合、結果が変わる可能性がある。 -
Cursor IDE の学習曲線
参加者の 44 % は Cursor をほとんど使った経験がなく、習熟度の差が影響している可能性を完全には除去できていない。 -
実験アーティファクトの残存可能性
ランダム化やロバストネス検証を行ったものの、
「実験だから AI を使いすぎた」といった介入起因のバイアスを完全に排除できたわけではない。
ぼくおも（僕が思ったこと)
非常におもしろい実験だと思った。
今まで、さまざまなベンチマークと実社会タスクとの乖離は思っていたが、ちゃんと検証して面白い示唆を出しているなと思った。特に、issueを終えた後も開発者がAIを使って高速化できたと思っているのが不思議に思った。AIを使って開発速度が遅くなったとなっているが、治験者が高速化したと思っているということは、頭の負荷が減ったとかなにかしら実際の時間では測れなていない効果もありそう。例えば、待機時間とかは別の作業できるから問題ないとか、一から考えるよりAIが出したものからできるから楽とか。
今回のAIが開発速度を下げているは、結構極端な結論だが、自分が使う場合もAIを使って本当に効率的になっているのかを考え、使うべきところを見定めていくべきだなと思った。
特に、習熟していない領域はAIの方が賢いから任せた方が自分よりは良いアウトプットを出してくれるし、自分が習熟している領域ではなんとか暗黙知やコンテキストをAIに理解してもらえるように言語化(プロンプティング）していく必要がありそう。（ただ、本当に自分のコアな仕事を代替しようとすると、大抵の仕事はかなりのコンテキスト・暗黙知が含まれていると思うので、もう少し先の話になりそう）
Discussion