AI生成アプリはベンダーのクラウドで動作する——それが問題だ

AIアプリビルダーは、プロンプトからアプリへのループを驚くほどスムーズにした。要件を記述し、結果を確認し、デプロイをクリックするだけだ。Replit、Lovable、Base44などのツールがこのサイクルをほぼ魔法のように感じさせる。しかし、多くの人が見落としている重要な詳細がある。それは、アプリがビルダーのクラウド上で動作し、ユーザーのクラウドではないということだ。

プロトタイプであれば、これはほとんど問題にならない。しかし、アプリが実際のエンジニアリングワークフローに組み込まれる瞬間、その影響は大きくなる。監視スタックの追加、ステージングデータでのテスト、CIの実行、セキュリティスキャンと監査ログの通過、組織が実際に強制するポリシー制御の遵守、チームが障害時に所有・防御できるデプロイパス—これらのどれもデモでは提供されない。

ここに「プロンプト→アプリ」ストーリーの亀裂がある。生成された出力はソフトウェアのように見える。しかし、自分のクラウドで実行できず、パイプラインを通過できず、ガバナンスモデルを満たせないなら、それはプロダクションシステムではなく、プロトタイプに過ぎない。

欠けている特性には名前がある：Bring Your Own Cloud（BYOC）だ。BYOCは10年にわたるSaaS調達を再形成し、今やAIコード生成に到来している。製品はアプリ構築を支援できるが、アプリを製品内に閉じ込めるべきではない。この問題を最初に解決するAIコード生成ツールは、デモループが示唆するよりもはるかにインフラに近い姿になるだろう。

ロックインが本番ワークフローを損なう仕組み

コストは最初のデモを超えた瞬間に顕在化する。障害は予測可能な順序で連鎖する。まず可視性が失われる。アプリはプラットフォーム管理の環境で実行され、Datadog、Sentry、OpenTelemetryなどの内部監視を追加できない。障害時はプラットフォームのサポートチームとステータスページに依存せざるを得ない。

次にテストが崩壊する。アプリが開発エコシステムの外で実行されるため、ステージング環境やセキュリティスキャンに対して検証できない。統合テスト、負荷テスト、独自パイプラインでの自動チェックが不可能になり、本番環境でシステムを信頼する根拠が失われる。

その後、コンプライアンスとセキュリティが機能しなくなる。ランタイム環境を制御できないため、SOC 2やHIPAAの義務を満たすことが困難または不可能になる。ほとんどのセキュリティチームは、監査、検査、自社ポリシーに対する検証ができない本番システムを承認しない。データ主権要件を抱える医療・金融チームにとって、これは単なる障害ではなく、絶対的な停止要因だ。

最後に、インフラが乖離する。AI生成のプロトタイプはベンダーのクラウドに存在し、本番システムはユーザーのクラウドで動作する。チームは2つの環境を維持し、ワークフローを複製し、高コストな知識サイロを構築することになる。

これらは偶然ではない。ほとんどのAIアプリビルダーは、高速なデモとコンバージョンに最適化されており、本番システムに必要な可視性、制御、監査可能性には最適化されていない。ホスティングモデルはビジネスモデルそのものであり、機能と専有ホスティングの結合こそが、かつてSaaS全体でBYOCの反発を引き起こしたものだ。

ビルダーを実際に分けるもの

有用な質問は「どのビルダーが最善か」ではない。「生成後にホスティングに対する制御をどれだけ維持できるか」だ。ビルダーはスペクトラム上に存在し、各ポイントには実際のトレードオフがある：

• Lovable：デフォルトで専有クラウドを使用。コードエクスポートとGitHub同期は可能だが、ホスティングは依然としてLovableがデフォルト。共有可能なアプリへの最速パスだが、エクスポートは上級者向けのパスであり、デプロイはLovableのインフラに依存する。
• Base44：プラットフォーム（Wix所有）に密結合。エクスポートは限定的で、プラットフォーム上でのデプロイが前提。非エンジニアにとって最高の「そのまま動く」体験。インフラが製品そのものであり、離脱は実質的に再構築を意味する。
• Replit：Replitホスト型デプロイメント。コードはGitHubにクリーンにエクスポート可能だが、デプロイワークフローはReplitネイティブ。エンドツーエンドの開発ループとコラボレーションに優れる。コードは移植可能だが、デプロイパイプラインは移植不可。
• BYOC指向ツール（例：Bit Cloud、Nuon/Renderパターンなどのインフラ層アプローチ）：クラウドに依存しないアーティファクトを生成。標準プロジェクト＋抽出可能なビルド成果物を生成し、ユーザーのクラウド/CIにデプロイ可能。最大の制御と既存パイプラインへの最もクリーンな適合を提供。代償として、即時デモの魔法を失い、セットアップと学習曲線が急になる。

この表から浮かび上がる2つの正直な注意点がある。第一に、マネージドホスティングのビルダーは、プロトタイプ、内部ツール、またはスケール運用を意図しないサイドプロジェクトには本当に優れている。摩擦が敵であり、それを除去するからだ。第二に、「BYOC」は無料ではない。利便性を制御と引き換えにしており、迅速なデモには悪いトレードだ。BYOCのメリットは、アプリが本番環境、規制対象データ、または長期メンテナンスに近づくほど強くなり、それらから遠いほど弱くなる。

AIアプリビルダーの評価方法

ロックイン問題はツールを避けることを意味しない。それは、アプリの実際の行き先に照らして評価することを意味する。

プロトタイプ、デモ、またはベンダーのエコシステム内で完結するアプリを構築しているなら、スピードを最適化し、最も摩擦の少ないビルダーを選ぶべきだ。ホスティングの結合は、そのユースケースでは機能であり、欠陥ではない。

アプリが本番環境、特に実ユーザー、規制対象データ、または複数年にわたる寿命を迎えるなら、生成を開始する前に、より厳しいテストを適用すべきだ。後回しにしてはならない：

• 可観測性：独自の監視をアタッチできるか、それともプラットフォームのダッシュボードに制限されるか？
• テスト：生成されたアプリは、既存のCI内でステージング環境やセキュリティスキャンに対して実行できるか？
• コンプライアンス：セキュリティチームが実行環境を監査し承認できるか？
• 移植性：明日ベンダーを離れた場合、何が残るか？コードだけか、それともデプロイパス全体か？

これらのテストに合格できるアプローチは複数ある。BYOC指向のコード生成ツール（Bit Cloudなど）はその一つであり、マネージドビルダーをラップするインフラ層も別の選択肢、クリーンなコードをエクスポートして独自のパイプラインを構築するのも三つ目の選択肢だ。正しい答えはチーム次第であり、特定のロゴに依存するものではない。

避けるべき罠は、即時デモ体験を製品全体と見なすことだ。生成時のスピードは感じやすく、売り込みやすい。しかし、デプロイ時の制御は必要な瞬間まで見えず、その時にはすでにスイッチングコストがロックインされている。デモが重要でないと納得させる前に、実際に何を購入しているのかを決断すべきだ。