生成AIでシステム開発費はどこまで下がるか｜工程の比率から見た上限と、確かめる手間が増えるところ

「生成AIを使えば、システムの開発費は安くなるはず」。そう言われたとき、どこまで下がりうるかは、開発の工数のうちプログラムを書く工程がどれだけを占めるかで見当がつきます。情報処理推進機構（IPA）が公開している開発データでは、設計からテストまでの工数のうち、プログラムを書く工程（製作）は3割ほどでした。生成AIで製作の工数が半分になっても、合計は16%ほどしか小さくならず、製作がまるごと無くなっても31.6%までです。AI駆動開発で大きなコスト削減をうたう説明を聞いたときも、まずこの上限と比べます。

しかも、生成AIで速くなったと実験で測られたのは、作るものが先に決まっているプログラムの作業です。速くなったという実感と測った時間がずれた実験や、AIの利用が進むほどソフトウェアの不安定さが増えたという調査もあります。予算の超過の要因として多く挙がるのは、計画時の考慮不足、今の業務の複雑さ、仕様変更の多発で、プログラムを書く速さの外にあります。

ここでは、発注の前に社内で「生成AIを使えば安くなるはず」と言われ、予算の見込みをどう置けばよいか迷っている発注側の担当者を想定しています。Aurant Technologiesも生成AI（Claude Code）を使って業務システムを作っていますが、当社の料金や作り方の紹介ではなく、公開された研究と調査で確かめられることをもとに書きました。

工程の比率から見た、下がる余地の上限

IPAの「ソフトウェア開発分析データ集2022」には、国内の企業35社から集めた開発プロジェクトの実績が載っています。2016〜2021年度の新規開発のうち、基本設計から総合テストまでの5つの工程がそろった270件で工程ごとの工数の比率を見ると、製作（プログラムを書き、部品ごとに動かして確かめる工程）は平均も中央値も31.6%でした。IPAも、新規開発では製作の比率が30%を超え、ほかの工程より高いとしています。生成AIが広まる前のデータなので、生成AIが効く前の配分として読めます。

この比率から、製作が速くなったときに全体がどれだけ動くかを計算できます。ほかの工程が変わらないとすると、製作の工数が半分になれば、製作の31.6%が15.8%になり、5つの工程の合計は約84%、つまり16%ほど小さくなります（冒頭の図）。製作の比率はプロジェクトによって違い、真ん中の半分のプロジェクトは24〜40%に収まるので、小さくなる幅も12〜20%ほどです。製作の工数がゼロになったとしても、小さくなるのは31.6%までです。既存のシステムを改修・拡張する改良開発（580件）でも、製作の比率の中央値は29.7%でした。開発の見積もりは、工数に1人月あたりの単価を掛けて出すことが多いので、単価が同じなら、開発費が下がる割合も工数と同じところが目安になります。

しかも、この5つの工程には、要件定義、発注側が行う受け入れのテスト、データの移し替えと切り替え、使う人への説明が入っていません。見積もりの総額でみれば、製作の占める割合はこれより小さく、製作が速くなったときに総額が下がる割合も、これより小さくなります。「生成AIを使えば開発費が半分になる」という話は、製作の比率が平均並みである限り、製作だけでは説明がつきません。

設計書やテストのコードの下書きにも生成AIは使えるので、製作以外の工程が小さくなる余地はあります。ただ、次の節で見るように、実験で速さが測られているのは主に製作にあたる作業です。ほかの工程がどれだけ小さくなるかは、開発会社に根拠を聞く部分です。

実験で速くなったのは、作るものが先に決まったプログラムの作業

生成AIでプログラムを書く作業が速くなることは、条件をそろえた実験で確かめられています。ただし、どの実験も測ったのは、作るものが先に決まっているプログラムの作業です。

よく引用されるのは、GitHub Copilotを使った2022年の実験で、できたかどうかを確かめるテストまで先に用意されていました。フリーランスの仲介サイトで募った開発者95人を2つの群に分け、JavaScriptでHTTPサーバーを作る課題を出し、雛形のプログラムと12個の自動テストを渡して、テストがすべて通った時点を完了としています。Copilotを使えた群は、完了までの時間が55.8%短くなりました（95%信頼区間は21〜89%）。経験の浅い開発者ほど効果が大きく、コードの品質は調べていない、と論文に書かれています（Peng ほか、arXiv:2302.06590）。

