コンテキストを失わずに Cline から Cursor へ移行する方法 (2026)

ルールはテキストとして移行されますが、動作としては移行されません。 Cline のドキュメントによると、ワークスペースのルールはプロジェクトのルートにある .clinerules/ に配置され、Cline は「.clinerules/ 内のすべての .md および .txt ファイルを処理し、それらを統合されたルールセットに結合する」とされています。グローバルルールは macOS および Linux では ~/Documents/Cline/Rules に保存され、競合が発生した場合はワークスペースのルールが優先されます。

Cursor のモデルは本質的に異なります。プロジェクトルールは .cursor/rules 内のバージョン管理された .mdc ファイルであり、3つのフロントマターフィールド（alwaysApply、description、globs）によって、それぞれがいつコンテキストに組み込まれるかが決定されます。Cursor のドキュメントには、通常の .md ファイルはこれらのフィールドがないためルールシステムによって無視され、プレーンな Markdown は代わりに AGENTS.md に記述すべきであると明記されています。

特に .txt のケースに注意してください。Cline は .txt ルールを読み込みますが、Cursor のルールシステムにはそれらを配置する場所がありません。これらは警告なしに消去されます。

アクティベーションのセマンティクスはほぼ対応していますが、その形状は異なります。 Cline の条件付きルールは「現在のファイルが定義されたスコープに一致する場合にのみアクティブ化」され、変換において最も重要な一文として「フロントマターのないルールは常にアクティブ」になります。

したがって、典型的な .clinerules/ フォルダは、常にアクティブなファイルの集まりが結合されたものです。これは事実上、1つの巨大な「常にオン」の指示の塊です。これを alwaysApply: true を持つ .mdc ファイルに1対1で変換すると、その塊を忠実に再現することになりますが、Cursor 自身のガイドラインではルールを500行未満に抑えることが推奨されています。忠実ではありますが、間違ったアプローチです。

Memory Bank はファイルとして移行されますが、そのメカニズムは失われます。 ここが重要なポイントです。Cline の Memory Bank は「Cline がセッション間でコンテキストを維持するのを支援する構造化されたドキュメントシステム」として文書化されており、これにより Cline は「ステートレスなアシスタントから、永続的な開発パートナー」へと変化します。これには、projectbrief.md、productContext.md、activeContext.md、systemPatterns.md、techContext.md、progress.md の6つのコアファイルが規定されています。

Cline 自身のドキュメントに一人称で記載されている、その前提を読んでみてください。「私のメモリはセッション間で完全にリセットされます。これは制限ではなく、完璧なドキュメントを維持するための原動力です。」そして、動作ルールは「リセット後、私はプロジェクトを理解し、効果的に作業を継続するために、完全に Memory Bank に依存します。」となっています。

これが機能するのは、Cline が各タスクの開始時にこれらすべてを読み込むように指示されているからです。Cursor には同等の規約がありません。フォルダをコピーしても、ドキュメントはそこに存在し、最新の状態のまま、誰にも読まれません。

代わりに Cursor が提供するもの。 ドキュメントによると、4つのルールタイプがあります。コードベースにスコープされバージョン管理される .cursor/rules 内のプロジェクトルール、Cursor 環境全体に適用されるユーザールール、Team および Enterprise プランのダッシュボードで管理されるチームルール、そして .cursor/rules のプレーン Markdown 代替としての AGENTS.md です。ルールはモデルのコンテキストの先頭に追加されます。そして Cursor は、Cline と同様に根本的な現実を明確に述べています。「大規模言語モデルは、完了（completion）間でメモリを保持しません。ルールは、プロンプトレベルで永続的かつ再利用可能なコンテキストを提供します。」

両方のツールとも、メモリが存在しないという点では一致しています。異なるのは、それに対してどう対処すべきかという点です。Cline はドキュメントを厳格に維持することを求め、Cursor はルールを正確に構成することを求めます。移行とは、2つのファイルフォーマット間の移行ではなく、これら2つの哲学の間の移行なのです。

ステップ 1: 変換する前に、統合された塊を分割する

ファイルを1対1で変換しないでください。.clinerules/ の結合されたコンテンツを1つのドキュメント（Cline が処理していた方法）として読み、それぞれの部分がいつ適用されるべきかによって再構成します。

• 常に、すべての完了（completion）において: 回答を誤らせないための2、3の制約。著作権ヘッダー、「生成されたファイルを直接編集しない」、厳格なアーキテクチャルールなど。
• 特定のファイルに触れるときのみ: ディレクトリ、言語、またはレイヤーに言及しているものすべて。通常、これが大部分を占めます。
• モデルが関連していると判断したときのみ: パスにマッピングされないドメインの規約。
• 指示したときのみ: 長いチェックリスト、リリース手順、レビュープロトコル。

次に、.cursor/rules 内にグループごとに1つの .mdc ファイルを作成し、それに合わせてフロントマターを設定します。

