サマリ
受託開発の見積書は、たいてい「作る量」で書かれています。画面数、機能数、人月。ところが案件が崩れるとき、原因として名前が挙がるのは作る工程ではありません。何を作るかが決まりきらないまま、作る工程が始まってしまうことが、遅延と赤字の入口になっています。
一般社団法人日本情報システム・ユーザー協会（JUAS）の「企業IT動向調査2026」では、システム開発の品質・予算・工期（QCD）が過去5年の間に悪化していると答えた企業に、その悪化にどの工程が影響しているかを尋ねています。工期について「要件定義」を挙げた割合は69.0%で、全工程のなかで最も高くなりました。予算でも57.4%で最も高く、品質では「設計・実装・テスト」74.1%に次ぐ60.0%です。
一方、独立行政法人情報処理推進機構（IPA）の「ソフトウェア開発分析データ集2022」によれば、新規開発の工程別実績工数比率の中央値は製作工程が31.6%で最大でした。この集計の対象は基本設計から総合テストまでの開発5工程で、要件定義工程は含まれていません。調査も設問も違う2つの数字ですが、並べると受託開発の形が見えます。工数（＝請求根拠）が最も集まる工程と、悪化の原因として名前が挙がる工程が別にある、ということです。
生成AIはこの構図を動かします。JUASの同じ調査で、ユーザー企業における「コード系生成AI」の「導入済み」と「試験導入中・導入準備中」の合計は32.6%となり、前年度の20.8%から伸びました。作る工程が短くなるほど、人月で積んだ見積りは相対的に細り、代わりに「何を作るかを決めきる力」が値段のつく場所へ移動します。脅威ではなく、これまで無償の前工程だったものを、独立した商品として売れるようになったという話です。
結論は、最初の1業務を「直近で赤字または失注になった案件1件の、要件定義のやり直し」に絞ることです。承認済みの前提カードからAIに要件定義書の下書きと未確定事項の一覧を作らせ、顧客と合意するまでの日数と、その後の仕様変更件数を測る。売れる商品になるかどうかは、そこで初めて判断できます。
データ：調査で見る業界の現在地
売上の46.3%はSIサービス、そして売上の33.54%が外注費に出ていく
JISA（情報サービス産業協会）の「2025年版 情報サービス産業基本統計調査」は、令和7年7月現在のJISA正会員企業468社を対象に調査票を送付し、有効回答は300社（回答率64.1%）でした。集計対象は2024年4月1日から2025年3月31日までに終了した事業年度の単独決算です。回答企業の売上高合計は10兆6,695億円、従業員数合計は27万9,677人で、一人あたりの売上高は3,815万円でした。母集団がJISA正会員企業である点は、読むときに留意が必要です。
業務別売上高構成をみると、SIサービスが46.3%、ソフトウェア開発が14.7%、ITアウトソーシングが10.4%です。企業数で見た「主たる業務」では、ソフトウェア開発が46.0%（138社）、SIサービスが31.3%（94社）で、金額はSI寄り、社数はソフトウェア開発寄りという構造です。
この産業を他業界と分けている数字が、外注費です。同調査の売上高外注費率は加重平均33.54%（中央値29.01%）でした。JISAが1993年版から2025年版の同調査をつないだ「JISA基本統計・主な指標の推移」では、この比率は1991年度の20.99%から2024年度の33.54%へ、SIサービス売上高比率は1991年度の19.96%から2024年度の46.32%へ上昇しています（SIサービス売上高比率は2023年度の47.26%から直近1年では微減です）。売上の3分の1が、自社の外へ出ていく産業になったということです。ただしJISAは、入退会や合併で毎年の調査対象が変わるため、経年変化として使う際には留意してほしいと注記しています。長期の水準感として読むのが安全です。
同調査の詳細編（極端に売上高の大きい5社を除いた295社）で業態別に見ると、売上高外注費率はSIサービス型（92社）で38.95%、ソフトウェア開発型（146社）で29.69%でした。取引先別売上高の「同業者」の比率も、SIサービス型で5.7%、ソフトウェア開発型で14.5%と差があります。上流を取る会社ほど外へ出し、下流にいる会社ほど同業者から受けている構造が、金額として表れています。
プロジェクトが大きくなるほど、工期は崩れる
JUASの「企業IT動向調査2026」は、経済産業省商務情報政策局の監修を受けて実施された調査です。アンケートは2025年9月5日から10月24日に、東証上場企業とそれに準じる企業計4,500社のIT部門長を対象に実施され、回収数は957社（有効回答率21.3%）でした。回答者は自社システムを発注する側のIT部門長で、受注側であるITベンダー・SIerの自己申告ではない点が、この調査を読むうえで重要です。回答企業の業種内訳では「情報処理・ソフト開発、その他情報通信業」が45社（4.7%）含まれますが、その企業も自社のIT部門として回答しています。
2025年度調査では、システム開発の工期遵守状況をプロジェクト規模別に集計しています。「予定より遅延」と回答した割合は、10人月未満で9.6%、500人月以上で47.8%と、規模が上がるにつれて一貫して悪化します。
規模が大きいほど崩れるという傾向自体は、驚く話ではありません。注目すべきは崩れ方の幅です。10人月未満では品質・予算・工期のいずれも不良の割合が10.0%を下回るのに対し、500人月以上では品質で29.6%、予算で42.2%、工期で47.8%になります。関わる人と組織が増えるほど壊れるという、この産業の商流そのものが数字に出ています。
データ：この業界だけの構造
工数が集まるのは製作工程、悪化の原因に挙がるのは要件定義工程
IPAの「ソフトウェア開発分析データ集2022」は、複数企業から収集した5,546件のプロジェクトデータのうち、直近6年間（2016年度〜2021年度）を主な対象として分析した資料です。同書は収集データが無作為抽出ではないと明記しており、業界全体の分布ではなく、ベンチマークとして読むべき数字です。なお、IPAは同データ集の一覧ページで今後の発行予定がない旨を掲載しており、工程別の工数がどう変わったかを公的なデータで追える定点は、この2022年版で止まっています。生成AIが工程の形を変えつつある時期に、業界共通の物差しがないということです。
新規開発について、開発5工程（基本設計〜総合テスト）がすべてそろったプロジェクト270件の工程別実績工数比率を見ると、中央値は製作工程が31.6%で最大でした。
一方、JUASの調査には、品質・予算・工期が過去5年の間に「悪化している」と答えた企業に、その悪化にどの工程が影響しているかを尋ねた設問があります（複数回答）。工期について「要件定義」を挙げた割合が69.0%で最も高く、次いで「設計・実装・テスト」が51.7%でした。予算でも「要件定義」57.4%が最も高く、品質では「設計・実装・テスト」74.1%に次いで「要件定義」60.0%です。これは5年スパンでの悪化の実感について、どの工程が効いているかを尋ねた集計であり、案件ごとの事後検証ではありません。
2つの調査は対象も設問の設計も違うので、数字を直接引き比べることはできません。それでも並べて読むと、この産業の構造が見えます。請求の根拠になる工数は製作工程に集まり、悪化の原因として名前が挙がるのは要件定義工程である。同じ調査では、QCD悪化に影響する環境変化として「要件定義の難易度上昇」を挙げた割合が品質44.4%・予算40.4%・工期46.6%、「要件定義の時間不足」が品質33.3%・予算29.4%・工期36.8%でした。難しくなっているのに、時間が足りていません。
仕様は、商流を通るあいだに薄くなる
同じIPAの資料には、この産業だけが持つもう1つの数字があります。外部委託の工数比率です。基本設計から総合テストまでの総実績工数に対する外部委託実績工数の割合は、562件のプロジェクトで中央値63.4%（平均58.6%）でした。開発工数の6割強が、契約した会社の外で消化されているということです。
同じ資料の外部委託の金額比率は、54件で中央値40.0%（平均43.3%）でした。JISAの売上高外注費率33.54%とは分母が違う（IPAは工数と委託金額、JISAは売上高）ので単純に重ねることはできませんが、いずれも受託開発が要件を聞いた人と、コードを書く人が、法人をまたいで分かれている産業であることを示しています。他業界の内製部門にはない条件です。仕様が伝わる経路は、顧客の担当者、元請の営業、元請の技術担当、一次委託先、二次委託先と続き、その各段階で「たぶんこういう意味だろう」という解釈が1回ずつ入ります。
JUASの調査には、ここまでとは別の設問として、品質に「不満」・予算に「予定より超過」・工期に「予定より遅延」と回答した企業（品質n=172／予算n=245／工期n=297）に、予定どおりにならなかった要因を尋ねた集計もあります（複数回答）。その上位に「計画時の考慮不足」（品質48.8%・予算51.0%・工期52.5%）、「想定以上の現行業務・システムの複雑さ」（品質48.8%・予算51.4%・工期48.8%）、「仕様変更の多発」（品質30.2%・予算48.6%・工期42.4%）が並ぶのは、この経路の長さと無関係ではないと私たちは見ています。品質については「ベンダーのスキル不足」が59.9%で、3項目より高い要因になっていました。
発注する側で、コードを書くAIが動き始めている
JUASの調査では、ユーザー企業におけるAIの導入状況も尋ねています。「導入済み」と「試験導入中・導入準備中」の合計は、言語系生成AIが53.4%（2024年度調査41.2%）、画像および動画系生成AIが34.2%（同21.9%）、コード系生成AIが32.6%（同20.8%）、AIエージェントが21.0%でした。
この数字は、発注側が自分でコードを書けるようになったことを意味しません。「導入済み」と「試験導入中」の合計であり、成果は測られていないからです。ただし、コードを書く行為の価格は、発注側から見えるところまで下がってきていることは示しています。人月で積んだ見積りが説明しづらくなる場面は、これから増えると私たちは考えています。
承認済みの前提カードを大元にして、仕様を出す
ここでAIに議事録や提案依頼書（RFP）を読ませて要件定義書を作らせるだけでは、この産業の問題は解けません。確認していない業務ルールや制約を、自然な文章で埋めてしまうからです。受託開発では、その1文がそのまま契約範囲になり、あとから請求できない作業になります。
そこで、案件ごとに「前提カード」を1枚持ちます。少なくとも「現行業務の流れと例外」「連携する既存システムと制約」「データ量と繁忙期」「法令・社内規程の制約」「非機能の要求水準」「決裁者と承認の経路」「今回やらないこと」「未確定事項と確認先」を項目として分けます。ここに載るのは顧客が承認した内容だけで、AIが使ってよいのもその範囲です。AIの仕事は、承認済みの内容を要件定義書の様式へ並べ替え、埋まっていない欄を未確定事項として名指しすることです。
承認済みの前提カードから、未確定事項の一覧まで出す
AIは要件定義書の下書きと未確定事項の洗い出しまで。業務ルールの確定、やらないことの線引き、見積りへの反映は人が担います。
- 顧客と前提カードを承認する現行業務の流れと例外、連携先の制約、データ量、法令・社内規程、非機能の水準、決裁経路、今回やらないことを、承認者と更新日時つきで1案件1枚にそろえます。
- AIが要件定義書と未確定事項を下書きする承認済みの内容を要件定義書の様式へ並べ替え、根拠のない欄は補わずに未確定事項として一覧化し、確認先と締切をつけて残します。
- 人が確定し、決まった内容を前提カードへ戻す業務ルールと非機能の水準を顧客と確定し、やらないことを合意して見積りへ反映します。追加で決まった内容は前提カードへ追記します。
AIの役割は要件定義書の下書きと未確定事項の洗い出しまでです。業務ルールの確定、契約範囲の線引き、見積り金額の決定、顧客への説明と合意は人が担います。
価値は「書いた枚数」ではなく、決まるまでの日数と手戻りで測る
仕様をAIで支援するときに測るべきなのは、生成した文書の枚数ではありません。提案から要件が確定するまでの日数、未確定事項として残った項目数とその消化率、要件確定後に発生した仕様変更の件数、そのうち追加請求できた件数を、導入前後で同じ方法で記録します。
利益への影響を見る場合も、AIを使った案件と使わなかった案件の単純比較で結論を出しません。顧客、業務領域、規模、体制が違えば、仕様以外の要因が混ざります。まず1案件で確定までの日数と仕様変更の件数を確かめ、粗利は参考指標として分けて見ます。
服部の分析
服部の視点からこの産業を整理すると、機会は「AIで開発を速くすること」ではありません。速くなった分だけ、仕様を決めきる工程に値段をつけ直せることにあります。
現場で見た例を匿名化して挙げます。ある中堅のシステム開発会社では、提案段階で無償の要件ヒアリングを3か月続け、受注後に「聞いていない」業務例外が次々に出て、追加請求できないまま人を増やして納めました。担当者は「要件定義は営業活動なので請求できない」と説明しました。別の会社では、元請から渡された要件定義書に非機能の水準が書かれておらず、結合テストの段階で性能要件が判明して作り直しになりました。どちらも、作る力の問題ではありません。決めきる工程が、誰の商品にもなっていないという問題です。
私たちは、生成AIで取りに行ける付加価値を、「要件定義を、後工程の受注前提ではなく、それ単体で成立する商品として売れる会社」になることだと見ています。AIが仕様を考えるのではありません。承認済みの前提カードを大元にして、要件定義書の下書きと未確定事項の一覧を短時間で出し、顧客と決めきるまでの往復回数を減らす。そこで浮いた時間を、業務の例外や非機能の水準を掘る作業へ回せるかを実証します。
ここで大切なのは、速さを優先してAIに空欄を埋めさせないことです。確認していない業務ルールをもっともらしく書いた要件定義書は、社内のレビューを通っても、結合テストで壊れます。「承認済み」「未確定」「今回やらない」を文書上で区別し、未確定のまま見積もらないことが、この産業でAIを使う最低条件だと考えています。
提言 — どう付き合っていくか
1. 最初の1業務を「失注・赤字案件1件の要件定義のやり直し」に絞る
直近で赤字になった案件、または提案で失注した案件を1件選びます。当時の資料から前提カードを作り、顧客に承認された内容だけを載せます。AIには、その前提カードから要件定義書の下書きと、未確定事項の一覧を作らせます。新規案件ではなく終わった案件から始めるのは、答え合わせができるからです。当時どこが未確定のまま進み、どこで壊れたかが、そのまま自社の型になります。
2. 人が確定する項目を、前提カードの時点で分ける
業務ルールと例外、非機能の水準、連携先の制約、データ量、法令・社内規程、決裁経路、今回やらないことは、人が顧客と確定する項目として扱います。AIが根拠を見つけられない欄は補わせず、「未確定」と確認先・締切を表示させます。前提カードには承認者と更新日時を残し、古い前提のまま見積もらないようにします。
3. 要件定義を、単体で見積もれる商品として値付けする
前提カードと要件定義書の下書き、未確定事項の一覧、確定までの進め方を、後工程の受注を条件にしない単体のサービスとして値付けします。成果物、期間、顧客側で用意してもらうもの、含まれない範囲を明記します。ここを商品にできて初めて、実装工程の短縮が売上の減少ではなく、利益率の改善として現れます。
4. 確定までの日数と仕様変更の件数を測ってから、案件数を広げる
提案から要件確定までの日数、未確定事項の残数と消化率、要件確定後の仕様変更件数、そのうち追加請求できた件数を、導入前後で記録します。1案件で確定日数が短くなり、確定後の仕様変更が減ることを確認できたら、同じ業務領域の案件、別の顧客、元請から受ける案件の順に広げます。
最初から全案件の要件定義をAIに載せる必要はありません。まず終わった案件1件で、顧客が前提を承認する → AIが要件定義書と未確定事項を下書きする → 人が確定して見積りへ反映する → 決まった内容を前提カードへ戻すという一周を完成させることが、受託開発の仕様を商品にする具体的な一歩です。
出典・参照データ
本レポートの分析は以下の一次情報に基づいています。統計・数値の詳細は各出典をご確認ください。
- 企業IT動向調査報告書 2026（2025年度調査）一般社団法人 日本情報システム・ユーザー協会（JUAS）
調査概要（2025年9月5日〜10月24日実施、東証上場企業とそれに準じる企業4,500社のIT部門長が対象、回収957社・有効回答率21.3%）、図表7-1-4のプロジェクト規模別QCD遵守状況、図表7-1-6〜7-1-9の悪化要因と工程、図表7-1-11のトレンド、図表8-1-1と図表8-3-1のAI導入状況を引用
- 2025年版 情報サービス産業基本統計調査一般社団法人 情報サービス産業協会（JISA）
令和8年4月発行。調査概要（JISA正会員企業468社が対象・有効回答300社・回答率64.1%・2024年度の単独決算）、図表2-16と図表2-18の業務別構成、図表2-32の売上高外注費率、3.1.1の業態別外注費率と同業者比率、一人あたり売上高を引用
- JISA基本統計・主な指標の推移一般社団法人 情報サービス産業協会（JISA）
「情報サービス産業 基本統計調査」1993年版〜2025年版に基づく時系列として、売上高外注費率（1991年度20.99%→2024年度33.54%）とSIサービス売上高比率（1991年度19.96%→2024年度46.32%）を引用
- ソフトウェア開発分析データ集2022独立行政法人 情報処理推進機構（IPA）
収集5,546件のうち直近6年間（2016年度〜2021年度）が主対象で無作為抽出ではない旨、表1-3-2.1の外部委託の工数比率（N=562・中央値63.4%・平均58.6%）、表A3-3-8の工程別実績工数比率（新規開発N=270の中央値）を引用
- ソフトウェア開発分析データ集（一覧ページ）独立行政法人 情報処理推進機構（IPA）
「ソフトウェア開発分析データ集」の今後の発行予定がない旨の掲載を引用。工程別工数の公開データが2022年版で止まっている根拠として本文で扱う