人月見積もりが崩壊する：AIがコードを書く時代の「見積もりの新常識」

受託開発の世界には、昔から便利な“共通言語”があります。
それが 人月（にんげつ）──「1人が1か月働く分の工数」という見積もり単位です。

ところが今、AIがコードを書く時代になって、この人月が現場で静かに壊れ始めています。
もっと正確に言うと、壊れやすいチームほど、壊れる。

AI支援で“手が速い”チームほど、同じ要件でも実装が早く終わる。
すると発注側はこう思います。
• 「え、3人月って言ってたのに、もう動いてるじゃん」
• 「じゃあこれもついでに入れられるよね？」
• 「AI使ってるなら、もっと安くできるでしょ？」

一方、受注側はこうなる。
• 「コードは書けた。でも、品質保証と責任範囲が曖昧だ」
• 「“動く”と“使える”は違うのに、検証条件が決まってない」
• 「結局、レビュー・テスト・仕様調整で時間が溶ける」

このすれ違いが、見積もりの崩壊です。
そして崩壊した見積もりの先に待つのは、発注側・受注側どちらにとっても不幸な結末です。

なぜ人月見積もりはAI時代にズレるのか

人月見積もりは、暗黙にこう仮定しています。

かけた労働（時間と人数）に比例して、成果が出る

でもAIが入ると、この比例関係が崩れます。理由は大きく3つです。

1) 「書く」工数だけが極端に短縮される

AIが速いのは主に コーディング。
一方で、次の領域は短縮されにくい（むしろ増えることもある）。
• 要件の穴埋め（“どうあるべきか”の決定）
• アーキテクチャ設計と整合性
• 既存資産との統合、データ移行、運用設計
• テスト戦略、非機能要件（性能・セキュリティ・可用性）
• レビュー、監査、説明責任（とくに企業案件）

AIで「作る」速度が上がるほど、“決める・確かめる・守る”が相対的に重くなります。

2) 速いほど「追加要求」が増える（スコープが溶ける）

人は、進捗が速い相手に対して要求のハードルを下げます。
• 「ここまでできるなら、あと少し…」
• 「せっかくだから、画面ももう1枚…」
• 「エラー時の挙動も全部整えて…」
• 「運用の自動化もついでに…」

AI支援で“手が速い”チームほど、要求が増える速度も上がる。
結果、最初の人月は簡単に説明できなくなります。

3) “品質の責任範囲”が曖昧なまま契約しやすい

AIが書いたコードは、動くことが多い。
だからこそ危ない。
• 動くけど、例外系で壊れる
• 動くけど、将来の拡張で破綻する
• 動くけど、脆弱性やライセンスの地雷が混ざる
• 動くけど、チームが保守できない

「動いたからOK」なのか
「本番運用に耐える品質」なのか
「監査に通る証跡」まで含むのか

ここが曖昧なまま“人月”だけ握って走ると、だいたい揉めます。

見積もりとは、工数表ではなく「合意の設計図」だ

私がずっと言っているのは、これです。

見積もりは、未来を当てる占いではない
不確実性を“合意可能な形”に落とす技術だ

AI時代は、ここがより重要になりました。
なぜなら、実装速度が変動しやすくなった分、合意が固定されていないと契約が破裂するからです。

つまり、見積もりの主役は「人月」ではなく、
• 成果物の定義
• 検証条件
• 品質の責任範囲

この3点セットになります。

AI時代にフィットする「見積もり単位」3つ

ここからが本題です。
人月を完全に捨てろ、という話ではありません。
ただ、人月“だけ”で握るのは限界です。

現場で強いのは、次の3つの単位です。

1) 成果（成果物）ベース：アウトカム／デリバラブル見積もり

「何を納品したら完了か」を先に決める方式です。
• 機能一覧（ユーザーストーリー）
• 画面・API・バッチなど成果物の範囲
• 受け入れ基準（テスト条件）
• 非機能要件（性能・セキュリティ・運用）

これが明確な案件ほど、成果物見積もりは強い。
AIで実装が速くなっても、契約上の“完了の定義”がブレないからです。

向いているケース
• 要件がある程度固まっている
• 納品物が明確
• 発注側が受け入れテストを回せる

注意点
• 受け入れ基準が曖昧だと地獄を見る（後述のテンプレで防ぐ）

2) スプリント（タイムボックス）ベース：固定期間×優先順位で握る

「2週間でここまでやる」を繰り返すやり方です。
見積もりは、機能単位よりも “スプリント単価” で握ります。
• 1スプリント：◯円
• ベロシティ（消化できる量）は実測で更新
• スコープは優先順位で調整する

AI時代、要件は変わる前提で動く案件が増えました。
そのとき、人月よりスプリントの方が揉めにくい。

向いているケース
• 要件が流動的
• 早く試して学びたい（PoC〜MVP）
• 発注側もプロダクト側の意思決定に参加できる

注意点
• 「何をもってDoneか（Definition of Done）」が合意されていないと、速さだけが正義になって品質が死ぬ

3) 検証ベース：証拠（エビデンス）に値札を付ける

AI時代に一番効くのがこれです。
“できた”の証拠を納品物にします。

例：
• 性能試験の結果（想定負荷での応答時間）
• セキュリティ診断の結果（指摘ゼロ or 対応完了）
• E2Eテストの自動化と実行ログ
• 監査向けの設計・変更履歴（トレーサビリティ）

AIがコードを書けるようになっても、
「このシステムが安全に運用できる」ことを証明するのは別仕事です。

向いているケース
• 本番運用・規制・監査が絡む
• 品質の“体感”ではなく“証跡”が必要
• 発注側が品質リスクに敏感

注意点
• “何を検証するか”が曖昧だと形骸化するので、ここもテンプレで握る