• 常に適用 → alwaysApply: true (globs と description は無視されます)
• ファイルスコープ → globs: src/api/**/*.ts かつ alwaysApply: false
• モデル選択 → 適切な description: を設定し、globs はなし
• 手動 → 両方とも設定せず、チャットで @rule-name を使用して呼び出す

これを行う際、2つの罠があります。拡張子は必ず .mdc でなければなりません。.cursor/rules 内の .md ファイルはエラーなしで完全に無視されます。また、Cline のグローバルルール（~/Documents/Cline/Rules）はプロジェクトではなく個人に属するものなので、リポジトリではなく Cursor の「Customize」内にある「User Rules」に配置します。チームで標準を共有している場合、Team および Enterprise プランではダッシュボード管理のチームルールがその上のレイヤーになります。

このタイミングで不要なルールの削除も行いましょう。移行は、すべてのルールを新鮮な目で読み直す唯一の機会です。廃止されたサービスのために書かれたルールをそのままにしておくと、AI はそれをいつまでも守り続けてしまいます。

ステップ 2: Memory Bank の扱いを決定する

3つの選択肢があります。どれを選ぶかよりも、意図的に選択すること自体が重要です。

選択肢 A: 維持して Cursor に参照させる。 alwaysApply: true の .mdc ルールを1つ作成し、作業を開始する前に memory-bank/activeContext.md と memory-bank/progress.md を読み込み、終了時にそれらを更新するようエージェントに指示します。これが Cline の動作に最も近い再現方法です。ただし、これにはコストがかかります。すべてのセッションで、常にオンの指示と、それがトリガーするファイル読み込みが追加されることになります。

選択肢 B: 永続的な部分をルールに統合し、残りをドキュメントとして保持する。 systemPatterns.md と techContext.md は、ほとんどが安定したアーキテクチャやスタックに関する事実です。これらはプロジェクトルールまたは AGENTS.md に変換します。projectbrief.md と productContext.md は、人間が一度読めばよいオリエンテーションドキュメントなので、リポジトリのドキュメントとしてそのまま残します。activeContext.md と progress.md はセッションの状態です。ここで率直になる必要があります。Cursor ではこれらを自動的に維持してくれないため、手動で更新するか、あるいはプロジェクトの現状とは異なる「自信に満ちた誤った記述」へと風化させてしまうかのどちらかになります。

選択肢 C: フォーマットを廃止し、コンテンツを維持する。 6つのファイル構造が存在するのは、Cline がリセット後に参照する固定の場所を必要としたからです。Cline をもう使用しないのであれば、この構造は単なる足場にすぎません。重要なのは、その中にある決定事項、アーキテクチャ、制約が、取り出し可能な場所に残ることです。

どの選択肢を選ぶにしても、何もせずに放置することだけは避けてください。リポジトリ内の古い activeContext.md は、メモリバンクがないことよりも悪影響を及ぼします。なぜなら、次に作業する人や、そこに迷い込んだ次のエージェントがそれを真実だと信じてしまうからです。

古いセットアップを閉じる前にもう1つ確認すべき項目があります。それは、Cline が学習したものの、Memory Bank に書き込まれなかった内容です。セッション内で、プロジェクトの癖について知っていることや、新しい開発者に警告したいことについて Cline に尋ねてみてください。その回答をどこかに貼り付けておきましょう。これが、この移行において唯一期限のある作業です。

Cline の Memory Bank が正しかった点に注目してください。人々がそれを好む理由は、知識をチャットの副産物としてではなく、第一級の成果物（first-class artifact）として扱っているからです。その弱点は、その成果物がどこに存在し、誰が維持しているかという点にあります。1つのリポジトリにある6つのファイルは、1つのツールの規約によって更新され、他のアシスタントからは見えません。

ですから、その直感は維持しつつ、保存場所を変更しましょう。ルールはリポジトリ内に Cursor のフォーマットで小さく維持します。その背後にある知識（決定事項、アーキテクチャ、インシデント、コントラクト）は、どのツールからでも読み書きできるストアに保存します。

MemoryLake はそのためのメモリレイヤーです。ドキュメント、決定事項、プロジェクトの知識が1つのストアに保存され、Claude や Codex などの MCP 対応ツールから直接、また API を通じて ChatGPT からも読み込むことができます。1つのエージェントの規約に依存することなく、Memory Bank のアイデアを実現します。

ステップ 1: API キーの作成

キーを生成すれば、約30秒で最初のリクエストを送信できます。チャットに直接貼り付けるのではなく、環境変数やシークレットマネージャーに保存してください。

ステップ 2: 最初のメモリをアップロードする

Memory Bank が担っていたドキュメント、画像、ファイルを投入します。systemPatterns.md や techContext.md をそのまま、アーキテクチャの決定とその理由、インシデントの記録、API コントラクト、これまでに蓄積された制約などをアップロードします。要約されたバージョンではなく、ソース自体をアップロードしてください。要約すると、ルールの背後にある理由が失われてしまいます。

