Microsoft SecurityのAI memory poisoning研究で管理者がまず確認すべきことは、「AIメモリを便利な個人化機能としてだけ扱わず、権限・監査・削除・利用者周知の対象に入れること」です。2026年6月22日にMicrosoft Security Blogで公開された「Guarding AI memory」は、分類上はResearchですが、Microsoft 365 CopilotやSecurity Copilot、エージェント活用を進める組織にとっては、運用設計を見直すきっかけになります。(Microsoft)
特に注意したいのは、AI memory poisoningが「その場のプロンプト攻撃」では終わらない点です。悪意ある文書や外部コンテンツに含まれた指示が、AIメモリに影響し、数日後の別の会話やツール実行に影響する可能性があります。管理者は、機能を止めるかどうかだけでなく、「誰に有効化するか」「記憶された情報をどう監査するか」「誤ったメモリをどう削除するか」「利用者に何を説明するか」まで確認しておく必要があります。
Microsoft SecurityのAI memory poisoning研究で示されたポイント
Microsoftの発表では、AI memoryはAIシステムが会話や作業の文脈を保持し、将来の応答や行動に反映する仕組みとして説明されています。これにより、ユーザーの好みを覚える、作業の継続性を高める、エージェントの判断を一貫させるといった利点があります。一方で、AIが「過去に記憶した情報」をもとに判断するため、攻撃者がその記憶に悪意ある内容を混入させると、後から影響が出る可能性があります。(Microsoft)
Microsoft Security Blogでは、隠し指示を含む共有文書をユーザーが開き、AIアシスタントが即座には行動しないものの、後日の別会話で悪意ある記憶が呼び出される仮想シナリオが示されています。これは「delayed tool invocation」と説明されており、攻撃の危険性は、露出したタイミングと実行されるタイミングがずれる点にあります。(Microsoft)
管理者向けに言い換えると、AI memory poisoningは次のようなリスクです。
| 観点 | これまでのプロンプト攻撃 | AI memory poisoningで変わる点 |
|---|---|---|
| 攻撃のタイミング | 1回の会話内で成立しやすい | 複数回の会話や数日後に影響する可能性がある |
| 調査の難しさ | 直近のプロンプトを見れば原因を追いやすい | 過去に処理した文書・チャット・外部情報まで確認が必要になる |
| 影響範囲 | その場の回答や操作に限定されやすい | 記憶が残ると、後続の応答やツール実行に影響する可能性がある |
| 管理の焦点 | 入力内容の検査、プロンプト制御 | メモリ作成、保存、検索、監査、削除まで含めたライフサイクル管理 |
ここで重要なのは、AI memoryを単なる「ユーザー体験向上の設定」と見なさないことです。Microsoftも、AI memoryはユーザー情報を保存するだけでなく、エージェントの行動やツール呼び出しに影響するため、実行権限を持つシステムと同じ厳しさで管理すべきだと説明しています。(Microsoft)
管理者向けチェックリスト
AI memory poisoning研究を受けて、管理者が確認すべき項目は大きく6つあります。すべてを一度に完璧に整える必要はありませんが、少なくとも「有効化状況」「権限」「監査」「削除手順」「高リスク部門」「利用者周知」は早めに棚卸ししておくべきです。
| 確認項目 | 管理者が見るべきポイント | できていない場合のリスク |
|---|---|---|
| 対象範囲 | Microsoft 365 Copilot、Security Copilot、Copilot Studioエージェント、外部コネクタの利用状況 | どこでAI memoryが使われているか把握できず、調査対象が漏れる |
| 有効化ポリシー | Enhanced personalization controlやユーザー・グループ単位の適用範囲 | 高リスク部門にも一律でメモリ機能が有効になる |
| 権限 | テナント設定、eDiscovery、削除、監査ログ閲覧の担当者 | 削除や調査に過剰権限が必要になり、対応が遅れる |
| 監査 | MemoryUpdatedなど、メモリ更新を追えるログの有無 | いつ、誰のメモリが変わったのか追跡できない |
| 削除・是正 | eDiscovery、Microsoft Graph、Purviewでの検索・削除手順 | 誤ったメモリや機密情報を含むメモリを消せない |
| 周知 | ユーザーに「記憶させてよい情報」と「記憶させてはいけない情報」を説明 | パスワード、顧客秘密、内部手順などを不用意に記憶させる |
影響確認：まず「どのAIが何を記憶し得るか」を棚卸しする
最初にやるべきことは、AI memoryが関係するサービスやエージェントの棚卸しです。Microsoft Security Blogの対象はMicrosoft Security / AI memoryの研究ですが、記事内ではMicrosoft 365におけるメモリ作成、保存、監査、eDiscoveryにも触れられています。つまり、Security Copilotだけを見て終わりではなく、Microsoft 365 CopilotやCopilot Studio、Defender、Purview、Sentinelといった運用面まで含めて確認する必要があります。(Microsoft)
実務では、次の順に確認すると漏れを減らせます。
| 優先度 | 確認対象 | 確認内容 |
|---|---|---|
| 高 | Microsoft 365 Copilot / Copilot Chat | メモリや個人化機能が有効か、対象ユーザーは誰か |
| 高 | Security Copilot | SOC、Defender、Purview、Intuneなどで利用しているか |
| 高 | Copilot Studioエージェント | 外部データ、プラグイン、コネクタ、ツール実行の有無 |
| 中 | Teams、Outlook、SharePoint、OneDrive | Copilotが参照できる文書や会話の権限が適切か |
| 中 | 外部連携・Graph Connector | 外部データに機密情報や信頼できないコンテンツが混ざっていないか |
| 中 | 管理センターでのCopilot利用 | 管理者がCopilotを使って設定確認や運用作業をしているか |
特に、SharePointやTeamsに「全社共有」「リンクを知っている全員」「過去プロジェクトの放置サイト」が多い組織では、AI memoryの問題だけでなく、Copilot全般の過剰参照リスクも高まります。AI memory poisoning対策は、単体のセキュリティ設定ではなく、情報アクセス権の整理とセットで考えるべきです。
権限確認：Global Admin任せにせず、役割を分ける
AI memory関連の管理では、少なくとも次の権限領域を分けて考える必要があります。
| 役割 | 主な担当 | 確認すべき権限 |
|---|---|---|
| テナント管理者 | Copilotの個人化・メモリ機能の有効化範囲を決める | Global Administratorなど、テナント設定を変更できる権限 |
| セキュリティ運用担当 | Defender Advanced HuntingやSentinelでログを確認する | 監査ログ、Advanced Hunting、Sentinel Analyticsを扱える権限 |
| コンプライアンス担当 | eDiscoveryで検索・保全・調査を行う | eDiscovery Managerロールグループ |
| 削除・是正担当 | 誤ったAIデータやメモリを削除する | Search And Purgeロール、必要に応じてGraph API権限 |
| 業務部門責任者 | 高リスク業務での利用可否を判断する | システム権限ではなく、利用ルール承認の責任 |
Microsoft Learnでは、Copilot memoryを含むEnhanced personalization controlについて、テナント管理者が管理できると説明されています。また、機能を無効にすると、Copilot memoryのようにそのデータ処理シナリオに依存する機能が利用できなくなる場合があるとされています。(Microsoft Learn)
一方、eDiscoveryでAIデータを検索・削除する場合は、ケース作成や検索にはeDiscovery Managerロールグループ、削除にはSearch And Purgeロールが必要です。削除処理ではMicrosoft Graph ExplorerやGraph APIを使う場面があり、eDiscovery.Read.AllやeDiscovery.ReadWrite.Allへの同意が必要になる場合もあります。(Microsoft Learn)
ここで失敗しやすいのは、「とりあえずGlobal Adminで全部対応する」運用です。緊急時には便利に見えますが、監査性が落ち、削除や調査の責任範囲が曖昧になります。AI memory poisoningのような事案では、セキュリティ、コンプライアンス、業務部門が同じ事実を見ながら判断する必要があるため、権限と責任の分離を先に決めておくことが重要です。
監査確認：MemoryUpdatedを使えるか、実テナントで確認する
Microsoft Security Blogでは、Microsoft 365 Copilotがメモリ更新時の情報を組織の監査ログに記録し、SOCアナリストがDefender Advanced Hunting、Defender Sentinel、Azure Portal Sentinel Analyticsで利用可能なMemoryUpdatedフィールドを既存の分析に結合して、インシデント調査やアラート作成に使えると説明しています。(Microsoft)
ただし、管理者がここで注意すべきなのは、「公式ブログに書かれているから自社テナントでもすぐ同じログが取れる」と決めつけないことです。Microsoft自身も、説明されている機能は構成、ライセンス、サービス提供状況に依存すると明記しています。(Microsoft)
監査の初期確認では、次の観点でチェックします。
| 確認項目 | 実施内容 | 判断基準 |
|---|---|---|
| MemoryUpdatedの有無 | Defender Advanced HuntingやSentinelで該当フィールドを確認 | メモリ更新イベントを検索できる |
| 対象ユーザー | パイロットユーザーで明示的にメモリ更新を行い、ログを確認 | ユーザー、時刻、アプリ、操作の対応が取れる |
| 参照元情報 | Copilotがアクセスしたファイル、メール、Teams、SharePointなどの情報を確認 | 不審な外部文書や共有文書にたどれる |
| アラート化 | 深夜・大量・高権限ユーザーのメモリ更新などを検知条件にする | SOCの通常監視に組み込める |
| 保持期間 | 監査ログやSentinel側の保存期間を確認 | インシデント調査期間に耐えられる |
CopilotやAIアプリケーションの監査ログでは、ユーザーがいつ、どこでCopilotとやり取りしたか、Copilotが応答生成のためにアクセスしたファイルやサイトなどの情報が記録されると説明されています。監査ログにはAccessedResources、AppHost、AppIdentity、Operationなどのプロパティが含まれるため、AI memory poisoningが疑われる場合は、メモリ更新だけでなく、直前に処理された文書やチャットも合わせて追うことが重要です。(Microsoft Learn)
なお、監査ログはセキュリティ・コンプライアンス目的の可視化に使うもので、Copilotの利用率レポートとして使うものではありません。Microsoft Learnでも、監査データをプロンプト数やアクティブユーザー数の集計に使うと、公式の利用状況レポートと一致しない可能性があると説明されています。(Microsoft Learn)
eDiscoveryと削除：チャット削除だけでメモリ削除とは限らない
AI memory poisoningの運用で特に重要なのが、誤ったメモリや機密情報を含むメモリを見つけたときの削除手順です。
Microsoft Learnでは、Copilot personalization and memoryはeDiscovery上でIPM.Contactとして検索対象になると説明されています。さらに、ユーザーの連絡先も同じIPM.Contactを使うため、エクスポート時にはCopilotMemoryフォルダーを確認する必要があるとされています。保存済みメモリやチャット履歴から推論されたメモリはeDiscoveryやMicrosoft Graph Explorerで検出可能ですが、カスタム指示は現時点でこれらのソリューションからはアクセスできず、ユーザーが設定画面から手動でエクスポートする扱いです。(Microsoft Learn)
また、AIアプリケーションデータの削除手順では、eDiscoveryでケースを作成し、検索結果を確認したうえで、Microsoft Graph Explorerなどから削除を実行します。削除できる件数には制限があり、AIデータの検索・削除機能はイベント対応用の機能として設計されているため、1回の大規模な一括整理に使うより、対象を絞った調査・是正に向いています。(Microsoft Learn)
管理者が押さえるべき削除時の注意点は次の通りです。
| 注意点 | 内容 | 実務上の対策 |
|---|---|---|
| チャット削除とメモリ削除は別に考える | 会話やメッセージを削除しても、関連するCopilot memoryが削除されるとは限らない | メモリはIPM.ContactやCopilotMemoryを含めて確認する |
| 保持ポリシーや訴訟ホールドの影響を受ける | 対象メールボックスに保持やホールドがあると、削除しても保持される場合がある | 削除前後で保持設定を記録し、必要な承認を取る |
| 削除後すぐに完全消去とは限らない | 削除データはHidden folderやSubstrateHoldsを経由し、タイマー処理で消える | 「削除実行」と「完全削除」の時間差を手順書に書く |
| ユーザーへの通知がない場合がある | 削除処理後、ユーザーに明示的な通知が出ない場合がある | サポート窓口側で説明テンプレートを用意する |
| Graph権限が必要になる | 削除時にGraph API権限への同意が必要な場合がある | 平時に検証用ケースで手順を確認しておく |
AI memory poisoningの疑いがある場合、削除だけを急ぐと証拠保全に失敗します。まず、該当ユーザー、発生時刻、参照元コンテンツ、メモリ更新イベント、関連するCopilot操作を保全し、その後に削除・再発防止へ進むのが安全です。
移行・展開見直し：一斉有効化から段階展開へ切り替える
今回のMicrosoft Security BlogはResearchとして公開されており、特定バージョンへの強制移行や、すべてのテナントに対する即時変更期限を示すものではありません。したがって、管理者が行うべき「移行」は、製品アップグレードではなく、CopilotやAIエージェントの運用を「機能展開中心」から「メモリを含むガバナンス中心」に移すことです。
展開状況別に、次のように判断すると現実的です。
| 組織の状況 | 推奨される対応 |
|---|---|
| Copilot未導入 | ライセンス配布前に、メモリ、監査、eDiscovery、利用ルールを設計する |
| 一部部門でパイロット中 | パイロット対象を維持し、MemoryUpdatedや削除手順を検証してから拡大する |
| 全社展開済み | 高リスク部門を洗い出し、個人化・メモリ機能の適用範囲を見直す |
| Copilot Studioエージェントを運用中 | エージェントごとに、参照データ、ツール実行、メモリ利用、所有者を台帳化する |
| 規制業種・機密部門が多い | 有効化より先に、DSR対応、保持、削除、監査証跡の確認を優先する |
特に、法務、人事、経営企画、研究開発、セキュリティ運用のように、少数のユーザーが高機密情報を扱う部門では、全社標準の設定をそのまま適用しないほうがよい場合があります。AI memoryは利便性が高い一方で、誤った文脈を記憶すると後続の判断に影響するため、高リスク部門では「メモリを使うメリット」と「監査・削除できる体制」をセットで評価すべきです。
高リスクな利用シーンと判断基準
AI memory poisoningのリスクは、すべての利用で同じではありません。次の条件が重なるほど、管理者による制御を強めるべきです。
| 利用シーン | リスクが高くなる理由 | 管理者の判断 |
|---|---|---|
| 外部から受け取った文書をCopilotに要約させる | 文書内に隠し指示や誘導文が含まれる可能性がある | 外部文書の取り扱いルールを周知し、監査ログで参照元を確認する |
| エージェントがカレンダー、メール、チケット、顧客DBに接続している | メモリがツール実行に影響すると、影響範囲が広がる | ツール実行権限を最小化し、承認フローを入れる |
| 管理者やSOCがSecurity Copilotを使う | セキュリティ判断や調査結果に影響する可能性がある | 高権限ユーザーのメモリ更新を重点監視する |
| 人事・法務・財務データを扱う | 誤記憶や不要な保持がコンプライアンス問題になりやすい | 対象グループを限定し、eDiscovery手順を事前検証する |
| 外部コネクタやプラグインを多数使っている | 信頼境界が増え、参照元の把握が難しくなる | コネクタごとに所有者、データ分類、停止手順を管理する |
判断基準は単純です。AIが「覚える」情報が、後で業務判断やツール実行に使われても問題ないかを考えます。問題があるなら、メモリ機能の適用範囲を狭める、対象データの権限を見直す、監査と削除手順が整うまでパイロットに留める、といった対応が必要です。
SOC・管理者が作るべき検知ルールの考え方
AI memory poisoningを検知するには、従来の「不審なサインイン」「マルウェア検知」だけでは足りません。AIメモリの更新、参照元コンテンツ、後続のツール実行をつなげて見る必要があります。
最初に作るべき検知観点は次の通りです。
| 検知観点 | 例 |
|---|---|
| 高権限ユーザーのメモリ更新 | 管理者、SOC、役員、人事、法務ユーザーでMemoryUpdatedが発生 |
| 外部文書参照後のメモリ更新 | SharePoint外部共有、メール添付、外部コネクタ由来の文書を処理した後にメモリ更新 |
| 短時間の連続更新 | 同一ユーザーで短時間に多数のメモリ更新 |
| 深夜・休日の更新 | 通常業務時間外にメモリ更新が発生 |
| ツール実行との関連 | メモリ更新後にカレンダー、メール、チケット、ファイル操作が行われた |
| 高機密ラベルとの関連 | Copilotが機密ラベル付き資料へアクセスした後にメモリ更新 |
初期段階では、いきなり自動遮断にするより、アラートを低優先度で出して実データを観察するほうが安全です。通常利用でもメモリ更新は発生し得るため、まずは「何が正常か」を把握し、部署や役職ごとのベースラインを作ることが大切です。
利用者への周知：禁止事項より「覚えさせる基準」を伝える
AI memory poisoning対策では、管理者側の設定だけでなく、利用者への周知も欠かせません。ただし、「危険だから使うな」だけでは現場に定着しません。ユーザーには、AI memoryの利便性と注意点をセットで伝える必要があります。
社内周知では、次のような内容を入れると実務に落とし込みやすくなります。
| 周知項目 | 伝える内容 |
|---|---|
| AI memoryとは何か | Copilotがユーザーの好みや作業文脈を覚え、次回以降の応答に反映する機能 |
| 覚えさせてよい情報 | 文書の書き方の好み、通常の会議準備スタイル、公開可能な業務上の作業傾向 |
| 覚えさせてはいけない情報 | パスワード、APIキー、顧客の機微情報、未公開の人事情報、内部監査情報、秘密の業務手順 |
| 不審な兆候 | Copilotが急に関係ない操作を勧める、覚えさせていない内容を前提に話す、外部送信を促す |
| 相談先 | 情報システム部門、SOC、セキュリティ窓口、Microsoft 365管理者 |
周知文の例は次の通りです。
Microsoft 365 Copilotのメモリ機能は、業務の好みや作業文脈を覚えて回答を改善するための機能です。一方で、誤った情報や不要な指示が記憶されると、後の応答に影響する可能性があります。パスワード、認証情報、顧客の機微情報、社外秘の判断基準などはCopilotに記憶させないでください。Copilotが覚えていないはずの内容を前提に回答する、関係のない操作を促す、外部共有を勧めるなどの挙動があれば、情報システム部門へ連絡してください。
このように具体例を入れると、現場は判断しやすくなります。特に「覚えさせてはいけない情報」を明文化しておくと、インシデント対応時にも教育済みのルールとして扱いやすくなります。
よくある誤解と失敗しやすいポイント
AI memoryはチャット履歴と同じだと思ってしまう
AI memoryは、単なるチャット履歴ではありません。保存されたメモリ、チャット履歴から推論された情報、個人化設定などが関係します。Microsoft Learnでも、Copilot memoryの検索ではIPM.Contactを扱う必要があり、通常のCopilot会話データとは見方が異なることが示されています。(Microsoft Learn)
そのため、「チャットを削除したから安心」と考えるのは危険です。メモリと会話、監査ログ、保持ポリシーを分けて確認する必要があります。
プロンプトインジェクション対策だけで十分だと思ってしまう
Microsoftの発表では、AI memoryの防御は保存、検索、モデルとのやり取り、ユーザー制御など、複数レイヤーにまたがる防御が必要だと説明されています。(Microsoft)
つまり、入力時の検査だけでは不十分です。メモリに書き込む前の検査、保存後の監査、利用時の再評価、削除やユーザー制御まで含めて設計する必要があります。
全社一律で有効化してから考える
Copilotの導入では、まず利用率を上げたくなります。しかしAI memoryについては、全社一律で有効化してから後で統制を考えると、調査対象が広がりすぎます。
最初は、IT部門、セキュリティ部門、代表的な業務部門でパイロットを行い、ログ、削除、周知、問い合わせ対応を確認してから拡大するほうが安全です。
監査ログだけで中身まで分かると思ってしまう
監査ログは、誰がいつどのアプリでCopilotを使い、どのリソースにアクセスしたかを追うのに役立ちます。一方で、実際のプロンプトや応答内容の確認にはeDiscoveryなど別の仕組みが必要になる場合があります。Microsoft Learnでも、監査データはセキュリティ・コンプライアンス目的の可視化であり、プロンプトや応答そのものの確認には別の方法が必要と説明されています。(Microsoft Learn)
今日から進める確認手順
最後に、管理者が実際に進める順序を整理します。
| タイミング | 実施内容 |
|---|---|
| 今日 | Copilot、Security Copilot、Copilot Studioエージェントの利用状況を一覧化する |
| 今日 | Enhanced personalization controlやメモリ機能の有効化範囲を確認する |
| 今週 | Defender Advanced HuntingやSentinelでMemoryUpdated相当のログが確認できるか検証する |
| 今週 | eDiscoveryでCopilot memoryを検索できるか、検証用ユーザーで手順を確認する |
| 今週 | 高リスク部門の利用可否、対象グループ、例外ルールを決める |
| 今月 | SOCの検知ルール、インシデント対応手順、削除手順、利用者向け周知文を整備する |
| 継続 | Microsoft Security Blog、Microsoft Learn、Message Centerの更新を定期確認する |
Microsoft SecurityのAI memory poisoning研究は、すぐに全機能を停止すべきという話ではありません。むしろ、AI memoryを安全に使うために、管理者が「記憶の作成」「保存」「監査」「削除」「利用者制御」を運用に組み込むべきだという警告として読むべきです。
CopilotやAIエージェントは、業務を効率化する強力な仕組みです。しかし、メモリが後続の応答やツール実行に影響する以上、AI memoryは新しい監査対象であり、新しいデータ管理対象でもあります。まずは対象範囲と有効化状況を確認し、監査ログと削除手順を検証したうえで、段階的に展開を進めることが現実的な対策です。
コメント