LovableからMythexへの移行方法（コード、データ、ドメイン）

LovableからMythexへ移行するには、まずLovableのGitHub連携を使ってコードを取り出します。次にリポジトリを連携するか、アーカイブをインポートして、そのコードをMythexのプロジェクトに取り込み、シークレットを再登録して、公開前にプレビューでテストします。フロントエンドは通常、変更なしで移行できます。実際に判断が必要なのはバックエンドです。既存のSupabaseプロジェクトを使い続けるか、データを別の場所へ移すかを決めてください。

このガイドでは、移行の全体を順番に説明します。作業が必要な部分も隠さずに書いています。

開始前に：実際に移るもの

Lovableのアプリは複数の要素で構成されており、それぞれ移行の仕方が異なります。

まずは自分のアプリについてこの表を書き出してください。10分ほどで済み、ほとんどの想定外の問題を防げます。

手順1：Lovableからコードを取り出す

Lovableのドキュメント（2026年9月時点）では、取り出し方法として次の二つが説明されています。

• GitHub同期。 LovableはプロジェクトをGitHubと双方向に同期でき、そのドキュメントでは全プランでgithub.comに対応しているとされています。LovableでGitHubを接続すると、自分が所有するリポジトリにコードが保存されます。Lovableは一度に一つのブランチを同期する点に注意してください。
• コードベースのダウンロード。 Lovableの有料プランでは、Project settings → Gitから直接コードをダウンロードできます。

移行にはGitHubのほうが適しています。履歴をすべて取得でき、新しい環境をテストしている間も同期を続けられます。最新の手順は、LovableのGitHub連携のドキュメントを参照してください。

Lovableを離れる前に、リポジトリを開いて次を確認してください。

• アプリが必要とする環境変数の一覧がある.envまたは.env.exampleファイル
• データベースのマイグレーションやEdge Functionのコードが入っている可能性があるsupabase/フォルダ
• アプリのビルド方法と実行方法が分かるpackage.jsonのスクリプト

手順2：バックエンドをどうするか決める

これがもっとも重要な判断です。Lovableのアプリは通常、データベースとログインにSupabaseを使っています。自分で接続したSupabaseプロジェクトを使う場合と、Lovable Cloudを使う場合があります。

方法A：自分のSupabaseプロジェクトを使い続ける

アプリがすでに自分のSupabaseプロジェクトと通信しているなら、これがもっとも簡単な方法です。アプリのコードは同じSupabaseのURLと同じキーで呼び出しを続けるので、データ、ユーザー、ファイルはそのまま同じ場所に残ります。移すのはフロントエンドだけです。

方法B：Lovable Cloudから離れる

アプリがLovable Cloudを使っている場合、LovableはMore → Cloud → Overview → Advanced settingsからのデータベースのエクスポートを文書化しています。Lovableのドキュメント（2026年9月時点）によると、次のとおりです。

• エクスポートには、構造とデータを含むデータベース全体が含まれ、ユーザーアカウントとそのパスワードのハッシュも含まれます。
• 含まれないものは、ストレージ内のファイル、Edge Functionのコード、プロジェクトのシークレットです。サインインプロバイダーの設定も含まれません。
• エクスポートは最大15 GBのデータベースに対応し、ファイルは最大5 GBで、エクスポートは24時間に一回まで依頼できます。
• CloudからSupabaseへのワンクリックの移行はありません。Cloudのバックエンドを移す際にサポートされている移行先は、マネージドSupabaseまたはセルフホストのSupabaseです。

そのため、実際には次の流れになることが多いです。エクスポートを自分のSupabaseプロジェクトに復元し、ストレージのバケット、Edge Functions、認証の設定をそこで作り直し、その後は方法Aとして扱います。詳細は、Lovableの詳細設定のドキュメントを参照してください。

方法C：すべてをMythexのデータベースに移す

Mythexではプロジェクトに専用のPostgresデータベースを割り当てられます。データをそこへ移すことは可能ですが、アプリがSupabaseのクライアントライブラリを使っている箇所をすべて書き直す必要があります。また、Mythexにはエンドユーザー向けの組み込みログインがないため、別の認証プロバイダーも接続することになります。これは移行ではなく、バックエンドの本格的な作り直しです。SupabaseのままアプリをMythex上で動かしてから、必要であれば後で行ってください。

手順3：コードをMythexに取り込む

Mythexで新しい空のプロジェクトを作成します。そのうえで、次のいずれかを行います。

• アーカイブをインポートする。 project settings → Export → Import into this projectを開き、.zip、.tar.gz、.tgzをアップロードします。GitHubのDownload ZIPボタンで取得したファイルも使えます。
• GitHubを連携してプルする。 プロジェクト設定でGitHubを接続し、リポジトリを連携してプルします。GitHub同期はProの機能です。

インポートはプロジェクトのファイルを置き換えるため、空のプロジェクトを使ってください。アーカイブ内の.envファイルは、インポート時に削除されるため、シークレットが誤って持ち込まれることはありません。インポートが成功すると、Mythexは新しいチャットを開けます。そこでエージェントが依存関係をインストールし、アプリの実行方法を判断して、プレビューを起動します。このチャットは他のチャットと同じように操作できます。詳細はインポート後についてを参照してください。

プレビューが自動的に起動しない場合は、次のように依頼してください。

