MemoryLake
すべての記事に戻る
Tutorial2026年8月12日·11 分で読了

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

まず良いニュースからお伝えします。チームの指示書が `AGENTS.md` に保存されている場合、この移行作業の大部分はすでに完了しています。GitHub のドキュメントによると、Copilot は「リポジトリ内の任意の場所に保存されている」`AGENTS.md` ファイルを読み込み、最も近いファイルが優先されます。Codex も `AGENTS.md` を全く同じ方法で解決します。同じファイル名、同じ「最も近いものが優先される」動作であり、変換は不要です。

それ以外の部分についての直接的な答えはこうです。Copilot 固有のものはすべて再構築する必要があり、Codex のインポーターは役に立ちません。`/import` がカバーしているのは Claude Code と Cursor であり、Copilot は対象外だからです。つまり、3つのレイヤーを手作業で再構築する必要があります。リポジトリ全体の `.github/copilot-instructions.md`、`applyTo` glob を使用したパススコープの `.instructions.md` ファイル、そして(多くの人が忘れがちな)管理者が設定した組織(Organization)レベルの指示書(これには Codex に対応するものが存在しません)です。

本記事では、そのまま移行できるもの、移行できない3つのレイヤーを再構築する方法、そして次のエージェントへの切り替えを、1ヶ月の予期せぬトラブルではなく、半日の作業で済ませる方法について解説します。

実際に移行できるもの

`AGENTS.md` は何もしなくても移行できます。 両方のツールがこれを読み込み、どちらも最も近いものを優先して解決します。すでに AGENTS.md に集約している場合は、リポジトリで Codex を開くだけで指示が有効になります。これは、今期どのエージェントを使用しているかに関わらず、このファイルに標準化すべき最大の理由です。

`.github/copilot-instructions.md` はそのまま移行されませんが、きれいに変換できます。 GitHub はこれを「リポジトリのコンテキストで行われるすべてのリクエストに適用される」指示と説明しています。Codex にはこれと正確に一致する概念(リポジトリルートの AGENTS.md)があるため、これは名前を変更してコピーし、古い内容を削除するために一読するだけで済みます。

パススコープの指示は変換できますが、機械的には行えません。 Copilot は .github/instructions の下にある1つ以上の NAME.instructions.md ファイルをサポートしており、それぞれに glob 構文を使用した applyTo フロントマターフィールドがあり、カバーするファイルやディレクトリを宣言します。Codex には glob メカニズムはありません。その唯一のスコープツールは、ファイルがどこに配置されているかです。~/.codex/AGENTS.md(または $CODEX_HOME)、リポジトリルート、中間ディレクトリ、そして作業ディレクトリの順に、最も近いファイルが優先される形で上から下へと組み立てられます。

