生成AIで開発工数は本当に減るのか？工数見積と新しいコストモデル

はじめに

生成AIを使うと開発は本当に速くなるのでしょうか。そして、その変化を見積にどう反映すればよいのでしょうか。この記事では、生成AIが工数に与える影響と工程ごとの違いを整理します。あわせて、AI開発時代に向けて提案されている新しい見積モデルも紹介します。

研究データで見る、AIが開発の成果に与える影響

先に結論を述べると、AIで「コードを書く」作業は大きく速くなる一方、レビューやリリースまで含めた開発全体の成果は、同じ割合では増えません。工数の一部が、レビューや品質の維持に移っていると考えられます。

ここからは、その根拠を順に見ていきます。取り上げるのは、2025〜2026年に公開された研究です。

研究結果①コミットが240%増えても、リリースは30%増にとどまる

GitHub開発者50万人超を分析した研究では、自律型コーディングエージェントを使い始めた開発者のコミット数は累積で約240%増えましたが、リリース数の増加は約30%にとどまりました¹。

研究結果②レビュー時間は91%増え、PRも大きくなる

開発組織向けの分析プラットフォームを提供するFaros AIが1万人超の開発者のデータを分析したところ、AIをよく使うチームではマージされたPRが98%増えた一方、PRのレビュー時間は91%、PRの平均サイズは154%増えていました。そして、会社全体で見ると、AIの活用が進んでいる会社ほど開発の成果が良くなっている、という関係は確認できませんでした²。

研究結果③効果の大きさは開発者の経験によって変わる

Microsoft・Accentureなど3社の開発者4,867人を対象に、AIのコード補完ツールを使えるグループと使えないグループを無作為に分けて比べた実験があります。ツールを使えるグループでは完了タスク数が平均26%増え、特に経験の浅い開発者ほど効果が大きくなっていました³。

工程別に見る工数の変化

工程によって生成AIの影響は大きく異なります。

工程	工数が減りやすい作業	工数が増えやすい・減りにくい作業
要件定義	・議事録の要約 ・要件の抜け漏れチェック ・既存資料からの要件抽出	・関係者との合意形成 ・業務判断 ・優先順位付け
設計	・設計書のひな形作成 ・既存コードからの設計情報の復元（リバースエンジニアリング）	・アーキテクチャ判断 ・非機能要件の検討 ・AIが出した設計の妥当性確認
実装	・定型的なコード ・新規の小規模機能 ・コード変換	・大規模・複雑な既存コードの改修 ・AI生成コードの手直し
テスト	・テストケース ・テストデータ ・テストコードの生成	・AI生成コードの不具合の検出 ・テスト結果の妥当性判断
レビュー	・静的な指摘の自動化（AIレビュー）	・PRの件数 ・サイズ増加に伴うレビュー負荷
保守	・影響調査 ・ドキュメント整備 ・定型的な改修	・AIが生成したコードの理解と品質維持

工数は「消える」のではなく「移動する」

見積の観点で最も重要なのは、工数が消えるのではなく別の工程に移るという点です。このことを、開発者の「実感」を聞いた調査と、実際の記録を「実測」した調査の2つから見てみます。

実感：開発者は設計・実装で大きな効果を感じている

Gurgulらは、文献レビューと開発者65人へのアンケートを組み合わせて、生成AIの効果を工程ごとに調べました。アンケートは2025年12月末から2026年1月にかけて、ドイツ語圏を中心に実施されています。生成AIの効果を感じる工程（複数回答）は、次のとおりでした⁴。

工程	効果を感じると答えた割合
設計・実装	85%
運用・保守	75%
要件分析	43%
テスト・統合	37%
計画	18%

実測：書く時間は減ったが、指示・待ち・確認の時間が増えた

AI研究機関のMETRは、経験豊富なOSS開発者16人を対象とした小規模な比較実験で、作業中の画面録画から時間の内訳を記録しました⁵。 コードを書く時間や情報を調べる時間の割合が減る一方で、プロンプトを書く時間、AIの出力を待つ時間、AIの出力をレビューする時間が新たに生まれています。

図1：AI利用可（AI-allowed）とAI利用不可（AI-disallowed）の作業時間の内訳（2025年初頭のAIを対象とした実験）
出典：Becker, J., Rush, N., Barnes, E., & Rein, D. (2025). “Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity.” arXiv:2507.09089, Figure 6.（CC BY 4.0、原図をそのまま掲載。原図（arXivの論文ページ））

従来の見積手法の限界

従来の見積手法は、それぞれ次のような前提に立っています。生成AIの普及によって、その前提が崩れつつあります。

手法	概要	生成AI時代に生じる課題
人月（工数積み上げ）	WBSの各作業に必要な人数×期間を積み上げる	作業時間の大部分をAIが担うと、「人の作業時間」が価値や規模を表さなくなる
ファンクションポイント法	画面・帳票・データなどの機能の数と複雑さから規模を測る	規模は測れても、規模から工数に換算する生産性係数が、AI導入前の実績に基づいている
COCOMO	コード行数などの規模と補正係数から工数を算出する経験式モデル	AIが大量のコードを生成するため、コード行数と人の労力の関係が崩れる
ストーリーポイント	基準のタスクと比べた相対的な大きさを、ポイントで見積もるアジャイルの手法	AIで大きく速くなるタスクとそうでないタスクが混在し、ポイントの大小と実際の工数が対応しなくなる

見積モデルはどう変わるか

従来手法の限界に対して、研究の世界では新しい見積モデルが提案され始めています。ここでは、人の検証・修正の工数に注目したHIEと、AIの利用料を含めてコストを分解するACEMの2つを紹介します。

