Skip to content
←

필사 모드: AI は本当に開発者を速くするのか — 測定された数字が語ること

日本語
0%
정확도 0%
💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

はじめに — 食い違う二つの数字

AI コーディングツールがどれだけ生産性を上げるのかについて、私たちはよく設計されたランダム化比較試験(RCT)を二つ持っています。そしてその二つは、正反対の答えを出しました。

一方は、AI を使った開発者が 55.8% 速かった と言います。もう一方は、19% 遅かった と言います。

そしてここに、もう一つのどんでん返しがあります。後者の数字は、もはや「現在」ではありません — その数字を作った研究チーム自身がそう言っています。19% のスローダウンを測った METR は、2026年2月に続報を公表し、2025年の結果の上に警告バナーを掲げました。"These results are out of date"(この結果は有効期限が切れている)、そしてそれは "no longer reflect the current impact of AI models"(現在の AI モデルの影響をもはや反映していない)、と。

ですからまず、本稿が立っている場所をはっきりさせます。19% は 間違った数字ではなく、過去の数字 です。2025年前半に実際に測定された値であり、その時点の記録としては今も有効です。ただしそれを「いま AI を使うと 19% 遅くなる」と読むのは誤読です。METR 本人が、そう読まないでほしくてバナーまで掲げたのです。

よくある反応は、どちらか一方を選ぶことです。楽観派は前者を引用し、懐疑派は後者を引用します。しかし、どちらも本物の実験であり、本物の結果です。面白い問いは「どちらが正しいか」ではなく、「何が二つを分けたのか」、そしていまや、もう一つ加わります — 「なぜこれを正しく測ることが、これほど難しいのか」 です。

先に核心を言っておきます。この記事で最も重要な発見は、19% という数字そのものではありません。もともとそうではなかったし、METR がその数字に有効期限を付けたいま、なおさらそうではありません。最も重要なのは 自己認識が間違っていた ということです。そしてその発見にはバナーが付いていません。以前の LLM バーンアウトの記事 で、生成は安くなったが検証はそのままだと書きました。本稿は、その非対称性に誰かがストップウォッチを当てたとき何が見えるか、という話です。

実験その一 — 55.8% 速くなった

2023年、Peng、Kalliamvakou、Cihon、Demirer は GitHub Copilot について統制実験を行いました。プロの開発者 95 名を集め、半分だけに Copilot を与え、全員に同じ課題を出しました。JavaScript で HTTP サーバーをできるだけ速く実装せよ。

Copilot を与えられたグループは、対照群より 55.8% 速く 終えました。しかも利得は均等ではありませんでした。経験の浅い開発者、年齢の高い開発者、業務負荷の大きい開発者ほど効果が大きく出たのです。著者たちはこれを、AI がソフトウェア開発への参入を助けうる兆候として読みました。

この数字は今もよく引用されます。ところが引用されるとき、ほとんど必ず落ちるものがあります。それが どんな種類の課題だったか です。

  • グリーンフィールドです。 既存のコードベースがありません。絡まるレガシーも、壊れる呼び出し元もありません。
  • 自己完結しています。 課題全体が一度に頭に入ります。
  • 仕様が明確です。 HTTP サーバーが何をすべきかで揉める人はいません。
  • 検証が安いです。 サーバーが起動して応答するか。数秒でわかります。
  • 測ったのは速度であって品質ではありません。 半年後に誰がそのコードを保守するのかは実験の範囲外です。

つまり 55.8% は嘘ではなく、きわめて特定の条件下で真である数字 です。問題は、多くの実務開発者が一日の大半をその条件の外側で過ごしているという点にあります。

実験その二 — 2025年初頭、19% 遅くなった

2025年、METR(Becker、Rush、Barnes、Rein)はまさにその外側を測りました。論文名は "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity" です。タイトルに Early-2025 と刻まれていることを覚えておいてください。あとで効いてきます。

設計はこうです。熟練したオープンソース開発者 16 名 が、自分が保守しているリポジトリから出た本物の Issue 246 件 を持ち寄ります。各 Issue はランダムに「AI 使用可」か「AI 使用不可」に割り当てられます。参加者は主に Cursor Pro と Claude 3.5/3.7 Sonnet を使い、試験は 2025年2月から6月にかけて行われました。

