実際に移行できるもの
アクティベーションモードはマッピング可能であり、その対応関係は書き留めておく価値があります。 Augment は3つのルールタイプをサポートしています。Always（「内容はすべてのユーザープロンプトに含まれます」）、Auto（「エージェントは説明フィールドに基づいて自動的にルールを検出し、添付します」）、そして Manual（「Rules ファイルを手動で @ 添付してタグ付けする必要があります」）です。
Cursor は、3つのフロントマターフィールドの相互作用を通じて、これらと同じ3つの状態を表現します。alwaysApply: true は「常に含まれます。Glob と説明（description）は無視されます」を意味します。alwaysApply: false で description があり、glob がない場合は、「エージェントが説明を読み、関連性がある場合にルールを取り込みます」となります。どちらもない場合、ルールは「チャットでルールを @ メンションしたときのみ含まれます」となります。
したがって、Always は alwaysApply: true に、Auto は alwaysApply: false と説明（description）に、Manual は alwaysApply: false で他には何もない状態にマッピングされます。Augment の CLI は、フロントマターで最初の2つを always_apply および agent_requested と命名しており、対応関係がさらに明確になります。
Cursor は Augment にはないモードを追加しています。 alwaysApply: false と globs が指定されている場合、Cursor のルールは「一致するファイルがコンテキスト内にある場合に自動添付」されます。Augment の agent_requested はモデルが説明を読んで判断することに依存していますが、Cursor の glob モードは決定論的なパターンマッチングです。TypeScript ファイルにのみ本当に関係する Augment ルールがあり、それをエージェントのために散文で説明していた場合、これはアップグレードになります。それを glob としてエンコードし、エージェントの「お祈り」に頼るのをやめましょう。
ファイル拡張子が罠です。 Cursor のドキュメントにはこうあります。「プロジェクトルールは .mdc 拡張子を使用する必要があります。.cursor/rules 内のプレーンな .md ファイルは、description、globs、alwaysApply を指定するフロントマターがないため、ルールシステムによって無視されます。」 Augment のルールは .md です。これらを変更せずにコピーすると、正しいディレクトリに配置され、正しく見えますが、何も機能しません。エラーも表示されません。
ディレクトリのネストは、Cursor に有利な形で動作が異なります。 Augment は制限について明記しています。「AGENTS.md と CLAUDE.md ファイルのみが階層的に検出されます。.augment/rules/ 内のファイルは、ワークスペースのルートからのみロードされます。」 Cursor はネストされたルールディレクトリを許可しているため、ルールをそれが適用されるコードの隣に配置できます。Augment の要件のためにすべてを1つのルートディレクトリにフラット化していたなら、もうその必要はありません。
User Rules（ユーザールール）は移行できますが、設定可能性は失われます。 Augment はユーザールールを ~/.augment/rules/ に保存し、ドキュメントはその挙動について断言しています。「ユーザールールは常に always_apply として扱われ、他のフロントマタータイプはサポートしていません。フロントマターの設定はワークスペースルールにのみ影響します。」 Cursor の User Rules は「Cursor 環境に対してグローバル」であり、Agent によって使用されます。同じ役割、同じ無条件のロードであるため、この部分は単純なコピーで済みます。
AGENTS.md はそのまま移行できます。 両方のツールがこれを読み取ります。Augment はサブディレクトリを通じて AGENTS.md と CLAUDE.md を階層的に検出します。Cursor は「プロジェクトのルートおよびサブディレクトリでの AGENTS.md をサポート」し、それを「.cursor/rules のシンプルな代替手段」— メタデータや複雑な設定のないプレーンな Markdown として説明しています。Augment の設定の一部がすでに AGENTS.md にある場合、その部分に手を加える必要はありません。
チームレベルのルールはモデルが完全に変わります。 Cursor の Team Rules は「ダッシュボードから管理されるチーム全体のルール」であり、Team および Enterprise プランで利用可能です。これらはルールフォルダ内のものとは異なり、次のように動作します。「Team Rules はフリーフォームのテキストです。Project Rules のフォルダ構造は使用しません。」 これらは glob をサポートし、Enforce this rule（このルールを強制する）としてマークできるため、ルールは「すべてのチームメンバーに必須となり、Customize で無効にすることはできません」。また、優先順位の最上位に位置します（「Team Rules → Project Rules → User Rules」となり、「適用可能なすべてのルールがマージされ、ガイダンスが競合する場合は、より早いソースが優先されます」）。
これは本当に有用な追加機能であり、チーム全体が依存していた Augment のワークスペースルールの移行先として最適です。
Cosmos Experts Memory に対応する機能はなく、これが本当の損失です。 Augment の Experts には、「共有仮想ファイルシステム（VFS）にスコープされた知識を保存し、将来のセッションで現在の会話に依存することなく、確立された好み、規約、教訓を適用できるようにする」記憶レイヤーがあります。Expert の記憶は「そのチームに属し、ワークフローに適したスコープで分離」されており、デフォルトで有効になっています（「Memory はすべての Template Experts で有効です」）。
また、シグナルの品質に応じて2つの異なるモデルを実行します。「Simple memory がデフォルトです。明示的で高品質な人間のフィードバックを、厳選されたナレッジファイルに直接書き込みます。」 代替手段として、「Noisy memory は、エビデンスログと厳選されたナレッジファイルを組み合わせて使用します。時間の経過とともにより弱いシグナルを組み合わせ、エビデンスが十分に強くなった後にのみ学習を促進します。」 両方とも「読者に対して同じ厳選されたナレッジビューを公開」します。
Cursor がドキュメント化している永続化メカニズムはルールです。ルールが何のためにあるのかについての Cursor 自身の位置づけは、それを直接物語っています。「大規模言語モデルは、補完（completions）間で記憶を保持しません。ルールは、プロンプトレベルで永続的かつ再利用可能なコンテキストを提供します。」 フィードバックから自動的に書き込まれる、チーム所有のスコープされた記憶ストアに相当するドキュメント化された機能は存在しません。そのため、Augment VFS に蓄積された学習内容は、切り替え後に考えるのではなく、切り替える前に計画を立てておくべき部分です。
手動での移行手順
ステップ 1: ルールファイルの変換（拡張子とフロントマターを同時に変更）
これら2つの編集は同じパス（一連の作業）で行ってください。一方だけを行うと、静かに機能しないファイルが作成されてしまいます。
.augment/rules/ 内の各ファイルについて、拡張子を .mdc に変更し、フロントマターを書き換えます。type: always_apply を持つ Augment ルールは alwaysApply: true になります。type: agent_requested を持つルールは、alwaysApply: false に加えて、すでに持っている description（説明）になります。Cursor は Augment と同様にこの説明を使用するため、そのまま保持してください。manual ルールは、説明も glob もない alwaysApply: false になり、ファイル名で @ メンションして使用します。
次に、2回目の確認を行い、本来 glob スコープにすべきルールを探します。説明が「X ファイルを操作するときにこれを使用する」といった内容になっているものは、代わりに globs の候補になり、判断をパターンマッチングに変換できます。また、Cursor はサブディレクトリのルールフォルダを許可しており、Augment は許可していなかったため、ネストされたガイダンスをルートから移動させるのもこのタイミングが最適です。
知っておくと便利な2つの機能があります。Cursor のチャットでの /create-rule は、「適切なフロントマターを持つルールファイルを生成し、.cursor/rules に保存」するため、説明可能なルールのフロントマターを手書きするよりも高速です。また、Cursor は GitHub リポジトリからルールをインポートできます。「リポジトリ内のすべての .mdc ファイルをスキャン」し、相対パスを維持したまま .cursor/rules/imported/<repoName> の下に配置します。複数のリポジトリを移行する場合は、共有ルールリポジトリに一度変換してインポートする方が、毎回変換するよりも手間が省けます。
~/.augment/rules/ の内容を Cursor の User Rules にコピーし、チームが従うべきものは Team Rules に昇格させます。個別にオフにすべきでないものには Enforce this rule（このルールを強制する）を使用します。避けるべきなのは、すべてを昇格させることです。「適用可能なすべてのルールがマージされ、ガイダンスが競合する場合は、より早いソースが優先されます」となるため、Project Rule と矛盾する大きな強制 Team Rule があると、ローカルで修正できない形で優先されてしまいます。
ステップ 2: アクセスできなくなる前に Experts の記憶を読み取る
このステップにはツールがなく、最も重要なステップです。
Augment は記憶を「独自の VFS ディレクトリの下に読み取り可能な Markdown として」書き出すため、探しに行けば解読可能です。探しに行きましょう。価値のある素材は、誰も二度と書き留めないようなものです。レビューのフィードバックから Expert が学んだコーディングスタイルの好み、繰り返しの修正から推測した規約、Code Review Memory Expert が数ヶ月分のコメントから抽出した教訓などです。
見つかったものを2つの山に分類します。ルールのように読めるもの（「常に API 境界でバリデーションを行う」「ここでは継承よりコンポジションを優先する」など）は、.mdc ルールまたは Team Rules になり、ステップ 1 でそのための仕組みはすでに構築されています。プロジェクトに関する事実のように読めるもの（なぜその決定が下されたのか、社内でその用語が何を意味するのか、どのサービスが何を所有しているのかなど）は、ルールファイルには一切属しません。ルールは「指示」であり、これらは「知識」です。これらを alwaysApply: true ファイルに詰め込むと、ルールディレクトリがプロンプトのたびにコンテキストを浪費するファイルキャビネットと化してしまいます。この違いこそが、コーディングエージェントが実際に読み取るもの の本質です。
また、手続き的に何を失うことになるのかを把握し、意識的に代替できるようにしてください。Augment の記憶は、何かを学習したときに教えてくれます。「インタラクティブなセッションでは、何かを記憶したときにそれを通知するため、修正や拒否（veto）を行うことができます。」また、状況が変わったときには、「現在のエビデンスが記憶されたルールと矛盾する場合に不一致のフラグを立てます。」ルールファイルはどちらも行いません。移行後は、このレビューの習慣はあなた自身が持つ必要があります。
より良い方法：知識をルールフォルダの外に置く
上記の手動ルートは指示をきれいに変換しますが、蓄積された知識を、適さないルールファイルにするか、誰も読まないドキュメントにしてしまいます。この2つ目の結果こそが、ツールの移行を「コストが高い」と感じさせる原因です。
代替案は、これら2つのレイヤーを意図的に分離することです。指示（「コミット前に lint を実行する」「2スペースのインデントを使用する」など）はルールに属し、ツールが許す限り厳密にスコープを設定します。プロジェクトに関する事実は、プロンプトのたびにロードされるものではなく、エージェントが必要なときに読み取るストアに属します。そうすれば、移行作業はフロントマターの変換だけに縮小され、次の移行はさらに簡単になります。MemoryLake は3つのステップでセットアップできます。
ステップ 1: API キーの作成
サインインし、ダッシュボードから API キーを生成します。これはルールディレクトリやワークスペースに紐づいていないため、Cursor からの要求であれ、CLI からであれ、あるいは来期に評価する他のツールからであれ、同じ知識を利用できます。
ステップ 2: 最初の記憶をアップロードする
上記のステップ 2 で分けた「2つ目の山」を投入します。アーキテクチャの決定とその理由、ドメイン用語、Augment Experts が学習していた永続的な好み、サービスの所有権、レビューで繰り返し回答している内容などです。
指示は .cursor/rules に残しておきます。ここは意図的に、ルールフォルダを複製する場所ではありません。
ステップ 3: AI とエージェントを接続する
Cursor をストアに向けます。.mdc ファイルは小さく振る舞いに関するものだけに保たれ、コンテキストの予算が背景の事実によって消費されるのを防ぎます。そして、来月参加するチームメンバーも、エージェントと同じ知識を読み取ることができます。この特性については、複数のツール間で1つの記憶を共有する で解説しています。
実務でこれがもたらす変化
最初の変化は、変換が機械的になることです。拡張子、フロントマター、完了。どの学習された規約をすべてのプロンプトに含めるべきかという判断は不要になります。
2つ目は、チームの知識がプランのティア（階層）に依存しなくなることです。Team Rules は Team および Enterprise プランの機能であり、フォルダ構造のないフリーフォームのテキストです。強制力を持たせるには便利ですが、ナレッジベースにするには適していません。
3つ目は、Augment が提供してくれた「レビュー可能性」を維持できることです。Augment の記憶は、何かを思い出したときにそれを通知し、矛盾にフラグを立ててくれましたが、ルールファイルは沈黙したままです。読み取り、監査、修正ができるストアを持つことで、その習慣を取り戻すことができます。これが AIが記憶している内容を監査する の目的です。
Augment Code から Cursor への移行におけるベストプラクティス
- 拡張子を
.mdcに変更し、フロントマターの書き換えを1回で行う。.cursor/rules内の.mdファイルはエラーなしで無視されます。 agent_requestedの説明（description）を保持する。 Cursor は関連性に基づく取り込みのために、同じようにdescriptionを使用します。- 散文によるスコープ指定を glob に変換する。 Cursor はコンテキスト内の一致するファイルに自動添付するため、条件を説明するよりも優れています。
- ルールのフラット化を解消する。 Cursor はネストされたルールディレクトリを許可します。Augment は
.augment/rules/をワークスペースのルートからのみロードしていました。 AGENTS.mdは手を加えずに移動する。 両方のツールがルートおよびサブディレクトリでこれを読み取ります。- Team Rules は強制用として残しておく。 これらはフリーフォームで、glob に対応し、優先順位の最上位にあり、オプションで無効化不可に設定できます。
- 移行する前に VFS の記憶を読み取る。 これは読み取り可能な Markdown ですが、自動でエクスポートしてくれるものはありません。
- レビューの習慣を自分自身で再構築する。 Augment は拒否（veto）のために新しい記憶を表示し、競合にフラグを立ててくれましたが、ルールファイルはどちらも行いません。
結論
この移行のルールの半分は、名前の変更とフロントマターの書き換えであり、Cursor の glob スコープモードとネストされたディレクトリは、これまでの環境を真に改善してくれます。
計画を立てる価値があるもう半分は、Augment の Experts の記憶（Memory）です。これは、チームスコープ、自動書き込み、2つのエビデンスモデル、拒否（veto）ステップを備えた本物のシステムです。一方、Cursor がドキュメント化している永続化への回答はルールであり、これは異なる役割を持っています。切り替える前にそれらのストアを読み取り、見つかったものを指示と事実に分割し、プロンプトのたびにコンテキストを請求されない場所に事実を配置してください。