昨今、AI駆動開発でアプリケーションを作るハードルが下がり、だれでもアプリをつくれるようになってきました。その変化は、受託開発の在り方にも波及しているのではないか、と感じています。
前の記事では、職業エンジニアの未来やプロダクトビルダーへの移行について書きました。今回は、クライアントとの関わり方──受託開発がどう変わっていくか、という視点で整理します。
開発支援の縮小。自社で作れる時代
いままでの受託開発の中心は、クライアントが持てない開発リソースを借りる、という構図でした。要件をもらい、設計し、実装し、納品する。開発そのものに価値があった。
AIの普及で、その前提が揺らいでいます。自社でプロトタイプを作れる。非エンジニアでも、CursorやClaude Codeのようなツールで動くものを出せる。開発支援の需要そのものが、縮小傾向にある、と見ています。
受託の依頼件数も減っていくだろう、という予感があります。副業やフリーランスの世界も同じです。人手不足は続く一方で、絶対数として必要な人数は、AIで効率化できる部分が増えています。「開発者を雇えば何とかなる」という発注の仕方は、以前ほど通用しなくなる。
「言われたものを作る」だけでは足りない
この変化のなかで、いままで受託をしてきた会社は、ただ顧客の求めるものを作るだけでは生き残りにくくなる、と感じています。
提案力のある会社は、まだ道がある。課題の整理、優先順位の設計、事業文脈に沿った選択──ここに価値が残る。一方で、開発だけを請け負ってきた会社は、厳しくなる。クライアント自身がAIで作れるようになった以上、「作業代行」だけの受託は、単価も件数も下がりやすい。
開発そのものではなく、別の形で入る必要がある。自分が考えているのは、AI伴走支援というスタイルです。
AI伴走支援とは何か
「伴走」という言葉を使っています。主役はクライアント側。AIと一緒に作るのも、自社メンバーが作るのも、クライアント自身です。受託側は、その横で伴走する。
具体的には、次のような支援をイメージしています。
- AIで作ったコードのレビューと品質チェック
- セキュリティや設計上の問題点の指摘
- 運用・監視・障害対応の設計
- アーキテクチャや技術選定の助言
- 「ここまで自社で作り、ここから外注」の線引きの整理
開発を全部引き受けるのではなく、クライアントがAIと一緒に作ったものを、経験則のある目で見て、危ないところを止め、足りないところを補う。そういう関わり方です。
初めて作ったものは、まだ完成度が高くない
AIで簡単に作れる、という話は本当です。ただ、初めて触る人がつくったものは、まだまだ完成度が高くない、というのも実感としてあります。
動く。デモでは見える。でも、セキュリティホールがある。設計が後から拡張しにくい。運用を想定していない。ログも監視もない。障害が起きたときに誰が対応するか決まっていない。
これは、AIの限界というより、経験則がないことの問題に近いです。何度も本番リリースを経験した人が、当たり前にチェックしている項目を、初めて作る人は知らない。AIはコードを出すが、「本番で壊れたときのこと」までは教えてくれない。
ただし、クライアント側が学習し、経験を繰り返せば、その穴は埋められる部分もあります。能動的に学ぶ姿勢があれば、セキュリティや運用の感覚も、少しずつ身についていく。問題は、能動的に学ぶ姿勢がなければ難しい、という点です。
人が動く理由の多くは、興味に近いと感じています。義務だけでは、同じ失敗を何度も繰り返して学ぶ、というサイクルに入りにくい。興味があれば調べる。失敗しても続ける。経験則は、その積み重ねでしか残らない。
興味のある分野だけ、経験が積み上がる
自分の話をすると、AIや「楽をしたい」という自分への価値が動機になって、経験を繰り返しています。だから、伴走支援の話も、ある程度言える立場にある、と思います。
一方で、興味のない分野では、同じようには踏み込めません。調べる気にもならない。失敗しても学びに変えにくい。クライアントも同じではないか、と想像しています。業務効率化のアプリをAIで作る、という動機はあっても、セキュリティや運用の深いところまで能動的に学ぶかは、別の話です。
だから、伴走の価値はここにもあります。作るスピードはクライアントとAIの組み合わせで十分に出せる。足りないのは、作ったあとの品質と、長く使うための設計です。興味の外側にある専門領域を、経験則のある目で補う。
受託の定義が変わる
従来の受託は、「要件定義 → 設計 → 実装 → テスト → 納品」というフローが中心でした。工数の大部分が実装に乗っていた。
AI伴走型では、フローが変わります。
クライアント + AI でプロトタイプ・実装
↓
伴走側がレビュー・設計助言・品質担保
↓
本番運用に耐える状態へ整える（必要に応じて部分開発）
実装工数がクライアント側に移るほど、受託側の請け負う範囲は「品質」「設計」「運用」「判断」にシフトする。単価の考え方も、人月ベースの開発費から、伴走・レビュー・助言の料金体系へ変わっていくはずです。
専門領域は、人間が人間である以上残り続ける
AIを使って、アプリケーションで業務効率化することは、すでに可能です。社内ツール、定型業務の自動化、プロトタイプの試作。ここはAIとクライアントの組み合わせで、かなり進む。
一方で、セキュリティや運用に耐えうるアプリを作るには、専門領域が必要です。認証・認可、データの扱い、障害時の復旧、監視とアラート。ここは「動けばよい」とは別次元の話で、経験と専門知識が効く。
人間が人間である以上、この部分は残り続けるのではないか、と思っています。興味のある人は自分で学び、経験を積んで埋めていく。興味のない人や、本業が別の人は、そこまで踏み込まない。だから、伴走でも、部分的な専門支援でも、需要はゼロにならない。
AIが実装を代行するほど、「作れる」と「本番で使える」の間が、よりはっきり見える。その隙間を埋めるのが、これからの受託の仕事の中心になる、という見立てです。
自分にとっての位置づけ
自分は長年、受託開発の現場にいます。ドメインをまたいだ知見は得られた。一方で、定年後にゆるくソフトウェアを作る、というイメージは、前の記事で書いたとおり、いまの流れでは遠のいています。
受託で「作業」を請け負う路線は、以前ほど描きにくい。代わりに、クライアントがAIと一緒に作る時代に、伴走として入る。経験則と判断を売る。これは、プロダクトビルダー側の仕事とも重なります。
意思決定の重要性について書いたとき、AIがコードを出すほど人間は採用・却下・設計判断に時間を使う、という話をしました。伴走支援は、その延長線上にある。クライアントがAIの出力を選び続けるとき、経験のある目が横にいることで、危ない選択を減らせる。
まとめ
受託開発の在り方について、いまの自分の整理は次のとおりです。
- AI駆動開発で、クライアント自社での開発が現実的になり、従来型の開発支援需要は縮小傾向にある
- 受託の依頼件数は減り、副業・フリーランスの「作業代行」も厳しくなる
- 提案力のある会社は残る余地があるが、開発だけを請け負ってきた会社は厳しい
- 開発そのものではなく、AI伴走支援──クライアントとAIが作り、経験則で伴走する形が重要になる
- 初めてAIで作ったものは動くが、セキュリティ・設計・運用の完成度はまだ低い。経験則の不足が原因
- クライアントが能動的に学び、経験を繰り返せば穴は埋められる。ただし動機の多くは興味に依存する
- 興味のある分野では経験が積み上がる。興味のない分野では、同じ深さまで踏み込めない
- 業務効率化はAIで可能だが、セキュリティ・運用に耐えるアプリには専門領域が必要で、人間が人間である以上残り続ける
- 「作れる」と「本番で使える」の間の隙間を埋めるのが、これからの受託の中心になる
- 受託のフローは「実装中心」から「レビュー・設計助言・品質担保中心」へシフトする
- 単価の考え方も、人月ベースから伴走・助言の料金体系へ変わっていく
思ったことをまとめてみました。
今後のどのように変化するのかなどの未来はわからないにしても、ビジネスの変化はいずれ起きるのかなと思っています。
AIのコストの高騰もあるので、一概にこのビジネスが成立するかはわかっていないので、また記事を更新していきたい。