CursorとClaude Codeで1つのメモリを共有する方法 (ステップ・バイ・ステップ、2026年)

メカニズムは対称的だが互換性はない

Cursorのドキュメントでは、4種類のルールが説明されています。.cursor/rulesに.mdcファイルとして保存されるプロジェクトルール、Cursor環境全体でグローバルなユーザールール、TeamおよびEnterpriseプランのダッシュボードから管理されるチームルール、そしてプロジェクトルートにあるMarkdownの代替手段としてのAGENTS.mdです。一方、Claude Codeのドキュメントでは、4つのスコープ（管理ポリシー、ユーザー（~/.claude/CLAUDE.md）、プロジェクト（./CLAUDE.mdまたは./.claude/CLAUDE.md）、ローカル（CLAUDE.local.md））におけるCLAUDE.mdと、パススコープの指示用の.claude/rules/が説明されています。

これらを並べてみると、異なるファイル名、異なるフロントマターフィールド、異なるロードルールを使用する、ほぼ並行した2つのシステムが存在することがわかります。どちらも相手の主要なフォーマットを読み込むことはありません。Claude Codeのドキュメントには、「Claude CodeはCLAUDE.mdを読み込み、AGENTS.mdは読み込みません」と直接書かれています。

両方のツールが読み込む1つのファイルと、その公式な連携方法

ここが多くの人が見落としがちなポイントです。Cursorは、プロジェクトルートにあるAGENTS.mdをサポート対象の指示ファイルとしてリストしており、より具体的な指示が優先されるサブディレクトリ内のネストされたAGENTS.mdファイルもサポートしています。そして、Claude Codeのドキュメントには、その同じファイルを自側で動作させるための正確なレシピが記載されています。「リポジトリがすでに他のコーディングエージェント用にAGENTS.mdを使用している場合は、それをインポートするCLAUDE.mdを作成することで、重複させることなく両方のツールが同じ指示を読み込むようにします。」

これは、@AGENTS.mdを含む1行のCLAUDE.mdを作成するか、Claude固有の追加設定が不要であればシンボリックリンクを作成することを意味します。これにより、両方のツールが1つのファイルを読み込むようになります。これはハックではなく、双方で公式にドキュメント化されているパターンです。

ファイルによるトリックではカバーできないこと

ファイルをどのように配置しても、以下の2つの要素は分離されたままになります。

Claude Codeの自動メモリ（auto memory）。 これはデフォルトで有効になっており、~/.claude/projects/<project>/memory/の下にメモを保存し、各セッションにMEMORY.mdの最初の200行または25KBをロードします。そして、明示的にマシンローカルです。ドキュメントには、これらのファイルは「マシン間やクラウド環境間で共有されない」と記載されています。また、これはあなたではなくClaudeによって書き込まれます。Cursorにはこれを読み込む同等の機能はなく、コミットできるいかなるファイルもこれを可視化することはできません。

条件付きロード。 Cursorの4つの適用モード（alwaysApply: true、インテリジェントな適用のためのdescription、特定ファイル用のglobs、または@-メンションを必要とする手動ルール）が、ルールがいつコンテキストに入るかを決定します。Claude Codeの.claude/rules/は、同じ目的のためにpaths:フロントマターフィールドを使用します。どちらも合理的ですが、これは「コンテンツを共有している」からといって「同じタイミングでロードされる」わけではないことを意味します。

MCPは両方のツールがすでにサポートしている唯一のチャネル

しかし、AGENTS.md以外にもこの2つのツールには共通点があり、そちらの方がより興味深いものです。それは、両方がMCPをサポートしている点です。Claude Codeは、サブエージェントごとのインラインmcpServers定義を含め、MCPサーバーの設定を主要機能としてドキュメント化しており、Cursorも独自の設定画面でMCP設定を公開しています。

これが重要なのは、「メモリの共有」が意味することを変えるからです。共有されたファイルは静的です。同じテキストが両方にロードされ、手動で更新されます。一方、共有されたサーバーは動的です。両方のツールが必要な瞬間に同じストアに問い合わせを行い、一方からの書き込みは次の読み込み時に他方から見えるようになります。作業中に変化するナレッジ（最も重要なナレッジの大部分がこれに該当します）にとって、この2番目の形態こそが真に機能するものです。

これはまた、2つのツールのネイティブなメモリシステムのどちらか一方を選ぶ必要がないことも意味します。Claude Codeはローカルな想起のために自動メモリを保持し、Cursorは条件付きロードのためにルールを保持します。そして、永続的なプロジェクトのナレッジは、どちらのツールも相手のフォーマットを理解する必要なく、双方がアクセスできる1つの場所に存在することになります。

