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

まず、各ツールの公式ドキュメントに記載されている内容から確認しましょう。ギャップは、多くの人が予想する場所とは異なる部分にあるからです。

Cursor のルールに関するドキュメントでは、ルールの目的と存在理由が明確に説明されています。

"Large language models don't retain memory between completions. Rules provide persistent, reusable context at the prompt level."

ルールはコンテキストとして注入されます。「適用されると、ルールの内容はモデルコンテキストの先頭に含まれます。」各プロジェクトルールはフロントマター（frontmatter）を持つ .mdc ファイルであり、フロントマターのフィールドによって4つの適用タイプのいずれかが決定されます。それらは、Always Apply（常に適用）、Apply Intelligently（「説明に基づいてエージェントが関連性があると判断したとき」に適用）、glob パターンによる Apply to Specific Files（特定のファイルに適用）、および @ メンションによる Apply Manually（手動で適用）です。Cursor は優先順位のチェーンについてもドキュメント化しています。「ルールは次の順序で適用されます：Team Rules → Project Rules → User Rules。適用可能なすべてのルールがマージされ、ガイダンスが競合する場合は、より早いソースが優先されます。」

Amazon Q Developer のプロジェクトルールはフォルダ内に配置され、プレーンな Markdown ファイルです。

"Project rules are defined in Markdown files in the project's {{project-root}}/.amazonq/rules folder."

そして、これらは明示的な条件なしで適用されます。

"Once you've created your project rules, Amazon Q will automatically use them as context whenever a developer chats with Amazon Q within your project, and will make sure to adhere to them when generating answers."

コントロールインターフェースはチャットパネルの「Rules」ボタンであり、ここにルールが一覧表示され、現在のセッションに対して各ルールのオン/オフを切り替えることができます。「チェックマークが付いているルールがアクティブになり、会話に適用されます。」同じ .amazonq/rules フォルダは、GitLab や GitHub の Amazon Q Developer でもドキュメント化されているため、このレイヤーは IDE 限定のものではありません。

したがって、移行の実態は次のようになります。ルールのコンテンツはきれいに移行できます。どちらのツールでも Markdown ファイル内の文章だからです。しかし、ルールの条件分岐（適用条件）は移行できません。Cursor の4つの適用タイプは、Amazon Q ではドキュメント化された1つの動作（常に適用）とセッションごとのチェックボックスに集約されます。Amazon Q のプロジェクトルールのドキュメントには、glob マッチング、説明に基づく検索、または手動の @ 呼び出しのためのフロントマターフィールドに関する記述は一切ありません。

また、移行できない2つ目の要素があり、これこそが事前に対策を立てておくべき重要なポイントです。Amazon Q には独自の自動生成コンテキストレイヤーがあり、それはまさにこれからルールを移行しようとしているのと同じフォルダ内に作成されます。

手順は2つあります。1つ目は機械的な作業で、2つ目は多くの人が見落としがちな作業です。

ステップ 1: フロントマターを削除し、条件を文章に組み込む

Cursor はファイル拡張子に厳格です。「各ルールは .mdc ファイルであり、名前は自由に設定できます。プロジェクトルールは .mdc 拡張子を使用する必要があります。.cursor/rules 内のプレーンな .md ファイルは、description、globs、alwaysApply を指定するフロントマターがないため、ルールシステムによって無視されます。」

Amazon Q は逆の方向で同様に明確です。ルールファイルは .amazonq/rules 内の「Markdown ファイルでなければならない」とされており、ドキュメントにはフロントマターのないプレーンな文章が示されています。

ここに「そのままコピーする」という罠があります。.cursor/rules/api.mdc をそのまま .amazonq/rules/api.md にコピーすると、description、globs、alwaysApply という3行の YAML フロントマターが、それを解釈する機能を持たないファイルに持ち込まれることになります。Amazon Q はエラーを吐きません。フロントマターを単なるルールテキストの一部として扱い、それらのフィールドが表現していた条件分岐は単に機能しなくなります。

そのため、ルールごとに以下の対応を行ってください。

Always Apply（常に適用）だったルールについては、フロントマターを削除するだけで完了です。これはきれいに移植できます。Cursor でも Amazon Q でも無条件で適用されるルールだからです。

