個人用と組織用ライセンス間でGitHub Copilot Memoryを管理する方法（2026年版ガイド）

Copilot Memoryは2種類の情報を保存します。リポジトリレベルの事実（Repository-level facts）は、"コーディング規約、アーキテクチャの決定、ビルドコマンド、プロジェクト固有のルール"をカバーします。ユーザーレベルの設定（User-level preferences）は、"ユーザーがCopilotとどのように対話したいかに関する、暗黙的または明示的な個人的設定"です。

この2つはスコープが異なります。

リポジトリの事実はリポジトリに帰属します。GitHubは、"これらの事実は同じリポジトリでの操作でのみ使用できる"とし、それらは"Copilot Memoryが有効で、リポジトリへの書き込み権限を持つユーザーのアクションに応じてのみ作成される"と説明しています。そのリポジトリでCopilot Memoryにアクセスできる人なら誰でも、その恩恵を受けることができます。また、使用前に検証されます。"リポジトリレベルの事実は、それを裏付けるコードを指す引用（citation）とともに保存され"、関連性があると思われる場合、Copilotは現在のブランチに対してそれらの引用をチェックします。"検証された事実のみが使用されます。"

ユーザー設定はあなたに追従しますが、所有者が紐付けられています。ここが重要な一節です。"設定は、ユーザーにライセンスを付与する組織またはEnterpriseである請求対象エンティティ（billing entity）によって所有されます。"設定が作成されると、"ユーザーの現在の使用におけるアクティブな請求対象エンティティに対して保存されます。"そして、Copilotがセッションのコンテキストを構築する際、"ユーザーの現在のactiveな請求対象エンティティを再度確認し、その請求対象エンティティが所有するメモリのみを取得します。"

つまり、雇用主から提供されたライセンスを使用している間にCopilotが学習した設定は、雇用主の組織またはEnterpriseが所有することになります。別のライセンスの下で作業する場合、Copilotは代わりにそのライセンスが所有する設定を取得します。

複数のアクセス元がある場合は、追加の要件があります。"複数のEnterpriseまたは組織を通じてCopilotへのアクセス権を受け取る場合、Copilot Memoryでユーザーレベルの設定を生成するには、デフォルトの請求対象エンティティを必ず選択しなければなりません。"そのデフォルト設定によって、あなたのために生成された設定を管理および削除できるアカウントが決定されます。

所有権は管理者にとっても実用的な影響を及ぼします。BusinessおよびEnterpriseプランでは、ユーザーレベルの設定は"組織またはEnterpriseの管理者によって表示および削除できます。"GitHubの管理者ガイドには、管理者が"組織をアクティブな請求対象エンティティとして生成されたすべてのユーザーレベルの設定をJSONL形式でエクスポートまたは削除できる"と付け加えられています。これらのアクションは記録されます。"管理者がメモリをエクスポートまたは削除したとき、およびユーザーがCopilot Memoryをオプトアウトしたとき、組織またはEnterpriseの監査ログにイベントが表示されます。"

保持できる情報を左右するルールがさらに2つあります。利用可能性はプランによって異なります。個人プランではCopilot Memoryはデフォルトでオンになっていますが、"Enterpriseおよび組織が管理するCopilotサブスクリプションの場合、Copilot Memoryはデフォルトでオフになっており、Enterpriseまたは組織の設定で有効にする必要があります。"また、メモリには有効期限があります。"使用されないままの保存された事実や設定は、28日後に自動的に削除されます。"Copilot Memoryはパブリックプレビュー中であるため、仕様は変更される可能性があります。

Copilot Memoryは1人につき1つのメモリであると思い込む。 実際には、請求対象エンティティごとに1つの設定セットが存在します。個人プランと会社ライセンスは、それぞれ独自のメモリを持っています。

デフォルトの請求対象エンティティをいつまでも選択しない。 複数の場所からアクセスできる場合、GitHubはユーザーレベルの設定を生成する前にデフォルトの選択を要求します。Memoryページに設定がまったく表示されない場合は、まずこれを確認してください。

コードレビューで個人設定が適用されると期待する。 GitHubは"Copilotのコードレビューはリポジトリレベルの事実のみを使用します。コードレビュー中にユーザーレベルの設定は適用されません"と述べています。CLIは異なり、"Copilot CLIは、リポジトリレベルの事実と、操作を開始したユーザーのユーザーレベルの設定を適用します。"

