知らないユーザーから、メールが届く。「この機能、ずっと欲しかったやつです」。自分で作ったものに、見ず知らずの誰かが価値を感じている——プロダクト・マーケット・フィット（PMF）の、最初の手応えだ。課金も少しずつ増えてきた。
だが、この実感の直後に、分岐点が訪れる。このまま自分で回し続けるか、それともエンジニアや専門の組織に渡すか。
多くのPdMは「早く人を入れなければ」と焦る。バグ報告は増え、要望は積み上がり、1人では手が回らない気がしてくる。だが、ここで安易に人を増やすと、PMFの検証がかえって曖昧になる。本記事は、この「いつ大規模体制へ移すか」という移行の判断に絞って扱う。渡し方そのものの手順は、別の機会に譲る。
まず、「1人で回す」ことの強みを手放さない
移行を語る前に、ソロ運用の強みを確認しておきたい。意思決定が速い（会議も合意形成もいらない）。利益率が高い（人件費がほぼかからない）。そして検証が速い。AIを相棒にすれば、1人でも企画から実装・計測までを一続きで回せる。
だから出発点はこうだ。これから挙げる「3つの問い」がすべて No なら、ソロのまま続けるのが正解。 焦って人を増やすのは、むしろPMFの解像度を下げる。手放すべき明確な理由が出てきて初めて、移行を考える。
移行を検討する、3つの問い
問い1：デバッグの時間が、新機能を作る時間を上回っていないか。 AIに「作って」と指示する時間より、「直す」時間のほうが長くなってきたら、黄信号だ。これは、コードの複雑さが、AIが一度に扱える範囲（コンテキスト）を超え始めたサインである。直しても直しても終わらない感覚が続くなら、1人＋AIで保てる複雑さの上限に近い。
問い2：SOC2・エンタープライズSLA・コンプライアンスが、自分の手に負えないレベルになっていないか。 法人顧客が相手になると、求められるものが変わる。SOC2のようなセキュリティ認証、可用性の保証（SLA）、監査への対応——これらは「動くものを作る」とは別種の専門性で、個人で担保しきるのは難しい。ここが本格的に必要になったら、セキュリティに強いエンジニアの力がいる。
問い3：マーケティングに本格投下して、トラフィックを10倍にする計画があるか。 計画的な急増は、運用体制の「質」を変える。スケールに耐える設計を担保するエンジニアリングが必要になる。
3つとも No なら、ソロ継続。1つでも Yes が重くなってきたら、移行を具体的に考えるタイミングだ。
サイン①：コンテキストドリフト
判断を助ける、わかりやすい現象がある。コンテキストドリフト——業界でそう呼ばれる、AIが過去の設計判断を「忘れる」現象だ。
コードが数万行に膨らむと、起きる。月曜にOAuthへ寄せたはずなのに、水曜にはAIが別の修正のついでに、古いAPIキー方式のコードを復活させている。一度直したバグが、別の修正で再発する。こうしたデグレ（後退バグ）が頻発し始めたら、それは「1人＋AIで保てる複雑さ」の天井が見えてきたサインだ。
サイン②：メンテナンスが、前進を食い始める
もう少し広く、移行のサインをチェックリストにするとこうなる。
- 新機能を作るより、既存のメンテナンスに使う時間のほうが長い。
- ユーザーからパフォーマンスや信頼性の苦情が増えてきた。
- AIに指示すると、意図しない既存機能の破壊（デグレ）が頻発する。
- 明確な需要があるのに、機能を足す速度が落ちている。
これらが揃ってきたら、移行を真剣に検討する。なお、プロトタイプが本番で壊れる仕組みそのものについては、別のナレッジで掘り下げているので、あわせて読んでほしい。
渡すなら、何を捨て、何を守るか
移行を決めたとき、よくある失敗がある。数万行のコードを、テストもドキュメントもないまま丸ごと渡すことだ。受け取ったエンジニアは絶句する。「これは直すより、書き直したほうが早い」と。
ここで大事な原則がある。作り直すべきものは、コードの“中身”だ。 アプリケーションの構造、セキュリティのインフラ、テストとCI/CD、エラーハンドリングとモニタリング——これらは、改めてちゃんと作る前提でいい。
一方で、守るべきものは「成果物」と「学び」だ。動くプロダクトが証明したこと、検証されたビジネスロジック、ユーザーとの間に積み上がった信頼。これらはコードよりはるかに価値がある。コードは書き直せるが、100人のユーザーが教えてくれたことは、書き直せない。ソフトウェア工学の古典で フレデリック・ブルックスが言ったように、最初の一つは「捨てる前提」で作られている（『人月の神話』, 1975）。捨てるのは中身、残すのは学びだ。
※ 「では具体的にどう渡すか（再構築の手順・エンジニアとの共創）」は、移行の“判断”とは別のテーマなので、ここでは深入りしない。
PdMの重心は、どう変わるか
移行は「敗北」ではない。役割の進化だ。
自分で全部やる人から、複数の力（人とAI）を束ねて全体を前に進める人へ。Lenny Rachitsky は、AI時代のPdMを「指揮者（conductor）」あるいはチームの「接着剤（glue）」と表現している。AIが資源の一つになったいま、何を任せ、誰が責任を持ち、どう束ねるか——この判断こそがPdMの価値になる（任せ方の原則は委任の設計で扱った）。
ちなみに、1人で並列にこなせることには理論的な限界もある。ある研究では、並列化できるタスクは中央で調整したほうが性能が大きく上がる一方、順を追った推論が要るタスクでは、多数のエージェントに分けるとかえって性能が落ちる、と報告されている。「全部を並列で回す」には、人でもAIでも上限がある。
対照実験：早すぎる移行と、遅すぎない移行
最後に、わかりやすい対照を二つ。
Base44（創業者 Maor Shlomo）は、PMFが見えるまでをほぼ1人で回し切った成功例だ。少人数の機動性を保ったまま深掘りし、最終的に大きな金額で買収されたと報じられている（TechCrunch 報道・約8,000万ドル）。焦って体制を膨らませなかったことが効いた。
逆に Color Labs は、PMFが固まる前に大型の資金（約4,100万ドル）を調達し、組織と支出を先に膨らませた末に苦戦した、早すぎるスケールの代表例として知られる（後に Apple が買収）。移行のタイミングを、需要の証明より先に置いてしまった。
教訓は同じ方向を向いている。移行は「需要が証明されてから」。早すぎても、引き延ばしすぎてもいけない。
まとめ
「1人で回す」は、AI時代の強力な武器だ。だが、限界線がある。
- 3つの問い（デバッグ過多／SOC2・SLA・コンプラ／10倍スケール）で、移行が必要かを見極める。すべて No ならソロ継続。
- コンテキストドリフトとメンテ過多が、複雑さの天井を教えてくれる。
- 渡すときは、コードの中身は作り直し、成果物と学びは死守する。
- 移行は役割の進化。PdMの重心は「全部やる人」から「束ねて前に進める人」へ。
AIで「作れた」のは、出発点にすぎない。その先で、いつ手を広げるか。その判断こそが、規模の大きいプロダクトを動かすPdMの仕事だ。
参考・出典
- Frederick P. Brooks Jr.・「The Mythical Man-Month: Essays on Software Engineering」（邦題『人月の神話』／Addison-Wesley）・1975（「最初の一つは捨てる前提で作る」＝plan to throw one away／記念版 ISBN 978-0-201-83595-3）
- Lenny Rachitsky・「How AI will impact product management」（Lenny’s Newsletter／PdMを「指揮者・接着剤（conductor/glue）」と表現）・2024・https://www.lennysnewsletter.com/p/how-ai-will-impact-product-management
- Google Research・「Towards a science of scaling agent systems: When and why agent systems work」（並列化タスクは中央調整が単一比+80.9%／逐次推論タスクは多エージェントで39〜70%劣化）・2025・https://research.google/blog/towards-a-science-of-scaling-agent-systems-when-and-why-agent-systems-work/
- TechCrunch・「Base44、6ヶ月・ブートストラップで Wix に約8,000万ドル（現金）で買収」・2025年6月18日（ソロ運用の機動性を保ったまま需要を証明した例）
- Fast Company・「Color Failed. What Happens To Its $41 Million?」（プレローンチで約4,100万ドル調達→失速→Apple が人材ごと取得＝早すぎるスケール）・2012・https://www.fastcompany.com/3002341/color-failed-what-happens-its-41-million
本記事の事例・概念は上記の公開・一次資料に基づく概説です。買収額・調達額は各報道時点の公表値で、細部は原典を参照してください。
同じテーマのナレッジや、すぐ使える無料テンプレもどうぞ。