コーディングエージェントを切り替えるとコンテキストが失われる理由
Copilot のメモリは想像以上に薄い
数ヶ月間使用していると、Copilot はプロジェクトのことをすべて理解しているように感じられます。しかし、セッションごとに実際に保持しているのは、開いているファイル、リポジトリから取得できる情報、そして指示ファイルだけです。リポジトリレベルのカスタム指示（.github/copilot-instructions.md や、それに付随するスコープごとの指示ファイルやプロンプトファイル）は実在し、ポータブルで、バージョン管理も可能です。しかし、それ以外のすべては、その都度実行される推論にすぎず、チャット履歴は単なる対話の記録であってナレッジベースではありません。開発者は常にこの限界に直面しています。その仕組みについては、why GitHub Copilot forgets your codebase context で詳しく解説しています。
価値のある情報は書き残されていない
本当に価値のある知識とは、会話の中でしか生み出されなかったものです。たとえば、なぜ決済モジュールが重複書き込みを許容するのか、どのテストスイートが誤検知を起こすのか、認証サービスの切り出しに前回失敗した理由は何だったのか、といったことです。これらはチャットの中で Copilot に説明したはずです。しかし、コピーできるファイルは存在せず、仮にあったとしても、それらをキャプチャできるエクスポートフォーマットはありません。
Claude Code もまたステートレスである
これは、ほとんどの移行ガイドが見落としている点です。Claude Code は、すべてのセッションをまっさらな状態で開始します。プロジェクトのルートにある CLAUDE.md やユーザーレベルの ~/.claude/CLAUDE.md を読み込み、MCP 経由で接続されたツールにアクセスすることはできますが、セッション自体には永続的なメモリは蓄積されません。コンテキストの保存方法を変えずにツールだけを切り替えると、UI が変わるだけで同じ問題に直面することになります。これについては、Claude Code forgetting project context で詳細に説明されています。
ツールの切り替えは、インターフェースの変更にすぎません。コンテキストの置き場所を変えることこそが、根本的な解決策となります。
手動での移行手順
ステップ 1: Copilot が実際に保持しているものを収集する
リポジトリ内を整理し、ポータブルな要素を収集します：
.github/copilot-instructions.md— リポジトリ全体の指示- これまでに蓄積された、特定のスコープ向けの指示ファイルや再利用可能なプロンプトファイル
- リンターやフォーマッタの設定など、規約をコード化したエディタ設定
- Wiki、ADR（アーキテクチャ決定記録）フォルダ、オンボーディングドキュメントなどにピン留めされているもの
次に、より困難な棚卸しを行います。過去2週間の Copilot のチャット履歴を開き、複数回説明せざるを得なかったコンテキストをすべて書き出します。その繰り返しこそが「メモリ監査」です。何度も再入力していた内容こそ、保存されていなかった情報そのものです。
ステップ 2: Claude Code が読み取れる場所に再構築する
Claude Code は CLAUDE.md を読み取るため、まずはここから始めます。指示内容を移植し、プロジェクトの成長に合わせて使い続けられるように構造化します：
- プロジェクトの全体像：どのようなサービスがあり、何が何と通信し、何が非推奨なのか
- 規約：命名規則、エラーハンドリング、テストの期待値、コミットやレビューのルール
- 理由を伴う決定事項：「Postgres を使用する」ではなく「キューモードのワーカーがインプロセス状態を破損したため、Postgres を採用」など
- 罠：不安定なテストスイート、隠れた結合があるモジュール、順序通りに実行する必要があるマイグレーション
ユーザーレベルの好みは ~/.claude/CLAUDE.md に、プロジェクトの事実はリポジトリ内のファイルに分けて記述することで、チームメンバーはあなたの個人設定に影響されることなく、プロジェクトに関する情報だけを引き継ぐことができます。
これで Claude Code のセットアップは完了し、ゼロから始めるよりもはるかにスムーズになります。しかし、これには限界もあります。単一の Markdown ファイルは「概要説明書」であって「メモリ（記憶）」ではありません。自動的に成長することはなく、過酷なデバッグセッションの後に誰も更新しません。また、インシデントレビューに使用するアシスタントや、来月より安価なモデルに切り替えるエージェントにその内容が共有されることもありません。半年も経てば、CLAUDE.md は陳腐化するか、あるいは肥大化してしまうでしょう。
より良い方法：どちらのツールでも使える単一のメモリレイヤー
この移行作業を繰り返さないための解決策は、使用するエージェントの内部にプロジェクトの知識を保存するのをやめることです。MemoryLake はツールの外部に位置します。アーキテクチャのメモ、決定事項、リポジトリのコンテキストは単一のメモリレイヤーに保存され、Claude Code は MCP 経由でそこから読み取ります。将来的に Codex を追加したり、オートコンプリート用に Copilot を併用したり、別のエージェントに作業を任せたりする場合でも、それぞれが独自のコピーを再構築するのではなく、同じソースを読み取ることができます。
ステップ 1: API キーを作成する
キーを生成し、約30秒で最初のリクエストを送信できます。
ステップ 2: 最初のメモリをアップロードする
プロジェクトの実際のコンテキストを保持するドキュメント、画像、ファイルをアップロードします。先ほど作成した CLAUDE.md、アーキテクチャ図、ADR、ランブック、インシデント報告書、API 仕様書などがこれに該当します。これらは、かつてチャットの中にしか存在しなかった資料です。
ステップ 3: AI とエージェントを接続する
MCP または API を介して、Claude、Codex、OpenClaw、およびその他のエージェントにそのメモリへのアクセス権を付与します。Claude Code の具体的な設定方法については、how to add memory to Claude Code を参照してください。それ以降は、プロジェクトがすでにロードされた状態で新しいセッションが開始され、次のツール変更は移行作業ではなく、単なる設定の編集になります。
移行にかかる実際のコストと、それによって得られる節約効果
手動での移行にかかるコストを現実的に見積もってみましょう。指示ファイルの移植：1時間未満。暗黙の知識を CLAUDE.md に再構築する作業：徹底的に行うと半日。そして、継続的に発生するコスト：仮にプロジェクトのコンテキストが 2,000 トークンあり、セッションやエージェントをまたいで1日に20回再提示されるとします。これは、同じことを繰り返すために毎月約 1.2M トークンを消費し、セッションを開くたびに4〜5分の再説明を行っていることになります。
共有メモリレイヤーへの1回限りの書き込みは、この継続的なコストを不要にします。また、次のツール評価の際にも大きな違いが生まれます。現在、Codex や新しいエージェントを試すには、コンテキストの再構築コストを再び支払う必要があります。これこそが、チームがすでに限界を感じているツールを使い続けざるを得ない理由です。メモリが外部化されていれば、ツールの評価にかかる時間は1か月ではなく、半日で済みます。
移行のためのベストプラクティス
チャットログではなく、決定事項を移行する
チャットログをそのまま新しいセットアップに流し込まないでください。結論（選択肢、理由、日付）を抽出し、それらを保存します。結論は検索しやすく、一方でチャットログは重要な情報を埋もれさせ、読み取りに余計なトークンを消費します。
2週間は両方のツールを併用する
Claude Code にエージェントとしての作業を任せつつ、Copilot の自動補完機能は残しておきます。併用期間を設けることで、移植し忘れたコンテキストが浮き彫りになります。なぜなら、同じことを2回説明している自分に気づくからです。
メモリの書き込みは一度だけ、読み取りはどこからでも
規約、制約、事後分析の知見など、今後も必要になる事柄をエージェントに説明するたびに、セッションではなく共有レイヤーに保存するようにしてください。この習慣こそが、3回目の移行を極めて容易にする鍵です。これは、migrating from Cursor to Claude Code や、ゼロからやり直すことなく moving off Codex を行う際と同じ原則です。
結論
GitHub Copilot から Claude Code への移行は、1つの名前の下に行われる2つの異なる移行作業です。1つ目は機械的な作業です。指示ファイルを CLAUDE.md に移行するだけで、1時間もあれば終わります。2つ目は、痛みを伴う作業です。チャットで説明してきた数ヶ月分のコンテキストの移行であり、これらは保存されていなかったため、エクスポートする手段がありません。
これを手動で再構築することは可能であり、一度は行うべきです。しかし、それを Claude Code の内部で再構築してしまうと、将来的にまた別のツールへ移行する際に同じ問題が発生します。プロジェクトのメモリは、エージェントが読み取れる外部レイヤーに保持しましょう。そうすれば、「コンテキストをどうやって Claude Code に移行するか」という問いは消え、「今日はどのエージェントにこれを読み込ませるか」という問いに変わるはずです。