実際に移行できるもの
AGENTS.md — 両方のツールが読み取る、真の架け橋。 Cursor は "プロジェクトのルートおよびサブディレクトリ" にある AGENTS.md をサポートしており、ネストされたファイルを親ファイルと結合して "より具体的な指示が優先される" ようにします。Cline のサポート対象ルール表では、AGENTS.md と ~/.agents/AGENTS.md が "ツール間の互換性のための標準フォーマット" としてリストされています。すでにルールが AGENTS.md にある場合は、移行作業の大部分は完了しており、どちらのツールを使用するか決める間、同じファイルに対して両方のツールを実行できます。
スキル — 完全に共有された1つのディレクトリ経由。 Cursor は .agents/skills/、.cursor/skills/、~/.agents/skills/、~/.cursor/skills/ からスキルを読み込みます。さらに互換性リストとして "互換性のために、Cursor は Claude および Codex のディレクトリ（.claude/skills/、.codex/skills/、~/.claude/skills/、~/.codex/skills/）からもスキルを読み込みます" とあります。一方、Cline はプロジェクトのスキルを .cline/skills/、.clinerules/skills/、および .claude/skills/ から読み取ります。この2つのリストを比較すると、両方に存在するディレクトリが1つだけあります。それが .claude/skills/ です（これはどちらのツールの専用ディレクトリでもありません）。スキルをそこに配置すれば、両方のツールがそれを読み取ることができます。SKILL.md の形状は双方で同じであるため、これは書き直しではなく、単なる移動作業です。
モデル — もしそれが理由でここにいるのであれば、OpenAI モデルも含まれます。 Cline は2つの OpenAI パスをドキュメント化しています。1つは設定に入力する API キー、もう1つは "OpenAI Codex (Subscription OAuth)" で、"OpenAI でサインインしてブラウザの OAuth を完了する" 方法です。これには "API キーの入力は不要" で、"利用可能なモデルは OpenAI のプランに依存" します。これは、OpenAI を "標準的な非推論チャットモデル" に制限し、"カスタム API キーはチャットモデルでのみ機能する" と記されている Cursor 独自の「キー持ち込み（BYOK）」ページと比較する価値があります。
移行できないもの: スコープ指定言語としての .mdc フロントマター。 これが本当の作業になります。Cursor の4つのルールタイプは3つのフロントマターフィールドに基づいて構築されており、そのドキュメントでは相互作用について次のように説明されています。alwaysApply: true は "常に含まれる。Glob と説明は無視される"、false で globs が指定されている場合は "一致するファイルがコンテキスト内にある場合に自動適用される"、false で description が指定されている場合は "エージェントが説明を読み、関連性がある場合にルールを取り込む"、false でどちらも指定されていない場合は "チャットでルールを @ メンションしたときのみ含まれる"。Cline にはこれに相当するメタデータはありません。Cline は ".clinerules/ 内のすべての .md および .txt ファイルを処理し、それらを統合されたルールセットに結合" します。すべてが適用されるか適用されないかのどちらかであり、ファイルごとに手動で切り替えます。
また、強制力としてのチームルール（Team Rules）も失われます。 Cursor のチームルールはダッシュボードで作成され、"チームルール → プロジェクトルール → ユーザールール" というドキュメント化された優先順位に従い、ルールを "すべてのチームメンバーに必須とし、カスタマイズで無効にできない" ようにマークできます。Cline のモデルは設計上その逆です。"検出されたすべてのルールタイプがルールパネルに表示され、個別に切り替えることができます。" すべてのルールは、それを使用するユーザーによって切り替え可能です。これは強制力に依存していたチームにとっては真の損失であり、どのファイルを使ってもこれを移行することはできません。
さらに、リモートルールの同期も失われます。 Cursor は GitHub リポジトリから .cursor/rules/imported/<repoName> にルールをインポートし、"プルして同期" することができます。Cline の同等機能は、.clinerules/ がリポジトリ内にあることであり、これは単一のプロジェクトに対する同じニーズをカバーしますが、多くのプロジェクト間で共有されるルールには対応していません。
手動移行の手順
ステップ 1: ルールがどのファイルにあるかではなく、どのようにアクティブ化されるかで分類する
.cursor/rules を開き、すべての .mdc ファイルをフロントマター（frontmatter）ごとに分類します。なぜなら、それだけがそのルールをどこに配置すべきかを決定する唯一の要素だからです。4つのグループに分けます。
alwaysApply: true。これらは常にオンになっているルールであり、直接移行できます。両方のツールに同じファイルを読み込ませたい場合は AGENTS.md に、Cline に完全に移行する場合は .clinerules/ に配置します。どちらでも機能しますが、前者の方法をとれば選択肢を広く残せます。
globs が設定されているもの。これらには直接対応するものはありません。Cline のルールはファイルパターンによって条件付きで添付されないため、src/components/**/*.tsx にのみ適用されていたルールは、常にオンのルール（すべてのタスクでコンテキストコストを支払う）にするか、その領域で作業するときに手動でオンにする切り替えルールにする必要があります。一括変換するのではなく、ルールごとに選択してください。
description が設定され、alwaysApply: false のもの。これらには、ルールシステムよりも適した配置場所があります。Cursor はこのタイプを "説明に基づいてエージェントが関連性があると判断したとき" に適用されると説明しています。Cline のスキルも同様に機能します。"メッセージを送信すると、Cline は利用可能なスキルとその説明のリストを表示します。リクエストがスキルの説明と一致する場合、Cline は use_skill ツールを使用してそれをアクティブにし、SKILL.md から完全な指示を読み込みます。" 同じメカニズムで、名前が異なるだけです。説明によってトリガーされるルールは、ルールファイルにするよりも、スキルに変換する方が忠実に再現できます。
どちらのフィールドも設定されていないもの。これらは @ メンション専用でした。Cline では、これらはオフのままにしておくルールファイルにするか、明示的に呼び出すスキルになります。どちらの方法でも問題ありませんが、トグルで切り替える方が元の挙動に近くなります。
この作業を行っている間、.mdc ファイルは削除しないでください。それらは、何が何にスコープされていたかを示す唯一の記録です。
ステップ 2: ファイルを配置し、モデルを接続し、コンテキストコストを監視する
プロジェクトのルートに .clinerules/ を作成し、1つのファイルにつき1つの関心事にとどめます。これは Cline 自身のアドバイスであり、トグル切り替えが唯一のスコープ指定ツールであるここではさらに重要になります。"トピックごとにルールを分割します... これにより、特定のルールを簡単にオンまたはオフに切り替えることができます。"
正しく行うべき3つのポイントがあります。
トークン費用に注意する。 Cline はこれを警告として記載しています。"ルールはコンテキストトークンを消費します。長々とした説明や、スタイルガイド全体を貼り付けることは避けてください。ルールは簡潔に保ち、詳細な参照が必要な場合は外部ドキュメントへのリンクを貼ってください。" Cursor では、glob 指定されたルールは、一致するファイルがコンテキストに入るまでコストはゼロでした。それらのいくつかを常にオンに変換すると、すべてのタスクにそのコストが静かに上乗せされることになります。
グローバルルールがどこにあり、どちらが優先されるかを知る。 Cline のグローバルルールディレクトリは、macOS と Linux では ~/Documents/Cline/Rules、Windows では Documents\Cline\Rules であり、~/.agents/AGENTS.md も読み取ります。両方が存在する場合、"グローバルルールと競合する場合、ワークスペースのルールが優先されます" —これは Cursor の「プロジェクト優先（対ユーザー）」の順序と同じ方向であるため、直感通りに機能します。
スキルレイヤーにおける1つの逆転現象に注意する。 Cline は "グローバルスキルとプロジェクトスキルが同じ名前の場合、グローバルスキルが優先される" と述べています。これはルールの解決方法とは逆であり、ほとんどのツールの挙動とも逆です。同じ名前の個人用スキルとプロジェクト用スキルを保持している場合、個人用のものが優先されます。
次に、プロバイダーを設定します。Cline の設定の OpenAI の下で API キーまたは Codex OAuth を設定し、エディターからは引き継がれない MCP サーバーを再追加します。
これで、ドキュメント化されている部分はカバーできました。残されているのはその背後にある「推論（reasoning）」であり、どちらのツールにもそれを保管する場所はありません。
より良い方法: どちらのエディターにも属さない場所に推論を置く
永続性に対する Cline の答えは Memory Bank であり、それが何であるかを率直に示しているからこそ、正確に理解する価値があります。リポジトリ内の6つの Markdown ファイル（projectbrief.md、productContext.md、activeContext.md、systemPatterns.md、techContext.md、progress.md）と、それらを読み取るよう Cline に指示する1つのルールファイルで構成されています。付属の指示書は、全文を引用する価値のある一文から始まります。"私は Cline です。専門のソフトウェアエンジニアですが、ユニークな特徴があります。セッション間で私の記憶が完全にリセットされることです。これは制限ではありません。完璧なドキュメントを維持するための原動力なのです。"
これはドキュメント作成の手法であり、優れたものです。また、コードベースにスコープされています。1つのプロジェクトの状態を説明する6つのファイルであり、Cline に "Memory Bank を更新して" と依頼することで更新されます。そこに収まらないのは、コードとは直接関係のない事柄です。なぜその標準が存在するのか、チームが何を試して却下したのか、誰に尋ねるべきか、どの締め切りが変更されたのか、などです。
MemoryLake は、単一のツールの外側に存在する記憶レイヤーであり、今回の移行や次の移行を乗り越えてその内容を維持することができます。セットアップは3つのステップです。
ステップ 1: API キーを作成する
サインインして API キーを作成します。接続するツール間で共通の1つの認証情報です。
ステップ 2: 最初の記憶をアップロードする
1つの項目につき1つの主張を含む、短いエントリを作成します。ソースとなる素材は、フロントマターに収まりきらなかったものです。
なぜ各「常にオン」のルールが常にオンなのか。 あなたは変換したすべての glob 指定ルールについて判断を下したばかりです。その判断と理由を記録しておかなければ、3ヶ月後にまた異なる判断を繰り返すことになります。
強制されたチームルールが何を保護していたか。 強制力は移行によって失われます。それが存在した理由は残すべきです。
定着した修正。 チームが試して断念したアプローチ。どちらの側のルールフォーマットにも、これを記録するフィールドはありません。
コードではない作業コンテキスト。 所有権、凍結された領域、現在の優先事項、ランブック。Memory Bank の activeContext.md は1つのリポジトリについてこれの一部をカバーしますが、こちらはすべてのリポジトリにわたってカバーします。
ステップ 3: AI とエージェントを接続する
使用しているものを接続します。MemoryLake は MCP および API 経由でアクセス可能であり、Cline は MCP サーバーをサポートしているため、同じ記憶をすぐに Cline で利用できます。Cursor、Claude Code、Codex、OpenClaw も同様に接続できます。つまり、移行期間中に両方のエディターを開いたまま、知っていることのコピーを2つ維持することなく作業できます。
3つの率直な制限事項。これは .mdc ファイルを自動変換するものではありません — ステップ1でのフロントマターのマッピングは手動であり、選択を伴うため、そうあるべきです。強制力を復元するものではありません。記憶レイヤーは、Cline のルールパネルでルールを無効化できないようにすることはできません。そして、記憶はコンテキストであり、強制力ではありません — Cursor のドキュメントも、独自の強制ルールについて同様の指摘をしています。"AI のガイダンスを唯一のセキュリティ管理策にすべきではありません。"
実務における変化
ルールのスコープ指定が明示的な決定になります。 Cursor はフロントマターからそれを決定していました。Cline では、ファイルごとに、公に一度選択する必要があります。
説明によってトリガーされるルールが、適切な場所に配置されます。 常にオンのファイルに詰め込むのではなく、スキルに変換することで、実際に望んでいた挙動を維持できます。
スキルが特定のエディターに依存しなくなります。 両方のツールが読み取る1つのディレクトリを使用するため、エディターの切り替えがスキルの移行作業になりません。
推論がチャットウィンドウの中に留まらなくなります。 これこそが、次のツール変更時にもこれらすべてが生き残る唯一の理由です。
Cursor から Cline への移行におけるベストプラクティス
ファイルごとではなく、アクティブ化モードごとに変換する。 フロントマターが仕様です。ファイル名からは何もわかりません。
移行を検討している間は、常にオンのルールに AGENTS.md を使用する。 両方のツールがそれを読み取るため、気が変わっても取り残されるものはありません。
説明によってトリガーされるルールはスキルに送る。 Cline のスキルアクティブ化は、どのルールファイルよりも Cursor の "Apply Intelligently" の挙動に近いです。
両方のエディターを使用したい場合は、スキルを .claude/skills/ に配置する。 これは、両方のサポート対象リストにある唯一のディレクトリです。
常にオンにしたルールを監査する。 変換されたすべての glob ルールは、すべてのタスクでコンテキストコストを消費するようになります。Cline はまさにこれについて警告しています。
強制力が何のためにあったのかを書き留める。 これは移行後に残らない唯一のプロパティであり、通常は誰かが今でも説明できる理由があって存在していたものです。
状況が落ち着くまで .mdc ファイルを保持しておく。 これらは、これから再実装しようとしているスコープ指定を記録しています。
Memory Bank をプロジェクト横断的な記憶と混同しない。 それは1つのコードベースの状態を説明するものです。より広い違いについては、why long context isn't memory で解説しています。
結論
Cline が一見無料で提供しているように見える移行は、あなたが本当に必要としているものではありません。そのルール表は .cursorrules を検出しますが、これは Cursor の現在のドキュメントにはもう記載されていないフォーマットです。一方で、あなたが実際に持っているフォーマット（.mdc ファイルでいっぱいの .cursor/rules）は、Cline のドキュメントのどこにも登場しません。実際に存在する架け橋は、両方のツールが読み取る AGENTS.md と、両方のサポート対象リストに登場する唯一のスキルディレクトリである .claude/skills/ です。
時間を消費するのはフロントマターです。Cursor の3つのフィールドは4つのアクティブ化挙動を生み出しますが、Cline のルールは手動トグルによる「全か無か（all-or-nothing）」です。何かをコピーする前に、alwaysApply、globs、description で分類してください。常にオンのルールは直接移動し、glob 指定されたルールはコンテキストコストに関するルールごとの判断になり、説明トリガーのルールはスキルに変換するのが最適であり、@ メンションルールはトグルになります。チームルールの強制力は一切変換されません。
そして、そのすべての下にあるレイヤー（なぜこれらのルールが存在するのか、何が試され却下されたのか、誰が何を所有しているのか）は、どちらのツールのフォーマットにも最初から存在していませんでした。Cline の Memory Bank はセッション間で完全にリセットされることを率直に認めており、だからこそ推論はどちらのエディターにも属さない場所に置くべきなのです。もし、あなたがここに来た原因が「ルールが静かに適用されない」という症状であったなら、その話の両面が why Cursor forgets your project rules と why Cline forgets your project context でカバーされています。