合意形成テンプレ：前提／除外／受け入れ基準（これだけは必須）

AI時代の見積もりで揉める原因は、9割これです。
• 前提が書かれていない
• 除外が書かれていない
• 受け入れ基準が書かれていない

人月がどうこう以前に、契約が成立していない状態でスタートしている。

ここで、私が見積書・SOW（作業範囲記述書）に必ず入れるテンプレを共有します。
そのままコピペして使ってください。

テンプレ：前提／除外／受け入れ基準

【前提（Assumptions）】
◾️ 発注側が提供する情報／素材／権限：
• 例：API仕様、既存DB定義、テスト用アカウント、デザインデータ、VPN、SSO設定情報
◾️ 対象環境：
• 例：クラウド（AWS/GCP/Azure）、リージョン、OS、DB、ブラウザ対応範囲
◾️ 利用する外部サービス／ライブラリ：
• 例：決済、メール、地図、認証基盤、LLM APIなど
◾️ AI支援の利用方針（必要なら明記）：
• 例：機密情報の入力禁止、生成コードは人がレビュー、OSSライセンス確認を実施

【除外（Out of Scope）】
◾️ 今回やらないこと（“当然やるでしょ”を潰す）：
• 例：運用監視設計、SRE対応、24/365保守、データ移行、既存不具合の全面改修、端末検証、脆弱性診断の実施（別途）
◾️ 将来やるかもしれないが、現時点で未確定なもの：
• 例：多言語化、権限管理の高度化、管理画面の拡充、レポート機能、外部連携追加

【受け入れ基準（Acceptance Criteria）】
◾️ 機能要件の完了条件：
• 例：ユーザーがメール＋パスワードで登録→ログイン→ログアウトできる
◾️ 例外系・エラー時の挙動：
• 例：パスワード間違い、ロック、再送、二重送信防止
◾️ 非機能要件：
• 例：同時◯◯件で平均応答◯◯ms以内、OWASP相当の基本対策、監査ログ保持◯日
◾️ テストと証跡：
• 例：単体テストカバレッジ◯%、E2Eテスト◯本、CIで全テスト通過ログ提出
◾️ ドキュメント：
• 例：運用手順、設定手順、API仕様、障害時切り分けガイド

ミニ例：ログイン機能を「揉めない」形にする

悪い例：
• 「ログイン機能を作る」：以上

良い例（受け入れ基準がある）：
• 「メール＋パスワードでログインできる」
• 「パスワードリセットができる」
• 「5回失敗で15分ロック」
• 「ログインログが監査ログとして保存される」
• 「E2Eテストで主要シナリオを自動実行し、CIログを提出する」

同じ“ログイン”でも、工数は全く違う。
そしてAI時代は、“差分の大半が実装ではなく検証と運用”に寄っていきます。

「AIで速い」のに燃える案件で必ず起きていること

私は燃える案件を見るたびに、同じパターンを確認します。

パターンA：成果物が「コード」になっている

発注側が欲しいのは、コードではなく 動くシステムです。
さらに言えば、欲しいのは 事業の成果です。

コードが速く書けても、
• デプロイできない
• データが整合しない
• 監視がない
• 障害対応できない

これでは価値になりません。

対策：成果物を「動作」「運用」「検証」に寄せる

パターンB：品質の責任が宙に浮いている

「バグが出たら直します」は聞こえは良いですが、
“どこまでがバグで、どこからが仕様追加か”が曖昧だと戦争になります。

AI時代は、実装速度が上がって変更頻度も上がる。
だからこそ、受け入れ基準と変更管理が必須です。

対策：
• 受け入れ基準にないものは追加（チェンジ）
• チェンジの単位を「スプリント」か「成果物追加」で握る

パターンC：「AIを使うなら安いはず」という誤解

AIで速くなるのは確かです。
でも“速い＝安い”ではありません。

なぜなら、企業の開発費用の多くは「入力」より「出力の確からしさ」に払われるからです。
• セキュリティ
• 信頼性
• 保守性
• 監査対応
• 運用負債の最小化

ここにコストが乗ります。AIは魔法ではなく、加速装置です。
加速するほど、ハンドル（合意）とブレーキ（検証）が要ります。

発注側が“損しない”ための質問リスト

最後に、発注側の方が見積書を受け取ったとき、ぜひ投げてほしい質問を置いておきます。
これを聞けば、AI時代の地雷をかなり踏みにくくなります。
• 完了の定義は何ですか？（コード？本番リリース？運用開始？）
• 受け入れ基準はどこに書かれていますか？
• 例外系（エラー時）はどこまで含みますか？
• テストは誰が、どの範囲を、何を証跡として残しますか？
• 非機能（性能・セキュリティ・監視）は見積もりに含まれていますか？
• AI支援を使う場合、レビューと品質責任はどう担保しますか？
• 仕様変更が出たときのプロセスと単価はどうなりますか？
• 保守・保証の範囲（期間・SLA）はどうなりますか？

この質問に対して、言語化された答えが返ってくる会社は強い。
逆に、曖昧に濁す会社は、だいたい後で揉めます（発注側も受注側も）。

結論：人月は“補助輪”に降格する。主役は「成果・スプリント・検証」

AIがコードを書く時代、見積もりの新常識はこうです。
• 人月で未来を当てに行かない
• 成果物・検証条件・品質責任を合意する
• 成果／スプリント／検証の単位で契約を設計する

人月が完全に不要になるわけではありません。
ただ、AIでチームの速度が変動する時代に、人月だけを主役にすると、必ず歪みが出ます。

見積もりとは、信頼の設計です。
AI時代は、その設計図を「工数表」から「合意テンプレ」に進化させる。
これが、発注側も受注側も幸せになる最短ルートだと私は思っています。