Googleは2024年6〜7月に、社員のエンジニア96人で同じ形の実験をしています。既存のコードをもとに新しいサービスを実装し、ビルドとテストのファイルも直して、テストが通るまで仕上げる課題で、3時間以内に終わるように作られていました。社内のAIの機能を使った群は作業時間が約21%短くなりましたが、推定の幅は大きいと報告しています（Paradis ほか、arXiv:2410.12944）。

業務の中での実験もあります。Microsoft、Accenture、米国の大手電子機器メーカーの3社が、開発者の一部にだけAIのコーディング支援を使えるようにした実験を合わせて分析すると、4,867人の開発者で、週あたりに完了した作業（プルリクエスト）が26.08%増えていました。増え方は経験の浅い開発者で大きく、Microsoftのデータでは、在籍が長い人や職位が高い人では、はっきりした増加は見られませんでした（Cui ほか、2025年）。

反対の結果もあります。研究機関のMETRが2025年2〜6月に行った実験では、熟練のオープンソース開発者16人が、平均5年関わってきた大規模なプロジェクトの実際の課題246件に取り組み、AIを使ってよい課題のほうが19%長くかかりました。METRは2026年2月に、この結果は今の効果を表していないとし、当時より速くなっている可能性が高いと説明しています。ただ、その後の実験は参加者の偏りが大きく、信頼できる数字は得られなかったとしています（METR、2025年7月・2026年2月）。

並べてみると、効き方は課題の中身と、誰が使うかで大きく変わります。どの実験も測ったのは、決まった課題のプログラムを書いて確かめるまでの時間か、完了した作業の数で、業務の聞き取り、発注側の受け入れテスト、データの移し替え、使う人への説明を測った実験ではありません。前の節の計算で製作だけを動かしたのは、このためです。

「速くなった」という実感と、測った時間はずれる

社内で「AIで速くなる」と言われるとき、その根拠が使った人の実感だけなら注意が要ります。先のMETRの実験では、開発者は始める前に、AIを使うと作業時間が24%短くなると予想し、終えた後も20%短くなったと感じていましたが、記録した時間では19%長くなっていました。画面の記録を分けて見ると、AIへの指示を書く時間、出力を待つ時間、出力を確かめて直す時間が加わっていて、AIを使ってよい課題では作業時間の約9%がAIの出したコードの確認と手直しでした。提案されたコードのうち採用されたのは、44%に届きませんでした。

実感は、反対向きにずれることもあります。Pengほかの実験では、参加者が見込んだ速さは平均35%で、測った55.8%より小さいものでした。どちらの向きにもずれる以上、実感は予算の見込みの根拠になりません。METRも2026年2月の報告で、開発者が自分で申告する速さは当てにならないことがある、と改めて書いています。

見込みに使えるのは、測った数字です。開発会社が「生成AIで何割速い」と説明するなら、過去の案件で生成AIを使った工程の工数を記録しているか、同じくらいの規模と種類の案件で使う前と後を比べたかを聞きます。効き方は担当者によっても違い、Cuiほかの実験では経験の浅い開発者ほど効果が大きく、METRの実験の熟練者はかえって遅くなっていました。誰が担当する前提の数字なのかも、あわせて確かめます。

速く書くほど、確かめる手間と不安定さが増える

生成AIで書く量が増えると、確かめる仕事も増えます。Googleは2024年10月の決算説明で、社内で新しく書かれるコードの4分の1以上をAIが生成し、それをエンジニアが確認して取り込んでいると説明しました（Alphabet 2024年第3四半期の決算説明）。GitHubもCopilotの説明の中で、提案されたテストがすべての場合を確かめているとは限らないので確認が要るとし、AIの出力を人が確かめることが重要だとしています（GitHub Docs「GitHub Copilot のインライン候補」）。

確かめる手順が追いつかないと、出来上がったものが不安定になりやすくなります。Google CloudのDORAが毎年まとめている調査では、2024年の報告書（回答約3,000人）で、AIの利用度合いが25%高まるごとに、ソフトウェアを届ける速さ（スループット）が1.5%、安定性が7.2%下がると推定しました。DORAは、AIで一度に書くコードが増えて変更の単位が大きくなったことを理由の候補に挙げ、変更を小さく分けることと、確かなテストの大切さを指摘しています。2025年の報告書（回答約5,000人）では、AIの利用は届ける速さを上げる方向に変わった一方で、不安定さは増やしたままでした。どちらも調査の回答から推定した関係で、実験ではありません（DORA 2024年の報告書・2025年の報告書）。

