実際に移行できるもの
「ChatGPT のメモリ」と一口に言っても、実際には3つの異なる要素で構成されており、それぞれ移行方法が異なります。何を移動させるのかを正確に把握しておきましょう。
保存されたメモリのエントリは、データとしてではなくコンテンツとして移行します。 これらは、ChatGPT が蓄積してきた短い事実（好み、技術スタック、進行中のプロジェクトなど）です。2026年6月4日に OpenAI が発表したメモリの再構築以降、表示されるのは古いフラットな保存エントリの一覧ではなく、読みやすいメモリの要約ページに移行しつつあります。いずれにせよ、それを読み取ることが唯一のエクスポート手段です。Codex がそのまま取り込めるファイルをワンクリックで出力するような、ドキュメント化されたルートは存在しません。
カスタム指示（Custom instructions）は、ほぼそのまま移行できます。 ChatGPT のカスタム指示ブロックに入力した内容は、すでにモデルへのディレクティブ（指示）として記述されています。これは、ほとんど編集することなく AGENTS.md にマッピングできます。主に削除するのは、コーディングの動作ではなく、チャットの応答スタイルに関する記述だけです。
チャット履歴は移行されませんし、基本的には移行すべきではありません。 Codex の /import は最近のチャットをプルできますが、それはサポートされているエージェントからのみであり、かつローカルのセッションデータに限られます。Web上のみの履歴はどこからもインポートできません。ChatGPT のスレッドはそのまま残ります。これは思ったほど大きな損失ではありません。1年分のスレッドに含まれる永続的な知識は、結局のところ1ページの規約に集約されるものであり、これからそのページを作成するからです。
プロジェクトファイルやアップロードしたファイルは移行されません。 ChatGPT の Project に添付したものはすべて、その Project 内に留まります。業務にとって重要なドキュメントは、コーディングエージェントがアクセスできる場所（リポジトリ内、またはメモリレイヤーなど）に存在する必要があります。
また、まったく移行されないものが1つあります。それは、あなたの好みの背後にある「理由」です。ChatGPT はあなたが小さなコミットを好むことは知っていますが、それが2025年のロールバック障害に起因していることまでは知りません。あなたが書き留めない限り、Codex もそれを知ることはありません。それを書き留める価値があるかどうかは判断が分かれるところですが、これまでに2回以上説明し直す羽目になった事柄については、通常は書き留めておく価値があります。
手動での移行手順
ステップ 1: ChatGPT のメモリを読み出して分類する
設定 → パーソナライズ → メモリ を開き、そこに何があるかを確認します。アカウントが新しいメモリシステムに移行している場合は、ChatGPT があなたについて合成した内容を示すメモリ要約ページが表示されます。そうでない場合は、保存されたメモリのリストが表示されます。どちらも読み取り可能であり、これが得られる唯一のエクスポートデータです。
次に、チャットで次のように指示して、すべてを書き出させます。「私について、および私の仕事の進め方について覚えていることをすべて、1行に1項目ずつ、解説なしでそのまま書き出してください。」 これをスクラッチファイルにコピーします。これは設定ページを確認することに「加えて」行ってください。代わりに行うのではありません。この2つは一致しないことが多く、その差異から得られる情報があるためです。
書き出した内容を、次の3つのバケツに分類します。
- 永続的かつポータブル — 技術スタック、規約、ツール、出力フォーマットの指定、絶対にやってほしくないこと。これが
AGENTS.mdになる素材です。 - プロジェクト固有 — 特定のコードベースにのみ適用されるもの。これはグローバル設定ではなく、そのリポジトリ内に配置します。
- どちらでもない — チャットの進め方に関する好み、およびモデルが学習したのではなく推測したすべての内容。これらは捨ててください。ここでは容赦なく切り捨てましょう。メモリのエントリにはソース（どこから来たか）のラベルが付いていないため、自分が実際に言った覚えのないものは、新しいツールに持ち込むべきではない単なる推測です。これは、フラットで属性情報のないメモリがどのように保存されるかという制限によるものであり、移行はそうした無駄なデータを整理する絶用な機会です。
1つ目のバケツの内容を、命令形に書き換えます。ChatGPT のメモリは、「ユーザーは TypeScript の strict モードを好む」のように、あなたに関する観察結果として表現されがちです。Codex は指示（インストラクション）を読み込みます。「TypeScript の strict モードを使用すること。エラーを消すために any を追加しないこと」のように、エージェントが従える形式に書き換えます。
ステップ 2: Codex が実際に参照する場所に配置する
Codex は AGENTS.md を読み込みます。CLAUDE.md は読み込みませんし、ChatGPT のカスタム指示も読み込みません。Claude Code から移行してきた方は、この移行の逆方向のプロセスですでにこれをご存知かもしれません。
参照は階層的に行われます。まず Codex のホームディレクトリ（~/.codex/AGENTS.md、または変更している場合は $CODEX_HOME）、次にリポジトリのルート、中間ディレクトリ、そして現在の作業ディレクトリの順です。ファイルは上から下へと結合され、競合が発生した場合はより近い（下位の）ファイルが優先されます。したがって、配置は以下のようになります。
- グローバルな好み（デフォルトの言語、出力スタイル、すべての作業に共通すること）は
~/.codex/AGENTS.mdに配置します。 - リポジトリの規約は、リポジトリのルートにある
AGENTS.mdに配置してコミットし、チーム全員に共有されるようにします。 - サブプロジェクト固有のルールは、そのサブディレクトリ内の
AGENTS.mdに配置します。
各ファイルは短く保ちましょう。スコープ内にあるすべての内容が、タスクごとにコンテキストにロードされるため、2,000語のグローバルファイルがあると、すべてのリクエストで永続的にコスト（トークン）を支払うことになります。ドキュメントではなく、指示を記述してください。
次に、Codex 独自のメモリ機能について判断します。Codex のメモリ機能はデフォルトでオフになっています。 デスクトップアプリの「設定 → パーソナライズ」で「メモリを有効にする」をオンにするか、~/.codex/config.toml の [features] セクションに memories = true を追加することで有効にできます。EEA（欧州経済領域）、英国、スイスでは、ここで有効にしない限り、Codex はメモリを使用または生成しません。これらは以下のように個別に調整できます。
```toml [features] memories = true
[memories] generate_memories = true # 新しいセッションからメモリを抽出する use_memories = true # 今後のセッションにメモリを注入する ```
有効にすると、Codex はスレッド間で一貫した好み、繰り返されるワークフロー、技術スタック、プロジェクトの規約、既知の落とし穴を引き継ぎ、要約、永続的なエントリ、最近の入力、および裏付けとなる証拠を ~/.codex/memories/ に保存します。デスクトップアプリまたは TUI で /memories コマンドを使用すると、特定のチャットがメモリを読み込むか、あるいはメモリに書き込むかを制御できます。
この機能はオンにする価値があります。ただし、公式の注意書きがすべてを物語っているため、その性質を明確に理解しておく必要があります。メモリの生成は、アクティブなセッションや短時間のセッションではスキップされ、残りのレート制限の割合が設定されたしきい値を下回ると一時停止し、チャット終了直後には更新されない場合があります。これらのファイルは自動生成された状態データであり、手動で編集すべきではありません。生成されたメモリフィールドから機密情報は削除されますが、共有する前にはファイルを確認することをお勧めします。また、このストレージはそのマシンに対してローカルであり、プロジェクト全体でグローバルです。リポジトリごとにスコープが分かれているわけではなく、どこにも同期されません。
つまり、次のマシンをセットアップするとき、仕事用ノートPCで Codex を開くとき、あるいは別のエージェントにタスクを任せるときには、再びステップ1を繰り返すことになります。
より良い方法：ツールに依存しない単一のメモリレイヤー
上記の手動移行は、あなたが尋ねた質問に対する正しい回答です。しかし、皆さんの中には今年すでにこれを3回も繰り返している方もいるでしょう。
手動ルートが実際に行っていることを見てみましょう。ある製品のプロプライエタリなストレージから知識を抽出し、それを手動で2つ目の製品のファイルフォーマットに変換し、どちらのツールも直接読めない3つ目の場所にコピーを残しています。これでは、次回移行するときに楽になる要素が何もありません。知識こそが永続的なものであり、ツールは移り変わるものです。
代替案は、その知識を両方のツールの外側に保持し、それぞれのツールから読み込めるようにすることです。MemoryLake は、アシスタントの背後に位置するメモリレイヤーです。ドキュメント、決定事項、規約を一度登録すれば、Codex、Claude、OpenClaw などがすべて同じストアから読み込みます。ツールの切り替えは「移行作業」ではなく、単なる「設定変更」になります。
公平を期すためにトレードオフを説明すると、AGENTS.md にはメモリレイヤーにはない明確な利点があります。プレーンテキストであり、リポジトリ内に存在し、プルリクエストでレビュー可能で、チームが自動的にそれを継承できます。リポジトリの規約には、引き続き AGENTS.md を使用してください。それがこのファイルの得意分野です。メモリレイヤーは、リポジトリの形をしておらず、ツールごとに再入力すべきではない、蓄積された知識のために使用します。
ステップ 1: API キーを作成する
キーを生成すれば、約30秒で最初のリクエストを送信できます。キーは設定ファイルに直接記述するのではなく、環境変数やシークレットマネージャーに保存してください。まさにこのような移行の際に、設定ファイルはマシン間でコピーされてしまうためです。
ステップ 2: 最初のメモリをアップロードする
先ほど手動で1時間かけて抽出した知識（規約ドキュメント、アーキテクチャの決定事項、クライアントの概要、ランブックなど）を含むドキュメント、画像、ファイルをドロップします。可能であれば、要約ではなくソースファイルをそのままアップロードしてください。要約を作成すると、詳細がいつの間にか抜け落ちてしまう原因になります。
ステップ 3: AI とエージェントを接続する
Claude、Codex、OpenClaw、その他の AI エージェントに、MCP または API を介してメモリへのアクセスを許可します。Codex は MCP サーバーをサポートしているため、これは書き換えではなく設定項目の追加だけで済みます。これにより、他のエージェントや API を使用して構築したシステムからも同じストアにアクセスできるようになります。MCP クライアントを持たない ChatGPT も併用している場合は、API 経由で必要な情報を取得し、プロンプトやワークフローに注入します。
実務における変化
最初の違いは、新しいツールを使い始めた初日に現れます。何も知らないエージェントの代わりに、「リトライについて何を決定したか？」に答えられるエージェントが手に入ります。なぜなら、その決定事項はエクスポートできないスレッドの中ではなく、ストアに保存されているからです。
2つ目の違いは、マシン間での共有です。Codex のメモリは設計上、ローカルかつマシンごとに閉じられていますが、メモリレイヤーは異なります。ノートPCと仕事用のデスクトップPCで同じ知識を共有できるため、好みの設定を毎回再現する手間が省けます。
3つ目は、今後の方向性です。現在のエコシステムの率直な現状として、Codex は設定を行わない限りセッション間でプロジェクトのコンテキストを忘れてしまいます。これは競合するすべてのツールも同様で、それぞれ少しずつ異なるファイルフォーマットを使用しています。知識が1つの場所に集約されていれば、Codex と Claude Code を併用する際にも、同じ規約のコピーを2つ維持する必要がなくなります。
移行のためのベストプラクティス
指示（インストラクション）と知識（ナレッジ）を分けて移行する
AGENTS.md はルール（短く、命令形で、すべてのタスクでロードされるもの）のためのものです。メモリレイヤーは知識（ドキュメント、決定事項、履歴など、毎回ロードするには長すぎ、かつ失うには惜しいもの）のためのものです。これらを混ぜてしまうと、指示ファイルが肥大化し、リクエストごとのコストが高くなる一方で、依然として不完全なものになってしまいます。
Codex のメモリ機能を有効にするが、アーカイブとしては扱わない
この機能を有効にすると、確かに同じ説明を繰り返す手間が減ります。ただし、ドキュメントに記載されている動作（1台のマシンにローカル、プロジェクトごとではなくグローバル、短いセッションではスキップされる、レート制限付近で一時停止する、チャット終了直後は最新でない可能性がある、手動編集すべきではない自動生成ステートであること）を正しく理解し、過度な期待は避けましょう。これは作業を便利にするレイヤーであり、作業の記録そのものではありません。
抽出は一度に、適切に行う
覚えている範囲で重要だと思う10項目だけを移行し、残りは自然に再構築させたいという誘惑に駆られるかもしれません。しかし、自然に再構築されることはありません。次の2ヶ月間、散発的なプロンプトで何度も説明し直すことになるだけです。メモリページ全体を読み、分類し、一度に書き出しましょう。メモリレイヤーを維持するのであれば、この作業を行うのはこれが最後になります。
丸ごとコピーするのではなく、引き継ぐ内容をレビューする
アシスタントがあなたについて「覚えている」ことの一部は、アシスタントが推測し、あなたが実際に言ったことと同じフォーマットで保存したものです。そのリストをそのまま新しいツールにコピーすると、それらの推測が永続的な設定として定着してしまいます。各行を読み、それが本当に自分の意図したものか確認してください。
結論
ChatGPT から Codex への移行が手動作業になるのは、OpenAI が競合他社のコーディングエージェント用のインポーターは構築したものの、自社のコンシューマー向けアプリ用のインポーターは構築しなかったためです。メモリを読み出し、永続的なものとプロジェクト固有のものに分類し、命令形に書き換えて、Codex が実際に読み込む AGENTS.md の階層に配置します。その際、デフォルトでオフになっている、ローカルかつグローバルスコープの Codex メモリ機能も有効にしておくと良いでしょう。
慎重に決定すべきなのは、知識をツールの中に置くのか、それともツールの下に置くのかという点です。ツール依存のメモリを選択すると、次のツールの切り替え時や新しいマシンをセットアップするたびに、この移行作業を繰り返すことになります。両方のツールが読み込めるメモリレイヤーを使用すれば、知識はツールの選択よりも長持ちします。この分野の進化の速さを考えれば、こちらの方がより堅実な選択肢と言えます。