ソフトウェアで起業するな、まず"人力"で稼げ——世界が4.6兆ドルを賭ける逆転の起業論

AIが「つくる」を無料にした。だから、難しくなった

ソフトウェアで起業する難易度は、上がっている。 作る難易度ではない。むしろ逆だ。AIが「作る」をほぼ無料にした。

問題は、誰でも作れるようになったことそのものにある。 同じ基盤モデルのAPIを叩けば、似たプロダクトが週末に量産される。 薄いラッパーには、もう守るものが何も残らない。

数字は容赦ない。 AIラッパーの6〜7割は売上ゼロ、月1万ドルに届くのは3〜5%という調査がある。 2026年末までに9割が消えるという見立てまである。 APIの値上げが一度走れば、利益率は自分の意思と無関係に削られていく。

つまり、勝負は「作れるか」から「当てられるか」「回せるか」に移った。 プロダクトマーケットフィット（PMF）と、流通と、運用。 ここが今のボトルネックだ。読者の実感は、構造的に正しい。

「SaaS」から「Service as Software」へ、市場がひっくり返る

ここで発想を反転させた人たちがいる。 ソフトウェアを売るのをやめて、「成果そのもの」を売る、という考え方だ。

従来のSaaS（Software as a Service）は、道具を貸す商売だった。 道具を使って成果を出す責任は、顧客の側にある。 だが「Service as Software（サービスとしてのソフトウェア）」では、成果を出す責任を、売り手が引き受ける。

なぜこの転換が巨大なのか。市場の大きさが文字どおり桁違いだからだ。 a16zの試算では、米国のソフトウェア支出は約3,130億ドル。 対して、人の労働に対する支出は約10.5兆ドル。ソフトの市場は、労働市場のわずか3%にすぎない。

a16zが挙げる例がわかりやすい。 ある眼科クリニックは、Officeに年500ドルしか払わない。 だが受付スタッフ1人には年4.7万ドル払っている。 受付業務の9割をソフトが担えるなら、顧客が払う相手は500ドルの枠ではなく、4.7万ドルの枠になる。

戦う土俵が「ソフト予算」から「人件費・外注費」へ移る。 Foundation Capitalはこの機会を4.6兆ドルと見積もった。 SaaSという略語の主語と述語が、静かに入れ替わろうとしている。

だから「人力で深く入り込む」が、合理になった

成果を売るなら、まず顧客の現場を骨の髄まで知らなければならない。 そこで効くのが、泥臭く始めるという選択だ。

最初は人がやる。手で回す。フローに入り込む。 ポール・グレアムの「スケールしないことをやれ」は、この文脈で再び輝いている。 AIを名乗りながら、最初の10社ぶんは人間が手で処理する。いわゆる「オズの魔法使い」型のMVPだ。

この泥臭さは、ただの初期コストではない。 顧客の業務に深く入るほど、独自データが溜まり、ワークフローが食い込み、乗り換えコストが積み上がる。 薄いラッパーに無かった「あとから効くモート（堀）」が、人力の現場で生まれる。

象徴がパランティアの「フォワード・デプロイド・エンジニア（FDE）」だ。 エンジニアを顧客先に常駐させ、現場の要件に合わせて作り込む。 この泥臭いモデルが、いまOpenAIやAnthropicの法人開拓の中核に据えられている。

FDE職の求人は今年8〜10倍に増えたという集計もある。 かつて「スケールしない」と敬遠された常駐型が、AI時代の最強の参入手段になった。 理由は単純だ。AIの導入は、現場に入り込まないと「当たらない」し「回らない」からだ。

"あとでソフトに化けた"会社は、ぜんぶ最初は泥臭かった

この順番は、新しいようでいて、実は王道の再来でもある。 いま誰もが知るプロダクトの多くが、最初は人力か受託か社内ツールから始まっている。

ショッピファイは、創業者が自分のスノーボード店「Snowdevil」のために書いたEC基盤が原型だ。 他の店主に「それ使わせてくれ」と言われて、プロダクトに化けた。 スラックは、ゲーム会社が自社のために作った社内チャットの転用だった。 AWSは、アマゾンが自社の重いインフラ運用を解いた末に、外へ開いたものだ。

そしてパランティア。 顧客の複雑な業務に常駐して作り込み、そこで見えた共通項を「抽象化」してプロダクトに落とした。 彼ら自身の言葉でいえば、サービスを「プロダクト化（productize）」したのだ。

企業	最初の姿	ソフトウェアへの転換
Shopify	自分のEC店舗向けの自作基盤	他店主の要望でEC基盤を外販
Slack	ゲーム開発会社の社内チャット	ゲーム撤退後、ツールを製品化
AWS	Amazon自社のインフラ運用	同じ仕組みを外部に開放
Palantir	顧客先に常駐する作り込み	共通要件を抽象化し製品へ

