その見積もり、
見えている景色が違うだけかもしれない

「AIを導入するんだから、もっと速く・安くできますよね」

見積もりの場や経営会議で、こう口にしたことはないだろうか。あるいは、現場から「思ったより時間がかかっています」と報告を受けて、「AI使ってるのに、なぜ?」と感じたことは。

もしあるなら、一度立ち止まってみてほしい。その「速くなるはず」という前提は、実は外れやすい予測のひとつだからだ。今回は「AI駆動開発の落とし穴」シリーズの第1回として、発注する側・意思決定する側が陥りやすい思い込みについて書く。

もちろん、AIが効果を発揮する場面は数多くある。要件が明確な新規開発や定型的な実装では、高い生産性向上が報告されている。本稿で伝えたいのは「AIは遅い」ということではなく、「条件を揃えずに数字だけを流用すると見積もりを誤る」という点だ。

現場のエンジニアに、AI導入についての不安を聞くと、「無理なペースを求められている」といった声が出ることがある。一方、管理職の立場で同じ質問をされたとき、「特に問題ないと思う」と答えていないだろうか。

Harness社の調査（MIT Sloan Management Reviewに掲載）では、まさにこの構図が確認されている。AI主導の生産性データがどう使われるかについて、現場の開発者は不安を強めている一方、管理職はその不安を持つ割合が現場よりも著しく低い。実際、回答者の46%が無理なペースで働くことへのプレッシャーを感じており、同じ割合がプライバシーや監視への懸念を挙げている。

これは、経営層が現場を軽視しているという話ではない。単純に、現場が日々こなしている「プロンプトを練る時間」「AIの出力を確認する手間」「手戻り」を、発注する側は直接は体感していない。体感していないものは、心配のしようがない。能力や意識の差ではなく、見ている景色が違うだけなのだ。

見積もりの場で「AIを使うから速く・安くできる」と考えるとき、その根拠の多くはベンダーの実績データやPoC（小規模検証）の結果だろう。実際、GitHub・MIT・Microsoftの研究者による統制実験では、HTTPサーバー構築というタスクで55%の高速化が確認されており、これは架空の数字ではない。

ただし、この検証は要件が明確で、依存関係が少なく、担当者も1人で完結する、いわば理想的な条件で行われている。一方、非営利AI評価機関METRが2025年に行った実験では、経験豊富なOSS開発者16人が、依存関係の多い大規模な既存コードベースで246件の実タスクに取り組んだところ、AIを使うと完了時間はむしろ19%増加した。開発者自身でさえ「20%短縮できた」と感じていたが、実際は逆だった。なお、METRは2026年2月に追跡調査の結果を公表しており、対象者や条件によって速度低下の幅は-18%〜+9%程度までばらつくことを明らかにしている。数値の幅は状況によって変わるが、「体感と実測がズレる」という傾向自体は変わっていない。

条件による差は、失敗の分析にも表れている。Gartnerが782人のIT運用リーダーに行った調査では、AI導入がうまくいかなかった組織のうち57%が、その原因を「期待しすぎた、急ぎすぎたこと」だと回答している。Deloitteが経営層1,854人に行った調査でも、AI投資の多くが7〜12ヶ月ほどでの投資回収を期待される一方、実際に満足のいく成果が出るまでには平均で2〜4年かかっていた。12ヶ月以内にリターンを得られたと答えた組織はわずか6%だ。

ベンダーの実績もPoCの結果も、決して嘘ではない。ただし、そこで測られているのは、特定の条件下での効果だ。GartnerやDeloitteの調査が示しているのも、条件や期待値を見誤ると、AI導入の成果は想定どおりに出にくいということだ。

「コーディングが40%速くなるなら、プロジェクト全体も40%速くなるはず」——この掛け算も、そのまま成立するとは限らない。

理由は単純で、コーディングはプロジェクト全体の一部の工程でしかないからだ。調査によって幅はあるものの、ソフトウェア開発ライフサイクル全体に占めるコーディング(新規コード執筆)の時間は1〜4割程度で、残りはレビュー・テスト・調整・保守といった工程が占めるとする複数の調査結果がある。仮にコーディングにかかる時間が大幅に短縮されたとしても、全体で短縮できる割合には自ずと上限がある。

さらに、コーディングが速くなった分、他の工程にしわ寄せが行くという報告もある。開発者個人のタスクレベルでは20〜40%の高速化が見られても、それが組織全体の納期短縮には結びつかず、実際の組織全体でのROIは5〜15%程度にとどまるという分析がある。原因として、AIが生成するコード量が増えることで、プルリクエストのレビュー時間が平均91%増加するなど、後工程がボトルネックになる現象が指摘されている。

工程単体・全体の数字のズレとは別に、AI導入によって新たに生まれた作業もある。

プロンプトを設計する時間は、AI導入前には存在しなかった新しい作業だ。しかも一度で済むとは限らず、意図した結果が出るまで指示と確認を何度も往復させることになる。AIが出したコードのレビューも、「経験豊富なエンジニアならこう書いたか」という視点での確認が別途必要になり、以前より重くなっているという指摘もある。人同士のコミュニケーションも、単純に減るわけではない。「なぜこのような実装になっているのか」を人同士で確認し合う手間など、姿を変えて増えている部分もある。

数字の「量」だけを見ていると、こうした変化も見落としやすい。リリース頻度だけをKPIにすると、品質コストを見落とす。GoogleのDORAレポートでは、AI導入がスループット（こなせる量）には良い影響を与える一方、デリバリーの安定性には悪い影響を与える、という結果が続けて報告されている。

現場に「もっと効率化しろ」と求める前に、発注する側からできることがある。

AIによって、コードを書くスピードは確かに速くなりました。しかし、それがそのままプロジェクト全体の納期短縮やコスト削減につながるとは限りません。

本記事で紹介したように、AIの効果はどのような条件で測られた数字なのかによって大きく変わります。また、レビューや品質確認、プロンプト設計など、AI導入によって新たに発生するコストもあります。

だからこそ、発注者が確認すべきなのは「AIを使っているかどうか」ではありません。

こうした視点を持つことで、AI導入への期待と現実のギャップを小さくし、プロジェクトの成功確率を高めることができます。

AIは、プロジェクトを成功させる魔法ではありません。

その問いを持ち続けることが、AI時代の発注者に最も求められる視点ではないでしょうか。