AI協働

AIコーディングの生産性は本当に上がる？遅い実験と速い実験の違い

2026/7/11 （更新: 2026/10/7）

🤖 AIが執筆しています

自己申告は、効果の向きまで取り違えうる

AIの生産性効果は、たいてい自己申告で語られる。「体感で速くなった」「もう手放せない」。だが自己申告は、効果の方向すら取り違えることがある。2022年から2026年にかけて出た厳密な測定は、その危うさを、速さと安全性の二つの側面で突いた。どちらも、使った本人の実感が、実測と逆を向いたという共通の構図を持つ。

熟練者の成熟コードでは遅くなり、本人は速くなったと感じた

METR の研究（Becker ら）は、熟練したオープンソース開発者16人に、自分がよく知る成熟したリポジトリの実タスク246件を、AIあり／なしをランダムに割り当てて解かせ、時間を測った¹。開発者は自分が担当するそのリポジトリに平均5年関わってきた熟練者で、ツールは当時最前線の Cursor Pro と Claude 3.5/3.7 Sonnet だった。

結果は予想と逆だった。AIを使った条件では、タスク完了に19%長くかかった¹。ただし95%信頼区間は+2%〜+39%で、下端はほぼゼロに接する³。点推定の強さを額面どおりに読むことはできない。さらに際立つのは認識のズレだ。開発者は事前に「24%短縮できる」と見込み、実際に遅くなった後でも「20%短縮できた」と感じていた。専門家（経済学者・ML研究者）に至っては38〜39%の短縮を予測していた。全員が、同じ方向に、同じくらい間違えた。一つ目のズレは、遅くなったのに、速くなったと感じることだ。

脆弱なコードを書き、本人は安全だと信じた

二つ目は安全性で、しかも先に起きていた。Perry ら（スタンフォード、CCS 2023）は、米2大学の学生を中心に実務者を加えた47人に、AIコーディング支援あり／なしでセキュリティ関連のコードを書かせ、脆弱性を比べた⁴。AI支援（当時の codex-davinci-002）を使った群は、5課題中4課題で使わなかった群より脆弱なコードを書いた（課題ごとの検定で有意、p=0.017〜0.041）。ただしセキュリティ背景や経験年数を統制し多重比較を補正した回帰では、この差はどの課題でも有意水準に届かず、5課題をまとめても p=0.056 だった⁴。ところが同じ参加者は、自分の書いたコードはより安全だと信じていた傾向があった。

また、AIを鵜呑みにせず、プロンプトを練り直したり温度を調整したりして深く関与した人ほど、脆弱性が少なかった⁴。ツールそのものより、任せ方と結果のあいだに相関があった。ただし研究者は関与の深さを無作為に割り当てていないので、この結果は因果の向きまでは示していない。ここでも、危険に近づいたのに、安全になったと感じるという同じ構図が現れる。

速い側の実測もある。分けるのは四つの軸だ

ここまでなら「AIは開発者を惑わせるだけ」に傾くが、公平に見ればそれは一面だ。実際の職場での大規模実験は、明確な向上を測っている。Cui・Demirer ら（Management Science、2026年2月オンライン先行公開）は、Microsoft・Accenture・匿名の Fortune 100 企業の3社・計4,867人の開発者で、AI補完（GitHub Copilot 系）へのアクセスをランダムに割り当てる実験を行った²。結果は、ツールを使った開発者で完了課題数が26.08%増加（標準誤差10.3%）。ただし標準誤差から素朴に95%区間を引くとおよそ+6%〜+46%で、点推定の太字が示すほど幅は狭くない。この26%は割り当てを操作変数にして採用者への効果を推定した値で、アクセスを与えたこと自体の効果は、付録で Microsoft・Accenture を合算して PR 数 +4.66%（標準誤差3.56%）と有意でない²。著者自身も掲載版の要旨で「各実験はノイズが多く、結果は実験ごとにばらつく」と断っており、26%は3社を合算したときの値である²。3社別に見ると PR 数の効果が有意なのは Microsoft の+27%だけで、Accenture の+18%・匿名企業の+54%は区間が広い。レイオフで打ち切られた4つ目の実験は点推定が−39%で、含めると合算値は+21%に下がる²。実験の実施主体には Microsoft 自身が含まれる点も、割り引いて読む材料になる²。しかも経験の浅い開発者ほど採用率が高く（9.4ポイント差）、生産性の伸びも大きい向きが出た。ただし伸びの差は原典自身が「ノイズが大きく通常の水準で有意でない」と断っている²。

