人月見積もりで食べてきた皆さんは今、「AI時代に、この見積もり詐欺なんじゃないか？」と悩まされているのではないでしょうか。
実装も設計書の執筆もAIがやるようになると、人月で積み上げるものがなくなります。
では開発費は何で決まるのか。よく出てくるのは「顧客が得る利益の何%か」という成果報酬の発想ですが、私はそれも少しずれていると思っています。
この記事の主張はひとつです。ベンダーが取れる金額の上限は、「お客さんが自分でAIを使ってやったらいくらかかるか」で決まる。
これは私の思いつきではなく、価格戦略の教科書に昔からある考え方の応用です。証拠と一緒に、具体的な計算方法まで落とします。
見積もりが「時間」なのは、価値ではなく原価の都合
顧客が欲しいのはシステムであって、ベンダーの労働時間ではありません。
それでも人月が生き残ってきたのは、作業に人手がかかり、その人件費が原価の大半を占めていたからです。原価を積み上げておけば、とりあえず赤字にはならない。
人月の危うさ自体は昔から知られています。Frederick Brooksが『人月の神話』で、人と月が交換できるのは互いに連絡を取らずに分担できる仕事だけだと指摘したのは1975年です。
IPAのソフトウェア開発データ白書は、2018-2019年版で「工期は工数の3乗根に比例する傾向」を示しています（2016-2017年版は4,000件以上のプロジェクトを収録）。こうした回帰式はどれも、人間のチームが手を動かす前提で作られています。
ここで思考実験として前提を置きます。
- 実装と設計書の執筆コストはほぼゼロ
- AIの利用料も考えない
- 顧客との会議やコミュニケーションのコストは残る
この前提だと、人月で積み上げる対象がほぼ消えます。原価の積み上げで値段を決める方法は、ここで使えなくなります。
作るコストは本当にゼロに近づいているのか
正直に書くと、2026年時点で「実装ゼロ」はまだ思考実験です。証拠ははっきり割れています。
小さな新規の課題なら、半分以下の時間で終わる。 MicrosoftとGitHubの研究者による2023年の対照実験では、JavaScriptでHTTPサーバーを実装する課題で、Copilotを使ったグループは使わないグループより55.8%速く終えました（Peng et al., 2023）。
成熟した大規模コードベースでは、逆に遅くなる。 METRが2025年2〜6月に行ったランダム化比較試験では、大規模OSSに何年も関わってきた開発者16人が実タスク246件に取り組みました。AIを使うと完了までに19%長くかかり、本人たちは事前に24%速くなると予想していました（InfoQの解説）。
方向としては作るコストは下がっていく。ただ、どこまで下がるかは対象によってまったく違う。
以降は「作るコストが十分小さくなった世界」の話として読んでください。そこまで行かなくても、作るコストが下がるほどこの記事の式は効いてきます。
値段の上限は「お客さんの代替手段」で決まる
価格戦略の教科書には、もう書いてある
マーケティングには「顧客にとっての経済価値（EVC: Economic Value to the Customer）」という考え方があります。1979年のForbisとMehtaの論文が起点で、Thomas Nagleの『The Strategy and Tactics of Pricing』で体系化されました。式はシンプルです。
経済価値 ＝ 参照価値（顧客にとって次善の代替手段の価格）＋ 差別化価値（代替手段より上乗せされる価値）
顧客は、次善の策との差分以上には払いません。交渉学のBATNA（交渉が決裂したときの最善の代替案。FisherとUryが1981年の『Getting to Yes』で提唱）も、同じことを交渉の側から言っています。
AI以後に変わるのは「次善の代替手段」の中身
これまで、システム開発の代替手段は「別のベンダー」でした。だから相見積もりで比べるのも人月単価でした。
作るコストがゼロに近づくと、代替手段に「顧客が自分でAIを使って作る」が加わります。ベンダーの競合は他社ではなく、お客さん本人とAIになる。
すると、ベンダーが取れる金額の上限はこう書けます。
ベンダーの上限 ＝ 顧客が自分でやる場合の総コスト − ベンダーに頼んでも顧客に残るコスト
「利益の何%」は上限の上限でしかない
顧客がシステムから得る利益は、払える金額の天井ではあります。ただ、実際にはその手前で、自分でやる場合のコストが天井として効いてきます。
利益が1億円出るシステムでも、顧客が200万円分の手間で自作できるなら、ベンダーに200万円以上払う理由はありません。
下限はベンダー自身の原価（会議、検証、責任を負うためのコスト）です。上限と下限のあいだが、交渉学でいうZOPA（合意可能な範囲）になります。
「自分でやったらいくら？」を5つに分解する
ここからは私の整理です。実装がゼロでも、顧客が自分でやるときに消えないコストは5つあります。
| コスト | 中身 | ベンダーが減らせるか |
|---|---|---|
| 決めるコスト | 何を作るか、どこまでやるかを決める時間 | ほぼ減らせない（論点の整理まで） |
| 翻訳コスト | 業務の言葉を、AIに渡せる仕様に落とすまでの試行錯誤 | 大きく減らせる |
| 検証コスト | できたものが正しいか、業務で使えるかを確かめる時間 | 一部減らせる（テスト観点の設計など） |
| 責任コスト | 障害や情報漏えいが起きたときの損失 × 起きる確率 | 契約で引き受けられる |
| 立ち上げコスト | AIや開発環境を使える状態にし、使い方を覚える時間 | ほぼゼロにできる |
ポイントは、決めるコストはベンダーに頼んでも顧客から消えないことです。最終的に決めるのは顧客だからです。
ベンダーが値段をつけられるのは、残り4つのうち「顧客自身がやると高くつく部分」だけです。
架空の例で計算してみる
以下の数字はすべて説明用の仮の値です。 実データではありません。
従業員50人の会社が、紙とExcelで回している受発注を業務アプリにしたいとします。担当は総務課長で、時間単価は仮に5,000円。扱うのは取引先の情報なので、漏えいしたときの損失を2,000万円と置きます。
| 項目 | 課長が自分でAIと作る | ベンダーに頼む（課長に残る分） |
|---|---|---|
| 決める | 20時間 | 20時間 |
| 翻訳 | 80時間 | 10時間（ヒアリングに答える） |
| 検証 | 40時間 | 15時間（受け入れ確認） |
| 立ち上げ | 20時間 | 0時間 |
| 時間の合計 × 5,000円 | 160時間 = 80万円 | 45時間 = 22.5万円 |
| 責任（2,000万円 × 発生確率） | 確率5%で100万円 | ベンダーが確率1%に下げて引き受け、課長側は0円 |
| 合計 | 180万円 | 22.5万円 |
ベンダーの上限は 180万円 − 22.5万円 ＝ 157.5万円。
下限はベンダー側の原価で、作業30時間 × 1万円 ＝ 30万円に、引き受けた責任の期待損失 2,000万円 × 1% ＝ 20万円を足して 50万円。交渉の余地は50万〜157.5万円です。
数字を動かすと見えること
- 担当が社長（時間単価2万円）なら、上限は330万円に上がる。 自分でやると420万円、頼んでも90万円が残るからです。偉い人の時間ほど高く、ベンダーの取り分が増えます。
- AIが賢くなって翻訳と検証が半分以下になると、上限は117.5万円に下がる。 自分でやるコストは140万円になり、そのうち100万円が責任コストです。
- 扱うデータが漏れても困らないものなら、責任コストが消えて上限はほぼ時間代だけになる。 ここが「ベンダー不要」に一番近い状態です。
面白いのは、このシステムが会社にいくら利益をもたらすかが、計算に一度も出てこないことです。
もうひとつ、AIが進むほど上限に占める責任コストの割合が大きくなります。最後にベンダーが売るのは、作業ではなく「責任を引き受けること」になっていきます。
日本ではまだ代替手段が高い。ただし長くは続かない
日本のIT人材の7割以上はベンダー側にいる。 IPAのIT人材白書2017では、IT企業に所属するIT人材の割合は日本が72.0%、米国が34.6%でした。DX白書2023で更新された数字でも、日本（2020年）は73.6%、米国（2021年）は35.1%で、ほとんど変わっていません（クラウド Watch）。
日本の発注側には、作れる人も確かめられる人も社内にいないことが多い。翻訳コストと検証コストが高いので、ベンダーの上限は高く残りやすい構造です。
ただしこれは「ベンダーが価値を出しているから」ではなく、「お客さんの代替手段が弱いから」です。AIは翻訳コストを下げる方向に効くので、この余白は削られていきます。
代替手段が安くなった市場では、腕のいい人ほど値段を守れない。 Hui、Reshef、Zhouの研究（Organization Science, 2024）は、ChatGPT公開後のUpworkで、文章系フリーランスの月間案件数が2%、月間収入が5.2%減ったと報告しています（Olin Business School）。過去の実績が高い上位層ほど影響が大きいという示唆も出ています（INFORMS）。著者たち自身が短期の効果だと断っている点は割り引いてください。
成果が数えられる領域では、値段はもう「置き換えた作業」に寄っている。 Intercomの顧客対応AI「Fin」は解決1件0.99ドル、HubSpotは1会話1ドルから、解決した会話1件0.50ドルに切り替えました（SaaStr）。比べられているのは人間のサポート担当者の人件費、つまり顧客の代替手段です。
プロセスモデル別に当てはめる
ウォーターフォールやアジャイルは「開発手法」とよく呼ばれますが、正確にはウォーターフォールや反復型は工程の並べ方の型（プロセスモデル）です。アジャイルは価値観と原則の総称で、スクラムはスクラムガイドが自らを軽量級フレームワークと定義しています。ここではまとめてプロセスモデルと呼びます。
| プロセスモデル | 顧客が自分でやると高くつく部分 | ベンダーが値段をつけられる所 |
|---|---|---|
| ウォーターフォール | 最初に要件を決め切る（決める・翻訳が前半に集中） | 要件定義の進行、承認の区切りの設計 |
| 反復型・スパイラル | どのリスクから潰すかの判断 | リスクの洗い出しと検証計画 |
| プロトタイピング | 試作を見て選ぶだけなら安い | 少ない（代替手段が一番安いモデル） |
| アジャイル（スクラム） | 毎スプリントの意思決定と受け入れ | プロダクトオーナーの補佐、検証の代行 |
ウォーターフォールは「後から変えると高い」、アジャイルは「作る前に確かめないと無駄が出る」という前提で生まれました。作るのも作り直すのもタダになると、どちらの前提も崩れます。
残るのは「決める」と「確かめる」の往復だけです。プロセスモデルの違いは、その往復をどういう段取りで回すかの違いでしかなくなります。
【そして見積もり不要の世界へ】この計算、お客さんがAIにやらせます
ここまでベンダー目線で書いてきました。
しかしこの計算式は、顧客がAIに「これ、自分でやったらいくら？」と聞けば、そのまま顧客側で回せます。
そうなると、見積書は「人月の積み上げ」ではなく「自分でやった場合との比較表」として読まれます。
ベンダーが書くべきなのは「何人月かかるか」ではなく、「あなたが自分でやると、翻訳と検証と責任でこれだけかかる。うちに頼むとここまで減る」という差分の説明です。
その差分を説明できないベンダーは、相見積もりの相手が他社ではなく、お客さんとAIのペアだと気づかないまま負けていきます。
そして、上で見たとおりAIが進むほど差分の中身は責任コストに寄っていきます。最後まで残るベンダーの仕事は、たぶん「一緒に決めること」と「何かあったら責任を取ること」です。どちらも、人月では見積もれません。
なお、この記事もAIと壁打ちしながら書いています。自分で書いていたら何時間かかったかは、怖いので計算していません。
おわりに：コメント欄で見積もってください
5つのコストの分け方も、架空の例の数字も、まだ粗い叩き台です。
「うちの業界の代替手段はそれじゃない」「責任コストの見積もりが甘い」といった指摘を待っています。
あなたの次の案件の「お客さんが自分でやったらいくら？」も、よければコメント欄に置いていってください。
参考文献
- Frederick P. Brooks Jr.『人月の神話』（原著1975年）
- IPA「ソフトウェア開発データ白書2018-2019」
- Sida Peng ほか「The Impact of AI on Developer Productivity: Evidence from GitHub Copilot」（2023年）
- METR「Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity」（2025年、InfoQの解説）
- Thomas Nagle ほか『The Strategy and Tactics of Pricing』
- Roger Fisher、William Ury『Getting to Yes』（1981年）
- IPA「IT人材白書2017」、「DX白書2023」（クラウド Watch）
- Xiang Hui、Oren Reshef、Luofeng Zhou「The Short-Term Effects of Generative Artificial Intelligence on Employment」Organization Science（2024年、INFORMS）
- SaaStr: HubSpot Switching AI Pricing From Per Use To Per Resolution
- スクラムガイド 2020年11月版（日本語）