ここで決定的なのは、開発者とコードベースの関係 です。

  • リポジトリは平均して 10 年以上を経た成熟プロジェクトで、100 万行を超え、スターは 2 万を超えます。
  • 開発者たちはそのリポジトリで平均 5 年 働き、コミットは平均 1,500 件 積み上がっています。
  • つまり彼らは、そのコードについて文書化されていない暗黙知を大量に抱えた人たちです。

結果は、AI を許可すると完了時間が 19% 増えた というものでした。遅くなったのです。著者の表現を借りれば "allowing AI actually increases completion time by 19%" — AI ツールが開発者を遅くしました。信頼区間は +2% から +39% で、0 を含みませんでした。統計的にも方向がはっきりした結果だったということです。

この段落の動詞がすべて過去形なのには理由があります。これは 2025年2月から6月までの世界についての測定です。そしてその世界は、その後変わりました。

その後に起きたこと — METR の 2026年の続報

2026年2月24日、METR は同じ実験を継続した結果を公表しました。題は "We are Changing our Developer Productivity Experiment Design" です。そして同じ時期に、2025年の論文の上に警告バナーが掲げられました。研究チームが自分の代表作の見出し数字を自ら下ろすのは、珍しいことです。ですから、新しい数字をそのまま見ましょう。

  • 既存の参加者(returning developers) — スピードアップ -18%、信頼区間 -38% ~ +9%
  • 新たに募集した参加者(newly-recruited developers) — スピードアップ -4%、信頼区間 -15% ~ +9%

ここでは二つのことを同時に読まねばなりません。

第一に、点推定値はいまだにマイナスです。 2026年初頭の道具をもってしても、この設定で測られた平均は依然として「速くなった」ではありません。ですからこの更新は、「実は AI が開発者を速くすると判明した」という話では ありません。 そう読むのは、もとの誤読を逆向きに繰り返すだけです。

第二に、しかし二つの信頼区間はいずれも 0 をまたぎます。 2025年の +2% ~ +39% とは違い、2026年の数値はスローダウンとスピードアップの両方を含みます。統計的に符号を確定できない、ということです。2025年には「遅くなった」と言い切れましたが、2026年のデータではそう言えません。

しかし数字より重要なものがあります。METR が併せて報告した 自己選択バイアス です。

こういう実験をするには、開発者に「この作業は AI なしでやってください」と指示せねばなりません。ところが 2026年になると、それを拒む人が増えました。METR の表現では、研究への参加を辞退する開発者が有意に増え、その理由が "because they do not wish to work without AI"(AI なしで働きたくないから)でした。参加した人たちの内側でも同じです。開発者の 30〜50% が、一部の作業をそもそも提出しなかったと METR に告げました。理由は "they did not want to do them without AI"(その作業を AI なしでやりたくなかったから)。

なぜ致命的か、見えるでしょうか。AI なしでやりたくない作業とは、すなわち AI が最も大きく助けてくれそうな作業です。 まさにそういう作業が、標本から組織的に抜け落ちていきます。METR 自身がこのバイアスの方向を明示しています — これは AI のスピードアップ推定値を下方に引っぱる、と("likely biases downwards our estimate of AI-assisted speedup")。

ですから 2026年の -18% と -4% は、それ自体では「AI が人を遅くする」の証拠ではありません。それは AI なしで働くことを拒まなかった人たちが、AI なしでも大丈夫だと自ら判断した作業から 出てきた値です。

では METR は何と結論づけたのか。彼らは、2025年初頭の推定と比べれば、いまの開発者は AI でより速くなっている可能性が高いと見ています("developers are more sped up from AI tools now")。しかしすぐに但し書きを付けます — 実験の選択効果のせいで、"our data is only very weak evidence for the size of this increase"(我々のデータはその増加幅について非常に弱い証拠にすぎない)。

これが現在得られる最善の答えです。おそらく良くなった。どれだけかは我々にもわからない。 この問題を世界で最も真剣に測っているチームが、二度目の試行を終えて出した結論がこれです。覚えておいてください。本稿の最後でもう一度使います。

本当の発見 — 認識と実測のずれ

