コンテキストを失わずに Amp から Codex へ移行する方法 (2026)

AGENTS.md の内容はそのまま移行できます。 両方のツールとも、特別な構造を必要としないプレーンな Markdown を読み込みます。Amp のドキュメントでは、AGENTS.md ファイルを「コードベースの構造、ビルド/テストコマンド、および規約に関するガイダンス」として検索すると説明されており、Codex のドキュメントでは「作業を開始する前に AGENTS.md ファイルを読み込む」とされています。文章自体を変更する必要はありません。

ルートレベルのガイダンスは移行できます。 リポジトリのルートにある単一の AGENTS.md は、両方のツールがまったく同じように処理する唯一の構成です。

ネストされた AGENTS.md ファイルは移行できますが、タイミングが異なります。 Amp は「エージェントがサブツリー内のファイルを読み取るときに、サブツリーの AGENTS.md ファイルを含める」という、ファイルアクセスによってトリガーされる遅延読み込みを行います。一方、Codex は事前にチェーンを組み立てます。起動時（1実行につき1回。TUI では通常、起動されたセッションごとに1回を意味します）に、プロジェクトルートから作業ディレクトリまで探索して「指示チェーンを構築」します。同じファイルですが、読み込まれるタイミングが異なり、Codex の場合はルートから現在の作業ディレクトリ（cwd）までのパス上にあるディレクトリのみが対象となります。

リポジトリより上の階層にあるガイダンスは移行できません。 ここが最初の大きな違いです。Amp は常に「現在の作業ディレクトリ（またはエディタのワークスペースルート）および 親ディレクトリ（$HOME まで）」にある AGENTS.md ファイルに加えて、$HOME/.config/amp/AGENTS.md、$HOME/.config/AGENTS.md、およびシステム全体のファイルを含めます。しかし、Codex のプロジェクトスコープはプロジェクトルート（「通常は Git ルート」）から始まり、そこから下方に探索します。リポジトリより上の親フォルダに置いていたものは、Codex のパスには一切含まれません。Codex にもグローバルスコープはありますが、それは特定の場所（Codex ホームディレクトリ内の AGENTS.override.md または AGENTS.md）に限定され、「このレベルで最初の空でないファイルのみを使用」します。

デフォルトでは CLAUDE.md のフォールバックは移行されません。 Amp のルールは明確です。「ディレクトリに AGENTS.md が存在しない場合でも、AGENT.md（末尾の S なし）または CLAUDE.md という名前のファイルが存在すれば、そのファイルが含まれます。」しかし、Codex にはこのような暗黙のフォールバックはありません。Codex は AGENTS.override.md、次に AGENTS.md、そして project_doc_fallback_filenames にリストされているファイルを確認します。ドキュメントには「このリストにないファイル名は、指示の検出において無視されます」と率直に記載されています。リポジトリ内のディレクトリがこれまで CLAUDE.md に依存して動作していた場合、Codex に移行すると、それらは警告なしに無効化されます。

グロブ（Glob）スコープのガイダンスは移行できません。 これが最大のギャップであり、Codex のドキュメント化されたスコープメカニズムはまったく異なる軸で動作します。Amp では、ルートの AGENTS.md で他のファイルを @言及（@-mention）でき、それらの言及されたファイルは YAML フロントマターに globs を持つことができます。「globs を持つ言及されたファイルは、Amp がそのグロブのいずれかに一致するファイルを読み取った場合にのみ含まれます」。また、グロブは「../ または ./ で始まらない限り、暗黙的に **/ がプレフィックスとして付加されます」。これにより、条件付きで常にフラットなガイダンス（例：TypeScript ファイルが読み込まれたときにのみ docs/typescript-conventions.md が有効になり、それ以外の場合は無視される）を実現できます。この仕組みを構築している場合、そのパターンは scoping Amp's instructions to the files they apply to で説明されています。

