GitHub Copilotの自動修正がMemoryに対応。記憶する内容とレビューの注意点

この記事でわかること

• 更新内容：agentic autofixが過去の修正パターンを参照・保存する。
• 記憶の扱い：共有範囲、現在のコードとの照合、既定90日の有効期間と更新条件。
• レビュー：記憶に頼り切らず、今回の条件と検証結果を確認する。

自動修正が、過去の修正パターンを参照するようになった

GitHubは2026年9月25日、セキュリティ警告への修正を支援するagentic autofixがCopilot Memoryを利用するようになったと発表しました。

Memoryを利用できる設定では、修正時に既存の記憶を参照し、作成した修正のパターンを今後のために保存します。

期待されるのは、プロジェクト固有のルールを毎回説明し直す負担を減らすことです。一般に正しそうなコードでも、そのリポジトリが採用する処理方法と合わなければ修正が必要になります。過去の経験を参照できれば、その前提を次の提案にも使える可能性があります。

ただし、修正の経験を参照することと、今回の修正が安全だと保証されることは別です。コードスキャン警告向けagentic autofixは2026年10月15日に一般提供へ移行しました。以下では、Memoryの設定や保持条件を11月9日時点の公式文書に沿って整理します。

出典：GitHub Changelog：agentic autofixのMemory対応

Copilot Memoryには、共有範囲の違う2種類の記憶がある

GitHub Docsでは、リポジトリについての事実と、利用者個人の作業上の好みを分けて説明しています。すべての会話を全員が共有する仕組みとして理解すると、扱う情報の範囲を誤ります。

機能ごとの差もあり、Copilot code reviewとagentic autofixはリポジトリの事実を使い、個人の好みは適用しないと案内されています。「自分が別の会話で伝えた好みが、そのままチーム全体のレビュー基準になる」とは考えないようにします。

企業で導入する際は、まず共通ルールと個人の好みを分けて説明できるかを確認します。必ず守る規約は正式な文書やリポジトリの指示にも残し、AIが偶然記憶していることだけを業務の前提にしない方が、担当者の交代にも対応しやすくなります。

古い記憶をそのまま使わないための照合と保持期間

リポジトリの事実には、根拠となるコードへの参照が付きます。Copilotは現在のブランチと照合して妥当性を判断しますが、古い事実を必ず見抜くというシステム上の保証ではありません。必須の規約は、正式な指示や文書にも残してください。

閉じられて未マージのプルリクエストから記憶が作られた場合も、現在のコードが裏付けるかが重要になります。

記憶の有効期間と、正式な記録を分ける

記憶の有効期間は既定で90日です。作成時から数え、Copilotが有用性を評価して肯定票を付けると期間が更新されます。単に参照しただけでは延びません。組織・企業の所有者はリポジトリの事実を7〜180日に設定できますが、個人の好みは既定の90日です。既存の事実は、次に肯定票が付いた時点で新しい保持設定を採用します。

出典：GitHub Docs：Memoryの保存・保持・検証

この仕組みを踏まえると、Memoryは正式な設計書や監査記録の代わりには向きません。後から「なぜこの方針にしたか」を人が確実に確認する必要がある情報は、Issueや設計文書にも残します。

AIの作業を助ける記憶と、チームが管理すべき記録を使い分けることが大切です。

修正経験が役立つ場面を、具体例で考える

以下は仕組みを理解するための架空の例です。あるプロジェクトでは、入力内容の確認を共通の関数にまとめているとします。新しい警告を直すたびに別の確認処理を作ってしまうと、条件の差や修正漏れを生みやすくなります。

過去の修正で共通関数を使う方針が把握され、現在のコードでも確認できれば、次の修正案をその方針に沿わせるための文脈になります。

レビュー担当者は、既存のルールを一から説明する代わりに、今回の入力でもその関数が十分かを確認できます。

反対に、以前とはデータの入り口や権限の条件が違う場合、同じ修正を当てはめるだけでは足りません。似た警告名であっても、影響する範囲が同じとは限らないためです。過去のパターンは出発点に使い、今回の条件で確かめる工程を残します。

記憶を蓄積する前に、曖昧な共通ルールを整理する

