短い答え
Lovableは、モデルが可視コードから各生成を構成するため、あなたのコンポーネント構造を忘れます。おおよそ15〜20のコンポーネントを超えると、関連するコンポーネントツリーのスライスがアクティブウィンドウに収まらなくなります。プロジェクト知識はルールを保持しますが、特定のコンポーネント契約を取得することはありません。修正方法は、Lovableが各生成で読み取る持続的な記憶としてコンポーネント構造を保存することです。
なぜLovableはコンポーネント構造を忘れるのか
Lovableは、プロンプトからReact + Tailwindを生成するバイブコーディングビルダーです。あなたのコンポーネント構造をモデルの作業コンテキストから押し出す3つのデザイン選択肢があります：
1. 生成は可視コードを読み取るが、全体のツリーは読み取らない。 モデルはピン留めされているものとアクティブウィンドウに収まるものを確認できます。プロジェクトが成長するにつれて、あなたの基盤となるコンポーネント（AppLayout、PageHeader、DataTable）は、明示的にピン留めされない限りウィンドウから外れます。
2. 約15〜20のコンポーネントコンテキスト喪失の閾値。 Lovableのコミュニティは、15〜20のコンポーネントのマーク付近でドリフトが始まることを文書化しています。新しいコンポーネントはプリミティブを再利用するのをやめ、レイアウトを再実装し始め、ツリーを徐々に断片化します。
3. プロジェクト知識はグローバルテキストであり、コンポーネント契約ではない。 プロジェクト知識フィールドに「AppLayoutを使用、FormShellを使用」と書くことができますが、それは役立ちます。それでもグローバルなアドバイスであり、取得ではありません — モデルは生成しているファイルの特定の契約や例を引き出しません。公式のLovableドキュメントは、docs.lovable.devでプロジェクト知識モデルとこの動作の背後にあるコンテキスト制限をカバーしています。
結果：構造は初期には一貫しており、プロジェクトが成長するにつれて徐々に断片化します。
Lovableがコンポーネント構造を忘れると失うもの
構造のドリフトは、プロンプトのドリフトとは異なるコストがかかります：
- 重複するプリミティブ。 モデルが毎回あなたのものを再利用するのではなく、新しいものを再構築するため、3種類の「ページヘッダー」が存在します。コードベースはサイズが倍増し、明確さが半減します。
- スキップされたレイアウト。
AppLayoutをバイパスするページは、ナビゲーション、認証ゲーティング、グローバルスタイルを失います。QAでキャッチされ、生成時には見逃されます。 - リファクタリング税。 すべてのリリースは、ページを標準レイアウトに再配線し、重複するコンポーネントをマージするためのスイープで終わります。
修正方法は「毎回ファイルをもっとピン留めする」ではなく、コンポーネント構造を第一級の取得可能な記憶にすることです。
Lovableの組み込みワークアラウンド
Lovableは、構造を視界に保つための3つの方法を提供します。それぞれが役立ちますが、それぞれがスペースが不足します。
ピン留めされたファイルは、特定のコンポーネントをモデルに見えるように保ちます。AppLayout.tsxをピン留めすると、モデルはそれをより信頼性高く再利用します。ただし、ウィンドウが新しい作業を圧迫する前に、ほんの少ししかピン留めできません。
プロジェクト知識は、構造ルールを平易な英語で述べることを可能にします：「すべてのページはAppLayoutを使用します。すべてのフォームはFormShellを使用します。」便利ですが、依然としてグローバルテキストであり、契約の取得ではありません。
手動リファクタリングパスは人間のフォールバックです。これらは機能しますが、最初にLovableを選んだ理由であるスピードの利点を消し去ります。
Lovableの組み込み記憶が不足している点
より深い問題は、コンポーネントツリーが長期的な契約であることです。モデルは「AppLayoutを使用する」だけでなく、「ここにそのプロップシグネチャがあり、使用例があり、PageHeaderを内部で使用するタイミングがある」と知る必要があります。それは構造化された記憶に属し、1つのグローバルテキストフィールドや固定されたピン留めファイルのセットには属しません。
コンポーネント構造はビルダーの上に存在する必要があります。
MemoryLakeがLovableのコンポーネント構造を忘れる問題を解決する方法
MemoryLakeは、LovableがREST経由で読み取るクロスモデルの記憶レイヤーです。ファイルをピン留めして祈るのではなく、コンポーネント契約を記憶として保存し、取得が各生成ごとに関連する部分を表面化させます。
- クエリ可能な記憶としてのコンポーネント契約。 各基盤となるコンポーネントには記憶が与えられます：その目的、プロップシグネチャ、使用タイミング、標準的な使用例。取得は生成されるコンポーネントに関連する契約のみを返します。
- 例を伴う構造ルール。 「すべてのページは
AppLayoutを使用します」は、再現するための正確なスニペットとペアになっているため、モデルには再発明する言い訳がありません。 - 生のプロンプトの10,000倍の取得範囲。 MemoryLakeは数十億のトークンのプロジェクト記憶から読み取り、生成されるファイルにとって重要なものだけを返すため、あなたの構造は15〜20のコンポーネントを超えて成長します。
MemoryLakeは、LoCoMoの長文コンテキストベンチマークで94.03％を記録し、2026年時点での最高の公開結果であり、ミリ秒単位の取得とAES-256のエンドツーエンド暗号化を実現しています。
MemoryLakeをLovableに接続する3つのステップ
- プロジェクトを作成し、コンテキストを読み込む。 MemoryLakeにサインインし、プロジェクト管理を開き、「プロジェクトを作成」をクリックし、「Lovable — Acmeコンポーネントツリー」と名付けます。基盤となるコンポーネント（
AppLayout.tsx、PageHeader.tsx、DataTable.tsx、FormShell.tsx）、そのドキュメント、およびアーキテクチャノートをドキュメントドライブを通じてアップロードします。構造ルールを追加します — 「すべてのページはAppLayoutを使用する」、「すべてのフォームはFormShellを使用する」 — およびプロップシグネチャを記憶として記憶タブに追加します。 - MCPサーバーエンドポイントを生成する。 プロジェクト内のMCPサーバータブを開き、「MCPサーバーを追加」をクリックし、「Lovableコンポーネント記憶」と名付け、生成をクリックします。MemoryLakeはAPIキーID、シークレット、およびエンドポイントURLを返します。Bearerトークンをすぐにコピーしてください — 一度だけ表示されます。
- REST経由でLovableを接続する。 LovableはまだMCPをネイティブに話しませんので、REST APIを使用します。コンポーネント契約の要約をLovableのプロジェクト知識エリアに貼り付け、契約が変更されたときにMemoryLakeから更新するか、Bearerトークンを使用してMemoryLakeのRESTエンドポイントを呼び出し、各リリースでプロジェクト知識を更新するセットアップスクリプトを実行します。