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

ファイル名と内容は完全に移行されます。 Codex は「作業を開始する前に AGENTS.md ファイルを読み込みます」。Warp の Project Rules は「AGENTS.md ファイル（または後方互換性のための WARP.md）」に配置されます。同じファイル名、同じ Markdown であり、変換は不要です。

ファイル名の詳細を怠ると、痛い目を見る可能性があります。 Warp のドキュメントには明示的な警告があります。「Warp が認識するためには、ファイル名はすべて大文字である必要があります（例：AGENTS.md。agents.md や Agents.md は不可）」。Codex も別の意味で同様に厳格です。フォールバックリストは正確であり、「このリストにないファイル名は、指示の検出において無視されます」。もし project_doc_fallback_filenames を通じて小文字やカスタム名を登録していた場合、Warp はそれを認識しません。

ネストは機能しますが、オーバーライドではなくスタッキング（累積）に置き換わります。 これが実質的な変更点です。

Codex のモデル：「プロジェクトのルート（通常は Git のルート）から開始し、Codex は現在の作業ディレクトリまで下っていきます... パスに沿った各ディレクトリで、AGENTS.override.md、次に AGENTS.md、そして project_doc_fallback_filenames にあるフォールバック名をチェックします。Codex はディレクトリごとに最大1つのファイルを含めます」。その後、マージされます：「Codex はルートから順にファイルを連結します... 現在のディレクトリに近いファイルほど、結合されたプロンプトの後半に表示されるため、以前のガイダンスをオーバーライドします」。

Warp のモデル：「Warp はルートおよび現在のディレクトリにある AGENTS.md（または WARP.md）を自動的に適用します」。また、「別のサブディレクトリのファイルを編集する場合、Warp はそのサブディレクトリのルールファイルも含めるようベストエフォートで試みます」。競合は、規定された優先順位によって解決されます：「1. 現在のサブディレクトリのプロジェクトルールファイルのルール 2. ルートディレクトリのプロジェクトルールファイルのルール 3. グローバルルール」。

どちらも最終的には、一般的なルールよりも具体的なルールを優先します。違いは、消し去りたかったガイダンスに何が起こるかです。Codex では、ディレクトリ内の AGENTS.override.md は、同階層の AGENTS.md がまったく読み込まれないことを意味し、完全に置き換えることができます。Warp では、優先順位によって競合が解決されますが、ルートファイルは依然として適用されます。ルートファイルで規定されており、サブディレクトリで言及されていないルールは、そのまま有効であり続けます。

そのため、オーバーライドを使用して例外を設けていた Codex の設定では、サブディレクトリのファイルにおいて、単に記述を省くのではなく、明示的な矛盾（打ち消し）としてそれらの例外を再定義する必要があります。

バイト制限がなくなり、本当に一安心です。 Codex は「空のファイルをスキップし、結合されたサイズが project_doc_max_bytes（デフォルトは 32 KiB）で定義された制限に達するとファイルの追加を停止します」。その対策は「制限を引き上げるか、上限に達した場合は指示をネストされたディレクトリに分割する」ことでした。Warp のルールに関するドキュメントには、これに相当する制限は記載されていません。32 KiB 未満に抑えるためにファイルを分割していた場合、その制約はなくなります。ただし、「可能だから」という理由だけでそれらを再結合するのは、あまり良いアイデアではありません。

グローバルスコープはファイルから UI に変更されます。 Codex はグローバルなガイダンスを ~/.codex/AGENTS.md（または AGENTS.override.md。なぜなら「Codex はこのレベルで最初の空でないファイルのみを使用する」ため）に保持し、CODEX_HOME で場所を変更できます。Warp の Global Rules は「すべてのプロジェクトとコンテキストに適用」され、Warp Drive Rules ペインで管理されます。ここでは、各ルールに名前と「説明（ルールが何を行うか、いつ適用するか）」を設定できます。

これは異なる成果物です。グローバルファイルはドキュメントではなく、個別に説明されたルールのセットになります。また、どこかにコピーを保管しておかない限り、バージョン管理の対象外となります。

検証ツールが変更されますが、どちらも優れています。 Codex は、codex --ask-for-approval never "Summarize the current instructions." や、ネストされた挙動を確認するための --cd subdir バリアント、そして「codex -c log_dir=./.codex-log によるプレーンテキストの TUI ログ」を介した完全な監査コマンドを提供します。また、キャッシュと戦う必要もありません。「Codex は実行ごと（および各 TUI セッションの開始時）に指示チェーンを再構築するため、手動でクリアするキャッシュはありません」。

Warp では、適用されているルールが会話の中に表示されます。「インタラクションで使用されたルールは、会話の References の下に表示されるか、特定のルールから派生したものとしてマークされます」。仕組みは異なりますが目的は同じであり、思い込みに頼るのではなく、移行後の最初の1週間はこれを活用する価値があります。

