なぜCodexのコンテキストはClaude Codeに引き継がれないのか
各ツールが保存するもの
Codexは起動時にAGENTS.mdを読み込み、それ以外のすべて（開いたファイル、決定事項、進行中の計画など）をコンテキストウィンドウに保持し、ウィンドウがいっぱいになると圧縮します。Claude Codeも同様の仕組みで動作します。起動時にCLAUDE.mdを読み込み、それ以外はセッションコンテキストに保持します。静的な指示ファイルには直接的な互換性があります。しかし、動的な理解はどちらのツールにも保存場所がないため、互いに引き渡すことができません。
移行できない技術的な理由
AGENTS.mdとCLAUDE.mdは単なるMarkdownファイルであるため、その部分はコピーして調整するだけです。しかし、セッション状態は本質的に一時的なものです。Codexは長いタスクの間にそれを圧縮して消去し、セッション終了時に破棄するため、Claude Codeにインポーターがあったとしてもエクスポートするものがありません。あなたが移行しているのはエージェントのメモリではなく、設定ファイルであり、その後メモリを手動で再構築しているのです。
これによるコスト
最初の1つ目のエージェントがすでに理解していたコードベースに対して、2つ目のエージェントを再度オンボーディングすることになります。同じ規約、同じアーキテクチャの説明、同じ修正を繰り返す必要があります。Codexが学習したもののうち、AGENTS.mdに書き込まれなかったものはすべて消えてしまいます。そして、移行先でも同じ状況に直面します。Claude Codeもセッション間はステートレスであるため、翌日にはまたゼロからのスタートになります。根本的な問題を解決せずにツールだけを変えたことになります。
ステップ・バイ・ステップ：手動でCodexからClaude Codeへ移行する
標準的な移行ルートは手動ですが、本質的な部分は移行できます。
ステップ 1: Codexが保持しているものを抽出する
AGENTS.md（エージェントが従っていた規約、コマンド、制約）をコピーします。- 最近のCodexセッションを見直し、ファイルに反映されなかった決定事項や制約（却下されたアプローチ、アーキテクチャの選択、既知の罠など）を書き留めます。
- Codexのセットアップが依存していたMCPサーバーとツールをメモします。
ステップ 2: Claude Codeをセットアップする
- リポジトリのルートに
CLAUDE.mdを作成または更新し、AGENTS.mdから調整した規約を記述します。 - 回収した決定事項や制約を
CLAUDE.mdまたはClaude Codeが起動時に読み込むドキュメントファイルに追加します。 - MCPサーバーをClaude CodeのMCP設定に再追加します。
これで、翻訳されたベースライン（設定ファイルと、回収できたコンテキスト）が手に入ります。セッション履歴の転送はなく、一部の作業でCodexを使い続けたとしても、ここの内容は同期されません。
移行で失われるもの
ファイルに書き出されなかったセッションレベルのプロジェクト理解。過去の修正の背後にある推論。そして、永続性の問題そのものです。どちらのエージェントも圧縮して破棄するため、手動で維持するファイルだけが、どちらのエージェントも確実に開始できる唯一の手段となります。両方のセッションよりも長生きするレイヤーを追加しない限りは。
より良い方法：両方のエージェントで共有する単一のメモリレイヤー
移行が苦痛なのは、各エージェントの知識がその内部で消えてしまうからです。プロジェクトの知識を中立的なレイヤーに配置すれば、切り替えは単なる「接続」になります。MemoryLakeは、アーキテクチャ、決定事項、規約を一度保存すれば（検索可能、Gitスタイルのバージョン管理、エンドツーエンド暗号化）、MCPを介してClaude CodeとCodexの両方に提供するため、どちらも白紙からスタートする必要がなく、切り替えコストはゼロになります。
| 項目 | 手動でのCodex → Claude Code | MemoryLakeレイヤー |
|---|---|---|
| 必要なステップ | 設定の変換 ＋ 手動での回収 | 3ステップ（初回のみ） |
| セッションレベルの理解 | ほとんどが失われる | 保持され、検索可能 |
| 圧縮（compaction）への耐性 | なし | あり（オンデマンドで取得） |
| 段階的な移行中の同期 | 同期しない | 同期する |
| 決定事項の履歴 | なし | あり（Gitスタイル） |
| 将来的なエージェントの切り替え・追加 | 再度変換が必要 | 接続するだけ |
ステップ 1: APIキーを作成する
MemoryLakeにサインインし、キーを生成して最初のリクエストを送信します。これには約30秒かかります。
ステップ 2: 最初のメモリをアップロードする
1つのツールの設定ファイルに閉じ込める代わりに、両方のエージェントが必要とするプロジェクト知識（アーキテクチャのメモ、決定事項の記録、規約、APIドキュメントなど。ドキュメント、画像、その他のファイルすべてに対応）を投入します。
ステップ 3: AIとエージェントを接続する
どちらのエージェントもMCPに対応しています。APIキーを使用して、Claude CodeとCodexのMCP設定にMemoryLakeを追加します。段階的な移行中もどちらかが遅れることはなく、同じメモリがOpenClawや他のMCP対応エージェントにも届くため、次のツールへの移行は再スタートではなく単なる接続になります。
エージェントの再オンボーディングに実際にかかるコスト
2回支払うことになる「切り替え税」
エージェントを移行するということは、前のエージェントが知っていたコードベースを再学習させることを意味します。そして、新しいエージェントもセッションごとにリポジトリを再探索するため、その日常的なコストも支払うことになります。従量課金制のツールでは、その再探索は作業が始まる前に消費されるトークンとなります。
再オンボーディングの代わりに検索を利用する
共有レイヤーがあれば、Claude Codeは規約や決定事項を再構築するのではなく、オンデマンドでプルします。そのため、初日から情報を把握し、圧縮後もその状態を維持できます。スタートが早くなり、同じ修正を繰り返すことが減り、支出も抑えられます。MemoryLakeのToken Saving Calculator（トークン削減シミュレーター）で、実際の使用状況からその効果を予測できます。
クロスエージェント・メモリのベストプラクティス
切り替える前に回収する
Codexが保持しているセッション知識は、切り替え時に消失する部分です。最初にそれを共有レイヤーにキャプチャしておけば、移行で失われるものは何もありません。
規約はリポジトリに、決定事項はレイヤーに保存する
CLAUDE.mdやAGENTS.mdは、各ツールが起動時に読み込む安定した規約を置くのに適しています。日付のある決定事項、却下されたアプローチ、解決済みの問題などは、圧縮によって失われない検索可能なメモリに属します。
リポジトリごとにスコープを分ける
リポジトリごとに1つのメモリ・スコープを設定することで、両方のエージェントのコンテキストを正確に保ち、あるプロジェクトの規約が別のプロジェクトに漏洩するのを防ぎます。
結論
CodexからClaude Codeへの移行は、設定の変換と手動でのメモリ再構築を伴います。そこで止まってしまえば、問題を移動しただけで解決したことにはなりません。新しいエージェントも古いエージェントとまったく同じように、セッション間で忘れてしまうからです。プロジェクトの知識を両方のエージェントが読み取るレイヤーに配置すれば、切り替えは単なる接続になります。初日から情報を把握したセッション、圧縮に耐える決定事項、そして次回ツールを変更するときに再学習させる必要がなくなります。設定を移行し、メモリは維持しましょう。