そして、何かをコピーする前に知っておくべき1つの罠があります。 Cursorのドキュメントには、「.cursor/rules内のプレーンな.mdファイルは、description、globs、alwaysApplyを指定するフロントマターがないため、ルールシステムによって無視されます」と記載されています。コンテンツを移動して、そのディレクトリにプレーンなMarkdownファイルを配置しても、何も警告されずに無視されます。この具体的な失敗については、why Cursor forgets project rulesで解説しています。

同じ内容の2つのファイルを維持する。 デフォルトのアプローチであり、約2週間は機能します。しかし、誰かが一方を更新すると、ツール間で不一致が生じます。両方のファイルがメンテナンスされているように見えるため、エラーも発生せず、差分にも気づきません。

両方のファイルを巨大にする。 ファイルが唯一のチャネルである場合、すべてをファイルに詰め込むことになります。しかし、両方のベンダーがこれを推奨していません。Cursorはルールを500行未満に抑え、大きなルールは再利用可能なパーツに分割することを推奨しています。Claude Codeは1ファイルあたり200行未満に抑えることを推奨しており、ファイルが長くなると「より多くのコンテキストを消費し、指示への追従性が低下する」と指摘しています。

マシン間で`~/.claude`を同期する。 自動メモリがマシンローカルである問題を回避するために、設定ディレクトリ全体を同期する人もいます。これは開発者によるワークアラウンドであり、公式にドキュメント化された機能ではありません。また、書き込みの競合が発生する現実的なリスクがあります。本番の設定ではなく、実験的なものとして扱ってください。

/initを実行して完了とする。 便利ですが十分に活用されていません。Claude Codeの/initは、.cursor/rules/または.cursorrulesからCursorのルールを読み込み、生成されたCLAUDE.mdに関連部分を組み込みます。また、CLAUDE_CODE_NEW_INIT=1を使用すると、AGENTS.md、.devin/rules/、.windsurf/rules/、.clinerulesも読み込みます。しかし、これは1回限りのコピーであり、リンクではありません。一度実行すると、2つのファイルは再び乖離し始めます。サポートされているエージェントの設定を取り込み、MCPサーバー、コマンド、サブエージェント、スキルを引き継ぐ/importも同様で、同期ではなく移行（マイグレーション）です。この一方通行の移行を適切に行いたい場合は、migrating Cursor rules to Claude Codeで詳しく解説しています。

二重の手間を受け入れる。 最も一般的な結果です。開発者は単に説明を繰り返します。これはメッセージごとにトークンを消費し、本当に重要なこと、つまり「2番目のツールが、1番目のツールが学んだことを知らないまま意思決定を行う」というコストを支払うことになります。

問題を2つに分割すれば、どちらも簡単になります。

常にコンテキストに含めるべきルールは、コミットされた1つのファイルに配置します。AGENTS.mdを実際の内容とし、それをインポートする1行のCLAUDE.mdを使用します。内容は短く保ちましょう。ナレッジベースではなく、コードレビューで主張するようなルールに限定します。

蓄積されていくナレッジは、両方のツールが問い合わせるメモリレイヤーに配置します。それこそがMemoryLakeです。両方のエージェントからアクセス可能な1つのストアであり、そうしなければ一方のツールのプライベートなメモリディレクトリに埋もれてしまう決定事項や制約事項を保持します。セットアップは3つのステップで行えます。

ステップ 1: APIキーの作成

MemoryLakeにサインインし、APIキーを作成します。両方のツールで1つの認証情報を使用します。これが重要なポイントであり、認証情報は現在使用しているエディタに縛られません。

ステップ 2: 最初のメモリのアップロード

何度も説明し直していることから始めましょう。アーキテクチャの決定とその背後にある理由、コンテキストなしでは恣意的に見える制約、暗黙の了解となっている規約、そして試したものの却下したアプローチなどです。Claude Codeが自動メモリを蓄積している場合は、そのディレクトリを開いて読み取ってみてください。そこにある永続的な事実は、まさにCursorがこれまでアクセスできなかった情報です。検索時に実用的な結果が得られるよう、各エントリーは短く、単一のトピックに絞って記述してください。

ステップ 3: AIとエージェントの接続

両方のツールを接続します。MemoryLakeはMCPおよびAPI経由でアクセス可能です。そのため、Claude Code、Codex、OpenClawなどのMCPネイティブなエージェントはMCPサーバーを指定することで接続し、Cursorは独自のMCP設定を介して接続します。この時点から、2つのツールは同じナレッジを読み込むようになり、一方での作業中に記録された決定事項が他方でも利用可能になります。MCP側の一般的なセットアップ手順については、setting up cross-AI memory with MCPを参照してください。

