AI協働

AIで開発は本当に速くなるのか——実測は食い違い、『体感』は測定とズレる

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

🤖 AIが下書き・人間が編集

要点： AIコーディング支援は開発を速くする——多くの人がそう体感している。だが「体感」と「実測」は、しばしばズレる。熟練開発者を対象にした厳密な実験（METR）では、AIを使ったほうがむしろ19%遅かった。しかも当の開発者は、遅くなったその作業を「約20%速くなった」と感じていた¹。似たズレは安全性でも起きる。別の実験では、AI支援を使った人はより脆弱なコードを書きながら、より安全に書けたと信じていた²。——ここで話が終われば「AIは役に立たない」だが、それは早計だ。現場の大規模なランダム化比較試験は逆を測る。3社4,867人では完了課題が+26%³、ラボの課題では Copilot 利用が+55.8%速い⁴。そして当の METR 自身が、2026年に選択バイアスを見つけて推定を中立〜プラスへ見直した⁵。効果は一枚岩ではない——誰が・どのコードで使うかで、速くも遅くもなる。確かなのは一つ、「速くなった気がする」は当てにならないということだ。

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

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

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

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

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

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

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

面白いのは、AIを鵜呑みにせず、プロンプトを練り直したり温度を調整したりして深く関与した人ほど、脆弱性が少なかった点だ²。道具そのものより、任せ方が結果を分けた。ここでも構図は同じ——危険に近づいたのに、安全になったと感じる。

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

ここまでなら「AIは開発者を惑わせるだけ」に傾くが、公平に見ればそれは一面だ。実際の職場での大規模実験は、明確な向上を測っている。Cui・Demirer ら（Management Science 2025）は、Microsoft・Accenture・匿名の大企業の3社・計4,867人の開発者で、AI補完（GitHub Copilot 系）へのアクセスをランダムに割り当てる実験を行った³。結果は、完了課題が26.08%増加（標準誤差10.3%）。しかも経験の浅い開発者ほど採用率も伸びも大きく、道具の恩恵が誰に厚いかは人によって違うと示した。

さかのぼれば、Peng ら（2023）の Copilot 実験では、HTTPサーバをできるだけ速く書く課題で、AI利用群が55.8%速く完了した⁴。整理すると、新しめ・定型的・単独のタスクでは大きく速くなり、熟練者が成熟コードの複雑な実タスクに向かうと、むしろ遅くなりうる。効果はタスクと人に強く依存する。

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

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

より大きな追試コホート（57人・800超のタスク）では、遅れは約4%（信頼区間は−15%〜+9%）まで縮み、本当の高速化と両立する幅になった。METR の更新後の見立ては「2026年初頭では、AIはおおむねAI生産性に寄与しているだろう」だ⁵。最初の衝撃的な数字は、消えたのではなく、文脈の中に置き直された。

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

鵜呑みにする前の留保を、両側に置く。AI不利側：METR の原研究は熟練者×成熟コードという特定の条件で、標本も小さく（16人）、後に選択バイアスが見つかった¹⁵。Perry らは2022年のモデルで、いまの支援ツールとは世代が違う²。AI有利側：Cui らの「+26%」は完了課題数という量の指標で、質（保守性・欠陥）は別に見る必要があり、Peng らの「+55.8%」は単純なラボ課題での上限に近い値だ³⁴。どちらの側も、額面より狭く読むべきだ。

それでも、独立に効く教訓が一つ残る。四つの研究に共通して、開発者の自己認識は実測と系統的にズレた——速さでも、安全性でも。効果の符号は文脈で変わるが、「体感で判断してはいけない」ことだけは、どの結果とも矛盾しない。

実務で何を見るか

AIコーディングを導入する側なら、勘所は絞れる。

• 体感で評価しない。 「速くなった気がする」は、遅くなっていても出る¹。満足度アンケートではなく、完了時間や課題数を実測する。
• 自分の文脈で測る。 効果はタスクと熟練度で変わる。熟練者×成熟コードでは慎重に、新規・定型タスクでは効きやすい¹³。他人のRCTを自社の答えにしない。
• 速さと質を分けて見る。 完了が速い／多いことと、コードが安全・保守可能なことは別だ。脆弱性は増えうる——鵜呑みにせず関与した人ほど安全だった²。
• 結論を更新する構えを持つ。 モデルも人も変わる。METR のように、バイアスを見つけたら数字を書き直す姿勢そのものを、評価プロセスに組み込む⁵。

生成の速さや補完の便利さは、生産性の向上を意味するとは限らない——が、意味しないとも限らない。2022〜26年の測定は、その両方を、条件を変えて示した。評価的な主張として要点はこうだ：AIコーディングの効果は文脈しだいで変わりうるし、自分の体感が当てにならないこともある。だからこそ、他人の数字で決めず、自分の現場で測る——それが、この食い違いを実務の判断に落とすための第一歩になる。

この記事はAIが下書きし、人間が編集・公開しています。