実際に移行されるもの
Warpは、多くの移行ガイドが隠したがる一文から始まります。「WarpにはワンクリックのCursorインポーターはありません。」
その理由は技術的に正しく、明確です。「CursorはVS Codeのコードベースを基に構築されているため、ターミナル設定はsettings.json内のterminal.integrated.fontFamilyやterminal.integrated.defaultProfile.*といったキーの下に存在します。このファイルは読み取り可能であるため、WarpのAgentは一致するターミナルの値をWarpのsettings.tomlに変換できます。」
つまり、自動化は確かに存在しますが、それは外観の設定に限定されています。エージェント機能に関しては、ページでも同様に率直に述べられています。「CursorのComposerおよびAgent機能には1対1の移行パスはありません。これらはWarpの異なるコンセプトにマッピングされます。」
以下は、Warp自身の対応表から作成した、重要なマッピングです。
| Cursorから | Warpでは |
|---|---|
| Composer / Agentパネル | 任意のタブでのAgent Mode |
| Agentタブ | タブ間で並行して動作する複数のエージェント |
.cursorrules | プロジェクトルートのAGENTS.md / WARP.md（ルールとして検出） |
| MCPサーバー | MCP |
| 会話ごとのモデル選択 | モデルセレクター |
| コードベースのインデックス作成 | Codebase Context |
| インライン差分レビュー | Code Review |
注目すべきは.cursorrulesの行です。Warpの指示は驚くほど単刀直入です。「Agent Modeで/initを実行してAGENTS.mdを生成するか、.cursorrulesの内容を直接コピーしてください。」
これはCursorの4つの指示スコープのうちの1つをカバーしています。Cursorのドキュメントには、.cursor/rules内の「プロジェクトルール」、Cursor環境全体に適用される「ユーザールール（グローバル）」、TeamおよびEnterpriseプランで「ダッシュボードから管理される」「チームルール」、そして.cursor/rulesの「シンプルな代替手段」としてのAGENTS.mdがリストされています。
一方、Warpには「グローバルルール」と「プロジェクトルール」の2つのスコープしかありません。そのため、マッピングは特定の方向で情報が失われます。ダッシュボードで一元管理されるCursorの「チームルール」には、Warp側で対応する機能がありません。これらは、各個人のマシンのグローバルルールにするか、リポジトリにコミットされたAGENTS.mdにするかのどちらかになり、自動的に同期が保たれるのは後者のみです。
期待しすぎる前に、もう一つ述べておくべきことがあります。Warpには確かに永続的なメモリシステムである「Agent Memory」が存在し、これは真にクロスハーネス（複数の環境をまたぐ）です。ドキュメントでは、メモリは「組み込みのWarp Agent、Claude Code、Codex、および今後追加されるその他のサポート対象エージェントハーネスすべてで共有される」と説明されています。しかし、利用可能性については明確に「Agent Memoryはリサーチプレビュー段階であり、デザインパートナーのチームごとに有効化されています」と書かれており、アクセス申請のためのウェイトリストが用意されています。もしあなたのチームがデザインパートナーでない場合は、この機能はまだ利用できないものとして移行を計画してください。
手動での移行
ステップは2つです。最初のステップでは、Cursorが実際にエージェントに提供していた情報を整理し、2番目のステップでそれをWarpが読み取れる場所に配置します。
Step 1: 覚えているものだけでなく、Cursorの4つのスコープすべてを整理する
Cursor의 ドキュメントでは、ルールを永続化メカニズムそのものとして位置づけています。「大規模言語モデルは、補完の間にメモリを保持しません。ルールは、プロンプトレベルで永続的かつ再利用可能なコンテキストを提供します。」つまり、ルールファイルこそがあなたのコンテキストであり、そのすべてが必要になります。
各スコープを開き、内容をコピーしてください。
- プロジェクトルール:
.cursor/rules内の.mdcファイル。ここで注意すべき落とし穴があります。「.cursor/rules内のプレーンな.mdファイルは、フロントマターがないためルールシステムによって無視されます。」もしそのディレクトリに.mdファイルとしてメモを保存していた場合、Cursorはそれを一度も読み込んでおらず、ルールとして移行する意味はありません。 - ユーザールール: Cursor環境全体に適用されるグローバルなルール。これらはリポジトリではなくあなた自身の環境に紐づいているため、最も忘れられがちです。
- チームルール: TeamまたはEnterpriseプランを利用している場合のダッシュボードからのルール。アクセス権を失う前にエクスポートしておきましょう。
AGENTS.md: すでに使用している場合。これはそのまま移行できるため、最も簡単です。
コピーする際、各ルールの有効化タイプ（アクティベーションタイプ）を記録しておいてください。Cursorのタイプには、Always Apply（常に適用）、Apply Intelligently（「説明に基づいてエージェントが関連性があると判断したときに適用」）、およびApply to Specific Files（パターンマッチング）があります。Warpのモデルはよりシンプルであるため、一部のルールのカテゴリを変更する必要があり、Warp側でこの情報が必要になります。
また、どのファイルにも現れないもの、つまり過去6ヶ月間にチャットで行った修正にも注意してください。Cursorのドキュメントに明記されているように、モデルは補完の間にメモリを保持しないため、好みがルールに書き込まれていなかった場合、セッションごとに再設定されていたことになり、エクスポートできるものは何もありません。これらを今すぐ書き留めておきましょう。この移行プロセスにおいて、情報源があなた自身の記憶である唯一の部分です。なぜCursorがプロジェクトルールを忘れるのかや、マシン間で忘れてしまうのか疑問に思っていたなら、この4つのスコープの分裂が原因であることがほとんどです。
Step 2: Warpの2つのスコープに配置し、ファイル名ルールに注意する
Warpがサポートするルールタイプは、正確に2つだけです。「グローバルルールは、すべてのプロジェクトとコンテキストに適用されます」と、「プロジェクトルールは、コードベース内に存在し、そのプロジェクト内で作業するときに自動的に適用されます。これらはAGENTS.mdファイル（または後方互換性のためのWARP.md）に保存されます。」
以下のようにマッピングします。Always Applyが設定されたCursorのプロジェクトルールは、ルートのAGENTS.mdの内容になります。特定のファイルにスコープされたCursorのプロジェクトルールは、ディレクトリレベルのAGENTS.mdファイルになります。なぜなら、「Warpはルートおよび現在のディレクトリにあるAGENTS.md（またはWARP.md）を自動的に適用する」からです。CursorのユーザールールはWarpのグローバルルールになります。Cursorのチームルールは、コミットされたAGENTS.mdの内容になります。これが共有状態を維持できる唯一の方法です。
以下の3つのファイル名ルールを無視すると、トラブルの原因になります。
- 「Warpが認識できるように、ファイル名はすべて大文字にする必要があります（例：
agents.mdやAgents.mdではなくAGENTS.md）。」 - 「同じディレクトリに
WARP.mdとAGENTS.mdの両方が存在する場合、WARP.mdが優先されます。」そのため、以前の実験で残されたWARP.mdがあると、新しく作成したファイルが無視されてしまいます。 - Warpは新規プロジェクトには
AGENTS.mdを推奨していますが、既存のWARP.mdファイルも引き続きサポートしており、他の変更を加えることなくいつでも名前を変更できます。
CursorのApply Intelligently（インテリジェントに適用）モードに依存していたルールについては、判断が必要です。なぜなら、Warpのプロジェクトルールはモデルの判断ではなく、場所によって自動的に適用されるからです。これらを無条件にするか、特定のディレクトリにスコープを絞るかのどちらかを行ってください。曖昧なままにして関連性に基づいて実行されることを期待していると、移行したルールセットが静かに無視されることになります。これは、エージェントが指示ファイルを無視する理由の背後にあるのと同じ失敗パターンです。
/initをスキップしないでください。Agent Modeでこれを実行すると、Warpが期待する形式のAGENTS.mdが生成されます。これは、.cursorrulesファイルをそのまま貼り付けるよりも優れた開始点になります。
より良い方法：どちらのエディタにも依存しない場所に学習レイヤーを配置する
上記の2つのステップに従えば、正しいWarpのセットアップが完了します。しかし同時に、不都合な事実も証明されることになります。それは、「この移行の自動化された部分はフォントを移動させただけで、手動の部分が重要なすべてのものを移動させた」ということです。
この非対称性はWarpのせいでも、Cursorのせいでもありません。プロジェクトに蓄積された知識が、特定のツールのファイル形式の中に存在しているときに起こる現象です。これに対するWarp自身の回答である「Agent Memory」は正しいアプローチですが、現在はデザインパートナーのチームに限定されています。外部のメモリレイヤーを使用すれば、ウェイトリストに並ぶことなく、今日から同じ機能を利用できます。MemoryLakeは3つのステップでセットアップできます。
Step 1: APIキーを作成する
サインインし、ダッシュボードからAPIキーを生成します。この資格情報はエディタではなくチームに紐づくため、今日のWarpからでも、来期に評価する他のツールからでも、同じ知識を読み取ることができます。
Step 2: 最初のメモリをアップロードする
ステップ1で書き留めた、保存するファイルがなかった情報をここに入力します。アーキテクチャの決定とその理由、チャットで何度も繰り返し指摘した規約、クライアントやドメインの仕様、特定のワークアラウンドが存在する理由などです。また、一元管理が重要であった場合は、チームルールの内容もここに配置します。これは、Warp側でダッシュボード管理のスコープに最も近いものになります。
AGENTS.mdは、リポジトリにコミットしてレビュー可能にする、常に適用すべきルールなど、その得意分野に限定して使用します。
Step 3: AIとエージェントを接続する
WarpのAgentをこのストアに向けます。移行の試行期間中にチームの一部がCursorに留まる場合（これは移行を安全に進めるための賢明な方法です）、両方のエディタが同じレイヤーを読み取るため、後で誰かが調整しなければならないような2つの異なるルールセットに分岐するのを防ぐことができます。
実務における変化
最初の変化は、試行期間のコストが下がる点です。CursorからWarpへの評価の多くは、2つのルールセットの同期を保つのが面倒なために頓挫します。その結果、時期尚早に移行を決定するか、試行を断念するかのどちらかになります。両方の外部に永続的なレイヤーを置くことで、並行して運用するための追加コストは発生しなくなります。
2つ目は、チームルールのギャップが問題にならなくなる点です。Warpの2つのスコープはシンプルですが、ダッシュボードのように一元管理することはできません。共有ストアを使用することで、全員が手動で同一のグローバルルールを維持することなく、一元管理の特性を取り戻すことができます。
3つ目は、プロンプトの領域を奪い合う必要がなくなる点です。常に適用されるルールは毎回コンテキストに結合されます。これは10個の規約であれば適切ですが、ドメインに関する200個の事実に対しては不適切です。「エージェントが従うべきルール」と「エージェントが知っておくべきこと」を分けることは、コーディングエージェントが実際に読んでいるものにおける区別の実践的なアプローチです。
CursorからWarpへの移行におけるベストプラクティス
- 最初に設定の移植を実行し、その後は忘れる。 WarpのAgentに
modify-settingsスキルを使ってsettings.jsonを変換させ、差分を確認します。これは外観を処理するものであり、それ以上の期待はしないでください。 - アンインストールする前に、Cursorの4つのスコープすべてを整理する。 ユーザールールとチームルールは、特に紛失しやすいものです。
.cursor/rulesから不要な.mdファイルを削除し、移行しない。 Cursorはこれらを無視していたため、移行しても不要なデータを移動させるだけになります。- 残された
WARP.mdがないか確認する。 同じディレクトリにある場合、WARP.mdがAGENTS.mdよりも優先されるため、デバッグ時に非常に混乱する原因になります。 - ファイル名にはすべて大文字を使用する。
agents.mdは認識されません。 Apply Intelligentlyルールを、常時オンまたはディレクトリ制限のいずれかに変換する。 Warpは関連性の判断ではなく、場所によってプロジェクトルールを適用します。- アクセス権がない限り、Agent Memoryを前提とした計画は立てない。 これはデザインパートナーチーム向けのリサーチプレビュー段階であり、ウェイトリストがあります。今週使える機能に基づいて移行を計画してください。
- 決定事項やドメイン知識はルールファイルに含めない。 ルールは振る舞いを規定するためのものであり、増え続けるコンテキストは、それが成長できる別の場所に配置すべきです。
結論
最初の段落で「ワンクリックのインポーターはない」と明記しているWarpの移行ページは、称賛に値します。その誠実さは、どこに作業が必要かを示しています。ターミナル設定は自動で移行され、.cursorrulesはAGENTS.mdにコピーされますが、エージェントがプロジェクトについて学習したすべての内容は、それを覚えている人間が書き直す必要があります。
この移行において、その書き直しを行うのは一度だけです。次の移行で再び同じことを行う必要があるかどうかは、今回それをどこに配置するかによって決まります。