Codex のドキュメント化されたスコープメカニズムは、ディレクトリのネストです。グロブ条件付きの取り込みに対応するドキュメント化された機能はありません。そのため、これらのスコープ付きファイルは、それが管理するディレクトリ内のネストされた AGENTS.md にするか、親ファイル内の無条件のテキストにする必要があります。そして、無条件のテキストはバイト制限にカウントされるため、次の問題が発生します。

AGENTS.md のサイズが重要になります。 Amp のエージェントファイルに関するドキュメントには、合計サイズ制限の指定はありません。しかし、Codex には制限があります。「空のファイルをスキップし、合計サイズが project_doc_max_bytes（デフォルトは 32 KiB）で定義された制限に達すると、ファイルの追加を停止します」。この失敗はエラーとしては表示されず、単にガイダンスが含まれなくなるだけです。グロブスコープのファイル群を1つの常に有効なファイルにまとめようとすると、簡単にこの制限を超えてしまいます。

Amp にはなく、Codex にはあるもの。 Amp のドキュメント化された永続化メカニズムは、ユーザーが記述する AGENTS.md ファイルとスレッドのみです。過去のセッションから自動的に書き込まれるストアに相当するものは、Amp にはドキュメント化されていません。Codex にはそれがあります。「メモリ（Memories）機能により、ChatGPT と Codex は以前の作業から有用なコンテキストを将来の作業に引き継ぐことができます」。これに依存する前に、それが具体的に何であるかを正確に把握しておく必要があります。これについては次のセクションで説明します。

ステップ 1: 下方探索用に検出ツリーを再構築する

まず、Amp のコマンドパレットから agents-md list を実行します。これにより、Amp が現在実際に使用しているファイルのセットが表示されます。これは通常、自分が書いたと記憶しているファイル群よりも多くなっています。

次に、そのリストを4つのグループに分類します。

リポジトリのルート以下にあり、普段作業するパス上のディレクトリにあるファイルは、変更の必要はありません。Codex が自動的に検出します。

リポジトリより上の親ディレクトリにあるファイルについては、判断が必要です。デバイス固有のコマンドやテスト中の設定など、個人用の内容であれば、Codex のグローバルスコープである ~/.codex/AGENTS.md に配置します。たまたまリポジトリの上に置いていたプロジェクト関連の内容であれば、リポジトリ内に移動してください。元の場所のままでは検出されません。

Amp が暗黙的に昇格させていた CLAUDE.md や AGENT.md ファイルは、明示的に扱う必要があります。これらを AGENTS.md にリネームするか（これがよりクリーンな方法であり、詳細は migrating CLAUDE.md to AGENTS.md で解説しています）、~/.codex/config.toml の project_doc_fallback_filenames に追加して Codex が指示ファイルとして処理できるようにします。すでに Amp を使っていない場合はリネームが推奨されます。一部のチームメンバーがまだ Amp を使用しており、古い名前を想定している場合は、フォールバックリストを使用するのが適しています。

グロブスコープの @言及ファイルは、それらが管理するディレクトリに再配置する必要があります。たとえば、グロブが src/components/** および **/*.tsx であるファイルは、src/components/AGENTS.md になります。無関係なツリーにまたがるグロブを持つファイルは、分割するか、常に有効なファイルに昇格させてバイト制限の予算内に収める必要があります。

この作業を行う際、Codex の2つの挙動を念頭に置いてください。1つは、1ディレクトリあたり最大1ファイルしか使用されないこと（「Codex は1ディレクトリあたり最大1ファイルを含めます」）、そして同じディレクトリ内では AGENTS.override.md が AGENTS.md よりも優先され、もう一方は完全に無視されることです。もう1つは、マージ順序がルートから下方向であることです（「現在のディレクトリに近いファイルほど、結合されたプロンプトの後半に表示されるため、以前のガイダンスを上書きします」）。つまり、具体性はルールの種類ではなく、ディレクトリの深さによって決まります。

