1つのプロダクトが2つになるとき：AIで作ったアプリを、ゼロからやり直さずに分割する方法

あなたは1つのアイデアから始めました。それをAIアプリビルダーに説明し、画面が生成されるのを眺め、粗い部分を直し、本物のものを出しました。人々が使い始めました。そして、最初はゆっくりと、フィードバックの中にあるパターンが現れてきます。ユーザーの半分はあるものを求め、もう半分は別のものを求めている。同じ機能を取り合っているのではありません。彼らは2つの異なるプロダクトを求めているのです。

これは、多くの創業者がパニックに陥り、2つめのプロジェクトをゼロから始めてしまう瞬間です。そうすべきではありません。1つのプロダクトが実は2つだったと分かったとき、AIアプリを分割するもっときれいなやり方があります — そしてそれは、たいてい、すでに作ったもののほとんどを残します。この記事は、分割をどう見極めるか、いつやるべきか、そして分割が取りがちな3つの形について、です。

自分が2つのプロダクトを持っていると気づくとき

そのサインは、ほとんど機能リクエストのようには見えません。それは摩擦のように見えます。

私が見てきた、これを経験したある生産性アプリには、はっきりした物語がありました。それは「個人向けプランナー」として売られていました。ユーザーは2種類に分かれて現れ始めました。一方のグループは、自分の週の予定を組むために使い、まるで個人のノートのように扱っていました。もう一方のグループは小さなチームを率いていて、他の人にタスクを割り当てたがっていました。どちらも同じプロダクトを使い続ける程度には満足していましたが、リリースのたびに一方のグループを喜ばせ、もう一方を苛立たせていました。チームは、自分たちには機能の優先順位づけの問題があると思っていました。実際にあったのはブランドの問題でした。彼らは、個人向けアプリとチーム向けアプリが、1つのコードベース、1つのホームページ、1つの価格ページを共有している状態だったのです。

次のいずれかが本当になり始めたとき、あなたはその一線を越えたと分かります。

2つの読み手が同じ言葉を信じてくれないせいで、ランディングページが実際の売り文句を当たり障りのない言い回しの裏に埋めなければならない。
新しい機能を作るたびに、「でも、もう一方のタイプのユーザーには違う動きをすべきだ」という但し書きがつく。
サポートの返信が枝分かれし始める。「もしご自身のために使っているなら…」対「もしチームを管理しているなら…」。
少なからぬ数のユーザーが、2つのモードを分けておくために、別々のアカウントを2つ持っている。

これらのうち2つ以上を目にしているなら、それは機能の問題ではありません。起こるのを待っているプロダクトの分割です。

分割の3つの形

初日に形を選ぶ必要はありません。たいていは、いちばん軽いものをまず試して、必要に応じて格上げできます。ただ、AIビルダーに説明し始める前に、選択肢を知っておくと役に立ちます。あなたが使う言葉が、生成されるものを形づくるからです。

形1：1つのアプリ、2つのドア

いちばん軽い版です。コードベースは1つのまま。最初の起動時に質問を1つ足します — 「ご自身のために来ましたか、それともチームのために？」 — そしてその答えを使って、異なるページのセットと異なるナビゲーションを表示します。同じデータストア。同じログイン。同じ課金。ただ表層が違うだけ。

ほとんどのAIアプリビルダーは、これを「2モードのアプリ」として説明すれば、うまく扱えます。注意すべきは、2つのモードが、あちこちに条件つきの表示・非表示が散らばった画面を共有してはいけない、ということです。それは結局、2つのふりをした、ごちゃごちゃの1つのアプリのように見えてしまいます。ビルダーには、2つのドアは別物だと伝えましょう — 異なるホームページ、異なる設定ページ、異なる空の状態。実際に重なる数少ない画面（アカウント設定、課金）は共有してかまいません。

これがうまくいくとき：2つの読み手が、異なる枠づけを求めているが、根底にあるオブジェクトは同じである場合。プランナー対チームの例がここに当てはまります。予定を組んでいる対象は依然としてタスクであり、変わるのは割り当て・共有・通知をめぐるルールだけです。

これがうまくいかないとき：2つの読み手が、まったく異なるオブジェクトを期待している場合。「クライアントポータル」と「社内管理ツール」は、たとえ同じビジネスについてのものに見えても、ほとんど重なりがありません。

形2：2つのアプリ、1つのバックエンド

中間の形です。プロダクトの表側を、2つの別々のアプリに分割します — 2つのURL、2つのランディングページ、2つのオンボーディングフロー、2つの価格表 — でも、その下では両方が同じデータベースから読み込んでいます。顧客は両方にアカウントを持てます。管理者は両方のデータを見られます。

これは、このブログを運営している会社で、私たちが最近やったことです。私たちは、2つの読み手に応えようとする1つのアプリを抱えていました。私たちのエージェントプラットフォームを検討しているエンジニアと、私たちのAIアプリビルダーを使っているビルダーです。同じバックエンド、同じ認証、同じデータベース — でも表側は頭が2つに育っていて、メッセージは混乱していました。私たちはそれを、読み手ごとに1つずつ、2つの表側アプリに分割しました。バックエンドはまったく同じままです。

この形が正解なのは、こういうときです。

