実際に移行されるもの
Git同期が運ぶもの
Lovableのドキュメントは、コードの保存場所について次のように説明しています。「Lovableでビルドすると、プロジェクトのコードはLovableプラットフォーム内に保存・管理されます。」Git同期はプロジェクトを所有するリポジトリにリンクし、その後は「Lovableで行った変更がリポジトリにコミットされ、同期されたブランチにプッシュされたコミットがLovableプロジェクトに反映されます。」
これにより、コード側の連携は非常にシンプルになります。どのコーディングアシスタントでも対応可能です。「Lovableは、どのツールで作成されたかに関わらず、同期されたブランチにプッシュされたコミットを受信するため、Gitに対応している任意のIDEやコーディングアシスタントがサポートされます。」有料プランでは、Gitを接続せずにコードベースをダウンロードすることも可能です。
セットアップにあたって、いくつかの制限事項があります：
- 一度に1つのブランチのみ。 Lovableが編集および同期するのは、同期されたブランチのみです。他のブランチのコミットは、マージするまでLovableには表示されません。
- エクスポートのみ。 Lovableのドキュメントには「既存のリポジトリをLovableにインポートすることはできません」と記載されています。接続すると、常に新しいリポジトリが作成されます。
- データやシークレットは含まれない。 リポジトリに含まれるのはプロジェクトのコード（「構造を定義するデータベースマイグレーションファイルを含みますが、データベース内のデータは含まれません」）です。また、「Lovableに保存したシークレットはリポジトリには保存されません」。
Lovableに残るもの
主なものはKnowledge（ナレッジ）です。Lovableはこれを「Lovableエージェントに永続的な指示とコンテキストを提供する」方法と説明しており、2つのレベルがあります。ワークスペースKnowledgeは、コーディング標準や命名規則などの共有ルールを保持します。プロジェクトKnowledgeは、アプリの目的、データベーススキーマ、アーキテクチャの決定、ドメイン用語など、特定のアプリに固有の情報を保持します。それぞれ最大10,000文字までサポートされています。
Knowledgeは設定フィールドであり、リポジトリ内のファイルではありません。LovableのGit同期に関するガイダンスは、この点を間接的に指摘しています。「Lovableは、ユーザーが書いたコードも自身が生成したコードも同様に扱い、後のリクエストでどちらも変更する可能性があります。」そのため、リクエスト間で維持すべき制約はプロジェクトKnowledgeに記述し、依存する挙動のテストを維持することが推奨されています。これはLovable内では優れたアドバイスですが、最も重要な制約こそがクローンしたリポジトリには含まれないことを意味します。
2つ目はスキル（Skills）です。ワークスペーススキルは、繰り返し発生するタスクのための名前付きプレイブックであり、常に読み込まれるのではなく、オンデマンドで読み込まれます。これらはワークスペースの設定に保存され、リポジトリには保存されません。
3つ目はプロジェクトのチャットです。Git同期のドキュメントがカバーしているのはコードであり、それを生み出した会話ではありません。チャット内で行われた意思決定は、誰かが書き留めない限りリポジトリに反映されません。
代わりにClaude Codeが読み取るもの
Claude Codeは、すべてのセッションの開始時に指示ファイルを読み込みます。メインとなるのは CLAUDE.md です。また、AGENTS.md も読み取ることができますが、今回の移行において重要な条件が1つあります。「デフォルトでは、Claudeはワーキングディレクトリまたはその上位ディレクトリに CLAUDE.md が存在しない場合にのみ AGENTS.md を読み込みます。」このチェックに該当するファイルについては、Claude CodeのAGENTS.mdデフォルトに関するガイドで解説しています。Anthropicは「AGENTS.md を直接読み取るには、Claude Code v2.1.277以降が必要です」と指摘しています。
スキルはより直接的に引き継がれます。「Claude Codeのスキルは、複数のAIツールで動作するオープンスタンダードであるAgent Skillsに準拠しています。」プロジェクトのスキルは .claude/skills/<skill-name>/SKILL.md に配置され、Anthropicはプロジェクトスキルについて「チーム全員が利用できるようにコミットすること」を推奨しています。
また、Claude Codeは自動メモリ（ユーザーの修正や好みに基づいてClaude自身が書き留めるメモ）も保持します。これらのメモはClaude Codeのセッションから生成されるため、書き留めない限り、Lovableのチャットが学習した内容は一切含まれません。
両者が出会う場所：LovableのMCPサーバー
Lovableは外部クライアントが接続できるMCPサーバーを実行しており、Claude CodeはLovableがドキュメントでサポートを明記しているクライアントの1つです。「LovableのMCPサーバーはすべてのプランで利用可能です。」これはLovableのチャットコネクターとは逆の仕組みです。Lovableがツールにアクセスするのではなく、ツールがLovableにアクセスします。
移行において便利なのは、読み取り（read）ツールです。ドキュメントに記載されているリストには、Knowledgeのテキストを返す get_workspace_knowledge や get_project_knowledge、スキルの「全コンテンツを含む」内容を返す list_workspace_skills や get_workspace_skill、「プロジェクトの最近のメッセージを新しい順にリスト表示する」と説明されている list_messages、およびプロジェクトの履歴やファイルを取得する list_edits や read_file が含まれます。
つまり、手動でコピー＆ペーストしなくても、Claude CodeがKnowledgeやスキルを直接読み取ることができます。ただし、2つの注意点があります。Knowledgeの書き込み（write）ツールは、追記ではなく「置換」を行います。set_project_knowledge の説明には「既存のコンテンツを完全に置き換えます」とあるため、引き続きLovableを使用している場合は、エージェントに不用意にKnowledgeを書き戻させないようにしてください。また、list_messages は最近のメッセージのみを返すため、チャット全体のアーカイブではなく、最新の決定事項を確認するための手段として捉えてください。
開始前に確認すべきこと
Enterpriseワークスペース。 サードパーティのMCPアクセスは「Enterpriseワークスペースではデフォルトで無効」になっています。まずオーナーまたは管理者が有効にする必要があります。
スコープとコスト。 Lovableは、接続が「1つのプロジェクトに限定されない」こと、および「ツール呼び出しは実際のクレジットを消費し、実際のプロジェクトを編集する」ことを警告しています。FAQによると、クレジットは create_project と send_message に適用され、その他のツールは無料であるため、Knowledgeやスキルの読み取りでクレジットが消費されることはありません。ただし、Lovableエージェントにメッセージを送信するとクレジットが消費されます。
権限の確認。 「ワークスペースKnowledgeを管理できるのは、ワークスペースのオーナーと管理者のみ」です。カスタムスキルは、エディター以上の権限を持つユーザーがダウンロードできます。Lovableの組み込みスキルについて、FAQには「ワークスペースに追加したスキルのみがダウンロード可能」と記載されています。管理権限がない場合は、管理者に現在のワークスペースKnowledgeの提供を依頼してください。
組織のルール。 Knowledgeには社内参照情報が含まれていることが多く、プロジェクトのチャットにはクライアントの詳細が含まれている場合があります。新しいツールやファイルに移行する前に、何が許可されているかを確認してください。
手動での移行手順
ステップ 1：コードを同期し、LovableからKnowledgeとスキルを抽出する
プロジェクト設定の「Git」でプロジェクトをリポジトリに接続し、進行中のLovableの編集が完了するのを待ちます。同期ステータスカードにより、Lovableとプロバイダーが同じコミットにあるかどうかがわかります。リポジトリをクローンし、フィーチャーブランチで作業を進めることで、Lovable'sの同期ブランチをクリーンに保ちます。
次に、コンテキストを取り出します。Lovableのドキュメントに記載されているセットアップ手順に従って、Claude CodeをLovableのMCPサーバーに接続します。その後、Claude CodeにプロジェクトKnowledgeとワークスペースKnowledgeを読み取らせ、それぞれをスクラッチファイルに保存するよう指示します。使用する前に、必ず自身で両方の内容を確認してください。数ヶ月前に書かれたKnowledgeには、すでに変更された古いルールが含まれていることがよくあります。MCPを接続したくない場合は、プロジェクト設定の「Knowledge」から手動でテキストをコピーしてください。
スキルについては、ワークスペース設定の「Skills」からカスタムスキルをZIPファイルとしてダウンロードできます。Lovableは、そのスキルが「AnthropicのClaudeや、Agent Skillsコンベンションに従う他のツールと同じ SKILL.md の形状を使用している」と説明しているため、変換の必要はありません。
最後に、最近のチャットを確認します。Claude CodeにMCP経由でプロジェクトの最近のメッセージをリストアップさせるか、自身でチャットをスクロールして、Knowledgeに反映されなかった決定事項（ライブラリを選定した理由、試して断念したこと、変更してはならない挙動など）を書き留めます。それぞれに日付を記載しておきましょう。
ステップ 2：両方のツールが読み取る共通の指示ファイルを記述し、スキルをリポジトリに移動する
デフォルトでは、2つのツールは異なるファイルを読み込みます。LovableのKnowledgeに関するFAQには、「ルートレベルの AGENTS.md ファイルは、セッションの長さに関わらず、常にLovableエージェントによって読み込まれる」とあり、CLAUDE.md などの指示ファイルもエージェントをガイドできるとされています。一方、Claude Codeは CLAUDE.md が存在しない場合にのみ AGENTS.md を読み込みます。
そのため、Claude Codeと並行してLovableを使い続ける場合は、共有ルールをルートレベルの AGENTS.md に記述します。これにより、両方のツールがそれを読み取ります。Claude固有の指示が必要な場合、Anthropicが推奨するパターンは、CLAUDE.md 内に @AGENTS.md のインポートを記述することで、AGENTS.md を「すべてのツールが共有する唯一のファイル」として維持することです。Lovableも CLAUDE.md を読み取る可能性があるため、このファイルは短く保ちましょう。
次に、Lovableのコンテキストの各部分を移行します：
- プロジェクトKnowledgeを
AGENTS.mdに変換する。 短く直接的なルールとして書き直します。Anthropicのガイダンスでは「CLAUDE.mdファイルあたり200行未満を目指す」ことが推奨されており、ここでも同様の規律が役立ちます。 - ワークスペースKnowledgeを共有ルールに変換する。 すべてのプロジェクトに適用されるルールを各リポジトリの
AGENTS.mdに記述するか、個人用のルールをユーザーレベルのClaude Code指示ファイルに保持します。 - チャットでの決定事項を決定事項ファイルにする。 日付付きのエントリを新しい順に並べた1つのファイルを作成します。
AGENTS.mdからこのファイルにリンクさせます。 - スキルを
.claude/skills/に移動する。 ダウンロードした各スキルを解凍して専用のフォルダに配置し、コミットします。
Lovableは、クライアントにMCPサーバーの操作方法を教えるスキルも公開しており、ドキュメントではClaude Code用の配置場所として .claude/skills/lovable-mcp/SKILL.md を推奨しています。Claude CodeからLovableでのビルドを継続する予定がある場合のみ、これを追加してください。
Claude Codeのセッションを開始し、何が読み込まれたかを確認します。AGENTS.md のみが存在する場合、インタラクティブセッションには CLAUDE.md が見つからず AGENTS.md が読み込まれたことを示す行が表示されます。CLAUDE.md がある場合は、/context を実行して「Memory files」の下に表示されているか確認します。その後、Claudeに読み込んだルールを要約するよう指示します。不足している情報がある場合は、チャットではなくファイルを修正してください。
以前に他のブラウザベースの開発ツールから移行したことがある場合、ReplitからClaude Codeへの移行ガイドも同様のパターンに従っています。
より良い方法：両方のツールが利用できる1つの場所にプロジェクトの決定事項を保持する
手動での移行により、LovableのKnowledgeやチャットはClaude Codeが読み取るファイルに変換されます。決定事項ファイルは最も価値のある部分です。しかし、LovableとClaude Codeの両方が同じコードに対して作業を続けるため、このファイルは最も乖離（ドリフト）しやすい部分でもあります。
MemoryLake は、これらの決定事項を1つのリストとして維持し、Claude Codeや他の使用しているアシスタントから利用できるようにするためのメモリレイヤーです。
エントリは、あなた自身の言葉で記述します。LovableのKnowledge、ワークスペーススキル、Claude Codeのメモリ、またはその他のベンダーのストレージから情報が読み取られたり、書き込まれたり、削除されたりすることはありません。プロジェクトの詳細をどこかにコピーする前に、組織のポリシーを確認してください。
ステップ 1：APIキーを作成する
サインインし、ダッシュボードからキーを生成します。このキーは、LovableやAnthropicのアカウントとは別の、あなたのMemoryLakeワークスペースに属します。
ステップ 2：最初のメモリをアップロードする
手動移行のステップ1で書き留めた決定事項から始めます。1つのエントリにつき1つの決定事項を、日付と理由とともに記述します。
ステップ 3：AIとエージェントを接続する
Claude Codeや、その他に使用しているアシスタントを接続します。これにより、特定のツールの設定内に留まることなく、接続したすべてのツールで同じ決定事項を利用できるようになります。
実務における変化
最初の違いは、Lovableのコンテキストが読み取りやレビューが可能なものになる点です。以前は設定フィールドに埋もれていたKnowledgeが、リポジトリ内のファイルとなり、コードとともにバージョン管理されるようになります。
2つ目は、意図しないコードの先祖返りや上書き（reversals）が減ることです。Lovableは、後のリクエストでユーザーが書いたコードを変更してしまうことがあります。制約が両方のツールで読み取られるルートの AGENTS.md に記述されていれば、LovableとClaude Codeの両方が常にその制約を意識して動作します。
3つ目は、スキルがそのまま機能し続けることです。両方のツールが同じ SKILL.md の形状を使用しているため、Lovableで洗練させたワークスペースのワークフローを、書き直すことなくClaude Codeで実行できます。ただし、スキルが保持するのは手順であり、決定事項ではありません。そのため、スキルはメモリの代わりにはならず、決定事項ファイルが依然として重要になります。
4つ目は、同じ説明を繰り返す必要が減ることです。適切な指示ファイルから開始されるセッションでは、プロジェクトについて再説明する必要がありません。この状況については、Claude Codeがプロジェクトのコンテキストを忘れてしまう問題に関するガイドで詳しく解説しています。
LovableからClaude Codeへ移行するためのベストプラクティス
Lovableは専用のブランチに保つ。 フィーチャーブランチで作業し、同期されたブランチにマージします。
同期された履歴を書き換えない。 Lovableのドキュメントでは、同期されたブランチにすでに存在するコミットに対して、フォースプッシュ、リベース、またはスクワッシュを行わないよう推奨されています。
コピーする前にKnowledgeを確認する。 古いルールは、すでに誤ったルールになっていることがよくあります。
1つのルート AGENTS.md を使用する。 両方のツールがこれを読み取ります。
MCPの書き込みは慎重に行う。 Knowledgeの書き込みは、フィールド全体を置き換えます。
スキルをリポジトリにコミットする。 Claude Codeはそこからプロジェクトのスキルを見つけます。
チャットでの決定事項を書き留める。 Lovableがプロジェクトのコンテキストを忘れてしまう問題に関するガイドで説明されているように、チャットの内容はコードと一緒に移動しません。
結論
LovableからClaude Codeへの移行は、コードに関しては容易ですが、コンテキストに関しては慎重に行う必要があります。Git同期により、Claude Codeが作業できるリポジトリが手に入ります。しかし、LovableのKnowledge、スキル、チャットは、明示的に取り出さない限りLovable内に残ります。
LovableのMCPサーバーを利用すれば、この作業が容易になります。書き込みツールを慎重に扱う限り、Claude CodeはプロジェクトやワークスペースのKnowledge、カスタムスキル、最近のメッセージを直接読み取ることができます。スキルは両方のツールで同じ SKILL.md の形状を使用しているため、そのまま移行できます。
共有ルールをルートレベルの AGENTS.md に記述し、Claude固有の指示が必要な場合はそれをインポートする短い CLAUDE.md を追加し、日付付きの決定事項ファイルを維持しましょう。これを行わないと、毎回1つずつ修正を加えながらコンテキストを再構築することになってしまいます。