「AIで開発が速くなるなら、外注費も下がるはずだ」——そう考えるのは自然です。しかし実際には、AIを導入したというベンダーに発注していても、見積りも毎月の支払いも変わらない。原因の多くは、生成AIの使い方がコードを書く時間を削るだけの域にとどまり、費用が動くほど総工数が減っていないことです。本コラムでは、外注費を「量×単価」「作業の対価＋判断と責任の対価」に分解するところから始めて、費用を実際に下げる3つの経路——要員枠の縮小、工程を分離した発注、内製化——と、そのすべての前提になる自社での実測、発注側が骨格を用意するRFPの作り方、人月単価の先にある「責任の値段」までを扱います。
いま多くの発注側が、同じ行き違いの中にいます。「AIで開発は安くなるはずだ」という期待がある。ベンダーは「AI駆動開発を導入済みです」と言う。それなのに、毎月の支払いも、次の案件の見積りも、目に見えては変わらない。誰かが嘘をついているのか、どこかで手を抜かれているのか。
どちらでもありません。行き違いの原因は、「外注費」という金額を、何にいくら払っているのか分けないまま議論していることにあります。分けると、AIで動く場所と動かない場所がはっきりします。
毎月の支払いは、何人月買うか(量) × 1人月いくらか(単価) の掛け算です。そして単価に含まれているものは、2種類に分かれます。
AIが下げうるのは、作業の対価だけです。それも総額ではなく差し引きで下がります。生成が増えた分、レビューと検証という作業が逆に増えるからです(実装で浮かせた分の反動は、必ずどこかの検証に出ます)。判断と責任の対価は、AIでは下がりません。そして量は、発注側が減らさない限り減りません。
「AIを入れたのに費用が下がらない」の答えは、この分解にほぼ尽きます。以下、契約形態別に確かめます。
SESでも請負でも、外注費は自動では1円も減らない。減らすには発注側の作為が要る。
SES・準委任が買っているのは量(稼働時間)です。枠(人数×稼働時間)をそのままにすれば、量も単価も動かないので、費用は1円も変わりません。しかも稼働時間のうちAIが効く作業(実装・テスト・ドキュメント)はもともと一部で、残りは会議・調整・仕様確認・待ちです。AIが縮めるのは作業の部分であって、稼働時間という器ではない。「実装2倍速＝アウトプット2倍」にすらなりません。
枠を減らせば費用は下がります。ただし何人分減らせるかは、「AIを入れた」という事実ではなく、総工数がどれだけ減ったかの実測値で決まります。道具を配っただけの現場で浮くのは10人中1人分あるかどうか。半減は、レビュー・検証・承認まで工程を組み替えた組織にしか起きません。根拠なしに削れば品質の劣化として返ってきます。誰が何を根拠に枠を削るか——これが経路1です。
請負が買っているのは成果物で、金額は契約時に固定です。ベンダーが総工数を減らせていれば、その差分はベンダーの粗利になります。もっとも、これ自体は乗り換えで解ける問題です。本当に工数を減らせているベンダーが市場にいるなら、相見積りで安いところに出せばいい。実際の問題はその手前にあります。「本当に減らせているベンダー」を、見積書と営業資料から見分けられないことです。この識別の問題は、次章で扱います。
その前に、下げる経路を並べておきます。分解式の項に対応して3つです。量を減らす(経路1)、単価の内訳を割って作業の相場低下を届かせる(経路2)、そもそも買わない(経路3)。
いずれも自社の実測値がないと交渉が成立しない。そして、いずれも「決める側」のコストを増やす。
共通の前提は、自社で小さい開発を1本AI駆動で実施して工数の実測値を持つこと。外注費の削減とは、支出の一律カットではなく、内製と外注の線の引き直し。
経路の各論に入る前に、前章で棚上げにした問いを片付けます。ベンダーの言う「AI駆動開発を導入済み」で、費用が動くほど総工数は減っているのか。
まず、何を「減った」と数えるかをはっきりさせます。見るべきはコード生成の速さではなく、テスト・レビュー・結合まで済んだ成果物一式が、前より少ない総工数で出てくるようになったかどうかです。
この定義に照らすと、いま多くの現場で起きているのは、この意味での工数削減ではありません。生成AIの使い方が、お遊びの域にとどまっているからです。
コーディングを速くする道具は、今に始まったものではありません。コピペ、ライブラリ、フレームワーク、IDEの補完。コードを書く作業は何十年も前から短縮され続けてきました。Gartner(米国の大手ITリサーチ・アドバイザリー会社)が「コーディングがボトルネックだったためしがない」と指摘するのはこのことです。開発の時間を実際に食ってきたのは、書くことではなく、確かめることと擦り合わせることでした。
そして、自分で書いたコードは、書きながら確認と調整が済んでいます。生成されたコードは、どれほど正しくても他人のコードです。読み直し、意図と突き合わせ、既存のコードの文脈に馴染ませる作業が、別に立ちます。2026年の調査では、開発者がAI生成コードのレビューに使う時間(週11.4時間)が、自分でコードを書く時間(週9.8時間)を上回ったという報告が出ています。開発の主戦場は、もう書くことではなく確かめることです。
この確認コストがどれほど効くかを、METR(AI評価を専門とする米国の非営利研究機関)の対照実験が数字にしています。2025年の実験では、経験豊富な開発者がAIを使うと平均19%遅くなり、本人たちは「20%速くなった」と体感していました。2026年の追試(57名・800タスク超)では、エージェント型に進化した道具と使い方の変化で、同じ測定が平均18%の高速化へと反転しています。1年で符号が変わるほど、結果は道具と使い方の設計に依存する——だから体感や「導入済み」の看板ではなく、測定で確かめるしかありません。
つまり、チャットにコードを書かせて貼り付ける——コードを書く時間だけを削る使い方は、コピペやライブラリの時代から続いてきた短縮の延長でしかなく、増えた確認コストで相殺されます。費用が下がり切らないのは当然です。実際、2026年に12万人超の開発者を分析した調査では、93%がAIを使っているのに、組織のスループット(プルリクエストの消化量)は1割しか増えていませんでした。個人が使っていることと、組織の総工数が減ることの間には、それだけの距離があります。総工数が減ると言える規模になるのは、確かめること自体を作り替えたとき——テストと検証の自動生成、ドキュメント・管理資料まで含めた工程の組み替え——だけです。DORA(Google Cloud傘下の開発組織研究プログラム。年次のState of DevOpsレポートで知られる)の最新の調査でも、統制の整った組織でだけスループットが上がり、そうでない組織では不安定さが増幅されると報告されています。
前章の問いに答えが出ました。総工数の削減は、体制を組み替えた現場でしか起きていない。そして起きているかどうかは、「AI導入済み」の看板からは判別できない。発注側が自分で確かめる方法が実測で、これは経路の各論の後、第6章で扱います。
時間を買う契約で費用を下げる方法は、原理的にひとつしかありません。買う時間を減らすことです。スループットが上がった分だけ要員枠(人数×期間)を縮めたとき、初めて工数の減少が費用の減少になります。
前提になるのは、スループットの実測です。「AIで速くなったはずだから枠を減らしてほしい」では交渉になりません。ベンダーは「案件の性質上、効果は限定的です」と返せますし、それが事実かどうかを発注側は判定できません。
だから、枠の交渉より先に測定の設計が要ります。何を測るかを決めて、現在の値を取っておくことです。使いやすい指標は、月あたりの消化チケット数、リリース頻度、改修1件あたりのリードタイムあたりです。厳密である必要はなく、枠を1名減らしたときにスループットが維持できているかを判定できれば足ります。
進め方も、いきなり全体を削るのではなく、1名分を減らして四半期様子を見る形が現実的です。維持できていればもう1名、劣化したら戻す。この往復ができる状態を作ること自体が、ベンダー任せだった生産性を発注側の管理下に置くことを意味します。
注意点がひとつあります。枠を削る交渉は、ベンダーにとっては純粋な減収なので、AI活用への協力動機を削ぎます。長く付き合うベンダーに対しては、削った枠の一部を別の発注(後述する要件定義支援や、内製化の伴走)に振り替える形のほうが、関係としては持続します。
請負の固定価格が下がらないのは、内訳がブラックボックスだからです。「一式 3,000万円」の中で実装工程が何割を占めるのかが見えなければ、実装の相場が下がってもそれを価格に反映させる交渉の足場がありません。
しかも、実装の直接費は見積り総額の一部にすぎません。元請けの間接費(営業・管理・オフィス)と多重下請けの各層のマージンが厚く積まれた見積り構造では、仮に実装工数が半分になっても、総額はその何分の一しか動かない計算になります。「AIを導入したはずなのに見積りがほとんど変わらない」の一因はここにあり、実装の効率化だけを追及しても、この構造には届きません。
対応は、発注の単位を割ることです。要件定義、設計・実装、テスト、保守を分けて発注すれば、工程ごとに見積りの根拠を問えるようになり、実装工程については「AI駆動を前提とした場合の工数」で相見積りが成立します。実装だけをAI駆動に強いベンダーに出す、という選択肢も生まれます。
ただし、この経路には明確な代償があります。一括請負でベンダーが負っていた統合責任——工程間の整合、全体スケジュール、不具合発生時の切り分け——が、発注側に戻ってくることです。要件定義のベンダーと実装のベンダーが別なら、要件の解釈齟齬を裁定するのは発注側です。
したがって経路2を取れるかどうかは、価格交渉力の問題ではなく、統合責任を担える人が社内にいるかの問題です。いないまま分離発注に踏み切ると、工程間の齟齬がそのまま手戻りとなり、削減した以上の費用が発生します。ここが埋まらない場合、統合の機能だけを外部(PMOや技術顧問)に置く形が中間解になります。
もうひとつ、分離しないまでも今日からできることがあります。見積りの内訳として工程別工数の提示を求め、実装工程について「AI活用を前提とした場合の見積り」を併記してもらうことです。応じ方そのものが、そのベンダーのAI駆動開発の実力を測る材料になります。
3つの経路のうち、唯一確実に効くのがこれです。交渉も契約変更も要りません。発注しなければ費用はゼロです。
AI駆動開発が内製化の損益分岐を動かしたことが、この経路の根拠です。従来、内製化の壁は「作れる人を雇い続けるコスト」でした。エンジニアを2〜3名抱えても、外注していた開発の一部しか置き換えられない。この算盤が、少人数でも回る方向に変わっています。
とはいえ、すべてを内製に戻せるわけではありません。移せる候補には型があります。
共通するのは、要件が社内で閉じていて、失敗の影響範囲が限定されることです。逆に、基幹システムの刷新のような、統制と品質保証の比重が大きいものは残ります。
代償も明確です。保守責任と技術選定の責任が社内に残ります。作った人が異動すれば引き継ぎの問題が生じ、技術の選択を誤れば数年後の負債になります。ここで必要なのは実は「作れる人」ではなく「決められる人」です。何を内製し、何を外に残すか。どの技術で作り、何を作らないか。AIは実装を安くしましたが、この判断は安くしていません。
始め方としては、経路1・経路2の交渉材料づくりを兼ねて、小さい案件を1本、社内でAI駆動で作ってみることを勧めます。これが次章の実測につながります。
3つの経路を並べると、共通の前提がひとつあることに気づきます。「実装の工数はAIでこれだけ減らせる」という数字を、発注側が自分で持っていることです。
経路1の枠交渉も、経路2の工程別査定も、根拠が「世間でそう言われている」では通りません。ベンダー側には「当社の品質基準では従来工数が必要です」という応答がいつでも可能で、一般論はこれを崩せません。崩せるのは「同種の改修を社内でAI駆動で実装したら、この工数だった」という実測だけです。
だから、削減の取り組みの最初の一歩は、ベンダーとの交渉ではなく、社内で小さい開発を1本、AI駆動で実際にやってみることになります。
作り方は、軽くて構いません。いわゆるバイブコーディング——仕様書を書き込まず、AIとの対話で動くものを先に出してしまう進め方——で十分です。目的は本番品質のシステムを作ることではなく、プロジェクトを軽く一周させて、規模感と課題を先に押さえることだからです。画面数はどの程度か、データはどこで詰まるか、既存システムとの接続のどこが重いか。従来はベンダーの見積りが出てくるまで分からなかったことが、発注する前に手元で分かります。
この1本から得られるものは4つ重なっています。
1本で構いません。ベンダーマネジメントの世界では、発注側が原価構造を知っていること自体が価格を規律します。「この工程がこの工数なのはなぜですか」を具体的に問える発注者になること——それ自体が、交渉の前から削減効果を持ち始めます。
前章のプロトタイプは、交渉材料で終わらせるにはもったいない資産です。ここから、発注の作り方そのものが変わります。
従来のRFPでは、発注側が出せるのは文章の要件と予算の枠だけでした。規模感はベンダーの見積りが出てきて初めて分かり、予算は前年実績と勘で置くしかない。情報の非対称は最初から最後までベンダー側に有利でした。
これからは、発注側が骨格を先に用意できます。動くプロトタイプ、画面構成、データモデルの叩き台、受入基準の案。AI駆動で軽く作ったものをRFPに添付し、予算はプロトタイプで掴んだ規模感から逆算する。ベンダーへの問いは「いくらで作れますか」から、こう変わります。
「この骨格に乗れますか。どこを作り直し、どこを本番品質に上げ、それぞれいくらですか」
この問いは、ベンダーの査定装置としてそのまま機能します。乗れるベンダーは、骨格の欠陥を具体的に指摘し、工程別の見積りを返してきます。その指摘の質が、技術力の証明になる。逆に「弊社の標準プロセスでは一から要件定義を行います」としか返せないベンダーは、骨格を読めていないか、人月の温存を優先しているかのどちらかです。
乗れるベンダーがいなかった場合の選択肢は3つです。
ひとつ、注意点があります。骨格に乗ってもらう発注では、骨格の欠陥は発注側の責任になります。プロトタイプの設計判断が誤っていた場合、その手戻りをベンダーの契約不適合とは言えません。楽になる代わりに、責任の一部が発注側に移る。ここでも起きているのは、コストの削減というより責任の再配置です。
やってはいけない形も書いておきます。 実際のベンダーマッチングの場で、次のようなRFPが出始めています。設計書一式を支給し、「AI駆動開発を実務導入しており、それによって工期を短縮できること」を応募の必須条件に置き、費用は安いほどよい、とする形です。一見、本章で勧めた発注と似ています。しかし中身は逆です。
このRFPに集まる一番安い札は、ほぼ確実に、どこかで責任を静かに降りた札です。そして条件を読める実力のあるベンダーほど、この構図を見抜いて応募しません。残った札から選ぶことになるのは発注側です。骨格を支給する発注は、短縮分の受益先(価格か、納期か、スコープか)・支給物の欠陥時の扱い・受入基準の3点をRFPに書いて、初めて対等な取引として成立します。この3点は、次章の「誰がどの席に座るか」の話そのものです。
ここまでの3つの経路とRFPの話を貫いている事実を、正面から書きます。
冒頭の分解式に戻ります。単価の中身は「作業の対価＋判断と責任の対価」でした。人月単価という値付けは、この2つを区別せず、まとめて人月に溶かし込んだものです。AIが安くしたのは前者だけ。だから工数が減っても費用が減らず、減らそうとすると必ず「では誰が責任を持つのか」という問いに突き当たる。本コラムの3経路がすべて発注側に責任を戻す構造になっていたのは、偶然ではありません。
自動運転に置き換えると、この構造は分かりやすくなります。技術としての自動運転は、すでに走れています。それでも広がらない。残っているのが技術の問いではなく、次の3つだからです。
システム開発の外注費も、同じ場所に来ています。AIがコードを書けるようになっても、承認し、検収し、リスクを受け入れる「運転席」は残ります。外注費として払ってきた金額は、作業の対価とこの席の対価が混ざったものでした。人月単価はこの2つを区別しないので、作業が安くなった分がどこへ行ったのか、発注側からは見えません。これからの予算の作り方は、金額を工数で積むことではなく、誰がどの席に座り、何にどう責任を負うかを仕分けることになります。
3つ目の「自動運転を弱める」は、逃げではなく設計の選択肢です。すべての開発を同じ強度でAI駆動にする必要はありません。基幹系や決済のような、事故のときの責任が重いシステムは自動化の度合いを下げ、人の承認を厚くする。社内ツールや帳票のような軽いものは、思い切り自動化する。責任の重さに合わせて自動化の強度を選ぶこと自体が、予算の設計変数です。怖さを理由に全部をやめるのでも、全部に突っ込むのでもなく、システムごとに席の重さを決める。
そのうえで、誤解のないように書きます。総額は下がります。運転席は残りますが、10人のドライバーは要らなくなるからです。実装の席が減り、残るのは責任の席で、席の数そのものが減る。減った分は、経路1〜3を通じて確かに費用として下がります。下がらないのは責任の値段のほうで、そこを値切ると、事故のときにまとめて払うことになります。手戻り・検収トラブル・野良システムは、値切った責任の請求書です。
「AIで外注費は下がるのか」と問われたときの答えも、ここから導けます。「下がります。ただし自動では下がらず、誰が何に責任を負うかを設計し直す投資が先に要ります」。この一文が、実態に即した唯一の答えです。
本コラムの内容を、着手の順番に直します。
最初の四半期で1と2を終えれば、交渉の足場はできます。金額として効き始めるのは、契約の更新と次の発注が回ってくる2〜4四半期目からです。
Chapter Techでは、この線の引き直し——要件定義・ベンダー査定・内製化の立ち上げを含む発注側の体制づくり——をエンタープライズDX & FDE支援サービスとして支援しています。外注費の構造の見立てからで構いませんので、お問い合わせからご相談ください。
なお、同じ構造をベンダー側から見た話——工数が半分になったとき、受託・SES企業は何をどの順番で変えるべきか——はベンダーとしてAI駆動開発するための道標で扱っています。交渉の相手が何を考えているかを知っておくことは、どの経路を取るにしても無駄になりません。