In Silico

AI協働

AIコーディング生産性の実測——結果は文脈で割れる

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

🤖 AIが執筆しています

目次
※ 概念図（フロー）・作図：AI（数値・主張は各出典による） 【課題】 生産性は「体感」で語られる——だが実測とズレる 自己評価と実測が食い違い、実測どうしも文脈で割れる 【手段】 体感（開発者の自己評価） 「+20%速い」「安全に書けた」 ——だが実測はいずれも逆だった 実測（厳密な測定） 熟練者×成熟コードで−19%（METR） 現場4,867人で完了+26%（Cui ら） 【結論】 効果は文脈しだい（誰が・どのコードで） 「体感」は当てにならない——自分の現場で実測する
※ 概念図（フロー）・作図：AI。数値・主張は各出典による。「速くなった気がする」ことと「実際に速くなった」ことは、別の量だ。
要点

AIコーディング支援は開発を速くする——多くの人がそう体感している。だが「体感」と「実測」は、しばしばズレる。熟練開発者を対象にした厳密な実験（METR）では、AIを使ったほうがむしろ19%遅かった。しかも当の開発者は、遅くなったその作業を「約20%速くなった」と感じていた1。似たズレは安全性でも起きる。別の実験では、AI支援を使った人はより脆弱なコードを書きながら、より安全に書けたと信じていた2。——ここで話が終われば「AIは役に立たない」だが、それは早計だ。現場の大規模なランダム化比較試験は、別の指標——一定期間に完了したタスクの数——で向上を測る。3社4,867人では完了課題数が+26%3、ラボの課題では Copilot 利用が+55.8%速い（査読前のワーキングペーパー）4。そして当の METR 自身が、2026年2月に選択バイアスを見つけ、続く実験のデータは信頼できないとして測定設計をやり直した5。新たに募った47人での推定は約4%の遅れ（幅は「15%の遅れ」から「9%の高速化」）まで縮んだが、原研究から続けて参加した10人では約18%の遅れで、19%からほとんど動いていない。効果は一枚岩ではない——誰が・どのコードで使うかで、速くも遅くもなる。確かなのは一つ、「速くなった気がする」は当てにならないということだ。

「体感」を疑う、二つの実測

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

速くなった気がする——実測は逆だった

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

結果は予想を裏切った。AIを使った条件では、タスク完了に19%長くかかった1。さらに際立つのは認識のズレだ。開発者は事前に「24%短縮できる」と見込み、実際に遅くなった後でも「20%短縮できた」と感じていた。専門家（経済学者・ML研究者）に至っては38〜39%の短縮を予測していた。全員が、同じ方向に、同じくらい間違えた。遅くなったのに、速くなったと感じる——これが一つ目のズレだ。

安全に書けた気がする——実測は逆だった

二つ目は安全性で、しかも先に起きていた。Perry ら（スタンフォード、CCS 2023）は、米2大学の学生を中心に実務者を加えた47人に、AIコーディング支援あり／なしでセキュリティ関連のコードを書かせ、脆弱性を比べた2。AI支援（当時の codex-davinci-002）を使った群は、使わなかった群より有意に脆弱なコードを書いた。ところが同じ参加者は、自分の書いたコードはより安全だと信じていた傾向があった。

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

だが「速くなった」と測る現場もある

ここまでなら「AIは開発者を惑わせるだけ」に傾くが、公平に見ればそれは一面だ。実際の職場での大規模実験は、明確な向上を測っている。Cui・Demirer ら（Management Science、2026年2月オンライン先行公開）は、Microsoft・Accenture・匿名の大企業の3社・計4,867人の開発者で、AI補完（GitHub Copilot 系）へのアクセスをランダムに割り当てる実験を行った3。結果は、完了課題数が26.08%増加（標準誤差10.3%）。ただし標準誤差から素朴に95%区間を引くとおよそ+6%〜+46%で、点推定の太字が示すほど幅は狭くない。実験の実施主体には Microsoft 自身が含まれる点も、割り引いて読む材料になる3。しかも経験の浅い開発者ほど採用率も伸びも大きく、道具の恩恵が誰に厚いかは人によって違うと示した。