ネストされたディレクトリから Codex を起動し、ロードされた指示ソースのリストを表示させて検証します。期待したファイルが見つからない場合、主な原因は、プロジェクトルートより上にあること、同階層のオーバーライドファイルによって抑制されていること、またはチェーンがバイト制限に達したことです。関連する検出エラーについては why Codex skips your AGENTS.md rules で解説しています。また、Copilot rather than Amp から移行する場合も、同じ検出モデルが適用されます。

ステップ 2: Codex Memories に何を任せるかを決める

Codex のメモリ（memory）レイヤーはデフォルトでオフになっています。有効にするには、Settings > Personalization で設定します。有効にすると、「Codex は対象となる過去のチャットから有用なコンテキストをローカルのメモリファイルに変換」できます。また、「アクティブなセッションや短時間のセッションをスキップし、生成されたメモリフィールドから機密情報を削除し、各チャットの終了直後ではなくバックグラウンドでメモリを更新」します。ファイルは ~/.codex/memories/ 以下に保存され、「過去のチャットからの要約、永続的なエントリ、最近の入力、および裏付けとなる証拠」が含まれます。チャットごとに、/memories コマンドで現在の会話が既存のメモリを読み取るか、将来のメモリに反映させるかを制御でき、「チャットレベルの選択によってグローバルなメモリ設定が変更されることはありません」。

この機能にどれだけの比重を置くかを決める前に、OpenAI 自身のガイダンスを確認してください。「チームに必要なガイダンスは AGENTS.md やチェックインされたドキュメントに保持してください。メモリは、常に適用されるべきルールの唯一のソースとしてではなく、補助的な想起レイヤーとして扱ってください。」

これは正しい境界線であり、自分自身の言葉で再確認する価値があります。Codex Memories は、ローカルでインストールごとに生成される想起レイヤーです。ドキュメントには「これらのファイルを生成された状態として扱う」べきであり、「主要な制御手段として手動で編集することに依存しない」よう記載されています。これはチームメンバーと共有されず、Codex ホームディレクトリに紐づいており、レート制限に近づくと生成がスキップされることもあります。自身のマシンでの重複作業を減らすには非常に便利ですが、チームの決定事項を保存する場所ではありません。

これにより、Amp のときと同じギャップが、より明確な形で残ることになります。開発中にチームが確立したこと（ストリーミングパーサーの使用をやめた理由、不安定なテストで既に失敗した2つの修正方法、顧客指定の命名規則など）は、指示ファイルにも、ノートPCごとの生成ストアにも適していません。これは、sharing context between sessions（セッション間でのコンテキスト共有）が、これらすべてのツールにおいて未解決の課題となっているのと同じギャップです。

この移行が面倒な理由は、両方のツールが「エージェントが常に知っておくべきこと」を解決しようとしている一方で、「私たちが何を学んだか」を解決していないためです。指示ファイルは設計上、実行ごとに再送信されます。生成されるローカルストアは設計上、マシンごとに閉じられています。チームの知識はそのどちらでもありません。

MemoryLake はその両方の外側に位置します。検出された事実を保持し、MCP や API を介して公開するため、今週のクライアントが Amp であろうと、Codex であろうと、あるいはまだ導入していない他のツールであろうと関係ありません。これにより、次の移行作業を「退屈で簡単なもの」にすることができます。それこそが真のゴールです。

ステップ 1: API キーを作成する

キーを生成すれば、約30秒で最初のリクエストを送信できます。チームが使用するあらゆる環境から読み取り可能な1つのキーを持つことで、知識が特定のエディタの設定ディレクトリに縛られるのを防ぎます。

ステップ 2: 最初のメモリをアップロードする

アーキテクチャのメモ、現在のリトライポリシーの背景にあるインシデント報告書、誰も繰り返したくないデザインレビューなど、すでに確立されている決定事項を含むドキュメント、画像、ファイルを投入します。まずは、何度も説明するのにうんざりしている内容から始めましょう。

ステップ 3: AI とエージェントを接続する

