最初のユーザーには動いた。むしろ好評だった。ところがアクセスが増えた途端、アプリの内部で何が起きているか見えにくくなり、本番のトラブルに耐える備えが追いつかない——LovableやBoltで素早く形にした人が、次にぶつかるのがこの壁です。
Lovableとは、自然言語の指示からWebアプリを丸ごと生成するAIアプリビルダー。
先に方向性を示します。ここで必要なのはゼロから作り直すことではありません。LovableもBoltも生成したコードを外部へ持ち出す手段があり、データも構成に応じて移行できます。GitHub連携やバージョン履歴も備えています。足りないのは本番運用の体制のほうです。生成済みの資産を、自分が監視・管理できる基盤へ移して運用設計を整える「中間道」があります。
- AIビルダーは試作の速さに最適化されており、監視・CI/CD・権限・本番向け復旧といった運用設計は利用者側で補う必要がある
- 選択肢は「作り直す・留まる・中間道」の三択。コードとデータを移す中間道が現実的
- 移行はコード抽出・データ移行・デプロイパイプライン・ロールバックの4要素に分解できる
本記事に出てくる料金・API仕様・対応サービス名は更新が速いため、実際に移行へ着手する際は各サービスの公式ドキュメントで最新情報を確認してください。以降の各章では繰り返しません。
AIビルダーで作ったアプリが本番で詰まる瞬間
詰まり方には共通したパターンがあります。ビルダー内だけで運用を続けると、どの変更がどの不具合につながったのかを追いにくくなったり、外部の監視・CI/CD・本番向けロールバックの設計が後回しになったりします。LovableもBoltもコードの書き出し、GitHub連携、バージョン履歴は用意されています。データについても、Supabase連携やエクスポート、移行手順を使える場合がありますが、構成によって移し方や復元範囲は変わります。それでも、実運用で必要なバックアップ・権限管理・監視・デプロイ履歴を自分の管理下で整えていなければ、本番トラブルが起きたときに動きが取れなくなります。
ここで起きているのは、バグというより構造上の限界。AIビルダーは「アイデアから試作まで最速で到達させる」ことに最適化されています。その目的に対しては正しく機能していて、欠陥ではありません。問題は、試作の次に来る本番運用の準備までは面倒を見てくれない点にあります。
具体的な症状を並べると次のようになります。ユーザーが数人のうちは快適だったレスポンスが、同時アクセスが増えると急に遅くなる。エラーが出ても、本番のログやトレースをどこで見れば原因が分かるのか整っていない。設定をひとつ変えたら別の画面が壊れ、どの変更が原因か追いにくい。どれも「動くプロトタイプ」では表面化せず、本番のトラフィックで初めて顔を出します。
「動く」と「本番で運用できる」は別物
デモで動くことと、収益を支える本番システムとして運用できることの間には、見た目以上の距離があります。デモで魅力的に見えることと、本番で安定して動き続けることは別問題です。AIを組み込んだ処理では、実行は成功したように見えて内部では誤っている、という現象も起きます。
つまり「動いた」という体験は、本番耐性のごく一部しか保証しません。表示が出る、ボタンが押せる、という見える部分が正常でも、その裏側の監視・デプロイ履歴・復旧の仕組みを本番向けに整えていなければ、運用フェーズで必ず効いてきます。
本番で足りなくなるもの——監視・本番向けロールバック・CI/CD
なぜ詰まるのかをアーキテクチャの視点で分解すると、本番運用で自分が用意すべきものがはっきりします。
まずデータの置き場所と管理。LovableはSupabase、Boltも外部DB接続やエクスポートに対応しますが、初期設定のままビルダー任せにしていると、バックアップの頻度や別環境への移し方を自分で設計しないままになりがちです。データは事業の中核資産なので、その管理を自分の手に置いておく必要があります。
次にデプロイ履歴とロールバック。ビルダーにもバージョン履歴や復元機能はあります（Boltのversion history／Restore、Lovableのバージョン復元など）。ただし本番では、どのコミットをいつどの環境へ出したかをGitやCI/CDの履歴として持ち、問題が出たら直前の正常なリリースへ即座に戻せる体制が要ります。チャット履歴ベースの復元と、本番リリースのロールバックは別物だと捉えておく必要があります。
さらにCI/CDパイプライン。コードを変更したら自動でテストが走り、問題なければ本番へ反映され、おかしければ止まる——この仕組みはビルダー内だけでは完結しにくく、GitHub連携後に外部のCI/CDへ載せて自分で組む必要があります。これが無いと、変更のたびに本番が手作業の綱渡りになります。
本番に進むとき自分で整える3つの要件
整理すると、本番運用で利用者側が用意すべき要件が3つあります。
ひとつはデータとコードを移設できる形で自分の管理下に置くこと（書き出し自体はビルダーが対応しているので、それを実運用の手順に落とし込む）。次が本番リリースのバージョン管理とロールバックで、壊れたらリリース単位で戻せること。そして変更を安全に反映する自動化された経路、つまりCI/CDです。
これらはビルダーの怠慢ではなく、設計の目的が別だったというだけ。試作の高速化を優先した結果、本番運用の体制づくりは利用者側に委ねられています。だからこそ、本番に進む段階では別のレイヤーで補う必要が出てきます。
三択（作り直す・留まる・中間道）をどう選ぶか
本番の壁にぶつかったとき、取れる道は大きく3つに分かれます。判断を迷わせないよう、コストと本番耐性、適する状況を表で並べます。
| 選択肢 | 初期コスト | 本番耐性 | 移行の手間 | 適する状況 |
|---|---|---|---|---|
| ゼロから作り直す | 高い（数か月規模） | 高い | 非常に大きい | 仕様を大幅に見直したい・予算と時間に余裕がある |
| ビルダーに留まる | 低い | 限定的 | なし | 試作・検証段階でユーザーがごく少数 |
| 中間道（コードとデータを移す） | 中程度 | 高い | 中程度 | すでに実ユーザーがいて、作り直す余裕はない |
作り直しは確実に本番耐性を得られますが、動いているものを捨てて数か月かけ直す判断は、コストも精神的負荷も重い。留まる選択は手間こそゼロでも、本番向けの監視・復旧・CI/CDを別途整えないまま抱え込むことになります。中間道は、ビルダーで作った資産を生かしながら、運用基盤だけを自分の管理下に移す折衷案です。
ケース別の当てはめ（プロト段階／初ユーザー獲得後／収益化済み）
どの道を選ぶかは、アプリが今どの段階にいるかで決まります。
まだ仮説検証中で、ユーザーが身内や少数のテスターだけなら、無理に動かさず留まるのが合理的。ここで移行に労力を割いても回収できません。次に、最初の実ユーザーが付き、課金や問い合わせが発生し始めた段階。ここが中間道を検討する分岐点で、データ消失や障害が事業に直結する前に運用基盤を整えるのが現実的です。すでに収益化していて運用が止まると損失が出る段階なら、中間道は検討ではなく着手のフェーズに入ります。
判断軸はシンプルで、「壊れたときに失うものの大きさ」。失うものが小さいうちは留まってよく、無視できなくなったら移す、という順序になります。
中間道の移行手順——コード抽出からロールバックまで
中間道の中身を、実際の作業順で分解します。ここが本記事の山場です。移行は次の4要素に整理できます。
移行前に押さえる4点チェックリスト
着手前に、この4つが揃うかを確認してください。
まずコードのクリーンな抽出。ビルダーが生成したコードを、提供元のシステムに依存しない形で取り出せること。次にダウンタイムを出さないデータ移行で、本番のユーザーデータを欠損なく別の基盤へ移すこと。3つめがデプロイパイプラインの構築。コード変更からテスト、本番反映までを自動化された経路に乗せること。最後にロールバックの確保で、問題が出たら直前の正常な状態へ戻せる仕組みを持つこと。
この4点が、ビルダー内だけでは整えにくい本番要件をそのまま埋める形になっています。移行を「引っ越し」ではなく「運用体制づくり」と捉えると、何を自分の管理下に置くべきかが見えてきます。
近年は、生成済みアプリを外部ホスティングへ移す手順や補助ツールも増えています。たとえばBoltのプロジェクトをVercelへデプロイする手順、Bolt生成アプリをRailwayへ移す手順、LovableのデータをSupabaseへ移す補助などが公開されています。ただし対応範囲はサービスごとに異なり、どんな構成でもワンクリックで一括移行できる汎用ツールがあるわけではありません。自分のアプリの構成に合う経路を選び、ビルダーで速く作ってから自分が管理できる基盤へ移す、という順序で進めるのが現実的です。
移行を安全に進めるうえで、AIコーディングツールを自律実行させる際のリスク管理も併せて押さえておくと役立ちます。隔離環境やフックを使ってリスクを下げる手法は、Claude Code を安全に自律実行する方法｜Hook・/sandbox・隔離でリスクを下げるで具体的に解説しています。
ダウンタイムを出さないデータ移行の考え方
4要素のうち最も神経を使うのがデータ移行です。本番のユーザーデータを止めずに移すには、いきなり切り替えるのではなく、移行先を並走させてから切り替える発想が要ります。
概念としての最小の流れは次のようなイメージです。実際に動くコードではなく、手順の骨格として捉えてください。
db-export --source builder-db --out snapshot.dump
db-import --target new-db --in snapshot.dump
db-sync --source builder-db --target new-db --verify
deploy --db new-db --keep-rollback
大事なのは、切り替えの瞬間まで元のデータベースを生かしておくこと。検証が通らなければ接続先を戻せる状態を保てば、ユーザーから見た停止時間を最小化できます。バックアップを取らずに移行作業を始めるのは、最も避けたい進め方です。
移行後に待つ運用リスク——データ消失とコスト膨張
移行して運用基盤を自分の管理下に移したあとも、運用フェーズ特有のリスクが残ります。
ひとつが、AIへの任せすぎによるデータ消失。ITmedia AI+の報じたGMOインターネットグループの調査では、生成AIの業務活用が広がる一方で「AIに任せすぎて本番データが消失する」事故が発生したと伝えられています。活用が進むほど、こうした事故の起きる場面も増えるという傾向が読み取れます。AIエージェントに本番の操作を委ねるなら、消えて困るデータほど人間側の確認と権限の壁を残しておく必要があります。
もうひとつがコストの膨張。高価なモデルを用途に関係なく固定で使うと、推論コストはすぐに積み上がります。ビルダー任せのままだと、こうしたコストが見えにくいまま膨らみがちです。AI機能を本番に入れるなら、モデル選定・利用量の上限・ログ監視・アラートを最初から設計し、過剰な部分を削るだけでも運用費を下げられます。
監視と権限設計を最初に決める
運用リスクは、移行が終わってから慌てて対処するより、移行と同時に枠組みを決めておくほうが安全です。何を監視するか、誰が（どのエージェントが）どの操作まで実行できるか。この2点を最初に設計しておけば、データ消失も予期せぬコストも、起きる前に検知できる可能性が高まります。運用基盤を整えることとセットで、観測と権限の設計を進めるのが現実的な順序です。
動かない・壊れたときの切り分け
AIを組み込んだアプリの厄介な点は、エラーが出ないまま間違うこと。通常のプログラムなら、処理が失敗すればエラーが表示され、そこを直せば済みます。ところがAIエージェントは、表面上は実行が成功していても、内部で誤った判断やツール選択をしている場合があります。n8nの解説でも、この「静かに失敗する」性質が強調されています。
n8n公式ブログも、AIエージェントは幻覚を起こしたり間違ったツールを選んだり指示を無視したりしても、表面上は実行が成功して見えることがある、と指摘しています。非AIのワークフローならステップが失敗すればエラーで気づけますが、AIは「静かに失敗する」ぶん厄介です。
n8nが示す切り分けは3つのレベルで構成されます。まず問題のある実行をフィルタリングして特定する。次に意思決定の連鎖をステップごとにトレースし、エージェントが「何をして、何を決め、なぜそう決めたか」を追う。それでも足りなければ外部の観測プラットフォームを使い、コードの意図ではなく実際のトレースを事実の根拠として分析する。
失敗の原因はモデル本体よりも、プロンプト内のデータ不足やツール定義の曖昧さといった周辺要因にあることが多い、とも指摘されています。症状別に当てはめると、出力が毎回少しずつ違って安定しないならプロンプトに渡すデータの不足を疑う。意図しないツールを呼ぶならツール定義の説明が曖昧でないか見直す。同じ処理を延々と繰り返すならループの終了条件が抜けていないか確認する、といった順で切り分けられます。
「成功して見える失敗」を見抜く観点
最も見落としやすいのが、ステータス上は成功なのに結果が間違っているケースです。実行ログが「成功」を返していても、それは「処理が完走した」ことしか保証しません。出力の中身が正しいかは別問題。本番では、成功フラグではなく実際のトレース（エージェントが辿った判断の記録）を根拠に判断する習慣が要ります。見えている結果だけで安心せず、裏側の決定過程まで追えるようにしておくことが、静かな失敗を早く見つけるための基本になります。
まとめ
LovableやBoltで作ったアプリが本番で詰まりやすいのは、ビルダーが試作の速さに最適化されていて、監視・権限管理・CI/CD・本番向けロールバック・データ移行手順といった運用設計を利用者側で補う必要があるからです。取れる道は「作り直す・留まる・中間道」の三択。失うものが小さいうちは留まってよく、実ユーザーが付いて事業リスクが無視できなくなったら、中間道でコードとデータを自分が管理できる基盤へ移すのが現実的です。
移行はコード抽出・データ移行・デプロイパイプライン・ロールバックの4要素に分解でき、データ移行は移行先を並走させてから切り替えることでダウンタイムを抑えられます。運用基盤を自分の管理下に移したあとも、AIへの任せすぎによるデータ消失と、見えにくいコスト膨張という運用リスクが残るため、監視と権限設計は移行と同時に決めておく。そして動かないときは、成功フラグではなく実際のトレースを根拠に、フィルタリング・トレース・外部観測の順で切り分ける。この流れを押さえておけば、試作の次の壁を越えられます。
よくある質問
Q. Lovableで作ったアプリはそのまま本番公開できますか？
小規模な検証用途であれば公開自体は可能です。ただしアクセスが増える本番運用では、監視・本番向けロールバック・CI/CDを自分で整えていないと、障害時の切り分けや復旧に手間取りやすくなります。コードやデータの書き出しはできるので、実ユーザーが付いた段階で、運用できる基盤へ移す検討が必要になります。
Q. 移行にコードの全面的な書き直しは必要ですか？
中間道では、原則として全面的な書き直しは前提にしません。ビルダーが生成したコードを依存のない形で抽出し、自分が管理できる基盤へ移すアプローチが取られます。ゼロから作り直す道もありますが、それは仕様を大きく見直したい場合の選択肢です。
Q. データを移すとダウンタイムは発生しますか？
進め方しだいで最小化できます。いきなり切り替えるのではなく、移行先のデータベースを並走させ、差分を同期して整合性を検証してから接続先を切り替えれば、ユーザーから見た停止時間を短く抑えられます。切り替え後も元のデータを残し、戻せる状態を保つのが安全です。
Q. 移行先はAWSとVercelのどちらがいいですか？
アプリの構成によって適性が変わるため一概には決められません。フロントエンド中心で素早くデプロイしたいならVercel、データベースやバックエンドまで含めて細かく管理したいならAWSが選ばれる傾向があります。
Q. AIエージェントが「成功」と表示されるのに結果が間違うのはなぜですか？
実行ステータスの「成功」は処理が完走したことを示すだけで、出力内容の正しさは保証しないためです。AIエージェントは幻覚やツールの誤選択を起こしても表面上は成功して見える場合があります。判断の根拠は成功フラグではなく、実際のトレース（決定過程の記録）に置くのが確実です。
参考資料
- Vercel 公式: Deployments ドキュメント
- AWS 公式: データベース移行ガイド
- Supabase 公式: プロジェクト移行ガイド
- n8n 公式ブログ: AIエージェントのデバッグ手法
- ITmedia AI+: 生成AI活用に関する報道