このプロジェクトはLovableからエクスポートされたものです。React + TypeScript + Tailwindのアプリで、Supabaseを使っています。依存関係をインストールし、package.jsonから開発用コマンドを判断して、プレビューを起動してください。まだアプリのコードは変更しないでください。

手順4：シークレットを再登録する

project settings → Secretsを開き、アプリに必要な値をそれぞれ追加します。Supabaseを使うアプリの場合、通常はSupabaseプロジェクトのURLと公開用（anonまたはpublishable）キーです。名前は.env.exampleか、コードが値を読み込んでいる場所から取得してください。

次の二つのルールに従ってください。

• フロントエンドの変数には公開キーだけを入れます。Viteのアプリでは、VITE_で始まるものはすべて、訪問者全員がダウンロードするJavaScriptに埋め込まれます。
• Supabaseのservice roleキーをフロントエンドのコードに入れないでください。サーバー側の関数で必要な場合は、サーバー側にとどめてください。

そのうえで、アプリがそれらを正しく読み込んでいるかをエージェントに確認してもらいます。

このアプリが読み込んでいる環境変数を確認してください。プロジェクトのシークレットにまだ設定されていないものを一覧にしてください。値は表示しないでください。

公開値と非公開値の違いについては、環境変数とシークレットのガイドで説明しています。

手順5：切り替える前にテストする

Lovableのアプリはまだ稼働しているので、急ぐ必要はありません。Mythexのバージョンをプレビューで、実際の操作の流れに沿ってテストしてください。

• サインアップ、ログイン、ログアウト、パスワードのリセット
• レコードの作成、編集、削除
• ファイルのアップロード（アプリがその機能を持つ場合）
• Edge Functionやサードパーティ製APIを呼び出す処理

Supabaseの認証には見落としやすい設定が一つあります。ログインやパスワードリセットのメールで許可されるリダイレクトURLです。Mythexのプレビューと公開用のアドレスをそこに追加してください。さもないと、ログインが古いドメインに戻されてしまいます。

Mythexの/testコマンドを使うと、エージェントがユーザーのようにプレビューを操作し、壊れている操作の流れを報告します。より詳しいチェックリストは、公開前にアプリをテストする方法のガイドにあります。

手順6：公開してドメインを移す

すべてが動作したら、ワークスペースから公開して<slug>.mythex.appのアドレスを取得します。公開されたアプリはプロジェクトの独立したスナップショットなので、そこでもう一度テストしてください。

Proプランでは、自分のドメインを接続できます。ドメインプロバイダーでDNSレコードを更新し、新しいアドレスをSupabaseの許可されたリダイレクトURLに追加してから、ようやくLovableのバージョンを停止してください。DNSの手順は、独自ドメインの接続方法のガイドで段階ごとに説明しています。

よくある失敗

• データベースとフロントエンドを同時に移す。 まずフロントエンドを移し、既存のバックエンドに対して動作することを確認してから、データをどうするかを決めてください。
• Edge Functionsを忘れる。 アプリがSupabase Edge Functionsを呼び出している場合、それらはSupabaseに残すか、サーバーコードとして書き直す必要があります。Viteのフロントエンドの中では動きません。
• service roleキーをフロントエンドに貼り付ける。 開発者ツールを開いた人なら誰でも、データベース全体に対する完全なアクセス権を得てしまいます。
• 認証のリダイレクトURLの追加忘れ。 プレビューではログインできても、実際のドメインでは失敗します。
• 公開されたURLをテストする前にDNSを切り替える。 まずmythex.aiのアドレスをテストしてください。DNSの変更は元に戻すのに時間がかかります。
• 作業済みのプロジェクトにインポートする。 インポートではファイルが置き換えられます。新しいプロジェクトを使ってください。

Lovableに残る方が適している場合

なぜ移行するのかを率直に考えてください。Lovableは、プレビュー上でのポイント＆クリックのビジュアル編集と、Lovable Cloudによる製品化されたバックエンドを提供しています。Mythexにはどちらもありません。日々それらに頼っているなら、移行によって得るものより失うものの方が大きくなります。実際のコードエディターとターミナルがチャットと並んで使えること、構築とホスティングに一つのクレジット残高を使えること、あるいは別のスタックで動かしたいことが目的であれば、Mythexの方が適しています。より詳しい比較は、Lovableの代替サービスのガイドとMythex対Lovableのページを参照してください。

移行チェックリスト

• アプリのすべての要素を一覧にした：コード、データベース、ユーザー、ファイル、関数、シークレット、ドメイン
• コードを自分が所有するGitHubリポジトリに同期した
• バックエンドの判断をした（Supabaseを使い続けるか、Lovable Cloudからエクスポートするか）
• 空のMythexプロジェクトにコードをインポートし、プレビューが起動している
• シークレットを再登録した。VITE_の変数に非公開キーは入れていない
• 新しいアドレスに合わせて認証のリダイレクトURLを更新した
• プレビューでサインアップ、ログイン、主要なデータの操作の流れ、アップロードをテストした
• 公開し、mythex.aiのアドレスで再テストした
• DNSを移し、新しいアプリの動作を確認してから古いアプリを停止した

Mythex側の作業については、ドキュメントのGitHub、エクスポート、インポートを参照してください。

よくある質問