Cursorにプロジェクト of ファイル構造を記憶させる方法 (2026)

ツリーの一部が意図的にインデックスから除外されている

これは最初に確認すべきことであり、何も通知されないため、多くの人が驚くポイントです。

Cursorは無視ファイルを尊重します。ドキュメントには次のように書かれています。「Cursorは自動的に.gitignoreパターンを尊重します。gitによって無視されるファイルは、Cursorのインデックス登録からも除外されます。」さらに、.cursorignoreは「.gitignoreがカバーする範囲を超えた追加の除外」を加え、Cursorは「デフォルトで.envファイル、.git/、およびロックファイルをすでに無視しています」。

その結果は明白です。「無視されたファイルは、インデックス登録およびAgentからブロックされます。」したがって、生成されたAPIクライアント、ベンダー提供のSDK、またはビルド出力ディレクトリがgitignored（通常はそうです）になっている場合、Agentはその部分の構造をまったく見ることができません。それらのファイルがどこにあるかを忘れているのではなく、最初から見せられていないのです。

ここには、本当に紛らわしい挙動を説明するニュアンスがあります。「ターミナルコマンドとMCPツールはCursorのファイルアクセス制御の外で実行されるため、無視されたファイルを読み取ることができる場合があります。」そのため、同じAgentがlsを実行した後にディレクトリが存在することを知っていても、検索を通じてその中の何も見つけられないということが起こります。この一貫性のなさは、まさに「物忘れ」のように見えます。

保存されたマップは存在しない — 構造は毎回再発見される

@メンションに関するCursorのガイダンスは、見た目以上に示唆に富んでいます。それらを使用するのは「どのファイルが関連しているか分かっているとき」であり、「どのファイルが重要か分からない場合はスキップしてください。Agentは独自の検索を通じて関連ファイルを見つけます」とされています。

それが設計です。Agentはメッセージ間でプロジェクトマップを保持するのではなく、リクエストごとに関連する場所を特定します。ルールがそれを配置するか、あなたが添付しない限り、ターンの間でレイアウトに関する情報は何も残りません。そして、Cursorはなぜ何かが持続するのかについて率直に述べています。「大規模言語モデルは、補完の間でメモリを保持しません。ルールはプロンプトレベルで永続的かつ再利用可能なコンテキストを提供します。」

したがって、「ファイル構造を記憶する」というのは、見つけられなかったメモリ設定ではありません。何を、どのように永続化させたかという問題なのです。

構造について書いたルールがロードされていない

もし配置ルールを書いたのに無視されている場合、ほぼ確実に4つの原因のいずれかです。CursorのFAQはそのうちの最初の2つを挙げています。「ルールのタイプを確認してください。Apply Intelligently（インテリジェントに適用）の場合は、説明（description）が定義されていることを確認してください。Apply to Specific Files（特定のファイルに適用）の場合は、ファイルパターンが参照ファイルと一致していることを確認してください。」

フロントマターの表を頭に入れておく価値があります。なぜなら、フィールドが設定されていないルールは壊れたルールではなく、手動ルールだからです。alwaysApply: trueの場合、それは「常に含まれます。Globと説明は無視されます」となります。alwaysApply: falseでglobがある場合、「一致するファイルがコンテキスト内にあるときに自動添付」されます。説明がありglobがない場合、「Agentは説明を読み、関連性があるときにルールを取り込みます」。どちらもない場合、「チャットでルールを@メンションしたときにのみ含まれます」。

そして拡張子の罠です。「.cursor/rules内のプレーンな.mdファイルは、description、globs、alwaysApplyを指定するフロントマターがないため、ルールシステムによって無視されます。プレーンなMarkdownを好む場合は、代わりにAGENTS.mdを使用してください。」

そして最後に場所です。ルールは、開いているフォルダの.cursor/rulesに配置されます。モノレポのサブディレクトリをプロジェクトとして開くと、ルールはそのサブディレクトリにスコープされます。

貼り付けられたツリーは1週間以内に間違ったものになる

ロードされたとしても、それは劣化します。ディレクトリ一覧は、常にオンのファイルに入れるものの中で最も早く腐敗するものであり、古くなったツリーは無い方がマシです。移動したパスをAgentに積極的に指し示してしまうからです。これこそが、Cursorがルールが「コードの変更に伴って古くなる」と言っている意味であり、コピーするのではなく参照することを勧める理由です。

tree -L 3の出力を常にオンのルールに貼り付ける。 ロードされ、数日間は正確ですが、その後誤った方向へ導き始めます。ルールの内容は「モデルコンテキストの開始時に含まれる」ため、すべてのメッセージでその分のコストを支払うことになります。

「プロジェクトは機能ごとに整理されている」とだけ書く。 事実ですが、実行不可能です。これではAgentに新しいファイルがどこに行くべきかを伝えられません。

