GitHub Copilot Memoryを使っているチームは、今回の更新で「保存された記憶をどう消すか」「リポジトリ単位で止められるか」「Copilot CLIで状態を確認・切り替えられるか」を確認すべきです。結論から言うと、GitHub Copilot Memoryは削除導線が分かりやすくなり、リポジトリ単位のオフスイッチが追加され、Copilot CLIからも/memoryコマンドで有効・無効・状態確認ができるようになりました。
特に管理者が注意したいのは、リポジトリ単位でCopilot Memoryをオフにしても、既存のメモリが自動削除されるわけではない点です。機能を止めるだけでなく、保存済みのリポジトリレベルの事実やユーザー設定を確認し、不要なものを削除する運用までセットで見直しましょう。
GitHub Copilot Memoryの今回の更新で何が変わったのか
GitHubの公式Changelogでは、Copilot Memoryに対して「削除の改善」「リポジトリ単位のオフスイッチ」「Copilot CLIでの制御」「保存時のスコープ表示の明確化」が追加されたと説明されています。Copilot Memoryはパブリックプレビュー中の機能で、有料のCopilotプランで利用できます。(The GitHub Blog)
今回の変更点を整理すると、次の通りです。
| 変更点 | 内容 | 確認すべき人 |
|---|---|---|
| 削除ガイダンスの改善 | Copilotに「忘れて」と依頼した際、削除すべき場所へ誘導し、投票可能な場所では該当メモリを低評価にする | 開発者、リポジトリ管理者 |
| リポジトリ単位のオフスイッチ | リポジトリ設定からCopilot Memoryを無効化できる | リポジトリ管理者、組織管理者 |
Copilot CLIの/memoryコマンド | CLIでMemoryの有効化、無効化、状態確認が可能 | Copilot CLI利用者 |
| 保存時のスコープ表示 | 保存される内容が「ユーザー単位」か「リポジトリ単位」かを明示 | 全利用者、セキュリティ担当者 |
実務上のポイントは、Copilot Memoryが単に「便利になった」のではなく、保存範囲と削除責任を管理しやすくなったことです。チームでCopilotを使っている場合は、開発効率だけでなく、ガバナンスや情報管理の観点でも設定を確認する必要があります。
Copilot Memoryとは何か
Copilot Memoryは、GitHub Copilotがリポジトリに関する事実や個人のコーディング上の好みを記憶し、次回以降のCopilot利用時に活用する機能です。GitHub Docsでは、Copilot MemoryはCopilot cloud agent、Copilot code review、Copilot CLIで使われると説明されています。(GitHub Docs)
たとえば、次のような情報が記憶対象になり得ます。
| メモリの種類 | 例 | 使われ方 |
|---|---|---|
| リポジトリレベルの事実 | ビルドコマンド、設計方針、命名規則、特定ディレクトリの役割 | 同じリポジトリで作業するCopilot利用者に適用 |
| ユーザーレベルの好み | 「テストコードは詳細に書きたい」「説明は短めにしてほしい」など | そのユーザーのCopilot利用時に適用 |
従来のAI支援では、毎回「このプロジェクトではpnpmを使っている」「API層ではこの命名規則にしている」と説明する必要がありました。Copilot Memoryは、こうした繰り返し説明を減らすための機能です。
一方で、便利さと引き換えに「どの情報が保存されているのか」「誰に見えるのか」「誤った情報が残っていないか」を確認する必要があります。今回の更新は、この管理面を強化するものです。
変更点：削除ガイダンスが改善された
今回の更新で、Copilotに何かを忘れるよう依頼した場合、Copilotは対象のメモリを削除する適切な場所へ案内するようになりました。GitHub公式Changelogでは、投票が利用できる場所では該当メモリをdown-voteすることも説明されています。(The GitHub Blog)
これは、開発者にとって地味ですが重要な改善です。これまでは「Copilotに忘れてと言えば消えるのか」「設定画面から消す必要があるのか」が分かりにくい場面がありました。今回の変更により、誤った記憶や不要な記憶に気づいた時点で、削除アクションへ進みやすくなります。
削除した方がよいメモリの例
次のような情報は、見つけた時点で削除や見直しを検討しましょう。
| 削除・見直し対象 | 理由 |
|---|---|
| 古いビルドコマンド | Copilotが誤った手順を提案し続ける原因になる |
| 廃止済みのアーキテクチャ方針 | レビューや実装修正の精度を下げる |
| 一時的な回避策 | 恒久ルールのように扱われると技術的負債が残る |
| 機密に近い運用情報 | 保存範囲や共有範囲を確認すべき |
| 個人の好みとして不適切な内容 | チーム標準と混ざると混乱しやすい |
特に注意したいのは、リポジトリレベルの事実は他のユーザーにも影響し得る点です。自分の作業だけでなく、チーム全体のCopilot体験に影響するため、放置しない方が安全です。
変更点：リポジトリ単位でCopilot Memoryをオフにできる
今回の更新で、リポジトリ管理者はリポジトリ設定のCopilot機能制御からCopilot Memoryを無効化できるようになりました。公式Changelogでは、無効化後はリポジトリレベルの事実が保存・読み取りされなくなる一方、既存の事実は削除されず、ユーザーレベルの好みには影響しないとされています。(The GitHub Blog)
ここが最も重要です。オフにすることと、保存済みデータを消すことは別の操作です。
リポジトリ単位オフスイッチの影響
| 項目 | オフにした場合の影響 |
|---|---|
| 新しいリポジトリレベルの事実 | 保存されなくなる |
| 既存のリポジトリレベルの事実 | 自動削除されない |
| リポジトリレベルの事実の読み取り | 行われなくなる |
| ユーザーレベルの好み | 影響を受けない |
| 他リポジトリのMemory設定 | 影響を受けない |
たとえば、規制対応が必要なリポジトリ、顧客別の専用リポジトリ、実験的なコードベースでは、リポジトリ単位でCopilot Memoryを停止する判断があり得ます。ただし、停止するだけでは保存済みのリポジトリレベルの事実は残るため、リポジトリのSettings > Copilot > Memoryで内容を確認し、必要に応じて削除する運用が必要です。
変更点：Copilot CLIでMemoryを操作できる
Copilot CLIでは、/memoryコマンドによる制御が追加されました。公式Changelogでは、/memory onで有効化、/memory offで無効化、/memory showで現在の状態確認ができ、選択はセッションをまたいで保持されると説明されています。(The GitHub Blog)
CLI中心で開発しているチームにとっては、設定画面を開かずに状態を確認できる点が便利です。
| コマンド | 役割 |
|---|---|
/memory on | Copilot Memoryを有効化 |
/memory off | Copilot Memoryを無効化 |
/memory show | 現在のMemory状態を確認 |
実務では、まず/memory showで状態を確認してから利用するのがおすすめです。特に、複数の組織・リポジトリをまたいで作業する開発者は、「どの作業でMemoryが有効になっているか」を意識しておくと、意図しない記憶の保存を避けやすくなります。
変更点：保存時にスコープが分かりやすくなった
今回の更新では、store_memoryの権限確認プロンプトにおいて、保存される情報がユーザーレベルの好みなのか、リポジトリレベルの事実なのかが明示されるようになりました。公式Changelogでは、ユーザーレベルは自分だけに見え、リポジトリをまたいだ自分のセッションで使われる一方、リポジトリレベルはそのリポジトリの全コントリビューターに見えると説明されています。(The GitHub Blog)
この変更は、情報管理上かなり重要です。なぜなら、同じ「記憶」でも、影響範囲が大きく違うからです。
| スコープ | 保存される内容の例 | 影響範囲 |
|---|---|---|
| ユーザーレベル | 説明の好み、コード生成時の個人的な希望 | 自分のCopilot利用に適用 |
| リポジトリレベル | ビルド手順、設計ルール、プロジェクト固有の制約 | そのリポジトリでCopilot Memoryにアクセスできる利用者に影響 |
保存時に「これはチーム全体に影響してよい情報か」を判断できるようになったため、開発者はプロンプトを流し見せず、スコープを確認してから許可するべきです。
影響範囲：開発者、管理者、セキュリティ担当で見るべき点
今回のCopilot Memory更新は、利用者全員に同じ影響があるわけではありません。立場ごとに確認すべきポイントが変わります。
| 立場 | 確認すべきこと | 具体的なアクション |
|---|---|---|
| 開発者 | 自分のMemoryが有効か、何が保存されるか | Copilot設定や/memory showで状態確認 |
| リポジトリ管理者 | リポジトリ単位で有効にすべきか | Settings > Copilot > Memoryを確認 |
| Organization管理者 | 組織ポリシーとして許可するか | Copilot Policiesで有効・無効を確認 |
| Enterprise管理者 | 企業全体のAI利用ポリシーに合うか | AI controls配下のCopilot設定を確認 |
| セキュリティ・法務担当 | 保存対象や削除手順が運用に合うか | 監査ログ、削除手順、利用ルールを整備 |
GitHub Docsでは、エンタープライズまたは組織管理のCopilotサブスクリプションではCopilot Memoryはデフォルトでオフであり、エンタープライズまたは組織設定で有効化する必要があると説明されています。(GitHub Docs)
そのため、管理対象のCopilotを使っている企業では、いきなり全員が使えるようになるというより、管理者が方針を決めたうえで展開する形になります。
管理者が確認すべき設定
管理者が最初に確認すべきなのは、Copilot Memoryを「どの単位で許可するか」です。
Enterprise管理者の確認ポイント
Enterprise管理者は、企業全体でCopilot Memoryを有効にするか、組織ごとの判断に委ねるか、無効にするかを検討します。GitHub Docsでは、Enterprise ownersがエンタープライズ全体の有効化ポリシーを定義するか、Organization ownersへ判断を委任できると説明されています。(GitHub Docs)
判断基準は次の通りです。
| 方針 | 向いているケース |
|---|---|
| 全体で有効 | 開発標準が整備され、Copilot活用を積極推進している |
| 組織ごとに判断 | 部門ごとにリポジトリの性質や規制要件が違う |
| 全体で無効 | 情報管理ポリシーが未整備、またはプレビュー機能を許可しない方針 |
パブリックプレビュー中の機能であるため、最初から全社展開するより、リスクの低いリポジトリや内製ツールから段階的に試す方が現実的です。
Organization管理者の確認ポイント
Organization管理者は、組織配下のメンバーに対してCopilot Memoryを使わせるかを決めます。GitHub Docsでは、Organization ownersがCopilotライセンスを持つ全メンバーに対してCopilot Memoryを有効または無効にできると説明されています。(GitHub Docs)
確認すべき項目は次の通りです。
- Copilot Memoryを利用してよいリポジトリの基準
- リポジトリ管理者に削除権限や確認作業を任せるか
- ユーザーレベルの好みを管理者が削除・エクスポートする運用の有無
- 監査ログを確認する担当者
- 開発者向けの利用ルール
組織として使うなら、「便利だからオン」ではなく、何を記憶させてよいか、何を記憶させてはいけないかを先に決めることが重要です。
リポジトリ管理者の確認ポイント
リポジトリ管理者は、保存済みのリポジトリレベルの事実を確認し、不適切・誤り・古い情報があれば削除します。GitHub Docsでは、リポジトリ管理者がSettingsからCopilot > Memoryへ進み、保存されたリポジトリレベルの事実を確認・削除できると説明されています。(GitHub Docs)
特に確認すべきリポジトリは次の通りです。
| 優先度 | リポジトリの例 | 理由 |
|---|---|---|
| 高 | 本番サービス、顧客別プロジェクト、認証・決済関連 | 誤った記憶や情報管理リスクの影響が大きい |
| 中 | 社内ツール、共通ライブラリ、テンプレート | 多くの開発者に影響しやすい |
| 低 | 個人検証、短期実験、サンプル | 影響範囲は小さいが、不要ならオフでよい |
開発者が確認すべき設定と使い方
開発者は、まず自分のCopilot Memoryが有効かどうかを確認しましょう。個人の有料CopilotプランではCopilot Memoryがデフォルトで有効になり得ますが、組織やエンタープライズ管理のプランでは管理者設定の影響を受けます。GitHub Docsでは、個人の有料Copilotプラン、または管理組織が利用を許可した場合にアカウントで有効になり、個人設定から無効化・再有効化できると説明されています。(GitHub Docs)
開発者向けチェックリスト
- Copilot設定でMemoryが有効になっているか確認する
- Copilot CLIを使う場合は
/memory showで状態を確認する store_memoryの確認プロンプトでスコープを見る- 個人的な好みとチームのルールを混同しない
- 誤ったメモリを見つけたら削除導線に従う
- 顧客情報、秘密情報、社内限定の運用情報を不用意に保存しない
特にCLI作業では、リポジトリをまたいで移動しながらCopilotを使うことがあります。作業前に/memory showで状態を確認する習慣を付けると、意図しない保存を防ぎやすくなります。
ユーザーレベルの好みとリポジトリレベルの事実を混同しない
Copilot Memoryの運用で失敗しやすいのは、個人の好みをチーム標準のように扱ってしまうことです。
たとえば、ある開発者が「テストは詳細なコメント付きで書いてほしい」とCopilotに伝えた場合、それはユーザーレベルの好みとして扱われるべきです。一方、「このリポジトリではAPIレスポンス型をtypes/apiに集約する」というルールは、リポジトリレベルの事実として扱われる可能性があります。
| 判断基準 | ユーザーレベルに向く | リポジトリレベルに向く |
|---|---|---|
| 誰に影響してよいか | 自分だけ | チーム全体 |
| 内容の性質 | 表現、説明量、作業スタイル | 設計、規約、ビルド手順 |
| 変更頻度 | 個人の好みで変わる | プロジェクト方針として管理される |
| 誤った場合の影響 | 自分の出力品質に影響 | チーム全体の提案やレビューに影響 |
Copilot Memoryを安全に使うには、保存を許可する前に「これは自分の好みか、リポジトリの事実か」を一呼吸置いて確認することが大切です。
削除・無効化・監査の実務フロー
管理者は、今回の更新をきっかけにCopilot Memoryの運用フローを作っておくと安心です。
推奨フロー
| 手順 | 作業 | 担当者 |
|---|---|---|
| 1 | Copilot Memoryの有効化方針を決める | Enterprise / Organization管理者 |
| 2 | 対象リポジトリを分類する | 開発責任者、リポジトリ管理者 |
| 3 | パイロット対象のリポジトリで有効化する | リポジトリ管理者 |
| 4 | 保存されたリポジトリレベルの事実を確認する | リポジトリ管理者 |
| 5 | 誤りや不要な情報を削除する | リポジトリ管理者 |
| 6 | 開発者に/memory showや保存時スコープ確認を周知する | 開発リード |
| 7 | 監査ログと削除履歴を定期的に確認する | 管理者、セキュリティ担当 |
GitHub Docsでは、管理者がメモリをエクスポートまたは削除した場合や、ユーザーがCopilot Memoryをオプトアウトした場合、組織またはエンタープライズの監査ログにイベントが表示されると説明されています。(GitHub Docs)
監査ログが残る点は、企業利用では重要です。利用を許可するなら、設定だけでなく「誰が、いつ、何を削除・エクスポートしたか」を追える体制も整えましょう。
移行や展開時に注意すべきポイント
Copilot Memoryはパブリックプレビュー中の機能です。GitHub Docsでも、現在パブリックプレビュー中であり変更される可能性があると明記されています。(GitHub Docs)
そのため、本番運用では次の点に注意してください。
既存メモリは自動削除されない
リポジトリ単位でCopilot Memoryをオフにしても、既存のリポジトリレベルの事実は削除されません。オフにしただけで安心せず、保存済みメモリの確認と削除を別途行いましょう。
複数組織に所属するユーザーは制限が強い設定に影響される
GitHub Docsでは、ユーザーが複数の組織からCopilotサブスクリプションを割り当てられている場合、最も制限の強い設定が適用されると説明されています。(GitHub Docs)
「自分の環境では動かない」「別の組織ではMemoryが使える」といった差が出る場合は、所属組織ごとの設定を確認しましょう。
ユーザーレベルの好みは組織・Enterprise管理者の対象にもなる
Copilot BusinessやCopilot Enterpriseでは、ユーザーレベルの好みを組織またはEnterprise管理者がエクスポート・削除できる場合があります。GitHub Docsでは、組織・Enterprise管理者がアクティブな請求主体として生成されたユーザーレベルの好みをエクスポートまたは削除できると説明されています。(GitHub Docs)
企業利用では、開発者に「個人の好みとして保存される情報も、管理者による管理対象になり得る」ことを明示しておくべきです。
エクスポート結果は常に完全なリアルタイムとは限らない
GitHub Docsでは、ユーザーレベルの好みのエクスポートについて、既存のエクスポートが2時間のウィンドウで再利用される場合があり、結果がやや古い可能性があること、またエクスポートは1時間に10回までに制限されることが説明されています。(GitHub Docs)
棚卸しや監査目的でエクスポートする場合は、実行タイミングと回数制限を考慮しましょう。
どのリポジトリで有効化すべきか
Copilot Memoryは、すべてのリポジトリで無条件に有効化すればよい機能ではありません。情報の性質と開発効率のバランスで判断しましょう。
| 有効化の判断 | 向いているリポジトリ | 理由 |
|---|---|---|
| 有効化を検討 | 開発標準が明確な内製サービス | 規約や構成を記憶させるメリットが大きい |
| 段階導入 | 共通ライブラリ、基盤リポジトリ | 影響範囲が広いため確認しながら進めたい |
| 慎重に判断 | 顧客別、機密性の高い、規制対象のリポジトリ | 保存内容と閲覧範囲の確認が必要 |
| 無効化を検討 | 短期検証、使い捨てプロジェクト | 記憶を蓄積するメリットが小さい |
おすすめは、まずリスクの低い内製リポジトリで試し、保存される内容を確認してから対象を広げる方法です。導入初期は、週1回程度リポジトリレベルの事実を確認し、誤ったメモリが残っていないかをチェックすると運用が安定します。
開発チーム向けの周知文例
社内に展開する場合は、次のような短い周知文を用意しておくとスムーズです。
GitHub Copilot Memoryは、リポジトリのルールや個人の好みをCopilotが記憶し、以後の提案に活用する機能です。保存時にはユーザー単位かリポジトリ単位かを確認してください。誤った内容や不要な内容を見つけた場合は、Copilot設定またはリポジトリの
Settings > Copilot > Memoryから削除してください。Copilot CLI利用者は/memory showで状態を確認できます。
この程度の周知でも、保存スコープの誤解や「どこで消せばよいか分からない」という混乱をかなり減らせます。
まず何をすべきか
今回のGitHub Copilot Memory更新で、管理者と開発者が最初にやるべきことは明確です。
管理者は、Copilot Memoryを組織・Enterprise・リポジトリのどの単位で許可するかを決め、保存済みメモリの確認・削除・監査ログ確認まで含めた運用を整えましょう。開発者は、自分のCopilot Memory状態を確認し、Copilot CLIでは/memory showを使い、保存時にはユーザーレベルかリポジトリレベルかを必ず確認することが重要です。
Copilot Memoryは、正しく使えばプロジェクト固有の説明を繰り返す手間を減らし、Copilotの提案精度を高められる機能です。一方で、誤った事実や不要な情報が残ると、チーム全体の開発体験に悪影響を与える可能性があります。今回追加された削除、スコープ、CLI制御を活用し、便利さと管理のバランスを取って展開しましょう。
コメント