目次
受託開発の見積もりは「時間の販売」でできています
システム開発を外注すると、見積書には「人月」が並びます。エンジニア1人が1か月働く作業量を単位に、単価を掛けて金額を出す方式です。要件が膨らめば人月が増え、金額が上がる。受託開発の価格は、成果ではなく作業時間を根拠にしてきました。IPAのソフトウェアモダナイゼーション委員会報告書も、ソフトウェア開発は「現在も人月ベースの契約が主流」だとしたうえで、AIの適用が進めば「成果の価値に基づく評価が求められるようになる」と述べています。
人月契約（工数課金）とは、成果物ではなく作業時間に対価を払う契約です。同じ「外注」でも、何に対価を払うかで、AIで実装が速くなった分の行き先が変わります。
| 契約の形 | 何に対価を払うか | AIで実装が速くなった分の行き先 |
|---|---|---|
| 請負（固定金額） | 完成した成果物 | 見積もりが変わらなければ受託側の利益に残る |
| 準委任・派遣（時間精算） | 作業時間 | 同じ時間で多く進むが、終わった量を測らなければ見えない |
| 成果対価 | 定義した成果や効果 | 発注側と受託側で分け合う。成果の定義が先に要る |
この方式が長く成立してきたのには理由があります。実装できる人手が希少で、かかる時間が成果の量にほぼ比例していたからです。何かを作りたければ、誰かの時間を押さえるしかない。発注側の予算取りも、稟議も、相見積もりの比較も、「実装には時間がかかるものだ」という前提の上に組み立てられてきました。
生成AIが崩しつつあるのは、個々の機能や品質の話の前に、まずこの前提です。
生成AIは「時間がかかるから高い」の根拠を崩します
生成AIの普及で、コードを書く工数は縮んでいます。どれだけ縮むかは対象や条件で大きく変わるため、ここで倍率を断定はしません。一方でMETRの開発者生産性の実験は、いまの開発者はAIで速くなっている可能性が高いとしつつ、AI利用が広がったことで速度差を実験で測ること自体が難しくなったと報告しています。ただ、弊社の受託の現場でも、実装そのものにかかる時間は明らかに短くなっています。かつて実装の主工程だった「書く」作業の多くを、AIが肩代わりするようになりました。
ここで、工数課金の構造が問題になります。かかった時間に対して対価が支払われる仕組みでは、作業が速く終わるほど請求できる金額は小さくなります。受託会社にとって、AIで生産性を上げることは、そのままでは減収を意味します。効率化のインセンティブが、ビジネスモデルと逆を向いている。ここに悪意は要りません。構造の問題です。
自社プロダクトを持つ会社なら、浮いた時間を自社の資産づくりに回せます。しかし、売り物が時間だけの受託会社には、その逃げ場がありません。実装の速さと量を売り物の中心にしてきた外注先ほど、この変化の影響を正面から受けます。受託業界の内側で危機感が語られているのは、このためです。
数字で見ると、値付けはすでに動いています
構造の話だけではありません。人月を売る側の値付けは、市場でも大手の方針でも動き始めています。
- インドのIT大手5社の時価総額合計は、2024年8月の33.71兆ルピーから2026年7月の18.15兆ルピーへ46%減りました（Business Today 2026年7月4日）。案件が消えたのではなく、生産性向上分が顧客への値下げに回った結果です。詳しくはインドIT大手5社の時価総額は2年で46%減りましたで整理しています
- NTTデータグループは2025年度に500件のプロジェクトへ生成AIを適用して開発工程全体で20%、2027年度には40%の生産性向上を目標に置き、社長は「50%生産性が上がって価格を変えないわけにはいかない」と述べています（日経クロステック 2025年11月）。派遣・準委任の側で何が起きるかは派遣技術者3万人がAIを持ちますで扱いました
売り手の側が価格に反映すると言い始めた以上、発注側の見積もりの読み方も同じ前提に更新する必要があります。
危機は「下がらない見積もり」として発注側に現れます
この構造は、受託会社だけの問題ではありません。発注側には、見分けの難しい形で現れます。
外から見えにくいのは、見積もりの中身です。受託先が社内でAIを使って実装を速くしていても、人月の見積もりを従来のまま出せば、差分は受託側の利益になります。逆に、AIを使っていない受託先の見積もりは、本当にその時間がかかります。同じ金額の見積書が2枚あっても、根拠はまるで違うかもしれない。発注側からは、どちらなのかがほとんど分かりません。
工数の妥当性を測るモノサシも古びていきます。過去案件の人月を基準に「この規模ならこれくらい」と判断してきた発注側の相場観は、実装が速くなった分だけ実態からずれていきます。金額から受託先の質を読み取る方法には適正価格の見方で整理したとおり以前から限界がありましたが、その限界はさらに広がっています。安くならないことではなく、安くならない理由を確かめられないことが、発注側にとっての危機です。
実装が縮むほど「何を作るか」が重くなります
開発の総工数が実装の分だけ縮む一方で、縮まない工程があります。
縮まない3つの工程
- 要件定義: 何を作るべきかを決める。曖昧なまま渡すと、AIは曖昧なものを高速に量産する
- 評価: できたものの良し悪しを測る。何を正解とするかの基準は発注側にしか決められない
- 運用: 動かし続け、変化に合わせて直す。速く作れるほど、直す回数も増える
むしろ実装が速くなるほど、これらの工程は重くなります。曖昧な要件を渡せば、AIは曖昧なものを高速に量産します。作り直しのサイクルが速くなるだけで、向かう先が正しくなるわけではありません。作る速度が上がった分、どこへ向かうかを決める精度が、プロジェクト全体の成否をこれまで以上に左右します。
弊社の受託でも、この比重の移動は進行中です。実装にかける時間が縮んだ一方で、日本側PMが発注側と要件を整理し、「何をもって良しとするか」の評価基準を言語化する時間の比重が増えました。ベトナム開発チームの仕事も、コードを書くことから、AIの出力をレビューし、テストし、運用の中で改善し続けることへ寄っています。実装の速さではなく、要件整理から運用改善までを一続きに回す体制が売り物になる。AIネイティブ開発と呼んでいる進め方は、この変化に対する弊社なりの答えです。日本側PMの担当範囲がどう動いたかはAI時代のオフショア開発で日本側PMが担う役割で具体的に扱っています。
受託先の選び方は、単価表の比較では済まなくなります
発注側にとって、この変化の意味ははっきりしています。受託先を選ぶ基準が変わる、ということです。単価の安さと人月レートの比較は、実装が希少だった時代の選び方です。実装が縮んだ今、確かめるべきは工程の中身に移ります。
見積もりを受け取ったときに確認する4項目
- AIの使い方と見積もりへの反映: 自社の開発プロセスでAIをどう使い、短縮した工数を見積もりにどう反映しているかを説明できるか
- 要件定義と評価の位置づけ: 何を正解とするかを決める工程を、見積もりの主工程として明記しているか
- 運用と改善の体制: 納品後の運用と改善を、誰がどの体制で担うかを提示できるか
- 契約の形: 請負・準委任・成果対価のどれで、AIで速くなった分の扱いが見積書に書かれているか
相見積もりの比較表や、受託先との初回の打ち合わせでそのまま確認項目として使えます
答えが具体的なら、その受託先は変化の当事者として、自分の商売を作り替えている最中です。答えが曖昧なら、時間を売る前提がまだ変わっていません。
そのうえで、もうひとつ大きな問いが残ります。受託先の中身が変わっても、契約が「時間を買う」形のままなら、速くなるほど受託側が損をする構造は消えません。発注側と受託側の利害を揃えるには、対価の払い方そのものを見直す必要があります。ではどう契約を変えるか。この問いは成果対価の契約で扱います。
実装が速くなった受託が売るもの
受託が売るものは、実装の速さから、何を作るかを決めて動かし続ける体制へ移っています。見積書の人月が減らなくても、その中で何が主工程になっているかを読めば、受託先が変化の当事者かどうかは分かります。
いまの外注先の見積もりがAIを前提に更新されているか確かめたい。次の開発をどの前提で発注すべきか迷っている。そうした段階のご相談から対応します。お問い合わせからお聞かせください。