実際に移行できるもの
エディタレベルの設定は自動的に移行されます。 両者とも VS Code のフォークであるため、拡張機能、テーマ、キーバインド、設定は最小限の手間で引き継がれます。これが移行を簡単だと錯覚させ、そうではない部分を見えにくくしている要因です。
ルールはテキストとして移行されますが、動作（挙動）は移行されません。 コミュニティのドキュメントによると、Windsurf は2つのルールシステムを併用しています。プロジェクトルートにあるレガシーな .windsurfrules ファイルと、.windsurf/rules/ 配下にある新しいスコープ付きの Markdown ファイルで、合計の文字数制限は約12,000文字とされています。一方、Cursor のモデルは本質的に異なります。プロジェクトルールはバージョン管理下の .cursor/rules に .mdc ファイルとして保存され、3つのフロントマターフィールド（alwaysApply、description、globs）によって、それぞれがいつコンテキスト（context）に読み込まれるかが決定されます。
つまり、コピーによってコンテンツは残りますが、「有効化（activation）」の仕組みが失われるため、コピーしたルールセットが動作しているように見えて、実際には静かに無視されるという現象が起こります。
Cascade の記憶（memories）は一切移行されません。 これらは自動生成され、作成されたマシン上にローカルに保存され、チームメンバーと共有されることもなく、エクスポート方法もありません。これが移行において何を意味するかに注意してください。それらは実際に役立つ仕事をこなしてくれていましたが、移行において明確な「期限」がある唯一の要素です。これらを抽出する唯一の方法は、古いアシスタントがまだ動作しているうちに、それが何を知っているかを直接尋ねることです。
明文化していなかったことも移行されません。 特定のディレクトリがアクセス禁止である理由、デプロイの順序、クライアントの制約など、ルールファイルにも書かれず、Cascade の記憶にも読み取れる形で残っていなかった情報は、あなたの頭の中か、それを覚えているチームメンバーの頭の中にしか存在しません。
移行後に Cursor が提供するのは、以前よりも構造化された仕組みです。 ドキュメントによると、Cursor には4つのルールタイプがあります。.cursor/rules 内のプロジェクトルール（バージョン管理可能、リポジトリスコープ）、Cursor 環境全体に適用されるユーザールール、Team および Enterprise プランのダッシュボードで管理されるチームルール、そして .cursor/rules のプレーン Markdown 代替案としての AGENTS.md です。Cursor はその仕組みを明確に説明しています。「大規模言語モデルは、補完（completion）間で記憶を保持しません。ルールは、プロンプトレベルで永続的かつ再利用可能なコンテキストを提供します。」ルールはモデルのコンテキストの先頭に追加されます。これらは記憶（memory）ではなく、Cursor もそうとは主張していません。
手動での移行手順
ステップ 1: アンインストールする前に Cascade に尋問する
何よりも先に、古いエディタがまだ開くうちにこれを行ってください。Cascade を開き、このプロジェクトについて学んだこと（コーディング規約、注意点、意思決定、あなたの働き方について覚えていることなど）を自然な言葉で尋ねます。異なる角度から繰り返し質問し、その回答を一時ファイルに貼り付けておきます。次に、このコードベースで「すべきではない」と判断していることは何かを尋ねます。これにより、肯定的な質問とは異なる角度の記憶を引き出すことができます。
これは移行作業において、唯一の「後戻りできない」時間です。ルールファイルはディスク上にあるため来週でも残っていますが、Cascade の記憶はエクスポート機能のないマシンローカルな生成ステートであり、エディタを削除すると同時に消え去ってしまいます。
古いプロジェクトを開いている間に、以下のファイルも整理しておきましょう。
- プロジェクトルートにある
.windsurfrules（まだ存在する場合） .windsurf/rules/配下のすべてのファイル- 設定したワークフローやツール定義
- MCP サーバーの設定（これは変換するのではなく、再追加します）
次に、ルールをその出自ごとに3つのグループに分類します。「リポジトリから派生したもの（README にも書いてあるため削除）」、「自分で書き、今も有効なもの（これが移行対象）」、「自分で書いたがすでに不要になったもの（どれがどれか覚えているうちに、今すぐ意図的に削除）」。移行は、すべてのルールを新鮮な目で見直す絶好の機会です。この時間を有意義に使いましょう。
ステップ 2: 各ルールを適切な有効化モードで再定義する
ここからは、1つずつルールを変換し、意図的にタイプを選択していきます。Cursor の4つのモードは、それぞれ異なるコスト（コンテキスト消費）に対応しています。
- Always Apply（常に適用） (
alwaysApply: true) — すべてのチャットセッションに含まれ、globs や description は無視されます。これを適用するのは、回答が「誤り」になるのを防ぐためのごく一部のルールに限定してください（例：著作権ヘッダー、"決してdist/内の生成されたファイルを編集しないこと"、厳格なアーキテクチャ上の制約など）。 - Apply to Specific Files（特定のファイルに適用） (
globsを設定、alwaysApply: false) — 一致するファイルがコンテキストにある場合に自動的に適用されます。Windsurf のスコープ付きルールのほとんどはここに該当します。globs: src/components/**/*.tsxと指定することで、「フロントエンドのルール」を単なる期待ではなく、パターンとして厳密に表現できます。 - Apply Intelligently（インテリジェントに適用） (
descriptionを設定、globs なし) — エージェントが説明（description）を読み、関連性があると判断したときにルールを取り込みます。特定のパスにマッピングできないドメインルールに有用ですが、その効果はあなたが書く説明の質に依存します。 - Apply Manually（手動で適用） (description なし、globs なし) —
@my-ruleのように、@-メンションしたときのみ含まれます。毎回の補完には不要で、必要なときだけ呼び出したい長いチェックリストなどに最適です。
この作業を行う際に避けるべき3つの技術的な罠：
拡張子が重要です。 プロジェクトルールは .mdc を使用する必要があります。Cursor のドキュメントには、.cursor/rules 内の通常の .md ファイルはフロントマターフィールドがないため、ルールシステムによって無視されると記載されています。プレーンな Markdown を好む場合、ドキュメント化されているパスはルールフォルダ内の .md ファイルではなく、AGENTS.md です。
すべてを「Always Apply」にしないでください。 It's the fastest way to make the migration "work" and the surest way to make it useless: すべての補完にすべてのルールを含めると、本当に重要なルールが薄れてしまいます。また、Cursor のガイドラインでは、ルールを500行未満に抑えることが推奨されています。もし Windsurf の設定で文字数制限に悩まされていたなら、その制限は選択を強制することであなたを助けてくれていたのです。Cursor ではそれを強制する制限はありません。
共有スタンダードはチームメンバーがアクセスできる場所に配置してください。 プロジェクトルールはバージョン管理されるため、コミットすることでチームがあなたの成果を引き継ぐことができます。On Team and Enterprise plans, team rules in the dashboard are the layer above that. 個人の開発習慣はリポジトリではなく、ユーザールールに設定してください。
最後に、ステップ1で回収した Cascade の知識を意図的に配置します。その大部分はルールの形をしていません。それらはコンテキスト、歴史、そして推論です。一部はルールになり、残りはリポジトリのドキュメントや、アシスタントが読み取れるストア（次のセクションで説明します）に保管すべきです。
より良い方法：エディタに依存しない単一のメモリレイヤー
あなたが今行った作業を振り返ってみてください。あるベンダーのルールフォーマットを別のベンダーのルールフォーマットに変換し、チャットウィンドウから手動で記憶をコピーしました。他に方法がなかったからです。もし来年 Cursor が別のサービスに取って代わられたら（あなたがこの記事を読んでいるのも、まさに前回の移行が原因でしょう）、また同じことを繰り返すことになります。
永続的な切り分けはこうです。ルールはリポジトリに残します。コーディングエージェントが目の前で必要とするものだからです。そして、ルールの背景にある知識は、どちらのエディタにも所有されない場所に保管します。
MemoryLake はそのためのメモリ（memory）レイヤーです。意思決定、インシデントの記録、ルールの元となったソースドキュメントを1つのストアに集約し、Claude や Codex などの MCP 対応ツールから直接、また API を通じて ChatGPT から読み取ることができます。.mdc ファイルは「何をすべきか」を示し、ストアは「なぜか」を示し、エディタの寿命を超えて存続します。
ステップ 1: API キーを作成する
キーを生成し、約30秒で最初のリクエストを送信できます。チャットウィンドウに貼り付けるのではなく、環境変数やシークレットマネージャーに保管してください。
ステップ 2: 最初の記憶をアップロードする
先ほど変換したルールの背景にあるドキュメント、画像、ファイルをドロップします。モジュールへのアクセスを禁止にしたインシデントの記録、アーキテクチャの決定とその日付、クライアントの要件、API 契約、そして回収した Cascade の知識などです。整理された要約ではなく、ソース自体をアップロードしてください。要約こそ、ステップ1で再構築しようと苦労した対象だからです。
ステップ 3: AI とエージェントを接続する
Claude、Codex、OpenClaw、その他の AI エージェントに、MCP または API 経由でメモリへのアクセス権を付与します。MCP 対応ツールは、独自のルールファイルと並行して、同じストアを直接読み取ります。ChatGPT の場合は、API を通じて必要な情報を取得し、プロンプトやモデルを呼び出すワークフローに注入します。
実務における変化
第一の違いは、Always Apply（常に適用）のルールセットを小さく維持できる点です。すべてをロードしなければならないというプレッシャーは、他に保管場所がないことから生じます。詳細情報が検索可能であれば、常にロードしておくルールは、実際に回答を左右する3つの制約だけで済みます。
第二に、理由がルールに付随するようになります。「generated/ 内のファイルを編集しないこと」というルールは、新しいエンジニアや新しいエージェントが加わるたびに疑問視されます。しかし、同じルールにチケットやインシデントの記録が紐づいていれば、疑問は生じません。これこそが、単なる慣習と存続するアーキテクチャ上の決定の違いです。
第三に、情報の回収が一度限りのコストになります。あなたは Cascade のためにそれを行いました。しかし、Cursor のためにそれを行う必要はありません。知識が Cursor の中に閉じ込められることはないからです。これは、情報があなたのノートPCの中だけに留まるのではなく、チームメンバーが尋ねたときにも利用可能であることを意味します。これは、マシン間で引き継がれないルールの背後にある課題と同じです。
そして、これは Cursor がネイティブに行うことと調和します。ルールはドキュメント通り、プロンプトレベルでその役割を果たし続けます。そしてストアは、ルールが本来保持すべきではないもの（歴史、根拠、およびドキュメント自体）を保持します。
サポートが終了したエディタから移行する際のベストプラクティス
アプリ内に存在するものはエクスポートできないと想定する
ルールファイルはあなたのものです。しかし、どのツールであれ、自動生成された記憶（memories）は通常そうではありません。アンインストールする前に、アシスタントが知っていることを尋ね、その回答をコピーしておきましょう。UI 上にしか存在しないものはすべて、いつか消えるものとして扱ってください。
テキストだけでなく、スコープも変換する
この移行において最も価値の高い作業は、「これらはフロントエンドのルールです」という記述を globs: src/components/**/*.tsx に変換することです。パススコープのルールは、関連性があるときだけロードされ、そうでないときはコンテキストから除外されます。これは、モデルが修飾語に気づいてくれることを期待するルールよりも、コストが安く、かつ正確です。
ルールをコミットし、標準化にはチームレイヤーを使用する
バージョン管理されたルールはレビュー可能で引き継ぎ可能ですが、個人の設定にあるルールはそうではありません。Team または Enterprise プランでは、組織全体の標準をチームルールに設定し、各開発者のローカル環境に依存しないようにしてください。
移行時に削除する
移行時に引き継いだ古いルールは、それが古いことを知る由もないエージェントによって、静かに実行され続けます。まだ必要だったルールを削除してしまった場合のコストは、1分で書き直すことだけです。しかし、誤ったルールを保持し続けた場合のコストは、1週間に及ぶ混乱を招く差分（diff）の修正です。
ルールを強制手段として扱わない
Cursor は、ルールがプロンプトレベルでコンテキストを提供するものであると明確に述べています。それは影響を与えるものであり、保証するものではありません。フォーマット、main ブランチへの直接プッシュの禁止、生成されたファイルの不変更など、常に真であるべきルールは、フォーマッタ、フック、または CI に属するべきです。ルールは説明し、ツールが強制します。
結論
Windsurf から Cursor への移行はファイルのコピーのように見えますが、実際は異なります。両方のエディタは VS Code のフォークであるため、エディタレイヤーは自動的に移行されますが、重要な部分（各ルールがいつ適用されるか）は Cursor の仕様に合わせて再構築する必要があります。つまり、フロントマターで Always Apply、ファイルパターン、エージェント選択、または手動を選択する .mdc ファイルにする必要があります。通常の .md ファイルを .cursor/rules にコピーしても、エラーが表示されることなく完全に無視されます。
したがって、2つの作業を正しい順序で行ってください。アンインストールする前に Cascade に尋問してください。自動生成されたローカルの記憶にはエクスポート機能がなく、二度と取り戻せないからです。次に、各ルールを適切な有効化モードで再定義し、古いものを削除し、チームに必要なものをコミットし、それらのルールの背景にある理由をエディタの外部にあるストアに保管します。次に IDE を乗り換えるとき、そのストアのおかげで、作業は1週間ではなく半日で済むようになるでしょう。