現実を知る

「AIで速くなった」は本当か——METRの実験が暴いた19%遅くなる現実

ランダム化比較試験で測定したら、経験豊富な開発者はAIを使うと19%遅くなっていた。「速くなった気がする」という体感がなぜ嘘をつくのか。

公開: 2026年2月26日約12分

「AIを使えば開発が速くなる」——その研究に参加した開発者たちは、自分が24%速くなると予測していた。実験が終わったあと、20%速くなったと感じた。だが客観的な計測では、19%遅くなっていた。


研究を読む前に知っておくこと

ランダム化比較試験(RCT)とは

医薬品の治験と同じ手法だと思えばいい。薬の効果を調べるとき、「薬を飲んだ人」と「飲まなかった人」にランダムに分けて比較する。「飲もうと思った元気な人」だけで測ると、薬の効果なのか元々の体力差なのかわからなくなる。ランダムに割り当てることで、それ以外の要因を排除できる。

AI生産性研究の多くは、このランダム割り当てをしていない。「AIを使いたい人」が「AIが得意なタスク」で測ると、当然よく見える数字が出る。RCTはその選択バイアスを排除する。

METRとはどんな組織か

METR(Model Evaluation and Threat Research)は、AIモデルの能力評価を専門とする独立した非営利研究機関だ。政府や企業とは独立した立場で動いており、資金提供者の利益のために数字を作る動機がない。今回の研究は、AIが実際の開発作業でどれほどの効果をもたらすかを客観的に測るために設計された。


実験の設計と結果

2025年2月から6月にかけて行われた実験は、これまでのAI生産性研究の中で最も厳格な設計のひとつだ(2025年7月10日公開)。

参加者の条件:

  • 経験豊富なOSSコントリビューター16名
  • 平均5年以上の開発経験、1,500コミット以上
  • 対象リポジトリの平均スター数: 22,000以上
  • 平均コード行数: 100万行以上

つまり「そのコードベースを最もよく知っている本人」が、自分の庭でテストを受けた。使用したAIツールはCursor Pro(Claude 3.5/3.7 Sonnet)。246タスク(1タスク平均2時間)を「AIあり」と「AIなし」にランダムに割り当て、所要時間を記録した。

結果: AIありの条件でタスク完了時間が19%長くなった。

この研究の文脈は重要だ。「経験豊富な開発者が、熟知したリポジトリで、普段のタスクを実行した」場合の結果だ。新人が未知のコードベースを探索する場合や、全く新規の機能実装では結果が異なる可能性がある。

Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivitymetr.org

予測・体感・現実、三つのズレ

この研究が特に注目される理由は、主観的な認識と客観的な測定値の乖離を同時に記録している点だ。

❌ 参加者が信じていたこと(主観):

事前予測:   +24%速くなるはず
事後体感:   +20%速くなったと感じた

✅ 実際に計測されたこと:

客観測定:   -19%遅くなっていた
           (= 同じ作業に1.24倍の時間がかかっていた)

なぜここまでの乖離が生まれるのか。ソフトウェアコンサルタントのMike Judgeは「スロットマシン」で説明している。スロットを2時間回して3回ジャックポットが出たとする。記憶に残るのはジャックポットの瞬間だ。2時間の損失は、勝ちの興奮の中に消える。AIも同じだ。AIが一発でドンピシャの解答を出した瞬間だけが記憶に残り、生成コードを読んで理解して修正した時間は記憶から消える。


なぜ遅くなるのか

「19%遅い」という結果は「AIが無能だから」という話ではない。構造的なメカニズムがある。

AI提案の採用率は44%未満

参加者がAIの提案をそのまま使ったのは全提案の半分以下だった。提案を読み、理解し、問題がないか確認し、修正して使う。この確認コストが積み重なる。

熟練者ほどこのコストが大きくなる。自分のコードベースをよく知っているから、「これは違う」「ここは自分のアーキテクチャと合わない」という判断が頻繁に入る。10年の大工が見習いのアシスタントと組んで働くようなものだ。一部の作業は分担できる。でも「ここはどうする?」という確認作業が増えて、トータルの進行が遅れることがある。

コンテキストスイッチのコスト

AIとの対話は思考の流れを切断する。「どう実装するか」を考えているところに「AIに聞く」アクションを挟むと、集中状態から外れる。AIの返答を読み、意図を汲み取り、自分の作業に戻る。この往復が積み重なると、表には出ないコストになる。

「関係ない箇所も変える」問題

参加者から多く挙がったのが「関係ない箇所を変えられて、どこが変わったか探すのに時間がかかった」という問題だ。AIは指示された機能を実装しながら、ついでに周辺をリファクタリングしようとする。変更範囲が広がるほど、確認コストが増える。


個人でコイン投げ実験をした開発者

METRの結果と独立した実験が一致している。

シニア開発者のMike Judgeは、METRの手法を個人で再現した。6週間にわたって、タスクを始めるたびにコインを投げた。表が出たらAI(Cursor)を使い、裏が出たら使わない。完全にランダムに割り当てて所要時間を記録し続けた。

結果: 中央値で21%遅くなった。METRの19%と一致する。彼はこう書いている。「スロットマシンに2時間使っても、勝ったときしか記憶に残らない。AIも同じだ。上手くいった瞬間だけが記憶に残り、それが体感を形成する。でも計測すると別の結果が出る」

Where's the Shovelware? Why AI Coding Claims Don't Add Up78% of developers claim AI makes them more productive. 14% say it's a 10x improvement. So where's the flood of new software? Turns out those productivity claims are bullshit.mikelovesrobots.substack.com