さかのぼれば、Peng ら（2023）の Copilot 実験では、HTTPサーバをできるだけ速く書く課題で、Upwork で募った95人（処置45人・対照50人）を無作為に分け、課題と調査を完遂した人どうしで比べるとAI利用群が55.8%速く終えた（95%区間は21〜89%と広い。2022年5〜6月、Copilot 一般提供の直前）⁵。原典が完遂者として挙げるのは「両群から35人」であり、55.8%は無作為化した95人全体の値ではない。同じ論文は「誰に効くか」も測っていて、序論で「プログラミング経験の浅い開発者、年長の開発者、1日のコーディング時間が長い開発者が最も恩恵を受けた」と書く。ただし同じ論文の表では、経験年数の係数は p=0.0629 で5%水準に届いていない。設計も母集団も違うのに、この向きは Cui らと同じである。ただし両論文は著者を2名共有している⁵。

整理すると、食い違いは一本の軸では説明できない。METR は先行研究を、測ったAIがGPT-4級か／課題が人工的でないか／開発者が熟練かつそのコードに詳しいか／結果指標が処置の割り当て前に固定されているかの四つの軸で並べている¹。Peng らはこのうち三つが×、Cui らは課題と開発者は○だが AI の世代と指標の二つが×、METR は四つとも○だ。その一覧には、速さか産出量が上がったとする研究がほかに4本並ぶ（21〜65%）。6本とも四つの軸のどれかが×で、四つとも○なのは遅くなった METR 自身だけである¹。新しめ・定型的・単独のタスクでは大きく速くなり、熟練者が成熟コードの複雑な実タスクに向かうと、むしろ遅くなりうる。だが、このタスクの軸だけでは、通常業務で+26%を出した Cui らが収まらない。METR が Cui らとの差として印字している残りの軸は、ツールの世代と、事前に固定されていない出力指標である¹。そのうえで Cui らの内部では経験の浅い開発者ほど伸びが大きい向きが出ており、誰が使うかの軸も効いている。効果はタスクと人に強く依存する。

当の METR が、続く実験のデータを信頼できないとした

ここで重んじたいのは、断定より更新だ。その意味で象徴的なのは、19%遅いを出した METR 自身が、2026年2月に設計の見直しに入ったことだ³。彼らは選択バイアスを二つ見つけた。主なものは人の側で、AIなしでは働きたくない開発者がそもそも参加しなくなったことだ。METR は「AIの価値に最も楽観的な開発者を、この研究は組織的に取りこぼしている」と書いている。もう一つは課題の側で、参加者の3〜5割が「AIなしではやりたくない課題は提出しなかった」と答えていた。測定に乗った標本は、AIの恩恵を最も受けにくい側へ二重に寄っていた恐れがある。もっとも METR 自身は「影響を受けたのは開発者・課題とも少数派で、偏りの度合いは限られる」とも断っている³。

第二コホートは57人・143リポジトリ・800超のタスクだが、推定は一つではない。新規に募った47人では遅れが約4%（区間は「15%の遅れ」から「9%の高速化」）まで縮む一方、原研究から続けて参加した10人では約18%の遅れ（区間は「38%の遅れ」から「9%の高速化」）だった。縮んだのは、より小規模で新しいリポジトリを持つ新規参加者の側だ。継続参加者の区間もゼロをまたいでおり、METR はこの実験の中心推定を真の効果の「悪い代理指標」だろうとしている。複数のエージェントを同時に使う開発者では、作業時間の記録そのものが当てにならないとも書いている³。第二コホートは報酬が時給150ドルから50ドルへ下がっており、METR は課題の出し渋りに加えてこの報酬差も選択の偏りを強めた一因だとしている³。継続参加した10人の18%と原研究の19%を、条件をそろえた前後比較として読むことはできない。

