GitHub Copilotがコードベースのコンテキストを忘れる理由
現在のCopilotにおけるコンテキストの処理方法
現在のCopilotは、編集中のファイルと、開いている関連タブのウィンドウから提案を生成します。ローカルの自動補完としてはこれで十分であり、実際にその精度は非常に優れています。しかし、リポジトリ全体の永続的な全体像（モジュールの境界、共有ユーティリティ、「常にこの方法で行う」というコーディング規約など）を構築することはありません。関連するコンテキストが画面上にない場合、Copilotはそれを認識できないため、プロジェクトの実態ではなく、一般的なパターンから推測して提案してしまいます。
記憶が定着しない技術的な理由
やり取りの合間に、コードベースの構造や決定事項を保持する永続的なメモリレイヤーが存在しないためです。Copilot Chatやワークスペース機能は、必要に応じてリポジトリのより多くの部分を取り込むことで、コンテキストウィンドウをある程度広げますが、これはセッション内での一時的な「検索（リトリーバル）」であり、蓄積される「メモリ（記憶）」ではありません。昨日あるアプローチを却下したことや、先週ルールを策定したことなどはどこにも記録されないため、再びパターンから外れた同じ提案が繰り返されることになります。
これによる損失
開発者は、既存のコードと重複する提案や、Copilotが認識できない規約に違反する提案を検出するために、より厳しいコードレビューを強いられます。修正内容が保存されないため、同じ間違いを何度も修正することになります。そして、コンテキストの支援が最も必要とされる大規模なコードベースや不慣れなコードベースにおいて、Copilotは最も信頼性が低くなります。リポジトリが大きくなればなるほど、その狭い視野に収まる割合が少なくなってしまうからです。
Copilotの組み込みの回避策（とその限界）
適切なタブを開いておく
Copilotは開いているファイルを重視するため、関連するファイルを開いたままにしておくと提案の精度が上がります。しかし、これは手動のその場しのぎに過ぎません。セッションごとに手動でコンテキストを流し込む必要があり、ウィンドウが保持できる容量にも限界があります。
Copilot Chatとワークスペースコンテキスト
Copilot Chatにワークスペースについて質問すると、その質問のためにリポジトリのより多くの部分が取り込まれるため、単発の問い合わせには役立ちます。しかし、これはやり取りごとの一時的な検索であり、永続的なメモリではありません。学習された内容が次のセッションに引き継がれることはなく、規約が記憶されることもありません。
カスタム指示（Custom instructions）
リポジトリレベルのカスタム指示を使用すると、いくつかの固定ルールを設定できるため、少数の安定したルールには効果的です。しかし、これらは静的で手動メンテナンスが必要であり、実際のプロジェクトコンテキストを構成する、日々進化する決定事項やアーキテクチャを捉えることはできません。
共通の壁：これらの方法はいずれも、セッション間で維持される、クエリ可能な永続的コードベースモデルではありません。これは、Cursor forgetting architectural decisions（Cursorがアーキテクチャの決定事項を忘れる問題）で説明されているように、他のコーディングエージェントも直面している根本的な課題と同じです。
解決策：Copilotに永続的なコードベースメモリを提供する
永続的な解決策は、リポジトリの永続的なモデル（アーキテクチャ、規約、決定事項）を保持し、いつでも取り出せるメモリレイヤーを導入することです。MemoryLakeは、その知識を一度保存すれば、Gitスタイルのバージョン管理付きで検索可能にし、アーキテクチャの進化を追跡できるようにします。また、エンドツーエンドで暗号化されているため、コードのセキュリティも守られます。
ステップ 1: APIキーを作成する
MemoryLakeにサインインし、キーを生成して最初のリクエストを送信します。所要時間は約30秒です。
ステップ 2: 最初のメモリをアップロードする
アーキテクチャの概要、モジュールの役割、コーディング規約、そしてそれらの背景にある決定事項など、コードベースの永続的なモデルを投入します。ドキュメント、画像、その他のファイル形式に対応しています。新しい規約や却下されたアプローチが決まったら、その都度1行のメモリとして記録します。
ステップ 3: AIとエージェントを接続する
APIを介してこのメモリをワークフローに組み込むことで、提案を形成するコンテキストが開いているタブだけでなく、プロジェクト全体を反映するようになります。同じメモリは、MCPまたはAPIを介してClaude、Codex、OpenClaw、およびその他のMCP対応エージェントでも利用できます。これにより、Copilotが尊重すべきアーキテクチャを、すべてのツールが共通して尊重するようになります。
浅いコンテキストがもたらす実際のコスト
レビューと手戻りのコスト
既存のコードと重複していたり、規約を無視していたりする提案は、すべてレビューで検出され、手戻りが発生します。これは、修正内容を記憶できないツールを修正するために費やされる無駄な時間です。大規模なコードベースでは、パターンから外れた推測が最も頻繁に発生し、その検出コストも高くなるため、この問題はさらに深刻化します。
推測ではなく検索を活用する
永続的なコードベースモデルがあれば、開発ツールは現在のファイルから推測するのではなく、「このプロジェクトの構造はこうなっている」という情報に基づいて動作します。これにより、パターンから外れた提案が減り、手戻りが削減され、APIワークフローにおけるプロンプトもスリム化されます。MemoryLakeのToken Saving Calculatorを使用すると、実際の使用状況からその効果を予測できます。
コードベースメモリのベストプラクティス
コードではなく、マップと規約を保存する
開いているファイルからすでに読み取れる生のソースコードではなく、Copilotに不足しているプロジェクトの知識（アーキテクチャの概要、モジュールの役割、規約など）をメモリに保持します。価値があるのは、構造とルールです。
却下されたアプローチを記録する
特定のパターンを不採用にした場合は、それを1行のメモリとして記録しておきます。これにより、パターンから外れた同じ提案を何度も修正し続ける必要がなくなり、一度の修正で済むようになります。
リポジトリごとにスコープを分ける
リポジトリごとに1つのメモリ・スコープを設定することで、検索の精度が維持され、各プロジェクトのコンテキストをクリーンかつ適切に保つことができます。
結論
GitHub Copilotは、画面上の内容には極めて鋭いものの、周囲のコードベースを認識できず、前回の修正も記憶できないという、「1ファイル限定の世界観」に囚われた優れた自動補完ツールです。アーキテクチャ、規約、決定事項の永続的なモデルをCopilotに提供することで、その提案は一般的なパターンではなく、あなたのプロジェクトに適合したものになります。また、同じコンテキストを他のすべてのツールでも共有できるようになります。コードベースを忘れてしまうツールに合わせたレビュー作業はもうやめて、ツールに記憶させましょう。