ベンダーの「55%速い」との違いはどこから来るのか

GitHub Copilotは「55%速くなる」というデータを発表している。METRの「19%遅い」と真逆だ。どちらかが嘘をついているのではなく、測り方が根本的に違う。

ベンダー調査(GitHub等)
参加者が自己報告(主観)
短時間・独立タスクで測定
参加者自身のコードベースではない
→ 55%速い
METR(独立研究)
客観的な時間計測
実際の業務タスク・本人のリポジトリ
ランダム割り当てでバイアス排除
→ 19%遅い

Googleナビが「目的地まで3時間」と言っているのに、「自分なら2時間半で行ける」と思い込む状況に似ている。自分の思い込みが、測定値を歪める。

Google の DORA(DevOps Research and Assessment)が 2024年に 39,000人以上のプロフェッショナルを対象に行った調査でも、同じパターンが見えた。AI採用が25%増えた組織では配信速度が1.5%低下し、配信安定性が7.2%低下していた。多くの開発者がAIを使っているにもかかわらず、チームの配信パフォーマンスは改善されていない。主観と客観の乖離は、METRだけで見つかった現象ではない。

DORA | Accelerate State of DevOps Report 2024DORA is a long running research program that seeks to understand the capabilities that drive software delivery and operations performance. DORA helps teams apply those capabilities, leading to better organizational performance.dora.dev

コード品質の面でも同様の傾向がある。GitClearが2億1100万行のコード変更を分析した結果(2020〜2024年)、コードチャーン(2週間以内に修正されるコードの割合)が 2020年の3.1%から 2024年には推定5.7%に増加したと報告している。コードの重複ブロックは4倍に増えた。コミット数は増えているが、内容の密度は薄くなっている。

gitclear.comgitclear.com

2026年2月の最新情報

METRは 2025年8月から規模を拡大した新実験を進めている。参加者57人(うち10人は前回参加者)、リポジトリ143件、タスク800以上。しかしここで予想外の問題が起きた。

参加者の30〜50%が「AIなしで作業したくない」と拒否し、そのタスクをスキップするようになったのだ。これはデータとしては深刻な問題だが、一つの事実として示唆に富む。AIツールを日常的に使う開発者の間で、「AIなしの状態」が不自然に感じるほど習慣化が進んでいる。

暫定結果は前回参加者グループで-18%(95%信頼区間: -38%〜+9%)、新規参加者グループで-4%。前者は前回の-19%とほぼ一致する。METRは設計を変更し、引き続き研究を続けることを発表した。「現時点で確定的な結論を出すのは難しい」という誠実な立場を取っている。この誠実さが、METRの研究を参照する価値がある理由の一つでもある。

We are Changing our Developer Productivity Experiment Designmetr.org

それでも69%が使い続ける

実験終了後、参加者の69%はCursorを使い続けると回答した。「AIで遅くなる」とわかっていても、だ。

専門家のSean Goedeckeはこう分析している。「経験豊富な開発者は自分の得意なリポジトリではすでに非常に速い。AIの本当の価値は、コンフォートゾーン外のタスク——慣れていない言語、知らないAPIの探索——で現れる可能性がある」

英語が流暢な人が機械翻訳を使ったら、誤訳の修正にかえって時間がかかる。でも日本語しか話せない人には機械翻訳は圧倒的に助かる。使う人の文脈次第で、AIの効果はまったく変わる。

また「認知負荷が下がる」という効果もある。精神的なエネルギーを使わずに作業を続けられる感覚、集中力が落ちているときでも前に進める感覚。これは「速さ」の指標には出てこないが、開発者の体験として実在する。

「速さ以外の価値」は確かにある。問題は、それをベンダーの「55%速くなる」という主張と混同することだ。認知負荷の軽減と、タスク完了時間の短縮は別の話だ。

METR's AI productivity study is really goodseangoedecke.com

自分で計測する

信じるべきデータは一つしかない。自分のタスクで計測したデータだ。

ベンダーのデータは彼らが得意な条件で測ったものだ。METRのデータは、経験豊富な開発者が熟知したリポジトリで作業した場合のものだ。あなたの条件とは違う可能性が高い。

方法はシンプルだ。

❌ 体感だけで判断する場合:

「AIを使ったら速くなった気がする」
→ 記憶はジャックポットしか覚えていない
→ スロットで使った時間と損失は見えていない
→ 根拠のない確信だけが残る

✅ 計測してから判断する場合:

# タスク開始時に記録(AIあり/なし、タスク種別、開始時刻)
echo "$(date '+%Y-%m-%d %H:%M'),START,ai,バグ修正" >> ~/ai_log.csv

# タスク完了時に記録(所要時間を分単位で追記)
echo "$(date '+%Y-%m-%d %H:%M'),END,ai,バグ修正,45" >> ~/ai_log.csv

1週間でいい。同種のタスクを「AIあり」と「AIなし」に交互に割り当てて記録する。スプレッドシートに転記して比較する。それだけで「自分にとってAIは何分の差をもたらしているか」がわかる。

「速くなっている」という結果が出れば、根拠を持って使い続ければいい。「遅くなっている」なら、使い方を変えるか、特定のタスクに限定する判断ができる。

ベンダーが言う「速くなる」は商売上の主張だ。研究機関の数字は特定の条件下での結果だ。あなたの仕事に当てはまるかは、あなたが計測して初めてわかる。


「AIで24%速くなる」と予測した人が、計測したら19%遅くなっていた。その事実は変わらない。ただ、それが全員に当てはまるとも限らない。ジャックポットの記憶に引きずられず、自分で計測して、自分の答えを出す。それが今できる一番まともな判断だ。