実際に移行できるもの
ファイル名の変更と4行のフロントマターを追加した、ステアリングファイル。 これが移行の核心であり、マッピングは非常にシンプルです：
Kiro ステアリング inclusion: | Cursor ルールタイプ | Cursor フロントマター |
|---|---|---|
always (デフォルト) | Always Apply | alwaysApply: true |
fileMatch + fileMatchPattern | Apply to Specific Files | globs 設定、alwaysApply: false |
auto + name + description | Apply Intelligently | description 設定、globs なし |
manual | Apply Manually | description なし、globs なし |
水面下では、どちらも同じように動作します。Kiro の auto モードは「ステアリングファイルが関連するタイミングを判断するために description（説明）を使用」します。Cursor の同等機能は「ルールの description が Cursor Agent に提示され、適用すべきかどうかが判断」されます。Kiro の manual ファイルは #steering-file-name で呼び出されますが、Cursor のものは @ メンションで呼び出されます。各ファイルを .mdc にリネームし、対応するフロントマターを追加すれば、以前と同じ動作を再現できます。
常時オンのルールとしての、ファウンデーションファイル。 Kiro の product.md、tech.md、structure.md は「デフォルトですべてのインタラクションに含まれます」。これらは alwaysApply: true ルールになります。ただし、変換する前に一度目を通してください。Kiro 自身のステアリングガイドラインでは、コードベースにすでに記載されている内容を重複して記述しないよう警告しており、Cursor のルールドキュメントでも同様のアドバイスがなされています。ディレクトリ一覧がほとんどを占める structure.md は、移植するのではなく削減する価値があります。その理由は Cursor にプロジェクトのファイル構造を記憶させる方法 で解説しています。
変更なしの AGENTS.md。 両方のツールがこれをサポートしています。Kiro はワークスペースのルート、~/.kiro/steering/、およびサブディレクトリからこれを読み込みます（「AGENTS.md ファイルはインクルージョンモードをサポートしておらず、常に含まれる」とされています）。Cursor は「プロジェクトのルートおよびサブディレクトリにある AGENTS.md をサポート」しており、.mdc ルールのプレーン Markdown 代替案として明示的に推奨しています。ステアリングの大部分がもともと常時オンであったなら、AGENTS.md の方が摩擦の少ない移行先となります。
ディレクトリの移動、または移動すら不要な Skills。 Cursor は .agents/skills/、.cursor/skills/、~/.agents/skills/、~/.cursor/skills/ に加え、「互換性のために」.claude/skills/、.codex/skills/、~/.claude/skills/、~/.codex/skills/ も読み込みます。両方のツールが同じオープンな Agent Skills 標準に基づいているため、SKILL.md ファイルはそのまま移行できます。動作上の違いが1つあります。/ で呼び出された Cursor のスキルは「1つのメッセージにアタッチ」されます。セッション全体で有効にし続けるには、Option+Enter でカスタムモードとして実行する必要があります。
ファイルとしては残るが、ワークフローとしては残らない specs。 Kiro の spec は .kiro/specs/<name>/ 内に requirements.md（または bugfix.md）、design.md、tasks.md として存在します。これらはリポジトリ内の Markdown ファイルであるため、移行後もそのまま読み取り可能です。しかし、それらを取り巻く3フェーズのワークフロー（要件定義 → 設計 → タスクの進行、承認ゲート、リアルタイムのタスクステータス）は失われます。
Cursor における最も近い機能は Plan Mode（プランモード）です。これは決して侮れない機能で、「コードを書く前に詳細な実装プランを作成」し、「チャットまたは Markdown ファイルを通じてプランを確認・編集」でき、洗練されたプランから元に戻して再実行することも可能です。ただし、成果物の保存先に注意してください。「プランはデフォルトでホームディレクトリに保存されます。『Save to workspace』をクリックすると、将来の参照、チームでの共有、ドキュメント化のためにワークスペースに移動できます。」Kiro の spec はデフォルトでリポジトリ内にありました。Cursor のプランはデフォルトでホームディレクトリにあります。このデフォルトの違いが、チームの成果物か個人の成果物かの違いを生みます。
それ以外は何も移行できません。その理由はアーキテクチャにあります。 Kiro は3つのメモリサーフェスを維持しています。Cursor のドキュメントインデックスにはメモリに関するページがありません。
Kiro Crew の6つのレイヤーには移行先がありません。 Crew は preferences.md と projects.md（どちらも30メッセージごとにコンソリデータによって丸ごと置換されます）、段階的に減衰する history/ ディレクトリ、SQLite セマンティックストア、ベクトル検索を備えたエピソードストア、そして学習された修正のための lessons ストアを保持しています。各レイヤーには文字数制限と独自の減衰ルールがあります。履歴は14日後に「1日あたりの最初の入力 + カウント」に減少し、181日後に読み込みが停止し、365日後に「ディスクから削除」されます。Lessons は最大50エントリーに制限され、「ユーザーの明示的な指示が常に優先される」ようにマークされます。これは本格的なメモリシステムであり、Cursor にはそれを受け入れるコンテナがありません。
Kiro Web の学習されたメモリも同様に移行できません。 これはプルリクエストに対するフィードバック（「タスクを作成したユーザーであるあなたのフィードバックのみが、エージェントの学習に影響を与えます」）から構築され、ユーザーが制御できるのは削除のみです。
Crew のスナップショットはバックアップであり、エクスポートではありません。 kirocrew snapshot は、メモリ、ワークスペース、cron、設定、スキル、通知をカバーする単一の tarball を生成します。これはマシン間で移行するための正しい方法であり、Kiro もまさにそのようにドキュメント化しています。しかし、これを読み込めるのは Kiro だけであるため、これは移行元の安全なコピーに過ぎず、移行先へのインポートファイルではありません。取り扱いには注意してください。Kiro は「スナップショットには機密データ（監査ログの整合性のために使用されるセキュリティキー）が含まれています」と警告しています。
手動移行の手順
ステップ 1: スナップショットを取得し、失われようとしているレイヤーを確認する
何よりも先に kirocrew snapshot ~/migrate を実行してください。Cursor がそれを読み込めないとしても、コピーは手元に残しておくべきです。また、Crew の組み込みのデイリージョブは「直近の7つのスナップショットのみを保持」するため、昨日のものがまだ残っているとは限りません。
次に、コピーするのではなく、内容を読んでください。~/.kiro/crew/workspace/memory/preferences.md と projects.md を開きます。これら2つのファイルは「30メッセージごとにコンソリデータによって丸ごと置換され、追記型ではない」ため、ログではなく、Crew が捉えている現在のあなたのモデルのスナップショットです。そこに書かれている内容は、Crew が「今重要である」と判断していることそのものであり、短くも非常にシグナル密度の高い読み物となります。
次に、最大50エントリーに制限されている lessons（学習された修正）を確認します。これらは、あなたが Crew に常に実行するよう指示したことや、修正して実行させた内容です。リポジトリ内のどこにもこれらを示唆する情報はないため、Cursor がこれらを自動的に再構築することはありません。
また、~/.kiro/steering/ にあるグローバルステアリングも確認してください。Kiro は、競合が発生した場合にグローバルよりもワークスペースのステアリングを優先して解決します。Cursor の優先順位は「Team Rules → Project Rules → User Rules」であり、「ガイダンスが競合する場合は、より上位のソースが優先」されます。プロジェクトルールが個人ルールより優先されるという点では挙動の半分は維持されますが、Cursor の Team Rules を使用する場合、両方よりも優先される新しいレイヤーが加わることになります。
ステップ 2: ステアリングを .mdc に変換し、プレーンのまま残すものを選択する
.kiro/steering/ 内の各ファイルについて、そのフロントマターを読み、上記の表の行を参照して、Cursor の同等物を記述します。fileMatch ファイルは globs の値になり、auto ファイルは description を保持して name を削除します。常時オンのファイルは alwaysApply: true になり、どちらも必要ありません。
機械的ではなく、手動で行う価値のある2つの変換があります：
File 参照が機能しなくなります。 Kiro のステアリングは #[[file:api/openapi.yaml]] を使って生のファイルを埋め込むことができたため、ファイルが変更されてもステアリングのテキストは最新の状態に保たれていました。Cursor のルールには同等のディレクティブがありません。コンテンツをインライン化するか（古くなることを許容する）、文章中でパスを参照してエージェントに読み込ませるかのどちらかを選択してください。
カスタムエージェントのリソースリストに対応するものがありません。 Kiro のカスタムエージェントを設定していた場合、それらには「ステアリングファイルが自動的に含まれない」ため、多くの場合 {"resources": ["file://.kiro/steering/**/*.md"]} のように明示的にリストアップする必要があったことを思い出してください。Cursor はモードに関係なくフロントマターに従ってルールを適用するため、これらの明示的なリソースリストの変換先はありません。ステアリングなしで意図的に実行されていたエージェントがないか確認してください。その意図は引き継がれません。
ステアリングの大部分が常時オンかつプレーンなものであった場合、それらのファイルについては .mdc を完全にスキップし、コンテンツを AGENTS.md に記述することを強くお勧めします。Cursor のドキュメントでも、「構造化されたルールのオーバーヘッドなしに、シンプルで読みやすい指示を必要とするプロジェクト」に対して、まさにこの方法を推奨しています。.mdc は、本当に globs や description を必要とするファイルのために残しておきましょう。
チームを移行する場合の最後の注意点として、Kiro のチームステアリングは「MDM ソリューションまたはグループポリシーを介して」マシンにファイルをプッシュすることで配布されていました。Cursor の Team Rules は、Team および Enterprise プランのダッシュボードから管理され、「そのチームのすべてのリポジトリとプロジェクトに適用」されます。また、「Enforce this rule（このルールを強制）」としてマークできるため、メンバーがオフにすることはできません。これはより優れたメカニズムですが、フリーフォーマットのテキストです。Team Rules は「Project Rules のフォルダ構造を使用しない」ため、ステアリングファイルのディレクトリをフラット化する必要があります。
より良い方法：学習されたデータをエディタの管理外に保管する
この移行の2つの側面がどのように異なる挙動を示したかに注目してください。あなたが書き留めたものはすべて移行できました。ステアリングはルールになり、AGENTS.md はそのまま残り、スキルは変更不要で、spec は読み取り可能なまま維持されました。一方で、ツールが学習したものは何一つ移行できませんでした。
この分断は Kiro や Cursor の問題ではありません。Kiro は精巧な学習メモリシステムを構築し、それを ~/.kiro/ 以下に保持しています。Cursor は意図的に異なる選択をしました。永続的なコンテキストはバージョン管理されたルールファイルとスキルに存在するため、ルールはレビュー可能であり、ドキュメントにはメモリに関するページがありません。どちらも一貫した設計です。しかし、どちらも「なぜそのアプローチを却下したのか」という唯一の記録を保管する場所としては適していません。
それこそが MemoryLake が保持するものです。プロジェクトの永続的な知識をツールがクエリするレイヤーに保持することで、学習されたデータが「たまたま開いたエディタ」の所有物ではなくなります。セットアップは3つのステップで完了します。
ステップ 1: API キーを作成する
サインインして API キーを作成します。接続するすべてのツールで共通の認証情報として使用できます。
ステップ 2: 最初のメモリをアップロードする
1つのエントリーにつき1つの主張を含む、短いエントリーを作成します。ステップ1で読み取った内容から直接書き出してください：
1エントリーにつき1つの、あなたの lessons。 Crew で最大50に制限されていた学習済みの修正です。これらはあなたが所有する最も価値が高く、最も復元が困難なデータです。
preferences.md と projects.md に現在書かれている内容。 これらはリアルタイムのスナップショットであるため、短いはずです。ファイルをそのまま貼り付けるのではなく、個別の主張に分割してください。
理由が添付された決定事項。 「負荷がかかるとレプリカが遅延するため、書き込みをキューに入れます。」ルールはポリシーを規定しますが、代替案が再浮上するのを防ぐのはその「理由」だけです。
このコードベースですでに却下されたアプローチ。 ステアリングファイルにも、ルールにも、コミットメッセージにも現れないカテゴリです。
ステップ 3: AI とエージェントを接続する
使用しているツールを接続します。MemoryLake は MCP および API 経由でアクセス可能であり、Kiro と Cursor の両方が MCP サーバーをサポートしています。そのため、移行期間中に同じ推論プロセスのコピーを2つ維持することなく、これらを並行して実行でき、他のアシスタントも API を通じて同じメモリを読み取ることができます。
3つの率直な制限事項があります。MemoryLake は Crew のスナップショットの読み込み、Kiro Web の学習されたメモリのインポート、および .mdc ファイルの書き出しを行うことはできません。 これらは Kiro のフォーマットであり、Cursor のステアリングサーフェスだからです。MemoryLake は、あなたやあなたのエージェントが入力した内容のみを保持するため、ステップ2は手動で行う必要があります。また、ルールは強制される設定ではなくコンテキストです。常に適用されるべきルールは、メモリレイヤーではなく、強制設定をオンにした Cursor の Team Rules に配置すべきです。
実務における変化
ステアリングの変換が、判断を伴う作業ではなく、単なる参照作業になります。 4つのモード、4つのルールタイプ、1つの表で完結します。
サイレントな未実行状態が発生しなくなります。 .cursor/rules 内のプレーンな .md は無視されます。適用する前にこの事実を把握できるようになります。
spec は読み取り可能なまま残り、ワークフローをどうするかは自分で決定できます。 ファイルは残りますが、承認ゲートは残りません。
プランは意図的に保存する必要があります。 Cursor のプランはデフォルトでホームディレクトリに保存されるため、「Save to workspace」を実行することで初めてチームの成果物になります。
スキルが特定のツールに依存しなくなります。 同じ SKILL.md が Kiro、Cursor、Claude Code、Codex で動作します。
メモリの減衰に驚かされることがなくなります。 Crew の履歴は14日後に詳細が失われ、365日後に削除されていました。この挙動自体を理解することには価値があります。詳細は 保持スコア付きメモリツリーが示したもの を参照してください。
Kiro から Cursor への切り替えにおけるベストプラクティス
開始前にスナップショットを取得し、tarball は共有ドライブ以外の場所に保管してください。 Kiro は、スナップショットに機密キーが含まれていることを警告しています。
preferences.md、projects.md、および lessons を読んでください。 丸ごと置換されるファイルは、その構造上、短くなっています。これらを確認しない手はありません。
.mdc にリネームしてフロントマターを追加するか、コンテンツを AGENTS.md に移動してください。 実際に読み込まれる選択肢はこの2つだけです。
常時オンかつプレーンな指示には AGENTS.md を優先してください。 Cursor もこれを推奨しており、移行期間中も両方のツールで動作します。
#[[file:…]] 参照は意図的に変換してください。 インライン化すると内容が古くなりますが、文章での参照にすれば最新の状態を維持できます。
structure.md は移植するのではなく、削減してください。 両ベンダーとも、コードベースの内容を再記述しないようアドバイスしています。
Team Rules を設定する前に、チームステアリングをフラット化してください。 これらはフォルダ構造ではなく、フリーフォーマットのテキストです。
常時オンのルールから推論プロセス（理由）を排除してください。 すべてのツールは保持する情報量に制限を設けており、推論プロセスが最初にカットされます。この一般的な問題については、コーディングエージェントが実際に読んでいるもの で解説しています。
結論
Kiro から Cursor への移行は、難易度の全く異なる2つの移行作業から成り立っています。記述されたデータの移行はほぼ機械的です。4つのステアリングインクルージョンモードは4つの Cursor ルールタイプにマッピングされ、AGENTS.md は両方で動作し、SKILL.md ファイルは変更不要で、spec はリポジトリ内で読み取り可能な Markdown として残ります。唯一の落とし穴はファイル拡張子です。.cursor/rules 内のプレーンな .md は完全に無視され、エラーも表示されません。
学習されたデータの移行は全く不可能です。Kiro Crew はホームディレクトリ以下に6つのメモリレイヤーを保持しており、それぞれに独自の制限と減衰スケジュールがあります。さらに、PR フィードバックから構築された Kiro Web の独立した学習メモリもあります。Cursor のドキュメントインデックスにはメモリに関するページがありません。これは、永続的なコンテキストをバージョン管理されたルールやスキルに配置する設計になっているためです。kirocrew snapshot は完全なバックアップを作成しますが、これを読み込めるのは Kiro だけです。
したがって、スナップショットを取得し、Crew が捉えている現在のあなたのモデルを保持する3つのファイルを読み、表に従ってステアリングを変換し、ファイルごとに .mdc と AGENTS.md のどちらにするかを決定し、lessons や却下されたアプローチを両方のエディタからクエリできる場所に保管してください。そうすれば、次のツール切り替えは単なる好みの問題となり、記憶喪失のような事態を避けることができます。