チームに必要なルールをメモリに頼る。 リポジトリの事実は便利ですが、Copilotによって推測されるものであり、使用されないと期限切れになります。チームのルールは、how Copilot resolves its instruction files（Copilotが指示ファイルを解決する方法）で説明されているように、指示ファイルに記述すべきです。

Copilot MemoryとVS Codeのローカルメモリツールを混同する。 これらは異なるストレージと寿命を持つ別個の機能です。詳細はsetting up Copilot memory in VS Code（VS CodeでのCopilotメモリの設定）で解説しています。

ステップ 1：現在、どの請求対象エンティティがあなたの設定を所有しているか確認する

GitHubでCopilotの設定を開き、「Memory」に移動します。GitHubは"ユーザーは個人設定で、保存されているすべての設定と対応する所有者を表示できます"と説明しています。それらを確認し、それぞれの所有者をメモしておきましょう。また、"ユーザーはCopilotプランに関係なく、独自のユーザーレベルの設定を表示および削除できます"とあるため、不要になった古い設定はこの機会に削除してください。

複数の場所からCopilotの提供を受けている場合は、Copilotの機能設定に移動し、デフォルトの請求対象エンティティを選択します。主に業務で使用するものを選択してください。GitHubは、複数のアクセス元がある場合にユーザーレベルの設定を生成する条件として、この選択を必須としています。

その際、Copilot Memoryが有効になっているかも確認してください。組織管理のプランでは、まず管理者がポリシーを有効にする必要があります。その後、ユーザーは自動的にオプトインされ、個別にオプトアウトできます。GitHubは、組織またはEnterpriseがオンにするまで、組織管理のサブスクリプションではこの機能はオフであると説明しているため、作業セッションでメモリが表示されない場合は管理者に確認してください。

最後に、あなたにとって重要な設定（コーディングスタイルの選択、レビューの習慣、ワークフローの詳細など、どのライセンスのCopilotであっても知っておいてほしいこと）をリストアップします。

ステップ 2：チームの知識はリポジトリに置き、個人の設定は自分の言葉で保持する

2種類のコンテキストを分離し、それぞれの所有者に適した場所に保管します。

チームの知識はリポジトリに帰属します。規約、アーキテクチャの決定、ビルドコマンド、プロジェクトのルールは、.github/copilot-instructions.md、パス固有の指示ファイル、またはAGENTS.mdに記述すべきです。Copilot Memoryのリポジトリの事実はこれらを補完できますが、書かれた指示は28日間使われなくても期限切れになることはなく、Copilotが正しく推測してくれるかどうかに依存することもありません。Copilotが保存したリポジトリの事実が有用であれば、それをプロンプトとしてルールを書き起こしましょう。Copilotがコードベースの全体像を見失いがちな場合は、why GitHub Copilot forgets codebase context（GitHub Copilotがコードベースのコンテキストを忘れる理由）でより広範な解決策を解説しています。

個人の設定は、あなた自身が再定義するものです。コードの構造化方法、命名規則、テストの好み、説明の求め方など、自分の言葉で短いリストを作成してください。これはあなた自身の自己紹介であり、雇用主の請求対象エンティティの下に保存されているデータのコピーではありません。どのようなライセンスであっても、これらの設定をCopilotに伝えることで、Copilotはそれを再学習します。

この2つの境界線には注意してください。雇用主のライセンス下で生成された設定は雇用主が所有し、管理者はそれらをエクスポートまたは削除できます。これらは会社のデータとして扱ってください。そこから何かを取得したい場合は、自分でコピーしようとせず、管理者に依頼してください。

ステップ 3：ライセンスの変更に事前に備える

転職、チームのEnterpriseアカウントへの移行、個人プランの追加や解約など、ライセンスの変更は予測可能です。事前に計画を立てましょう。

組織を離れる前に、自分が貢献したチームのコンテキストがメモリ内だけでなく、リポジトリの指示ファイルに記述されていることを確認してください。リポジトリの事実はリポジトリに残りますが、期限切れになる可能性があります。書かれた指示があれば、次に参画する人もその知識を利用できます。この引き継ぎのより広範なアプローチについては、keeping AI context when someone leaves（メンバー離脱時にAIコンテキストを保持する方法）で解説しています。

新しいライセンスで利用を開始するときは、早い段階でCopilotに個人のリストを提示してください。推測されるのを待つのではなく、最初のセッションで好みを伝え、1週間後にMemory設定ページを確認して、何が保存され、誰が所有しているかを確認します。

