「AIで2倍速い」と答えた16人、実測すると19%遅かった
非営利研究機関のMETR（Model Evaluation and Threat Research）が2025年に発表した実験は、テックTwitterに静かな衝撃を与えた。
被験者は、自分が日常的に保守しているオープンソースプロジェクトのコアコントリビューター16人。
合計246件の実タスク、つまり実際のIssueやPull Requestを、彼らは2つの条件で解いた。
ひとつは、CursorとClaude 3.5 Sonnetを自由に使ってよい条件。
もうひとつは、AIコーディングツール完全禁止の条件。
実験前の予測は「AIで24%速くなる」。
実験後の自己評価は「AIで20%速くなった」。
ところが実測値は、AIあり群が「19%遅い」だった。
しかも興味深いのは、結果を提示された後でさえ、被験者の多くが「いや、それでも自分はAIで速くなっているはずだ」と信じ続けたことだ。
研究者はこれを「メタ認知のバグ」と呼んだ。
時計の針はウソをつかないが、人間の体感は平気でウソをつく、という事実が、データで示された瞬間だった。
自己評価との40ポイントギャップ。なぜ「速くなった」と錯覚するのか
なぜここまで盛大な勘違いが起きるのか。
論文では、3つの認知バイアスが指摘されている。
第一に、流暢性錯覚（Fluency Illusion）。
AIが提示するコードは、文法的に整っていて読みやすい。
人間の脳は、読みやすいテキストを処理する時間を「短い」と錯覚する性質がある。
第二に、待機時間の見えない蒸発。
LLMが応答するまでの十数秒、エンジニアはタブを切り替え、Slackを見て、戻ってきた時には集中が途切れている。
この「裏で抜けている時間」は、本人の主観時間にはカウントされない。
第三に、修正の自己責任化。
AIの提案を受けてバグが入った場合、人間はそれを「AIが書いたコードを直している」ではなく、「自分のコードをデバッグしている」と認識する。
つまり、ロスがロスとして記憶されない。
ベテランほど誤差が大きい、という現象は、ダニング・クルーガー効果の逆ではない。
むしろ「自分の手の内には誰よりも詳しい」という確信が、計測なしの自己評価を強化してしまう構造だ。
熟達はメタ認知を磨くと信じられてきたが、AIという新しい変数が入った瞬間、その熟達はむしろ盲点になる。
遅くなる5つの理由 — プロンプト、レビュー、修正、コンテキスト切替、過信
AIで時間が溶ける経路は、論文の中で5つに分解されている。
ひとつめは、プロンプト記述コスト。
「いい指示」を書くために、人は要件を一度文章化する必要がある。
これは思考を整理する効用もあるが、純粋な作業時間としてはオーバーヘッドだ。
ふたつめは、生成コードの全行レビュー。
AIは自信満々に「それらしいコード」を返してくるが、ハルシネーションは避けられない。
特にライブラリのAPI名や引数順序は、もっともらしく間違えてくる頻出領域だ。
みっつめは、既存コードベースの慣習との衝突。
成熟したプロジェクトには、ファイル分割の流儀、命名規則、既存ユーティリティの存在がある。
AIはそれを知らないため、車輪の再発明や、レビューで弾かれる実装を提案しやすい。
よっつめは、待機時間中のコンテキストスイッチング。
10秒待つくらいなら、Slackを開く、と人は考える。
しかし戻ってきたとき、もう一度「自分は何を解いていたか」を思い出すコストが発生する。
いつつめは、過信による検証不足。
「AIが書いたから」という前提は、テストを書く動機を弱める。
そして数日後、本番環境で予期しないエッジケースに殴られる。
「AI使えば速い」が成立する条件 — 経験・タスク・規模で逆転する境界
ただし、この実験結果を「AIコーディング不要論」に直結させるのは、雑な解釈だ。
被験者は「自分が長年メンテしているコードベースの専門家」だった。
裏を返せば、彼らは既にそのコードを脳内モデルに圧縮しており、ゼロから書く時間そのものが極小化されていた、ということでもある。
GitHub社が2023年に発表した実験では、別の条件で逆の結果が出ている。
タスクをHTTPサーバー実装に統一し、被験者にCopilotを使わせた群は、使わなかった群より55.8%速く完了した。
両者の違いは、コードベースの成熟度と、被験者のドメイン熟達度にある。
| 条件 | AIで速くなる傾向 | AIで遅くなる傾向 |
|---|---|---|
| 経験年数 | 1〜3年 | 5年以上の専門家 |
| タスク種別 | 新規プロジェクト・定型実装 | 成熟コードベースのバグ修正 |
| コードベース規模 | 1万行以下 | 10万行以上 |
| ドメイン熟達 | 自分が初めて触る分野 | 自分が長年保守してきた領域 |
| テスト要件 | プロトタイプ・実験コード | 本番運用・厳格なレビュー |
ジュニアの底上げと、シニアの足枷を同時に果たす。
それがAIコーディングの、最も誤解されている側面かもしれない。
「AIで生産性が上がる」と語る企業の多くは、無意識に前者の効用だけを見ている。
しかし、コードベースが10万行を超え、レビュアーがチームの古参になった瞬間、効果は逆転しはじめる。
それでもAIコーディングを手放せない理由 — 認知負荷の劇的な低下
ここまで読んで「ではAIを切れば良い」と短絡するのは、もう一段早計だ。
論文には、計測されなかった、しかし被験者全員が口を揃えた指標がひとつあった。
「速くはなっていないかもしれない。でも、明らかに楽になった」
これである。
5時間のコーディングセッションを終えた直後、AIなし群は精神的に消耗しきっていた。
AIあり群は、同じ5時間の後でも、まだ別のタスクに着手できる余力を残していた。
認知負荷の低下は、瞬間速度には現れない。 しかし、一日の終わりに「もう一仕事できる」状態が残るかどうかは、週単位、月単位で生産性を変える。
つまりAIコーディングが提供している本当の価値は、瞬間的な速度ではなく、持続可能な集中力である可能性が高い。
19%遅くなったとしても、その日の最後に余力が残るなら、夜のうちにもう1コミットできる。
それを30日続ければ、月間アウトプットは19%の損失を吸収して、なお黒字になる計算もできる。
ベテランほど「自分は速くなっている」と感じる錯覚は、もしかすると錯覚ではなく、別の指標を体感で捉えているのかもしれない。
時計が測れない疲労、その日の最後に残る余力、翌朝の「もう一度開く気力」。
これらは生産性の定義からこぼれ落ちる、しかし現場では決定的な変数だ。
私たちはAIコーディングを「速度の道具」として導入し、いまその看板を外そうとしている。
新しい看板は、まだ誰も書いていない。
あなたの現場では、AIは何を代替し、何を引き受けているだろうか。
時計の針が止まる場所と、心の余白が広がる場所は、本当に同じ場所だろうか。
出典・参考
- METR. "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity." 2025.
- Peng, Sida, et al. "The Impact of AI on Developer Productivity: Evidence from GitHub Copilot." GitHub / arXiv:2302.06590. 2023.
- Cursor / Anthropic Claude 3.5 Sonnet — 実験で使用されたツールセット