ステップ 3: AI とエージェントを接続する

Claude、Codex、OpenClaw、その他の AI エージェントに、MCP または API を介してメモリへのアクセスを許可します。MCP 対応のツールは同じストアを直接読み込むため、昨年採用したフォルダ規約に縛られることなく、今月使用しているどのエージェントからでも知識にアクセスできます。

最初の違いは、常にオンにするルールを3つ程度に抑えられる点です。すべてを「常に適用」にしたくなるのは、コンテキストを置く場所が他にないからです。検索（retrieval）が利用可能であれば、alwaysApply: true は回答を誤らせないための重要なルール専用に予約できます。

2つ目の違いは、activeContext.md が「いつか破綻する嘘」ではなくなる点です。誰も維持しない状態（state）は劣化します。エージェントが作業しながら書き戻すストア内の状態は最新に保たれ、本当に安定している部分（決定事項、アーキテクチャ）は維持管理の必要がまったくありません。

3つ目は、知識がツール固有の形状から解放される点です。Memory Bank は Cline の規約であり、.cursor/rules は Cursor の規約、CLAUDE.md は Claude Code の規約です。これら3つの中身は同じ情報です。だからこそ、情報を外部に切り離さない限り、エディタを切り替えるたびに週末が潰れることになります。

そして、これは Cursor がネイティブに行うことと調和します。ルールはドキュメント通りにプロンプトレベルのコンテキストを提供し続け、チームルールは標準を配布し続けます。どちらもプロジェクトの履歴を保持する必要はありません。履歴を保持させようとすると、Cursor のルールはすぐに忘れてしまうように感じられますが、実際には単に設計上、容量が小さいだけなのです。

ルールはファイル単位ではなく、アクティベーションごとに再構成する

Cline はすべてを結合していましたが、Cursor は各ファイルを個別に評価します。1対1でコピーすると、条件性が失われるか、すべてが常にオンになってしまいます。1時間を費やして再構成してください。これを行うことで、関連する時だけ起動するルールと、すべてのプロンプトを希釈してしまう巨大な塊との違いが生まれます。

デバッグする前に拡張子を確認する

.mdc でなければ存在しないものとみなされます。.cursor/rules 内の .md ファイルはルールシステムによって無視され、.txt ファイルは配置する場所すらありません。移行直後に Cursor が「ルールに従わない」場合は、まずこれを確認してください。

個人のルールは User Rules に、チームの標準はチームルールに配置する

Cline のグローバルルールフォルダは個人用レイヤーであり、リポジトリはそうではありません。Cursor の User Rules はプロジェクトをまたいだ個人の習慣をカバーし、ダッシュボード管理のチームルールは Team および Enterprise プランにおける組織の標準をカバーします。これら3つをプロジェクトルールに混在させると、誰かの個人的な好みを全員が引き継ぐことになります。

初日に Memory Bank の扱いを決定する

常にオンのルールで維持するか、ルールとドキュメントに統合するか、あるいはフォーマットを廃止してコンテンツを移行するか。3つのアプローチはいずれも合理的です。しかし、リポジトリに未管理のファイルを6つ放置することは避けてください。それらの価値は、最新であることのみに依存していたからです。

使用を停止する前に、古いエージェントが知っていることを尋ねる

Memory Bank に書き込まれていない内容は、これから放棄しようとしているセッションの中にしか存在しません。Cline に「新しい開発者に警告したいこと」を尋ねる10分間は、この移行プロセス全体において最も安価な保険となります。

ルールに強制力を期待しない

Cursor は直接述べています。ルールはプロンプトレベルで永続的かつ再利用可能なコンテキストを提供します。コンテキストは影響力です。フォーマット、保護されたファイル、禁止されたインポート、コミットポリシーなどは、フォーマッター、リンター、CI に任せるべきであり、ルールファイルはその存在理由を説明するために使用します。

Cline から Cursor への移行は、1つのコートを着た2つの移行です。ルールの側面は、コピーするのではなく再構成する必要があります。Cline は .clinerules/ 内のすべての .md および .txt ファイルを1つの統合されたセットに結合するのに対し、Cursor はフロントマターから各 .mdc ファイルの扱いを決定するためです。また、.cursor/rules 内の通常の .md ファイルはエラーなしで完全に無視されます。Memory Bank の側面は、静かに壊れる部分です。6つの Markdown ファイルはそのまま移行されますが、リセットのたびに Cline にそれらを読み込ませていた規約が失われます。

両方のツールとも、根本的な問題について真実を述べています。Cline はセッション間でメモリが完全にリセットされるため、ドキュメントを重視します。Cursor は完了（completion）間でモデルがメモリを保持しないため、ルールを重視します。Memory Bank の直感を真剣に受け止め、ルールは小さくスコープを絞って維持し、知識自体はどちらのツールにも属さないストアに保存しましょう。そうすれば、次の移行は発掘作業ではなく、単なる設定変更になります。