DORAの2025年の結果は、速さと安定性が引き換えになりうることを示しています。生成AIで製作が速くなった分の一部は、コードの確認とテストに回ります。社内の見込みでは、製作で浮く工数をそのまま下がる額にせず、確かめる手間が増える分を差し引いて考えます。見積もりで確認とテストの工数まで小さくなっていたら、何を省いたのかを聞きます。

予算が超える理由の上位は、作る速さの外にある

JUASが東証上場企業とそれに準じる企業のIT部門長を対象に毎年行っている企業IT動向調査（「企業IT動向調査報告書2026」。2025年9〜10月に調査、回答957社）では、システム開発の予算が予定より超過した企業に、その要因を複数回答で尋ねています（n=245）。上位は「想定以上の現行業務・システムの複雑さ」51.4%、「計画時の考慮不足」51.0%、「仕様変更の多発」48.6%で、「ベンダーのスキル不足」27.8%や「開発体制のリソース不足」21.2%を大きく上回りました。工期が遅れた企業（n=297）でも、「計画時の考慮不足」52.5%と「想定以上の現行業務・システムの複雑さ」48.8%が上位で、発注する側の「社員のスキル不足」46.5%が続きます。

同じ調査で、この5年で予算や工期が悪化していると答えた企業に、影響している工程を尋ねた設問では、「要件定義」を挙げた企業が予算で57.4%（n=272）、工期で69.0%（n=174）でした。「設計・実装・テスト」も予算で54.0%と多く、作る工程が関係ないわけではありません。それでも、予算や工期が崩れたときに多く挙がるのは、今の業務をどこまで調べ、何を作るかをどう決めたかに関わる要因です。生成AIでプログラムを書く時間が短くなっても、これらの要因がなくなるわけではありません。

JUASの「ソフトウェア・メトリクス調査2025」ガイドブックには、金融業の会社が、開発を速く安くするために、要件定義とテストにかける工数の割合をトップダウンで減らしたところ、苦戦するプロジェクトが増えた、という事例が載っています（p.31）。この会社はその後、JUASの工程ごとの工数の比率を示して、経営層に配分の必要性を説明したといいます。生成AIで製作の工数が小さくなっても、要件定義とテストまで同じだけ削れば、同じことが起きかねません。

「生成AIで安くなるはず」を、社内の見込みにするときは

予算の見込みに生成AIの効果を入れるなら、根拠は2つに分けます。1つは製作の比率で、IPAのデータでは設計からテストまでの工数の3割ほどです。見積もりが届いて工程ごとの工数が分かれば、その比率に置き換えます。もう1つは、開発会社が過去の案件で測った、製作の工数が短くなった割合です。この2つを掛けた分が、設計からテストまでの工数が下がる分の目安です。製作以外の工程も短くなると説明されたら、その工程の比率と実績の割合を同じように掛けて足します。そこから、確かめる手間が増える分を差し引きます。要件定義、受け入れテスト、データの移し替えと切り替え、使う人への説明、社内の担当者が確かめる時間は、生成AIを使わない場合と同じだけ見込んでおきます。

見積書が届いた後に、行ごとに何を聞くか（要件定義・テスト・移行・保守の行と、期間の確かめ方）は「システム開発の見積もりは妥当か」にまとめました。生成AIを前提にした見積もりなら、そこに、どの行を何割減らしたか（実績にもとづくか）、確認とテストの行まで減らしていないか、減らした作業が発注側の受け持ちに移っていないか、の3点を足して聞きます。

見込みを置く前に、社内で出せる上限そのものを決める材料（いま手作業にかけている時間、今のシステムの保守費、使う年数）は「予算が決まっていないときのシステム開発費の考え方」で解説しています。

受発注・在庫の仕組みについては、生成AI（Claude Code）で作る当社の進め方と、最初の見積りまでに伺う内容を、Aurant Technologiesの「受発注・在庫管理システムの開発」のページにまとめています。