週刊AI懐疑論 #1｜「生産性55%向上」は何を測ったのか

何が「生産性」なのかを問わずに、数字を受け取っている

「AIコーディングアシスタントで生産性が55%向上した」

GitHubが2022年に発表したこの数字は、その後のAI開発ツール議論のベースラインになった。McKinsey、Deloitte、Accenture——コンサル各社の調査もこれに続き、「生産性向上」を謳う数字が積み上がっていく。

問題は、これらの数字を引用する側が、測定設計を見ていないことだ。

参照: GitHub公式ブログ「Research: quantifying GitHub Copilot’s impact on developer productivity and happiness」（2022年9月）

GitHubの研究が対象としたのは、参加者がHTTPサーバーを実装するという孤立したタスクだ。「Copilotあり」と「Copilotなし」の条件でそれぞれ計測し、タスク完了時間に差が出た。この部分は事実だ。

だが、この実験が測っていないものがある。

「タスクを速く完了した」と「開発全体が速くなった」は別の話だ。計測されたのは前者であり、語られているのは後者だ。

AIが生成したコードは、レビューを省けない。むしろ、レビュー密度を上げないといけない。

自分で書いたコードは、書いた人間が意図を知っている。AIが生成したコードは、提案の根拠が不透明で、エッジケースへの対応が省かれていることが多い。

GitHub自身の別の調査では、Copilotで生成されたコードの「承認率（acceptance rate）」は26〜27%程度とされている。生成されたコードの4分の3は棄却か修正される。この棄却・修正にかかる工数は、生産性測定の分母に入っていない。

さらに言えば、承認されたコードが正しいとは限らない。承認は「問題ないと判断した」ことを意味するが、潜在的な問題が見逃されていた場合は後工程で顕在化する。

もう一つ見落とされているのは、「誰の生産性が上がっているか」という問いだ。

AIコーディングアシスタントは、既存のパターンを流暢に補完するのが得意だ。経験のある開発者ほど、この補完を正確に評価し、適切に取捨選択できる。

一方、経験の浅い開発者がAI生成コードを採用する際のリスクは、数字に現れにくい。「速く書けた」と本人は感じても、設計上の問題、セキュリティ上の見落とし、メンテナンスコストを増やす実装が含まれていた場合、そのコストは将来の誰かが払うことになる。

「生産性が上がった」という実感と、「品質のある成果が速く出た」は、検証方法が違う。

AIツールの評価に数字が出てきたとき、確認すべきなのは数字の大きさではなく、その数字が何を測ったかだ。

「55%向上」は嘘ではないかもしれない。ただ、その数字が指しているものは、私たちが日常的に「生産性」と呼んでいるものとは、ずれている可能性が高い。

週刊AI懐疑論は、こうした数字と語られ方のズレを毎週1本拾っていく連載だ。#1 はその出発点として、最も広く引用される根拠から始めた。