すべてのチャットで手動でフォルダを再添付する。 機能はしますが、how to stop re-explaining context to AI（英語）で説明されているようなループに陥ります。

Cursorが認識できるようにディレクトリの無視を解除する。 たまに正しいこともありますが、多くはそうではありません。ドキュメントには、「大きな生成ファイルはインデックス登録を遅くする」「シークレットや資格情報はAIコンテキストから除外した方が安全である」など、無視される理由がリストされています。

構造ルールを「Apply Intelligently」に設定する。 合理的に聞こえますが、5秒で書いた説明に決定を委ねることになります。曖昧な説明では、ルールは適用されません。

セッションごとにAgentにコードベースを再スキャンするよう依頼する。 コストがかかり、反復的です。同じパターンがhow to stop Claude Code re-reading your codebase（英語）にも現れています。

この問題を扱いやすくするための再定義：Cursorにファイルがどこにあるかを記憶させたいのではありません。新しいファイルがどこに行くべきか、そしてその理由を知ってほしいのです。前者は導出可能で劣化します。後者は規約であり、維持されます。

Cursor自身のドキュメントは、明言することなくこれを示しています。globs: src/components/**/*.tsxにスコープされた自動添付ルールの例には、「コンポーネントの隣のモジュールCSSファイルにスタイルを同じ場所に配置する」「コンポーネントを200行未満に保つ。ファイルがそれを超えて大きくなった場合は、サブコンポーネントを同じディレクトリに抽出する」といった行が含まれています。これらは配置ルールです。例の中にツリーはありません。

4つのステップ：

何かを書く前に、無視ファイルを監査する。 Agentが間違え続けるディレクトリに対して、.gitignoreと.cursorignoreを確認してください。フォルダが本当に表示されるべきである場合（チェックインされたスキーマディレクトリ、コミットする生成されたクライアントなど）、それは1行の修正で済み、どのようなルールもこれに代わることはできません。

globでスコープされた配置規約を書く。 領域ごとに1つのルールを作成し、そこで作業しているときにロードされるようにパターンで添付します。ドキュメント化されているglob形式を使用してください：src/配下のすべてには src/**、コンポーネントには src/**/*.tsx、2つ必要な場合は docs/**/*.md, docs/**/*.mdx のようなカンマ区切りのパターン。現在何が存在するかではなく、どこに何が配置されるべきか、ファイル名をどうすべきかを記述します。

構造的なスコープ設定には、ネストされた AGENTS.md を使用する。 任意のサブディレクトリに配置すると、「そのディレクトリまたはその子ディレクトリ内のファイルを操作するときに自動的に適用」され、指示は「親ディレクトリと組み合わされ、より具体的な指示が優先」されます。フロントマターやglobのメンテナンスは不要で、ファイルはそれが説明するコードの隣に置かれるため、レイアウトが変更されたときに更新される可能性が高くなります。

特定の要求に対してフォルダを明示的に添付する。 領域が分かっている場合は、それを@します。「ファイルやフォルダを含めるには @auth.ts または @src/components/（フォルダを選択した後に / を入力してさらに深く移動）。」これは目の前のリクエストのためのものであり、規約の代わりにはなりません。

これでロードとスコープは処理されます。しかし、これらがいずれも保持しないのは、レイアウトを意味のあるものにする部分です。なぜ境界がそこにあるのか、どの再編成を試して元に戻したのか、一見退化したように見えてそうではないディレクトリなどです。ルールは推奨される500行に制限されており、重複させるのではなく指し示すことを目的としているため、構造の背後にある議論を置く場所がありません。

それこそが MemoryLake が保持するものです。ツールが読み取るレイヤーにプロジェクトの永続的な知識を保持するため、ルールは短く保たれ、推論は利用可能な状態に維持されます。セットアップは3つのステップです。

ステップ 1: APIキーを作成する

MemoryLakeにサインインし、APIキーを作成します。接続するツール間で1つの資格情報を使用します。

ステップ 2: 最初の記憶（memory）をアップロードする

短いエントリで、それぞれ1つの主張を記述します。特に構造について書くべき内容は以下の通りです：

それぞれの新しいものがどこに行くべきかと、その理由。 「新しいAPIハンドラーは src/api/handlers/ にルートごとに1ファイルで配置します。ルーターがそのディレクトリをglobするためです。」 ルールは場所を示し、理由は来月現れるかもしれないもっともらしい代替案を阻止するものです。

一見任意に見えて、そうではない境界。 別のモジュールからインポートできないモジュール、フレームワークに依存しない状態を維持しなければならないディレクトリなど。ツリーの中には制約を伝えるものは何もありません。