コードベースのインデックス作成は新機能であり、ローカルで実行されます。 Codex はオンデマンドでファイルを読み込みます。Warp はインデックスを維持します：「Warp は Git で追跡されたコードベースのインデックスを作成し、エージェントがコードを理解して、正確でコンテキストを考慮した応答を生成できるようにします。コードは Warp のサーバーには保存されません」。Synced（同期済み）、Discovering files（ファイルを検出中）、Failed（失敗）、Codebase too large（コードベースが大きすぎます）などのステータスが表示され、制御用の .warpindexingignore も利用できます。すべてのプランで「コードベースあたり少なくとも 5,000 ファイル」をサポートしています。

ここには移行するものはありません。これは新しく得られる機能ですが、同期について考慮する必要があります：「多くのファイルが変更された場合やネットワークが遅い場合、エージェントがコンテキストにアクセスしようとする前に同期が完了しない可能性があります」。

Agent Memory は大きなメリットですが、3つの条件があります。 Warp の Agent Memory は「Warp のエージェントに、Warp Agent、Claude Code、Codex などのサポートされているハーネス間で永続的なメモリを提供します」。これは本格的なシステムです。個人、エージェント、チームのストア。自動抽出（「新しい知識は既存のメモリとマージされるか、競合時には上書きされます」）。ストアごとの読み取り専用または読み書きアクセスと、ストアごとの指示。トレーサビリティ（「各メモリはどこから来たのかを記録します」）。そして監査可能性（「メモリへのすべての変更が記録されます」）。

ここで、ドキュメントに記載されている、重要な3つの条件があります。まず、これは「リサーチプレビュー段階であり、デザインパートナー向けにチームごとに有効化」されており、ウェイティングリストがあります。サードパーティ製ハーネスのサポートは、それらがクラウドエージェントとして実行されている場合に適用されます。「リサーチプレビュー期間中、サードパーティ製ハーネスをローカルで実行することはサポートされていません」。そして、それは Warp 上に存在します：「メモリは、どのハーネスが読み書きするかに関係なく、その所有者（ユーザー、エージェント、またはチーム）に紐づいたままになります」。

つまり、率直に言えば、あなたのチームがデザインパートナーであり、Codex を Warp のクラウドエージェントとして実行している場合、ホストされたメモリレイヤーを利用できます。そうでない場合、または自身のターミナルで Codex をローカルに実行している場合は利用できません。そして、デフォルトでオフになっており、Codex のローカルメモリを有効にする方法 で解説されている Codex 独自のローカルメモリは、あなたのマシンに残されたままになります。

ステップ 1: ファイルを移動し、すべてのオーバーライドを矛盾（打ち消し）として再定義する

各 AGENTS.md を同じパスにコピーします。内容に変更はありません。

次に、判断が必要となるオーバーライドの処理を行います。ツリー内のすべての AGENTS.override.md について、それが何を抑制していたかを考えます。もしそれがルートのルールを置き換えるために存在していた場合（例：「npm test の代わりに make test-payments を使用する」）、そのディレクトリの AGENTS.md で明示的な指示として再定義してください。Warp ではルートのルールが依然として適用され、優先順位は2つのルールが直接競合する場合にのみ機能するためです。代替案を提示せずにルートのルールを抑制するために存在していた場合は、沈黙はもはや何も抑制しないため、その旨をはっきりと記述した文章が必要になります。

その際、グローバルファイルも確認してください。~/.codex/AGENTS.md を説明付きの個別の Global Rules に分割し、変更履歴を確認したい場合はバージョン管理にコピーを保管しておきます。Warp Drive ペインは優れた編集画面ですが、Git の履歴の代わりにはなりません。

もしリポジトリで project_doc_fallback_filenames を介してカスタムファイル名を使用していた場合は、適切なパスでそれらを AGENTS.md（すべて大文字）にリネームしてください。Warp の /init は既存の外部ルールファイルにリンクすることもでき、ドキュメント化されているリストは具体的です：「CLAUDE.md、.cursorrules、AGENT.md、GEMINI.md、.clinerules、.windsurfrules、.github/copilot-instructions.md」。そのリストにある単数形の AGENT.md に注意してください。複数形の AGENTS.md はネイティブで読み込まれます。

ステップ 2: Agent Memory について現実的に判断し、インデックスを作成して検証する

Agent Memory を中心とした計画を立てる前に、2つの質問に答えてください。あなたのチームはリサーチプレビューに対応していますか？そして、Codex をローカルではなく Warp のクラウドエージェントとして実行しますか？どちらかの答えが「いいえ」である場合は、Agent Memory を将来の機能として扱い、それが存在しないものとして設計してください。

これはこの機能を批判しているわけではありません。ドキュメントにそう書かれているからであり、登録されていないリサーチプレビューに基づいてワークフローを構築すると、3週間後にコンテキストの欠落に気づくという結果を招くからです。

