Lovableの代替候補｜コードを引き継いで育てるアプリ開発

この記事の内容

移す対象を画面とデータに分ける

画面のコードだけを移しても、ログイン、DB、画像、メール配信が移るとは限りません。使っている外部サービス、環境変数、ドメイン、保存データを一覧にします。移行先で同じ機能を動かすために必要な項目を把握してから、どの開発環境で修正を続けるかを検討します。

ReplitやBoltを候補にする場合は、既存コードの扱い、依存関係、実行環境、公開先を公式案内で確認します。同じ画面を一から再生成する方法と、既存のコードを引き継ぐ方法は別です。継続開発を重視するなら、簡単な不具合修正を既存コードで行えるかを優先して試しましょう。

コードを読む担当者がいる場合は、Claude Codeのような開発エージェントを使い、既存のリポジトリと通常の公開環境で育てる方法も候補です。これはホスティングまで一体で提供することを意味しません。起動、テスト、公開、障害対応を誰が行うかを先に決める必要があります。

移行用の複製で、未ログイン、一般ユーザー、別ユーザーのデータ、管理者の操作を確認します。見た目が同じでも権限や保存先が変わっている可能性があります。個人情報を含まない検証データで試し、移行前後の件数と必要な画面が一致することを確認してから公開先を切り替えます。

架空の問い合わせフォームを移すなら、見た目だけでなく、保存した件数、管理画面で読める内容、通知の送信先を確認します。旧環境で受けた問い合わせと、新環境へ移したデータが混ざらないように切り替え時点を決めます。試験では通知を実際の顧客へ送らない設定を使い、動作を確認してから本番の送信先へ切り替えます。

元の契約、移行先の契約、DBやサーバー、モデル利用、保守時間を分けます。移行後の月額が小さくても、日々の修正を依頼できる人がいなければ運営は止まります。現在の課題を解消し、別の担当者が修正と公開を一度行えることを、移行の完了条件にしましょう。

料金・提供条件・対応範囲は変更されることがあります。契約前に、下記の公式ページでご確認ください。