現在Codexのインポーターがカバーしているもの
Claude Codeの設定をほぼ丸ごと移行
当初のターゲットはClaude Codeであり、その範囲は多岐にわたります。Codexのドキュメントによると、指示ファイル、config.toml、settings.json、スキルとプラグイン、MCPサーバー設定、プロジェクトフォルダとメモリ、フックとスラッシュコマンド、サブエージェント、そして過去30日間のチャットを移行できます。CLIで /import を実行するか、デスクトップアプリのインポートフローを使用します。
試す前に知っておくべき制限事項があります。タスクの実行中、リモートセッションから、またはローカルのアプリサーバーデーモンに接続している間はインポートを利用できません。また、一部のプラグインはインポート後に再認証が必要です。
8月7日時点のCursor管理スキル
ここが新しい部分です。リリースノートは1文だけですが、その背景にあるマージされた作業がその仕組みを示しています。プルリクエストのタイトルは、「Migrate Cursor-managed skills into Codex（Cursor管理のスキルをCodexに移行する）」、「Parse Claude and Cursor session records separately（ClaudeとCursorのセッション記録を個別に解析する）」、「Preserve working directories when importing external sessions（外部セッションのインポート時に作業ディレクトリを保持する）」となっています。
最後の項目を読むと、彼らがどのような課題を解決しようとしていたかが分かります。セッションのインポートは単なるテキストではありません。セッションは特定のディレクトリにおいて意味を持つものであり、ディレクトリ情報を失ったインポートは、読むことはできても実用的に再開できない記録になってしまいます。
重複せず最新状態を維持する会話
リリースノートの後半部分は、さらに興味深いものです。「インポート済みのClaudeおよびCursorの会話への変更を重複させることなく同期する」機能は、「外部エージェントセッションのインポート済みアップデートの同期」として実装されています。
これまでは、インポートはスナップショットに過ぎませんでした。再度インポートすると、2つ目のコピーが作成されていました。現在では、再インポート時にすでに移行済みのデータと整合性が図られます。移行期間中に2つのツールを並行して実行している場合（多くの人が1〜2週間はそうします）、これは「おそるおそる一度だけ行うインポート」と「繰り返し実行できるインポート」ほどの大きな違いになります。
ただし、これが意味することに注意してください。同期するということは、そのデータのマスター（権限）は依然としてもう一方のツールにあるということです。これは両方を使用する期間の架け橋であり、管理権限の移転ではありません。
インポートされたチャットができること、できないこと
チャットのインポートには、ドキュメントに記載された制限があります。過去30日間、最大50件の会話です。これは意図的な範囲であり、この機能がアーカイブ目的ではなく、移行時の継続性のためのものであることを示しています。
これら50件の会話の価値を冷静に見極める必要があります。会話の書き起こし（トランスクリプト）はプロセスの記録であり、その大半は正解にたどり着くまでの「間違い」です。インポートされたチャットは、検索可能な最近の履歴と、金曜日に諦めたスレッドを再開する機能を提供します。しかし、結論を提供してくれるわけではありません。なぜなら、誰も探索プロセスから結論を切り離していないからです。もしそれらのチャットの中で意思決定が行われたとしても、チャットをインポートすることは決定を記録することとは異なり、後からそれを読み込むエージェントは、却下されたアプローチと最終的なアプローチをほぼ同等に評価してしまいます。
そして、変わらない境界線
インポーターのドキュメントには、今でもはっきりと「通常のClaudeチャットデータはインポートできません」と書かれています。ChatGPTのデータも取り込めません。これは人々を驚かせる非対称性です。OpenAI自身のCLIは、競合の開発者ツールを1つのコマンドで取り込める一方で、どちらのベンダーのコンシューマー向けアプリからも取り込むことはできません。
これは見落としではなく、一貫した判断です。/import は開発者向けのセットアップツールであり、コンシューマー向け製品のチャット履歴は開発者向けのセットアップではないからです。つまり、アシスタントがチャットアプリで構築したメモリの移行は、依然として手動で行う必要があり、それは独自の移行プロセスとなります。
人々が試みること
インポーターがすべてをカバーするのを待つ。 気持ちは分かりますが、そうはなりません。なぜなら、そのギャップは機能不足によるものではないからです。CursorやClaude Codeには、あなたの開発ルールの背景にある理由を保持するファイルは存在しません。誰もそれを書き残していないからです。インポーターは存在するデータしか移行できません。
インポートして、同じように動くと仮定する。 最もよくある落胆の原因です。ルール、スキル、MCPサーバーは移行されますが、新しいエージェントは依然として、あなたのチームが前四半期に却下したアプローチを提案してきます。移行中に何かが失われたわけではありません。その知識は最初からファイルの中に存在しなかったのです。
手動でルールを `AGENTS.md` にコピーする。 重視する部分については、今でもこれが正しい直感であり、インポーターがコンテンツを配置する場所でもあります。Codexは、~/.codex/AGENTS.md（または $CODEX_HOME）からリポジトリのルート、中間ディレクトリ、そして作業ディレクトリへと AGENTS.md を解決し、最も近いファイルが優先されます。場所ごとに整理することが、スコープを維持する方法です。
Codexのメモリをオンにして完了とする。 やる価値はありますが、完全な記録にはなりません。Codexのメモリはデフォルトでオフになっており、設定の「パーソナライズ（Personalization）」、または [features] memories = true で有効にします。これらは、チャットから派生した要約や永続的なエントリなどの生成された状態を保持し、~/.codex/memories/ に保存されます。これはプロジェクトごとではなくグローバルであり、そのマシンに対してローカルです。
両方のツールを永久に開き続ける。 正直な回避策であり、再インポートが同期されるようになったため、以前よりサポートが向上しました。しかし、これは2つの異なる基準セットを維持することを意味し、レビュー時にそれらがどこで分岐したかを発見することになります。
共通のパターン：すべての回避策は設定をうまく管理できますが、知識の管理には不向きです。
解決策：知識を両方のツールの設定から切り離す
移行するものを2つの山に分けましょう。それぞれ保管場所が異なるからです。
設定はツール内に置くべきであり、インポーターがそれを処理します。 ルール、スキル、MCPサーバー、フック、コマンド、サブエージェントなどは、/import に任せてから整理（クリーンアップ）しましょう。移行は、誰かがすべてのルールを新鮮な目で読み直す唯一の機会です。古いルールを引き継ぐのではなく、削除してください。
知識は両方のツールの外に置くべきです。 制約の背景にある理由、それを生み出したインシデント、却下した代替案、クライアントの要件、アーキテクチャの決定とその日付。これらはベンダーの設定ディレクトリに置くべきではありません。なぜなら、それらがツール変更のたびに「発掘作業」を強いる原因になるからです。
MemoryLake は、2つ目の山（意思決定、制約、ソースドキュメント）を1つのストアにまとめるメモリレイヤーです。ClaudeやCodexのようなMCP対応ツールから直接読み込むことができ、ChatGPTからはAPI経由で読み込めます。これにより、インポーターは設定の移行だけに集中でき、それはインポーターが実際に得意とする部分です。
ステップ 1: APIキーを作成する
キーを生成し、約30秒で最初のリクエストを送信します。セッションに直接貼り付けるのではなく、環境変数やシークレットマネージャーに保存してください。
ステップ 2: 最初のメモリをアップロードする
ルールの背景にあるドキュメント、画像、ファイルを投入します。ADR（アーキテクチャ決定記録）、インシデント報告書、クライアント要件、APIコントラクト、全員が合意したRFCなどです。要約ではなく、ソース自体をアップロードしてください。要約にしてしまうと、まさにその過程で理由が失われてしまいます。
ステップ 3: AIとエージェントを接続する
Claude、Codex、OpenClaw、その他のAIエージェントに、MCPまたはAPI経由でメモリへのアクセスを許可します。CodexとClaude CodeはどちらもMCPに対応しており、同じストアを直接読み込むことができます。ChatGPTの場合は、API経由で必要な情報を取得し、プロンプトやモデルを呼び出すワークフローに注入します。
実務における変化
最初の違いは、インポート作業が「退屈なもの」になることです。これはインポート作業に最も求められる性質です。設定が移行され、不要なものを整理すれば完了です。新しいエージェントが「これを知らない」と気づく日々を1週間も過ごす必要はありません。
2つ目の違いは、並行運用によるズレ（ドリフト）が発生しなくなることです。実際の移行期間中には両方のツールを使用することになりますが、会話はきれいに再同期されます。しかし、一方のツールで洗練させたルールは、もう一方には伝播しません。制約が共有ストアに存在する場合、両方のエージェントが同じ最新バージョンを読み込むため、何度も説明し直す必要があったコピーが2つのバージョンで存在し続けることはなくなります。
3つ目の違いは、ツールを解約しても同期が途切れないことです。同期は2つのベンダーのストア間の架け橋ですが、共有レイヤーはどちらのベンダーも所有していないストアです。古いサブスクリプションを解約しても、共有ストアは機能し続けます。
また、これは各ツールのネイティブメモリとも調和します。Codexのメモリはローカルであなたの習慣を学習し続け、Claude Codeのプロジェクトメモリはリポジトリごとにビルドコマンドを蓄積し続けます。どちらも有用であり、どちらもマシンローカルです。だからこそ、チームメイトが知るべき情報がそこだけに存在してはならないのです。これは、それぞれが個別にプロジェクトを学習するエージェントの背後にある課題と同じです。
コーディングエージェント間でインポートする際のベストプラクティス
インポートしたその日に整理する
移行されたものはすべて、今後あなたがメンテナンスしていくことになります。すべてのルールを一度読み、すでに存在しないサービス向けに書かれたルールを削除し、残りを簡潔にまとめます。Codexはセッションごとに AGENTS.md をコンテキストに読み込むため、長すぎると重要なルールの遵守率が低下します。
スコープをディレクトリの位置として再表現する
Cursorはアクティベーションモードやglobパターンでスコープを表現しますが、Codexはファイルが置かれている場所で表現します。請求（billing）サービスにのみ適用されるルールは、ルートファイルに修飾子を付けて書くのではなく、billing/AGENTS.md に配置すべきです。場所は強制力がありますが、修飾子は単なる「期待」に過ぎません。
インポートされた会話はメモリではなく参照として扱う
30日分のチャットを移行することは継続性の観点からは有用ですが、ナレッジベースとしては最悪です。それは単なる書き起こしであり、あらゆる書き起こしが抱えるのと同じ問題を抱えています。もしそれらのチャットの中に決定事項があるなら、別の場所に決定事項として書き残してください。
生成されたメモリについて慎重に判断する
Codexのメモリがデフォルトでオフになっているのは妥当な設定であり、オンにするのもまた妥当です。ただし、失うと困るものが1台のマシンの生成された状態としてのみ存在することがないようにしてください。また、これはプロジェクトごとではなくグローバルであるため、作業全体でコンテキストが混ざり合う可能性があることを覚えておいてください。
アクセス権があるうちに手動エクスポートを行う
ファイルではなくウェブアプリ内に存在するデータ（コンシューマー向けチャットアプリのメモリ、ホスト型エージェントのメモなど）は、有料プランの契約期間中に手動でコピーする必要があります。これだけが期限のあるステップであり、移行の他の部分は後からいつでもやり直すことができます。
結論
8月7日のリリースにより、Codexのインポーターは大幅に改善されました。Cursor管理のスキルが移行可能になり、以前インポートしたClaudeとCursorの会話は重複することなく再同期されるようになりました。手動での再構築が移行をためらう理由だったなら、その理由はほぼ解消されました。
変わっていないのは、境界線の形です。インポーターは設定と会話記録を移行します。通常のClaudeチャットデータは依然としてインポートできません。そして、あなたのルールの背景にある推論は、インポートすべきファイルの中には最初から存在しませんでした。したがって、設定にはインポーターを使用し、移行されたものを整理し、永続的な素材（意思決定、制約、インシデント、クライアント要件）はどちらのツールの中にもないストアに保管してください。そうすれば、次のリリースノートは「救済」ではなく、単なる「利便性の向上」になるでしょう。