Copilot Spaceが時代遅れになってしまう理由
まず、スペースに何を含めることができるかを確認しましょう。GitHubは「リポジトリ、コード、プルリクエスト、Issue、文字起こしやメモなどのフリーテキストコンテンツ、画像、ファイルのアップロード」を挙げています。追加するコンテキストは、主に「このスペース内でCopilotが焦点を当てるべき内容を説明するフリーテキスト」である「指示（instructions）」と、「ソース（sources）」の2種類です。
最新性の約束は、特定の種類のソースに限定されています。ドキュメントの表現は正確です。「スペースに追加されたGitHubファイルやその他のGitHubベースのソースは、変更されると自動的に更新され、Copilotをプロジェクトの常に最新のエキスパートにします。」アップロードされたファイルや貼り付けたテキストは、GitHubベースのソースではありません。ドキュメントでは、これらを「ローカルマシンから直接ファイルをアップロードできる」「フリーテキストコンテンツを入力または貼り付けることができる」と説明しており、自動更新については言及していません。これらは「スナップショット」として扱う必要があります。
コードは単一のブランチに従います。作成ガイドには、「スペースは常にリポジトリのmainブランチにある最新バージョンのコードを参照します」と記載されています。チームの現在の作業が長期にわたる開発ブランチ上にある場合、スペースはmainブランチから回答を生成します。
リポジトリとファイルでは扱いが異なります。「リポジトリをアタッチする場合、Copilotはプロジェクト全体をメモリにロードしません。代わりに、リポジトリを検索し、質問に最も関連性の高いコンテンツのみを取得します。」対照的に、「ファイルをアタッチすると、その全内容がCopilotのコンテキストウィンドウにロードされ、そのスペースでのすべてのクエリで考慮されます。」Copilotに毎回必ず参照させたいドキュメントは、検索に頼るのではなく、ファイルとしてアタッチする必要があります。
IDEから見える情報は少なくなります。これは多くの人が最も驚くルールです。GitHubの注記には、「IDEでSpacesを使用する場合、リポジトリコンテキストとアップロードされたファイルはサポートされません」とあります。それ以外のもの（追加したテキストコンテンツ、GitHubファイル、Issue、プルリクエスト、スペースの指示）は引き続き利用可能です。アタッチされたリポジトリ全体といくつかのアップロードされたPDFを中心に構築されたスペースは、github.com上では充実して見えても、エディタ内では貧弱なものになってしまいます。
IDEからアクセスするにはセットアップが必要です。スペースはGitHub MCPサーバー経由で提供されますが、「Spacesツールセットはデフォルト設定に含まれていないため、X-MCP-Toolsetsヘッダーを使用して明示的に有効にする必要があります。」接続されると、「スペースはGitHub MCPサーバー経由でアクセスされるため、IDEのエージェントモードでのみ使用できます。」
また、説明（description）はCopilotではなく人間のためのものです。GitHubは、説明は「Copilotの回答には影響しませんが、他のユーザーがスペースの目的を理解するのに役立ちます」としています。
これらは不具合ではありません。それぞれのルールは合理的な設計上の選択です。しかし、これらが組み合わさることで、スペースの最新性と完全性は、選択したソースに完全に依存することになります。
よくある代替アプローチとその限界
ドキュメントのエクスポートをアップロードする。 手軽で、初日はうまく機能します。しかし、アップロードした瞬間にドキュメントは固定され、さらにアップロードされたファイルはIDEのCopilotには届きません。
リポジトリ全体をアタッチし、Copilotがすべてを把握していると期待する。 リポジトリのアタッチは「検索」を意味し、全体をロードするわけではありません。重要なドキュメントが特定の質問に対して取得されるかどうかは不確実であり、リポジトリコンテキストはIDEでの利用に対応していません。
長いメモを一度だけ貼り付ける。 テキストコンテンツはIDEに届くため、その点は優れています。しかし、数ヶ月前に貼り付けられたメモは、誰かが編集するまで「最新」として扱われ続けます。
説明（description）にコンテキストを書き込む。 GitHubが述べているように、説明はCopilotの回答に影響を与えません。
質問ごとに個別のスペースを作成する。 スペースは、システム、ワークフロー、または機能ごとの永続的なコレクションとして最もよく機能します。重複し、メンテナンスされていないコンテンツを含む小さなスペースが乱立すると、適切に管理された1つのスペースよりも早く形骸化します。
解決策：自動更新されるソースからスペースを構築し、チームの作業環境で検証する
目指すのは、重要なコンテンツが自動的に更新され、スナップショットに所有者（オーナー）が割り当てられ、github.comだけでなくIDEにもコンテキストが届くスペースです。
ステップ 1: GitHubファイルを優先し、ソースごとにファイルかリポジトリかを選択する
チームメンバーがシステムを理解するために必要なもの（アーキテクチャの概要、主要なモジュール、ランブック、規約、未解決のデザイン課題など）をリストアップします。次に、各アイテムをどのようにスペースに取り込むかを決定します。
リポジトリ内に存在するものであれば、コピーをアップロードするのではなく、GitHubファイルとして追加します。GitHubファイルは、ドキュメントで「変更されると自動的に更新される」と説明されているソースであり、IDEでも利用可能です。意思決定レコードやデザインメモなど、まだリポジトリにないが含めるべきものがある場合は、まずコミットすることを検討してください。これにより、バージョン管理され、レビュー可能になり、スペース内でも常に最新の状態に保たれます。
ファイルかリポジトリかは意図的に選択してください。Copilotがすべての質問で考慮すべき少数のドキュメントについては、個別のファイルをアタッチします。ファイルの「全内容がCopilotのコンテキストウィンドウにロードされる」ためです。github.com上の大規模なコードやドキュメント全体にわたる質問に答えることが目的の場合は、リポジトリ全体をアタッチします。ただし、これは検索に依存し、IDEには届かないことを理解しておく必要があります。
進行中の意思決定が含まれるIssueやプルリクエストをリンクします。GitHubでは、これらのURLをソースとして貼り付けることができ、IDEでも利用可能です。
ブランチを確認します。mainブランチが現在のシステムの動作を反映していない場合は、指示（instructions）にその旨を記載するか、main上で最新のドキュメントをスペースの参照先に指定します。
ステップ 2: リポジトリに保持できない内容には指示とテキストコンテンツを使用し、所有者を決める
移行が延期された理由、APIの選択の背景にある顧客の制約、レビュアーが適用するチェックリストなど、一部のコンテキストはリポジトリに適していません。これらこそが、指示（instructions）とテキストコンテンツの出番です。
指示は、Copilotへのブリーフィング（要約）として記述します。GitHubのガイドラインでは、「専門分野、どのようなタスクを支援すべきか、何を避けるべきか」を含めることが推奨されています。スペースの目的に合わせて、簡潔かつ具体的に記述してください。
永続的な背景情報は、IDEに届くテキストコンテンツに配置します。各ブロックに日付を入れ、誰がメンテナンスしているかを明記します。日付のあるメモは古くなっていることが一目でわかりますが、日付のないメモは永遠に最新であるかのように見えてしまいます。
次に、ロール（役割）を設定します。組織が所有するスペースでは、「編集者（Editors）はスペースのアタッチメント、説明、名前、指示を更新できる」のに対し、「閲覧者（Viewers）はスペースを使用して質問し、含まれるアタッチメントや指示を表示できる」となっています。スナップショットを所有するメンバーに編集権限を与え、ランブックの更新と同じチェックリストに「スペースの確認」を追加します。GitHub自身のオンボーディング例でも、まさに「他の人を編集者にして、誰でも含まれるリソースを更新できるようにする」ことが推奨されています。
ステップ 3: IDEで接続し、実際に何が届くかをテストする
Spacesツールセットを有効にしたリモートのGitHub MCPサーバーをセットアップし、エージェントモードでCopilot Chatを開きます。GitHubは、get_copilot_spaceおよびlist_copilot_spacesツールがリストされ、有効になっていることを確認することを推奨しています。
ここで、2つの質問でテストを行います。1つはGitHubファイルまたはテキストコンテンツに回答がある質問、もう1つはアップロードされたファイルまたはアタッチされたリポジトリのどこかにしか回答がない質問です。両方をgithub.comとIDEの両方で質問してみます。その違いにより、チームがコーディング中にスペースのどの部分を実際に参照できているかが正確にわかります。
IDEから見えないソースにある重要な情報は、別の場所に移します。重要な回答がアップロードされたPDFにしか存在しない場合は、そのコンテンツをリポジトリにコミットしてGitHubファイルとして追加するか、重要な部分をテキストコンテンツとして貼り付けます。
最後に、利用料金（クレジット）に注意してください。スペース内で行われた質問は「Copilot Chatのリクエストとしてカウントされ、使用されたモデルと処理されたトークン数に基づいてAIクレジットを消費」します。厳選されたファイルで構成されたスリムなスペースは、あらゆるものを詰め込んだスペースよりもクエリのコストを抑えられます。
Setting this up in MemoryLake
適切に構築されたスペースは、GitHub内の1つのシステムをカバーします。しかし、複数のリポジトリに影響を与える決定、チーム横断的な規約、単一のファイルには記録されない選択の背景にある理由、およびGitHub以外のツールでチームメンバーが必要とする共通の背景情報など、それを超えるコンテキストも存在します。MemoryLakeは、そのようなレイヤーを保持し、チームが使用するすべてのAIアシスタントに届けるための場所です。
エントリーは、あなた自身の言葉で直接記述します。Copilot Spaces、リポジトリ、またはベンダーのストレージからデータが読み取られたり、書き込まれたり、削除されたりすることはありません。
Step 1: Create an API key
サインインし、ダッシュボードからキーを生成します。このキーにより、チームメンバーがどのツールを開いていても、アシスタントが作成されたエントリーを読み取ることができるようになります。
Step 2: Upload your first memories
ステップ2で挙げた、1つのスペースに収まらないコンテキスト（リポジトリをまたぐ決定、チームの規約、およびその背景にある理由など）から始めます。1つの決定につき1つのエントリーを作成し、日付と所有者を明記します。
Step 3: Connect your AI & agents
Copilotや、チームが使用しているその他のアシスタントを接続します。これにより、スペースと並行して、またスペースを読み取ることのないツールでも、同じ背景情報を利用できるようになります。
実践によってもたらされる変化
第1の変化は、重要な部分において「常に最新（エバーグリーン）」が実現することです。主要なドキュメントがGitHubファイルであれば、コードやドキュメントの変更に合わせてスペースが自動的に更新されます。これは、GitHubがそれらのソースに対して約束している動作そのものです。
第2に、IDEとウェブで同じスペースが表示されるようになります。重要なコンテキストがGitHubファイル、Issue、プルリクエスト、テキストコンテンツ、指示に配置されれば、開発者はgithub.com上と同じ前提知識をエージェントモードでも得ることができます。
第3に、情報の「古さ」に責任者が生まれます。日付付きのテキストコンテンツと明確な編集者ロールにより、「スペースが古い」という漠然とした不満が、誰かが対処できる具体的なタスクへと変わります。これは、そもそもCopilotがコードベースのコンテキストを忘れてしまうのを防ぐための規律と同じです。
第4に、Spacesが他のCopilotコンテキストとうまく調和するようになります。リポジトリの指示ファイルはコード内でのCopilotの動作を決定し、スペースはシステムについてCopilotが知っていることを決定します。そして、VS CodeでのCopilotメモリのセットアップは独自のレイヤーを追加します。これらの役割を明確に分けることで、どのCopilot指示ファイルが優先されるかで説明されているような競合を避けることができます。
Best practices for Copilot Spaces
リポジトリのコンテンツはアップロードではなく、GitHubファイルとして追加する。 自動的に更新されるとドキュメントに記載されているのは、GitHubベースのソースのみです。
Copilotが常に考慮すべきドキュメントはファイルとしてアタッチする。 アタッチされたファイルは全体がロードされますが、アタッチされたリポジトリは検索対象となるだけです。
mainブランチの内容を確認する。 スペースはmainブランチの最新コードを使用します。
重要な背景情報は、日付と所有者を明記したテキストコンテンツに配置する。 これによりIDEにも情報が届き、日付によって情報の古さが可視化されます。
github.comだけでなく、IDEでもテストする。 リポジトリコンテキストとアップロードされたファイルは、IDEでの利用に対応していません。
説明（description）は人間のために残しておく。 Copilotへの指示は、代わりに指示（instructions）に記述してください。
コードに属する決定事項はコミットする。 散在するプロジェクトドキュメントをAIメモリに変換するための第一歩は、ツールが確実にアクセスできる場所にそれらを配置することです。この考え方は、CLAUDE.mdのコンテンツをCopilotに移行する際にも役立ちます。
結論
Copilot Spacesは、Copilotとチームにシステムの共通認識を提供する実用的な方法です。スペースが「プロジェクトの進化に合わせて同期を維持する」というGitHubの約束は、変更時に自動更新されるGitHubベース of ソースにおいて真実となります。
それ以外の部分には設計が必要です。アップロードされたファイルや貼り付けられたテキストはスナップショットに過ぎません。スペースはmainブランチに従います。アタッチされたリポジトリは完全にロードされるのではなく検索され、IDEでは「リポジトリコンテキストとアップロードされたファイルはサポートされません」。
可能な限りGitHubファイルから構築し、ファイルかリポジトリかを意図的に選択し、スナップショットには日付と所有者を設定し、IDEでスペースをテストしてください。複数のスペースにまたがるコンテキストについては、チームが使用するすべてのツールからアクセスできる場所に保持しましょう。そのレイヤーの選択肢を比較する場合は、エンジニアリングチーム向けのコードベースメモリツールが参考になります。また、Copilotのリクエストごとのワークフローでは、コンテキストが単一のリクエストの外部に存在しなければならない理由を説明しています。