すでに却下した再編成。 試したフラットな構造、意図的に持たないようにしている utils/ など。新しいAgentは毎回これらを提案してきますが、リポジトリ内にはその決定を記録するものが何もありません。

インデックスから除外されているディレクトリと、その中身。 もし generated/ がgitignoredされているなら、そこに何があり、どのように生成されるかについての1行のメモは、40,000個のファイルの無視を解除するよりもはるかに有用です。

ステップ 3: AIとAgentを接続する

使用するツールを接続します。MemoryLakeはMCPおよびAPI経由でアクセスできるため、MCPネイティブのAgent（Claude Code、Codex、OpenClawなど）はMCPサーバーを指すことで接続し、他のアシスタントはAPIを介して同じ記憶（memory）を読み取ります。一度書いた配置規約は、リポジトリで動作するすべてのAgentが読み取るものと同じになります。

3つの率直な制限事項。MemoryLakeはコードベースのインデックス登録を行わず、Cursorルールも作成しません — Cursor独自のインデックス登録がファイルを見つけ、ルールはAgentを誘導する方法です。MemoryLakeは、あなたやあなたのAgentが入力したものだけを保持するため、ステップ2は手動です。また、これは強制ではなくコンテキストです。配置ルールを本当に維持する必要がある場合は、lintルールやCIチェックがその保証となります。

「ファイルが間違った場所に置かれた」という問題は、2ステップのチェックになります。 ディレクトリが無視されていませんか？ ルールのタイプとパターンは正しいですか？ ほぼ確実にそのどちらかです。

フォルダを追加するたびにルールを更新する必要がなくなります。 規約はリファクタリングを生き残りますが、ディレクトリ一覧は生き残りません。

新しいコントリビューターは、Agentと同じ回答を得られます。 書面による配置規約は、モデルを誘導するだけでなく、オンボーディングドキュメントとしても機能します。

インデックス除外がバグのように見えなくなります。 .gitignoreがAgentの手の届かないところからファイルを取り除くことを知っていれば、「dist/の中に何も見つからない」という報告は不思議ではなくなります。

レイアウトの決定はツールを超えて存続します。 Cursor、Claude Code、またはCodexのどれが読み取っているかに関わらず、推論は同一です。これはwhat persistent memory actually means（英語）でカバーされている形です。

最初に .gitignore と .cursorignore を確認する。 gitによって無視されるファイルはCursorのインデックス登録からも無視され、いかなるルールもそれを回避することはできません。

常にオンのルールにディレクトリツリーを絶対に貼り付けない。 導出可能であり、1週間以内に古くなります。両方のベンダーがこれに反対しています。

構造ルールはglobでスコープする。 コンポーネントに関するルールは、すべてのメッセージではなく、コンポーネントを開いたときに添付されるべきです。

ディレクトリごとの規約には、ネストされた AGENTS.md を優先する。 より具体的な指示が優先され、維持すべきフロントマターはなく、ファイルはそれが説明するものの隣に置かれます。

.cursor/rules内では .mdc を使用し、プレーンな .md は絶対に使用しない。 そこにある .md ファイルは黙って無視されます。

ファイルリストではなく、命名規則を書く。 「ルートごとに1つのファイル、ルートにちなんで命名」は、handlers/のいかなるスナップショットよりも長持ちします。

目の前のタスクのために @ でフォルダを添付する。 検索が正しい領域を選択することを期待するよりも、正確性が勝ります。

推論はルールの外に置く。 なぜ境界が存在するのかを知ることで、Agentは規約が想定していなかったケースに対処できるようになります。これはwhy agents ignore the instruction files you wrote（英語）で説明されている一般的な問題です。

Cursorはメッセージ間でプロジェクトのマップを保持しませんし、保持するようには設計されていません。Agentは毎回独自の検索を通じて関連ファイルを見つけ、ルールは永続化が必要なもののためのドキュメント化されたメカニズムです。したがって、ファイルが間違った場所に配置された場合は、次の3つの事項を順番に確認してください。ディレクトリが.gitignoreまたは.cursorignoreによって除外されていないか、ルールのタイプとglobパターンが実際にロードされるようになっているか、そしてルールがファイルがどこに行くべきかを示しているか、それとも単にどこにあるかを説明しているだけか、です。

最後の点が本質的な解決策であり、CursorとClaude Codeの両方のドキュメントが独立して指摘している点でもあります。ツールが導出できるコンテンツに常にオンのコンテキストを費やさず、古くなるものをコピーしないでください。配置規約を書き、それらが管理するディレクトリにスコープを設定し、レイアウトの背後にある推論をすべてのツールが照会できる場所に保管してください。そうすれば、ツリーのスナップショットがたまたま正確だったからではなく、規約が明確であるために、新しいファイルが正しい場所に配置されるようになります。