Apply to Specific Files（特定のファイルに適用）だったルールについては、フロントマターを削除し、ルールの最初の文にその適用範囲を記述します。たとえば、glob が **/*.test.ts だったルールは、テストファイルを対象とすることを明記した文から始まるルールに変更します。これにより、システムによって強制されていた条件を、文章による指示へと変換することになります。率直に言って、これは精度の面ではダウングレードです。モデルはマッチしたパスからではなく、あなたの記述した言葉から関連性を判断するようになるからです。

Apply Intelligently（インテリジェントに適用）だったルールについては、description フィールドが検索のシグナルでした。これを冒頭の行に組み込んでください。メタデータとしてではなく、通常の文章として機能させる必要があるためです。

Apply Manually（手動で適用）だったルールについては、本当に常にオンにしておきたいかを検討してください。これらのルールの一部は、デフォルトでトリガーされるべきではないからこそ手動に設定されています。そうしたルールは .amazonq/rules から完全に除外し、必要なときに意図的に呼び出せる別の場所に保管するのが賢明です。

Cursor 自身が推奨するルールの作成アドバイスは、移行後も有効であり、心に留めておく価値があります。ルールは500行未満に抑え、「内容をコピーするのではなくファイルを参照する。これによりルールを短く保ち、コードの変更に伴ってルールが古くなるのを防ぐ」ようにします。

以前にルールの変換を行ったことがある方なら、この形式に見覚えがあるでしょう。moving Cursor rules to a Codex AGENTS.md でも、異なる出力フォーマットで同じフロントマターの問題に直面します。

ステップ 2: 手動で作成したルールを再生成パスから保護する

Amazon Q はプロジェクトのメモリバンクを自動生成できますが、ここに移行における落とし穴があります。

"Amazon Q can automatically generate memory bank files that provide a quick index of your project's structure, technology stack, and product information. This feature analyzes key files in your project to create summary files that help Amazon Q understand your codebase without having to analyze the entire project each time you ask a question."

生成されるファイルは、product.md、structure.md、tech.md、guidelines.md の4つで、これらは .amazonq/rules 配下の memory-bank サブフォルダに書き込まれます。これは、先ほど Cursor のルールを移行したのと同じフォルダツリーです。

この更新プロセスは「編集」ではなく「再構築（再生成）」です。

"If your project changes, you can have Amazon Q generate new memory bank files to update its context. To do so, choose the Rules button and then select Regenerate Memory Bank."

これにより、2つの結果が生じます。第一に、チームメンバーが memory-bank/ 内に手動で書き込んだ内容は、次回の再生成時にすべて上書きされて消えてしまいます。第二に、そしてより重要なこととして、これら4つのファイルはコードを分析して生成されるため、コードにすでに書かれている内容しか含まれません。「別の HTTP クライアントは使用しないこと」といったルールを設けていた理由は、コード内には存在しません（その別のクライアントはコード内に使われていないからです）。再生成プロセスがそのようなルールを自発的に生成することは決してありません。

これは、この分野でよく知られている別のメモリバンクと比較すると分かりやすいでしょう。Cline's Memory Bank は、エージェントが作業の進行に伴って読み込み、更新するように指示されたファイル群であり、その内容はエージェントが記録したプロジェクトの状態です。Amazon Q のメモリバンクは名前こそ同じですが、ソースは真逆で、リポジトリから自動生成されます。どちらが優れているというわけではなく、異なる課題に対するアプローチです。一方がもう一方と同じように動作すると誤解することが、チームがコンテンツを失う原因になります。

したがって、これら2つのレイヤーは物理的に分けて管理してください。移行したルールは、個別のファイルとして .amazonq/rules/ の直下に配置します。memory-bank サブフォルダは自動生成に任せ、派生した出力として扱います。生成される内容をコントロールしたい場合、Amazon Q はサポートされている方法をドキュメントで提供しています。それは、希望するフォーマットを記述したルールを .amazonq/rules に配置することです。これは優れた特性です。自動生成されるレイヤーが、手動で作成したレイヤーによって制御されるため、その逆にはなりません。

上記の作業はすべて「翻訳（変換）」作業であり、次にツールを変更するときにも同じことを繰り返すことになります。コストがかかり続ける原因は、ファイル形式そのものではありません。各ルールの背後にある「意思決定の理由（reasoning）」が、ツール固有のファイル以外にどこにも保存されていないことです。

MemoryLake は、その意思決定の理由を両方の製品の外部に保存し、MCP または API を介して、要求してきたエージェントに提供します。Cursor はルールを保持し、Amazon Q はメモリバンクをそのまま維持します。MemoryLake はそれらと並行して動作し、どちらのツールも保存するように設計されていないレイヤー（何を決定し、何を却下し、それはなぜか）を保持します。

ステップ 1: API キーを作成する

キーを生成すれば、約30秒で最初のリクエストを送信できます。ルールファイルの書き換えを始める前にこれを行っておくことで、作業を進めながら意思決定の理由を保存する場所を確保できます。

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

上記のステップ1で各 .mdc ファイルを処理する際、なぜそのルールが存在するのかを再確認することになります。その過程で、コーディング規約、却下した代替案、その背景にある障害や制約などを記録してください。関連するドキュメント、図、ファイルなども一緒に追加できます。

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

Claude、Codex、OpenClaw、および Amazon Q に MCP または API 経由でアクセス権を付与します。意思決定レイヤーに問い合わせができるエージェントは、「なぜこれがここでの規約なのか」という問いに対して、単にルールを繰り返すのではなく、その理由を添えて回答できるようになります。

最も直接的な変化は、ステップ1で失われた条件分岐がそれほど重要ではなくなることです。glob スコープのルールが存在していた理由の一つは、無関係なガイダンスがコンテキストウィンドウを圧迫するのを防ぐためでした。意思決定の理由が、エージェントが必要に応じて照会するストアに保存されていれば、.amazonq/rules は常に適用すべき基本コマンドだけに絞って非常に短く保つことができます。そして、その他の細かなルールは、適用される可能性があるからといって事前に読み込むのではなく、関連性があるときにのみ取得されます。

2つ目の変化は、最初の Regenerate Memory Bank（メモリバンクの再生成）を実行したときに現れます。保存しておくべき価値のある情報は自動生成されたファイルには最初から含まれていないため、何も失われることはありません。

3つ目は、部分的な移行が問題にならなくなることです。多くのチームが、異なるリポジトリやチームの半分ずつで、Cursor と Amazon Q を何ヶ月も並行して運用しています。2つのフォーマットで2つのルールフォルダを運用すると、内容が乖離（ドリフト）していきます。しかし、両方のエージェントが読み取る単一の意思決定レイヤーがあれば、乖離は発生しません。

4つ目は、次の移行時に訪れます。ルールファイルは再び変換する必要がありますが、意思決定の理由は変換する必要がありません。そもそもルールファイルの中に保存されていたわけではないからです。

ルールは1つずつ移行し、それぞれに目を通してください。 一括コピーは、この移行における典型的な失敗パターンです。移行先では意味を持たないフロントマターがそのまま残り、極めて重要だった適用条件が静かに破棄されてしまうからです。

memory-bank/ 内で手動でルールを作成しないでください。 これは自動生成される出力です。作成するファイルは .amazonq/rules/ の直下に直接配置してください。

以前 glob を使用していたルールでは、適用範囲を明記してください。 ルールの冒頭で、それが適用されるファイルやディレクトリを指定します。システムによる強制的な条件を文章による表明に変換したのですから、その表明を見落とせないものにしてください。

ルールを使用して生成内容をコントロールしてください。 Amazon Q は、プロジェクトルールを介してメモリバンクの出力をカスタマイズすることをサポートしています。これが、手動作成レイヤーと自動生成レイヤーの間のドキュメント化された接合点です。生成されたファイルを直接編集するのではなく、この方法を使用してください。

ピン留め（pinning）が万能だと思わないでください。 コンテキストのピン留めは VS Code IDE でのみ利用可能とドキュメントに記載されており、ピン留めされたアイテムは現在のチャットタブにのみ適用されます。新しいタブを開くとリセットされます。これは会話ごとの一時的な利便性を提供するものであり、永続的なプロジェクトレイヤーではありません。

「なぜそうするのか」を、どちらのツールにも依存しない場所に一度だけ書き留めておきましょう。 これこそが、繰り返す必要のない唯一の作業です。

Cursor から Amazon Q Developer への移行は、両者ともプロジェクトフォルダ内で Markdown を使用しているため、過小評価されがちです。コンテンツは移植できますが、条件分岐は移植できません。Cursor のドキュメントに記載されている4つの適用タイプに対応するものは、Amazon Q のプロジェクトルールには存在せず、.mdc のフロントマターにある4つのフィールドは、そのままコピーすると単なる機能しないテキストになってしまいます。

2つ目に正しく理解すべきなのは、フォルダ管理の規律です。Amazon Q のメモリバンクは、同じ .amazonq/rules ツリーのサブフォルダに生成され、編集ではなく再構築されます。これはコードベースに含まれる内容の非常に便利なインデックスですが、まさにその理由から、コードベースに含まれていない意思決定を保持することはできません。

慎重に変換を行い、手動作成したコンテンツと自動生成されたコンテンツを別々の場所に保管し、次のツール変更時にも残る場所に意思決定の理由を保存してください。そうすれば、この特定の変換作業をゼロから行うのはこれが最後になります。