AIで開発は速くなった？生産性の実感と実測のずれ

AIが数秒でコードを出してくれる。以前なら調べていた実装方法も、その場で提案される。こうした体験が重なると、「開発がかなり速くなった」と感じるのは自然です。

ところが、熟練開発者を対象にした実験では、本人たちはAIで速くなったと感じていた一方、実際の完了時間は19％長くなっていました。

AIで作業が進んでいる感覚と、仕事が早く終わることは、必ずしも一致しません。 この結果はAIを使わない理由というより、自社の生産性向上を体感だけで判断していないかを考える材料になります。

AIで開発生産性は上がる？まず「何が速くなったか」を分ける

開発生産性を、コードの生成速度だけで捉えると実態を見誤りやすくなります。生成されたコードを読み、既存の仕様に合わせて直し、テストして利用できる状態にするまでが仕事だからです。

例えば、実装に8時間、修正・検証に2時間かかっていた仕事が、実装3時間、修正・検証7時間になったとします。これは説明用の仮数値ですが、実装は大きく短縮しても合計時間は変わりません。

逆に、合計時間は同じでも、以前は作れなかったテストや機能を追加できたなら、得られた価値は増えている場合があります。時間、成果の範囲、品質を合わせて見ることが、効果を読み取る起点です。

METRが2025年7月に公表した研究は、長年関わっている大規模なオープンソースの開発で、AI利用の有無を課題ごとに無作為に割り当てた実験です。16人が246件に取り組み、当時のCursor ProとClaude 3.5／3.7 Sonnetなどを使いました。

重要なのは、AIに不慣れな人の感想だけを集めた結果ではなく、同じ開発者が普段の課題に取り組む中で、実感と実測がずれたことです。

この研究は2025年前半のツールと特定の開発環境を対象にしています。現在のすべてのAI開発が19％遅くなる、という意味ではありません。

研究では、複雑なコード、文書化されていない要求、担当者の高い習熟、AIの出力の信頼性などが、速度低下に寄与したと分析しています。各要因の影響を個別に実験で分離した結論ではありませんが、画面記録やインタビュー等から検討されています。

既存の受注システムへ割引機能を追加する説明例で考えてみます。割引計算の式が正しくても、顧客ごとの特別価格、返品、請求、連携先との整合が必要です。

担当者ならすぐ分かる例外をAIへ説明し、提案を読み、過去の実装方針に合わせて修正する。こうした時間が、コードを作る時間の短縮を上回ることがあります。

研究は認識のずれを実測していますが、心理的な理由を一つに確定したわけではありません。記事として考えられるのは、すぐにコードが出る進展の分かりやすさに比べ、細かな確認・修正の積み重ねが意識に残りにくい、という説明です。

また、AIを使うことで作業が楽になったり、学習の価値を感じたりすることと、完了時間が短くなることは別です。使い続けたいと思う理由が、すべて時間短縮とは限りません。

METRは後続の実験について、2026年2月に説明を更新しています。元の参加者の一部では完了時間が18％短縮、新規参加者では4％短縮という推定になりました。ただし、どちらも統計的な不確実性が大きく、効果の大きさを確かな数字として使うには問題があるとしています。

特に、AIなしでは作業したくない人が参加しない、AIが得意そうな課題を実験に出さないといった選別が生じました。複数のAIエージェントを動かし、その間に別の仕事をする場合の時間測定も難しくなっています。

つまり、古い結果をもとに「AIは遅い」と決めるのも、使いたい人が増えたことだけで「必ず速い」と決めるのも適切ではありません。ツールが変わり、仕事の進め方も変わるため、自分たちの成果を確かめる意味が残ります。

厳密な研究を社内で再現する必要はありません。例えば一つのチームで、似た種類の改修について、着手から確認完了までを振り返るだけでも、コード生成の印象とは違う部分が見えます。

見たいこと	確認の例
仕事が終わるまでの時間	指示、生成、読解、修正、テストまで含める
完成の基準	テスト、文書、レビューなどを途中で緩めていないか
得られた成果	時間が同じでも、機能・テストなどが増えているか
使う課題の偏り	AI向きの仕事だけと、難しい既存改修を混ぜていないか