個人プランと会社ライセンスを併用している場合は、どちらの作業にどちらを使用するかを意識してください。GitHubは、設定が作成された時点でアクティブだった請求対象エンティティに対して各設定を保存するため、Copilotに重要なことを学習させるときは、どのライセンスを使用しているかに注意してください。

この解決策では、チームのルールをリポジトリに保持し、個人の設定を自分の言葉で管理します。しかし、その中間には、ライセンスの寿命を超えて存在するコンテキストがあります。複数のプロジェクトにまたがる決定事項、規約の背景にある理由、触れるすべてのコードベースに適用される教訓などです。MemoryLakeは、誰がCopilotの費用を支払っているかに関係なく、そのレイヤーを保持できる場所です。

エントリーはあなた自身の言葉で記述します。Copilot Memory、リポジトリ、またはベンダーのストアから読み取られたり、そこに書き込まれたり、削除されたりすることはありません。雇用主のコードや決定事項に関する内容を追加する前に、組織のポリシーを確認してください。

ステップ 1：APIキーを作成する

サインインし、ダッシュボードからキーを生成します。このキーは、GitHubの組織やライセンスとは無関係に、あなたのMemoryLakeワークスペースに帰属します。

ステップ 2：最初のメモリをアップロードする

ステップ2の個人リストと、どのセッションでも必要となるプロジェクト横断的な理由から始めます。1つのエントリーにつき1つの設定または決定事項を、日付とともに登録します。

ステップ 3：AIとエージェントを接続する

Copilotや、使用している他のコーディングエージェントを接続します。これにより、どのライセンスやツールで作業していても、あなたの設定が利用可能になります。

第一の違いは、消えた設定が謎ではなくなることです。どの請求対象エンティティがどのメモリを所有しているか、そしてなぜあるライセンスでのセッションに別のライセンスで学習した内容が表示されないのかを理解できます。

第二に、チームの知識がメンバーの入れ替わりを乗り越えて存続することです。ルールはすべてのCopilotインターフェースが読み取る指示ファイルに存在するため、28日間の有効期限も、最初にそれを説明した人も超えて存続します。これらのファイルがターミナルでどのように読み込まれるかについては、wiring Copilot CLI instructions（Copilot CLI指示の連携）を参照してください。

第三に、新しい仕事が「ゼロからのスタート」を意味しなくなることです。自分で書き留めた設定があれば、1〜2回のセッションで新しいCopilotを軌道に乗せることができます。

第四に、会社のコンテキストと個人のコンテキストの境界線が明確になることです。会社が所有する設定は会社の管理下に残り、持ち運び可能な知識はあなた自身が書いたものになります。

デフォルトの請求対象エンティティを設定する。 複数の場所からアクセスできる場合に必須となります。

Memory設定で所有者を確認する。 各設定に誰が所有しているかが表示されます。

チームのルールは指示ファイルに記述する。 メモリは推測されるものであり、使用されないと期限切れになります。

個人の設定は自分の言葉で再定義する。 リストは短く、最新の状態に保ちましょう。

雇用主が所有するメモリは会社のデータとして扱う。 コピーするのではなく、管理者に問い合わせてください。

各メモリがどこに適用されるかを覚えておく。 コードレビューはリポジトリの事実のみを使用し、CLIは両方を使用します。

他のコンテキストソースも活用する。 building a Copilot Space that stays current（最新の状態を維持するCopilot Spaceの構築）で示されているように、整理されたスペースはメモリが保持しないプロジェクト知識を伝達できます。また、ツールの移行を検討しているチームは、migrating from Copilot to Codex（CopilotからCodexへの移行）でアプローチを比較できます。

GitHub Copilot Memoryは、リポジトリに残るリポジトリの事実と、ライセンスを付与した組織またはEnterpriseが所有する個人の設定を保存します。Copilotは現在の請求対象エンティティが所有する設定のみを取得し、管理者は組織が所有する設定をエクスポートまたは削除でき、使用されていないメモリは28日後に期限切れになります。

この設計は組織にとっては合理的ですが、あなたのCopilotメモリが1つの連続したものではないことを意味します。デフォルトの請求対象エンティティを選択し、誰が何を所有しているかを確認し、チームのルールを指示ファイルに記述し、個人の設定を自分の言葉で保持しましょう。

これを行うことで、ライセンスの変更はゼロからのスタートではなく、簡単な再紹介のプロセスになります。