バイブコーディングの謳い文句には、最初の段落でほぼ必ずコード所有権の話が出てくる。GitHubへエクスポートできる、独自形式ではない、持ち出せる、と。ロックインとは正反対に聞こえるし、アプリのうちReactコンポーネントに過ぎない部分については、おおむねその通りだ。
謳い文句に決して登場しない部分がデータベースだ。そして実際のアプリはそのデータベースの中に存在している。
「エクスポート」が実際にエクスポートしているもの
BoltとBase44はどちらもフロントエンド向けにシンプルなGitHub連携を提供しており、LovableもそのReact/TypeScript出力に対して同様だ。あなたのアプリがマーケティングサイトや静的なプロトタイプであれば、そのエクスポートはほぼすべてに近く、リポジトリを開発者に渡してきれいに手を引くことができる。
業務用アプリはそうはいかない。ログイン、ロール、実データが登場した瞬間、アプリを動かしている要素の大半はコンポーネントツリーの中ではなく、その背後にあるスキーマ、認証ルール、権限ロジックの中にある。そしてまさにそこが、これらのプラットフォームが手放したがらない層なのだ。
Base44はこれを暗黙的ではなく明示的にしている。レビュアーたちはフロントエンドコードはGitHubへエクスポートされるが、データベースとバックエンドは完全にBase44のインフラ上にホストされたままで、直接変更もエクスポートもできないと指摘する。自分のファイルをプラットフォームから取り出そうとしたあるBase44ビルダーは、Redditで率直にこう述べた。「アクセス可能なファイルの中にsrcファイルが見当たらない。ビルドをBase44から取り出すためだけに、builderティアを1年分支払う必要がありそうで怖い。480ドルというのはさすがにばかげている」。技術的には離脱できる。ただし、何を持って離脱することになるのかを知るために、まず料金を支払わなければならない。
ホテル・カリフォルニア問題
Lovableへの苦情はさらに一歩踏み込んでいる。問題はエクスポートできないものが何かだけでなく、確認もなく何が変更されるかにもあるからだ。コミュニティで参照点になっているあるRedditスレッドは、LovableのAIがビルダーのプライベートなSupabaseデータベースを、明確な同意なしにLovable Cloudへ自律的に移行したと説明し、このプラットフォームを「あなたのデータベースにとってのホテル・カリフォルニア、チェックインはできるが決して出られない」と表現している。
これは「エクスポートボタンがない」とは違う種類の失敗だ。プラットフォームが、そもそもエクスポートする必要があったはずのものを静かに移動させているのだ。ツールの売り文句を信じて自分のデータは自分のSupabaseプロジェクトにあると思い込んでいた場合、後になって事実が違うと知ることは、まさに他のビルダーが同じ思い込みをする直前に読むことになる、警告のようなRedditスレッドを生み出す類の驚きだ。
Base44のバックエンドロックインは、別の角度から同じ結論に至る。あるProduct Huntのレビュアーは、フロントエンドコードがきれいにエクスポートできる場合でも、データベースとバックエンドはBase44の閉じたインフラに閉じ込められたままで、本当の意味でのデータベース移行を妨げていると指摘した。2つのプラットフォーム、2つの仕組み、しかし結果は同じだ。アプリの実際のビジネスデータを保持している部分こそが、簡単には持ち出せない部分なのだ。
なぜこの問題は横ばいではなく積み上がっていくのか
初日にはこれはさほど問題にならない。初日はサンプルデータによるデモに過ぎないからだ。問題が表面化し始めるのは、アプリに実際のユーザーがつき、スキーマが最初のプロンプトで組み立てられた規模を超えて成長した後だ。
**スキーマ負債こそが「いずれ移行すればいい」を「もう身動きが取れない」に変える仕組みだ。**Lovableを長期間使っているビルダーたちの報告によれば、AIにデータベーススキーマを設計させるのは最初はうまくいくが、6～9か月もすると、新しいフィールドを1つ追加するだけで下流の何十ものワークフローを書き直す必要が生じるほどのスキーマ負債が生まれる。その段階になると、移行はテーブルをコピーする作業ではなく、構築中に誰も完全には文書化しなかったシステムを解きほぐす作業になる。同じ調査は、経験を積んだビルダーたちが今では18～24か月を超えて運用するものにはLovableを勧めていないと指摘し、その負債がさらに積み上がる前にコードファーストのスタックへ移行することを推奨している。
そこに、プラットフォーム自身のアップデートが足元をすくうという事情も重なる。Lovableのビルダーたちは、プラットフォーム自身のアップデートが既存のクライアントアプリを頻繁に壊すと述べており、一部は今や、プラットフォーム自身が引き起こした不具合を吸収するためだけに、クライアントへ月額のメンテナンス料を請求しているほどだ。データベースにロックインされているだけではない。ロックインされている間にベンダーが引き起こす被害を修復することにもロックインされているのだ。
「Base44には正直、恐怖を感じている。自分のビジネスの基盤をあのプラットフォームの上に構築しているのに……今日動いているものが、明日には取り上げられてしまうから」 - Base44ユーザー、r/Base44
実際にリスクを減らすもの
「ホスト型プラットフォーム」でありながらロックインがゼロというバージョンが存在するふりをするつもりはない。Softrもホスト型であり、アカウントを解約すれば、LovableやBase44の場合と同じく、持ち出せるアプリが手元に残るわけではない。誠実に問うべきなのは「ロックインを完全に避けられるか」ではなく、「プラットフォームを使い続けている間、どれだけ自分のデータにアクセスし続けられるか、そしていつか離脱が必要になったとき、その離脱はどれだけひどいものになるか」だ。
この問いにおいては、マーケティングの謳い文句よりも仕組みそのものの方が重要だ。基幹業務を支える何かをどのプラットフォーム上に構築するにせよ、その前に確認しておく価値のある点がいくつかある。
- 外部ツールがアプリのUIを介さずにデータへアクセスできるか？ Softr自身のデータベースはMCPサーバー（
mcp.softr.io）とREST APIを公開しており、Claude、Cursor、あるいはスクリプトのようなツールが、構築中であっても自然言語でスキーマを読み取り、書き込み、再構成できる。Softrはこれを、データベースを単一インターフェースの外からもアクセス可能に保つことでロックインを防ぐ仕組みだと明確に位置づけており、これは「いずれコードをエクスポートできる」とは異なる種類の約束だ。 - プラットフォームは知らせずに静かにインフラを移動させるか？ これはまさにLovableに寄せられた苦情だ。プラットフォームがAIの動作の一部としてデータの置き場所を再割り当てできるなら、何がそれを引き起こすのか、オプトアウトできるのかを確認しておこう。
- 6か月後、スキーマの変更には実際にどれだけのコストがかかるのか？ すべてが真新しいAIの土台である初日ではなく、実際の利用がデータを形作った後の話だ。スキーマ負債はロックインのゆっくりとしたバージョンであり、料金ページには決して現れないものだ。
アプリが本当にプロトタイプや個人プロジェクトであるなら、これらの話は何一つ、今週末バイブコーディングでそれを作ることを妨げるものではない。エクスポート可能なコードだろうと何だろうと構わない。しかし、それがクライアントポータルや社内ツール、あるいは実際のユーザーと実データを扱う何かであるなら、Day Twoの問題とロックインの問題は、名前が2つある同じ問題だ。初日に考えなかった配管こそが、200日目に最も動かしにくいものになる。簡単には離れられない基盤を選ぶ前に、クライアントポータル向けランキングを確認してほしい。