したがって、applyTo: "src/api/**" でスコープされたルールは、src/api/ 内の AGENTS.md になります。これは、glob がディレクトリレイアウトに従っている場合には機能しますが、従っていない場合には判断が必要になります。たとえば、**/*.test.ts のような glob はツリー全体にまたがるため、単一の配置場所がありません。

組織(Organization)の指示はまったく移行されません。 GitHub は「個人用の指示が最も高い優先度を持ちます。次にリポジトリの指示、そして組織の指示が最後に優先されます」という3層の優先順位をドキュメント化しています。Codex には、その第3層を受け取るための組織管理の指示レイヤーがありません。

これが実務的に何を意味するかに注意してください。Copilot の出力を形成しているガイダンスの一部は、他の誰かによって書かれたものであり、あなたが一度も読んだことがない可能性があります。移行する前に、組織が指示を設定しているかどうかを確認し、そのコピーを入手してください。そうしないと、なぜ Codex がチームのものとは微妙に異なるコードを書くのか、何週間も悩むことになります。

`excludeAgent` に対応するものもありません。 Copilot のパス固有の指示は、code-reviewcloud-agent などの値を持つオプションの excludeAgent フィールドを受け入れるため、特定のサーフェスからルールを意図的に除外できます。Codex にはこれを表現するものがありません。コードレビューから除外するようにスコープしていたルールは、変換されると、そのファイルがロードされるすべての場所で適用されるようになります。これらは特に確認してください。

個人用の指示はグローバルファイルに変換されます。 GitHub の個人用の指示は、作業全体に適用され、最も高い優先度を持ちます。Codex での対応物は ~/.codex/AGENTS.md です。マシン上のすべてのプロジェクトでロードされるため、簡潔に保つようにしてください。

どちらのツールでも、ファイルに保持されないもの。 GitHub のカスタム指示のドキュメントには、Copilot がセッション間でメモリを保持するという主張はなく、Codex 独自のメモリ機能はデフォルトでオフになっています。そのため、規約の背後にある理由(障害、制約、却下された代替案など)は、移行するためのどちらのシステムにも存在しません。これが、完全に移行されたセットアップであっても、プロジェクトのことを理解していないように感じられる原因であり、Copilot がコードベースのコンテキストを失うという不満の背景にある部分です。

手動移行の手順

ステップ 1: 自分が書いていないものも含め、4つの Copilot レイヤーすべてをインベントリ化する

Codex に触れる前に、以下を収集してください:

  • .github/copilot-instructions.md — リポジトリ全体のファイル
  • .github/instructions/ 配下のすべて、および各ファイルの applyTo パターンと excludeAgent の値
  • すでにリポジトリ内にある AGENTS.md ファイルとその場所
  • GitHub 設定の個人用の指示
  • 組織(Organization)の指示(オーナーまたは管理者に問い合わせる必要があります)

次に、移行コストを抑えるための一般的なトリアージと同様に、オリジンごとに分類します。リポジトリから派生したもの(削除 — Codex はリポジトリを読み込みます)、自分が書いて今も有効なもの(これが移行対象)、廃止されたもの(内容を覚えている今のうちに削除)。

作業を進める際は、applyTo パターンに注意してください。これらは飾りではなく、各ルールがいつ重要になるはずだったかを示す唯一の記録です。スコープなしでコピーされたルールは、すべてのセッションでノイズになるか、無関係に見えて削除してしまうルールのどちらかになります。

ステップ 2: スコープをディレクトリ位置として再構築し、残りの処理を決定する

残った各ルールを、Codex が見つけられる場所に配置します:

  • リポジトリ全体 → リポジトリルートの AGENTS.md(コミットする)。
  • パススコープかつディレクトリ型 → そのディレクトリ内の AGENTS.mdapplyTo: "src/api/**"src/api/AGENTS.md になり、スコープはツールが従うべきパターンではなく、場所によって強制されるようになります。
  • パススコープかつ横断的 → これは判断が必要です。多数のパッケージにまたがって **/*.test.ts にマッチするルールには、3つの選択肢があります。短くて重要な場合はルートファイルに昇格させるか、テストが実際に存在する2〜3のディレクトリにコピーを配置するか、あるいは削除してリンターに任せるかです。すべてを昇格させると、ルートファイルが600行に達し、従われなくなってしまいます。
  • 個人用~/.codex/AGENTS.md(簡潔に保つ)。
  • 組織レベル → Codex には組織レイヤーがないため、ルート AGENTS.md のコミットされたセクションとしてリポジトリに組み込みます。誰かの個人的な好みとして削除されないよう、組織のポリシーに由来するものであることをファイル内に明記してください。
  • `excludeAgent` が設定されているもの → 今後すべての場所に適用すべきかどうかを意識的に決定し、適用すべきでない場合は削除します。

さらに2つの技術的な注意点があります。Codex は CLAUDE.md を読み込まないため、リポジトリが他のツールからそれを引き継いでいる場合は、その内容も AGENTS.md に存在させる必要があります。また、Codex のメモリは別の決定事項です。設定の「パーソナライズ(Personalization)」で有効にするか、[features] memories = true で有効にし、何が得られるかを理解しておいてください。これは ~/.codex/memories/ に保存される生成された状態であり、プロジェクトごとではなくグローバルで、そのマシン上のみで有効です。記録としてではなく、便利なレイヤーとして役立ちます。

その後、組み立てられた結果全体を一度に読み通してください。これは多くの人がスキップしがちなステップですが、削除済みのパッケージを使用するようエージェントに指示している2024年のルールなどを見つけることができる場所です。

より良い方法:どちらのエージェントでも使える単一のメモリレイヤー

ステップ1のインベントリが実際に何を意味していたかに注目してください。4つのレイヤー、3つのフォーマット、管理者に依頼しなければならなかった1つの階層、指示書のどこにも「なぜ(why)」に関する記述が1文も含まれていません。ルールとは、書き残されなかった決定事項の圧縮された出力なのです。

これこそが、再配置する価値のある部分です。指示ファイルはエージェントが読み取るリポジトリに保持し、その背後にある理由は、ベンダーの設定ディレクトリ内ではないストアに配置します。

