実際に移行されるもの
Cursor のルールに関するドキュメントでは、フォーマットの要件について正確に記載されており、その正確さこそが重要なポイントです。
"プロジェクトルールは.cursor/rules内に.mdcファイルとして保存され、バージョン管理されます。これらはパスパターンを使用してスコープ設定されるか、手動で呼び出されるか、または関連性に基づいて含められます。"
"プロジェクトルールは.mdc拡張子を使用する必要があります。.cursor/rules内のプレーンな.mdファイルは、description、globs、およびalwaysApplyを指定するフロントマターがないため、ルールシステムによって無視されます。プレーンな Markdown を好む場合は、代わりに AGENTS.md を使用してください。"
3つのフロントマターフィールドがすべての条件性を担っています。ドキュメントには重要な分岐が説明されています。
"alwaysApply が true の場合、ルールはすべてのチャットセッションに適用されます。そうでない場合、ルールの説明（description）が Cursor Agent に提示され、適用すべきかどうかが判断されます。"
さらに、ルールを一致するファイルにスコープするための globs と、「ルールは500行未満に抑える」という推奨事項があります。
この拡張子の要件については、立ち止まって考える価値があります。なぜなら、これが移行作業を始める時点で人々がすでに不満を抱いている最も一般的な原因だからです。そのディレクトリに .md として保存されたルールは、壊れたルールではありません。ルールとして認識すらされておらず、それを知らせるものもありません。Cursor がプロジェクトルールを忘れる問題 という報告の半分は、ルールシステムが一度も読み込んでいないファイルに起因しています。
次に Roo Code です。ワークスペースのルールは .roo/rules/ に配置され、ドキュメントではこれが推奨される方法とされており、ワークスペースのルートにある単一の .roorules ファイルがフォールバックとして機能します。グローバルルールは ~/.roo/rules/ に配置され、その場所は「固定されており、カスタマイズすることはできません」。読み込み順序は明確にドキュメント化されています。まずグローバルルール、次にプロジェクトルールであり、「競合がある場合は、ワークスペースのルールが優先されます」。
固定されたグローバルパスは、チームにとって実用上の影響を及ぼします。それはホームディレクトリの場所であるため、マシンごとに異なり、バージョン管理の対象外となります。そこに配置したものはすべて1台のラップトップ上にのみ存在することになり、これは Cursor がマシン間で設定を忘れる問題 の背後にある非対称性と同じです。チームに関連するルールは、グローバルディレクトリではなく、ワークスペースディレクトリに配置してください。
そして、あなたの計画を変える一文がこれです。
"Roo Code はファイルを再帰的に（サブディレクトリを含めて）読み込み、ファイル名に基づいたアルファベット順でその内容をシステムプロンプトに追加します。"
再帰的、追記、アルファベット順、ファイル名。ディレクトリ内のすべてが適用されるため、alwaysApply は存在しません。ファイルスコープのものはないため、globs も存在しません。モデルに判断を求めていないため、モデルが評価するための description も存在しません。
したがって、移行されるものとされないものは以下の通りです。すべてのルールの本文（散文）はそのまま移行されます。どちらにせよ Markdown です。Roo Code もサブディレクトリを読み込むため、ディレクトリ構造も移行されます。消失するのは3つのフロントマターフィールドすべてであり、それとともに、常に適用されるルールと src/api/**/*.ts に適用されるルールの区別全体が失われます。
これによって2つの結果が生じ、2番目の結果は人々を驚かせます。
第一に、コンテキストの消費量（コスト）が上がります。条件付きとして記述したすべてのルール（マイグレーションにスコープされた長いデータベース規約ファイルや、.tsx にスコープされた React パターンファイルなど）が、ビルドスクリプトに関するものも含め、すべてのリクエストのシステムプロンプトに含まれるようになります。
第二に、これまで決して交わることのなかった矛盾が交わるようになります。app ディレクトリにスコープされた「サーバーコンポーネントを優先する」というルールと、レガシーフォルダにスコープされた「これらはすべてクライアントコンポーネントである」というルールは、Cursor の下では同じコンテキストに入ることはありませんでした。しかし、フラットな追記の下ではこれらが共存し、どちらがプロンプトの後半に配置されるかは、どちらのファイル名が後にソートされるかで決まります。これが、Roo Code がプロジェクトのコンテキストを忘れる問題 といった報告の背景にあるメカニズムです。ルールは存在していますが、それらが矛盾しているのです。
Roo Code にも条件分岐のメカニズムはあります。ただ、別の場所にあるだけです。
手動での移行
Step 1: globs によるスコープを「モード」として再表現する
Roo Code はファイルパスではなく、モードによってルールをスコープします。.roo/rules/ と並行して .roo/rules-{modeSlug}/ ディレクトリを作成でき、ドキュメントに記載されている例には、Code モード用の rules-code/、アーキテクチャタスク用の rules-architect/、デバッグワークフロー用の rules-debug/、ドキュメント抽出用の rules-docs-extractor/ などがあります。同じパターンは ~/.roo/ の下でグローバルにも存在します。各レベルにおいて、ドキュメントには「モード固有のルールは一般的なルールよりも前に読み込まれる」と記されています。
そのため、.mdc ファイルを確認し、その globs が実際に何を近似していたかに基づいて分類してください。テストファイルにスコープされたルールは、通常、テストの書き方に関するルールであり、これは Code モードまたは Debug モードの関心事です。アーキテクチャドキュメントにスコープされたルールは rules-architect/ に属します。alwaysApply: true だったルールは、そのまま .roo/rules/ に配置します。それがそのディレクトリの意味だからです。
globs が作業の種類ではなく、純粋にパスに関するものであったルールは、すっきりと収まる場所がありません。それらは代わりに、本文中に明示的な条件文として記述してください（どのディレクトリにそのガイダンスが適用されるかを示す文）。ファイルはいずれにせよ読み込まれるため、モデルはテキストからその境界を知る必要があります。これは glob よりも信頼性は低いですが、移行先がサポートしている機能に対して誠実なアプローチです。
この作業を行う際、フロントマターのブロックは残さずに削除してください。ルールファイルの先頭にある不要な YAML ヘッダーは Roo Code によって解析されないため、そのままコンテンツとなり、モデルに対する意味のない alwaysApply の指示になってしまいます。
Step 2: 追記順序を意図的に制御し、2つの罠に注意する
コンテンツはファイル名のアルファベット順に追記されるため、ファイル名がそのまま読み込み順序になります。順序が意図したものになるように名前を付けてください。各ファイルに数値のプレフィックスを付けることで、シーケンスが明示的になり、後で名前を変更したときにシステムプロンプトの順序が意図せず変わってしまうのを防ぐことができます。
次に、ドキュメントに記載されている2つの挙動を確認します。
1つ目は、空のディレクトリの罠です。「.roo/rules/ ディレクトリが存在するが空である場合、Roo Code は代わりに .roorules ファイルの使用にフォールバックします。」したがって、移行が半分終わった状態（ディレクトリは作成したが、ファイルはまだ移動していない）では、忘れていたかもしれないレガシールートファイルが静かに再有効化されます。
2つ目は、より広い意味でのレガシーファイルの優先順位です。ドキュメントに記載されている読み込み順序では、ワークスペースルートにあるレガシーファイル .roorules および .clinerules は、「一般的なルールディレクトリのコンテンツが読み込まれなかった場合にのみ使用される」とされています。Cline から移行した人にとって Roo Code が .clinerules を読み込むのは便利ですが、そうでない人にとっては混乱を招きます。リポジトリに残っている古いファイルは、ルールディレクトリにコンテンツがある間は何もしませんが、コンテンツがなくなった瞬間に適用されます。
最後に、AGENTS.md はそのままにしておいてください。Cursor は .mdc のプレーンな Markdown 代替としてこれをサポートしており、スタック全体で引き続き役立ちます。Cursor ルールを Windsurf スタイルのセットアップに移行する でも、別の移行先に対する同じ翻訳の問題をカバーしていますが、共通しているのは、オープンな規約こそが生き残る部分であるということです。
より良い方法：ファイル名に依存しない理由
ステップ 1 では各ルールがどのモードに属するかを決定し、ステップ 2 ではそれらがどの順序で読み込まれるかを決定するよう求められました。どちらの決定も、各ルールが存在する理由を知っていれば簡単ですが、知らない場合はほぼ不可能です。
「サーバーコンポーネントを優先する」対「これらはすべてクライアントコンポーネントである」は、アルファベット順にソートされた2つの命令としては解決不可能です。しかし、後者がまだ誰も移行していないディレクトリを説明しており、前者が現在の基本方針であることを知っていれば、それは些細なことです。その理由はどちらのツールにも含まれておらず、.mdc のフロントマターにも含まれていませんでした。
MemoryLake は、そのレイヤー（決定、採用されなかった代替案、およびその理由）をエディタの外部に保持し、MCP または API を介して要求するエージェントに提供します。.roo/rules/ ファイルは、ドキュメントに記載されている通りに読み込まれる、短く命令的な状態を維持でき、その背後にある理由は、すべてのリクエストのシステムプロンプトに含まれることなく回答可能になります。
Step 1: API キーを作成する
キーを生成し、約30秒で最初のリクエストを行います。ファイルを分類する際に各競合を記録する場所を確保するために、上記のステップ 1 の前にこれを行ってください。
Step 2: 最初の記憶をアップロードする
保持した各ルールについて、何が決定され、何が除外され、そしてその理由は何だったのかを書き留めます。互いに矛盾していたペアは、再び表面化する可能性が高いため、最も価値のあるエントリです。サポートドキュメントやファイルも同じ場所に配置します。
Step 3: AI とエージェントを接続する
Roo Code、Claude、Codex、およびその他のエージェントに、MCP または API を介したアクセスを許可します。ルールが間違っているように見える場合、「なぜこれがここにあるのか」という問いに対する答えは、単なる再表明ではなく、その理由とともに届きます。
実務における変化
最初の変化は、ルールディレクトリを小さくできることです。理由を記録する場所ができれば、各ファイルは数行の命令的な記述で済みます。これは、条件付き読み込みの下よりも、フラットな追記の下で非常に重要になります。
第二に、モードの割り当てが決定可能になります。ルールを rules-code/ と rules-architect/ のどちらに分類するかは、それがどのような作業を管理するかという判断であり、ルールにその目的が伴っていればその判断は明白ですが、伴っていなければ推測に頼ることになります。
第三に、ファイル名の順序が重要ではなくなります。依然として意図的な名前付けは望ましいですが、真の不一致を解決するためにアルファベット順の偶然に頼る必要はなくなります。不一致は、意図的に一度解決され、記録されているからです。
第四に、次のツールへの移行は、今回の移行よりも簡単な作業になります。Cursor は条件性をフロントマターに置き、Roo Code はそれをモードに置き、その次のツールはまた別のことをするでしょう。変わらないのは、プロジェクトが行ってきた一連の決定事項です。これが、コーディングエージェントが実際に読んでいるもの が、特定のツールが要求する拡張子よりも永続的な問いであるのと同じ理由です。
Roo Code 移行後のベストプラクティス
.roo/rules/ 内のすべてが常に有効であると想定する。 そのディレクトリは常に有効なレイヤーであるため、alwaysApply に相当するものはありません。すべてのリクエストに含めたくないものは、モードディレクトリに配置するか、あるいは一切含めないようにします。
スコープツールとしてモードディレクトリを使用する。 rules-code/、rules-architect/、rules-debug/、およびそれらのグローバルな対応ディレクトリが、現在条件性が存在する場所です。
ファイル名で読み込み順序を表現する。 コンテンツはファイル名のアルファベット順に追記されるため、数値のプレフィックスを付けることで、暗黙的な順序を明示的なものに変換できます。
.roo/rules/ を決して空にしない。 空のディレクトリは .roorules にフォールバックするため、中途半端に終わった移行が、有効なレガシー設定として機能してしまいます。
不要な .clinerules および .roorules ファイルがないか監査する。 これらは、ルールディレクトリにコンテンツがある間は機能しませんが、コンテンツがなくなった瞬間に支配的になります。
変換時にフロントマターを削除する。 解析されない YAML は本文（散文）となり、alwaysApply に関する本文はモデルが読み取る必要のあるノイズになります。
リポジトリに AGENTS.md を保持する。 これは、これら2つのツール、あるいは次のツールの間でも変わらないインターフェースです。
結論
Cursor はフロントマター付きの .mdc ファイルを要求し、.cursor/rules 内のプレーンな .md ファイルは description、globs、および alwaysApply を指定するフィールドがないため無視されると規定しています。Roo Code は .roo/rules/ からプレーンな Markdown を再帰的に読み込み、ファイル名のアルファベット順に追記します。スコープメカニズムとしてモード固有のディレクトリを使用し、ディレクトリが空の場合は .roorules にフォールバックすることがドキュメントに記載されています。どちらも合理的な設計です。しかし、それらは同じ設計ではなく、フォルダの名前を変更するだけでは、すべての条件付きルールが静かに無条件のルールに変換されてしまいます。
機能する移行とは、再モデル化です。globs はモードになり、alwaysApply はデフォルトになり、ファイル名は読み込み順序になり、これまで出会わなかったために互換性を保っていたルールは、真に和解させる必要があります。この最後の部分には、ルールだけでなく「理由」が必要です。そのため、どちらのツールも所有していない場所にその理由を置いておけば、次に採用するルールシステムは、発掘作業ではなく単なる翻訳作業になります。