次に、確実に得られるものを設定します。Warp でリポジトリを開いてインデックス作成を開始し、Settings > Code > Indexing and projects の下のステータスが Synced になるまで確認します。リポジトリが大きい場合は、.warpindexingignore を追加してください。その後、エージェントとの会話を1回実行し、References セクションを確認して、実際にどのルールが取り込まれたかを確認します。これは Codex の指示要約コマンドを実行するのと同じ直感であり、エージェントが指示ファイルを無視する理由 で説明されているように、エージェントが指示ファイルを無視する理由は通常、理解力ではなく検出の問題です。

ファイルの移行は、コピーとオーバーライドの監査だけで済みます。しかし、この移行によって浮き彫りになるのは、プロジェクトの永続的な知識が、たまたま使用していたツール（あるマシン上の Codex のローカルメモリ、または登録されてクラウドで実行している場合は Warp の Agent Memory）に依存してしまっているという事実です。

どちらも実用的な機能です。しかし、登録ステータスやマシン、エージェントが実行される場所に関係なく必要な知識を保管する場所としては、どちらも適切ではありません。そのレイヤーは、ハーネスの属性であるべきではありません。

それを外部に置くことで、計算はシンプルになります。ルールを移行し、コードベースのインデックス作成の恩恵を受け、エージェントが必要とする事実は最初の実行時にすでにそこに存在します。MemoryLake は3つのステップでセットアップできます。

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

サインインし、ダッシュボードから API キーを生成します。これはリサーチプレビューの登録状況や、エージェントがローカルで実行されているかクラウドエージェントとして実行されているかには依存しません。これこそが、今回の移行がもたらす曖昧さそのものです。

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

ルールファイルやインデックスでは提供できないものを投入します。アーキテクチャの決定とその背後にある理由、非推奨のサービスがなぜまだ存在するのか、ドメイン用語、所有権、理由が紐づいた制約などです。

振る舞いに関する記述は AGENTS.md に残します。これで 32 KiB の上限と戦う必要はなくなりました。これは、強制されるからではなく、意図的にそれらのファイルを短く保つための良い理由になります。

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

Warp をストアに向け、両方を並行して実行している間は Codex もそこに向けておきます。段階的な移行こそ、共有レイヤーがその真価を発揮する瞬間です。そうしなければ、2つのツールがそれぞれ部分的な情報しか持たない状態になってしまいます。これについては 複数のツール間で1つのメモリを共有する で説明されています。

最初の変化は、オーバーライドの監査が、繰り返される想定外のトラブルではなく、1回限りのコストになることです。例外が暗黙的ではなく明示的に記述されれば、次のツールに移行しても機能し続けます。

2つ目は、バイト制限がなくなったからといって、規律を失ってよいわけではないということです。32 KiB は恣意的な上限にすぎませんでした。短い指示ファイルの方が、長いものよりも依然としてエージェントによく従われます。かつてその容量制限を争っていた事実は、今や別の場所に保管されています。

3つ目は、Agent Memory が依存対象ではなく、ボーナス（付加価値）になることです。チームが登録されれば、すでに持っているものに加えて、追跡可能で監査可能な、チーム共有のメモリが追加されます。登録されなくても、設定の何一つとしてそれに依存していません。これこそが、特定のツールに依存せずにチームの AI コンテキストを維持する の本質です。

• ファイル名はすべて大文字に保つ。 Warp ではこれが必須です。Codex で登録された小文字やカスタム名は認識されません。
• すべての AGENTS.override.md を監査する。 Warp はルートと現在のディレクトリを同時に適用するため、記述を省くだけでは抑制されなくなります。
• 抑制したいルールを明示的に再定義する。 消し去りたいルールには、省略ではなく、それを打ち消す文章が必要です。
• グローバルファイルを説明付きのルールに分割する。 変更履歴が必要な場合は、バージョン管理されたコピーを保管してください。
• 品質を判断する前にインデックス作成を完了させる。 Synced ステータスを確認し、大規模なリポジトリでは .warpindexingignore を使用してください。
• References セクションを確認する。 これは Codex の指示要約コマンドに対する Warp の回答です。
• 登録されていない限り、Agent Memory を前提とした計画を立てない。 リサーチプレビュー段階であり、デザインパートナー向けのチーム単位の提供、プレビュー期間中はクラウドエージェントのみが対象です。
• いずれにせよ指示ファイルは短く保つ。 32 KiB の制限はなくなりましたが、簡潔にするべき理由は失われていません。

この移行におけるファイル関連の作業は単なるコピーであり、コードベースのインデックス作成とバイト制限の撤廃という2つの真のメリットは、何の労力もなく手に入ります。

慎重に対処すべき2つの事項は、移行によって失われるオーバーライドのセマンティクスと、優れているもののドキュメントに記載された3つの条件がある Agent Memory です。例外を再定義し、永続的な事実をどちらのツールにも属さないレイヤーに保持すれば、この切り替えにかかるコストは、エージェントがかつて知っていたことを再発見するために四半期を費やすのではなく、半日程度で済みます。