MemoryLake はそのためのメモリレイヤーです。ルールの背後にある決定事項、障害レポート、ソースドキュメントを1つのストアにまとめ、Claude や Codex などの MCP 対応ツールから直接、また API を通じて ChatGPT から読み取ることができます。AGENTS.md は「何をすべきか」を指示し、ストアは「なぜか」を説明するため、次回の移行は不要になります。

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

キーを生成し、約30秒で最初のリクエストを送信できます。セッションに貼り付けるのではなく、環境変数やシークレットマネージャーに保存してください。

MemoryLake API キーの作成
MemoryLake API キーの作成

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

ルールの派生元となったドキュメント、画像、ファイルを投入します。アーキテクチャ決定記録(ADR)、障害レポート、API 契約、組織の指示が強制していたセキュリティ要件、全員が合意した RFC などです。1行のルールではなく、ソースをアップロードしてください。1行のルールはすでに手元にあり、常に疑問視され続けるものだからです。

MemoryLake への最初のメモリのアップロード
MemoryLake への最初のメモリのアップロード

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

Claude、Codex、OpenClaw、その他の AI エージェントに、MCP または API を介してメモリへのアクセスを許可します。Codex は、AGENTS.md ファイルと並行して MCP 経由でストアを直接読み込みます。ChatGPT の場合は、API を介して必要な情報を取得し、プロンプトやモデルを呼び出すワークフローに注入します。

MCP 経由で AI とエージェントを接続する
MCP 経由で AI とエージェントを接続する

実務における変化

最初の違いは、横断的なルールがジレンマでなくなることです。すべての場所でテストファイルにマッチするルールを、6つのディレクトリに複製したり、ルートファイルに詰め込んだりする必要はありません。エージェントがテストを作業しているときにのみ取得され、そうでないときは除外されます。

2つ目は、移行時に組織ポリシーレイヤーが消失しなくなることです。管理者が設定したルールは目に見えないインフラでした。それらが根拠とともに文書化され、検索可能な記録になれば、ツールの変更や管理者の交代を乗り越えて存続します。

3つ目は、ルートの AGENTS.md を、遵守されるのに十分なほど簡潔に保てることです。すべてのセッションでロードされるすべてのファイルは、リクエストと競合します。検索機能が詳細を担うことで、常にロードされるファイルには、回答を誤らせるような制約のみを保持させることができます。これにより、セッションごとにプロジェクトを再説明する必要がなくなります。

また、これは Codex 独自のメモリとも連携します。ローカルメモリはそのマシン上でのあなたの習慣を蓄積し続け、共有ストアはチームメイトや他のツールが必要とするものを保持します。一方が他方のふりをすることはありません。この切り分けこそが、マルチツール構成の乖離を防ぐポイントです。

コーディングエージェント切り替えのベストプラクティス

必要になる前に AGENTS.md に標準化する

この移行において AGENTS.md レイヤーが無料で移行できる理由は、両方のツールがそれを読み込むからです。この特性は最適化する価値があります。ベンダー固有のファイルではなく AGENTS.md で表現できるものはすべて、二度と移行する必要のないコンテンツになります。

組織の指示を文書で入手する

これは、Copilot から移行する際に最も見落とされがちな項目です。他の誰かのルールが、最も低い優先度階層であなたの出力を形成していました。それらを要求し、読み、何を移行するかを決定してください。6週間後に微妙に間違ったコードを見て、それらが存在しないことに気づくような事態は避けてください。

スコープを位置で表現し、一部のルールで精度が低下することを受け入れる

ディレクトリ配置は Codex の唯一のスコープメカニズムであり、ツリーを横断する glob パターンにとっては明らかなダウングレードです。変換がロスレスであるかのように装うのではなく、ルールごとにそのトレードオフを明示的に定義してください(昇格、複製、または削除)。

常にロードされるファイルを小さく保つ

ルートの AGENTS.md~/.codex/AGENTS.md は常にロードされます。そこには厳格な制約のみを記述し、それ以外は記述しないでください。長い指示ファイルはエラーを吐くわけではありません。ただ静かに無視されるようになるだけであり、その方が厄介です。

信頼する前に、実際に何がロードされたかを確認する

指示の移行後に発生する失敗モードはサイレントです。エージェントは、あなたのルールを一度も見なかったことを通知してくれません。ファイルを配置したら、リポジトリでセッションを開き、Codex に現在動作している指示を述べるよう求めてください。その後、サブディレクトリで作業して再度確認します。そのディレクトリで作業しているときにディレクトリスコープの AGENTS.md が表示されない場合、配置が間違っています。1ヶ月間微妙にずれた差分に悩まされるより、1分でそれを知る方がはるかに良いでしょう。

