GitHub Agentic autofixがCopilot Memoryに対応、安全修正パターンをタスク間で再利用

GitHubは9月25日、Agentic autofixがCopilot Memoryを利用するようになったと発表した。Memoryを有効にしているユーザーの場合、エージェントはセキュリティアラートの処理時に既存のメモリを参照し、修正を生成する際に修正パターンを保存して、後で再利用できるようにする。これらの情報はCopilot code reviewやcloud agentにも提供され、同じリポジトリのセキュアな開発慣行を他のワークフローでも活用できる。両機能は現在もパブリックプレビュー段階にある。[公式発表](https://github.blog/changelog/2026-09-25-agentic-autofix-now-uses-copilot-memory/)

今回の変更の技術的な要点は、安全修正で蓄積されたコンテキストをタスク間で共有するメモリに取り込むことだ。公式の説明から推測すると、エージェントがプロジェクト固有のデータベース接続や入力処理の慣行を取得できれば、後続の修正で同じ調査を繰り返す手間を減らし、一貫した実装を採用しやすくなる可能性がある。ただし、発表には修正の成功率、所要時間、コストを比較するデータはなく、実際の効果は今後の測定を待つ必要がある。

メモリの信頼性は、利用前の検証に左右される。公式ドキュメントによると、リポジトリレベルの事実には、それを裏付けるコードへの引用が付く。Copilotは情報がタスクに関連すると判断した後、現在のブランチを基準に引用を確認し、検証を通過した内容だけを使用する。こうした事実は同じリポジトリ内の操作にのみ使われ、記憶の作成元となるのは、Memoryを有効にし、書き込み権限を持つユーザーが開始したアクティビティに限られる。[メモリの仕組み](https://docs.github.com/en/copilot/concepts/agents/copilot-memory)

保存期間にも条件がある。事実や好みが28日間連続で使われないと自動的に削除されるが、検証に成功して使用されると、期間のカウントがリセットされる場合がある。また、マージされないままクローズされたプルリクエストからもメモリが作成される可能性がある。そのため、「保存済み」であることをチームが修正を受け入れた証拠と見なすことはできず、現在のコードに照らして適用できるかを確認する必要がある。[保存と検証のルール](https://docs.github.com/en/copilot/concepts/agents/copilot-memory#retention-and-validation)

導入にあたっては、適用されるポリシーの範囲を確認する必要がある。企業や組織が管理するサブスクリプションでは、Copilot Memoryは既定で無効になっており、管理者が有効にした後もユーザーはオプトアウトできる。複数の組織ライセンスを持つユーザーには、最も厳しい設定が適用される。リポジトリ管理者は、不適切または誤った事実を確認して削除できるため、メモリの内容を保守可能なエンジニアリング資産として扱える。[管理者向けドキュメント](https://docs.github.com/en/copilot/how-tos/use-copilot-agents/copilot-memory/manage-as-administrator)

今後は、メモリの追加によってテストや人手によるレビューを通過する修正の割合が上がるか、またアーキテクチャの変更後に古いパターンが誤って使われないかを追う必要がある。発表では、修正の生成時にパターンを保存すると説明されているが、マージやセキュリティテストの合格を保存の条件にするかどうかは明らかにされていない。実務では、引用の検証と脆弱性修正そのものの検証を分け、回帰テストと修正レビューを維持する必要がある。