実際に移行されるもの
コンテンツとしての CLAUDE.md の記述。 ビルドコマンド、規約、アーキテクチャのメモ、「常にXを行う」といったルールなどです。Cursor は、プロジェクトのルートおよびサブディレクトリにある AGENTS.md（「Markdown 形式のエージェント指示書。.cursor/rules のシンプルな代替手段」）を読み込みます。リネームするかコピーするだけで完了です。なお、これは Claude Code 側の制約とは逆であることに注意してください。Claude Code のドキュメントには「Claude Code は CLAUDE.md を読み込み、AGENTS.md は読み込まない」と明記されています。
パススコープのルール（1対1のきれいなマッピング）。 これは移行プロセスの中で最もすっきりしている部分ですが、多くの人が見落としがちです。Claude Code の .claude/rules/ ファイルは、フロントマターに glob パターンの paths: フィールドを持ち、「paths フィールドのないルールは無条件にロードされ、すべてのファイルに適用される」となっています。Cursor のプロジェクトルールも、.mdc のフロントマターで globs を使用して同じ目的を果たします。alwaysApply: false と glob を指定すると、そのルールは「一致するファイルがコンテキスト内にあるときに自動的に添付される」ようになります。したがって、Claude Code で src/api/**/*.ts にスコープされていたルールは、Cursor でも src/api/**/*.ts にスコープされたルールになります。同じパターン構文、同じ考え方です。
個人設定（設定画面へ）。 Claude Code のユーザーレベルのレイヤーは ~/.claude/CLAUDE.md と ~/.claude/rules/ です。Cursor の対応する機能は User Rules（ユーザールール）であり、「Customize → Rules で定義され、すべてのプロジェクトに適用されるグローバルな設定」です。役割は同じです。ただし、依存する前に知っておくべき注意点が1つあります。「User Rules はインライン編集（Cmd/Ctrl+K）には適用されません。Agent（チャット）でのみ使用されます。」
組織全体の指示（ダッシュボードへ）。 Claude Code は、IT部門がOSレベルのパスにデプロイする管理ポリシー CLAUDE.md をサポートしています。Cursor の対応機能は Team Rules（チームルール）で、Team または Enterprise プランの Cursor ダッシュボードから作成します。ここでは「Enforce this rule（このルールを強制する）: 有効にすると、すべてのチームメンバーにこのルールが必須となり、Customize で無効にすることはできません」となっています。
それ以外は何も移行されません。具体的なリストは以下の通りです。
自動メモリ（Auto memory）の移行先はありません。 Claude は自身のために4種類のメモを保存し、各ファイルのフロントマターに type フィールドとして記録します。user（ユーザーの役割や作業の好み）、feedback（ユーザーが Claude に与えた修正や確定したアプローチ）、project（コードや git の履歴からは導き出せない進行中の作業や決定事項）、reference（プロジェクト外の情報の場所）です。コードベースから読み取れる内容や「CLAUDE.md ファイルにすでに書かれていること」は意図的にスキップされます。つまり、自動メモリには、設計上、他にはどこにも書き留められていない情報だけが保持されていることになります。そして、これは移行できません。「自動メモリはマシンローカルです。同じ git リポジトリ内のすべてのワークツリーとサブディレクトリは、1つの自動メモリディレクトリを共有します。ファイルはマシン間やクラウド環境間で共有されません。」移行する前に必ず中身を確認してください。
@path インポートに相当する機能は Cursor にはありません。 CLAUDE.md は @path/to/import 構文を使って「最大4ホップの深さまで」再帰的に他のファイルを取り込むことができ、インポートされたファイルは「起動時に展開されてコンテキストにロード」されます。Cursor で最も近い仕組みはルール内での @filename.ts の使用であり、FAQ でも「ルールのコンテキストにファイルを含めるには @filename.ts を使用してください」とされていますが、これはインポートチェーンではなく、4レベルの深さまで合成することはできません。4ホップのインポートツリーは、1つのファイルにフラット化するか、複数のルールに分割する必要があります。
CLAUDE.local.md はその役割を失います。 これはプロジェクトルートにある gitignore された個人用レイヤーで、「バージョン管理にコミットすべきではない、プロジェクトごとのプライベートな設定用」です。Cursor の User Rules はプロジェクトごとではなくグローバルであるため、特定のリポジトリでのみ意味を持つ個人用メモは、グローバルにするか、ステージング（コミット）しないように注意しなければならない未コミットの AGENTS.md にするしかありません。
競合の処理方法が異なり、これによって挙動が変わります。 Claude Code では「検出されたすべてのファイルは、互いに上書きし合うのではなく、コンテキストに連結される」となっており、ファイルシステムのルートから順に並べられます。2つのファイルの内容が矛盾している場合、「Claude は任意に一方を選択することがあります」。一方、Cursor は明確な優先順位を定義しています。「ルールは次の順序で適用されます：Team Rules → Project Rules → User Rules。適用可能なすべてのルールがマージされ、ガイダンスが競合する場合は、より優先度の高いソースが優先されます。」Claude Code がコインの裏表で解決していたような矛盾を抱えたまま運用していた場合、Cursor はそれを一貫したルールで解決するため、これまで慣れていた挙動とは異なる結果になる可能性があります。
フックは移行されません。 Claude Code のドキュメントには、エスケープハッチについて「Claude の判断に関わらずアクションをブロックするには、代わりに PreToolUse フックを使用してください」と明記されています。これはコンテキストではなく強制力（enforcement）であり、移行対象のルールシステムの一部ではありません。
サブエージェントのメモリはもともと分離されていました。 「メインの会話の自動メモリはサブエージェントにはロードされない」ため、サブエージェント独自の自動メモリは専用のディレクトリに保存され、サブエージェントごとの状態としてその場に残ります。この境界線については、why Claude Code subagents don't share memory（Claude Code のサブエージェントがメモリを共有しない理由）で解説しています。
手動での移行手順
ステップ 1: 変更を加える前に、実際にロードされている内容をダンプする
読んだことのないセットアップを移行することはできません。Claude Code において、実際にロードされている設定は、自分が書いたと記憶している内容と一致しないことがよくあります。
セッション内で /context を実行し、Memory files の下にあるリストを確認してください。これが、どの CLAUDE.md や CLAUDE.local.md ファイルが実際に読み込まれたかを示す「真実のソース（ground truth）」です。ドキュメントでも、最初のデバッグステップとしてこれが推奨されています。「そこにファイルがない場合、Claude はそれを認識できません。」作業ディレクトリより上の階層にあるファイルは起動時にロードされます。サブディレクトリ内のファイルは「Claude がそれらのディレクトリ内のファイルを読み取るときにオンデマンドでロードされる」ため、一度もマッチしなかったサブディレクトリのルールは表示されません。
次に /memory を実行します。これにより、CLAUDE.md、CLAUDE.local.md、およびその他のメモリファイルの場所がリスト表示され、自動メモリフォルダを開くオプションが表示されます。これを開いてください。中にあるものはすべて、読み取り、編集、削除が可能なプレーンな Markdown です。特に feedback や project ファイルは、セットアップ全体の中で最も価値の高い記述であることが多いです。あなたが与えた修正、デッドライン、コードには残っていない決定事項などが含まれています。今でも重要な内容を、ポータブルな形式にコピーしておきましょう。これらは自動的に Cursor に移行されることはありません。
確認する際、注意すべき点が2つあります。MEMORY.md は「MEMORY.md の最初の200行、または最初の25KBのいずれか早い方」までしかロードされません。そのため、ファイルが長い場合、後半部分はそもそも読み込まれていませんでした。また、トピックファイルは起動時には一切ロードされず、Claude は「標準のファイルツールを使用してオンデマンドで読み取ります」。目視ではなくログとして監査したい場合は、InstructionsLoaded フックが「どの指示ファイルが、いつ、なぜロードされたか」を正確に記録しています。
ステップ 2: フォーマットを一度決めて、Cursor でレイヤーを再構築する
以下の順序で、4つの決定を行います。
リポジトリの指示: AGENTS.md か .cursor/rules か。 CLAUDE.md を AGENTS.md にコピーすれば、すぐに機能します。条件付きでロードしたいものだけを .cursor/rules に変換してください。これが .mdc のフロントマターが提供する機能です。Cursor の4つのルールタイプは、Always Apply（常に適用）、Apply Intelligently（インテリジェントに適用：「説明に基づいて Agent が関連性があると判断したとき」）、Apply to Specific Files（特定のファイルに適用：「ファイルが指定されたパターンに一致するとき」）、Apply Manually（手動で適用：「チャットで @メンションされたとき」）です。すでに paths: でスコープされたルールがあった場合は、それらを変換対象とし、残りは通常のテキスト（prose）のままで構いません。
拡張子に注意してください。「.cursor/rules 内のプレーンな .md ファイルは、description、globs、alwaysApply を指定するフロントマターがないため、ルールシステムによって無視されます。プレーンな Markdown を好む場合は、代わりに AGENTS.md を使用してください。」古いルールファイルをそのままそのディレクトリに放り込んでしまうのは、移行したつもりが何も適用されない状態（沈黙）になってしまう最も一般的な原因です。
インポートをフラット化する。 すべての @path チェーンを、それを参照しているファイルに展開するか、個別のルールに解決します。その際、長さに注意してください。Cursor のガイドラインでは「ルールは500行未満に抑える」こと、および「内容をコピーするのではなくファイルを参照する。これによりルールを短く保ち、コードの変更に伴ってルールが古くなるのを防ぐ」ことが推奨されています。Claude Code も同様の方向性を示しており、「CLAUDE.md ファイル1つあたり200行未満」を目標としています。
グローバルとローカルを分割する。 個人の好みは Customize → Rules に設定します。リポジトリの規約は AGENTS.md または .cursor/rules に記述してコミットします。ネストされた AGENTS.md を使用すると、フロントマターを一切使わずにディレクトリのスコープを設定できます。指示は「親ディレクトリのものと結合され、より具体的な指示が優先されます」。
チームでルールを共有する場合は、リモートルール（Remote rules）を使用する。 Cursor は GitHub リポジトリからルールをインポートできます。Customize → Rules → Add Rule → Remote Rule (Github) を選択し、リポジトリの URL を貼り付けると、「Cursor はリポジトリ内のすべての .mdc ファイルをスキャン」し、相対パスを維持したまま .cursor/rules/imported/<repoName> に配置します。これは .mdc 専用の機能であるため、テキストのまま残すのではなく変換する理由になります。また、これは両方のツールの中で、共有・更新可能なルールソースに最も近い仕組みです。
しばらく両方を併用することになった場合、逆方向の移行については migrating from Cursor to Claude Code（Cursor から Claude Code への移行）にまとめられており、ファイル標準に関する疑問は migrating your CLAUDE.md to AGENTS.md（CLAUDE.md から AGENTS.md への移行）でカバーされています。
より良い方法：蓄積された知識を両方のツールの外に置く
ステップ1で行ったことを振り返ってみてください。Claude が数ヶ月にわたってプロジェクトについて書き留めたメモのフォルダを開き、手動で読み、良い部分を別の場所にコピーしました。これは機能しましたが、通用するのは一度きりです。
手動で行わなければならない理由は、構造的なものです。自動メモリは設計上、マシンローカルです。Cursor のルールは設計上、リポジトリごとであり、バージョン管理されます。どちらのツールも、リクエストごとに常に送信されるコンテンツの量を制限するため、保持できる量に上限（ここでは200行、あちらでは500行など）を設けています。どちらも、アーキテクチャがなぜそのようになっているのかという「永続的な記録場所」として構築されておらず、そうであるとも主張していません。
それこそが MemoryLake が保持するものです。プロジェクトの永続的な知識を、ツールが読み取るレイヤーに保存するため、ツールの切り替えが「知識の移行作業」ではなくなります。セットアップは3つのステップで完了します。
ステップ 1: API キーを作成する
MemoryLake にサインインし、API キーを作成します。接続するすべてのツールで共通の認証情報として使用できます。
ステップ 2: 最初のメモリをアップロードする
1つの項目につき1つの主張を含む、短いエントリを作成します。先ほど確認した自動メモリフォルダがソース素材となります。すでに大まかに適切なカテゴリに分類されています：
複数回行う必要があった修正。 これは Claude Code 独自の feedback カテゴリであり、ディレクトリ内で最も価値のある情報です。両方のツールから読み取れる場所に移動しましょう。
決定事項と、それを強制した制約。 「負荷がかかるとリードレプリカが遅延するため、マイグレーションは追加のみとする」といった内容です。ルールはポリシーを規定しますが、このような制約を記録しておくことだけが、来週また同じ代替案が提案されるのを防ぐ唯一の方法です。
すでに却下されたアプローチとその理由。 ルールファイルにもコミットメッセージにも現れないカテゴリです。新しいエージェントは、毎回これを再び提案してきます。
苦労して学んだ環境に関する事実。 CI でのみ失敗するテスト、ドキュメント化されていないレート制限、最近のデータが全くないステージングデータベースなどです。
ステップ 3: AI とエージェントを接続する
使用しているツールを接続します。MemoryLake は MCP および API 経由でアクセスできるため、Claude Code、Codex、OpenClaw などの MCP ネイティブなエージェントは MCP サーバーを指定することで接続し、他のアシスタントは API を通じて同じメモリを読み取ります。これにより、移行をいつでも元に戻せるようになります。まだ検討している段階でも、両方のエディタから同じレイヤーを読み取ることができます。
3つの率直な制限事項があります。MemoryLake は自動メモリフォルダを読み取ることはなく、CLAUDE.md や Cursor のルールを書き換えることもありません。 ステップ1の手動での読み取りは必要であり、各ツールを制御するのはあくまでルールファイルです。MemoryLake は、ユーザーまたはエージェントが入力した内容のみを保持します。また、ルールとメモリはどちらもコンテキストであり、強制的な設定ではありません。状況に関わらず毎回必ず実行させたい処理がある場合は、メモリレイヤーではなく、フックや CI チェックを使用してください。
実務における変化
移行が「一方通行の扉」ではなくなります。 両方のエディタが同じ外部メモリを読み取るため、Claude Code のセットアップを解体することなく、Cursor を2週間試してみるといったことが可能になります。
移行しない場合でも、自動メモリの確認は行う価値があります。 ほとんどの人はそのフォルダを開いたことがありませんが、project や feedback ファイルは、過去6ヶ月間の驚くほど優れた要約になっています。
新しいツールではルールファイルが短くなります。 CLAUDE.md が200行を超えて肥大化するのは、「制御」と「記憶」という2つの役割を同時に担っているからです。これらを一度分割してしまえば、どちらのツールの制限にも縛られなくなります。
「エージェントがまだ私のプロジェクトを理解していない」に対する本当の解決策が得られます。 「さらにルールを書く」のではなく、「その知識は最初からルールに含まれていなかった」という気づきです。これについては、why RAG isn't memory（なぜ RAG はメモリではないのか）で詳しく解説しています。
Claude Code から Cursor への移行におけるベストプラクティス
何よりも先に、自動メモリフォルダを開いてください。 これは、移行先にインポーターが存在しない唯一のセットアップ部分であり、あなたが直接記述していない部分です。
自分が書いた記憶ではなく、/context を信頼してください。 Memory files のリストに表示されているものが、実際にロードされたものです。一度もマッチしなかったサブディレクトリのファイルはそこには表示されません。
paths: ルールを globs に変換し、残りは通常のテキストとして保持します。 マッピングは直接行えます。それ以外は AGENTS.md として扱う方が簡単です。
.cursor/rules 内にプレーンな .md を放置しないでください。 何の警告もなく無視されます。フロントマター付きの .mdc を使用するか、AGENTS.md を使用してください。
@path インポートを再現しようとせず、フラット化してください。 Cursor の @filename 参照は、4ホップのインポートチェーンには対応していません。
矛盾が発生したときの解決先を決めておきます。 Cursor は Team Rules ＞ Project Rules ＞ User Rules の順にマージしますが、Claude Code は連結して任意に選択していました。これまで見過ごされてきた矛盾を解決しておきましょう。
グローバルな好みは User Rules に配置し、インライン編集のギャップに注意してください。 これらはプロジェクトをまたいで適用されますが、Cmd/Ctrl+K には適用されません。
意思決定の背景にある理由は、両方のルールシステムの外に置いておきます。 ルールは指示とポインタに過ぎません。決定の背後にある議論こそが、想定外のケースにエージェントが対処できるようにするための鍵となります。これについては、why agents ignore the instruction files you wrote（なぜエージェントはあなたが書いた指示ファイルを無視するのか）で解説しています。
結論
Claude Code から Cursor への移行は、机上では簡単に見えますが、実際には情報が失われやすく、その分岐点は予想外の場所にあります。CLAUDE.md はリネームするだけで AGENTS.md になります。paths: でスコープされたルールは、Cursor の globs にほぼ正確にマッピングされます。ユーザーレベルのファイルは User Rules になり、管理ポリシーファイルは Team Rules になります。
移行されないのは、Claude が自身のために書き留めたすべての内容です。自動メモリはデフォルトで有効になっており、~/.claude/projects/<project>/memory/ にマシンローカルな Markdown として保存されています。ここには、CLAUDE.md には含まれていない重要な情報が保持されていますが、Cursor がこれを見ることはありません。@path チェーンはフラット化する必要があり、CLAUDE.local.md はプロジェクトごとのスコープを失い、Claude Code が任意に解決していた矛盾は、明示された優先順位に従って解決されるようになります。
したがって、まずは自動メモリフォルダを確認し、/context でロードされたセットをダンプし、条件が必要なルールのみを変換し、決定事項や却下されたアプローチは両方のエディタからクエリできるレイヤーに配置するようにしてください。