2つの読み手が、異なる理由で購入する。
もう一方の読み手向けのマーケティングコピーに、混乱したり、興ざめしたりする。
彼らが気にするデータは、形はだいたい同じだが、枠づけが違う。
データベースや課金のしくみを2つ維持したくない。

AIビルダーには、「既存のAPIを共有する2つめの表側アプリがほしい」と伝えましょう。たいていの現代的なAIビルダーは、兄弟プロジェクトの骨組みを作り、それを既存のバックエンドに向けられます。避けるべき罠：最初のアプリのコンポーネントをそのままコピペして、それから両方のコピーを永遠に編集し続けること。ビルダーに、共有部分（認証画面、共通のフォーム部品）を、両方のアプリが使う小さなライブラリに抽出してもらいましょう。あとあと、重複した修正で何ヶ月も無駄にせずに済みます。

形3：2つのアプリ、2つのバックエンド

いちばん重い分割です。あなたは本当に2つのプロダクトを持っています。それらはデータを共有せず、ユーザーを共有せず、ロードマップも共有すべきではありません。正しい動きは、完全に分離することです。別々のコードベース、別々のデータベース、別々のドメイン。

これが正しい動きであることは、人々が思うよりも少ないものです。きれいに感じられるから魅力的なのです。現実は、まったく別々の2つのアプリということは、動かし続けるべきものが何もかも2つになる、ということです — 2つのデプロイパイプライン、2つのオンコール当番、2つの課金連携、2つのヘルプドキュメント。プロダクトが本当に重ならないのでない限り、この形に手を伸ばさないこと。良いテスト：プロダクトAのユーザーが絶対にプロダクトBのユーザーにならない、というなら、あなたはおそらく形3が必要です。ユーザーのほとんどが、もっともらしく両方を求めうるなら、ほぼ確実に求めているのは形2です。

AIビルダーでこれをやるとき、いちばん簡単な動きは、2つめのために既存のプロジェクトを出発点としてコピーすることで、それからビルダーに、属さない機能を取り除き、属する機能を足してもらいます。2つめのプロジェクトを真っ白なキャンバスから始めないこと。最初のものを作る過程ですでに多くを学んでいますし、許せばAIビルダーがその文脈を引き継いでくれます。

何かを分割する前にやるべきこと

分割をAIビルダーに説明する前に、小さなことを3つやりましょう。聞こえるより価値があります。

第一に、それぞれの側の新しいホームページを書く。 それぞれ2段落。売り文句、読み手、彼らにやってほしい1つのこと。異なるホームページを2つ書けないなら、あなたはまだ実際には2つのプロダクトを持っていません — 1つのプロダクトの2つのセグメントを持っているだけで、それはアーキテクチャではなくメッセージで解決すべきです。

第二に、どの画面が共有で、どれが共有でないかを挙げる。 正直に。「ログインは共有。オンボーディングは別。ダッシュボードは別。設定はほぼ共有。課金は共有。」このリストが、AIビルダーに渡すブリーフになります。多くの行ったり来たりを省いてくれます。

第三に、根底で何が同じかを決める。 同じユーザー？同じデータ？同じ決済？「はい」のたびに、あなたは形1か2へ引き寄せられます。「いいえ」のたびに、形3へ引き寄せられます。正解はありません — あなたのプロダクトが実際にどう動いているかに合う答えがあるだけです。

分割のあとに変わること

2つのことが楽になり、1つのことが難しくなります。

マーケティングが楽になります。各アプリが、それ自身の明確な売り文句を持ちます。各ランディングページが、ぼかさずに1つの読み手に語りかけられます。コンバージョン率は、たいてい少なくとも片側で上がり、ときには両側で上がります。

オンボーディングが楽になります。初めてのユーザーが、みんなのためであろうとするページではなく、自分についてのページに着地します。

難しくなるのは、共有部分を同期させておくことです。ログインフローのバグを直したら、両方のアプリで直っていてほしい。課金画面の見た目を変えたら、両方のアプリにそれが反映されていてほしい。必要な規律は — そしてこれは、AIビルダーでバイブコーディングしていようと、人間の開発者チームで作っていようと、変わりません — 共有部分を本当に共有にしておくことです。複製しないこと。フォークしないこと。共有画面を、両方のアプリが使う小さなライブラリに抽出するか、あるいは、自分には本当に別々の2つのアプリがあると受け入れて、それを引き受けるか、どちらかです。

最後に、小さな問い

もし今のあなたのアプリの売り文句を見知らぬ人5人に聞かせて、彼らがそれぞれ違うふうに — でも2つのはっきりしたバケツに分かれて — 説明したなら、あなたはおそらくもう分割と共に生きています。唯一の問いは、混乱した1つのプロダクトの税金を払い続けるか、それとも、2つであることに正直になる仕事をするか、です。

今日決める必要はありません。でも、次にAIアプリビルダーが「次は何を作りましょう？」と尋ねたら、いちばん役に立つ答えは新しい機能ではないかもしれない、と考えてみてください。それは、新しい入り口かもしれません。

これが響いたなら、以前の記事チームのために作るか、顧客のために作るかも気に入るかもしれません — 同じ味の判断で、プロダクトの人生のもう一歩手前にあるものです。