実際に移行できるもの
指示ファイル（スムーズに移行可能）
Copilot の永続的な設定は、.github/copilot-instructions.md と、これまでに蓄積されたスコープ付きの指示ファイルやプロンプトファイルです。Cursor はこれに相当する2つの要素を読み込みます：
- プロジェクトルール：
.cursor/rules内の.mdcファイルとしてリポジトリでバージョン管理されます。それぞれに適用モードが設定できます：Always Apply（常に適用）、Apply Intelligently（エージェントが説明に基づいて判断）、Apply to Specific Files（グロブパターン一致）、または Apply Manually（@-メンションで呼び出し）。 - AGENTS.md：プロジェクトのルートまたはサブディレクトリに配置するプレーンな Markdown ファイルで、フロントマターは不要です。今日すぐにコンテンツを移植するのに最も手軽な場所です。
また、Cursor の「Customize」設定で指定するグローバルな設定である User Rules もあります。これはエージェントチャットのプロジェクト横断で適用されます。個人の好みはここに、プロジェクトの事実はリポジトリに分けて管理することで、チームメンバーが不要な個人設定を引き継ぐのを防げます。
移行できないもの
Copilot のチャット履歴を Cursor にエクスポートする経路はなく、生のログをそのまま移行しても適切な形にはなりません。チャット内の価値あるコンテンツとは、あなたが提供した「理由」です。なぜ決済モジュールが重複書き込みを許容するのか、どのテストスイートが不正確なのか、3月に認証の切り出しを試みて断念したことなどです。基礎となるコンテキストが実際どれほど薄かったかという仕組みについては、GitHub Copilot がコードベースのコンテキストを忘れてしまう理由 で解説しています。
Cursor もセッション間で忘却する
ルールはプロンプトごとに注入されます。セッションをまたいで自動的に蓄積されるものは何もありません。新しいチャットは新しいコンテキストから始まります。これが、Cursor ユーザーも反対側から同じ壁にぶつかる理由であり、Cursor が以前のセッションを忘れてしまう理由、プロジェクトルール、および アーキテクチャの決定事項 で詳しく説明されています。エディタを切り替えても、問題へのアプローチが変わるだけで、問題そのものが解決するわけではありません。
手動での移行手順
ステップ 1: 指示を Cursor のフォーマットに移植する
まず、Copilot の指示を次の2つのグループに分けることから始めましょう。これらはほぼ確実に混ざり合っているはずです：
- 行動に関する指示 — 命名規則、フォーマット、エラーハンドリング、レビューの基準、絶対に触れてはならないファイルなど。これらは「ルール」に分類されます。
- プロジェクトの事実 — サービスの境界、データモデル、非推奨事項、決定事項とその理由。これらは「知識」であり、時間とともに増加します。
次に、行動に関する指示を配置します。そのまま移植する場合は、AGENTS.md に貼り付けるだけでその日のうちに使い始めることができます。長期的にメンテナンスする場合は、.cursor/rules 内に .mdc ルールを作成し、適切なモードを慎重に選択してください。絶対に譲れない数少ないルールには Always Apply、特定の言語やディレクトリに関するものには Apply to Specific Files、明確な説明を伴うドメインガイドには Apply Intelligently、オンデマンドで呼び出したいチェックリストには Apply Manually を選択します。
すべてを Always Apply に設定したくなる衝動を抑えてください。そうしないと、わずか2行の指示しか必要としないコード生成であっても、毎回 3,000 トークンのルールファイルを読み込むコストを支払うことになります。
ステップ 2: チャットにしか存在しなかった知識を再構築する
過去2週間の Copilot のチャット履歴を開き、2回以上説明したことをすべて書き出してください。繰り返しは監査のようなものです。何度も再入力していたことこそ、どこにも保存されていなかった情報です。
それらを、日付と理由を添えた短いエントリとして書き留めます。「決済ウェブフックのべき等性キー — プロバイダーが再試行し、ステージング環境で二重課金が発生、2026-05」といった具合です。このようなエントリが10個あるだけで、1,000語の散文よりも価値があり、Cursor がチームがすでに却下した提案をしてくるのを防ぐことができます。
より良い方法：エディタに依存しない単一のメモリレイヤー
ここで注目すべきパターンがあります。ルールが移行を生き延びたのは、それがリポジトリ内のファイルだったからです。一方で、知識が失われたのは、あなたが離れたツールの中に存在していたからです。解決策は、ルールファイルを肥大化させることではなく、プロジェクトの知識をエディタの完全に外側に保持することです。
MemoryLake はまさにその役割を担います。アーキテクチャ、決定事項、インシデント履歴を1つのメモリレイヤーに集約し、Cursor から MCP 経由で読み込むことができます。また、次の四半期に評価するかもしれない他のツールからも同様に読み込めます。
ステップ 1: API キーを作成する
キーを生成すれば、約30秒で最初のリクエストを実行できます。
ステップ 2: 最初のメモリをアップロードする
プロジェクトの真のコンテキストを保持するドキュメント、画像、ファイルを投入します。先ほど作成したルール、ADR、アーキテクチャノート、ランブック、ポストモーテム、API 仕様書などです。
ステップ 3: AI とエージェントを接続する
Claude、Codex、OpenClaw、およびその他のエージェントに、MCP または API 経由でそのメモリへのアクセスを許可し、他の MCP サーバーとともに Cursor に追加します。ルールはエージェントが「どのように」振る舞うべきかを処理し、メモリは「システムについて何が真実であるか」を処理します。関連する移行パス：Cursor から Claude Code への移行 および Copilot から Claude Code への移行。
移行にかかるコストと、それによって節約できるもの
各部分のコストを見積もってみましょう。Cursor のインストールと指示ファイルの移植：1時間。すべてを Always-Apply にするのではなく、賢明なルールモードを選択する作業：もう1時間（これは1週間以内にトークン消費量の削減として元が取れます）。暗黙知の再構築：半日（ここだけが、将来にわたって効果が複利で積み重なる部分です）。
次に、継続的に発生するコストです。もしプロジェクトの常時コンテキストが 2,000 トークンあり、それがチャットやエージェント全体で1日に20回再提示されるとすると、月に約 1.2M トークンの重複が発生し、さらにセッションごとに4〜5分の再説明の時間が失われます。巨大な Always-Apply ルールファイルは、このコストを排除するのではなく、それを「無条件に発生するもの」にしてしまいます。
本当の節約は「選択肢（オプショナリティ）」にあります。現在、新しいエディタを評価することは、コンテキスト再構築のコストを再び支払うことを意味するため、チームはすでに使い古したツールに留まりがちです。メモリが外部化されていれば、次のツールを試すコストは半日で済み、それを諦めるコストはゼロになります。
移行のベストプラクティス
初日からルールと知識を分離する
ルールは指示であり、規模が小さく、常に価値を持ちます。知識はシステムに関する事実であり、規模が大きく、状況に応じて選択的に価値を持ちます。これらを分離しておくことで、ルールファイルが誰も信頼しない「テキストの壁」に肥大化するのを防ぐことができます。
ルールモードを形式的なものではなく「予算」として捉える
Always Apply は、すべてのコード生成においてコストが発生します。これを適用するのは、常に真実である少数の事柄に限定し、残りはグロブパターンや説明文に任せましょう。これは、コストを劇的に変化させる Cursor 特有の習慣です。
思い出したときではなく、学んだその瞬間にメモリに書き込む
事実を保存する最適なタイミングは、エージェントにそれを説明した直後です。その瞬間に保存しておけば、次のセッション（Cursor、Claude Code、あるいは次に登場するツール）は、最初の推測からではなく、あなたの結論から開始することができます。
結論
Copilot から Cursor への移行は、表面上は非常に簡単ですが、本質的には「知識の移行」です。指示ファイルは .cursor/rules や AGENTS.md にきれいに移植でき、ルールモードによって何がいつ読み込まれるかを細かく制御できます。また、User Rules を使えば、個人の好みがチームメンバーの邪魔になることもありません。
移植できないのは、チャットで提供してきた数ヶ月分のコンテキストです。Cursor のドキュメントにも明記されている通り、ルールはプロンプトレベルのコンテキストであり、メモリではありません。この知識を一度再構築してエディタの外に保存しておけば、次の移行は接続先を変更するだけで済み、自社のコードベースを再び1ヶ月かけて説明し直す必要はなくなります。