AIエージェントのメモリ汚染(sleeper memory poisoning)とは｜永続メモリを狙う遅延型攻撃を業務目線で

AIエージェントに「ユーザーを覚える」永続メモリ(long-term memory)を持たせる構成が広がっています。過去のやり取りや好みを会話をまたいで保持できると使い勝手は上がりますが、この「覚える」性質そのものが新しい攻撃面になります。2026年に相次いで公開された研究は、外部の文書やWebページに仕込まれた内容を通じて、エージェントに偽の「記憶」を書き込ませ、後日の別の会話で遅延的に発火させる攻撃を報告しています。いわゆる「スリーパー型のメモリ汚染(sleeper memory poisoning)」です。この記事では、業務でエージェントを使う・運用する立場から、仕組みの理解と防御・運用対策に軸足を置いて整理します。攻撃の再現手順は扱いません。

メモリ汚染とは何か、なぜ「新しい」のか#

多くのLLMエージェントは、会話が終わっても消える短期の文脈だけでなく、ユーザー固有の情報をセッションをまたいで保存する永続メモリを備えつつあります。個人化や継続性のためにこの状態性(statefulness)は有用ですが、同時に「エージェントが覚えている内容そのものを外部から汚せる」という新しいリスクを生みます。

代表的な研究「Hidden in Memory: Sleeper Memory Poisoning in LLM Agents」(arXiv:2605.15338)は、この攻撃を次のように説明しています。攻撃者は文書・Webページ・リポジトリといった外部コンテキストを操作し、エージェントにユーザーに関する「捏造された記憶」を保存させます。同論文の表現を借りると、従来のプロンプトインジェクションと違い、この攻撃は「休眠状態のまま留まり、後の複数の会話で再び現れうる(remain dormant and re-emerge across multiple later conversations)」点が本質的な違いです。つまり、注入した瞬間に効かせるのではなく、正規のメモリとして書き込ませておき、後日の無関係な会話で取得されたときに発火させる、時間差のある攻撃です。

単一ターンのプロンプトインジェクションとの違い#

プロンプトインジェクションは、その場の入力に紛れ込ませた指示でモデルの振る舞いをその場で乗っ取る、単一ターン・即時型の攻撃です。対してメモリ汚染は、書き込み(write)、後の取得(retrieve)、そして取得された記憶による行動誘導(steer)という複数段階のパイプラインを通ります。厄介なのは、汚染が「記憶」として定着した後は、攻撃コンテンツがもう目の前になくても、別の会話で悪影響が再生することです。単一ターンの入力チェックだけでは、この時間差の経路を捕まえきれません。

スリーパー型メモリ汚染の定義とパイプライン(書き込み->取得->行動誘導)、および上記の報告値は arXiv:2605.15338「Hidden in Memory: Sleeper Memory Poisoning in LLM Agents」に基づきます。数値は同論文の実験下の値で、モデル・構成依存かつ変動前提です。

性能と攻撃面はトレードオフになりうる#

もう一つ押さえておきたいのが、メモリ設計の「性能を上げる選択」が「攻撃面を広げる選択」と表裏一体になりうる点です。「From Untrusted Input to Trusted Memory: A Systematic Study of Memory Poisoning Attacks in LLM Agents」(arXiv:2606.04329)は、メモリ汚染を体系的に調べた研究で、たった一度の敵対的な書き込みがエージェントの振る舞いへ長期的な影響を及ぼしうる、と指摘しています。

同研究が示す論点として重要なのは、メモリへ積極的に書き込み・取得するように設計されたエージェントほど、汚染に対して脆弱になりやすいという傾向です。記憶を活発に使うほど個人化や継続性は高まりますが、その分だけ「信頼できない入力が記憶へ昇格する」経路が増えます。加えて同研究は、既存のプロンプトインジェクション対策がメモリ汚染を十分カバーしないとも述べています。ここでも、単一ターン向けの防御をそのまま流用するだけでは足りない、という含意が読み取れます。

メモリのライフサイクルで捉える#

攻撃も防御も、記憶の一生(ライフサイクル)で捉えると整理しやすくなります。「A Survey on Long-Term Memory Security in LLM Agents」(arXiv:2604.16548)は、永続メモリの脅威を書き込み(Write)、保存(Store)、取得(Retrieve)、実行(Execute)、共有・伝播(Share & Propagate)、忘却・巻き戻し(Forget & Rollback)という各段階で捉えるフレームを提示しています。メモリ汚染は、このうち書き込み・保存の段階での「完全性(Integrity)」の侵害にあたると位置づけられます。

同サーベイが強調するのは、堅牢なメモリ安全性は取得時や実行時だけの後付けでは実現できず、保存時の来歴(provenance)・バージョン管理・保持ポリシーといった「入口側」に錨を下ろす必要がある、という考え方です。つまり、汚染された記憶を後段で見つけて弾く発想だけでなく、そもそも信頼できない情報を記憶へ昇格させない設計が要になります。

業務・運用で取れる防御策#

防御は研究段階にあり、有効性は構成に依存します。以下は、上記の研究群や一般的なベストプラクティスから整理した、運用で検討できる多層の対策です。単一の銀の弾丸はなく、組み合わせて低減を図る前提で読んでください。

これらの有効性は研究段階であり、構成やモデルに依存します。たとえば arXiv:2606.24322 は、出所束縛・非可鍛(non-malleable)な権限付与といった手法を提案し、その枠組みで攻撃成功率を大きく下げられたと報告していますが、これも特定の実験環境での結果です。既存の一般的な防御は、汚染を「洗浄」して信頼情報に見せかける経路(laundering)に対して弱い場合があるとも報告されており、防御は単層で完結しないと考えるのが安全です。自社で導入する際は、これらを取り入れつつ、自環境での検証と監視を前提にしてください。

よくある質問#

まとめ#

永続メモリを持つエージェントは、便利さと引き換えに「覚えている内容そのものを汚される」という新しい攻撃面を抱えます。スリーパー型のメモリ汚染は、注入から発火までに時間差があるぶん見えにくく、単一ターン向けの防御だけでは取りこぼしが生じます。とはいえ、現時点で分かっているのは「メモリを使うな」ではなく、「何を・どの由来で・どこまで記憶へ昇格させるかを設計で切り分け、監査と承認を重ねる」という運用の勘所です。数値やベンチに振り回されず、研究段階であることを前提に、可視化・来歴付与・承認ゲート・最小権限・監査という多層の備えを、自環境で検証しながら積み上げていくことが、遅延型の脅威に対する現実的な着地点になります。