先に結論
今回の更新で大きいのは、Copilot Memory が賢くなったことより、止め方と消し方がやっと実務向けになったことです。
追加されたのは3つです。
- 削除先を案内する導線
- repository 単位で止める off switch
- Copilot CLI の
/memory on/memory off/memory show
Copilot をすでに使っているチームほど、見るべきなのは新機能紹介ではありません。
どの repo で Memory を止めるか、既存 facts をどう消すか、CLI 利用者に何を徹底するか を決める段階に入った、という理解がいちばん近いです。
何が変わったのか
GitHub は 2026-05-26 の changelog で、Copilot Memory の control update を公開しました。
今回の変更点は次の4つです。
1. 「忘れて」と言った時の削除導線が増えた
Copilot に何かを忘れさせたい時、適切な削除場所へ案内しやすくなりました。
投票できる場所では、対象 memory を down-vote する動きも入ります。
これで、消したいのに設定場所が分からず放置する状況は減らしやすくなります。
2. repo 管理者が repository 単位で止められるようになった
repository settings の Copilot controls から、Copilot Memory をその repo だけ off にできます。
ここで止まるのは repository-level facts の保存と利用 です。
一方で、既存 facts は自動では消えません。user-level preferences も影響を受けません。
つまり、機密 repo や短命な検証 repo で off にする価値は高い一方、過去に残った facts の掃除は別作業です。
3. Copilot CLI から /memory を直接触れるようになった
CLI では /memory on、/memory off、/memory show が使えるようになりました。
GitHub の説明では、この選択はセッションをまたいで保持されます。
shared shell、録画デモ、検証用の一時環境では、使い始める前に /memory show、必要なら /memory off を確認する運用がかなり現実的です。
4. 保存時のスコープ表示が明確になった
store_memory の permission prompt では、それが user-level preference なのか repository-level fact なのかがより明確に表示されます。
ここが見えるようになると、個人の書き方を shared な repo facts に混ぜる事故を減らしやすくなります。
まず整理したいのは repo facts と user preferences の境界
Copilot Memory の更新は control 面が主題ですが、運用ではこの線引きが先です。
repo facts は、その repository の共有ルールです。
build command、アーキテクチャの前提、レビュー基準のような内容が入ります。
user preferences は、その人だけに効く個人設定です。
commit 文や説明のトーンのような癖はこちらです。
この違いを踏まえると、今回の off switch が止める対象も読みやすくなります。
repo で off にして止まるのは repo facts です。個人の preferences までは切れません。
逆に言えば、個人の書き方を組織統制の対象にしたいなら、Memory ではなく docs や custom instructions に寄せるほうが安全です。
境界の整理そのものは、GitHub Copilot Memory user preferences対応｜repo facts と個人設定の違い、28日保持、enterprise有効化で何を確認すべきか も合わせて見るとつながります。
code review と CLI では効き方が違う
GitHub Docs では、Copilot Memory の利用先は cloud agent、code review、Copilot CLI です。
ただし同じようには効きません。
いちばん重要なのは、code review は repository-level facts しか使わない ことです。
user-level preferences を丁寧に整えても、review の基準にはそのまま乗りません。
一方の Copilot CLI は、操作した本人の facts と preferences を使います。
だから今回の /memory 追加は、CLI 利用者の運用に直結します。
- repo 全体の統制は settings 側
- 個人の CLI 利用は
/memory側
この分担で見ると混乱しにくいです。
Copilot CLI の普段使いを詰めたいなら、GitHub Copilot CLI auto model selection vs fixed model 指定｜premium request と速度でどう選ぶか も隣の論点です。
管理者が今すぐ見直すべき点
今回の更新で、管理者のチェック項目はむしろ増えました。
止めるべき repo がないか
すべての repo で facts を蓄積したいとは限りません。
- 検証専用 repo
- 一時的な顧客作業 repo
- 共有範囲を絞りたい機密 repo
このあたりは repository-level off switch の候補です。
既存 facts の掃除手順があるか
repo で off にしても、保存済み facts は残ります。
設定を切るだけで片付いた気にならないことが大事です。
運用文書には、不要 fact をどこで確認し、誰が消すかまで書いたほうが事故が減ります。
複数 organization 所属ユーザーの扱いが整理されているか
GitHub Docs では、複数 organization からライセンスを受けるユーザーには 最も restrictive な設定 が適用されます。
一部の組織だけ有効にしても、別の組織が止めていれば使えません。
Business / Enterprise の管理全体を見直すなら、GitHub Copilot Business / Enterprise のモデル承認ガイド｜GPT-5.3-Codex LTSを軸にどう許可するか と同じ粒度で、Memory も組織ポリシーに落としたいところです。
CLI 利用者が決めておくと楽なこと
今回いちばん行動に移しやすいのは CLI 側です。
おすすめは次の3つです。
- shared shell や demo 環境では最初に
/memory showを打つ - 一時作業なら
/memory offを既定にする - 継続利用する個人環境だけ
/memory onを許可する
これだけでも、意図せず個人の癖や repo facts を混ぜる事故はかなり減らせます。
特に録画、登壇、ペア作業、顧客同席のセッションでは、Memory が前回の文脈を引きずる前提で手順を組んだほうが安全です。
28日保持と「off にしても消えない」を同時に理解する
GitHub Docs では、使われない fact や preference は 28日で自動削除 されます。
使われて検証に通った entry は、保持期間が延びることがあります。
この仕様だけ見ると、自然に消えるから放置してよさそうにも見えます。
ただし今回の update で重要なのは、repo で off にしても既存 facts は自動削除されない ことです。
つまり、保持ポリシーと停止ポリシーは別物です。
- もう使わない entry は 28 日で薄れていく
- それでも今すぐ消したいものは手動削除が必要
- repo off は今後の保存と利用を止めるだけ
ここを取り違えると、監査説明で詰まりやすいです。
個人 Pro / Pro+ と組織契約は同じ話ではない
GitHub Docs では、Copilot Memory 自体は public preview として案内されています。
ただし有効化条件は一段ではありません。
個人の Copilot Pro / Pro+ では、Memory は既定で有効です。user-level preferences もこの系統で利用できます。
一方で organization や enterprise が配る契約 では、Memory は既定で無効です。
管理者が設定で開けない限り使えません。
この違いを飛ばして「有料プランなら全部同じ」と説明すると誤解を生みます。
まとめ
今回の GitHub Copilot Memory update は、派手な新機能というより 導入後の統制を整える更新 です。
押さえるべきポイントは3つだけです。
- repo 単位で止められるようになった
- CLI から
/memoryを管理できるようになった - off にしても既存 facts は消えない
Copilot を本番運用に寄せたいなら、まず決めるべきなのは「Memory を使うかどうか」ではありません。
どの repo で止めるか、CLI でいつ切るか、削除を誰が担当するか を先に固めるほうが、あとで揉めません。