Microsoft Securityが公開したAI memory poisoning研究で押さえるべき点は、「AIのメモリ機能は便利な個人化機能である一方、攻撃者に悪用されると一時的なプロンプト攻撃が“後から効く持続的な攻撃”に変わる」ということです。2026年6月22日のMicrosoft Security Blog「Guarding AI memory」は、製品の単なる新機能紹介ではなく、AI memoryを使う組織が確認すべきリスク、監査ログ、メモリ更新の可視化、eDiscoveryでの調査・削除、テナント単位の個人化制御を整理したResearch分類の記事です。(Microsoft)
特にMicrosoft 365 Copilot、Microsoft Security Copilot、Copilot Studioで作成したエージェント、社内AIエージェントを利用している企業は、AI memory poisoningを「AIの回答品質の問題」ではなく、「監査・権限・データ保護・インシデント対応の対象」として扱う必要があります。
Microsoft SecurityのAI memory poisoning研究は何が変わったのか
今回のポイントは、MicrosoftがAI memoryを「個人化のための保存領域」だけでなく、「将来のAI動作に影響する制御面」として明確に位置付けたことです。AI memoryは、ユーザーの好みや作業文脈を保持し、後の会話や作業支援に活用します。便利な反面、攻撃者が不正な内容を記憶させると、元の会話や文書から時間が経ったあとに、AIの判断やツール実行へ影響する可能性があります。(Microsoft)
従来のプロンプトインジェクション対策は、「その場の入力に含まれる悪意ある命令を検出する」発想が中心でした。しかしAI memory poisoningでは、攻撃が複数回のやり取りに分かれたり、共有ドキュメントなどの外部コンテンツを経由したり、数日後の別セッションで発火したりします。Microsoftはこの性質を、単一ターンの防御だけでは不十分になる問題として説明しています。(Microsoft)
変更点を短く整理
| 確認項目 | これまで見落とされやすかった点 | 今回意識すべきこと |
|---|---|---|
| AI memoryの位置付け | 便利な個人化データとして見がち | 将来のAI動作に影響する高リスクな永続データとして扱う |
| 攻撃の考え方 | 1回のプロンプトで成立する攻撃を想定 | 複数ターン、時間差、別コンテキストで成立する攻撃を想定 |
| 防御の焦点 | 入力時の検出だけに偏りやすい | 書き込み、保存、取得、監査、削除までライフサイクル全体で見る |
| 運用担当 | AI導入担当だけで判断しがち | SOC、情報システム、コンプライアンス、データ管理部門も関与する |
| 調査方法 | 会話履歴だけを確認しがち | メモリ更新ログ、アクセス元、参照された文書、eDiscoveryも確認する |
AI memory poisoningとは何か
AI memory poisoningとは、AIが将来参照するメモリに、攻撃者の意図した内容や命令を混入させる攻撃です。たとえば、共有ドキュメントに見えない形で悪意ある命令を埋め込み、AIがそれを読み取ったあと、別の日の会話でその内容がメモリとして利用されるように誘導するケースが考えられます。
Microsoft Security Blogでは、共有ドキュメントに隠された命令が、後日の別コンテキストでメモリ更新やツール実行に影響する仮想シナリオが示されています。重要なのは、攻撃が文書を開いた瞬間には目立たず、時間差で発火する点です。(Microsoft)
何が危険なのか
AI memory poisoningが厄介なのは、攻撃内容が「会話の一時的な入力」ではなく「将来の判断材料」として残る可能性があることです。通常のプロンプトインジェクションなら、その会話や処理を閉じれば影響が終わる場合があります。しかしメモリに残った場合、次回以降の回答、ツール呼び出し、データ参照、タスク実行に影響する可能性があります。
実務では、次のようなリスクを想定すべきです。
- ユーザーの予定、顧客情報、社内文書などを不適切に参照させる
- AIに特定のツール実行を優先させる
- 以前の悪意ある文脈を、無関係な会話で再利用させる
- メモリに残った誤情報により、AIの回答や判断が継続的に歪む
- 調査時に「どの入力が原因だったのか」を追跡しにくくなる
影響を受けやすい対象者
今回の研究は、Microsoft Security Copilotだけを使う担当者に限った話ではありません。Microsoft Security Blog上では対象サービスとしてMicrosoft Security Copilotが示されていますが、本文ではMicrosoft 365 CopilotのAI memory、監査ログ、eDiscovery、テナントポリシーにも触れています。(Microsoft)
特に確認が必要なのは、次のような組織です。
| 対象者 | 確認すべき理由 |
|---|---|
| Microsoft 365 Copilotを展開している企業 | Copilot memoryや個人化機能が業務データと結び付く可能性があるため |
| Microsoft Security Copilot利用組織 | セキュリティ調査や運用判断にAI出力を使うため、メモリ汚染の影響が運用判断に波及しやすい |
| Copilot Studioでエージェントを作成している部門 | 独自エージェントがメモリ、ツール、外部データを組み合わせる場合、設計段階で対策が必要 |
| SOC・CSIRT | MemoryUpdatedなどのログをインシデント調査に組み込む必要がある |
| コンプライアンス・法務部門 | eDiscoveryや削除、保持ポリシーとの関係を確認する必要がある |
| 情報システム部門 | テナント単位の個人化制御、監査、権限、データ共有状態を確認する必要がある |
すぐ確認したい設定と運用ポイント
まず確認すべきなのは、「AI memoryを使うかどうか」ではなく、「使っている場合に、誰が、何を、どのように記憶し、後から追跡・削除できるか」です。
AI memoryの個人化制御を確認する
Microsoft 365 Copilotの個人化は、テナント管理者が制御できる項目です。Microsoft Learnでは、Enhanced personalization controlにより、テナント全体または一部ユーザーに対して関連機能を無効化でき、場合によってはCopilot memoryのような機能が利用できなくなると説明されています。(Microsoft Learn)
確認すべきことは次の3つです。
| 確認項目 | 判断基準 |
|---|---|
| 個人化機能を有効にする範囲 | 全社一律ではなく、まずは部門・役職・データ感度で分ける |
| 対象ユーザー | 経営、人事、法務、セキュリティ部門など高機密情報を扱うユーザーは慎重に判断する |
| 利用者への説明 | AIが何を記憶する可能性があるのか、削除や問い合わせ先を明確にする |
「便利だから全員オン」にするのではなく、業務上の効果と情報漏えい時の影響を比較して段階的に展開するのが現実的です。
監査ログでメモリ更新を追跡できるか確認する
Microsoft Security Blogでは、Microsoft 365 Copilotがメモリ更新を組織の監査ログに記録し、SOC担当者がDefender Advanced Hunting、Defender Sentinel、Azure Portal Sentinel AnalyticsでMemoryUpdatedフィールドを既存の分析と結合できると説明しています。(Microsoft)
ここで重要なのは、「ログがある」ことと「運用で見ている」ことは別だという点です。AI memory poisoningを想定するなら、次のような観点でアラートやハンティングクエリを検討します。
| 見るべき兆候 | 例 |
|---|---|
| 短時間に多数のメモリ更新がある | 特定ユーザーで不自然にMemoryUpdatedが連続する |
| 外部共有ファイル参照後にメモリ更新がある | SharePoint、OneDrive、Teams上の共有文書を読んだ後にメモリが更新される |
| 高権限ユーザーでメモリ更新がある | 管理者、役員、セキュリティ担当者のメモリ更新を優先監視する |
| 機密ラベル付きファイルが参照されている | Copilot監査ログのAccessedResourcesやSensitivityLabelIdを確認する |
| XPIA検出とメモリ更新が近い | Cross Prompt Injection Attack検出後のメモリ更新を重点調査する |
Microsoft Learnの監査ログ資料では、CopilotやAIアプリのユーザー操作は監査ログに記録され、AccessedResources、AgentId、AgentName、AppHost、Messages、XPIADetectedなどの属性が含まれることが説明されています。(Microsoft Learn)
eDiscoveryで検索・削除できる範囲を確認する
メモリ汚染が疑われる場合、会話履歴を削除するだけでは不十分な場合があります。Microsoft Learnでは、Copilot memoryデータはeDiscovery上でIPM.Contactとして扱われ、会話やメッセージを削除しても関連するCopilot memoryが削除されるわけではないと説明されています。(Microsoft Learn)
インシデント対応の観点では、次の点を事前に決めておくべきです。
| 対応項目 | 事前に決めること |
|---|---|
| 調査権限 | eDiscovery Manager、Search And Purgeなど必要なロールを誰に付与するか |
| 削除判断 | 誤ったメモリ、機密情報、悪意ある内容を誰が削除判断するか |
| 証跡保全 | 削除前にどのログ、対象ユーザー、関連文書を保存するか |
| 影響範囲確認 | 同じ文書を参照した他ユーザーにも影響がないか確認する |
| 再発防止 | 共有文書、外部ファイル、コネクタ、エージェント権限を見直す |
特に「削除できるから安心」ではなく、「削除前に証跡を残す」「保持ポリシーや訴訟ホールドとの関係を確認する」ことが重要です。
管理者が優先して実施すべきチェックリスト
Microsoft SecurityのAI memory poisoning研究を受けて、管理者は次の順番で確認すると効率的です。
| 優先度 | 確認内容 | 目的 |
|---|---|---|
| 高 | AI memoryや個人化機能の有効範囲を確認する | 不要なユーザーまでメモリ機能が広がっていないか確認する |
| 高 | 監査ログが有効で、Copilot関連ログを確認できるか確認する | メモリ更新やAI操作の追跡性を確保する |
| 高 | SOCでMemoryUpdatedやXPIA検出を確認する運用を作る | メモリ汚染の早期発見につなげる |
| 中 | eDiscoveryでCopilot memoryを検索・削除する手順を確認する | 汚染・誤記憶・機密情報混入時に対応できるようにする |
| 中 | 高機密部門のCopilot利用範囲を見直す | 人事、法務、経営、セキュリティ情報の不適切な記憶を避ける |
| 中 | Copilot Studioや独自エージェントのメモリ設計を棚卸しする | 独自開発部分の責任範囲を明確にする |
| 低 | 利用者向けに「AIに記憶させてよい情報」のルールを整備する | 現場の誤用や過信を減らす |
Copilot Studioや独自AIエージェントで注意すべき設計
AI memory poisoningは、Microsoft 365 Copilotだけの問題ではありません。Copilot Studioや独自エージェントでメモリを持たせている場合、設計側で「何を記憶してよいか」「どの情報源からの内容を記憶してよいか」「記憶した内容を後からどう検証するか」を決める必要があります。
Microsoftのガイダンスでは、AI memoryを保護する考え方として、書き込み時にユーザー意図と出所を確認すること、モデルのプロンプトだけに境界制御を依存しないこと、取得したメモリを無条件に正しい情報として扱わないこと、メモリ操作のライフサイクルを記録すること、ユーザーが確認・編集・削除できるようにすることが示されています。(Microsoft)
実装・運用で避けたい設計
避けたいのは、次のような設計です。
- 外部文書やWebページの内容を、そのまま長期メモリに保存する
- 「以前の会話で言われたこと」を無条件にシステム指示のように扱う
- メモリの出所、作成日時、作成理由を記録しない
- ユーザーや管理者がメモリ内容を確認できない
- 削除・無効化・ロールバック手順がない
- エージェント間でメモリを広く共有しすぎる
- ツール実行権限とメモリ参照権限を分離していない
AIエージェントにメモリを持たせる場合は、メモリを「便利なメモ帳」ではなく「AIの動作に影響する設定情報」として扱うべきです。
利用者に周知すべき注意点
現場ユーザーには、専門的なAIセキュリティ用語よりも、具体的な行動ルールとして伝える方が効果的です。
| 利用者向けルール | 理由 |
|---|---|
| AIに機密情報を安易に「覚えて」と指示しない | 後の回答や処理に使われる可能性があるため |
| 外部から受け取った文書をCopilotで処理する場合は注意する | 隠れた命令や不正な内容が含まれる可能性があるため |
| AIの回答が急に不自然になったら報告する | メモリや参照情報が影響している可能性があるため |
| 顧客情報・認証情報・個人番号・契約情報をメモリ化しない | 情報管理上のリスクが高いため |
| 「前に覚えた内容」が間違っている場合は放置しない | 誤情報が継続的に回答へ影響する可能性があるため |
ユーザー教育では、「AIは便利だが、覚えた内容が間違っていると次の仕事にも影響する」と説明すると理解されやすくなります。
影響範囲を判断する基準
すべての組織が同じ緊急度で対応する必要はありません。次の条件に当てはまるほど、優先度を上げて確認すべきです。
| 状況 | リスク評価 |
|---|---|
| Microsoft 365 Copilotを全社展開している | 高 |
| 高機密部門でCopilotを利用している | 高 |
| Copilot Studioで業務エージェントを作成している | 高 |
| 外部共有文書や取引先ファイルをCopilotで頻繁に処理する | 高 |
| Sentinel、Defender、Purviewの監査運用が未整備 | 高 |
| 一部ユーザーで限定的に試験利用している | 中 |
| メモリ機能や個人化機能をまだ利用していない | 低。ただし導入前設計は必要 |
特に、AIがメール、予定表、Teams、SharePoint、OneDrive、業務アプリの情報を横断して扱う環境では、メモリ汚染の影響範囲が広がりやすくなります。Microsoft 365 Copilotは既存の権限とアクセス制御の範囲でデータにアクセスする一方、共有範囲が広すぎるコンテンツはCopilot結果のリスクを高める可能性があるため、過剰共有の見直しも重要です。(Microsoft Learn)
まず実施すべき実務対応
今回のMicrosoft SecurityのAI memory poisoning研究を受けて、最初に行うべき対応は大きく3つです。
まず、AI memoryや個人化機能の有効範囲を確認します。全社に有効化している場合は、高機密部門や管理者アカウントを含めて妥当かを見直します。
次に、監査ログを確認します。Copilot関連の操作、参照されたリソース、XPIA検出、メモリ更新をSOCや管理者が追跡できる状態にします。ログが存在しても、誰も見ていなければ検知にはつながりません。
最後に、削除とインシデント対応の手順を整備します。メモリ汚染が疑われる場合、会話履歴だけでなくCopilot memory自体を調査対象に含め、eDiscoveryやMicrosoft Graphを使った検索・削除、証跡保全、影響範囲確認まで手順化しておくことが重要です。MicrosoftのeDiscovery資料では、AI関連データの検索・削除がデータ流出や不適切な内容の混入に対応する目的で説明されています。(Microsoft Learn)
まとめ：AI memoryは便利機能ではなく管理対象として扱う
Microsoft SecurityのAI memory poisoning研究で最も重要なのは、AI memoryを「個人化を便利にする機能」としてだけ見ないことです。メモリは、AIが将来どう判断し、どの情報を参照し、どのツールを実行するかに影響します。そのため、攻撃者に汚染されると、単発のプロンプト攻撃よりも長く、見つけにくく、調査しにくい問題になります。
Microsoft Security / AI memory利用者は、まず次の3点を確認してください。
- AI memoryと個人化機能の有効範囲は適切か
- MemoryUpdatedなどの監査ログをSOCや管理者が確認できるか
- eDiscoveryや削除手順を含め、メモリ汚染時の対応手順があるか
AIのメモリ機能は、今後の業務AIに欠かせない要素になります。だからこそ、導入後に慌てて対策するのではなく、展開前または利用拡大前に、権限、監査、削除、ユーザー説明まで含めて運用設計を見直すことが重要です。
コメント