長期記憶(メモリ)を持つAIエージェントに、攻撃者がこっそり悪意ある「記憶」を書き込み、後から実行させる――そんな攻撃手法を実証した研究がarXivで公開されました。論文「When Agents Remember Too Much: Memory Poisoning Attacks on Large Language Model Agents」(2026年7月6日投稿、査読前)は、攻撃「GhostWriter」の注入成功率が約98%に達したと報告しています。メールやカレンダー、社内リポジトリを自動操作するAIエージェントの導入を検討している情シスにとって、無視できない新しい攻撃面(アタックサーフェス)です。
この記事でわかること
- 「記憶汚染(メモリ汚染/memory poisoning)」攻撃とは何か、通常のプロンプトインジェクションと何が違うのか
- 研究が示したGhostWriterの仕組みと結果(数値)
- 提案された防御策と、その限界
- 社内でAIエージェント導入を検討する情シスが今から押さえるべき論点
※本記事は査読前(プレプリント)の研究をもとにしています。結果は今後の検証で変わりうるため、1本の論文の数値をそのまま自社環境に当てはめて断定しないようご注意ください。
記憶汚染(メモリ汚染)攻撃とは
記憶汚染攻撃とは、AIエージェントが長期記憶に保存する情報へ悪意ある内容を紛れ込ませ、後の別のやり取りでそれを「正しい事実」として呼び出させて誤動作させる攻撃です。
近年のAIエージェントは、大規模言語モデル(LLM)に「ツールを使う能力」と「長期記憶」を組み合わせています。長期記憶があると、過去のやり取りの要点を覚えておけるため、毎回すべての文脈を渡さなくても済み、効率が上がります。一方で、その記憶に一度でも汚染された情報が入り込むと、セッション(会話)をまたいで悪影響が残り続けるという弱点が生まれます。
通常のプロンプトインジェクションとの違い
プロンプトインジェクションは、外部から渡した文章の中に「これまでの指示を無視して〜せよ」といった命令を紛れ込ませ、その場でLLMをだます攻撃です。OWASPが公開する「Top 10 for LLM Applications(2025)」でも最上位(LLM01)に位置づけられています。
記憶汚染は、これを「時間差」に発展させたものと捉えると分かりやすいでしょう。攻撃の効果がその場限りではなく、汚染された内容が記憶に保存されることで、後日の無関係なタスクでも呼び出されて悪用され得ます。OWASPの「Top 10 for Agentic Applications」でも、エージェント固有のリスクとして「メモリ・コンテキストの汚染(Memory and Context Poisoning)」が挙げられています。
研究が示したこと:GhostWriterの仕組み
論文では、メール・カレンダー・コードリポジトリなど、機微な情報を扱う「パーソナルAIエージェント」を想定した脅威モデルを設定しています。エージェントが信頼できない外部の情報源(受信メールなど)とやり取りする場面に着目し、現状のメモリ管理には安全性の観点が欠けていると指摘しています。
攻撃「GhostWriter」は2段階で構成されます。
| フェーズ | 内容 |
|---|---|
| 注入(Injection) | 攻撃者が、隠した悪意あるペイロードを標的エージェントへ送り込み、記憶に保存させる |
| 発火(Activation) | 保存された汚染メモリが、後のやり取りで呼び出され悪用される |
結果の数値はどれくらいか
論文が報告した主な結果は次のとおりです(査読前の値である点に留意)。
- 注入の成功率:約98%――悪意ある内容を記憶に保存させる段階は、ほぼ成功したとされています。
- 発火(呼び出し・悪用)率:平均で約60%――保存された汚染メモリが、後に実際に呼び出されて悪用された割合です。
論文は、最新のエージェントに対しても攻撃が成立した要因として、セキュリティを意識したメモリ制御(どんな内容を記憶に保存し、どう呼び出すかの検査)が組み込まれていない点を挙げています。
提案された防御策と限界
論文は防御機構「Agentic Memory Sentry(AM-Sentry)」も提案しています。考え方はシンプルで、次の2点です。
- 記憶に保存する段階のポリシー制限:何を記憶として残してよいかにルールを設ける。
- 記憶を呼び出す段階のスクリーニング:保存済みの記憶を使う前に検査する。
論文は、AM-Sentryがエージェントの本来の機能を保ちつつ、GhostWriterの有効性を大きく下げられたと報告しています。ただし、これは提案手法を含む同じ研究チームの実験環境での結果です。査読前であり、対象とした環境やモデルも限られるため、あらゆる製品・構成で同じ効果が出ると一般化はできません。自社での採否は、実際に使うAIエージェント製品の仕様に即して個別に判断する必要があります。
現場目線の課題:導入の勢いに、統制が追いつくか
率直なところ、多くの現場では「便利だから」とAIエージェント系のツールが部門主導で先に入り、情シスが全体像を把握しきれないまま広がっていく――という展開が起きがちです。メールを読ませ、カレンダーを操作させ、コードを書かせる、といった自動化はまさに情シスの業務そのものと親和性が高く、導入の誘惑も強い領域です。
しかし記憶汚染のような攻撃は、「その場で怪しい応答が返る」のではなく、汚染が記憶に静かに残り、後日ふつうの業務の中で発火します。ログを見ても因果関係が追いにくく、限られた人員で異常を検知・切り分けするのは容易ではありません。実際に何が記憶として保存され、どのタイミングで呼び出されているのかは、製品の外からは見えづらいのが現実です。ここに、従来のマルウェア対策やパッチ管理とは違う難しさがあります。
情シスはどうすべきか(公的指針への誘導)
個別の製品仕様に踏み込む前に、まずは生成AI・AIエージェント全般のリスクと基本対策を体系立てて押さえるのが近道です。自前で長大なチェックリストを作るより、公的機関の指針を土台にする方が抜け漏れが少なく、経営層への説明材料にもなります。
- IPA「AIセキュリティ」特設ページ――生成AIの利活用・開発におけるセキュリティの考え方がまとまっています。
- IPA「AI利用者のためのセキュリティ豆知識」――利用者目線の注意点を平易に整理。社内啓発の教材にも使えます。
- OWASP「Top 10 for LLM Applications」――プロンプトインジェクションを含む代表的リスクの整理。エージェント固有のリスクは同プロジェクトのAgentic Applications向け資料も参照。
IPAの「情報セキュリティ10大脅威 2026」では、組織向けに「AIの利用をめぐるサイバーリスク」が初めてランクインしました。AIの安全な利用は、もはや先進的な一部の話ではなく、全社的なポリシー整備と地道な利用者教育が問われるフェーズに入っています。まずは「機微情報を安易に入力させない」「AIの出力を鵜呑みにせず検証する」といった基本を、利用ルールとして明文化することから始めるとよいでしょう。
まとめ
- 記憶汚染(メモリ汚染)は、長期記憶を持つAIエージェントに悪意ある「記憶」を仕込み、時間差で悪用する攻撃。研究「GhostWriter」は注入成功率約98%と報告した(査読前)。
- その場限りのプロンプトインジェクションと違い、汚染がセッションをまたいで残るため、検知・切り分けが難しい。
- まずはIPAのAIセキュリティ指針やOWASPの整理を土台に、利用ルールの明文化と利用者教育から着手するのが現実的。
出典
- George Torres, Sharad Shrestha, Satyajayant Misra「When Agents Remember Too Much: Memory Poisoning Attacks on Large Language Model Agents」arXiv:2607.06595(2026年7月6日、査読前)https://arxiv.org/abs/2607.06595
- IPA「AIセキュリティ」https://www.ipa.go.jp/digital/ai/security/index.html
- IPA「AI利用者のためのセキュリティ豆知識」https://www.ipa.go.jp/digital/ai/security/ai_security_tips.html
- OWASP「Top 10 for LLM Applications」https://owasp.org/www-project-top-10-for-large-language-model-applications/