さかのぼれば、Peng ら（2023）の Copilot 実験では、HTTPサーバをできるだけ速く書く課題で、Upwork で募った95人を無作為に分け、課題を完遂できた人どうしで比べるとAI利用群が55.8%速く終えた（95%区間は21〜89%と広い。2022年5〜6月、Copilot 一般提供の直前）4。整理すると、新しめ・定型的・単独のタスクでは大きく速くなり、熟練者が成熟コードの複雑な実タスクに向かうと、むしろ遅くなりうる。効果はタスクと人に強く依存する。

当の研究者が、自分の結論を更新した

ここで重んじたいのは、断定より更新だ。その意味で象徴的なのは、19%遅いを出した METR 自身が、2026年2月に設計を見直したことだ5。彼らは選択バイアスを見つけた——参加者の3〜5割が、「AIなしではやりたくない課題は提出しなかった」と答えていた。つまり測定に乗ったのはAIなしでも進めてよい課題に偏り、標本全体がAIの恩恵を最も受けにくい側へ寄っていた恐れがある。

第二コホートは57人・143リポジトリ・800超のタスクだが、推定は一つではない。新規に募った47人では遅れが約4%（区間は「15%の遅れ」から「9%の高速化」）まで縮む一方、原研究から続けて参加した10人では約18%の遅れ（区間は「38%の遅れ」から「9%の高速化」）で、19%からほとんど動いていない。縮んだのは、より小規模で新しいリポジトリを持つ新規参加者の側だ。METR 自身の見立ても「AIは生産性に寄与している」ではない。「2026年初頭の開発者は、2025年初頭の我々の推定と比べれば、より速くなっている可能性が高い」であり、比較対象は19%の遅れのほうだ。しかもその増分の大きさについては「ごく弱い証拠しかない」と付記している5。最初の衝撃的な数字は、消えたのではなく、測り直しの対象になった。

この食い違いをどう読むか

AI不利側・AI有利側、どちらにも留保がある。AI不利側：METR の原研究は熟練者×成熟コードという特定の条件で、標本も小さい（16人）1。なお選択バイアスが見つかったのは原研究ではなく続く実験のほうで、そこでの推定を下振れさせる要因とされている5。Perry らは2022年のモデルで、いまの支援ツールとは世代が違う2。AI有利側：Cui らの「+26%」は完了課題数という量の指標で、質（保守性・欠陥）は別に見る必要があり、Peng らの「+55.8%」は単純なラボ課題での上限に近い値だ34。どちらの側も、額面より狭く読むべきだ。

効果の符号は文脈で変わった。変わらなかったのは、認識のほうだ——認識を実測と突き合わせた二つの研究（METR・Perry ら）で、書き手の自己認識は実測と系統的にズレた。速さでも、安全性でも。揺れる結論のなかで、「体感で判断してはいけない」だけは持ち帰れる。

実務で何を見るか

同じ実験で計測された19%の遅れと、当人が感じた20%の短縮。この開きが、評価の設計をほぼ決めてしまう。

生成の速さや補完の便利さは、生産性の向上を意味するとは限らない——が、意味しないとも限らない。2022〜26年の測定は、その両方を、条件を変えて示した。効果は文脈しだいで変わりうる。そして自分の体感は、その効果を測る道具にならないことがある。他人の数字で決めず、自分の現場で測る。この食い違いが自分に効いているかどうかは、他人の現場の数字には書かれていない。