共通点は明快だ。 先に「深い現場」があり、後から「広い製品」が生まれている。 順番が逆ではない。

VCはもう、これを"工業化"している

個人の起業論にとどまらない。 資本の側が、この順番を産業として量産し始めた。

ジェネラル・カタリストの「Creation Strategy（創造戦略）」は、その極北だ。 約15億ドルを投じ、AIネイティブな会社を自ら作り、断片化した労働集約型のサービス企業を買収していく。 そこにAIを差し込み、利益率を引き上げる。

狙う先は、低利益率で近代化が遅れた16兆ドルのサービス経済。 彼らは70のサービス業種を、AIの効きやすい10業種に絞り込んだという。 一部の会社は12カ月でEBITDAマージンを倍にし、2年でEBITDA1億ドルに達したと報じられている。

従来の「先に買収、後からAIを当てはめる」を、彼らは逆にした。 タスクレベルの知識をAIに学ばせてから、流通（顧客基盤）を買う。 人力で現場を理解する工程を、丸ごと買収で調達する発想だ。

読者の直感は、ここでも裏打ちされる。 労働集約から入り、ソフトに化けるという順番に、いま世界で最も賢い資金が張っている。

では、何を失うのか

ここからが本題だ。 この道が本流だとしても、無料ではない。失うものは、確かにある。

最も有名な罠は「コンサルの罠」だ。 人力は気持ちよく稼げる。だから人を増やす。すると人手はプロダクトではなく受託に吸われる。 転換期には、利益率の高い顧客が安いサブスクに移り、新規はまだ足りず、粗利がへこむ谷が必ず来る。

次に、バリュエーションの天井だ。 サービス業の企業価値はEBITDAの10倍前後が相場。 予測可能な継続収益を持つSaaSの評価倍率とは、見られ方の桁が違う。 ある経営者はこの断崖を「オーダーメイドのスーツ屋がユニクロになるくらいの違い」と表した。

そして、組織カルチャーの非可逆性。 受託脳は「言われたものを作る」に最適化されていく。 ビジョン設定、潜在ニーズの発掘、市場での立ち位置の設計。プロダクトに必要な筋肉が育ちにくい。 日本でも、受託からプロダクトに挑んだ企業がイベント基盤を早期撤退した例が知られる。 運用監視のような「作った後」の体力が、受託だけの組織には欠けがちだという指摘もある。

最後に、いちばん静かなリスク。 人力の心地よいキャッシュフローが、痛みを伴う転換を「来期でいい」と先送りさせる。 そのまま、高級な受託会社として終わる。化けないまま終わるリスクだ。

失うもの	中身	危険な兆候
焦点	人手が受託に吸われ製品が進まない	採用がいつも納品都合で決まる
評価	倍率の天井（サービス相場に固定）	投資家に「結局は受託」と見られる
文化	受託脳が抜けず製品筋が育たない	「言われた通り作る」が美徳になる
時間	谷を恐れて転換を先送り	黒字なのに何年も同じ業態

順番ではなく、「設計」で決まる

ここまで来ると、問いの形が変わる。 「労働集約で始めるべきか」ではない。 「最初から化ける前提で、人力をどう設計するか」だ。

同じ受託でも、ただ食うための受託と、抽象化を狙う受託は別物だ。 最初から共通項を探し、データが自社に溜まる契約を結び、転換のトリガー指標を決めておく。 そして、谷を越えるだけの資本と覚悟を、入り口で用意しておく。

労働集約は、逃げ場ではない。 AIが「作る」を無料にした世界で、現場の深さだけが、まだ複製されにくい資産だからだ。 人力で深く潜り、そこで掴んだものを、いつソフトウェアへ引き上げるか。

あなたの事業は、深く潜るための器か。 それとも、潜ったまま戻れなくなる沼か。 その線を引けるのは、入り口に立っている今のあなただけだ。

出典・参考

• a16z「Service as Software」/「The Palantirization of everything」/「AI Is Driving A Shift Towards Outcome-Based Pricing」
• Foundation Capital「AI leads a service as software paradigm shift」/「The $4.6T Services-as-Software opportunity」
• Y Combinator「The FDE Playbook for AI Startups with Bob McGrew」
• Sierra「Outcome-based pricing for AI Agents」（Bret Taylor）
• General Catalyst「The Future of Services」/ PitchBook・Sourcery.vc によるCreation Strategy報道
• Paul Graham「Do Things that Don't Scale」
• Coral Capital「もう受託は嫌、自社SaaSをやりたい」/ エンジニアtype「受託開発企業が自社プロダクト開発で陥った三つの罠」