同じリポジトリの中で、古い実装と新しい方針が混在していることもあります。その場合、記憶できる情報が増えても、チームがどちらを採用するかを決めていなければ、期待する提案はそろいません。

たとえば、ある機能だけに残る古い処理を「プロジェクト全体の標準」と読み取ってほしくない場合は、移行中であることや対象範囲を文書へ残します。人のレビューでも判断が割れる状態なら、Memoryの良し悪しを測る前に、基準を明確にする必要があります。

試行では、同じ種類の警告について、最初の提案で直った範囲とレビューで戻した理由を記録すると評価しやすくなります。

「提案が増えたか」だけでなく、同じ前提を説明し直す回数や、現在の方針に合わない修正が減ったかを見ると、Memoryに期待した効果を確認できます。

有効化する前に、利用者設定と組織の方針をそろえる

Copilot Memoryは有料Copilotプランで利用できますが、リポジトリの事実と個人の好みは別々に設定します。個人の好みはPro・Pro+・Maxでは既定で有効、Business・Enterpriseでは管理者の許可が必要です。リポジトリの事実は別のアクセス設定に従い、個人の好みを無効にしても連動して無効にはなりません。agentic autofixではリポジトリ側の設定を確認してください。

Memoryの利用条件と、agentic autofix自体の条件は別です。コードスキャン警告向けagentic autofixは、GitHub Enterprise CloudでGitHub Code SecurityまたはGitHub Advanced Securityを利用する顧客が対象です。企業管理者によるポリシー許可と組織・リポジトリ側の有効化、Copilotの課金設定が必要で、Code SecurityのAI CreditsとGitHub Actionsの実行時間を消費します。

記憶の確認・削除権限も確認します。リポジトリ設定で事実を確認・削除するには、書き込み権限と、そのアカウントで個人の好みを有効にすることが必要です。個人の好みは本人が確認・削除でき、Business・Enterpriseでは組織・企業の管理者も管理できます。好みが共有したエージェントセッションに表示されれば、その閲覧者にも見える点に注意してください。

設定を担当する人だけでなく、実際に修正をレビューする人にも共有しておくと、「なぜこの前提で修正されたか」が分からないときの確認先をそろえられます。

少人数の対象から試す場合も、利用者によってMemoryの状態が違う可能性を記録しておきます。

レビューでは、修正内容・根拠・検証結果の3点を見る

運用の評価では「同じ説明が減ったか」だけでなく、修正案を確認しやすくなったかを見ます。以下は編集部が整理した確認項目です。

1. 修正内容：警告の原因へ対応しているか、無関係な変更を含まないか。
2. 根拠：参照した過去の方針が現在のコードにも当てはまるか。
3. 検証：該当条件の確認と、周辺動作への影響確認ができているか。

指摘が消えたことだけを完了条件にすると、機能の動きが変わった場合に見落とす恐れがあります。たとえば入力検証を直したなら、不正な入力を拒否できることに加え、正しい入力まで拒否していないかを確認します。

誤った前提が繰り返されるときは、記憶と共通ルールを見直す

Memoryが原因と思われる誤った前提が繰り返されるなら、記憶の内容と根拠を見直し、必要に応じて削除します。そのうえで共通ルール側も分かりやすくしておくと、単に一つの記憶を消すだけでなく、次の作業の前提を整えることにつながります。

実務上の注意

Memoryの有効化は、修正の自動承認を意味しません。保持される情報や削除権限を管理担当者と確認し、修正案には通常のレビューと検証を行ってください。この記事のコード修正例は架空の説明例で、実際の性能評価ではありません。

まとめ

agentic autofixのMemory対応は、リポジトリ固有の修正経験を次の提案へ活かす更新です。共有される事実と個人の好みを分け、現在のコードとの照合や保持期間を理解したうえで利用します。

レビューでは、過去の経験が今回にも当てはまるかを確認することが、便利さを品質へつなげるポイントです。

関連記事：AIへの指示・スキルを整理する考え方

よくある質問

出典・参考情報

利用条件と保持設定は2026年11月9日に確認しています。

• GitHub：Agentic autofix now uses Copilot Memory
• GitHub Docs：About GitHub Copilot Memory
• GitHub Docs：Copilot Memoryの管理と保持期間
• GitHub：コードスキャン警告向けagentic autofixの一般提供