19% はもう過去形です。しかし 2025年の研究には、バナーの付かなかった発見がもう一つあります。そして本稿の助言が実際に足を置いているのは、そちらの方です。

  • 実験の 前、開発者たちは AI が自分を 24% 速く すると予測しました。
  • 実験を 終えたあと、つまり実際に 19% 遅くなる経験を身をもって通過したあとで、彼らは自分が 20% 速くなった と見積もりました。
  • ちなみに経済学の専門家は 39% の短縮を、機械学習の専門家は 38% の短縮を予測しました。全員、大きさどころか符号を外しています。

これは予測が外れたという話ではありません。事後の振り返りすら外れた という話です。たった今自分がやった仕事を、ストップウォッチと逆向きに記憶したのです。認識と実測のあいだに、およそ 40 パーセントポイントの溝が開いていました。

なぜこんなことが起きるのか。もっともらしい説明は単純です。生成は目に見え、検証は目に見えないから です。

モデルが 3 秒で 40 行を吐き出す瞬間は鮮烈で、記憶に残ります。その 40 行を読み、前提を疑い、このリポジトリの作法に照らし、半分を捨てる 20 分は記憶に残りません。それはただ「仕事をしている」ように感じられるだけです。私たちはドーパミンが跳ねる瞬間で一日を採点し、静かに削られた時間を帳簿に書きません。

METR のデータはこの解釈を裏づけます。開発者たちが受け入れた AI 生成コードは 44% 未満 でした。残りは、読み、判断し、捨てるために使われた時間です — 何の成果物も残さずに。そして参加者のうち実際に AI で速くなったのは 約 4 分の 1 だけでした。

ここでもう一度強調しておきます。この発見には有効期限バナーが付きませんでした。 METR が期限切れだと言ったのはスピードアップの大きさであって、人が自分のスピードアップをどれほど読み違えるか、ではありません。道具は一世代進みましたが、その道具を使う人間の自己計測能力がその間に良くなったという証拠は、どこにもありません。

何が二つの実験を分けたのか

二つの実験の違いを一文に縮めると、こうなります。AI は、あなたが持っていない文脈を埋めるときに勝ち、あなたがすでに持っている文脈に追いつかねばならないときに負ける。

Copilot 実験の参加者は白紙の画面の前にいました。モデルが埋めるものはすべて純粋な利得です。METR 実験の参加者は、5 年分の暗黙知をすでに頭に抱えていました。モデルはその文脈を知らず、教えるにはプロンプトを書く必要があり、返ってきたものは再びその暗黙知に照らして検査せねばなりません。文脈が豊かな人ほど、モデルを自分に追いつかせる費用が高くつくのです。

METR の著者が突いた最も鋭い点がこれです。2025年の試験で、開発者たちは より馴染みのある Issue でこそ、より大きく遅くなりました。 馴染みは盾ではなく、税だったのです。

2026年のデータもこの方向と矛盾しません。自分のリポジトリを長く守ってきた既存の参加者は -18% で、新たに加わった参加者は -4% でした。馴染みのある側のほうが大きく遅くなったわけです。ただし二つの信頼区間は大きく重なるので、これを証拠と呼ぶのは行きすぎです。仮説と矛盾しない、その程度にとどめて記しておきます。

だから実務で使える軸は二つです。馴染み と 検証コスト。

  • 不慣れ + 検証が安い — AI が最も確実に勝つマスです。初めて使う言語、不慣れな API、使い捨てスクリプト、足場づくり。間違えばすぐわかり、あなたが知らなかったものをモデルが埋めてくれます。存分に使ってください。
  • 慣れている + 検証が安い — ボイラープレート、繰り返しのパターン。利得は小さいが損失も小さい。無難です。
  • 慣れている + 検証が高い — METR のマスです。微妙なロジック、古いコードの不変条件、あなただけが知る落とし穴。自分で書くほうが速いかもしれません。
  • 不慣れ + 検証が高い — 最も危険なマスです。 理解していないものはレビューできません。ここで AI の出力は静かに技術的負債になり、請求書はたいてい数か月後に届きます。このマスにいるなら、直すべきは道具ではありません。まずその領域を学ぶことです。

この四つのマスは今も使える地図です。ただし、いまはこう但し書きを付けねばなりません。これは仮説であって、測定された法則ではありません。 ですから自分がどのマスにいるのかは、自分で測って確かめるしかありません。

組織の単位で見ると — DORA と Stack Overflow

