AI で開発工数は何割減るのか。公表データの読み方と、工程別の効き方

「AI を使うと開発はどのくらい速くなりますか」。この質問を、最近は提案のたびに受けます。答えに困るのは、公表されている数字の幅がとても大きいからです。公表値には、生産性の向上率、工数の削減率、期間の短縮率が混在しています。生産性の向上率で見ると、会社全体の平均では1〜2割、条件のそろった新規開発では3〜4割。特定の作業では、工数7割減や作業速度約100倍という数字もあります。ただし、それぞれ測定対象や条件が異なります。どの範囲の、どの作業の、何の数字なのかを読み違えると、見積も期待もずれます。この記事では、公表データを同じものさしに直して並べ、そのうえで私たちが見積に置いている考え方を書きます。

「生産性70%向上」は「工数7割減」ではない

最初に押さえておきたいのが、生産性と工数は別物だということです。同じ量と品質の成果を出す前提で、生産性が30%上がると、工数は 1 ÷ 1.3、つまり従来の約77%になり、約23%減ります。70%向上なら約41%減、2倍なら50%減です。「生産性70%向上」という見出しを「工数が7割減る」と読むと、本来は6割近く残る工数を3割しか残らないと見積もることになり、必要な工数を半分近く過小評価します。

もう一つは、数字がどの範囲を指しているかです。企画からリリースまでの工程のうち、コードを書いてテストする時間は全体の25〜35%にすぎない、という Bain の指摘があります。コードを書いてテストする作業が2倍速くなっても、全体で見れば1〜2割しか縮まない計算です。大きな数字を出している会社は、要件定義や設計、テストまで含めてやり方を変えています。

公表データを指標と対象範囲で整理する

国内の大手 SIer（システム開発会社）と事業会社の数字を整理します。工数に換算できるものは削減率で示し、期間の短縮など別の指標は区別して書いています。目標か実績か、どの作業の値かも添えました。

こうして並べると、工程全体の目標値は2〜4割減のあたりに集まり、7割減や100倍は特定の作業を切り出した値だと分かります。

海外の調査では、作業条件によって効果が分かれる

海外の調査では、生産性の向上に加え、作業時間が増えた例も報告されています。公表事例より数字は控えめで、作業の条件によって結果が大きく分かれます。

作業の性質で効果が大きく変わること、熟練者が慣れたコードを扱う場面では逆効果になりうること、処理量が増えた分だけ手戻りも増えうること。この三つが、公表事例の大きな数字を読むときの補助線になります。

「速くなった気がする」と実測はずれる。レビューとテストの仕組みが追いつかないと、速くなった分が手戻りで相殺される。この2点は、見積を考えるときに外せない前提です。

どの工程に効いて、どこに効かないか

私たちの見積は、AI を使わない場合の工程ごとの工数に、工程ごとの削減率を掛けて合計する方法です。コーディングエージェントを使い、テストを自動生成し、仕様書から実装までを AI と進める体制を組む前提で見ています。以下は、各工程の工数削減率について、私たちが見積に用いている想定範囲です。ここまでの海外調査の数字は生産性の向上率でしたが、ここからは工数の削減率です。

要件定義は5〜20%。議事録や資料の下書き、調査は速くなりますが、お客様との合意形成の時間はほとんど縮みません。設計は15〜30%。仕様書や画面設計、図の下書きは AI が得意で、方式の判断とレビューは人がします。デザインは10〜25%。案出しは速くなり、デザインの方向性の最終判断は人です。開発（実装）は25〜50%で、最も効く工程です。一般的な Web 技術を使う新規開発なら、この幅の上限に寄りやすいと見ています。テストは15〜40%。テスト仕様書とテストコードの生成は効きますが、品質のリスクがあるので削りすぎません。リリース準備は10〜20%で、手順書やマニュアルの下書きが速くなります。

新規の Web サービス（70機能程度）を作る想定で、AI を使わない場合の工程別の工数配分と、各ケースで置いた削減率は次のとおりです。PM は他の工程の合計に対する比率（約1割）のまま、全体に連動して減るものとしています。配分は四捨五入しているので、合計は100%になりません。

配分に削減率を掛けて合計すると、全体では控えめに見て約17%減、計画値で約25%減、積極的に見て約38%減になります。幅としては2〜4割ですが、通常の見積では計画値の約25%減を中心に、2〜3割減を目安に置いています。公表データの工程全体の目標値と、だいたい同じところに落ちます。

実績ではこれを上回ることもあります。自社の案件では、AI を前提にした体制で工数が5割以上減ったものもあります。それでも見積では控えめに置くのは、案件ごとに条件が違い、品質の工程を削った分が手戻りで返ってくるリスクを見ているからです。

人が判断する境界も、ここで決まります。調査と下書きと作業は AI、結果を見て何をするかを決めるのは人。このループを短く回すことが、私たちの仕事の仕方です（詳しくは METHOD のページに書いています）。

見積で気を付けていること

三つあります。一つ目は、他社の数字を自分の案件にそのまま当てはめないこと。目標か実績か、対象はどの作業か、新規開発か既存システムの改修かで、意味が変わります。二つ目は、レビューとテストの工数を削りすぎないこと。速くなった分を手戻りで失うのが、いちばんもったいない。レビューとテストは AI で速くはしますが、人の確認は残します。三つ目は、人月で測ること自体の限界を意識すること。AI 前提の開発では、同じ人月でできることが変わるので、工数ではなく成果で合意する形に少しずつ寄せていく必要があります。

AI ツールの進化は早く、この記事の数字も来年には古くなっているはずです。それでも、生産性と工数を取り違えないこと、平均と特定作業を分けて読むこと、品質の仕組みを先に用意すること。この三つは当分変わらないと思っています。

—

出典

• NTTデータ: 日経ビジネス電子版 SPECIAL、日経クロステック（2023年10月）
• 日立製作所: IT Leaders（2026年7月）
• 富士通: プレスリリース（2026年2月17日）
• TIS: @IT（2026年5月）
• 楽天: Anthropic 導入事例
• メルカリ: LINEヤフー ストーリー（2026年7月、メルカリ担当者のインタビュー）
• Bain & Company: Technology Report 2025
• スタンフォード大学: AI Engineer での発表
• Microsoft・Accenture ほか: Microsoft Research
• METR: 2025年の論文（arXiv）、2026年2月の続報
• DORA 2025: Google Research