出典5件

  1. Joel Becker, Nate Rush, Elizabeth Barnes, David Rein, “Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity”（arXiv:2507.09089, 2025年7月12日公開／同月改訂・査読前, METR）。熟練オープンソース開発者16人が、平均5年関わる成熟リポジトリの実タスク246件を、AIあり／なしランダム割当で解いた。AI条件でタスク完了に19%長くかかった一方、開発者は事前に24%短縮を見込み、遅くなった後も20%短縮できたと感じた（専門家予測は38〜39%短縮）。主にCursor Pro・Claude 3.5/3.7 Sonnetを使用。標本が小さく特定条件下である点は著者も留保（5の更新も参照）。https://arxiv.org/abs/2507.09089 ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  2. Neil Perry, Megha Srivastava, Deepak Kumar, Dan Boneh, “Do Users Write More Insecure Code with AI Assistants?”（arXiv:2211.03622, 2022年11月公開／2023年改訂, ACM CCS 2023 採択）。参加者は47人（処置群33人・対照群14人）で、米国の2大学の学生に4社の実務者を加えた構成。AIコーディング支援（OpenAI codex-davinci-002）ありの参加者は、なしの群より有意に脆弱なコードを書いた一方、自分のコードはより安全だと信じる傾向があった。AIを鵜呑みにせずプロンプトを練り直すなど深く関与した参加者ほど脆弱性が少なかった。使用モデルは2022年時点で現行支援ツールとは世代が異なる点は割り引いて読む必要がある。https://arxiv.org/abs/2211.03622 ↩ ↩2 ↩3 ↩4 ↩5

  3. Zheyuan (Kevin) Cui, Mert Demirer, Sonia Jaffe, Leon Musolff, Sida Peng, Tobias Salz, “The Effects of Generative AI on High-Skilled Work: Evidence from Three Field Experiments with Software Developers”（Management Science, 2026年2月27日オンライン先行公開＝Articles in Advance。ワーキングペーパー版は2025年6月）。Microsoft・Accenture・匿名の大企業の3社・計4,867人の開発者で、AI補完（GitHub Copilot系）へのアクセスをランダム割当。完了課題が26.08%増加（標準誤差10.3%）。経験の浅い開発者ほど採用率・生産性の伸びが大きかった。指標は完了課題「数」であり、コードの質は別評価が要る。https://www.microsoft.com/en-us/research/publication/the-effects-of-generative-ai-on-high-skilled-work-evidence-from-three-field-experiments-with-software-developers/ ↩ ↩2 ↩3 ↩4

  4. Sida Peng, Eirini Kalliamvakou, Peter Cihon, Mert Demirer, “The Impact of AI on Developer Productivity: Evidence from GitHub Copilot”（arXiv:2302.06590, 2023年2月13日公開・ワーキングペーパー）。Upwork で募集した95人の開発者にJavaScriptでHTTPサーバをできるだけ速く実装させるランダム化実験（2022年5月15日〜6月20日＝Copilot 一般提供の直前）で、GitHub Copilot利用の処置群が対照群より55.8%速く完了（95%信頼区間21〜89%）。単純で自己完結的なラボ課題での値であり、実務の複雑なタスクへの外挿は慎重に。https://arxiv.org/abs/2302.06590 ↩ ↩2 ↩3 ↩4

  5. METR, “We are Changing our Developer Productivity Experiment Design”（metr.org ブログ, 2026年2月24日）。1の追跡で選択バイアスを発見——参加者の3〜5割が「AIなしではやりたくない課題は提出しなかった」と回答しており、測定対象のタスクがAIの恩恵を受けにくい側に偏っていた恐れ。第二コホートは57人・143リポジトリ・800超タスク。新規募集の47人では遅れ約4%（信頼区間−15%〜+9%）だが、原研究から継続の10人では約18%の遅れ（−38%〜+9%）で19%からほぼ不変。METR は新しい実験のデータを「現在の生産性効果の信頼できない指標」「中心推定は真の影響の悪い代理指標だろう」とし、推定の更新ではなく測定設計のやり直しを宣言している。見立ては「2026年初頭の開発者は2025年初頭の推定と比べればより速くなっている可能性が高い」だが、その増分には「ごく弱い証拠」しかないと付記。自己修正の一次記録。https://metr.org/blog/2026-02-24-uplift-update/ ↩ ↩2 ↩3 ↩4 ↩5 ↩6

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