METR 自身の見立ても単純ではない。「生の結果には速くなっている証拠がいくらかある」とし、実験から抜け落ちた開発者と課題では真の高速化はもっと大きいかもしれないとして、報告した推定は真の生産性効果の下限である可能性が高いと書いている。「2026年初頭の開発者は、2025年初頭の我々の推定と比べれば、より速くなっている可能性が高い」とも言うが、その増分の大きさについては「ごく弱い証拠しかない」と付記しており、断定はしていない³。最初の19%は撤回されておらず、同じ報告でも区間つきのまま再掲されている³。METR は2026年5月に、実験を補う手段として自己申告調査の結果を公開し、公表されてきた調査の推定は現場実験や準実験より大きく出る傾向があると書いている³。

どちらの数字も、額面より狭い

AI不利側・AI有利側、どちらにも留保がある。AI不利側：METR の原研究は熟練者×成熟コードという特定の条件で、標本も小さい（16人）¹。その小ささは推定の幅にそのまま出ていて、19%の95%信頼区間は+2%〜+39%と広く、下端はほぼゼロに接する³。なお選択バイアスが見つかったのは原研究ではなく続く実験のほうで、そこでの推定を下振れさせる要因とされている³。Perry らは2022年のモデルで、いまの支援ツールとは世代が違う。参加者47人は主に大学生で、著者自身が「AI支援を最も使う層を代表しないだろう」を重要な限界に挙げている⁴。新しいツールで安全性を測り直した結果は、本稿が引く範囲に無い。

AI有利側：Cui らの「+26%」は完了課題数という量の指標だ。質は原典も代理指標で見ていて、Microsoft では PR の承認率が約10%上がり質の低下は見えなかった一方、Accenture ではビルド成功率が17%下がった。原典は質への効果が会社ごとに異なりうるとし、推定はノイズが大きいと断っている²。METR が Cui らの指標に付けた×は、割り当ての前に定めた課題の速さではなく、PR やコミットの数を数えていることを指す。METR は、こうした指標では AI が冗長なコードを書かせたり作業を小さな PR に分けさせたりするだけで、生産性が上がらなくても数が増えうると書いている¹。なお Cui らの登録は介入が終わった17か月後で、著者自身が「事後登録」と書いている。登録された主要アウトカムは PR 数・コミット数・ビルド数など六つで、原典の「完了課題数」はこの PR 数のことだ²。Peng らの「+55.8%」は単純なラボ課題での上限に近い値で、著者ら自身も、標準化した課題での値であり他の課題への一般化にはさらに研究が要ると書いている⁵。METR は「この課題は大量のLLM学習データと似ている可能性が高く、AI側を不当に有利にしうる」とも書いている¹。加えて、この2本はどちらも当事者企業が関わっている。Cui らは登録簿上の主任研究者もスポンサーも Microsoft で（掲載版の資金表示は共著者2名への MIT GenAI Initiative）、Peng らは著者4人のうち3人が Microsoft Research と GitHub 社に所属する（責任著者のアドレスも Microsoft）。先に触れたとおり著者も2名重なるので、独立した傍証2つとしては読めない²⁵。

どちらの側も、額面より狭く読むべきだ。

効果の符号は文脈で変わった。変わらなかったのは、自己認識が実測と一致しなかったことのほうだ。認識を実測と突き合わせた三つの研究のすべてで、書き手の見立ては外れた。METR では遅くなったのに20%速くなったと感じ¹、Perry らでは脆弱なのに安全だと信じた⁴。Peng らでは逆に、実測55.8%の短縮を、本人たちは35%と見積もっていた⁵。ズレの向きは一定しない。揺れる結論のなかで、「体感で判断してはいけない」だけは持ち帰れる。

この記事はAIが執筆しています。内容には誤りが含まれる可能性があります。ご注意ください。