LLMエージェントの長期記憶を守る
Mnemonic Sovereignty論文に学ぶメモリポイズニング対策の全体像
LLMエージェントの長期記憶を狙うメモリポイズニング攻撃と、2026年4月公開のサーベイ論文『Mnemonic Sovereignty』が提示するライフサイクル別の防御フレームワークを、実装で参照できるチェックリストに落として解説します。
LLMエージェントを「セッションを超えて学習する」設計に近づけるほど、ひとつの落とし穴が大きくなります。それは長期記憶（long-term memory）の汚染です。会話履歴、ベクターストア、エピソード記憶、共有ワークフロー——そこに一度悪意あるレコードが入り込むと、次回以降のユーザーリクエストが静かに乗っ取られる。従来のプロンプトインジェクションが「1回の実行をハイジャックする一過性の攻撃」だとしたら、メモリ攻撃は「システム状態を持続的に汚染する慢性疾患」に近いものです。
この記事では、2026年4月に公開された arXiv プレプリント A Survey on the Security of Long-Term Memory in LLM Agents: Toward Mnemonic Sovereignty（Zehao Lin、Chunyu Li、Kai Chen、2026年4月17日投稿）を中心に、LLMエージェントの長期記憶を守るための設計観点を整理します。あわせて、クエリだけで記憶を汚染できる攻撃手法 MINJA（Memory INJection Attack、arXiv:2503.03704） も取り上げます。
既存のたきびAIラボ記事は「RAGナレッジ汚染対策」や「MCPツール汚染対策」を扱ってきましたが、本記事はエージェント自身の長期記憶——会話を覚える、過去のタスクから学ぶ、ユーザーの嗜好を保持するための記憶領域——に絞ります。
なお、本記事で参照する論文はいずれも査読前の arXiv プレプリントです。引用する数値・主張は原論文の記述範囲に限定し、論文が直接主張していない性能や安全保証は書きません。
なぜ「長期記憶」の安全性が新しい論点になったのか
LLMエージェントは、ここ1〜2年で「単発の質問に答える」段階から「過去のセッションを思い出しながら継続的にユーザーを助ける」段階へと拡張されてきました。ChatGPTのMemory、Claudeのプロジェクト記憶、LangChain系のメモリストア、独自実装のエピソード記憶など、形態はさまざまですが、共通点はひとつ。過去の入出力を持続的に保存し、将来のプロンプトに自動的に注入することです。
この設計は便利な反面、攻撃面を時間軸に広げます。Lin らのサーベイは、この問題意識を冒頭で次のように整理しています。
従来のプロンプトインジェクションが「単一の実行フローの一過性ハイジャック」に相当するとすれば、長期記憶への攻撃は「システム状態の持続的汚染」に近い。（arXiv:2604.16548 抄訳）
つまり、
- 一過性攻撃: 注入した指示はその場限りで効く。セッションを閉じれば消える。
- 持続的汚染: 注入したレコードが記憶に残り、次回以降のユーザー、時には別のユーザーにも作用する。
特にエンタープライズで「組織共有のエージェント記憶」を持つ設計（ナレッジワーカー全員で1つのアシスタントを使う、など）では、1人のユーザーが踏んだ罠が全社員に波及する可能性があります。これがメモリポイズニングが新しい設計課題として浮上した背景です。
サーベイ論文の中心アイデア：メモリライフサイクル × セキュリティ目標
Mnemonic Sovereignty の最大の貢献は、ばらばらに研究されてきた攻撃・防御をひとつのマトリクスに整理したことです。
著者らはエージェント記憶の扱いを6つのライフサイクル段階に分けています（論文の用語を意訳）。
- Write（書き込み）: 新しい記憶レコードを作成・追加する段階
- Store（保存）: ベクターDBや構造化ストアに保持する段階
- Retrieve（取り出し）: クエリに応じて関連レコードを検索する段階
- Execute（実行）: 取り出した記憶を実際の応答や行動に反映する段階
- Share（共有）: 別エージェント・別ユーザー・別組織へ記憶を伝播する段階
- Forget/Rollback（忘却・巻き戻し）: 不要・不正な記憶を消去または以前の状態に戻す段階
これに4つのセキュリティ目標——Integrity（完全性）、Confidentiality（機密性）、Availability（可用性）、Governance（統制）——を掛け合わせ、各セルに既存研究をマッピングしています。
ここから論文が明らかにしている事実は次の通りです（論文の主張範囲）。
- 既存研究は Write と Retrieve の Integrity に集中している
- Confidentiality（記憶からの情報漏えい）、Availability（記憶の破壊・拒否）、Store/Forget（保存・忘却制御）、良性レコードの永続性 は研究が薄い
- 著者らが定義した「9つのガバナンス基本要素」のすべてをカバーするアーキテクチャはまだ公開されていない
論文はこの状況を踏まえ、「Mnemonic Sovereignty（記憶の主権）」——何を書き込んでよいか、誰が読めるか、いつ更新が許されるか、どの状態を忘れるべきかを、検証可能かつ復旧可能な形で統制できる状態——を目指すべきだと主張しています。
クエリだけで記憶を汚染するMINJA攻撃
Mnemonic Sovereigntyが地図だとすれば、地図のなかでも特に注意すべきセルが「Write段階のIntegrity」です。代表例が MINJA（Memory INJection Attack） です。
論文情報：
- タイトル: Memory Injection Attacks on LLM Agents via Query-Only Interaction
- 著者: Shen Dong、Shaochen Xu、Pengfei He、Yige Li、Jiliang Tang、Tianming Liu、Hui Liu、Zhen Xiang
- 公開日: 2025年3月5日初版、2026年2月12日に最新版
- 状態: arXiv プレプリント（査読状況は時期によって変動するため、最新版を直接確認することをおすすめします）
MINJAの怖さは、攻撃者がメモリストアに直接書き込み権限を持たなくても、通常のユーザーとしてエージェントにクエリを送るだけで悪意あるレコードを記憶に残せる点にあります。
仕組みを大づかみに整理すると次のようになります（詳細は原論文 arXiv:2503.03704 の手法セクションを参照）。
- 攻撃者は、正当に見えるクエリの中に bridging step（橋渡しの推論ステップ） を仕込む
- 同時に、エージェントが「似たような推論を自分で生成する」よう誘導する indication prompt を入れる
- やり取りを重ねるうちに、エージェントの記憶には橋渡し付きの記憶レコードが蓄積される
- 最後に indication prompt を取り除いても、すでに蓄積された記憶が将来のクエリに対して検索ヒットし、悪意ある推論経路が再生される
論文は「多様なエージェントで効果を確認した」と述べていますが、攻撃成功率は実験設定（記憶モジュールの種類、検索器、ターゲットタスク）に依存するため、報告値をそのまま自社環境に当てはめてはいけません。「クエリ専用、観測可能な出力のみ、というハードルの低さで記憶汚染が成立しうる」という質的な事実を実装側の前提とするのが安全な読み方です。
ここで重要なのは、MINJAのようなクエリ専用攻撃は従来のRAGナレッジ汚染対策（ドキュメント投入時のスキャン、ソース検証）では捕まえにくいという点です。記憶レコードはユーザーとエージェントの正常な対話から生まれるため、外部ファイルのスキャンや署名検証ではフィルタリングできません。詳細は後述のチェックリストで触れます。
実装で参照するメモリ・セキュリティ・チェックリスト
ここからは、エージェント記憶を扱う実装担当者向けに、Mnemonic Sovereigntyのライフサイクル6段階に沿った実務での確認ポイントを整理します。論文が直接「これを実装せよ」と書いているわけではない箇所もありますので、論拠は段階ごとに明示します（各防御手法はサーベイ内で参照されている個別研究や、関連研究 Design Patterns for Securing LLM Agents（arXiv:2506.08837）、DRIFT（arXiv:2506.12104） から要素を抽出しています）。
1. Write（書き込み）
- ユーザー入力・エージェント出力をそのまま記憶に書き込まない。最低限、「記憶に残す候補」と「破棄」の二値判定を入れる
- システムプロンプトとユーザー入力の出処を明示的にタグ付けし、記憶レコードのメタデータとして残す（出処不明レコードは取り出し時に低スコア化）
- MINJA対策として、**長すぎる橋渡し推論や、外部から指示された“将来クエリで思い出すための鍵”**を疑う検査ルールを設ける
2. Store（保存）
- ベクターDBには最小権限でアクセスする。エージェントランタイムが書き込みできるネームスペースを限定する
- 記憶レコードは追記＋論理削除で管理し、改ざんが起きても監査で巻き戻せるようにする
- 機密度の高いエージェント（経理・人事・SOC補助など）は個人別パーティションを作り、ユーザー間で記憶が混ざらない設計にする
3. Retrieve（取り出し）
- 取り出し時に信頼スコアを併用する。出処メタデータ、レコード齢、書き込み時の検査結果を入力に組み合わせる
- DRIFT（arXiv:2506.12104）が示すように、ユーザーの現クエリと矛盾する命令を含む記憶は、Injection Isolator のように「実行に渡す前にマスク・要約する」レイヤーで隔離する
- 検索結果の上位 N 件をそのまま LLM に渡さず、**「ユーザータスクと整合する記憶か」**を別段の LLM 呼び出しで二段審査する設計も検討する
4. Execute（実行）
- Design Patterns for Securing LLM Agents（arXiv:2506.08837）が強調するように、エージェントの実行可能アクションを明示的に制限する。記憶が汚染されても、できることが限定されていれば被害は抑えられる
- 高リスク操作（送金、外部送信、権限昇格）は人間の確認または事前承認テンプレートを挟む。記憶からの提案だけで起動させない
- ツール呼び出しの引数をホワイトリストで制約し、自由文字列のまま eval / shell に渡さない（ここはツール側の最小権限設計の話になります。詳しくは LLM Excessive Agencyと最小権限 を参照）
5. Share（共有）
- 「複数ユーザーで共有する記憶」は読み取り専用のスナップショットとして配り、書き込みは管理者がレビューしたレコードに限る
- 別エージェントへ記憶をエクスポートするときは、機密度ラベルと出処メタデータを併送し、受け取り側で再評価する
- 監査ログにエクスポート・インポートのトレースを残す（後の Forget/Rollback でも使える）
6. Forget / Rollback（忘却・巻き戻し）
- ユーザーや管理者が「特定レコードの削除」「特定期間の記憶ロールバック」を要求できる API を最初から設計に入れる（後付けは難しい）
- 不正レコードが見つかった場合、個別削除＋影響範囲の再検索（そのレコードが影響したセッションの洗い出し）を運用フローに含める
- GDPR や個人情報保護の「忘れられる権利」とも整合させる
プロンプト例：エージェント設計レビューで使うチェック質問
実装担当者がエージェント設計をレビューするときに、LLMアシスタント（Claude／ChatGPT／Gemini）に貼って使えるプロンプト例です。Mnemonic Sovereigntyのフレームワークをそのまま反映しています。
あなたはLLMエージェントのセキュリティレビュアです。以下の設計について、
Mnemonic Sovereignty フレームワークの6段階（Write / Store / Retrieve /
Execute / Share / Forget）と4目標（Integrity / Confidentiality /
Availability / Governance）を表形式で評価してください。
【設計概要】
- ユースケース: <例：社内ナレッジ補助、SOCアシスト>
- 記憶モジュール: <例：ベクターDB（pgvector）＋エピソード記憶＞
- 書き込みトリガー: <例：会話終了時に要約レコード生成>
- 取り出しトリガー: <例：ユーザー発話ごとに top-5 検索>
- 共有範囲: <例：チーム内共有、個人別、組織共有>
評価軸ごとに、(a) 現状で実装されている対策、(b) 不足している対策、
(c) MINJA のようなクエリ専用攻撃に対する耐性、を 3 行以内で述べ、
最後に優先度の高い改善案を 3 件、根拠とともに提案してください。
論文が主張していない性能保証は書かないでください。このプロンプトの狙いは、レビュー観点をライフサイクル全体に強制的に広げることです。実務では「Write の Integrity」だけ気にしてしまいがちなので、Forget / Rollback や Share といった軽視されがちな段階まで議論を引き上げる効果があります。
論文の限界と、過信しないための読み方
最後に、本記事で取り上げた論文を正しく薄目で見るためのポイントを残します。
- Mnemonic Sovereignty はサーベイ論文であり、提示しているのは枠組みと未開拓領域の地図です。新しい防御技術のベンチマーク勝者を選んでいるわけではありません
- MINJA を含む攻撃論文の成功率は、論文中の実験設定（特定の記憶モジュール、特定のターゲットタスク）に依存します。自社のエージェントが同等以上に堅牢／脆弱であるとは限りません
- いずれも査読前の arXiv プレプリントです。引用時は、最新版・採録状況・関連する公式実装の有無を必ず確認してください
- 論文は「Confidentiality・Availability・Forget は研究が薄い」と述べています。逆に言えば、ここに自社の運用要件で踏み込む場合、参考にできる先行研究が少ないため、設計判断を文書化し、運用で検証する責任は実装側に残ります
セキュリティ対策は「論文の手法を1つ採用すれば安全」というものではありません。Mnemonic Sovereigntyのフレームワークは抜け漏れを発見するための地図として使い、個別の防御は段階ごとに自社要件に合うものを選び取る——という姿勢が現実的です。
よくある質問
クリックで展開。
ChatGPTやClaudeのMemory機能を使うだけのユーザー側でも、メモリポイズニングは気にすべきですか？
エンドユーザー単体での被害は限定的ですが、共有ワークスペースで誰かのMemoryが他者の応答に影響する設計の場合は注意が必要です。実務上は、機密性の高いプロンプトや個人情報をMemoryに残さない、定期的にMemoryの内容を見直す、というシンプルな運用で多くのリスクは下げられます。
既存のRAGナレッジ汚染対策とどう違うのですか？
RAGナレッジ汚染対策は「投入されるドキュメント側」を守る話が中心で、ファイル投入時のスキャンや署名検証が有効です。一方、長期記憶へのクエリ専用攻撃（MINJAなど）はユーザーとエージェントの正常な対話から記憶が生まれるため、ドキュメントスキャンでは捕まりません。「取り出し時の信頼スコア」「実行前の二段審査」「忘却APIの設計」など、別のレイヤーの対策が必要です。
自社のエージェントにすぐ取り入れられる優先順位は？
最初に着手しやすいのは、(1) 記憶レコードへの出処メタデータ付与、(2) 高リスクツール呼び出しへの人間確認、(3) 個別レコード削除APIの実装、の3つです。これらは Mnemonic Sovereignty の Write / Execute / Forget に対応し、後付けが難しい設計要素を先に押さえられます。
論文を読むときの順番のおすすめは？
まずサーベイ（arXiv:2604.16548）で全体像とライフサイクル分類を頭に入れ、そのうえで攻撃側 MINJA（arXiv:2503.03704） と防御側 DRIFT（arXiv:2506.12104） を読むと、議論の位置関係がつかみやすくなります。
関連記事
- 社内RAGのナレッジポイズニング対策ガイド — RAGの入力ドキュメント汚染に焦点。本記事の「Write 段階・外部ソース由来」を補完する位置付け
- MCPツールポイズニング対策 — ツールチェーン経由の汚染。本記事の Execute 段階での権限制約と連動して読むと効果的
- LLM Excessive Agencyと最小権限設計 — Execute 段階で参照する権限設計の基礎
- AgentDojo論文解説 — エージェントのプロンプトインジェクション耐性を評価する別系統のベンチマーク
参考リンク
- A Survey on the Security of Long-Term Memory in LLM Agents: Toward Mnemonic Sovereignty (arXiv:2604.16548)
- Memory Injection Attacks on LLM Agents via Query-Only Interaction (arXiv:2503.03704)
- Memory Poisoning Attack and Defense on Memory Based LLM-Agents (arXiv:2601.05504)
- Design Patterns for Securing LLM Agents against Prompt Injections (arXiv:2506.08837)
- DRIFT: Dynamic Rule-Based Defense with Injection Isolation (arXiv:2506.12104)
次に読むおすすめ
LLMエージェントのセキュリティ設計は、論文の枠組みを実装に落とし込んだあとも、社内のレビュー観点や運用ナレッジの整理が必要になります。たきびAIラボでは、ブログ本体では扱いきれない「実務で気づいた小さな運用上のコツ」を、運営者のnoteでも継続的に発信しています。設計レビューや社内勉強会のたたき台にお使いください。