ここで、2つの現実的な制限事項があります。第一に、これは2つのツール独自のメモリシステムを統合するものではありません。Claude Codeは引き続きマシンローカルな自動メモリを書き込みますが、それで問題ありません。最近のローカルな作業を思い出すにはそれが適しています。第二に、これは強制力のあるレイヤーではありません。両ベンダーとも、指示を「設定」ではなく「コンテキスト」として説明しているため、モデルの判断に関わらず必ず遵守すべきルールは、フックやCIチェックに記述すべきです。

1つの修正が両方のツールに反映される。 具体的なメリットです。現在、Cursorに「そのORMはもう使っていません」と伝えても、学習するのはその1つのツールだけです。修正が共有レイヤーに反映されれば、もう一方のツールもそれを提案するのをやめます。

引き継ぎ時のコンテキスト喪失がなくなる。 一般的なワークフローは、一方のツールで調査し、もう一方のツールで実行するというものです。この引き継ぎの際に説明の繰り返しが発生しますが、共有レイヤーはこれを取り除きます。これは、1つのツール内で行われるsharing context between Claude Code sessionsに近い効果を、2つのツール間に拡張したものです。

両方の指示ファイルが短くなる。 参照ナレッジが検索可能になれば、AGENTS.mdは本来あるべき短いリストに収めることができ、指示が遵守される信頼性が目に見えて向上します。

マシンの境界がそれほど重要ではなくなる。 自動メモリがマシンローカルであるということは、蓄積されたナレッジの半分が1台のコンピュータ上に存在することを意味します。共有レイヤーはそのメカニズム自体を変えるわけではありませんが、重要な部分がそこだけに留まらないようにします。これは、stopping Cursor from forgetting across machinesで説明されている問題に対処します。

3つ目のツールの追加は、単なる接続作業になる。 次にどのようなツールを導入しても、白紙の状態から始めて再び1週間かけて説明し直す必要はなく、同じメモリを読み取ることができます。

1つの実ファイルと1つのポインタ。 AGENTS.mdがコンテンツを保持し、CLAUDE.mdには@AGENTS.mdと、必要に応じてその下に短いClaude固有のセクションを記述します。決して2つの完全なコピーを作成しないでください。

globパターンの整合性を保つ。 CursorルールのglobsとClaude Codeルールのpaths:が同じファイルセットを記述している場合、それらをペアとしてレビューできます。これらが乖離すると、特定の領域向けルールが一方のツールにのみ適用され、他方には適用されないという状況が発生します。

`.cursor/rules`にプレーンな`.md`ファイルを絶対に置かない。 警告なしに無視されます。フロントマターのないコンテンツはAGENTS.mdに配置すべきです。

/initは意図的に1回だけ実行する。 これはCLAUDE.mdを作成する良い出発点であり、既存のCursorやCopilotのルールを読み取ってくれます。ただし、これを継続的な同期と混同しないでください。

再構成後はロードされた内容を確認する。 Claude Codeは、セッション内で/contextを実行することで、ロードされたメモリファイルをリスト表示します。モデルが指示を無視していると結論付ける前に、まずロードされているか確認してください。この違いは、5分で済む修正か、あるいはwhy Claude Code forgets project contextで説明されているような1週間にわたるプロンプト調整かの違いを生みます。

決定事項だけでなく、却下した事項も書き留める。 最も価値の高いカテゴリです。却下した理由が読み取れる場所に記述されていない限り、両方のツールはすでに除外したアプローチを何度も再提案してきます。

2つのツールを使用することによる手間には2つの要素があり、それぞれ異なる解決策が必要です。常に有効なルールは、真に1つのファイルにまとめることができます。CursorはAGENTS.mdを読み込み、Claude Codeの公式ドキュメントは1行のCLAUDE.mdからそれをインポートするよう指示しています。今日の午後にでもこれを実行すれば、最も頻繁に重要となるレイヤーでの乖離問題を解消できます。

ファイルにできないのは、蓄積されるナレッジの共有です。Claude Code側ではそのレイヤーはマシンローカルかつ自動生成されるものであり、Cursor側ではフロントマターの条件によって管理されているためです。その半分を、両方のツールが問い合わせるメモリレイヤーに配置すれば、コード編集とエージェント作業の間の引き継ぎが、コンテキストの墓場になることはなくなります。