人月商売、崩壊が鮮明に
AIコード生成の普及が、IT受託業界を支えてきた「人月見積もり」の前提を根底から覆しつつある。わずか3カ月で顕在化した変化は、受託・発注の両側に直撃する。
人月が「正しかった」時代の論理
「人月（にんげつ）」とは、一人の技術者が一カ月間かけてこなせる仕事量を1単位とする見積もり手法だ。1970年代にアメリカで体系化され、日本のSIer文化に深く根を張った。この手法が数十年にわたって機能した理由は単純だ——ソフトウェア開発の生産性向上が緩やかだったからである。
コードを書くのは人間であり、その速度は個人差があれど一定の範囲に収まっていた。要件を聞いてから設計し、実装し、テストし、納品するまでのサイクルは、ツールが変わっても月単位で動いていた。発注側も受託側も、「3人が6カ月かかれば18人月」という計算を疑わなかった。
リスク配分も明確だった。工数が増えれば請求が増え、工数が減れば利益が出る。受託側は見積もりの精度を磨くことで競争優位を得た。発注側は工数を管理することでコストをコントロールできると信じていた。この構造が崩れるには、開発速度そのものが桁違いに変わる必要があった。
AIコード生成が壊した人月の数学
問題の核心は速度だ。GitHub CopilotやCursor、そして各社が社内展開するコード生成AIは、定型的な実装作業を10倍以上のペースでこなす。これはある種のタスクについて、1人月で終わっていた仕事が3〜4日で完了することを意味する。
業界観測によると、AIコード生成ツールが実プロジェクトに本格導入された2026年第1四半期から、一部のIT受託案件では工数が従来比60〜80%減少し、わずか3カ月で採算ラインが崩れ始めたという。これは受託側の問題であると同時に、発注側の比較優位の問題でもある。人月単価を払う理由が薄れれば、外注そのものの正当性が問われる。
さらに深刻なのは、この変化が「じわじわ来る」ものではなく、特定のプロジェクトや顧客から突如として顕在化する点だ。技術に詳しい発注担当者が「なぜこの機能に2カ月かかるのか」と問い始めた瞬間、従来の見積もり根拠は崩壊する。
今すぐ動くべき人、様子を見るべき人、無関係な人
この変化は全員に等しく降りかかるわけではない。現時点での立場で対応の緊急度は大きく異なる。
今すぐ動くべき：人月で見積もっている受託事業者
最も直撃を受けるのは、今もなお人月単価で顧客に請求している受託IT事業者だ。技術系の発注担当者を持つ顧客がAIコード生成の実態を把握し始めた今、「なぜ3カ月かかるのか」という問いに答えられない受託会社は、契約更新時に価格交渉で追い詰められるリスクが現実化している。アウトカムベース（成果報酬型）への転換を今から設計しなければ、来期には手遅れになる可能性がある。
動向を注視すべき：エンタープライズの発注担当者
人月契約で外部ベンダーに仕事を出している企業の調達・IT部門は、自社の契約内容を今すぐ見直す好機にある。ただし「AIを使えば安くなるはず」という単純な値下げ圧力は逆効果になることもある——質の低下や責任所在の曖昧化というリスクと引き換えになりうるからだ。成果指標と品質保証の再定義が先決だ。
当面は影響が小さい：アウトカムベースの内製チーム
すでに成果指標でチームを評価し、開発工数を外部に開示していない内製開発組織は、この変化の恩恵を享受しやすい。AIツールの導入によってスループットが上がっても、契約上のコスト構造を変える必要がないからだ。ただし、それは「何もしなくていい」ではなく、「先行して恩恵を受けられる立場にある」という意味だ。
人月という単位は消えても、ソフトウェア開発の価値そのものが消えるわけではない。問われているのは、その価値をどう測り、どう契約し、どう分配するかという根本的な再設計だ。