なぜリポジトリの知識が失われ続けるのか
2つのシステムがあり、それらは互換性がありません
メモリツール（memory tool）はローカルであり、VS Codeに組み込まれています。ドキュメントでは「エージェントが作業しながらメモを保存し、思い出すことができる組み込みのエージェントツール。エージェントに明示的に何かを記憶するように指示することもできる」と説明されています。現在はプレビュー版で、chat.tools.memory.enabled設定で制御され、3つのスコープがあります：
- User（
/memories/） — セッション間およびワークスペース間で永続します。「好み、パターン、頻繁に使用するコマンド」向けです。 - Repository（
/memories/repo/） — セッション間で永続し、ワークスペーススコープです。「コードベースの規約、プロジェクト構造、ビルドコマンド」向けです。 - Session（
/memories/session/） — 「いいえ（チャット終了時にクリアされます）」。「タスク固有のコンテキスト、進行中の計画」向けです。
Copilot Memoryはもう1つのシステムです。「Copilotが作業しながらリポジトリ固有のインサイトを学習し、保持できるようにするGitHubホスト型のメモリシステム」であり、「Copilotクラウドエージェント、Copilotコードレビュー、Copilot CLIを含む、複数のGitHub Copilotサーフェス間で共有」されます。リポジトリスコープのみで、エージェントによって自動的に書き込まれ、デフォルトではオフになっています。
この2つを混同することが、メモリが機能していないと誤解される最も一般的な原因です。ローカルツールはデフォルトでオンですが、ホスト型はオンになっていません。
サーフェスをまたぐシステムは、2段階のオプトインが必要
Copilot Memoryは「デフォルトでオフになっており、GitHubの設定で有効にする必要があります」。Copilot ProまたはPro+ユーザーの場合は個人のCopilot設定で、チームの場合は組織またはエンタープライズのポリシー設定で有効にします。
さらに、リポジトリのメモリをこれにバックアップさせたい場合、VS Code側にもう1つのゲートがあります。それはデフォルトで無効になっている実験的な設定と、「GitHubの設定でリポジトリに対してCopilot Memoryが有効になっていること」という要件です。そして、失敗しても警告は出ません。「どちらかの条件が満たされない場合、リポジトリメモリはローカルファイルストレージにフォールバックします。」エラーは発生しません。リポジトリメモリは単にローカルのノートPCに留まり、オンにしたつもりのクロスサーフェス動作は決して実行されません。
リポジトリメモリは28日後に期限切れになる
これが、設計の前提とすべき事実です。Copilot Memoryは28日後にメモリを削除します。その理由は「古い情報を避けるため」という納得のいくものです。これと組み合わされているのが、称賛に値する実に珍しい保護策です。メモリは「使用前に検証」されます。つまり、「エージェントはメモリを適用する前に現在のコードベースと照合して検証し、古い情報や誤った情報が結果に影響を与えるのを防ぎます」。実行前に現実と照らし合わせて自己検証するメモリシステムは、ほとんどありません。
しかし、この2つを合わせて考えてみてください。コードに対して検証を行い、かつ4週間のサイクルで期限切れになるシステムは、最近の運用上のインサイト（ビルドの癖、不安定なテスト、先週のレビューで見つかったパターンなど）に最適化されています。3月に下されたアーキテクチャ上の決定を保持するようには作られていません。半年後に必要になるものは別の場所に置く必要があります。ドキュメントの比較表でも、Copilot Memoryの「自動（28日間）」の期限切れと、ローカルツールの「手動管理」を対比させることで、そのことを示しています。
指示（Instructions）とメモリ（Memory）は異なる疑問に答える
指示（Instructions）はあなたが要求するものであり、メモリ（Memory）はエージェントが学習したものです。Copilotは前者を多くサポートしています。単一の.github/copilot-instructions.md、1つ以上のAGENTS.mdファイル、GitHub組織レベルで定義された組織レベルの指示、そして特に「Claude Codeや他のClaudeベースのツールとの互換性のための」CLAUDE.mdファイル（ワークスペースのルート、.claudeフォルダ、またはユーザーのホームディレクトリから読み込まれます）などです。ファイルベースの*.instructions.mdファイルは、applyToヘッダーを介してglobスコープを追加し、ドキュメントに記載されている場所には.github/instructionsや.claude/rulesが含まれます。
このシステムの特性の中で、ここで最も重要なのは次の点です。「プロジェクト内に複数の指示ファイルがある場合、VS Codeはそれらを結合してチャットコンテキストに追加しますが、特定の順序は保証されません。」 優先順位によって解決されるのではなく、結合されるのです。2つのファイルの内容が矛盾している場合、どちらを優先するかは決定されません。これは、要件を少なく明確に保ち、指示ファイルをすべての知識を詰め込むキャビネットとして使わないようにすべき強い理由になります。
よくある試みと落とし穴
メモリツールをオンにして、それがCopilot Memoryだと思い込む。 ローカルツールはデフォルトで有効になっており、ローカルマシンに書き込みます。クロスサーフェスシステムは、GitHub上での個別のオプトインが必要です。
すべてを.github/copilot-instructions.mdに詰め込む。 内容が長くなるまでは機能しますが、長くなると、2つ目のAGENTS.mdや、継承されたCLAUDE.md、一致した任意の.instructions.mdファイルとコンテキストを奪い合うことになり、それらの順序も保証されません。
メモリがルールを強制することを期待する。 メモリはルールを強制しません。指示はあなたが要求するものであり、メモリは気づかれたことです。常に維持されるべきルールは、ビルドを失敗させるチェック（CIなど）に組み込むべきです。
問題が起きてから28日間の期限切れに気づく。 よくあるパターン：第1週に記録された決定事項が、第6週には消えており、第7週に再び議論をやり直すことになります。
Copilotにはメモリがまったくないと結論づける。 数ヶ月前なら理解できましたが、現在は誤りです。これにより、ドキュメント化された2つのシステムがすでに提供している機能を、手動で再構築してしまうことになります。
解決策：維持すべきものと期限切れになってもよいものを分ける
セットアップ自体は短時間で終わります。次の順序で行ってください。
メモリツールがオフになっている場合は有効にします。 デフォルトでオンになっていますが、chat.tools.memory.enabledを確認し、意図的に使用してください。プロジェクト横断的な好みにはユーザーメモリ、コードベースの事実にはリポジトリメモリ、現在取り組んでいる計画にはセッションメモリを使用します。覚えておく価値のある詳細として、ユーザーメモリについては「最初の200行が、すべてのセッションの開始時にエージェントのコンテキストに自動的にロードされる」という点があります。そのファイルの先頭部分は、ロードする価値のある内容にしておきましょう。
クロスサーフェス学習が必要な場合にのみ、Copilot Memoryを有効にします。 個人ユーザーの場合は個人のCopilot設定、組織の場合はポリシー設定を行い、リポジトリメモリをバックアップしたい場合はリポジトリレベルの有効化とVS Codeの実験的設定を行います。ローカルストレージへのフォールバックは警告なしに行われるため、思い込みではなく実際に検証してください。
リポジトリ所有者にレビューの習慣をつけさせます。 保存されたメモリは、Repository Settings > Copilot > Memoryで確認および削除できます。また、メモリは「書き込み権限を持つコントリビューターのみが作成できます」。月に一度このリストを確認してください。エージェントがあなたのコードベースをどのように認識しているかを知る最も早い方法です。
必須のガイダンスはメモリではなく、指示（instructions）に記述します。 常にオンにするファイルを1つ用意し、残りはスコープ指定された.instructions.mdファイルにします。どちらのファイルにも、無視されて困るような内容は含めないでください。ファイル間の順序は保証されないためです。
次に、4週間のタイマーが設定されている部分に対処します。MemoryLakeは、特定のツールに依存しない外部のメモリレイヤーであるため、28日を超えて残すべき知識を維持できます。セットアップは3つのステップです。
ステップ 1: APIキーの作成
サインインしてAPIキーを作成します。接続するすべてのツールで共通の認証情報として使用できます。
ステップ 2: 最初のメモリのアップロード
1つのエントリに1つの主張を短く記述します。Copilot Memoryが保持するように設計されていないものをここに書き込みます：
決定事項とその理由。 「2つのモバイルクライアントが古いビルドを固定しているため、APIはパスでバージョン管理されています。」リポジトリメモリは期限切れになりますが、その理由は期限切れになるべきではありません。
試行して却下されたアプローチ。 正しそうに見えて失敗したアプローチと、その失敗の経緯。Copilotのどちらのシステムにも、否定的な結果を記録するフィールドはありません。
所有権と境界。 どのサービスを誰が所有しているか、どのディレクトリが凍結されているか、どのチームに問い合わせるべきか。これらはコードではなく人に関する事実であるため、コードベースに対してどれだけ検証を行っても復元できません。
外部へのポインタ。 ダッシュボード、インシデントログ、設計書など、エージェントがリポジトリを読み込むだけでは見つけられないコンテキストです。
ステップ 3: AIとエージェントの接続
使用しているツールを接続します。MemoryLakeはMCPおよびAPI経由でアクセス可能であり、VS CodeはMCPサーバーをサポートしているため、Copilotの傍らで同じメモリを利用できます。Claude Code、Codex、Cursor、Clineも同じメモリを読み込むことができます。Copilotの指示ローダーはすでにCLAUDE.mdや.claude/rulesを読み込むため、複数のツールが混在するチームは例外ではなく一般的なケースであり、この点が重要になります。
3つの率直な制限事項があります。MemoryLakeは/memories/やCopilot Memoryの読み書きを行いません。 どちらのストレージにもAPIが存在しないため、上記のレビュー習慣は手動で行う必要があります。指示の順序は変更されません。 「特定の順序は保証されない」という動作はVS Codeの仕様です。そして、メモリはコンテキストであり、強制力はありません。 実行するたびに必ず真であるべきルールは、CIに組み込むべきです。
実践において何が変わるか
2つのシステムが1つの曖昧な機能ではなくなります。 どれがローカルで、どれがホスト型で、実際にどれを有効にしたのかを明確に把握できます。
期限切れに驚くことがなくなります。 4週間の運用上のインサイトはCopilot Memoryに、タイマーのない永続的な推論は別の場所に保存されます。
指示ファイルが短くなります。 知識の保存場所が決まれば、要件に背景情報を詰め込む必要がなくなります。
オンにしたときに、クロスサーフェス機能が実際に動作します。 ローカルストレージに静かにフォールバックする設定を盲信するのではなく、実際に検証したためです。
Copilotメモリのベストプラクティス
有効にしたシステムを確認する。 ローカルメモリツールはデフォルトでオン、Copilot Memoryはデフォルトでオフであり、GitHub側での有効化が必要です。
28日間の期限切れを設計上の制約として扱う。 次の四半期に必要となるものは、その範囲外に置いてください。
リポジトリのメモリリストを毎月確認する。 Repository Settings > Copilot > Memory。これはエージェントが認識している内容の鏡です。
ユーザーメモリの最初の200行を有益な内容に保つ。 これがすべてのセッションにロードされる部分です。
計画にはセッションスコープを使用する。 /memories/session/はチャット終了時にクリアされるため、進行中の作業に最適です。
優先順位に期待して指示ファイルを積み重ねない。 順序は保証されず、矛盾する内容が両方とも適用されてしまいます。
指示はインライン提案には届かないことを覚えておく。 ドキュメントには「エディタでの入力時のインライン提案には考慮されません」と記載されています。
Agent Hostでユーザーレベルの指示がどこから読み込まれるかを確認する。 ドキュメントには「VS Codeのプロファイルユーザーデータからではなく、~/.copilot/instructionsや~/.claude/rulesのようなハーネスに依存しないフォルダから読み込まれる」と記載されています。一般的な罠については、why agents ignore your instruction filesで説明されています。
結論
VS CodeにおけるCopilotのメモリ機能は、日常の会話では1つの名前で呼ばれていますが、実際には2つの機能です。ローカルメモリツールはプレビュー版で、デフォルトでオンになっており、ユーザー、リポジトリ、セッションのスコープに分かれています。ユーザーメモリの最初の200行はすべてのセッションにロードされます。Copilot Memoryはプレビュー版で、デフォルトでオフ、GitHubホスト型、リポジトリスコープであり、書き込み権限を持つエージェントによって自動的に書き込まれ、クラウドエージェント、コードレビュー、CLI間で共有されます。その保護策は本物であり、メモリは使用前に現在のコードベースに対して検証されます。これは、ほとんどのシステムが行う以上のことです。
そして、それらは28日後に削除されます。この1行だけで、このシステムが何のためのものかがわかります。組織的な知識ではなく、最近の検証可能な運用上のインサイトのためのものです。両方のシステムを意図的にセットアップし、クロスサーフェスの経路を思い込みではなく検証し、順序が保証されないことを理解した上で要件を指示ファイルに保持し、決定事項、却下されたアプローチ、所有権に関する事実は期限切れタイマーのないレイヤーに保存してください。
そうすることで、Copilotが毎月コードベースを再学習するのを防ぐことができます。また、各レイヤーが何を保持しているかを自分で確認することもできます。その方法については、how to audit what your AI assistants actually rememberを参照してください。