実際に移行されるもの
Cursor と Codex はどちらも Markdown の指示を読み込みます。この類似性の裏には、重要な違いが隠されています。
ルールの内容はそのまま移行されます。 .mdc ファイルの Markdown 本文は、モデルへの単なる指示です。文章を書き直す必要は一切ありません。
ルールの有効化条件は移行されません。なぜなら、Codex には有効化モデルがないからです。 Cursor のプロジェクトルールは、フロントマター（description、globs、alwaysApply）を持つ .mdc ファイルとして .cursor/rules に保存され、その上に4つのモードが構築されています。
- Always Apply（常に適用） — すべてのチャットセッションに適用
- Apply Intelligently（インテリジェントに適用） — 説明に基づいてエージェントが関連性があると判断したときに適用
- Apply to Specific Files（特定のファイルに適用） — ファイルが指定されたパターンに一致したときに適用
- Apply Manually（手動で適用） — チャットで @ メンションされたときに適用
Codex のメカニズムは1つだけです。それは AGENTS.md であり、Codex のホームディレクトリ（~/.codex/AGENTS.md または $CODEX_HOME）からリポジトリのルート、中間ディレクトリを経てワーキングディレクトリへと階層的に解決され、近いファイルが優先される形で上から下へと結合されます。スコープは、glob や説明文ではなく、ファイルがどこに配置されているか によって決まります。「エージェントが関連性を判断する」というレイヤーは存在しません。
これが移行における問題のすべてを1文で表したものです。4つの条件付きモードを、1つの位置ベースのメカニズムにフラット化する必要があります。
`AGENTS.md` は直接移行されます。すでに作成している場合もあるでしょう。 Cursor は .cursor/rules の代替として、プロジェクトルート（サブディレクトリ内のネストされたファイルを含む）での AGENTS.md をサポートしています。ルールがすでにそこにある場合、移行作業のほとんどは不要（no-op）です。なぜなら、それこそがまさに Codex が求める形式だからです。
ユーザールールはグローバルファイルとして移行されます。 Cursor のユーザールール（User Rules）は、「Customize → Rules」で定義される、すべてのプロジェクトに適用されるグローバルな設定です。Codex におけるこれの同等物は ~/.codex/AGENTS.md です。意図は同じで、場所が異なるだけなので、コピー＆ペースト以外の変換は不要です。
MCP サーバー、設定、プラグイン、スラッシュコマンド、最近のセッションはインポーター経由で移行されます。 /import は6つの領域をカバーしています。settings.json から config.toml への変換、両方の JSON 方言における MCP サーバー、プラグイン、過去30日間の最大50件の最近のセッション、カスタムスラッシュコマンド、そしてプロジェクトスコープのメモリです。
移行できないものもあります。 Cursor の Web インターフェースからのチャット履歴はインポートできません（ローカルのセッションデータのみ）。インポートは一方向であり、Codex で変更した内容が Cursor に戻ることはありません。また、メモリの再現性は保証されません。Cursor の composer 履歴のようなツール固有の機能を参照するメモリは、Codex の動作モデルにマッピングされないため、インポート後に /memories list で確認する2分間の価値は十分にあります。
どちらの方向にも移行されないものが1つあります。それは、ルールの背後にある「推論」です。Cursor 自身のドキュメントには、なぜルールが存在するのかが率直に書かれています。「大規模言語モデルは、補完の間にメモリを保持しません。ルールは、プロンプトレベルで永続的かつ再利用可能なコンテキストを提供します。」 ルールは回避策であり、あなたが書き留めようと考えたことだけを保持する回避策にすぎません。
手動での移行手順
ステップ 1: 有効化方法ごとにルールを整理する
何かを実行する前に、各 .mdc ファイルを開き、フロントマターごとに分類してください。モードによって移行先が決まるからです。
`alwaysApply: true` → これらは、実際のスコープに一致するレベルの AGENTS.md に直接配置します。ルールが作業全体に対して本当にグローバルである場合は ~/.codex/AGENTS.md に、このリポジトリに関するものである場合はリポジトリのルートに配置します。考える必要のない、直接的な変換です。
`globs` を持つルール → これらは翻訳ではなく、配置が必要です。src/api/** にスコープされたルールは、src/api/ 内の AGENTS.md になります。Codex はそのディレクトリで作業するときにこれを読み込みます。これは、行う価値のある変換です。適切に行えばスコープの動作を維持できますが、怠ってルートファイルにすべて流し込んでしまうと、API 固有のルールが CSS にまで適用されてしまいます。
glob がディレクトリにきれいにマッピングされない場合（ツリー全体に散らばる **/*.test.ts など）、現実的な選択肢は2つあります。最も近い AGENTS.md 内に文章で条件を記述するか（「テストファイルを編集するときは、…」）、常に読み込まれることを受け入れるかです。文章による条件は glob マッチよりも弱く、モデルがその条件が適用されることに気づく必要があるため、適用漏れが発生しても影響が少ないルールにのみ使用してください。
Apply Intelligently を使用しているルール → これらは最も慎重に検討すべきものです。Cursor は実行時に description に基づいてルールが関連しているかどうかを判断していましたが、Codex はそれをしません。これらは、常にオン（リクエストごとにコンテキストを消費する）になるか、事実上消滅するかのどちらかになります。これらを整理し、重要なものはファイルに残し、あれば便利程度だったものは削除してください。すべてをルートファイルに移行しないでください。それは典型的な失敗パターンであり、誰もが後悔する肥大化した指示ファイルを生み出す原因になります。
Apply Manually（手動適用）ルール → これらは、意図的に取り込んでいた参照ドキュメントでした。これらはリポジトリ内のドキュメント（docs/ などで十分です）として保持し、AGENTS.md に「その種の作業を行う場合は、関連するファイルを読み込むこと」という指示を1行追加します。インライン化は避けてください。
移行のついでに、新しい環境でも Cursor 自体のサイズに関するアドバイスを適用しましょう。ルールは500行未満に抑え、大きなルールは構成可能な小さなパーツに分割します。これは Cursor においても優れたガイダンスですが、スコープ内にあるすべてがタスクごとに読み込まれる Codex においては、さらに重要なガイダンスとなります。
ステップ 2: /import を実行し、マッピングできなかった部分を修正する
Codex v0.145 以降を使用していることを確認し、プロジェクトルートで新しい Codex TUI セッションを開始して、/import を実行します。ソースとして Cursor を選択し、必要なカテゴリを選択します。/import にはローカルに組み込まれた TUI セッションが必要であり、リモートセッションやタスクの実行中には実行できないことに注意してください。
その後、インポーターが自動で行えないレビュー作業を行います。
- 生成された `AGENTS.md` を読みます。 Cursor 固有の概念（composer 履歴、@-メンションのワークフロー、Cursor 独自のツール名など）に関する表現は、書き直すか削除する必要があります。そうしないと、存在しない機能を使用するよう Codex に指示し続けることになります。
- glob スコープのルールを、ステップ1に従ってサブディレクトリの
AGENTS.mdファイルに配置します。インポーターはコンテンツを移動するだけで、フロントマターからディレクトリ構造を推測することはありません。 - `/memories list` を実行し、何が移行されたかを確認します。Cursor の仕組みを参照しているインポートされたメモリは、せいぜいノイズにしかなりません。
- MCP サーバーが実際に起動することを確認します。 両方の JSON 方言は変換されますが、変換された設定はあくまで設定にすぎません。Cursor で環境変数が必要だったサーバーは、Codex でも同様に環境変数が必要です。
次に、指示とは別の機能である Codex 独自のメモリ機能について決定します。ローカルの Codex メモリはデフォルトでオフになっています。 デスクトップアプリの「Settings → Personalization」で「Enable memories」をオンにするか、~/.codex/config.toml の [features] セクションで memories = true を設定して有効にします。EEA（欧州経済領域）、英国、スイスでは、Codex はそこで有効にした後にのみメモリを使用または生成します。これら2つの側面は個別に制御できます。
```toml [features] memories = true
[memories] generate_memories = true # extract memories from new sessions use_memories = true # inject memories into future sessions ```
有効にすると、Codex はスレッド間で、安定した設定、繰り返し発生するワークフロー、技術スタック、プロジェクトの規約、既知の落とし穴を保持し、サマリー、永続的なエントリ、最近の入力、および裏付けとなる証拠を ~/.codex/memories/ 以下に保存します。
オンにする価値は十分にあります。また、公式の注意事項も読んでおく価値があります。なぜなら、それが何であるかを定義しているからです。生成はアクティブなセッションや短時間のセッションをスキップし、残りのレート制限の割合が設定されたしきい値を下回ると一時停止し、チャット終了直後には更新されない場合があります。また、ファイルは手動で編集すべきではない自動生成された状態のものです。生成されたメモリフィールドから機密情報は削除されますが、ドキュメントでは共有前に確認することを推奨しています。そして、このストアはプロジェクトごとではなくグローバルであり、そのマシンに対してローカルです。同期は行われず、あるリポジトリのメモリが別のリポジトリで表面化することもあります。
より良い方法：エディタに依存しない単一のメモリレイヤー
ステップ1は興味深い作業でしたが、それがどのような作業であったかに注目してください。あるツールの有効化モデルを、別のツールのディレクトリレイアウトに翻訳する作業です。この努力は、再利用可能なものを何も生み出しません。次のエディタに移行するときに、また同じことを繰り返すことになります。
また、ルールファイルに一度も存在しなかったため、この移行にはまったく現れないカテゴリの知識もあります。なぜリトライ処理が間違っているように見えて実は正しいのか。クライアントが3月に却下した内容は何か。金曜日の午後6時に発見した制約は何か。ルールは、あなたが机に向かって書くことを決めた内容だけを保持します。残りの知識は、エクスポートしても残らないスレッドの中に眠っています。
そのレイヤーをエディタの外に保持することが、これら両方の問題を解決する鍵となります。MemoryLake は、ツールが読み取るためのメモリレイヤーです。意思決定、ドキュメント、蓄積されたコンテキストを1つのストアにまとめ、MCP 経由で Codex や Cursor から、また API を通じて他のあらゆるものからアクセスできます。次の移行は、変換プロジェクトではなく、単なる設定の追加になります。
公平を期すために言うと、.cursor/rules や AGENTS.md には確かなメリットがあります。これらはプレーンテキストであり、リポジトリ内に存在し、プルリクエストでレビューされ、チームメンバーは何もしなくてもそれらを引き継ぐことができます。恒久的なルールにはこれらを使用し続けてください。それが彼らの得意分野であり、Codex もこれらをネイティブに読み込みます。メモリレイヤーが真価を発揮するのは、毎回読み込むには長すぎるもの、公開するには特定すぎるもの、あるいは誰かが書き留めておくことを忘れて失われやすいものです。
ステップ 1: API キーを作成する
キーを生成し、約30秒で最初のリクエストを実行します。設定ファイルではなく、環境変数やシークレットマネージャーに保存してください。設定ファイルは、まさにこのような移行の際にコピーされ回るものだからです。
ステップ 2: 最初のメモリをアップロードする
ルールでは捉えきれなかったコンテキストを保持するドキュメント、画像、ファイルを投入します。理由付きのアーキテクチャ決定、奇妙なリトライを説明するインシデント報告書、クライアントの制約などです。可能な限り、サマリーではなくソース自体をアップロードしてください。
ステップ 3: AI とエージェントを接続する
Claude、Codex、OpenClaw、その他の AI エージェントに、MCP または API 経由でメモリへのアクセス権を付与します。Codex は MCP サーバーをサポートしており、インポーターはすでに既存の MCP 設定を変換しているため、これはサーバーエントリを1つ追加するだけです。同じストアは、Cursor を使い続ける場合でも、API を使用して構築するあらゆるものからでも読み取ることができます。
実務における変化
第一の違いは、ルールの移行が「不可逆（ロスあり）」ではなくなることです。現状では、有効化ロジックや書き留められていない知識が失われますが、移行後は、純粋にファイルである部分のみを変換するだけで済みます。
第二に、両方のエディタを併用することが当たり前になります。多くの人が、編集には Cursor を使い、より長いエージェントの実行には Codex を使用しています。現在、これは同じ規約のコピーを2つのフォーマットで維持し、それらが乖離していくのを見守ることを意味します。両方が読み取る単一のストアがあれば、この重複は解消されます。これは、MCP 経由で共有メモリを接続することが、ツールごとではなく一度だけ行う価値があるのと同じ理由です。
第三に、マシンからの独立性です。Codex のメモリは設計上ローカルであるため、完璧に移行した後でも、2台目のノート PC は空の状態でスタートします。メモリレイヤーにはそのような制約はありません。
そして、指示ファイルが小さくなります。これは Cursor よりも Codex において重要です。スコープ内にあるすべてがすべてのタスクで読み込まれるため、Codex がプロジェクトコンテキストなしで各セッションを開始するという問題は、より長いルートファイルではなく、検索（リトリーバル）によって解決すべき問題だからです。
移行のベストプラクティス
ファイル単位ではなく、有効化モード単位で変換する
直感的にはファイルごとに移行したくなりますが、代わりにフロントマター（alwaysApply、globs、説明ベース、手動）で分類してください。各モードで移行先が異なり、そのうちの1つ（Apply Intelligently）には移行先がまったく存在しないからです。ファイルごとの移行を行うと、最終的にすべてがルートの AGENTS.md に集まってしまいます。
スコープされたルールはスコープされたディレクトリに配置する
API レイヤーに関するルールは、API ディレクトリ内の AGENTS.md に配置します。これは移行全体の中で最も価値のある習慣です。失われがちなスコープを維持し、ルートファイルを短く保つことができます。また、新しいチームメンバーがコードのある場所でそのルールを発見できることも意味します。
インポートを過信せず、必ずレビューする
/import は優れていますが、翻訳機ではありません。出力を確認し、Cursor 固有の表現を削除し、/memories list を実行し、MCP サーバーが起動することを確認してください。ここで15分かけることで、エージェントが別のツール向けに書かれた指示に何ヶ月も従い続けるのを防ぐことができます。
何を本当に「常にオン」にするべきか判断する
スコープ内にあるすべてのものは、永続的にリクエストごとのコンテキストを消費します。以前は条件付きだったルールを「常にオン」に昇格させる前に、すべてのタスクでそのコストを支払う価値があるかを自問してください。ほとんどの Apply Intelligently ルールはそのテストに不合格となり、それらを削除することは、引きずり続けるよりも良い結果をもたらします。
結論
機械的な部分は簡単になりました。Codex v0.145 は、Cursor の設定、MCP サーバー、プラグイン、セッション、スラッシュコマンド、プロジェクトスコープのメモリを1つのコマンドでインポートします。判断が必要なのは、Cursor の4つの有効化モードが Codex の単一の位置ベースのメカニズムに統合される点です。そのため、alwaysApply ルールはそのまま移行し、glob スコープのルールはサブディレクトリの AGENTS.md ファイルにし、説明トリガーのルールは昇格させるか意図的に削除し、手動ルールは参照先のドキュメントとして残す必要があります。
そして、この移行が決して触れることのないレイヤーがあります。なぜなら、それはファイルに存在しなかったからです。両方のエディタが読み取るストアにそれを保持することは、「ルールを移行する」ことと「知識を移行する」ことの違いであり、次の移行で再び午後を丸ごと潰さずに済むようにするための鍵となります。