個人レベルの錯覚は、組織レベルではどう現れるのか。2025年の DORA レポート(State of AI-assisted Software Development)が、技術専門家およそ 5,000 名を調査しました。

採用率の議論はもう終わっています。開発者の 約 90% が AI を使い、80% 以上 が生産性が上がったと答えます。そして DORA は、AI が 実際にスループットを増やす と見ています — ここまでは楽観的です。

問題は、同じレポートが AI は 不安定性(instability)も同時に増やす と述べていることです。コードがより多く、より速く作られれば、その下流にある弱い環がそのまま露出します。自動テスト、成熟したバージョン管理、速いフィードバックループといった制御装置がなければ、変更量の増加はそのまま不安定さに変わります。

だから DORA の結論は 「AI は増幅器である」 です。AI は組織の既存の強みと弱みを一緒に拡大します。健全なエンジニアリングシステムの上に載せれば成果は積み上がり、壊れたシステムの上に載せれば 低品質な成果物をより速く量産するだけ です。速度だけあって安定性がなければ、それは加速された混沌にすぎません。

Stack Overflow の 2025年開発者調査(回答者およそ 4 万 9 千名)が最後の一片を置きます。利用率と信頼が逆方向に動いています。

  • AI ツールを使っている、あるいは使う予定の回答者は 84% — 前年の 76% から増えました。
  • ところが AI 出力の正確さを 信頼しない という回答が 46% で、信頼する という回答の 33% を上回ります。
  • 「強く信頼する」はわずか 3.1% です。
  • 最大の不満は 66% が挙げた 「ほぼ正しいが、完全には正しくない答え」 です。二位は 45% の 「AI が書いたコードのデバッグのほうが時間がかかる」。

「ほぼ正しいが、完全には正しくない」 — これが本稿全体を貫く言葉です。明らかに間違ったコードは安く弾けます。高くつくのは、信じたくなるほどもっともらしく、代償を払うほど間違っている コードです。そしてそれを弾く労働は、どのダッシュボードにも載りません。

では何をすべきか

このデータは「AI を使うな」という意味ではありません。やるべき仕事は別にあります。

1. 感覚を信じず、自分の仕事を実際に測る。 この研究の教訓は振り返りが噓をつくということなので、記憶ではなく記録が要ります。そして METR の 2026年の続報は、この助言を弱めるどころか強めます — 専従の研究チームがランダム化比較試験を二度回してなお符号を確定できなかったのなら、一日を終えたあなたの印象は、なおさら確定できません。道具は大げさである必要はありません。作業を始める前に見積もりを一行書き、終わったら実際の時間と AI を使ったかどうかを書く。二週間分も溜めれば、どんな調査よりもあなたにとって正確です。測られていない生産性向上は、ただの気分です。

2. 馴染みと検証コストで仕事を選ぶ。 上の四つのマスを基準にすればよいのです。不慣れで検証が安い仕事には惜しみなく、慣れていて検証が高い仕事にはけちに。そして不慣れかつ検証が高い仕事には、道具より先に学習を投じてください。

3. レビューを一級の業務として予算に入れる。 生成が無料に近づくほど、ボトルネックはすべて検証へ移ります。レビューを「本当の仕事のあとの雑務」として扱うかぎり、増えた費用は帳簿の外に残り続けます。この点は LLM バーンアウトの記事 でより詳しく扱いました。

4. ベンダーの数字はベンチマークと同じように扱う。 つまり懐疑的に。55.8% がどんな課題から出た数字かを覚えていれば、次にマーケティング資料で見る数字にも同じ問いを立てられます — どんな課題で、誰が測り、何が省かれたのか。そしていま、問いがもう一つ増えました。いつ測った数字なのか。 評価の数字がどう揺らぐかは コーディング評価で信号とノイズを見分ける記事 で扱いました。

5. 人間が読めるように書く。 検証がボトルネックなら、読みやすいコードはもはや趣味の問題ではなく、スループットの問題です。AI がコードを保守する時代でも、人間のために書く で述べたとおりです。

数字を読むときの正直な注意書き

本稿が「研究は AI が役に立たないと証明した」と読まれては困るので、両方の限界をはっきり書いておきます。

