実際に移行できるもの
スキル — 変更は一切不要です。 Zedのスキルインストール手順では、「グローバルで使用する場合はスキルのフォルダを~/.agents/skills/にコピーし、プロジェクトローカルで使用する場合はプロジェクトの.agents/skills/フォルダにコピーする」となっています。Cursorは、.agents/skills/、.cursor/skills/、~/.agents/skills/、および~/.cursor/skills/からスキルを読み込みます。.agents/のパスは同一であり、どちらもSKILL.mdを含むフォルダを使用し、同じオープンスタンダードを採用しています。スキルが.agents/skills/にある場合、リポジトリを開いた瞬間にCursorで動作します。
Cursorは互換性をさらに高めており、「ClaudeおよびCodexのディレクトリ（.claude/skills/、.codex/skills/、~/.claude/skills/、~/.codex/skills/）からもスキルを読み込みます。」
指示の内容 — どのファイルに記述されていたかを特定した上で移行します。 テキスト自体はそのまま移行できます。ただし、どのファイルに記述されていたかと、Zedが実際にどのファイルを読み込んでいたかは別問題です。
個人の指示 — User Rulesとして移行。 Zedの個人用指示ファイルは~/.config/zed/AGENTS.md（Windowsでは%APPDATA%\Zed\配下）にあります。Cursorにおけるこれに相当する機能は、User Rules（「Cursor環境全体にグローバルに適用」）です。
移行できないもの：「最初に一致したものが優先される」仕組み。 Zedは1つのファイルを選択します。一方、CursorのProject Rulesは条件付きです。各.mdcファイルは、フロントマターを通じて独自の読み込み挙動を決定します。これにより、より高度な制御が可能になりますが、その分正しく設定する必要があります。
こちらも移行できません：外部エージェントに関する前提。 ZedはACPを介して外部エージェント（Claude、Codex、OpenCode, Copilot、Cursorなど）を実行し、CLIを直接実行するTerminal Threadsもサポートしています。Zedのドキュメントには慎重にこう書かれています。「外部エージェントやTerminal Threadsは、独自のネイティブな指示ファイルを直接読み込む場合があります。Zedの指示ローダーがそれらのエージェントを制御していると仮定しないでください。」もしZedのセットアップが外部エージェントに依存していた場合、コンテキストの挙動の一部は、最初からZedの管理下にはなかったことになります。
そして率直な事実として、どちらのツールもメモリー層をドキュメント化していません。 Zedのドキュメントインデックスにはメモリーに関するページはなく、Cursorにもありません。どちらも設計上、指示とスキルを提供するツールであり、Cursorはその前提を直接述べています。「大規模言語モデルは、補完の間に記憶（メモリー）を保持しません。ルールは、プロンプトレベルで永続的かつ再利用可能なコンテキストを提供します。」これはルールが何であるかを正確に説明しており、何ではないかを明確に示しています。この移行によってそれが変わることはありません。あなたは、継続性をユーザー自身が提供することを前提とした2つのツールの間を移動しているに過ぎないのです。
手動での移行手順
ステップ 1: Zedが実際に読み込んでいたファイルを特定する
リストを順番に確認します（.rules、.cursorrules、.windsurfrules、.clinerules、.github/copilot-instructions.md、AGENT.md、AGENTS.md、CLAUDE.md、GEMINI.md）。そして、リポジトリに存在する最初のファイルで立ち止まってください。それが、実際に機能していたプロジェクト指示ファイルです。それより下にあるファイルはすべて機能していませんでした。
よくある結果として以下の2つがあり、移行前に把握しておく価値があります。
古いレガシーファイルが優先されている。 以前のツールが残した.cursorrulesや.windsurfrulesが、AGENTS.mdよりも優先されています。この移行における皮肉な点として、.cursorrulesは現在のCursorのドキュメントには一切記載されていません。現在のCursorの4つのルールタイプは、.cursor/rules内のProject Rules、User Rules、Team Rules、およびAGENTS.mdです。古い.cursorrulesがZedを制御していた一方で、Cursor自体はすでにそのファイルから移行しているのです。
メンテナンスしていたファイルが読み込まれていなかった。 もしAGENTS.mdが最初のマッチでなかった場合、適用されていると思っていたルールは適用されていませんでした。優先されていたファイルを読み直してください。あなたが動作していると思い込んでいたことの一部は、一度もテストされていなかった可能性があります。
また、個人用とプロジェクト用の優先順位も確認してください。「プロジェクトの指示は、競合する場合、個人用のAGENTS.mdを上書きします。」あるリポジトリでは予期しない挙動が発生し、別のリポジトリでは発生しなかった場合、通常はこれが原因です。
用語に関する注意点として、名前が変更されたものを探してしまわないようにしてください。Zedのドキュメントには「ルールはスキルと指示（Instructions）に置き換えられました」と記載されており、再利用可能なオンデマンドのルールは「スキル」に、常にオンのルールは個人用のAGENTS.mdになり、プロジェクトの.rulesファイルは互換性のために維持されています。古いZedのガイドを参考にしていた場合、これらの概念は異なる名前で存在しています。
ステップ 2: 常にオンのファイルを、適切なタイミングで読み込まれるルールとして再構築する
CursorのProject Rulesは、.cursor/rules内に.mdcファイルとして保存されます。この拡張子は必須です。ドキュメントには明記されています。「プロジェクトルールは.mdc拡張子を使用する必要があります。.cursor/rules内のプレーンな.mdファイルは、description、globs、およびalwaysApplyを指定するフロントマターがないため、ルールシステムによって無視されます。プレーンなMarkdownを好む場合は、代わりにAGENTS.mdを使用してください。」
そのため、2つの移行先オプションがあり、最もシンプルな方法が正しい場合が多いです。もしZedの指示が常にオンの1つのファイルであり、それを維持したい場合は、それらをAGENTS.mdに配置します。Cursorのドキュメントでは、これを「.cursor/rulesに代わるシンプルな選択肢」として紹介しています。これで完了です。
Zedではできなかった条件付きの読み込みを行いたい場合は、代わりにルールを変換します。Cursorの4つのルールタイプは、多くの人のAGENTS.mdが肥大化していく中で作成されるセクションと綺麗に対応しています。
| Zedでの役割 | Cursorのルールタイプ | フロントマター |
|---|---|---|
| 常にオンのリポジトリ規約 | Always Apply | alwaysApply: true |
| コードベースの特定領域向けガイドライン | Apply to Specific Files | globs: src/components/**/*.tsx, alwaysApply: false |
| エージェントが判断すべき状況に応じたガイドライン | Apply Intelligently | description: …, alwaysApply: false |
| 手動で呼び出すもの | Apply Manually | description も globs もなし |
この相互作用はドキュメントに表として記載されており、その記述通りに動作します。alwaysApply: trueは、globsとdescriptionが無視されることを意味します。alwaysApply: falseでglobsが指定されている場合、一致するファイルがコンテキスト内にあるときに自動的に適用されます。falseでdescriptionが指定されている場合、関連性があるときにエージェントがそれを引き込みます。そして、どちらも指定されていないfalseの場合、ルールはあなたが@でメンションしたときにのみ読み込まれます。
Apply Intelligentlyタイプは、慎重に記述する必要があります。descriptionはエージェントが関連性を判断するために読み込むものであるため、「バックエンド用のRPCサービス規約とパターン」といった記述は有効ですが、「その他のルール」といった記述は役に立ちません。
実用的なヒント：Agentで/create-ruleを実行すると、正しいフロントマターを持つファイルが生成されます。これが、.mdの罠を完全に回避する最も手っ取り早い方法です。ルールは.cursor/rules内のフォルダに整理できます。入れ子になった.cursor/skills/ディレクトリは、そのディレクトリ内のファイルに自動的にスコープされるため、モノレポではスキルをそれが属するパッケージと同じ場所に配置できます。また、Cursorのクラウドやリモート実行を使用する場合の注意点として、Cursorは「ローカルの~/.cursor/skills/および~/.agents/skills/フォルダをCloud Agents、リモートSSHセッション、またはセルフマネージドワーカーにコピーしません」。リポジトリ内のプロジェクトスキルは移行されますが、個人用のスキルは移行されません。
これでファイルの移行は完了です。しかし、ファイルに一度も記述されなかったものは移行されていません。
より良い方法：どちらのツールも提供していない「推論」の置き場所を作る
どちらのツールも指示をうまく処理しますが、それ以上の機能は謳っていません。Cursor自身の表現が最も率直です。ルールは「プロンプトレベルで永続的かつ再利用可能なコンテキストを提供」し、ルールの内容は「モデルコンテキストの最初に含まれます」。
関連するすべてのリクエストにおいて、コンテキストの最初に含まれます。この制約こそが、特定のカテゴリーの知識をルールファイルに保存すべきではない理由です。なぜその規約が存在するのか、すでに試して却下したアプローチは何か、明らかな解決策が誤りである理由となる制約、近道を説明する締め切りなど、これらはどれも「指示」ではありません。これらをAGENTS.mdに記述するとファイルが長くなるだけで、エージェントの遵守率が上がるわけではありません。自分がメンテナンスしていたファイルが読み込まれてさえいなかったことを発見したばかりの移行作業の後では、指示ファイルを短くすることの魅力は明らかでしょう。
それこそが、MemoryLakeが保持するものです。プロジェクトの永続的な知識をツールがクエリできるレイヤーに保持するため、ルールは短く保たれ、今年どのエディタを使っていても推論を利用可能な状態に維持できます。セットアップは3つのステップです。
ステップ 1: APIキーを作成する
サインインしてAPIキーを作成します。接続するツール間で共通の1つの認証情報です。
ステップ 2: 最初のメモリーをアップロードする
1つの項目につき1つの主張を含む、短いエントリを作成します。最適なソースは、これから長くしようとしていた指示ファイルです。
すべてのルールの理由。 「レビューツールが大きな差分を切り捨てるため、コンポーネントは200行未満に抑える。」ルール自体は.mdcファイルに記述し、その理由はここに保存します。これにより、次の四半期にルールが誤って削除されるのを防ぐことができます。
このリポジトリで既に却下されたアプローチ。 ルールファイルにもコミットメッセージにも現れず、新しいセッションのたびに再提案されてしまうカテゴリーです。
誰も教えてくれない環境に関する事実。 ドキュメント化されていないレート制限、2つのジョブ間の順序依存関係、CIでのみ失敗するテストなどです。
移行によって学んだこと。 もし古い.cursorrulesがAGENTS.mdより優先されていたなら、その結果として実際には一度も適用されていなかった規約を書き留めておきます。これはコードベースに関する事実であり、ルールではありません。
ステップ 3: AIとエージェントを接続する
使用しているツールを接続します。MemoryLakeはMCPおよびAPI経由でアクセス可能であり、ZedとCursorの両方がMCPサーバーをサポートしています。これは、完全に移行しきれていない重複期間に便利です。Claude Code、Codex、OpenClawなどのMCPネイティブなエージェントは同じメモリーを読み込み、それ以外のツールはAPIを介してアクセスします。
3つの率直な制限事項。MemoryLakeは、.mdcファイル、AGENTS.md、またはUser Rulesを書き換えません。 これらはCursorを制御するためのものであり、上記の読み込み挙動はCursorの仕様です。MemoryLakeは、あなたやエージェントが入力した内容のみを保持するため、ステップ2の作業は意図的に行う必要があります。また、ルールは強制される設定ではなくコンテキストです。常に必ず維持されるべきルールは、Markdownの記述ではなく、CIでのチェックが必要です。
実務における変化
実際に何が読み込まれていたかが分かります。 「最初に一致したものが優先される」ため、編集していたファイルが適用されていなかったケースが多々あります。
スキルの移行コストはゼロです。 どちらのツールも.agents/skills/を読み込みます。
読み込みが「全か無か」ではなく、条件付きになります。 1つの常にオンのファイルが、4つのルールタイプに置き換わります。
.mdの罠に悩まされることがなくなります。 .cursor/rules内で拡張子が間違っていると、ファイルが存在しないものとして扱われます。
指示ファイルが短くなります。 推論が外部に移動するため、残るのは純粋な指示だけになります。
次のエディタへの乗り換えコストが下がります。 永続的な知識が、特定のツールの設定ディレクトリ内に閉じ込められなくなります。
ZedからCursorへ移行するためのベストプラクティス
何かをコピーする前に、優先されているファイルを特定する。 Zedは9つのファイルのリストから最初に一致したものを読み込みます。
古いレガシーなルールファイルは、内容を確認した後に削除する。 残された.cursorrulesは、ZedではAGENTS.mdより優先され、現在のCursorではドキュメント化されていません。
.mdcのフロントマターを手書きするのではなく、/create-ruleを使用する。 これにより有効なフロントマターが生成され、最も一般的な失敗を回避できます。
プレーンなMarkdownを使用したい場合は、AGENTS.mdを使用する。 Cursorはこれをシンプルな代替手段としてドキュメント化しています。.cursor/rulesと無理に戦う必要はありません。
Apply Intelligentlyルールには、具体的な説明（description）を記述する。 説明は、エージェントが関連性を判断するために読み込む内容です。
1つの巨大な常にオンのファイルにするのではなく、globsでスコープを制限する。 すべてのリクエストですべてを読み込むことが、Zedのファイルを扱いにくくしていた原因です。
Cloud Agentsを使用する場合は、個人用スキルをリポジトリ内に保持する。 ローカルの~/.agents/skills/はリモート実行環境にコピーされません。
どちらのツールも記憶（メモリー）を保持していると期待しない。 どちらもメモリー層をドキュメント化していません。一般的な仕組みについては、コーディングエージェントが実際に読み込んでいるものを参照してください。
結論
この移行は他の多くの移行よりも簡単ですが、1つだけ本当に驚くべき点があります。簡単な部分はスキルです。ZedとCursorはどちらも.agents/skills/および~/.agents/skills/から読み込み、どちらもSKILL.mdを含むフォルダを使用するため、変換は不要です。驚くべき点は移行元にあります。Zedは9つのリストから最初に一致したファイルを読み込むため、エージェントを制御していた指示ファイルは、あなたがメンテナンスしていたファイルではない可能性があり、AGENTS.mdはその優先順位の7番目に位置しています。
どのファイルが優先されていたかを特定し、内容をよく確認した上で、どのように移行するかを決定してください。常にオンのファイルであれば、AGENTS.mdに配置するだけで完了です。条件付きの読み込みを行いたい場合は、.cursor/rulesに変換します。その際、そのディレクトリ内のプレーンな.mdは無視されること、そして/create-ruleが有効なフロントマターを自動生成してくれることを忘れないでください。
どちらのツールも提供していないのは、推論の置き場所です。Cursorははっきりと述べています。ルールはプロンプトレベルで再利用可能なコンテキストを提供し、モデルコンテキストの最初に読み込まれます。これは指示ファイルの説明としては正しいですが、決定事項、却下されたアプローチ、制約事項を保存する場所としては不適切である理由でもあります。指示を適切なルールタイプに移動して短く保ち、推論は次のエディタでも読み込める場所に保存しましょう。Cursor側でこれが具体的にどのように機能するかについては、セッション間でCursorのコンテキストを引き継ぐ方法で解説しています。