Claude、Codex、OpenClaw などのエージェントに、MCP または API 経由でアクセス権を付与します。実際には、タスクの開始時に関連するメモリを読み込み、タスク中に加えた修正を書き戻すことで、修正内容がそのセッションの寿命を超えて残るようにします。

移行のリスクがなくなります。検出ツリーが再構築され、チームの知識が両方のツールの外部に置かれれば、将来ツールを変更する際に影響を受けるのは指示ファイルの構文だけになります。これは半日もあれば終わる作業であり、知識を再発掘するような大がかりなプロジェクトにはなりません。

AGENTS.md ファイルがより小さく、より洗練されます。肥大化した指示ファイルの多くは、他に行き場のない「検出された事実」が蓄積されたことが原因です。これらを外部に移動することで、32 KiB の制限を余裕でクリアできるようになり、さらに重要なこととして、残されたコンテンツを「リポジトリでの作業方法」に特化させることができます。

Codex Memories を安全に有効化できるようになります。必要なルールがチェックインされたファイルにあり、チームの知識が共有ストアにあれば、ローカルの想起レイヤーは単なる便利な機能となり、重要な役割を担う必要がなくなります。これこそが、OpenAI のドキュメントが推奨しているアプローチです。

そして、属人化していた知識が属人化しなくなります。新しく入ったエンジニアの Codex も、最初のタスクから他のメンバーと同じ確立された決定事項を読み取ることができます。指摘を受けて3ヶ月かけて徐々に覚える必要はもうありません。

信頼する前にツリーを再構築する。 最も深い作業ディレクトリから Codex を起動し、何をロードしたかを確認してください。Amp とは異なり、Codex ではディレクトリの深さによって結果が変わります。

フォールバックリストよりもリネームを優先する。 project_doc_fallback_filenames は機能しますが、これはローカルの設定ファイルです。AGENTS.md にリネームすればリポジトリに含まれるため、全員に対して機能します。

オーバーライドは作業場所の近くに配置する。 Codex 自身の推奨事項：「オーバーライドは、専門的な作業にできるだけ近い場所に配置してください」。探索は現在のディレクトリで停止するためです。

グロブをフラット化する際は制限に注意する。 グロブスコープだった Amp ファイルを常に有効なテキストに変換すると、それらすべてが 32 KiB の制限を奪い合うことになります。制限を引き上げるよりも、ネスト構造にする方が効率的です。

## Code Review Rules はスコープを絞って維持する。 Codex は、対象となるコードに最も近い AGENTS.md からこのセクションを読み取ります。そのため、ルートレベルのチェックはルートに配置し、サービス固有のチェックはネストされたファイルに配置します。

メモリに機密情報を入れない。 Codex は生成されたフィールドから機密情報を削除しますが、ドキュメントでは Codex ホームディレクトリを共有する前にファイルを確認するよう指示されています。どちらも事実です。自動削除機能はあくまでセーフティネット（防護策）であり、機密情報を入れてもよいという許可ではありません。

Amp と Codex は同じファイルフォーマットを読み込みますが、そのファイルをどこから探すかについては、ほぼすべての点で意見が異なります。Amp は上方に検索して寛容に取り込み、Codex は下方に1つのチェーンを組み立て、1ディレクトリあたり1ファイルを取得し、バイト制限で停止します。どちらのアプローチも間違いではなく、各ツールの挙動は十分にドキュメント化されているため、「ファイルの互換性＝挙動の互換性」という前提を捨てさえすれば、移行は機械的に進められます。

機械的にいかないのは、どちらのツールもカバーしていない部分です。Codex 自身のドキュメントがその境界線を示しています。メモリは「補助的な想起レイヤーであり、常に適用されるべきルールの唯一のソースではない」とされています。その帰結として、第3のカテゴリが存在することになります。それは、チームが解決したことであり、指示ファイルにするには具体的すぎ、ノートPCごとのストアにするには共有されすぎている知識です。それを両方のツールから読み取れる場所に配置し、下方探索用に検出ツリーを再構築すれば、移行は半日で完了し、その後も安定して機能し続けます。