HIE：工数の中心は「書く」から「確かめる」へ

従来の見積は、主に「書く」作業の量を基準にしています。しかしAIを使うと、工数の中心はAIの出力を「確かめる」作業へ移ります⁶。HIE（Hybrid Intelligence Effort）は、AIとのやり取りや確認・修正の手間を測る要素を見積に組み込み、この変化を反映させる考え方です。

AIエージェントに開発を任せると、見積に「AIの利用料」が加わる

AIエージェントに開発を任せる場合、費用は人件費だけでは済みません。AIの利用料や、AIの作業をチェックする人の手間もかかります。こうした費用の内訳を整理する考え方として、2026年8月にarXivで公開された論文「ACEM」があります⁷。ACEMでは、エージェント型開発の費用を次の3つに分けて考えます。

1. AIの利用料：AIが読み書きした文章の量（トークン数）に応じてかかる料金
2. 人間のチェック費用：AIの成果物を確認・修正・承認する担当者の工数
3. 環境の費用：エージェントを動かすためのサーバーやツールの費用

新しい見積・契約モデルの議論

人月モデルとの矛盾

AIで生産性が上がると、人月単価×工数で価格を決めるモデルでは売上が減ります。発注側から見ると、AIで工数が減った分の値下げを求めるのは自然なことです。受注側にとっては、生産性を上げるほど売上が減るという矛盾が生じます。

成果・価値ベースへの移行

海外では、成果に応じて対価を決める契約が広がりつつあります。Forresterが2025年3月に公開した分析によると、11か国2,300人超のサービス意思決定者のうち、45%が成果連動型の価格設定の拡大を、46%が固定価格契約の増加を見込んでいました⁸。Forresterは、サービス提供企業が生成AIを使った開発基盤を整えることで、スピードや品質の予測可能性が高まり、固定価格での受注に自信を持てるようになると指摘しています⁸。

主な契約モデルの特徴を整理します。

価格の決め方	計算方法	AIによる生産性向上の恩恵	主な課題（筆者の見解）
時間単価型	作業時間×単価	発注側（工数が減れば支払いも減る）	受注側に生産性向上の動機が働きにくい
固定価格型	成果物に対する一括価格	受注側（安く作れれば利益が増える）	見積の精度が受注側の利益を左右する
成果連動型	業務指標の改善などに連動	両者で分け合う	成果の定義と測定方法の合意が難しい
サブスクリプション型	月額などの定額（例：保守・運用の定額契約）	受注側（効率化すれば利益率が上がる）	提供範囲と品質水準の定義が必要

どのモデルでも、見積の重要性は下がりません。固定価格型や成果連動型では、見積の誤りがそのまま受注側の損失になります。

実務で取り入れるためのポイント

調査結果を踏まえて、生成AI時代の見積で意識したいポイントを3つ挙げます。

1. 実装工数だけを削らない：実装が速くなっても、レビュー・テスト・受け入れ検証の工数は減らないか、むしろ増えることを前提にする
2. タスクの性質で係数を分ける：新規開発か既存改修か、定型的な作業か判断が必要な作業かで、AIの効果を別々に見込む
3. 自社の実績を測る：外部の調査結果は参考値にとどめ、AI活用後の自社プロジェクトの実績を工程別に記録する

まとめ

生成AIで開発工数は確かに減ります。ただ、それ以上に変わるのは、人がどこに時間を使うかだと感じています。これからの見積では、AIに任せる作業と人が担う作業を分けたうえで、人の時間をどこにどれだけ使うかを考えることが大切になりそうです。

Footnotes

1. Mert Demirer, Leon Musolff, Liyuan Yang「Writing Code vs. Shipping Code: Productivity Effects Across Generations of AI Coding Tools」NBER Working Paper 35275（査読前）、2026年5月（2026年9月改訂）、https://www.nber.org/papers/w35275 ↩

2. Faros AI「The AI Productivity Paradox Report 2025」Faros AI、2025年7月23日、https://www.faros.ai/blog/ai-software-engineering ↩

3. Kevin Zheyuan Cuiほか「The Effects of Generative AI on High-Skilled Work: Evidence from Three Field Experiments with Software Developers」Management Science（INFORMS）、2026年掲載（SSRN初出2024年）、https://pubsonline.informs.org/doi/10.1287/mnsc.2025.00535 ↩

4. Vincent Gurgul, Robin Gubela, Stefan Lessmann「The State of Generative AI in Software Development: Insights from Literature and a Developer Survey」arXiv（プレプリント、査読前）、2026年3月17日、https://arxiv.org/abs/2603.16975（ライセンス：CC BY-NC-SA 4.0） ↩

5. METR「Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity」METR、2025年7月10日、https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/（論文：https://arxiv.org/abs/2507.09089）。METRは2026年2月以降、この結果は現在のAIの影響を反映していないとしている ↩

6. Feisal Alaswadほか「Toward LLM-aware software effort estimation: a conceptual framework」Frontiers in Artificial Intelligence（査読付き学術誌、概念論文）、2026年3月23日、https://www.frontiersin.org/journals/artificial-intelligence/articles/10.3389/frai.2026.1772418/full ↩

7. Mohammad El-Ramly「ACEM: A Cost Estimation Model for Agentic Software Engineering」arXiv（プレプリント、査読前）、2026年8月3日、https://arxiv.org/abs/2608.02582 ↩

8. Ted Schadler「The State Of Services, 2025: Co-Innovation, AI-Powered Delivery, And Performance Pricing Set The Bar」Forrester、2025年3月18日、https://www.forrester.com/blogs/the-state-of-services-2025-co-innovation-and-performance-pricing-set-the-bar/ ↩ ↩²