「AIで開発が速くなるなら、外注費は下がるはずだ」。役員会でこう問われて、答えに詰まった情報システム部門の方は多いはずです。実際、ツールを入れたベンダーに発注していても、請求額は下がっていない。これは誰かが怠けているからではなく、契約の構造上、実装工数の減少が支払いの減少に自動ではつながらないためです。本コラムでは、まずなぜ自動では下がらないのかを契約形態別に確認し、費用を実際に下げる3つの経路——要員枠の縮小、工程を分離した発注、内製化——を、前提条件と代償まで含めて整理します。後半では、発注側が骨格を先に用意するRFPの作り方と、人月単価の先にある「責任の値段」の話をします。
最初に、期待と現実のずれの正体を確認します。
AIで実装の工数が下がることは、もう疑う余地がありません。問題は、その工数の減少が発注側の支払いに届くかです。標準的な契約形態の両方で確かめます。
SESでも請負でも、外注費は自動では1円も減らない。減らすには発注側の作為が要る。
SES・準委任で買っているのは成果物ではなく時間です。エンジニアが月160時間稼働する対価として単金を払う契約なので、AIでエンジニアの作業が速くなっても、稼働時間が変わらない限り請求は1円も変わりません。変わるのはその時間内に出てくるアウトプットの量です。つまり効果は「同じ費用でより多く作れる」形で現れ、「同じものが安く作れる」形では現れません。
請負で買っているのは成果物ですが、金額は契約時に固定されています。ベンダーがAIで工数を圧縮しても、その差分はベンダーの粗利になります。契約として何も間違っていません。固定価格契約とはそういう仕組みであり、効率化の利益は請けた側に落ちます。
どちらの形態でも、「ベンダーがAIを使えば費用が下がる」は成立しないことになります。役員の期待が現場で再現できないのは、現場の交渉力の問題ではなく、契約構造の帰結です。下げるには、契約と発注の形そのものに手を入れる必要があります。その経路は3つです。
いずれも自社の実測値がないと交渉が成立しない。そして、いずれも「決める側」のコストを増やす。
共通の前提は、自社で小さい開発を1本AI駆動で実施して工数の実測値を持つこと。外注費の削減とは、支出の一律カットではなく、内製と外注の線の引き直し。
時間を買う契約で費用を下げる方法は、原理的にひとつしかありません。買う時間を減らすことです。スループットが上がった分だけ要員枠(人数×期間)を縮めたとき、初めて工数の減少が費用の減少になります。
前提になるのは、スループットの実測です。「AIで速くなったはずだから枠を減らしてほしい」では交渉になりません。ベンダーは「案件の性質上、効果は限定的です」と返せますし、それが事実かどうかを発注側は判定できません。
だから、枠の交渉より先に測定の設計が要ります。何を測るかを決めて、現在の値を取っておくことです。使いやすい指標は、月あたりの消化チケット数、リリース頻度、改修1件あたりのリードタイムあたりです。厳密である必要はなく、枠を1名減らしたときにスループットが維持できているかを判定できれば足ります。
進め方も、いきなり全体を削るのではなく、1名分を減らして四半期様子を見る形が現実的です。維持できていればもう1名、劣化したら戻す。この往復ができる状態を作ること自体が、ベンダー任せだった生産性を発注側の管理下に置くことを意味します。
注意点がひとつあります。枠を削る交渉は、ベンダーにとっては純粋な減収なので、AI活用への協力動機を削ぎます。長く付き合うベンダーに対しては、削った枠の一部を別の発注(後述する要件定義支援や、内製化の伴走)に振り替える形のほうが、関係としては持続します。
請負の固定価格が下がらないのは、内訳がブラックボックスだからです。「一式 3,000万円」の中で実装工程が何割を占めるのかが見えなければ、実装の相場が下がってもそれを価格に反映させる交渉の足場がありません。
対応は、発注の単位を割ることです。要件定義、設計・実装、テスト、保守を分けて発注すれば、工程ごとに見積りの根拠を問えるようになり、実装工程については「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つです。
ひとつ、注意点があります。骨格に乗ってもらう発注では、骨格の欠陥は発注側の責任になります。プロトタイプの設計判断が誤っていた場合、その手戻りをベンダーの契約不適合とは言えません。楽になる代わりに、責任の一部が発注側に移る。ここでも起きているのは、コストの削減というより責任の再配置です。そしてこれが、次章の本題につながります。
ここまでの3つの経路とRFPの話を貫いている事実を、正面から書きます。
人月単価×工数という値付けは、実装がコストの中心だった時代の慣行です。この値付けは「実装の手間賃」と「責任の対価」を区別せずに、まとめて人月に溶かし込んでいました。AIが安くしたのは前者だけです。だから工数が減っても請求が減らず、減らそうとすると必ず「では誰が責任を持つのか」という問いに突き当たる。本コラムの3経路がすべて発注側に責任を戻す構造になっていたのは、偶然ではありません。
自動運転に置き換えると、この構造は分かりやすくなります。技術としての自動運転は、すでに走れています。それでも広がらない。残っているのが技術の問いではなく、次の3つだからです。
システム開発の外注費も、同じ場所に来ています。AIがコードを書けるようになっても、承認し、検収し、リスクを受け入れる「運転席」は残ります。外注費として払ってきた金額は、実装の手間賃とこの席の対価が混ざったものでした。人月単価はこの2つを区別しないので、実装が安くなった分がどこへ行ったのか、発注側からは見えません。これからの予算の作り方は、金額を工数で積むことではなく、誰がどの席に座り、何にどう責任を負うかを仕分けることになります。
3つ目の「自動運転を弱める」は、逃げではなく設計の選択肢です。すべての開発を同じ強度でAI駆動にする必要はありません。基幹系や決済のような、事故のときの責任が重いシステムは自動化の度合いを下げ、人の承認を厚くする。社内ツールや帳票のような軽いものは、思い切り自動化する。責任の重さに合わせて自動化の強度を選ぶこと自体が、予算の設計変数です。怖さを理由に全部をやめるのでも、全部に突っ込むのでもなく、システムごとに席の重さを決める。
そのうえで、誤解のないように書きます。総額は下がります。運転席は残りますが、10人のドライバーは要らなくなるからです。実装の席が減り、残るのは責任の席で、席の数そのものが減る。減った分は、経路1〜3を通じて確かに費用として下がります。下がらないのは責任の値段のほうで、そこを値切ると、事故のときにまとめて払うことになります。手戻り・検収トラブル・野良システムは、値切った責任の請求書です。
役員会への答え方も、ここから導けます。「AIで外注費は下がります。ただし自動では下がらず、誰が何に責任を負うかを設計し直す投資が先に要ります」。この一文が、実態に即した唯一の答えです。
本コラムの内容を、着手の順番に直します。
最初の四半期で1と2を終えれば、交渉の足場はできます。金額として効き始めるのは、契約の更新と次の発注が回ってくる2〜4四半期目からです。
Chapter Techでは、この線の引き直し——要件定義・ベンダー査定・内製化の立ち上げを含む発注側の体制づくり——をエンタープライズDX & FDE支援サービスとして支援しています。外注費の構造の見立てからで構いませんので、お問い合わせからご相談ください。
なお、同じ構造をベンダー側から見た話——工数が半分になったとき、受託・SES企業は何をどの順番で変えるべきか——はベンダーとしてAI駆動開発するための道標で扱っています。交渉の相手が何を考えているかを知っておくことは、どの経路を取るにしても無駄になりません。