METR 2025年研究の限界。 参加者は 16 名です。小さい。測ったのは特定の一つの設定(大規模で成熟したオープンソースリポジトリ、高熟練の保守者)にすぎません。参加者の 56% は Cursor を使ったことがなく、モデルは 2025年前半のもの — 今の基準では一世代以上前の道具です。著者たち自身が、この結果は次のことを示すもので はない と明記していました。AI が大半の開発者を速くしないということ、ソフトウェア以外の領域でもそうだということ、近い将来の AI も同じ設定で失敗するということ、そして既存の AI をもっとうまく使う方法が存在しないということ。この四つは、この論文の主張ではありません。そしていまや著者たちは、その上に有効期限の警告まで掲げました。

METR 2026年続報の限界。 ある意味ではもっと深刻です。自己選択バイアスが実験の骨格を蝕んでいます。AI なしで働くことを拒む開発者が増えるほど、残って測られるものは「AI なしでも大丈夫な作業」へと偏っていきます。METR がこのバイアスの方向(推定値を下に引っぱる)を明示したのは誠実ですが、方向がわかることと大きさがわかることは別です。だからこそ 2026年の数値は、より広い信頼区間とより弱い結論を伴って出てきます。そしてこの問題は、時間とともに良くなるのではなく 悪くなります。 AI が有用になるほど、AI なしの対照群を確保することが難しくなるからです。METR が続報の題を「実験設計を変える」としたのは、まさにそのためです。

Copilot 研究の限界。 課題は一つ、グリーンフィールドで、自己完結しています。測ったのは完了時間であって、コード品質でも保守性でもありません。著者に GitHub 所属の研究者が含まれる点も記録しておく価値があります。

DORA と Stack Overflow の限界。 どちらも自己申告の調査です。そして METR が明らかにしたまさにその理由により、自己申告はこの主題に関してこそ最も信用ならない道具なのです。

ですから正直な結論は「AI はあなたを遅くする」ではありません。正直な結論は三文です。効果は文脈しだいで符号すら反転する。その符号は、よく設計されたランダム化試験をもってしても綺麗には読み取れない。そしてあなたの感覚では、なおさら読み取れない。

おわりに

私たちはたいてい、道具について「良いか悪いか」を問います。このデータが言っているのは、それが間違った問いだということです。同じ道具が、ある実験では 55.8% の利得を、別の実験では 19% の損失を生みました。道具は変わっていません。変わったのは 仕事の種類と、それをする人の文脈 です。

そしてその上に、もう一枚あります。19% という数字さえ、いまや「いま」ではなく「あのとき」の値になりました。その数字を作った当人たちが、自らそう表示したのです。続報の実験は符号を確定できず、その理由はデータ不足ではありませんでした。AI なしで働くことを拒む人たちのせいで、綺麗な対照群そのものが消えつつあるから です。

ここで謙虚になることもできますし、逆に結論をより強く握ることもできます。私は後者だと思います。考えてみてください。専従の研究チームが、ランダム化比較試験を設計し、実在のリポジトリから本物の Issue を数百件集め、二度試みた。それでも出てきた結論が「おそらく良くなった、ただしその大きさについては非常に弱い証拠しかない」なのです。

彼らがストップウォッチを手にしてなお符号を確定できなかったのなら、あなたが感覚だけでそれを知ることはできません。 これが本稿の本当の結論であり、2026年の更新はこの結論を揺るがしたのではなく、釘をより深く打ち込みました。

そして、19% 遅くなった人たちが自分は 20% 速くなったと信じていた、あの溝は、いまも同じ場所にあります。私たちの多くは、いまも彼らと同じ場所に立っています — 自分の生産性について確信を持ちながら、その確信を一度も測ったことがない場所に。

だからこの記事から一つだけ持ち帰るなら、これであってほしいと思います。AI をもっと使ってもいいし、減らしてもいい。ただ、これからの二週間、あなたの作業時間を実際に記録してみてください。 あなたには METR にない利点が一つあります。あなたが扱うべき標本は一つだけで、その標本は参加を拒みません。 そのデータは、どんなベンチマークよりも、どんなベンダー資料よりも、そして何より、あなた自身の感覚よりも正確です。

参考資料

현재 단락 (1/91)

AI コーディングツールがどれだけ生産性を上げるのかについて、私たちはよく設計されたランダム化比較試験(RCT)を二つ持っています。そしてその二つは、正反対の答えを出しました。

작성 글자: 0자원문 글자: 10,994자작성 단락: 0/91