生成AIで生産性向上してバラ色っぽい未来を描いている感じがします。ぼくはSIerに勤めているわけですが、仕事はどうなんだろと気になって、思考実験をしていました。念の為言っておくと、以下は個人の見解であり、所属組織とは関係ありません。

この手の話、供給側の話と需要側の話が混ざります。そのあたりが議論の落とし穴だと思っていて、今回は、生成AIによる生産性向上が受託開発企業の売上構造をどう変えるのかという思考実験です。結論を先に言うと「速くなるだけでは売上が増えづらくて。大事なのは、その速さが需要に接続されるかどうかだ」という話です。

生産性向上は売上増加と同義ではない

生成AIによって、設計補助・コード生成・レビュー・テスト生成・リファクタリングといった開発工程の一部は確実に高速化しつつあります。少なくとも、同じ人数でより多くの開発タスクを処理できる可能性は、実証的に裏付けられつつあります。

問題は、この生産性向上が受託開発企業の財務構造に対してどう働くか、です。

受託開発企業に対し、市場が効率化分の価格転嫁を迫るなら、生産性向上は一見すると売上減少要因になり得ます。10人月かかっていた案件が5人月で終わり、その効率化分がそのまま見積価格に反映される「なら」、顧客請求額は下がります。さらに粗利率まで従来と同じ水準に保たれるなら、1件あたりの粗利額も下がる。

供給力は増える。では需要は？

一方生成AIによって、同じチームが同じ期間で処理できる開発量が増えるなら、それは原価低下であると同時に、供給力の増加でもあります。1案件に必要な期間が短くなれば、同じチームがより多くの案件を処理できる。つまり受託開発企業は「1件あたりの売上低下」と「案件回転数の上昇」を同時に経験する可能性があります。

しかし、回転数が上がることと、売上が増えることも、やはり別の話です。

ここで必要になるのが、Jevonsのパラドックスやリバウンド効果の視点です。

Jevonsのパラドックスとは、ざっくり言うと「効率化したら節約できるはずだったのに、安くなったせいでみんながもっと使い始めて、結果的に総使用量が増える」という話です。技術が進歩すると、ある資源を使うための実質的なコストは下がります。すると、これまで高くて使えなかった用途にも広がり、需要も増えることがあります。1回あたりは効率化されているのに、使われる回数や範囲が増えすぎると、社会全体ではむしろ消費量が増える。特に、価格が下がったときに需要が大きく増える、つまり「価格弾力性が高い」領域で起きやすい現象です。

開発においても同じ問いが立ちます。開発が安くなったら、顧客はもっとたくさん発注するのでしょうか。

Bessenの研究、"Automation and Jobs: When Technology Boosts Employment"は、この問いに対するひとつの答えを示しています。

この研究では、綿織物、鉄鋼、自動車の各産業において、自動化初期には生産性向上とともに雇用が増え、その後に雇用が減る「逆U字型」の推移が見られると示されています。

ここで面白いのは、自動化が雇用を増やすか減らすかを決めるのは、「機械が人間の仕事をどれだけ置き換えるか」だけではない、という点です。むしろ重要なのは、生産性向上で価格が下がったときに、需要がどれだけ増えるか。つまり、需要の価格弾力性です。

安くなった結果、みんながもっと買うなら市場は広がる。逆に、もう十分に行き渡っていて需要が増えないなら、同じ量を少ない人手で作れるようになるだけです。

受託開発に置き換えると、「AIで開発原価が下がったとき、どの領域の案件需要が増えるのか」「どの領域で価格弾力性が強いのか」という問いに直結します。

大型案件では、価格以外の制約が支配的になりやすいのでは

大規模基幹刷新や大型案件は、価格が少し下がったからといって急に本数が増えるタイプの需要ではなさそうです。これらの案件が獲得できるかどうかは、一般に開発費だけが判断基準ではないだろうからです。経営判断、移行リスク、既存システムとの依存関係、予算サイクル、失敗時の責任体制。開発費が2割下がったからといって、基幹刷新をもう1本走らせようという話にはなりにくい。開発費は、意思決定を左右するコストの一部に過ぎないからです。

