実際に移行されるもの
コードは移行され、同期され続けます。 Lovable の GitHub 連携はエクスポートと双方向同期を行います。Lovable で行われた変更は GitHub に同期され、アクティブな GitHub ブランチにプッシュされた変更は Lovable に同期されます。これには 2 つのレイヤーがあります。GitHub アプリを介して Lovable を認証し、プロジェクト間で再利用可能なワークスペース接続と、1 つの Lovable プロジェクトを 1 つのリポジトリに接続するプロジェクトリポジトリリンクです。
これに頼る前に、いくつかの実際の制限を知っておく価値があります。Lovable は一度に 1 つのブランチのみを編集および同期します。通常はリポジトリのデフォルト（通常は main）です。他のブランチで作業するには、プロジェクトの GitHub 設定で別のブランチを選択します（そこで作成することもできます）。既存の GitHub リポジトリを Lovable にインポートすることはできません。また、一度切断すると同じリポジトリに再接続することはできません。新しいリポジトリが作成されます。GitHub アプリは同じアカウントまたは組織に 2 回インストールすることはできず、100 MB を超えるファイルは同期に失敗し、GitHub のユーザー名や組織名を変更すると接続が切断されます。
環境変数とシークレットは、通常最初のつまずきポイントになります。 Lovable の GitHub ドキュメントではこれらについて触れておらず、実際にはリポジトリにプロバイダーのキーは保存されません。この移行を行った開発者は一貫して、クローンした後に Supabase、Stripe、および同様の認証情報を手動で設定したと報告しています。「Lovable では動いたのに」というエラーの原因が環境変数の不足であることに対処するため、1 時間ほど時間を確保しておきましょう。
Knowledge は移行されません。これこそが Cursor が「馬鹿」になったように感じる最大の理由です。 Lovable の Knowledge 機能を使用すると、エージェントに永続的な指示とコンテキストを 2 つのレベルで提供できます。
- Workspace Knowledge — ワークスペース内のすべてのプロジェクトで共有されるルール：コーディングスタイルの規約、命名規則、推奨されるライブラリやフレームワーク、共有アーキテクチャパターン、テスト要件、コード品質やリンターのルール。ワークスペースの所有者と管理者のみが管理できます。
- Project Knowledge — 単一のプロジェクトに対する永続的な指示とコンテキスト：アプリケーションの機能、ユーザーペルソナ、データベーススキーマ、アーキテクチャの決定、ドメイン用語、デザインガイドライン、重要なリファレンスへのリンク。プロジェクトの編集権限を持つ全員が編集可能です。
どちらも「Settings → Knowledge」および「Project settings → Knowledge」にあり、どちらも最大 10,000 文字に制限されています。そして（ここが過小評価されがちな部分ですが）、Knowledge はすべてのメッセージにおいて Lovable の背景コンテキストとして常に含まれます。ただし、Lovable 自身のドキュメントでは、極端に長い会話では一貫性が失われる可能性があると指摘されています。
このリストをもう一度見て、これがルールファイルであることに気づいてください。Lovable は .cursor/rules が行うことを行っていたのです。ただ、何ヶ月も開いていないかもしれないテキストボックスの中でそれを行っていただけです。
チャット履歴は移行されません。これこそが本当の損失です。 あなたが入力したすべての「いや、そうじゃない」、直面して発見したすべての制約、却下したすべてのアプローチ。これらは会話の中にあり、会話は Lovable に残ります。規律を守っていれば、その一部は Knowledge に含まれているかもしれません。しかし、ほとんどは含まれていません。だからこそ、Lovable がセッション間でプロジェクトのコンテキストを見失うという不満が、あちら側でもよく聞かれるのです。
手動での移行
ステップ 1: コードを Cursor に取り込み、同期の動作を確認する
Lovable プロジェクトで「Settings」を開き、まだ接続していない場合は GitHub を接続します。これにより Lovable の GitHub アプリが認証され、リポジトリが作成されます。その後、ローカルにクローンし、Cursor でフォルダを開きます。
編集を開始する前に、同期に対する姿勢を決めてください。双方向同期は諸刃の剣だからです。
- 完全な決別 (Clean break) — Lovable の使用を終了します。クローンして通常通り作業します。何も Lovable には戻りません。
- 両方を維持 (Keep both) — 迅速な UI イテレーションには Lovable を使い、ロジックには Cursor を使います。これは合理的で一般的であり、この 2 つは実際には競合しません。ただし、Lovable は 1 つのブランチしか監視していないことを忘れないでください。そのブランチにプッシュしたコミットは Lovable に戻りますが、他のブランチでの作業は、ブランチピッカーを切り替えるまで Lovable からは見えません。
次に環境変数を処理します。存在する .env.example をコピーし、プロバイダーのダッシュボードから実際の値を入力し、コードを変更する前にアプリがローカルで動作することを確認します。これを最初に行うことで、次に発生するエラーがキーの不足ではなく、自分自身のコードによるものであることが保証されます。
注意点として、「整理するため」に GitHub 連携を切断しないでください。その後、同じリポジトリに再接続することはできません（Lovable は新しいリポジトリを作成します）。整理のつもりが、自分のプロジェクトのフォークになってしまいます。
ステップ 2: Lovable の Knowledge を Cursor のルールに変換する
ここが、Cursor がダウングレードのように感じるかどうかを左右する部分です。
Lovable で両方の Knowledge レベルを開き、コピーします。次に、それらを Lovable よりもきめ細かい Cursor のモデルにマッピングします。
Cursor のプロジェクトルールは、バージョン管理された .mdc ファイルとして .cursor/rules に保存され、フロントマターフィールド description、globs、alwaysApply を持ち、4 つの有効化モードがあります。
- Always Apply（常に適用） — すべてのチャットセッション
- Apply Intelligently（インテリジェントに適用） — エージェントが説明に基づいて関連性があると判断したとき
- Apply to Specific Files（特定のファイルに適用） — ファイルがパターンに一致したとき
- Apply Manually（手動で適用） — チャットで @ メンションされたとき
Lovable の Knowledge は常にオンだったため、安易にすべてを Always Apply に変換してしまいがちですが、それは避けてください。Lovable の Knowledge はレベルごとに 10,000 文字あり、Cursor のドキュメントではルールを 500 行未満に抑え、構成可能なピースに分割することを推奨しています。新しく得られた粒度を活用しましょう。
- Workspace Knowledge（コーディング標準、命名、推奨ライブラリ、リンター） → Cursor の User Rules（「Customize → Rules」にある、すべてのプロジェクトに適用されるグローバル設定）。これが構造的に最も近く、Lovable のときと同様に次のプロジェクトにもこれらが継承されます。
- リポジトリに対して真にグローバルな Project Knowledge（アプリの機能、ドメイン用語） →
.cursor/rules内の Always Apply ルール、またはプロジェクトのルートにあるAGENTS.md（Cursor は.cursor/rulesの代替としてサポートしており、サブディレクトリからも読み込みます）。 - 特定の領域に特化した Project Knowledge（データベーススキーマ、デザインガイドライン） → スコープ付きルール。データレイヤーを指す
globsを持つスキーマルールは、その領域にいるときにのみロードされます。これは Lovable ができたことよりも明らかに優れており、今回の移行における最大のアップグレードです。 - 重要なリファレンスへのリンク → @ メンションするルールとして保持するか、
AGENTS.mdから参照されるリポジトリ内のドキュメントとして保持します。すべてのリクエストに含める必要はありません。
次に、Knowledge に含まれていなかったことを書き出します。Lovable のチャット履歴（少なくとも過去 2 週間分）を確認し、決定事項を抽出します。コードではなく、理由です。なぜこのコンポーネント構造にしたのか、どのライブラリを試して断念したのか、クライアントが何を拒否したのか。それぞれを日付付きのドキュメントとしてリポジトリに保存します。これは退屈な作業ですが、移行全体の中で最も価値のある 1 時間となります。なぜなら、このプロセスにおいて、成果物から再構築できない唯一のコンテンツだからです。
ステップ 2 の最後に、自分が構築したものについて率直に評価してみましょう。それは、同じものをより良く整理したバージョンに過ぎません。Cursor 自身のドキュメントには、なぜこの仕組みが存在するのかが説明されています。「大規模言語モデルは、補完の間でメモリを保持しません。ルールは、プロンプトレベルで永続的かつ再利用可能なコンテキストを提供します。」 ルールとは、毎回コンテキストを再提供する方法です。書き留めることを覚えていた内容を保持するものであり、1 つのツールのフォーマットに過ぎません。これは、Knowledge で直面していた状況とまったく同じです。
より良い方法：どちらのツールでも使える単一のメモリレイヤー
ステップ 2 で実際に行ったことを見てみましょう。ある製品の 10,000 文字のテキストボックスからコンテキストをコピーして別の製品のファイル形式に貼り付け、どちらにも存在しなかった部分を手動で再構築しただけです。
ここで、この移行を行う多くの人が両方のツールを使い続けることを考慮してください。そして、ここに誰も想定していない「乖離」が発生します。GitHub 連携のおかげで、コードは自動的に同期されます。しかし、ナレッジは同期されません。Cursor で行った決定は Lovable の Knowledge には届かないため、Lovable は 1 ヶ月前の古いプロジェクトのイメージに基づいて生成を続け、そのズレは、他で確立したルールを静かに無視して再生成されたコンポーネントとして現れます。双方向のコード同期と一方向のナレッジ同期の組み合わせは、同期がまったくない状態よりも悪い失敗パターンです。なぜなら、一見問題なさそうに見えるからです。
両方のツールが読み取れる単一のレイヤーにナレッジを保持することが、この問題を解決します。MemoryLake は、ツールの下に位置するメモリレイヤーです。決定事項、スキーマ、ドメイン用語、およびその背後にある理由を 1 つのストアに保存し、MCP 経由で Cursor から、また API を介して他のあらゆるツールから読み取ることができます。このストアはテキストボックスの制限を受けず、次のツールへの切り替え時に再び変換が必要になるようなフォーマットでもありません。
公平を期すために言うと、Lovable の Knowledge はその機能において非常によく設計されています。2 つのスコープレベル、常に適用、適切な権限を持つユーザーによる編集が可能で、エージェントの動作を確実に制御します。同様に .cursor/rules もプレーンテキストであり、バージョン管理され、プルリクエストでレビューされ、チームに自動的に継承されます。恒久的なルールには両方を使い続けてください。メモリレイヤーは、蓄積された記録のためのものです。10,000 文字のフィールドには長すぎ、公開するには具体的すぎ、誰かが書き留めることに依存するには簡単に失われすぎてしまう情報のためです。
ステップ 1: API キーを作成する
キーを生成し、約 30 秒で最初のリクエストを実行します。環境変数またはシークレットマネージャーに保存してください。このプロジェクト用にすでに環境変数を設定しているはずですので、GitHub に同期されるファイルではなく、そこに追記します。
ステップ 2: 最初のメモリをアップロードする
Knowledge に収まらなかったドキュメント、画像、ファイルを投入します。履歴付きのスキーマ、アーキテクチャの決定とその理由、デザインガイドライン、クライアントの制約などです。可能な限り、要約ではなくソース自体をアップロードしてください。
ステップ 3: AI とエージェントを接続する
Claude、Codex、OpenClaw、およびその他の AI エージェントに、MCP または API 経由でメモリへのアクセスを許可します。Cursor は MCP サーバーをサポートしているため、これは設定項目を追加するだけです。MCP クライアントを持たないツールの場合は、API 経由で必要な情報を取得し、プロンプトやワークフローに注入します。
実務における変化
最初の違いは、Cursor での最初の実務タスクで現れます。ファイルツリーしか知らないエージェントの代わりに、認証フローがなぜそのような形になっているのかを答えられるエディタが得られます。その決定が Lovable のスレッドではなく、ストアに保存されているからです。
2 つ目は、スコープ付きルールが Lovable にはできなかった働きをし始めることです。データレイヤーにいるときはスキーマの規約がロードされ、CSS を編集しているときは邪魔になりません。これは移行による真の機能向上であり、すべてを Always Apply に変換する誘惑に抗った場合にのみ実現します。
3 つ目は、前述の乖離の問題です。両方のツールが 1 つのストアを読み取る場合、Cursor で行われた決定は次に使用するツールからも確認できます。これは、2 つのツールが協力し合うか、プロジェクトについて徐々に意見が食い違っていくかの違いになります。
そして、これは次のステップでも生き残ります。多くの人が 1 年以内に Lovable → Cursor → さらに別のツールへと移行しています。このパターンは十分に確立されており、プロトタイププラットフォームから本物のエディタへの移行は、今や独自のジャンルとなっています。ツール内にナレッジがある場合はこれをやり直す必要がありますが、ツールの下層にナレッジがあれば、その必要はありません。
移行のベストプラクティス
変更を加える前に、アプリがローカルで動作することを確認する
クローンし、インストールし、環境変数を設定し、実行します。「Lovable のコードが壊れている」という報告で最も多いのは認証情報の不足であり、リファクタリングと同時にそれを診断するのは苦痛です。まずは正常に動作することを確認してから、作業を開始してください。
すべての Knowledge を Always Apply に変換しない
Lovable の Knowledge は、それしか選択肢がなかったために常にオンになっていました。Cursor は glob や説明に基づくアクティブ化を提供しています。これらを使用してください。すべてを Always Apply に設定すると、永久にすべてのリクエストでロードされるようになり、ルールディレクトリの肥大化はこの移行における典型的な後悔の種になります。
ルールだけでなく、理由も移行する
Knowledge は Cursor に規約が 何であるか を伝えます。しかし、なぜ そうなのかを伝えることはほとんどありません。そして、その「なぜ」こそが、エージェントがすでに断念したライブラリを嬉々として再提案するのを防ぐものです。どのスレッドが重要かを覚えているうちに、チャット履歴から理由を抽出しておきましょう。
同期に対する姿勢を明確に決める
完全な決別を選択するか、両方を維持することを選択するか、どちらかにコミットしてください。両方を維持する場合は、Lovable が一度に 1 つのブランチしか監視せず、その Knowledge は Cursor での作業から何も学習しないことを忘れないでください。どのツールが信頼できる情報源（オーソリティ）なのか誰もわからない半移行状態のプロジェクトでは、手動で修正した箇所の上にコンポーネントが再生成されてしまう原因になります。
結論
Lovable から Cursor への移行は、実際にはコードの移行ではありません。GitHub の双方向同期がコードを処理します（ただし、1 つのブランチしか同期されないこと、既存のリポジトリを Lovable にインポートできないこと、切断後にリポジトリを再接続できないことなどの注意点があります）。移行の本質はあなたの Knowledge です。すべてのメッセージに適用されていた 2 つの 10,000 文字制限のレベルを、ワークスペースレベルの規約用の User Rules と、プロジェクト固有のスコープ付き .cursor/rules に変換する必要があります。さらに、チャットスレッドにしか存在しなかったすべての決定事項について、日付付きのドキュメントを作成する必要があります。
慎重に検討すべき選択は、そのナレッジをその後どこに置くかです。Cursor のルールに置く場合、それはこのエディタのこのリポジトリにのみ役立ち、次回ツールを切り替えるときに再び変換することになります。両方のツールが読み取るレイヤーに置く場合、両方で最新の状態が維持されます。これは、Lovable と Cursor の両方をまだ開いているという、人々が実際に直面する状況において最も重要になります。