AIビルダーを卒業する時が来たら？FAQ

この質問は、決まった形で出てきます。「AIビルダーを使うべきか」ではありません――それは別の投稿であり、たいてい別の人が聞くものです。今回の質問は、実際にうまくいっている構築を6ヶ月、8ヶ月、12ヶ月と続けてきた人から来ます。本物のユーザーがいて、本物の収益もあるが、ツールがこれ以上先に連れて行ってくれない壁にぶつかりそうだという、しつこい違和感があるのです。以下は、私が実際によく聞かれる質問を、聞かれるおおよその順番で並べたものです。

AIビルダーは本当に限界に達しうるのか、それとも自分に言い聞かせているだけの話なのか?

どちらも実際に起きますし、外から見ると見分けがつきません。本当に限界に達している場合は具体的です。3者間の分割決済を伴う決済フローが必要だったり、規制当局が実際に読む監査証跡を伴うコンプライアンスワークフローが必要だったり、あるいはリアルタイム動画処理、物理シミュレーション、自社データで学習させたカスタムレコメンドモデルなど、計算面で特殊なことをしている場合です。これらはプロンプトの問題ではなく、アーキテクチャの問題です。

偽物のバージョンは、まだ書いていないプロンプトです。「ビルダーはカーソルページネーション付きの無限スクロールができない」というのは、たいてい誰もカーソルページネーション付きの無限スクロールをきちんと説明していないという意味です。誰かが一度「ページネーションを追加して」と試して、結果が気に入らず、二度目の試みではなく静かに「制限事項」として片付けてしまったということです。「限界に達した」という会話の4分の3くらいは、書き直しではなく、より良いプロンプトで解決すると私は思っています。

自分がどちらのケースなのか、どう見分ければいいのか?

正直なところ見分けるポイントは、具体的な技術要件を名指しできるか、それとも単なる感覚を語っているかです。「指数バックオフとデッドレターキュー付きのwebhookリトライが必要だ」は要件です。「なんとなく、もう自分専用のものが必要な気がする」は感覚であり、感覚はたいてい移行ではなく、より良いプロンプトを書くことで解決します。

離れると決めた場合、実際に何を所有しているのか?

これは人々が最も不安に思う点ですが、答えは最もすっきりしています。自分が所有しているのは、自分自身のドメインにデプロイされたもの、それにデータです。自分で管理するドメイン――SFTP経由や自分のレジストラ経由で――に公開したのであれば、そのサーバー上のファイルは、レンタルしているどんなサーバー上のコードとも同様に自分のものです。誰もそれを取り上げることはできません。Search ConsoleやAnalyticsとの連携は自分が認可したGoogleアカウントであり、ビルダーとの連携を解除しても、Googleのシステムに蓄積された過去のデータには何の影響もありません。もともとビルダーのデータではなかったからです。それはあなたのアカウントの、フィルターされたものにすぎません。

自動的には手に入らないのは、チャット履歴、計画文書、検証記録、そしてプロジェクトに関するビルダーの内部モデル――反復を高速にしていたものそのものです。これがプラットフォームに本当に結びついている部分であり、新しいツールでその文脈を手作業で再構築することになるまで、多くの人がその価値を過小評価しがちな部分でもあります。

ロックインは存在するのか、それとも自分が心配しすぎなのか?

「ロックイン」の意味次第です。「サイトを人質に取られることがあるか」という意味なら――答えはノーです。初日から自分自身のドメインにデプロイしていれば、その心配はありません。それこそが、いつまでもサブドメインで運用し続けるのではなく、ドメインを所有することの意義です。「離脱すると、数ヶ月の反復で積み上げた複利的な価値を失うか」という意味なら――答えはイエスですが、それは本当の意味でのロックインではなく、時間を投資したツールから切り替えるときに誰もが払う、単なるサンクコストです。どんなエディタも、どんなフレームワークも、どんなCRMもこの性質を持っています。問題は、切り替えコストが存在するかどうかではありません。それが人為的なもの（契約条項、データの人質化）なのか、自然なもの（どこかで勢いをつけたので、移動すればそれを再構築する必要がある）なのかです。人為的なロックインは危険信号です。自然な切り替えコストは、単に「あるツールに習熟する」ということの意味そのものです。

もう一つプロンプトを書くのではなく、実際にエンジニアを雇うべきタイミングはいつか?

よく見かける順に3つの状況があります。

• コンプライアンス上の理由で、その場に責任を負う人が必要な場合――一部の規制フレームワークでは、どれほど優れていても、AI生成コミットの監査証跡ではなく、名前のある責任あるエンジニアを求めます。
• 本当に新規性のある技術的課題を抱えている——「マーケットプレイスを作る」のような既に確立された話ではなく、独自データでチューニングされたカスタムマッチングアルゴリズムのような、価値そのものが新規性にある課題です。求められる相手は、望む結果を説明するだけでなく、その特定の数式について推論できる人物です。
• 「動く生成コード」と「実際のトラフィック形状に合わせてプロファイリング・調整された生成コード」が乖離する規模をすでに超えている場合――これは実在しますが、ほとんどの人が思うよりずっと先の話です。「ビルダーには大きすぎる」と感じるアプリの多くは、月間アクティブユーザー数万人程度であり、構造がしっかりした生成コードにとってはそもそもスケールの問題にはなりません。

このリストに載っていないものに注目してください――「もっと制御したい」です。もっと制御したいというのは好みであって要件ではなく、自分が今感じているのがどちらなのか、正直に見極める価値があります。

エンジニアを迎え入れる場合、AIが構築したコードを拡張すべきか、それとも一から作り直すべきか?

ほぼ常に拡張すべきです。チームが「AI生成だから使い捨てに違いない」とデフォルトで判断し、一から書き直すことでこれがうまくいかなくなるケースを、うまくいくケースより多く見てきました。それは評価ではなくバイアスです。まず実際のコードを読んでください。合理的に構成されていれば――そして、出荷前に計画と検証ステップを見せてくれるビルダーは、一貫した計画が一貫したコードを生むため、筋の通ったコードを生成する傾向があります――最も速い道は、普通のエンジニアが普通のコードベースを引き継ぐことです。全面書き直しは高くつく選択肢であり、コードの出所を理由にではなく、これから必要になることを本当にコードが支えられない場合に限って取っておくべきです。

ビルダーを「卒業」した6ヶ月後に、人々が実際に陥る失敗パターンは何か?

彼らはイテレーションループを失い、それを補うことをしない。ビルダーの本当の価値は、多くの人にとって「コードを書くこと」だけではなかった——コードを書けるものはほかにもたくさんある。それは、人間が毎ステップのボトルネックにならずにタイトなループで回る、提案 → 検証 → デプロイ → 計測というサイクルだった。ビルダーから卒業してもそれに匹敵するループ——CI、ステージング、モニタリング、アイデアから出荷までの速い経路——を再構築しないチームは、ビルダー導入初日よりも出荷が遅くなり、しかもコードベースが以前より「本物」らしく感じられるため、数か月間その事実に気づかないことが多い。本物であることと速いことは同じ性質ではない。ツールを卒業するなら、離れる前のループと少なくとも同じくらいタイトなプロセスへ卒業すべきで、単に自分が所有するファイルが増えるだけの状態へ卒業してはいけない。

「限界に達した」という言葉の正直なバージョンは、たいてい「特定の、名前のつけられる要件に対応できないところまで成長した」という意味です。その要件を名指しできないなら、おそらく何も限界に達していません――ただ反復をやめただけです。