さらに、既存ベンダーの代替困難性もあります。ドメイン知識こそが重要と言われる中で、業務知識・既存システムの暗黙知・顧客社内の関係性などは、単純な価格比較では置き換えにくい。スイッチングコストが高い領域では、開発原価が下がっても競合に奪われるリスクは低い一方、案件数の急増にもつながりにくい。そういう意味で、大型案件はAI時代でも安定していそう。ただしそれは、競合も同じことを考えている。「関係性で守られている」は「競合に入られにくい」であって、「案件が増える」とは別の話。

価格や期間に反応しやすいのは、ロングテールの未充足需要かもしれない

逆に、価格弾力性が高いのはどこなのでしょうか。

小規模な業務改善、既存システム改修、運用自動化、AIエージェント導入。こうした領域は、「やりたいけれど見積が高い」「効果はありそうだが稟議に通すほどではない」「開発者が足りず3か月待つなら今は諦める」といった理由で先送りされがちです。

これが、いわゆる未充足の需要です。潜在的な需要は存在するが、費用・期間・人手という摩擦によって案件化されていない。生成AIによって開発費と期間が下がれば、この摩擦は減り、先送りされていた要求も動き出す可能性があります。

つまり、生成AIによって顕在化しやすいのは新しい巨大プロジェクトではなく、今まで見積の前で消えていた小さな改善要求かもしれません。ロングテールの需要が、AI時代の成長余地である、という仮説です。ただし、めっちゃレッドオーシャンっぽい。夢がある場所には、だいたい全員来る。SaaS、ノーコード、フリーランス、そして顧客がAIを直接使う未来。「小さい案件も安く早く」と言い始めると、SIerは今まで戦ったことのない相手と戦うことになる。つまり、需要はあるかもしれないが、そこを誰が取るのかは別問題です。

問いは「速くなるか」ではなく「案件処理の型が変わるか」

だとすると、AI時代の受託開発の成長仮説は「大型案件をさらに多く受注する」ではなく、「小型・中型案件を大量かつ軽量に、品質を落とさず処理できるか」に寄っていきます。

ここで問題になるのが、従来の受託開発プロセスが小型案件の大量処理に向いているか、かもしれません。一連の取引コストは、よほど最適化しない限り、案件規模にかかわらずほぼ固定です。開発だけが速くなっても、案件全体の回転数は上がりません。

受託開発企業が生産性向上を実現した後、本当に重要なのは「AIで何人月削れるか」ではなく、「削れた人月によって、これまで案件化しなかった需要をどれだけ案件化できるか」です。そのためには、このような小型・多数の案件処理そのものの型が必要になります。

エンジニアの役割も変わる

小型案件では、毎回ゼロから業務理解・影響調査・テスト観点整理をしていると、案件単価に対して準備コストが重すぎます。したがって、過去の設計情報、既存仕様、テスト観点、運用ルールを再利用可能な形で蓄積し、AIが参照できる状態にしておくことが重要になります。突き詰めると「案件をスケールさせる仕組みを作りましょう」という話に行き着く。あれ、いつもと同じか。

おわりに

生成AIは原価構造を変える。でも、それだけで売上が増えるほど甘くない。 1案件あたりの売上が下がるなら、案件を増やすしかない。案件が増えるかどうかは、価格への需要の反応で決まる。

大規模基幹刷新の需要は価格弾力性が低く、費用以外の制約も強いと思います。一方、小規模改善・既存改修・運用自動化・AI導入支援のような領域には、費用対効果が合わずに眠っていた未充足需要が多くあると暗黙的にみんな思っている。Jevonsのパラドックスが起きるとしたら、この領域においてなのではないでしょうか。

AIは、受託開発企業を一律に不要とするというより、「小さな需要を継続的に事業価値へ変換する会社」へ変われるかを迫っているのだと思います。つまり、AIでコードを書くのが速くなった。それで万々歳、とはいかない。むしろ問われるのは、その速さをどうやって案件にし、どうやって品質を保ち、どうやって次の案件に再利用するかです。

結局、生成AI時代の受託開発で増えるのは、コードを書く速度だけではなく、「小さな仕事をちゃんと仕事にする力」なのかもしれません。というところまでが、今回の思考実験の結果でございました。