なぜ制限が存在するのか、そしてなぜエントリを増やすことがゴールではないのか
制限はバイト数ではなく、エントリ数に対して課される
Manusはエントリ数をカウントします。100個の長いエントリも、100個の1行のエントリも、同じ壁に突き当たります。つまり、これは容量の制限ではなく、キュレーション（整理）の制限なのです。また、最も手軽な解決策は通常「統合」であることを意味します。同じルールを説明している3つのエントリがあるなら、それらを1つにまとめるべきです。
公表されている理由は「回答の品質」
これが、あなたがこれまで経験してきた多くの制限と異なる点です。Manus自身の説明によると、「エントリ数が多すぎると、システムの回答品質に影響を与える可能性があります」とのことです。ストレージコストに関する言及はなく、ProとFreeの区分以外のプランによる違いもありません。
これは、それ自体として非常に説得力のある主張です。常にオンになっているコンテキストとしてロードされるものはすべて、同じくロードされている他のすべての情報と注意力を競い合います。雑多な100の事実が詰まったストアは、関連性の高い30の事実が詰まったストアよりも、検索対象として劣ります。これは他のあらゆる場所でも見られるパターンです。Claude Codeは「MEMORY.mdの最初の200行、または最初の25KBのいずれか早い方」のみをロードし、指示ファイルあたり「200行未満」に抑えることを推奨しています。その理由は「ファイルが長くなるとコンテキストの消費量が増え、指示への追従性が低下するため」です。Kiro's Crewメモリは、各レイヤーの文字数を個別に制限しています（環境設定は4,250文字、プロジェクトは6,400文字）。Perplexityはプロジェクトの指示を8,000文字に制限しています。
Manusが珍しいのは、この制限を「エントリ数」という目に見える形で表現している点だけです。挙動自体はどこも同じです。
グローバルストアが、本来の設計とは異なる役割を担っている
ユーザーナレッジベースは、広範囲に適用される単一のストアです。もしManusを4つの無関係な仕事に使用している場合、そのうちの1つについて教え込んだすべての内容が、他の3つの仕事のコンテキストにも居座ることになります。
これこそが、人々が制限に達してしまう本当の理由です。本当にグローバル（全体共通）な事実を100個持っているからではなく、プロジェクトという概念のないストアに、20個のグローバルな事実と80個のプロジェクト固有の事実を詰め込んでいるからです。
奇妙なことに、Manusにはその概念が存在する
Manusの「プロジェクト（Projects）」は、「指示やファイルを共有できる永続的なワークスペースであり、すべての新しいタスクが適切なコンテキストで開始される」と説明されています。プロジェクトには、マスター指示（master instruction）と、ファイルやドキュメントを保存する独自のナレッジベースの2つがあり、これらは両方とも「そのプロジェクト内で作成されたすべての新しいタスクに自動的に適用」されます。
2つの特性が、これを真の解決策にしています。プロジェクトは「すべてのサブスクリプション層のすべてのユーザーが利用可能」であるため、アップグレードを促すための機能ではありません。そして、Manusはプロジェクトのナレッジベースに対するエントリ制限をドキュメント化していません。カウントされるエントリではなく、ファイルやドキュメントを保持するからです。
Manus自身のドキュメントにある次の表現は、心に留めておく価値があります。「作業自体は繰り返せるかもしれないが、セットアップはそうではないことが多い。」これこそが、グローバルナレッジベースが苦手とし、プロジェクトが得意とすることです。
よく試されるアプローチ
最も古いエントリを削除する。 ドキュメントで推奨されているアドバイス（「最も重要かつ最近のニーズに基づいてナレッジベースのエントリをフィルタリングし、不要なエントリを削除する」）であり、実際に効果はあります。しかし、作成時期は価値の指標としては不十分です。18ヶ月前に設定し、その後一度も変更していないルールこそ、最も失いたくないものであることがよくあります。
複数の事実を1つのエントリに詰め込む。 これによりカウントは減らせますが、制限が存在する本来の目的に逆行します。9つの無関係なルールが含まれる1つのエントリは、9つの個別のエントリよりも適用が難しくなり、そのうちの1つだけを削除することも不可能になります。
余裕を持たせるためにProにアップグレードする。 上限が50から100に倍増し、他の理由から見ても合理的な選択肢です。しかし、品質に関する力学は変わりません。Manusの「整理を推奨する」というアドバイスは、Proユーザーにも同様に適用されます。
マスタードキュメントを手元に置き、タスクに貼り付ける。 よくある回避策であり、確かにManusにコンテンツを認識させることはできます。しかし、タスクごとに手動で作業するコストが発生し、これこそが「プロジェクト」機能が解消するために存在するセットアップの負担そのものです。
制限が引き上げられるのを待つ。 Manusは「将来的には、ユーザーのニーズやフィードバックに基づいてナレッジベース機能を最適化し続ける」と述べているため、変更される可能性は十分にあります。しかし、今週すぐに解決する計画ではありませんし、上限が上がったとしても品質に関する議論は残ります。
検索の問題として扱う。 適切なドキュメントが見つかるようにドキュメントを増やすというのは、ドキュメント検索（RAG）に慣れた人の本能的なアプローチですが、常に適用される小規模なストアには通用しません。この違いについては、なぜRAGはメモリではないのかで解説しています。
解決策：仕事の種類ごとに専用のコンテキストを与え、その下に永続的なレイヤーを1つ維持する
この移行作業は一種の仕分け（トリアージ）であり、約20分で完了します。
すべてのエントリを3つのバケツのいずれかに分類します。 完全にグローバル（執筆のルールやあなたの役割など、あなたとすべての仕事に共通するもの）、プロジェクト固有（特定の繰り返されるワークフローにのみ適用されるもの）、古い情報（かつては正しかったが、現在は不要なもの）。
3つ目のバケツは削除します。2つ目のバケツはプロジェクトのナレッジベースに移動します。グローバルストアに残るものはわずかになるはずであり、その「少なさ」こそが重要なポイントです。
次に、プロジェクトを適切に設定します。マスター指示に関するManusのガイダンスは、最も効果の高い部分です。「詳細なマスター指示を記述してください。指示が具体的であればあるほど、新しいタスクごとに提供する必要のあるコンテキストは少なくなります。」また、既存のタスクを後からプロジェクトに移動することもできます。ドキュメントでは、プロジェクトはフォルダのように機能すると説明されています。
依存する前に知っておくべき、直感に反する2つの反映ルールがあります。「指示の更新：現在のタスクで次にメッセージを送信したときに適用されます。」しかし、「ファイルの更新：更新後に作成された新しいタスクでのみ有効になります。」さらに広く言えば、「以前に作成されたすべてのタスクは影響を受けず、作成された時点の構成を引き続き使用します。」タスクは作成された時点の構成に固定されるため、ファイルを修正しても実行中のタスクは修正されません。新しいタスクを開始してください。
プロジェクトを共有する場合のコラボレーションに関する注意点：「同僚をプロジェクトに招待すると、その同僚は共有されたマスター指示とナレッジベースにアクセスできるようになります。ただし、そのプロジェクト内で自分自身が作成したタスクしか見ることはできません。」知識は共有されますが、作業は共有されません。
これで切り分けは完了です。しかし、これでは解決できない問題があります。それは、どちらのストアもManusのものであり、Manusのルールによって制限され、Manusの内部でしか読み取れないという点です。そこで、その下にある永続的なレイヤーが役立ちます。それこそがMemoryLakeが保持するものです。プロジェクトの知識をツールがクエリできるレイヤーに保持するため、エントリ制限は「あなたが知ることを許されている情報量」ではなく、「Manusがロードし続ける情報量」を制御するものになります。セットアップは3つのステップです。
ステップ 1: APIキーを作成する
サインインしてAPIキーを作成します。接続するすべてのツールで共通の認証情報となります。
ステップ 2: 最初のメモリをアップロードする
1つの主張につき1つの短いエントリを作成します。先ほどの仕分け作業によって理想的な入力リストができているはずですので、それに従って進めます。
「古い情報」の山の中で、削除をためらったものすべて。 確信が持てなかったエントリこそ、制限のない場所に保管しておく価値があります。Manusからは削除し、ここに保管しましょう。
理由が紐づいた決定事項。 「財務の締め日が変動するため、月次ではなく4週間サイクルで報告します。」エントリにはルールを記載します。理由が添えられて初めて、そのルールが再び疑問視されるのを防ぐことができます。
マスター指示に収まらなかったプロジェクト固有の詳細。 マスター指示は短く、指示的であるべきです。その背景にある情報はそこには馴染みませんが、捨てる必要はありません。
プロジェクトをまたぐ事実。 2つのワークフローには当てはまるが、すべてには当てはまらないものは、どちらのストアにも適切な居場所がありません。
ステップ 3: AIとエージェントを接続する
MemoryLakeはMCPおよびAPI経由でアクセス可能であり、ManusはMCPコネクタとカスタムMCPサーバーをサポートしています。そのため、Manusは他のアシスタントが読み取るのと同じメモリをクエリできます。また、Claude、Codex、OpenClawなどのMCPネイティブなエージェントは、MCPサーバーを指定することで接続できます。これにより、「これについて何を決めたか」という問いに対する答えが、前回のクリーンアップで生き残った100個のエントリのどれであるかに依存しなくなります。
3つの率直な制限事項。MemoryLakeは、あなたのManusナレッジベースを読み書きしたり、カウントしたりすることはできません。 制限はManusの内部で適用され、それらのエントリを操作できるのはManus自身のツールのみです。MemoryLakeは、あなたやあなたのエージェントが入力したものだけを保持するため、ステップ2は手動で行う必要があります。また、制限自体を引き上げるわけではありません。Manusは依然としてManusがロードするものをロードするため、より小さく、より良く整理されたナレッジベースを目指すというゴールは変わりません。
実践において何が変わるか
エントリの削除がリスクに感じられなくなります。 失うのではなく、移動しているだけだからです。
グローバルストアが小さくなり、有用性が維持されます。 雑多な100の事実よりも、関連性の高い20の事実の方が優れているというのは、開発元自身の主張でもあります。
プロジェクトのセットアップを繰り返す必要がなくなります。 マスター指示とプロジェクトナレッジベースが、すべての新しいタスクに自動的に適用されます。
「これはどのエントリのためのものか？」に対する答えが明確になります。 プロジェクト範囲のコンテキストはプロジェクトに属します。
制限に達することが大ごとではなくなります。 それは仕分けを行うためのきっかけに過ぎず、どのみち仕分けを行うことでメリットが得られます。
知識がツールよりも長生きします。 将来的に移行する場合に役立ちます。その具体的な方法については、ManusからCursorへの移行方法で解説しています。
Manusナレッジベースのベストプラクティス
削除する前に統合する。 3つのエントリに重複しているルールをまとめることが、最も簡単にカウントを減らす方法です。
グローバルストアは本当にグローバルなものだけに限定する。 あなたの役割、共通のルール、永続的な好みなど。特定のプロジェクト名が含まれるものは除外します。
プロジェクトのコンテキストはプロジェクト内に置く。 すべてのプランで利用可能であり、ドキュメント化されたエントリ制限はありません。
具体的なマスター指示を書く。 Manusのガイダンスによると、指示を具体的にすることで、タスクごとに提供しなければならない情報が減少します。
プロジェクトファイルを変更した後は、新しいタスクを開始する。 ファイルの更新は、変更後に作成されたタスクにのみ適用されます。
上限に達したときではなく、定期的に見直す。 Manus自身のヒントは「ナレッジベースを最新の状態に保つこと」です。四半期ごとの見直しは、緊急のクリーンアップよりも効果的です。
1つのエントリに無関係なルールを詰め込まない。 制限が存在する目的を損ない、選択的な削除ができなくなります。
削除するもののコピーを手元に残しておく。 制限は「ロードするかどうか」の決定に過ぎません。「忘れるかどうか」の決定であってはなりません。
結論
Manusのナレッジベースは、Proユーザーは100エントリ、Freeユーザーは50エントリに制限されており、開発元が公表している理由はストレージ容量ではなく回答の品質です（「エントリ数が多すぎると、システムの回答品質に影響を与える可能性があります」）。そう捉えれば、この制限は整理（キュレーション）に関するアドバイスであり、推奨されるアクションは拡張することではなく、純粋にスリム化することです。
実用的な解決策は、Manusには2つのナレッジベースがあり、ほとんどの人が1つしか使用していないという点にあります。プロジェクトは独自のマスター指示とファイルのナレッジベースを持ち、その中で作成されたすべての新しいタスクに自動的に適用され、すべてのサブスクリプション層で利用可能です。グローバルエントリを「グローバル」「プロジェクト固有」「古い情報」に分類し、中間のグループをプロジェクトに移動することで、必要な情報を削除することなく制限を解決できます。
ただし、反映ルールを把握しておいてください。指示の更新は次のメッセージから有効になり、ファイルの更新は新しく作成されたタスクにのみ適用され、既存のタスクは作成時の構成を維持します。そして、決定事項やその理由、削除をためらったものなど、永続的に残したい半分はエントリ制限のないレイヤーに保管してください。そうすれば、Manusがロードする情報を整理することが、あなたの知っている知識を失うことには繋がりません。