AIで開発工数が減ると、システム開発費も安くなるのか？

AIの生産性向上を示す研究はある。Microsoft、Accentureなど３社の開発者4,867人を対象にした無作為化比較試験では、３つの実験を統合した分析で、AIツールによる完了タスク数の増加が約26％と推定された。ただし、実験ごとの結果にはばらつきがあり、これは開発案件全体の費用が26％下がったという意味ではない。^[1]

効果は、作業や環境によっても変わる。METRが2025年前半に実施した研究では、使い慣れた大規模なオープンソースのコードを扱う熟練開発者は、AIを使うと所要時間が19％増えた。その後、METRは2026年２月の更新で、AIによる高速化は進んでいる可能性が高いとしつつ、参加者や対象タスクの偏りにより、効果の大きさを信頼して推定することは難しいと説明している。古い結果を現在のAI全般に当てはめることも適切ではない。^[2]

ここから読み取るべきなのは、「AIは速いか、遅いか」という二択ではない。何を、どの環境で、どの品質まで仕上げるかによって、効果が異なるということだ。

例えば、従来100人月かかっていた案件で、実装が30人月を占めていたとする。AIによって実装工数を半減できても、他の工程が変わらなければ、全体は85人月になる。そこにAIの利用料や追加の検証費用が加われば、費用の削減率は工数の削減率より小さくなる。

これは説明のための仮定だが、「実装が50％速くなった」と「開発費を50％下げられる」の間にある隔たりを示している。

各工程に効率化の余地はある。ただし、一つの作業を速くするだけでは、案件全体の期間や費用は同じ割合で減らない。

実装が速くなっても、レビュー待ちや仕様確認待ちが増えれば、納期は縮まらない。生成されたコードが増えた結果、確認作業が追いつかなくなる可能性もある。

DORAが2026年３月に公表した分析でも、コード作成で浮いた時間が監査や検証に振り向けられる状況が報告されている。また、2025年のDORA調査では、AI導入の拡大はソフトウェア提供量の増加と、不安定性の増加の双方に関連していた。これは相関であり、AIが必ず品質を下げるという意味ではないが、生成速度だけでは成果を評価できないことを示している。^[3]

ここで、発注企業にも役割が生じる。業務要件を決める人が不在、承認に数週間かかる、受入れ条件が曖昧という状態では、ベンダー側だけを効率化しても限界がある。

AIの効果を納期や費用に反映するには、開発ツールの導入とともに、意思決定・レビュー・受入れまでを含む仕事の流れを見直す必要がある。

工数が減ったとき、その利益が誰に渡るかは、料金の決め方によって変わる。

なお、これは料金方式の整理であり、請負・準委任といった契約類型とは分けて考える必要がある。

固定価格で受注した案件なら、効率化の利益をベンダーが確保しやすい。しかし、次の案件でも同じ利益を維持できるとは限らない。同じ品質をより安く提供する競合が現れれば、発注企業には比較する理由ができる。

短期的には利益率を改善する技術が、中期的には市場の価格水準を下げる要因にもなり得る。これが、AI活用を現場の生産性改善だけで捉えられない理由だ。

ただし、価格低下の進み方は一様ではない。仕様が明確で、成果物を比較しやすく、代替可能なベンダーが多い領域では圧力が強まりやすい。一方、複雑な業務知識や既存システムへの理解が必要な領域では、切り替えの難しさが価格に影響する。

ベンダーが品質や納期への責任を負うことには価値がある。しかし、その責任が以前と同じだからといって、効率化後も価格が同じでよいとは自動的には言えない。

顧客が知りたいのは、AIを使ったうえで、必要な品質を確保するためにどの作業が残り、どの費用が増え、総額としてどう変わるのかという点だ。

価格を説明するには、従来の人数や工数に加えて、品質を確認する仕組み、移行を安全に完了する能力、障害対応や運用改善の実績を示す必要がある。これらも効率化の対象になり得るため、「人が担当するから高い」という説明だけでは弱い。

人月は原価や要員計画の尺度として残っても、顧客への価格説明では、何を、いつまでに、どの品質で提供するかの比重が高まると考えられる。

さらに、作業時間の削減が、そのまま会社全体の費用削減になるわけではない。

社員の作業が減っても、給与や固定費は直ちには減らない。空いた時間を別案件に振り向ける、新たな受注を獲得する、外注費や残業を減らすといった変化があって、初めて経営上の効果として表れる。

つまり、ベンダーのAI戦略には、開発の効率化と並んで、増えた供給能力を何に使うかという営業・事業戦略が必要になる。

従来と同じ案件を少人数で回すだけなら、売上が縮小する可能性がある。一方、これまで人手不足で断っていた案件や、採算が合わなかった小規模開発を取り込めれば、売上を伸ばす余地がある。

差を生むのは、AIを導入したかどうかに加え、効率化後の仕事を設計できるかどうかだ。

発注企業にも同じ構図がある。

例えば、これまで費用に見合わず見送っていた業務改善が、低い費用で実現できるようになれば、投資対象は増える。同じ予算で改善回数を増やす、早期に試作して判断する、現場ごとの小さな課題に対応するといった使い方も可能になる。

そのため、AIによって個々の開発費が下がっても、企業のIT投資総額が減るとは限らない。投資件数が増えれば、総額が増えることもある。

ただし、需要の拡大は自動的には起きない。開発後の保守、セキュリティ、データ管理まで含めて採算が合い、発注側に改善を進める体制があることが条件になる。

安く作れることに加えて、作ったものを使い続け、成果を得られることが重要だ。

発注企業は、AIを使っているかという確認から一歩進み、同じ要件・品質で、費用と納期がどう変わるのかを比較する必要がある。一律の値下げ率を求めるより、削減余地の大きい工程と、品質確保に必要な工程を把握した方が、交渉も投資判断も具体的になる。

ベンダーは、効率化で得られる利益を恒久的なものと考えず、価格低下や契約更新を織り込んで収益構造を見直す必要がある。浮いた工数を新たな受注や継続的な改善サービスにつなげられるかが、重要な分岐点となる。

双方に共通する課題は、従来の体制や工数を前提にした見積もりを更新することだ。AIで何が変わったのかを測定できなければ、顧客は効果を受け取れず、ベンダーも自社の競争力を説明できない。

AI開発支援、テスト自動化、開発プロセス可視化、品質・セキュリティ検証、レガシー解析、内製化支援。

これらの導入効果は、コード生成量やツールの利用率だけでは測れない。受入れを終えた機能の提供速度、品質を含めた総費用、そして事業成果まで確認する必要がある。

AIによって、開発費が下がる余地はある。その余地を実際の価格低下に変えるのは、開発全体の効率化と市場競争だ。そして、その先にある経営課題は、安く・速く作れるようになった能力を、次の事業価値につなげられるかである。