実際に移行できるもの
両ベンダーの公式ドキュメントに基づいた、レイヤーごとの全体像です。
ルートファイル：そのまま移行可能。 GitHub の指示（instructions）ドキュメントには、リポジトリ内の任意の場所にある AGENTS.md ファイルがリストされており、ディレクトリツリー内で最も近いファイルが優先されます。また、リポジトリのルートにある CLAUDE.md または GEMINI.md も代替として挙げられています。そのため、ルートの CLAUDE.md は変更なしで Copilot のエージェントに読み込まれます。ビルドコマンド、規約、アーキテクチャのメモなど、プロジェクトの知識がそこに集中している場合、重要な部分の大部分はすでに移行が完了しています。
パススコープのルール：明確なマッピングで移行可能。 これは、今回の移行において最も相性の良い組み合わせです。Claude Code の .claude/rules/ ディレクトリには、paths: フロントマターフィールドを持つ Markdown ファイルを配置でき、Claude が一致するファイルを処理するときにのみルールがロードされます。Copilot の同等機能は .github/instructions/NAME.instructions.md であり、そのフロントマターは glob 構文を使用した applyTo フィールドを受け取ります。考え方も glob の語彙も同じで、ファイル名の命名規則だけが異なります。一方のシステムで src/api/**/*.ts にスコープされたルールは、もう一方のシステムでも src/api/**/*.ts にスコープされたルールになります。
リポジトリ全体の指示：冗長な2つ目の場所。 Copilot は、リポジトリコンテキスト内のすべてのリクエストに適用される .github/copilot-instructions.md もサポートしています。ルートの CLAUDE.md が読み込まれている場合は、このファイルは不要です。両方を維持すると、2つのファイルのうち片方だけが更新されるという「ズレ（drift）」の問題が発生します。どちらか一方を信頼できる唯一の情報源（Source of Truth）として選択してください。
ネストされた `CLAUDE.md` ファイル：移行不可。 ここが多くの人が見落とすポイントです。Claude Code のドキュメントでは、作業ディレクトリからディレクトリツリーを遡り、途中の各ディレクトリから CLAUDE.md と CLAUDE.local.md をロードし、検出されたすべてのファイルをコンテキストに結合すると説明されています。サブディレクトリ内のファイルも検出され、Claude がそのディレクトリのファイルを読み込む際にオンデマンドでロードされます。しかし、Copilot が受け入れるのは リポジトリのルートにある CLAUDE.md のみです（これがドキュメント化されたスコープです）。packages/billing/CLAUDE.md は Copilot からは見えません。Copilot ネイティブな方法でディレクトリごとの指示を表現するには、ネストされた AGENTS.md を使用します。ドキュメントによると、ツリー内で最も近いものが優先されます。モノレポでは、この1つの違いによって、指示の大部分が静かに適用されなくなる原因になります。
`@` インポート：移行先なし。 Claude Code の CLAUDE.md は、@path/to/import 構文を使用して他のファイルを再帰的に取り込むことができます（ドキュメント上の最大深度は4ホップ）。GitHub の指示ドキュメントには、インポートメカニズムの記載はありません。ルートファイルが5つの実際のドキュメントをインポートするだけの薄いインデックスである場合、Copilot はインデックスのみを読み込み、インポートされたドキュメントは一切読み込みません。
`CLAUDE.local.md`：移行先なし。 Claude Code は、バージョン管理から除外する個人設定用のプロジェクトルート CLAUDE.local.md をサポートしています。Copilot における個人設定のレイヤーは「個人用の指示（personal instructions）」であり、リポジトリ内ではなく GitHub アカウントに保存されます。これは実際のレイヤーであり、GitHub の優先順位では「個人用の指示が最も高い優先度を持ちます。次にリポジトリの指示、最後に組織の指示が優先されます」とされています。しかし、これはローカルリポジトリ内のファイルではないため、コンテンツを移行するにはコピーではなく、再入力する必要があります。
自動メモリ（Auto memory）：移行先なし（そもそもポータブルではない）。 Claude Code の自動メモリはデフォルトで有効になっており、プロジェクトごとのメモを ~/.claude/projects/<project>/memory/ に保存し、すべてのセッションで MEMORY.md の最初の200行または25KBをロードします。これは明示的にマシンローカルなものであり、ドキュメントには「マシン間やクラウド環境間で共有されない」と記載されています。GitHub の指示ドキュメントには、セッション間でメモリやコンテキストを永続化することに関する記述はありません。指示ファイルがドキュメント化された永続化メカニズムです。したがって、このレイヤーは移行されません。その理由は Copilot の設計によるものではなく、そもそもこのレイヤーが共有可能なアーティファクトではなかったためです。すでにこの壁にぶつかっている場合は、Claude Code がマシン間で記憶を忘れる理由 で説明されているのと同じ状況です。
手順に入る前に、1つ前提を整理しておきます。両方のシステムにおいて、指示は「強制（enforcement）」ではなく「コンテキスト（context）」として説明されています。Claude Code のドキュメントでは、指示は「強制される設定ではなくコンテキスト」であり、システムプロンプトの後にユーザーメッセージとして配信され、「厳格な準拠は保証されない」とされています。GitHub の優先順位に関する記述も、「ただし、関連するすべての指示セットが Copilot に提供されます」で結ばれています。どちらのベンダーも絶対的な従順さを保証していません。移行は、従わせたいことではなく、何が 読み込まれるか を基準に計画してください。
手動での移行手順
ステップ 1: 移行先があるレイヤーをマッピングする
上から順に作業を進め、すべてを1つの巨大なファイルにまとめたいという衝動は抑えてください。
ルートの CLAUDE.md はそのままにしておきます。これで動作します。Copilot がこのファイルを読み込むことを知らないチームメンバーに対して明示したい場合は、ファイルの上部に「両方のエージェントがこのファイルを読み込みます」という1行のコメントを追加してください。.github/copilot-instructions.md に複製しないでください。2つのコピーを維持することになり、片方が古くなってしまいます。
paths: フィールドを持つ各 .claude/rules/*.md ファイルを、applyTo の下に同じ glob パターンを持つ .github/instructions/<name>.instructions.md に変換します。差分（diff）でペアが明確にわかるように、認識しやすいファイル名にしてください。paths: フィールドを持たないルールは無条件のルールです。Claude Code は起動時に .claude/CLAUDE.md と同じ優先度でこれらをロードするため、これらはパススコープのディレクトリではなく、ルートファイルまたは AGENTS.md に配置する必要があります。
ネストされた CLAUDE.md ファイルを、同じディレクトリ内のネストされた AGENTS.md ファイルに昇格させます。これは名前の変更と、ある決定を伴います。両方のエージェントに同じネストされたコンテンツを読み込ませたい場合、Claude Code のドキュメントはこの非対称性について直接言及しています（「Claude Code は CLAUDE.md を読み込み、AGENTS.md は読み込みません」）。推奨されるパターンは、@AGENTS.md を使用して AGENTS.md をインポートする CLAUDE.md を作成するか、シンボリックリンクを作成することです。したがって、各サブディレクトリに1つの実ファイル（AGENTS.md）と、それをインポートする1行の CLAUDE.md を保持できます。これにより、両方のエージェントが同じテキストを読み込み、編集する場所は1つになります。
これ以上進める前に、インポートをフラット化（インライン化）してください。すべての @ インポートされたファイルは、それをインポートしたファイル内のインラインコンテンツ、関連するディレクトリ内のネストされた AGENTS.md、またはパススコープの指示ファイルにする必要があります。Claude Code 自身のドキュメントでも、インポートへの分割は「整理には役立つが、インポートされたファイルは起動時にロードされるため、コンテキストは削減されない」と指摘されています。そのため、フラット化しても Claude 側のコンテキストの観点からは何も失われませんし、コンテンツを Copilot に届ける唯一の方法でもあります。
ステップ 2: 移行先がないレイヤーの扱いを決定する
3つの山があり、それぞれデフォルトのままにするのではなく、実際の決定を下す必要があります。
`CLAUDE.local.md`。内容を読み、整理します。これらのファイルのほとんどは、純粋に個人的な好み（サンドボックスの URL、好みのテストデータなど）と、数ヶ月前にコミットしておくべきだったプロジェクトの事実が混ざり合っています。後者はルートファイルにコミットしてください（Copilot を使うかどうかにかかわらず、そうして良かったと思うはずです）。前者は Copilot の個人用の指示に再入力します。これらはこのリポジトリだけでなく、作業するすべてのリポジトリに適用されることに注意してください。どちらの場所にも置きたくないものは削除してください。1台のマシンの1つのツールしか読み込めないファイルは、知識ベースとは言えません。
自動メモリ（Auto memory）。メモリディレクトリを開き、MEMORY.md とトピックファイルを読みます。これは移行プロセス全体の中で最も価値のある時間です。なぜなら、ビルドの癖、デバッグの洞察、テストが不安定な理由など、あなたがわざわざ書き留めなかった、Claude がプロジェクトについて理解したことの記録がそこにあるからです。これらは自動的には Copilot に移行されません。永続的な事実は、ルートファイルまたはパススコープの指示ファイルに昇格させてください。特定のモデルの癖に関するメモや、単発のデバッグの軌跡など、残りの部分はそのままにしておきます。それらは間違いではありませんが、共有されるべき知識ではありません。
移行時に考慮すべき Copilot 専用のメカニズム。Copilot 側には Claude Code に相当する機能がないものが2つあります。これらを今知っておくことで、後で驚くのを防ぐことができます。パス固有の指示ファイルは、オプションの excludeAgent フィールドをサポートしており、"code-review" または "cloud-agent" による使用を防ぐことができます。そのため、コードレビューから意図的に除外していたルールを、Copilot 側で除外する手段はありません。また、組織の指示（organization instructions）は、他の誰かが管理している可能性のある実際のレイヤーです。GitHub はこれを優先順位の最後に位置づけていますが、依然として提供されます。元に戻す場合、または両方を実行する場合は、管理者にそのレイヤーに何が含まれているかを確認してください。これは、あなたが設定したことのない出力を形成します。
より良いアプローチ：エージェントに依存しない単一のメモリレイヤー
上記の手順を一度行うだけなら合理的です。しかし、新しいエージェントが登場するたびにこれを行うのは本質的な問題であり、状況は悪化する一方です。各ツールが独自のファイル名、独自のフロントマター、独自の優先順位、独自のプライベートメモリストアを考案するため、N個のツールがあれば、同じプロジェクト知識のN個のコピーがN個の異なるペースでズレていくことになります。
MemoryLake は、そのパターンを打破するために存在します。プロジェクトの知識を1つのメモリレイヤーに保持し、各エージェントが独自のローカルコピーからではなく、そこから読み取れるようにします。指示ファイルは本来あるべき場所（毎セッションでコンテキストに含める必要のあるルール用）に留まり、蓄積され成長し続ける知識体系は、両方のエージェントがアクセスできる場所に配置されます。セットアップは3つのステップです。
ステップ 1: API キーを作成する
MemoryLake にサインインし、API キーを作成します。接続するすべてのツールで1つの認証情報を使用します。これが重要なポイントです。認証情報は、現在選択しているエージェントよりも長生きします。
ステップ 2: 最初のメモリをアップロードする
移行中に発掘したばかりの素材から始めましょう。自動メモリからの永続的な事実、CLAUDE.local.md に隠れていたプロジェクトの真実、決定ログ、それらがなければ恣意的に見える規約の背後にある理由などです。エントリは短く具体的に保ちます。優れたエントリの基準は、新しいチームメンバーや新しいエージェントが、追加の質問をすることなくそれに基づいて行動できるかどうかです。
ステップ 3: AI とエージェントを接続する
ツールを接続します。MemoryLake は MCP および API 経由でアクセスできるため、MCP ネイティブのエージェント（Claude Code、Codex、OpenClaw など）は MCP サーバーを指定することで接続し、それ以外は API を介して同じメモリを読み取ります。指示ファイルは引き続きその限定された役割を果たし、共有知識がツールごとに重複することはなくなります。
2つの率直な制限事項。MemoryLake は強制レイヤーではありません。モデルの決定に関係なくルールを維持する必要がある場合は、両ベンダーのドキュメントが指示を「設定ではなくコンテキスト」と呼んでいるのと同様に、フックや CI チェックに記述すべきです。また、既存のファイルを自動的に読み取るわけではありません。上記の移行インベントリの作成は、一度は行う必要のある作業です。
実務における変化
2つ目のエージェントの導入コストが1つ目よりも低くなります。 Claude Code と並行して Copilot を追加する際、コストがかかるのは設定ではなく、最初のツールのセットアップにすでに暗黙的に含まれていた知識を再導出することです。これを共有レイヤーに対して一度行えば、3つ目のエージェントの追加は「接続」するだけであり、一大プロジェクトにはなりません。
モノレポが特殊なケースではなくなります。 ネストされたファイルの非対称性は、指示が静かに適用されなくなる最も一般的な原因です。領域ごとの知識が、各ツールがどのディレクトリでどのファイルを検出するかに依存するのではなく、検索可能（retrievable）になれば、ツリー構造が互換性の問題を引き起こすことはなくなります。
指示ファイルが短くなり、効果が向上します。 Claude Code のドキュメントでは、1ファイルあたり200行未満に抑えることを推奨しており、長いファイルは「より多くのコンテキストを消費し、準拠度を低下させる」と指摘しています。Copilot のガイダンスも同様の方向性を示しています。常にロードされるファイルから参照知識を排除し、検索されるものに移行することは、単に整理整頓になるだけでなく、残されたルールがどれだけ確実に守られるかを測定可能なレベルで向上させます。
レビューによってズレが隠されるのではなく、検出されるようになります。 信頼できる唯一の情報源が1つであれば、古くなったエントリは単なる差分（diff）として現れます。ツールごとに5つのコピーがある場合、古くなったエントリは「なぜ一方のエージェントが他方の信じていないことを信じているのか」という謎になってしまいます。
CLAUDE.md と Copilot を併用するためのベストプラクティス
ディレクトリごとに1つの実ファイルと、ポインタを用意する。 実コンテンツとして AGENTS.md を保持し、それをインポートする1行の CLAUDE.md を作成します。両方のエージェントが同一のテキストを読み込み、編集する場所は正確に1つになります。
ルートファイルを絶対に複製しない。 ルートの CLAUDE.md と、ほぼ同一のテキストを含む .github/copilot-instructions.md を両方維持することは、将来的に不整合を引き起こす原因になります。どちらか一方を選択してください。
両方のシステムで glob を同一に保つ。 paths: と applyTo が同じ構文で同じファイルセットを記述している場合、それらをペアとしてレビューできます。これらがズレると、特定の領域のルールが一方のツールにのみ適用され、もう一方には適用されないという状況が発生します。これはルールが全くない状態よりも悪質です。
構造変更の後は、何がロードされたかを必ず検証する。 Claude Code はセッション中にロードされたメモリファイルのリストを表示します。ファイルを移動した後はこれを確認してください。Copilot 側では、ネストされた AGENTS.md が実際に読み込まれていることを、思い込みに頼らず確認してください。読み込まれていないファイルは、モデルが指示を無視しているように見えます。この違いについては、GitHub Copilot がコードベースのコンテキストを忘れる理由 で説明されています。
組織レイヤーについて確認する。 リポジトリが指示の設定された組織（org）の下にある場合、あなたがそれを読んでいるかどうかにかかわらず、そのテキストは Copilot に提供されています。内容を確認してください。
必須のルールは指示ではなく、強制メカニズムに配置する。 両ベンダーとも、指示ファイルは動作を方向付けるものであり、保証するものではないことを明言しています。すべてのコミットの前に必ず実行されるべきことは、フックや CI に記述してください。
結論
今回の移行における最大のトピックは、非常に喜ばしいものです。Copilot はルートの CLAUDE.md を読み込むため、すでに維持しているファイルはそのまま機能し続けます。作業が必要なのは、その周囲にある4つのレイヤーです。AGENTS.md への昇格が必要なネストされたファイル、フラット化が必要なインポート、整理が必要なローカルファイル、およびそもそも共有不可能だった知識を保持する自動メモリディレクトリです。
この棚卸しを一度行い、その出力を両方のエージェントが読み取れる場所に配置してください。そうしなければ、次のツールを導入する際、さらに悪いスタート地点から同じ作業を繰り返すことになります。なぜなら、その頃には2つのコピーがズレてしまっているからです。逆方向の移行も検討している場合は、GitHub Copilot から Claude Code への移行 で逆のプロセスを解説しています。また、CLAUDE.md から Cursor への移行 では、3つ目の一般的な移行先について扱っています。