実際に移行されるもの
Trae 側。 Trae はプロジェクトレベルのルールを .trae/project_rules.md に、ユーザーレベルのルールを .trae/user_rules.md に保持します。また、プロジェクト内に .trae/rules/ ディレクトリを作成し、その下のサブフォルダにルールファイルを整理することができます。システムはこれらのディレクトリを再帰的に読み込みます。ルールはチャット内で #rulename を使って呼び出され、すべてがプレーンな Markdown であるため、バージョン管理やチーム内での共有が容易です。MCP サポートと .rules は Trae v1.3.0 で同時に導入されたため、設定した MCP サーバーは失われるものではなく、引き継がれる概念です。
Cursor 側。 プロジェクトルールは .cursor/rules 内に .mdc ファイルとして保存され、それぞれに4つのアクティベーションモード（Always Apply、Apply Intelligently、Apply to Specific Files、Apply Manually）のいずれかが設定されます。Cursor は、リポジトリのルートにあるプレーンな AGENTS.md も読み込みます。これは Codex、Amp、Jules、Factory も読み込むオープンなフォーマットです。コミットすべきではない個人的な設定は、Cursor の設定の User Rules に記述します。
そのため、マッピングは直接的です：
| Trae | Cursor |
|---|---|
.trae/project_rules.md | .cursor/rules/*.mdc またはルートの AGENTS.md |
.trae/user_rules.md | Cursor 設定の User Rules |
.trae/rules/ サブフォルダ | 関心事ごとに分かれた個別の .mdc ファイル |
#rulename による呼び出し | チャットで参照される Apply Manually モード |
| MCP サーバー | Cursor で再設定された MCP サーバー |
移行されないもの。 痛みの大きい順に3つのカテゴリがあります：
- セッション履歴。 Trae での会話は Trae に残ります。それを自動で読み取ってくれるものはありません。
- ファイルではなくチャット内に残したすべてのもの。 ほとんどの人は、書き留めるよりもはるかに多くのことをセッションごとに説明しています。その説明はどこにも保存されていません。
- 却下されたアプローチ。 これが最も失うコストが大きいものです。なぜなら、Cursor はあなたがすでに試して元に戻したリファクタリングを平然と提案してくるため、解決済みの問題を再決定するために午後を丸々潰すことになるからです。
Trae コミュニティがこれに対処するために構築したものに注目する価値があります。セッションの継続性を手動で構築する必要があったため、1つのコマンドでコンテキストを保存し、別のコマンドで復元する Trae 用のサードパーティ製ワークフロー継続パッケージが存在します。もしそのようなものを使用していた場合、それらの保存されたファイルはこの移行における最良の素材となります。
手動での移行
ステップ 1：ルールを移動し、ついでに分割する
1つの長い project_rules.md を1つの長い .mdc にそのまま貼り付けないでください。Cursor のアクティベーションモードは、ルールが関心事ごとに分離されている場合にのみ効果を発揮します。
.trae/project_rules.mdを読み、ビルドおよびテストコマンド、ディレクトリの命名規則、スタイル、セキュリティ制約、特定のサブシステムに関する事項などのトピックに分割します。.cursor/rules内にトピックごとに1つの.mdcを作成し、モードを慎重に設定します。普遍的な制約は Always Apply に設定します。サブシステム固有のルールは、glob パターンを使用して Apply to Specific Files に設定します。リリースのチェックリストや移行手順などのたまにしか使わないプレイブックは、Apply Manually に設定し、Trae で#rulenameを使用したときと同じように、必要なときに呼び出します。- すべてを Always Apply に設定しないでください。 そうしたくなりますが、コストがかかります。常にオンになっているルールは、すべての補完においてトークンを消費します。これはルールの移行において最もよくある間違いであり、エラーとしてではなく、請求額として現れます。
.trae/user_rules.mdはコミットするのではなく、Cursor の User Rules に移動します。個人の好みはリポジトリに含めるべきではありません。- 複数のエージェントがプロジェクトに触れる可能性がある場合は、Cursor や他のいくつかのエージェントも読み込むため、ツールに依存しないコア部分をルートの
AGENTS.mdに配置することを検討してください。 - Cursor で MCP サーバーを再設定し、実際に使用する前にそれぞれが応答することを確認します。
ステップ 2：ルールが保持していなかったものを再構築する
1時間を確保し、Trae のセッションにしか存在しなかったナレッジを書き出します。
- 決定事項とその理由。 「返金の順序が重要であるため、キューコンシューマーはシングルスレッドのままにする」という1行があるだけで、今後1年間にわたって不適切な提案を防ぐことができます。
- 行き止まり（デッドエンド）。 試行したものの元に戻したアプローチとその理由。これが無限ループを防ぎます。
- ローカルの罠。 Windows で不安定なテスト、手動で編集してはならない生成ファイル、シードの前に実行する必要があるマイグレーションなど。
- 保存されたコンテキストファイルからのすべての内容。 Trae の継続性ワークフローを使用していた場合は、今すぐそれらのアーカイブを掘り起こしてください。それらはあなたが持っているセッションの唯一の書面による記録です。
これはルールとしてではなく、ナレッジとして記述してください。毎週増え続けるため、常にオンの .mdc に置くべきではありません。すべての補完で 900 行の前置きにコストを支払いたい人はいません。
より良い方法：どちらのエディタでも使える単一のメモリレイヤー
ここで当然の疑問が生じます。それは一体どこに置くべきなのでしょうか？
どちらのエディタも、ルールファイルとセッションごとの新しいコンテキストという、同じ2つのものを提供します。だからこそ移行は簡単であり、同時に情報が失われやすいのです。ルールは制約を置くには適していますが、蓄積されたナレッジを置くには適していません。そして、Trae も Cursor もそれを置くための第3の場所を提供していません。そのため、最終的にチャットに書き込まれ、セッションの終了とともにチャットも終了してしまいます。
解決策は、より長いルールファイルを書くことではなく、欠けているレイヤーを追加することです。MemoryLake は、エディタの外部に存在し、MCP または API 経由でアクセスできるメモリレイヤーです。これにより、ナレッジはエディタ固有のものではなくなります。そして、次の移行が考古学のプロジェクトのようになるのを防ぎます。
ステップ 1：API キーを作成する
キーを生成し、約30秒で最初のリクエストを送信します。
ステップ 2：最初のメモリをアップロードする
先ほど作成した決定ログに加えて、アーキテクチャのメモ、API 契約、ランブック、インシデントの報告書、図など、人々が何度も説明し直している資料を読み込みます。ドキュメント、画像、その他のファイルはすべて同じ場所に保存されます。
ステップ 3：AI とエージェントを接続する
Cursor、Claude、Codex、OpenClaw、その他のエージェントに MCP 経由でアクセスを許可します。.cursor/rules ファイルは再び短くルールらしい形に戻り、毎週増え続けるナレッジは、来年どのエディタを使用していようとも、すべてのツールがクエリできる場所に存在することになります。
実務における変化
最初の違いはコストであり、これは測定可能です。ルールファイルは二重の役割を果たしているために肥大化し、常にオンになっているルールはすべての補完で課金されます。ナレッジをルールからクエリ可能なレイヤーに移動することで、リクエストあたりの支払いを削減しつつ、エージェントが実際に必要とするときに見つけられる情報を増やすことができます。
2つ目は、切り替えが一方通行ではなくなることです。現在、Cursor が自分に合わない場合、元に戻すには再び手動で再構築する必要があります。そのため、人々は機能していないツールを使い続けがちです。ナレッジが外部にある場合、2週間エディタを評価するためのコストは、設定の変更だけで済みます。
3つ目は、チームの一貫性です。リポジトリ内のルールファイルは共有されますが、Trae のチャットに入力したコンテキストは共有されません。3人の開発者がそれぞれ、なぜこのようなアーキテクチャになっているのかについて異なるメンタルモデルを持っている場合、彼らのエージェントは3つの異なる種類のコードを生成します。これは、Cursor がマシン間でコンテキストを忘れてしまう問題と同じ失敗が、人々の間で分散して発生している状態です。
移行後のベストプラクティス
最初の1週間でルールのモードを監査する
すべての .mdc を開き、そのアクティベーションモードが実際に必要とされる頻度と一致しているか確認します。普遍的な制約ではない Always Apply のものは、すべて降格させるべきです。Cursor が4つのモードを提供しているのには理由があり、そのうちの1つ（Always Apply）を使いすぎることが、ルールファイルが静かに高額化する原因になります。
ナレッジログは3つのファイルではなく、1つの場所にまとめる
移行後にありがちな誘惑は、メモを README、コメント、ルールファイルに分散させてしまうことです。蓄積されたナレッジの置き場所を1つに決め、すべてをそこに集約してください。断片化されたナレッジは、機能的にはナレッジがないのと同じです。なぜなら、そのすべてを検索できるものがないからです。
2週間は Trae の設定を削除しない
Cursor で実際のデバッグセッションを含む丸1週間を過ごすまでは、.trae/ と Trae のインストール環境を保持しておいてください。移行の漏れは最初の1時間には現れません。移行されたと思い込んでいたものが初めて必要になったときに現れます。同じ注意は、Copilot から Cursor への移行や、Cursor のルールを Claude Code にエクスポートする場合など、あらゆるエディタの移行に当てはまります。
結論
Trae から Cursor への移行は、最も簡単なエディタ移行の1つです。どちらも指示を Markdown で保持し、ルールのディレクトリを読み込み、MCP に対応しています。.trae/project_rules.md を個別の .mdc ファイルに分割し、すべてをデフォルトで Always Apply にするのではなくアクティベーションモードを慎重に設定し、ユーザールールを Cursor の設定に移動して、MCP サーバーを再接続します。
そして、節約できた労力を、どのファイルマッピングでもカバーできない部分に費やしてください。どちらのエディタもセッションから学んだことを保存しないため、決定事項や行き止まりは誰かが書き留める必要があります。それらを常にオンのルールファイルに書き込むと、すべての補完でコストを支払うことになり、次の移行時に再び失うことになります。エディタの外部にあるメモリレイヤーこそが、コンテキストを再構築するものではなく、保持するものに変える要素です。これは最終的に、Trae がセッション間でコンテキストを忘れてしまう問題や Cursor が以前のセッションを忘れてしまう問題の背景にあるものと同じギャップです。