2026年9月25日、GitHubは「Agentic autofix now uses Copilot Memory」を公開しました。対象は、Copilot Memoryを有効化している顧客のagentic autofixです。セキュリティアラートを直すとき、既存のmemoryを参照してリポジトリ固有の文脈を使い、修正後はその修正パターンを次回以降のmemoryとして保存します。
要点は、単なる自動修正の精度改善ではありません。セキュリティ修正の「なぜこの書き方にするのか」を、Copilot code reviewやCopilot cloud agentなど他のCopilot機能にも横展開できるようになる点です。導入担当者は、28日保持、repository-level facts、管理者による削除・エクスポートの3つを確認してから試すのが現実的です。
概要：agentic autofixがCopilot Memoryを使う
GitHubの発表では、agentic autofixはセキュリティアラートの解決に役立つ文脈がないか既存のmemoryを確認します。修正を作成した場合、その修正パターンをmemoryとして保存し、将来のセキュリティアラートやCopilot code review、Copilot cloud agentが参照できる形にします。
Copilot Memory自体はpublic previewで、GitHub Docsでは「repositoryに関する事実」と「個人のコーディング嗜好」を保存できる機能として説明されています。repository-level factsには、コーディング規約、アーキテクチャ判断、build command、プロジェクト固有ルールなどが含まれます。
仕様表：確認すべき3つのポイント
項目 | 公式情報 | 管理者の確認
対象機能 | agentic autofixとCopilot Memoryはいずれもpublic preview | 限定repoで試す
利用範囲 | cloud agent、code review、CLI、agentic autofixがMemoryを利用 | 波及範囲を共有
保持 | 未使用のfact/preferenceは28日後に自動削除 | 月1回棚卸し
権限 | repository-level factsは同じrepo内で使用 | 例外ルールの記録を確認
重要なのは、memoryが「便利なメモ」ではなく、将来の自動修正・レビュー・agent作業に影響する実行時コンテキストになる点です。設定を有効にする前に、どのリポジトリで、どの種類のセキュリティアラートから始めるかを決めておくと、効果とリスクを測りやすくなります。
自社リポジトリでCopilot Memoryやagentic autofixをどう試すべきか整理したい場合は、 HelloCraftAIにご相談ください。 既存のセキュリティ運用、CodeQL、Copilot設定を前提に30日PoCの設計を支援します。
設定前チェック：30日PoCで見る項目
最初のPoCは、すべてのrepositoryではなく、セキュリティアラートが継続的に発生し、かつテストが整っている1〜3リポジトリに絞るのがおすすめです。agentic autofixが生成する修正は、既存のCI、テスト、コードレビューを通して評価し、memoryが本当に修正品質を上げたかを見ます。
チェックリストは8項目です。1. Memoryの管理ポリシー確認。2. 対象repoを1〜3個に限定。3. alert種類を分類。4. 人手レビュー担当を決定。5. 保存されそうなルールを確認。6. 誤memoryの削除手順を確認。7. 28日後に棚卸し。8. code reviewやcloud agentへの波及を評価。
運用設計：memoryを増やすほど必要になる棚卸し
Copilot Memoryは、repository-level factsを現在のbranchで検証し、根拠となるcitationを確認してから使う設計です。ただし、組織側の運用として「古い回避策がmemoryに残っていないか」「一時的な移行ルールが恒久ルールとして扱われていないか」を見る必要があります。
特にセキュリティ修正では、例外的な対応が残りやすくなります。たとえば「このAPIだけは旧認証を許容する」という緊急対応がmemory化されると、将来の修正で望まない例外が再利用される可能性があります。月1回、保存されたrepository-level factsを棚卸しし、恒久ルール、暫定ルール、削除対象に分ける運用を置くと安心です。
導入判断：向いている組織とまだ待つべき組織
向いているのは、CodeQLやDependabotをすでに運用し、セキュリティ修正の型がある組織です。たとえば入力検証、認可チェック、secret handling、SQL/NoSQL injection対策、path traversal対策のように、同じ設計判断が複数箇所に出るチームでは効果を測りやすいです。
導入の目安は30日です。最初の1週間で対象repoとalert種別を決め、2週間目にagentic autofixを試し、3週間目に再発alertへの効き方を観察し、4週間目にmemoryの棚卸しと展開判断を行います。数字で見るなら、差し戻し率20%未満、同種alertの対応時間30%短縮、削除すべきmemoryが月5件未満を暫定基準にできます。
FAQ
Q. Copilot Memoryを有効化すると、すべての情報が他リポジトリに共有されますか？ A. GitHub Docsでは、repository-level factsは同じrepositoryでの操作にスコープされると説明されています。別リポジトリへ広く共有される前提ではありません。
Q. 保存されたmemoryはいつまで残りますか？ A. 未使用のfactやpreferenceは28日後に自動削除されます。ただし、Copilotがそのentryを検証して使うと、28日タイマーがリセットされる場合があります。
まとめ：28日保持を前提に小さく始める
Agentic autofixのCopilot Memory連携は、セキュリティ修正のパターンを組織の実務に近づけるアップデートです。特に、同じ種類の脆弱性対応を繰り返しているチームでは、修正方針を毎回説明する負担を減らせる可能性があります。
ただし、memoryは将来の修正とレビューに影響するため、便利さだけで有効化するのは危険です。30日PoC、1〜3リポジトリ、28日棚卸し、削除手順の確認をセットにして、効果とガバナンスを同時に見てください。
GitHub Copilot、CodeQL、agentic autofixを社内導入する前に、 HelloCraftAIへご相談ください。 セキュリティアラート運用、AI coding研修、管理者向けポリシー設計までまとめて支援します。