指示と強制を混同しない

どちらのツールの指示ファイルも、動作を保証するものではありません。プロンプトにコンテキストを追加するだけです。フォーマット、禁止されたインポート、保護されたファイル、コミットポリシーなどは、リンター、フック、CI に属します。指示ファイルには理由を説明させ、ツールに保証を任せましょう。

結論

GitHub Copilot から Codex への移行は、無料(手間なし)でできる部分とそうでない部分に明確に分かれます。無料:AGENTS.md。これは両方のツールがリポジトリ内の任意の場所から読み込み、最も近いものが優先されます。無料ではない:リポジトリ全体の .github/copilot-instructions.mdapplyTo glob をディレクトリ配置に変更する必要があるパススコープの .instructions.md ファイル、そして Codex には対応するものがない組織(Organization)レイヤーです。そして、/import は Claude Code と Cursor を対象としているため、これらを一切処理してくれません。

したがって、管理者が所有するものを含む4つのレイヤーすべてをインベントリ化し、削除キーを手にオリジンごとにトリアージし、スコープを位置として再構築し、信頼する前に組み立てられた結果を一度読み通してください。そして、それらのルールの背後にある理由をアシスタントが読み取る1つのストアに配置することで、次の切り替えを発掘作業ではなく単なる設定変更にしましょう。もし移行先が Cursor である場合は、Copilot から Cursor への移行パスで、逆のトレードオフ(真の条件付きロードと、独自の変換コスト)を持つルールシステムについて解説しています。

よくある質問

Codex は Copilot の設定を自動的にインポートできますか?

いいえ。Codex の /import は Claude Code と Cursor をソースとしてサポートしていますが、Copilot はその中に含まれていません。作業は手動になりますが、指示がすでに両方のツールで読み取れる AGENTS.md に存在している場合は、見た目よりも作業量は少なくなります。

Codex は .github/copilot-instructions.md を読み込みますか?

いいえ。Codex は、ホーム設定から作業ディレクトリに向かって解決される AGENTS.md ファイルを読み込み、最も近いファイルが優先されます。copilot-instructions.md の内容をリポジトリルートの AGENTS.md にコピーし、不要な部分を整理してください。

applyTo glob はどうなりますか?

直接対応するものはありません。Codex はディレクトリ位置によって指示のスコープを決定するため、ディレクトリにマッチする glob はそのディレクトリ内の AGENTS.md になります。ツリーを横断する glob については、ルートファイルに昇格させるか、重要な数箇所に複製するか、あるいは処理をリンターに任せるかの判断が必要です。

エンタープライズ組織に所属していますが、失うものはありますか?

潜在的に最も重要なレイヤーを失う可能性があります。GitHub は組織の指示を、すべてのリクエストに適用される最も低い優先度の階層としてドキュメント化していますが、Codex にはこれに相当するものがありません。オーナーにテキストを依頼し、それがどこから来たのかについてのメモを添えてリポジトリにコミットしてください。

Copilot や Codex はセッション間でプロジェクトを記憶していますか?

どちらのツールでも指示ファイルが永続化メカニズムであり、記憶されるのではなくセッションごとに再読み込みされます。GitHub のカスタム指示のドキュメントには、セッション間でメモリを保持するという主張はありません。Codex はローカルメモリを提供していますが、デフォルトでオフになっており、プロジェクトごとではなくグローバルで、1台のマシンに限定されています。どちらも共有レコードではないため、何かが提供しない限り、Codex は依然としてプロジェクトのコンテキストなしで起動することになります。

Codex が実際に AGENTS.md を読み込んだかどうかをどうやって確認できますか?

直接聞いてみてください。リポジトリでセッションを開始し、ロードされた指示を述べるよう求めます。次に、独自の AGENTS.md を持つサブディレクトリ内から同じ確認を繰り返します。解決はホーム設定から作業ディレクトリに向かって実行され、最も近いファイルが優先されるため、そのディレクトリで作業しているときにルールが表示されない場合は、無視されているのではなく配置が間違っています。

代わりに Claude Code に移行すべきですか?

これは同じような形状の異なる変換です。AGENTS.md の配置の代わりに CLAUDE.md の階層を使用し、より多くのソースをカバーするインポーターが用意されています。Copilot から Claude Code への移行でその手順を解説しています。どちらの方法をとるにしても、正しく設定する価値があるのは、これらのファイルのいずれにも含まれていないレイヤーです。