AIコーディングで開発の工数構造が変わりつつあるいま、発注側企業は見積もりをどう読み、何を外注に残し何を内製に取り込むべきか。ベンダーとの新しい付き合い方を、断定を避けつつ実務目線で整理します。
システム開発の外注費に、これまでとは違う疑問を持ち始めた経営者・購買・情シスの方が増えていると感じます。「同じような機能なのに、なぜこの金額なのか」「見積書の人月は、本当にこの工数が必要なのか」——こうした問いが以前より切実になってきた背景には、開発現場の道具立てそのものが変わりつつあるという事情があると考えられます。
従来のシステム開発では、要件定義・設計・実装（コーディング）・テスト・保守という工程のうち、実装工程に相当のエンジニア工数が割かれてきました。見積もりが人月（エンジニア1人が1か月働く単位）で積み上げられてきたのも、この構造を前提にしていたからです。
ところがAIコーディング支援ツールの実用化により、定型的なコードの生成、ボイラープレート（毎回書く決まりきった枠組み）の記述、テストコードの下書き、既存コードの解読といった作業の一部が、以前より短時間で進められるようになりつつあります。すべての工程が一律に速くなるわけではありませんが、少なくとも「手を動かしてコードを書く」局面での時間の使い方は変化していると考えられます。
この変化が発注側にとって重要なのは、見積もりの前提が静かに崩れ始めているからです。実装工数が圧縮され得るなら、人月ベースの数字をそのまま受け取ってよいのか、という問いが自然に生まれます。一方で、要件の曖昧さを潰す・業務を理解する・運用に耐える設計を選ぶといった「人でなければ難しい」工程の重みはむしろ相対的に増していると見ることもできます。
もともとシステム開発の発注には、発注側と受注側の情報の非対称という構造的な難しさがありました。発注側は技術の中身を細かく検証しづらく、見積もりの妥当性を「相場」や「相見積もり」で間接的に確かめるしかない場面が多かったと思われます。
AIコーディングは、この非対称をさらに複雑にする側面があります。工数構造が変わりつつある一方で、その変化がどの程度・どの領域で起きているかは案件によって大きく異なるため、「AIで安くなるはず」という素朴な期待も、「AIを使っても結局変わらない」という反発も、どちらも実態を単純化しすぎている可能性があります。だからこそ、発注側が見積もりを読み解く新しい視点を持つことに意味があると考えます。
本記事では、特定の開発言語やツールの使い方ではなく、発注する側の意思決定に焦点を当てます。具体的には、見積もりのどこを見れば妥当性を推し量りやすいか、外注に残すべき領域と内製に取り込みやすい領域をどう切り分けるか、そしてベンダーとの関係をどう更新していくか、の三点を軸に整理します。なお、社内AIエージェントを内製すべきか外注すべきかという隣接テーマは、社内AIエージェントは内製か外注かでも扱っており、あわせて読むと判断の幅が広がると考えます。
見積もりを読み解くには、その裏側にある工数構造の変化を、発注側もおおまかに理解しておくことが役立つと考えます。ここでは、どの工程が変わりやすく、どの工程が変わりにくいのかを整理します。断定できる話ではありませんが、傾向としての見取り図は持っておいて損はないはずです。
一般論として、AIコーディングの恩恵を受けやすいのは、パターンが決まっていて正解が明確な作業だと考えられます。たとえば、よくある画面の実装、データの単純な変換処理、定型的なAPI連携、テストコードの雛形づくりなどです。こうした作業は、過去の膨大なコード資産を学習したAIが下書きを素早く提示しやすい領域です。
逆に、変わりにくい——つまり人の判断が引き続き重い工程もあります。業務の実態をヒアリングして要件に落とす作業、複数部門の利害が絡む仕様の調整、障害時にどう振る舞わせるかの設計、既存システムとの整合、セキュリティや個人情報の扱いといった領域です。これらは「何を作るべきか」を決める工程であり、AIが下書きを出せたとしても、その妥当性を判断し責任を負うのは人だという構造は当面変わりにくいと考えられます。
ここで発注側が注意したいのは、実装が速くなることが、そのまま総額の低下を意味するとは限らない点です。理由はいくつか考えられます。第一に、実装工程が全体に占める割合は案件によって異なり、要件定義や調整の比重が大きい案件では、実装が速くなっても総額への影響は限定的になり得ます。第二に、AIの出力をそのまま使えるわけではなく、レビューや手直し、動作検証にかかる時間が新たに発生します。第三に、速く作れることでかえって作る量が増える（作り込みや変更要望が膨らむ）という力学も現場では起こり得ます。
したがって「AIを使っているなら安くなるはず」という一括りの期待は、交渉の入り口としては危ういと考えます。むしろ「どの工程がどれくらい変わり、どこに人の時間が残るのか」を工程単位で確認するほうが、実りある対話につながりやすいはずです。この費用構造の考え方は、AIエージェント導入の費用構造で扱っている論点とも重なる部分が多いと考えます。
もう一つ、工数構造の変化を読むうえで見落とされがちなのが、初期構築費と保守運用費の関係です。AIコーディングによって初期構築が速く進んだとしても、その後の保守・改修・障害対応にかかるコストは別問題です。むしろ、短期間で作られたシステムほど、設計の意図がドキュメントに残らず、後から手を入れにくくなる懸念もあります。発注側としては、初期費用の安さだけでなく、「作った後に誰がどう維持するのか」までを含めて総保有コストで捉える視点が、これまで以上に重要になると考えられます。
ここからは、実際に見積書を手にしたときに、発注側がどこに目を向ければ妥当性を推し量りやすいかを、具体的な観点として整理します。専門知識がなくても確認できる問いを中心に挙げます。
まず基本として、総額の一式表示ではなく、要件定義・設計・実装・テスト・保守といった工程ごとの内訳を開示してもらうことを勧めます。内訳が出てこない、あるいは「一式」でしか語られない見積もりは、妥当性の検証がそもそも難しくなります。工程が分かれていれば、「実装工程にAIをどう活用しているか」「その分の工数はどう見積もっているか」といった具体的な問いを立てやすくなります。
ここで大切なのは、AI活用を理由に一方的な値引きを迫ることではありません。むしろ、どの工程で効率化が効き、どの工程に人の判断が集中するのかを、ベンダーと一緒に言語化することが目的です。誠実なベンダーであれば、この対話を歓迎する余地があると考えます。
人月単価の高い・安いだけを比較すると、判断を誤りやすくなります。単価が高くても、業務理解が深く手戻りが少なければ結果的に安くつくこともありますし、単価が安くても、要件のすり合わせが甘く作り直しが続けば高くつくこともあります。単価という一次元の数字より、「そのチームが何に時間を使い、どこに価値を出すのか」を問うほうが、実態に近づけると考えます。
見積もりの数字そのものだけでなく、成果物の性質にも目を向けたいところです。具体的には、次のような点です。
AI時代には、初期に作ったものを内製で育て続ける選択肢が現実味を帯びます。だからこそ、引き継ぎやすさ・ロックインの有無は、見積もりの金額と同じくらい重要な評価軸になると考えられます。
相見積もりで極端に安い数字が出てきたときも、単純に喜ぶ前に中身を確認したいところです。安さの理由が、効率化による正当なものなのか、それとも要件の理解が浅く後から追加費用が発生する構造なのか、あるいは保守や引き継ぎのコストが見積もりから外れているだけなのか——理由によって意味がまったく異なります。ベンダー選定の観点は生成AI導入支援ベンダーの選び方でも整理しており、価格の背後にある前提を読む視点は共通していると考えます。
AIコーディングは「内製か外注か」の議論を再燃させています。ただし、二択で捉えると判断を誤りやすいと考えます。ここでは、業務特性に沿って線引きを考えるための枠組みを提示します。
内製と外注の線引きは、技術の難易度だけで決まるものではありません。むしろ次のような業務特性で切り分けるほうが、実態に合うと考えます。
AIコーディング支援によって、これまでは「小さすぎて外注しづらく、自作もできなかった」領域——たとえば部門内の定型作業を助ける小さなツール、データの突合や集計を自動化する仕組み、社内の問い合わせ対応を助ける仕掛けなど——が、業務担当者に近い人の手で作りやすくなりつつあると考えられます。こうした「小回りの利く内製」は、仕様変更に即応でき、業務知識がそのまま反映されるという利点があります。
ただし、内製化には落とし穴もあります。作った人しか分からないブラックボックスが増える、セキュリティや品質の担保が属人化する、といったリスクです。内製の範囲を広げるほど、後述するガバナンスの設計が重要になります。
一方で、外部の専門性に任せたほうが合理的な領域も引き続きあると考えます。基幹システムのように失敗の影響が大きいもの、高い可用性やセキュリティが求められるもの、法令対応や監査に耐える必要があるもの、あるいは自社に知見の蓄積がまったくない領域です。こうした領域では、AIで速く作れるかどうかより、責任を持って設計・運用できる体制があるかが重要になります。
現実的には、多くの企業にとって「基幹は外注で堅く、周辺の業務ツールは内製で軽く」といった役割分担が落としどころになりやすいのではないかと考えます。この内製と外注のバランスは、社内AIエージェントは内製か外注かでも具体的に掘り下げています。
いきなりすべてを内製に切り替えるのは現実的ではありません。多くの場合、外注で作ってもらいながら自社の担当者が並走して学ぶ、あるいはベンダーに伴走支援を依頼して内製の型を身につける、といった段階的な移行が現実解になると考えられます。重要なのは、どの領域を・どの順番で・誰が内製に取り込んでいくかというロードマップを、発注の段階から意識しておくことです。
工数構造が変わり、内製の余地が広がるなかで、ベンダーとの関係も更新が求められると考えます。ここでは、これからの発注実務で意識したい関係のあり方を整理します。
従来の一括請負は、要件を固めて発注し、完成品を受け取るという関係でした。この形は、要件が明確で変化の少ない案件には引き続き有効です。一方で、仕様が動き続ける業務や、内製化を見据えた取り組みでは、完成品を納めてもらうより、内製の型やノウハウを移転してもらう「伴走支援」型の関係が適する場面が増えていると考えられます。
伴走支援型では、ベンダーは「作る人」であると同時に「自社が作れるようにする人」でもあります。発注側にとっては、成果物だけでなく、社内に残る知見や再現性も評価対象になります。この視点は、AIエージェントを社内に根づかせる取り組みとも通じるため、AIエージェントを社内に導入するにはもあわせて参照すると全体像がつかみやすいと考えます。
これからの契約では、動くものが納品されることに加えて、その後に自社やほかのベンダーが引き継げる状態になっているかを重視したいところです。設計の意図が分かるドキュメント、コードの所有権、変更のしやすさ——こうした「引き継ぎやすさ」は、短期的なコストには表れにくい一方で、中長期の総保有コストを大きく左右すると考えられます。
ベンダーがAIコーディングをどう使い、どこに人の判断を残しているかを、率直に話し合える関係が望ましいと考えます。AI活用を隠して従来の人月で請求されるのも、逆にAI活用を口実に品質を犠牲にされるのも、どちらも発注側にとって望ましくありません。「どの工程でAIを使い、その品質をどう担保しているか」をオープンに語れるベンダーは、信頼に足る候補になり得ると考えます。
ベンダーとの関係を更新するには、発注側にも受け皿が要ります。見積もりを工程単位で読み、内製と外注の線引きを判断し、伴走支援を受け止められる担当者や体制です。この受け皿がないまま発注だけを変えても、結局は従来と同じ丸投げに戻ってしまいがちです。小さくてもよいので、社内に技術の会話ができる窓口を育てることが、遠回りに見えて近道になると考えられます。
ここまでの整理を踏まえても、実際の発注では判断を誤りやすい局面がいくつもあります。よく見られる落とし穴を挙げておきます。
これらの落とし穴に共通するのは、「AIで変わった一面」だけを見て、変わっていない一面——業務理解や責任、保守や引き継ぎの重み——を見落とすことだと考えます。変化と不変の両方を見据えるバランス感覚が、発注側に求められていると言えそうです。
最後に、ここまでの論点を、明日からの実務にどうつなげるかという視点で整理します。一度にすべてを変える必要はなく、段階的に自社の発注力を高めていく道筋を描くことが現実的だと考えます。
まずは、現在発注している開発費が、どの工程にどれだけ割かれているのかを把握することから始めるのが良いと考えます。工程ごとの内訳が見えないなら、次回の見積もりから開示を依頼するところが第一歩です。棚卸しによって、「どこが内製に取り込めそうか」「どこは外注に残すべきか」の議論の土台ができます。
次に、失敗しても影響の小さい業務ツールから、小さく内製を試すことを勧めます。目的は成果物そのものより、技術の会話ができる人・体制を社内に育てることです。AIエージェント導入の費用構造で触れられているように、費用の内訳を自分たちで読めるようになること自体が、発注力の底上げにつながると考えられます。
棚卸しと小さな内製で社内の目線が育ってきたら、ベンダーとの関係を、丸投げ請負から伴走支援へと少しずつ更新していきます。引き継ぎやすさ・所有権・AI活用の透明性を評価軸に加え、中長期の総保有コストで判断する。この積み重ねが、外注費への漠然とした疑問を、根拠のある意思決定へと変えていくと考えます。
ここまで述べてきた内容は、あくまで一般的な傾向としての見取り図です。実際にどの工程がどれだけ変わるか、どこを内製に取り込めるかは、企業の業種・規模・既存システムの状態によって大きく異なります。だからこそ、机上の議論だけで結論を出すのではなく、自社の実際の業務や実際の見積もりを題材に、小さく試して確かめることが欠かせないと考えます。
私たちNsightは、産業用画像検査やVLM/AIの開発に加えて、AI研修や社内AIエージェント・業務OSの内製化支援を手がけています。開発現場に長く携わってきた知見——たとえば元キーエンス画像処理事業部出身の監修者が持つ、現場で本当に使われる仕組みと、そうでない仕組みを見分ける目線——を踏まえ、見積もりの読み解きや内製・外注の線引きを、貴社の現物・現場に即して一緒に確かめていくことができればと考えます。まずは自社の一枚の見積書を題材に、どこが変わり得てどこは変わらないのかを、対話の中で棚卸しするところから始めてみてはいかがでしょうか。
工程によって変化の度合いが大きく異なるため、一律に安くなるとは言い切れないと考えます。定型的な実装は短時間化しやすい一方、要件定義や業務理解、調整、保守といった工程の重みはむしろ相対的に増す場合があります。実装が全体に占める割合が小さい案件では、総額への影響は限定的になり得ます。値引きの前提にするより、工程単位で「どこが変わるか」を確認するほうが実りやすいと考えられます。
まず工程ごとの内訳を開示してもらうことを勧めます。総額一式では検証が難しいためです。そのうえで、人月単価の高低だけでなく「何に時間を使うのか」、成果物の所有権や引き継ぎやすさ、変更時の費用の考え方、ロックインの有無を確認すると、金額の背後にある前提が見えやすくなります。安すぎる見積もりも、その理由を読むことが大切だと考えます。
技術の難易度だけでなく、業務特性で切り分けるほうが実態に合うと考えます。仕様が変わり続ける・競争力の源泉である・育て続ける前提の業務は内製に取り込む価値が高まりやすく、失敗の影響が大きい・高い可用性やセキュリティ・法令対応が必要な領域は外部の専門性に任せる判断が妥当な場合があります。多くの企業では『基幹は外注で堅く、周辺は内製で軽く』が落としどころになりやすいと考えられます。
その懸念はもっともだと考えます。小回りの利く内製は魅力的ですが、作った人しか分からない仕組みが増えると、退職や異動で急所になりかねません。内製の範囲を広げるほど、ドキュメント化・品質の担保・権限管理といったガバナンスの設計をセットで進める必要があります。最初は失敗しても影響の小さい業務ツールから小さく試し、社内に技術の会話ができる窓口を育てることを勧めます。
完成品を納めてもらう一括請負に加えて、内製の型やノウハウを移転してもらう『伴走支援』型の関係を選択肢に加えることを勧めます。評価軸も、動くものだけでなく『引き継げる状態になっているか』『AI活用の透明性があるか』へ広げると良いと考えます。ただし発注側にも、見積もりを読み線引きを判断できる受け皿が必要です。受け皿を育てながら関係を段階的に更新していくのが現実的だと考えられます。
AI時代の発注は、机上の議論より現物での検証が近道だと考えます。貴社の実際の見積書や業務を題材に、どこが変わり得てどこは変わらないのかを、元キーエンス画像処理事業部出身の監修者の知見も交えて一緒に確かめます。
発注・内製化の相談をする