メモリポイズニングとは｜AIエージェントの記憶を狙う2026年の脅威と防御策

本記事では、AIエージェントの永続的な記憶を狙う「メモリポイズニング」について、定義から防御の実装までを体系的に解説します。会話履歴やRAG索引に不正な情報を埋め込み、その後の判断やツール呼び出しを操作するこの攻撃は、2026年にMicrosoftやPalo Alto Networksの研究で実害が確認され、OWASPの最新フレームワークでも独立した脅威として位置づけられました。データポイズニングやプロンプトインジェクションとの違い、2026年に表面化した実事例、そしてメモリ入出力の検証を軸とした多層防御まで、AIエージェントを導入・内製する企業が押さえるべき要点を整理します。

メモリポイズニング対策の全体像と運用定着に向けた次の一歩

メモリポイズニングは、AIエージェントの永続的な記憶を狙い、推論から実際のツール操作までを時間差で歪める攻撃です。データポイズニングが学習段階を、プロンプトインジェクションが単発の入力を狙うのに対し、本攻撃は運用中の記憶を汚染し、被害がセッションを越えて残る点に特徴があります。2026年にはMicrosoftやPalo Alto Networks、Ciscoの研究で実害が確認され、MITRE ATLASの AML.T0080、OWASPのASI06として正式に分類されました。

防御の中核は、記憶への入出力を検査するI/Oゲーティングと、テナント分離・来歴追跡・未検証データの失効という基本統制の組み合わせです。導入を検討する企業は、まず記憶アーキテクチャを棚卸しし、信頼境界と権限を定義し、OWASP ASIを社内基準へマッピングするところから着手するとよいでしょう。次の一歩として、自社のエージェントがどの記憶領域を永続化しているかを洗い出し、そこに検査層を設けられるかを確認することをおすすめします。

メモリポイズニングの定義と永続記憶がもたらすAIエージェント固有のリスク

メモリポイズニングを正しく対策するには、まず「何が」「どこを」狙われるのかを明確にする必要があります。ここでは定義と、AIエージェント特有の記憶構造が生む固有のリスクを整理します。

外部からの不正な指示や事実が記憶へ注入される攻撃という定義

メモリポイズニングとは、外部の攻撃者がAIアシスタントの記憶に不正な指示や「事実」を注入し、汚染された内容を正規のユーザー設定であるかのように扱わせる攻撃を指します。Microsoftのセキュリティチームは、一度汚染されると注入された指示を正当な好みとして信頼し続ける点に本質があると説明しています。重要なのは、攻撃者が一度きりの応答を歪めるのではなく、エージェントが後から繰り返し参照する記憶そのものを書き換える点です。これにより、攻撃の効果は単発の会話を超えて持続します。

学習時のデータポイズニングと運用時メモリ汚染を分ける2つの判断軸

混同されやすい「データポイズニング」と区別する判断軸は、汚染が起きるタイミングと対象です。データポイズニングはモデルの学習・微調整の段階で訓練データを汚染し、モデル自体を作り変えます。一方メモリポイズニングは、すでに運用中のエージェントが保持する記憶（実行時の状態）を汚染します。前者の対策はデータパイプラインとモデル供給網に向き、後者の対策は実行時のメモリ入出力に向きます。この2軸を取り違えると、訓練側を固めても運用側が無防備なまま残るという見落としが生じます。

単発の応答では消えず複数セッションに残る永続性という危険性

メモリポイズニングが従来のプロンプトインジェクションより厄介なのは、汚染が複数のセッションやエージェントをまたいで残る永続性にあります。OWASPは、汚染されたコンテキストが時間とともに深く埋め込まれ、複数のセッションやエージェントに影響しうると指摘しています。たとえば共有メモリを持つ複数エージェント構成では、一体に注入された偽情報や隠し命令が、連携する他のエージェントへ伝播します。記憶は再起動で消えないため、攻撃者は「仕掛けて待つ」ことが可能になります。

推論・計画・ツール呼び出しが歪む3段階の影響波及パターン

汚染された記憶は、エージェントの動作を3つの段階で歪めます。第一に推論で、誤った前提に基づいて状況を解釈します。第二に計画で、歪んだ推論をもとに不適切な手順を組み立てます。第三にツール呼び出しで、外部APIやコマンドを誤った引数で実行します。エージェントはツールを介してインフラやデータに直接作用するため、最終段階での誤りは情報漏えいや不正操作に直結します。単なる出力の誤りでは済まない点が、エージェント固有の危険性です。

MITRE ATLAS「AML.T0080」が示すメモリポイズニングの正式な位置づけ

メモリポイズニングは、AIシステムへの攻撃を体系化したMITRE ATLASの知識ベースで AML.T0080: Memory Poisoning として正式に分類されています。MITREはこれをAIエージェントのコンテキスト汚染として整理しており、特定の企業やサービスを「信頼できる」「優先すべき」とエージェントに思い込ませる手口を含みます。フレームワーク上の正式な技術IDが付与されたことは、この脅威が研究上の仮説ではなく、対策を要する実在のリスクとして認知された節目を意味します。

会話履歴やRAGに汚染が侵入する経路とエージェントが偽情報を信頼する仕組み

攻撃を防ぐには、汚染がどの記憶領域に、どの経路で侵入するのかを把握することが出発点になります。ここでは記憶の所在と主要な侵入経路、そしてエージェントが偽情報を信頼してしまう構造を解説します。

会話履歴・ベクトルDB・スクラッチパッド・RAG索引という4つの記憶領域

AIエージェントの「記憶」は単一ではなく、複数の領域に分散します。代表的なのは、会話履歴、ベクトルデータベースに格納された埋め込み、作業中の一時メモ（スクラッチパッド）、そしてRAG（検索拡張生成）の索引です。これらはセッションをまたいで保持され、エージェントが次の実行時に読み戻す前提で設計されています。攻撃者の視点では、このいずれか一つに不正なテキストを書き込めれば足ります。防御側は、どの領域が永続化され、誰が書き込めるのかを領域ごとに把握する必要があります。

URLパラメータで指示を埋め込むワンクリック型の侵入経路

実用的な侵入経路の一つが、URLパラメータを使った指示の埋め込みです。多くのAIアシスタントは、URLのパラメータであらかじめプロンプトを差し込める仕様を備えています。攻撃者はWebやメールに、悪意ある指示を仕込んだリンクを置きます。利用者がそれをクリックすると、隠されたパラメータ経由でアシスタントが指示を解釈し、記憶を操作します。Microsoftはこれを、利用者の一度のクリックで成立する現実的な攻撃経路だと指摘しています。特別な技術がなくとも実行できる点が、この経路の危険性を高めています。

文書・メール・Webページに潜む埋め込みプロンプトという侵入経路

もう一つの経路は、文書・メール・Webページに隠した埋め込みプロンプトです。エージェントがこれらのコンテンツを処理する過程で、本文に紛れた指示を「読むべき内容」として取り込んでしまいます。これは間接的プロンプトインジェクションと呼ばれ、利用者が直接入力しなくても成立します。たとえば要約のために読み込ませた一見無害なPDFに指示が埋め込まれていれば、エージェントはそれを正規の入力として記憶に書き込みます。入力経路が「人の入力」に限られない点が、従来型の防御を無効化します。

記憶に書き込まれた内容を特権入力として読み戻す信頼の構造

なぜ偽情報が信頼されるのか。その核心は、記憶に書き込まれた内容が、後からエージェントにとっての「特権的な入力」として読み戻される構造にあります。OWASPのASI06解説では、いったん記憶に入った攻撃者由来のコンテンツを、システムが時間をかけて信頼し続けてしまう点が問題だと述べられています。エージェントは記憶を、自らが過去に確認した正しい情報として扱うため、外部入力に対する警戒を働かせません。信頼境界の内側に偽情報が紛れ込むことが、攻撃成立の前提条件です。

テナント間で記憶が漏えいするマルチテナント構成の失敗パターン

共有基盤で複数の顧客や利用者を扱うマルチテナント構成では、記憶の分離不全が典型的な失敗パターンになります。2026年4月に公表されたSpring AIの脆弱性群では、会話IDを介したテナント間の記憶漏えい（CVE-2026-40966）が報告されました。あるテナントの記憶が別のテナントから参照・汚染できる状態は、被害を一気に拡大させます。記憶領域をテナント単位で確実に区切ること、識別子の取り扱いを厳格にすることが、設計段階での前提になります。

データポイズニング・プロンプトインジェクションとの違いと脅威分類上の位置づけ

対策方針を決めるには、近接する脅威との違いを正確に押さえ、各フレームワークでの位置づけを理解しておく必要があります。ここで3つの脅威を比較し、分類上の整理を行います。

攻撃対象・タイミング・永続性で整理する3つの脅威の比較観点

メモリポイズニング、データポイズニング、プロンプトインジェクションは混同されがちですが、攻撃対象・発生タイミング・永続性で整理すると違いが明確になります。

この整理により、自社の防御がどの脅威に対応し、どこが手薄かを切り分けられます。三者は排他的ではなく、プロンプトインジェクションが記憶に書き込まれてメモリポイズニングへ移行するなど、連続的につながる点にも注意が必要です。

訓練データを狙うデータポイズニングとの混同を避ける判断基準

データポイズニングとの混同を避ける判断基準は、「いつ汚染が起きるか」です。データポイズニングは公開データや微調整パイプラインを通じてモデル自体を作り変え、その影響は展開後も長く残ります。これに対しメモリポイズニングは、完成済みのモデルはそのままに、運用中のエージェントが参照する記憶を書き換えます。Microsoftは前者をモデルポイズニング、後者をメモリポイズニングとして別個に研究対象としています。対策チームを分けるか連携させるかは、この区別を起点に決めるべきです。

単発のプロンプトインジェクションが永続化する境界線

プロンプトインジェクションとの境界線は「残るか、残らないか」です。通常のプロンプトインジェクションは、その場の応答を操作するだけで、会話が終われば効果も消えます。しかし注入された指示がエージェントの長期記憶やRAG索引に書き込まれた瞬間、それはメモリポイズニングへと性質を変えます。Ciscoが「MemoryTrap」と名付けた事例は、ありふれた開発作業が持続的なプロンプトインジェクションへ転じる経路を示しました。一過性の入力操作が永続的な汚染に化ける境界を、設計時に意識する必要があります。

OWASP「ASI06 メモリ＆コンテキストポイズニング」が独立項目化した背景

OWASPは2025年12月に「OWASP Top 10 for Agentic Applications（2026年版）」を公開し、メモリ＆コンテキストポイズニングを「ASI06」として独立した項目に位置づけました。これは自律的に動くAIエージェントを対象とした、査読を経た初のフレームワークとされ、100名超の専門家が関与し、NISTやMicrosoft、NVIDIAなどが支持しています。従来のLLM向けガイドが単発の推論を前提としていたのに対し、永続的な記憶という新たな攻撃面を正面から扱った点が、独立項目化の背景にあります。

旧来の「LLM04 データとモデルのポイズニング」との守備範囲の違い

混乱を避けるため、旧来の「LLM04: データとモデルのポイズニング」との守備範囲の違いも押さえておきます。LLM04はモデルレベルの脆弱性、すなわち訓練データやモデルそのものの汚染を主眼に置きます。一方ASI06は、エージェントが自律・ツール連携・複数エージェント協調・永続状態を持つことで生じる、実行時の記憶汚染を扱います。エージェントシステムはLLMのリスクをすべて引き継いだうえで、新たなリスク群を上乗せします。両者は競合せず、対策範囲を補完し合う関係にあると理解するのが適切です。

2026年に表面化したAI推薦汚染など実被害事例と研究が示す攻撃の実態

脅威の深刻さは、研究と実被害の双方で裏づけられています。ここでは2026年に表面化した代表的な事例を取り上げ、攻撃が現実の問題であることを確認します。

Microsoftが報告した31社・14業種に及ぶAI推薦汚染の実態

Microsoftの脅威インテリジェンスは2026年2月、AI推薦汚染（AI Recommendation Poisoning）と呼ぶ手口の実態を報告しました。約2か月の観測期間で、14業種にまたがる31社が、AIアシスタントの記憶に隠し指示を仕込んでいたことが確認されています。特徴的なのは、攻撃者が国家支援のハッカーではなく、自社を有利に推薦させたい一般企業のマーケティング部門だった点です。この手口は、検索エンジンを狙うSEOポイズニングのAI版とも言える構図です。

「Summarize with AI」ボタンを悪用した記憶操作という具体的手口

報告された具体的な手口は、Webページに置かれた「Summarize with AI（AIで要約）」ボタンの悪用です。ボタンのリンク先URLには、特定企業を推奨させる指示が忍ばせてあります。利用者がボタンを押すと、その指示がアシスタントの永続記憶に静かに書き込まれ、以降の推薦が偏ります。Cloud Warsが紹介した例では、ある企業のCFOが数週間前に押したボタンが原因で、AIが架空のクラウド事業者を強く推奨し、多年契約の判断を歪めた筋書きが示されています。人の懐疑心を介さず判断を操作する点が、この手口の核心です。

Palo Alto Unit 42が実証した長期記憶への持続的汚染のPoC

研究側でも実証が進んでいます。Palo Alto NetworksのUnit 42は、間接的プロンプトインジェクションによってAIの長期記憶が汚染されることを示し、Amazon Bedrock Agentsの記憶機能を題材にした概念実証（PoC）を公開しました。ここでは、汚染された記憶が会話の終了後も残り、後続の挙動を持続的に左右する様子が確認されています。攻撃者が能動的に介入し続けなくても、仕込まれた汚染が時間差で発動する「待ち伏せ型」の性質が、実機に近い環境で裏づけられた点に意味があります。

Cisco「MemoryTrap」が示した開発ワークフロー経由の汚染

2026年5月には、CiscoのAIセキュリティ研究者が「MemoryTrap」と呼ぶ脆弱性を報告しました。これは開発支援AIであるClaude Codeをめぐる事例で、ごく日常的な開発作業が持続的なプロンプトインジェクションに転じる経路を明らかにしたものです。リポジトリを複製し、エージェントに作業を手伝わせ、依存パッケージの導入を承認するという普通の流れの中に、汚染の起点が潜んでいました。OWASP ASI06の項目リードを務めるCiscoの研究者は、エージェントが未検証の入力を「持ち越す」ことの危うさを、この事例で具体的に示しています。

Spring AIの脆弱性公表に見るベクトルストアとテナント越え漏えい

実装フレームワーク側の脆弱性も相次いでいます。2026年4月、Spring AIの開発者はこの領域で5件のCVEを公表しました。内容には、ベクトルストアに対するフィルタ式やドキュメントID注入（CVE-2026-40967 / CVE-2026-40978）、および会話IDを介したテナント間の記憶漏えい（CVE-2026-40966）が含まれます。また独立した研究では、悪意ある埋め込みによって検索結果を約80%の確率で乗っ取れることが示されました。記憶やRAGの基盤コンポーネント自体が攻撃面になる現実が、具体的な脆弱性番号とともに明らかになっています。

メモリ入出力の検証を中核とした多層防御と検出・監視体制の設計

脅威の構造と実態を踏まえ、ここからは防御の実装に移ります。中核となるのは、記憶への書き込みと読み出しを検査するという考え方です。

記憶への書き込みと読み出しを検査するI/Oゲーティングの設計

防御の中核は、エージェントと記憶ストアの間に検査層を置く「I/Oゲーティング」です。これは、記憶へのすべての書き込みと読み出しを、検出器とポリシーのパイプラインを通して審査する設計を指します。書き込み時には注入された指示や疑わしい内容をブロックし、読み出し時には汚染された記憶がそのまま推論へ流れ込むのを防ぎます。エージェント本体に手を入れず、記憶との境界に防御を集約できる点が利点です。記憶を「無条件に信頼する内部データ」ではなく「検査対象の入力」として扱う発想の転換が前提になります。

データ来歴を追跡しテナント単位で記憶を分離する3つの基本統制

OWASPがASI06の緩和策として挙げる基本統制は、大きく3つです。第一に、記憶をテナント単位で分離し、他者の記憶に触れられないようにすること。第二に、未検証のデータには有効期限を設け、無期限に残さないこと。第三に、データの来歴（プロブナンス）を追跡し、各情報が「いつ・どこから・誰によって」書き込まれたかを記録することです。来歴が分かれば、汚染源の特定と影響範囲の切り分けが容易になります。これらは個別の機能ではなく、組み合わせて初めて効果を発揮します。

未検証データに有効期限を設けて汚染の残留を断つ運用基準

永続性こそがこの攻撃の本質である以上、「残さない」ことは強力な対策になります。具体的には、検証を経ていない記憶に有効期限（TTL）を設定し、一定期間で自動的に失効させる運用基準が有効です。これにより、仮に汚染が成立しても、時間差で発動する前に消える可能性が高まります。重要な記憶だけを検証済みとして永続化し、それ以外は短命に扱うという二段構えが、残留リスクと利便性のバランスを取ります。何を長期保持するかの判断基準を、あらかじめ明文化しておくことが運用の要点です。

OWASP「Agent Memory Guard」を参照実装とした検出パイプライン

ASI06に対する具体的な実装の指針として、OWASPは2026年に「Agent Memory Guard」という参照実装を公開しました。これはエージェントと記憶ストアの間に位置するオープンソースの実行時防御層で、すべての読み書きを5つの検出カテゴリとYAMLポリシーで審査します。リスク定義だけでは不足しがちな「実際にどう守るか」を、コードとして示した点に価値があります。自社で一から検出ロジックを組む前に、こうした参照実装の検出観点を出発点として取り入れることで、設計の抜け漏れを減らせます。

異常検知と読み戻し時の整合性検証による継続監視の体制

入口の防御に加え、継続的な監視も欠かせません。記憶の読み戻し時に整合性を検証し、過去の記録と矛盾する内容や、急に現れた不審な指示を異常として検知する体制を組みます。実装の進め方としては、次の流れが基本になります。

1. 記憶への書き込み・読み出しを監査ログとして記録する
2. テナントや情報源ごとに正常な振る舞いの基準を定義する
3. 基準から外れた読み戻しを検知し、隔離・通知する

監視は一度きりの設定で終わらせず、攻撃手口の変化に合わせて基準を更新し続けることが前提です。検知したインシデントの内容を基準へ反映する循環を回すことで、防御は時間とともに強くなります。

日本企業がエージェント導入時に踏むべきガバナンスと実装チェック項目

最後に、これらの知見を日本企業の現場でどう運用に落とし込むかを整理します。導入前の棚卸しから、ベンダー選定の確認項目までを実務目線でまとめます。

導入前に記憶アーキテクチャを棚卸しする最初の判断ポイント

AIエージェントの導入や内製を検討する企業がまず行うべきは、記憶アーキテクチャの棚卸しです。どこに記憶が保存され（会話履歴・ベクトルDB・RAG索引など）、どれが永続化され、誰が書き込めるのかを一覧化します。この棚卸しを飛ばすと、防御の対象範囲そのものが曖昧になり、後続の対策がすべて手探りになります。特に、外部から取り込んだコンテンツが記憶に書き込まれる経路があるかどうかは、最初に確認すべき判断ポイントです。可視化されていない記憶領域は、そのまま無防備な攻撃面になります。

信頼境界とアクセス権限を定義する設計レビューの実務手順

棚卸しの次は、信頼境界とアクセス権限の定義です。設計レビューでは、次の手順で進めると抜けが生じにくくなります。

1. 各記憶領域について、信頼できる入力源と信頼できない入力源を線引きする
2. 信頼できない入力が記憶へ直接書き込まれる経路を洗い出し、検査層を挟む
3. 記憶への読み書き権限を、エージェントやツールごとに最小限へ絞る
4. 外部ツールやMCP接続を、明示的な許可リスト方式で限定する

人間向けに設計された権限管理は、エージェントには通用しません。エージェントを「広い権限と速い処理を持つが、懐疑心を持たない利用者」と見なして権限を設計することが要点です。

OWASP ASI Top 10を社内基準へ落とし込むマッピングの進め方

個別対策を場当たり的に行うのではなく、OWASP ASI Top 10を社内のセキュリティ基準へマッピングする進め方が有効です。ASI01からASI10までの各リスクについて、自社のエージェントが該当するか、該当する場合に既存の統制で十分かを評価します。メモリポイズニング（ASI06）だけを単独で見るのではなく、ツール誤用や権限濫用といった隣接リスクと併せて点検することで、汚染が連鎖する経路も把握できます。フレームワークを共通言語にすれば、開発・運用・経営の間で議論の土台がそろいます。

インシデント発生時に記憶を隔離・ロールバックする運用設計

予防だけでなく、汚染が成立した後の対応も設計に含めます。インシデント時には、汚染が疑われる記憶を速やかに隔離し、検証済みの状態へロールバックできる仕組みが必要です。前述の来歴追跡が整っていれば、いつの時点から汚染が始まったかを特定し、その後に書き込まれた記憶だけを取り消せます。記憶を不可逆な単一の塊として持つのではなく、復元点を持つ更新履歴として管理しておくことが、被害の封じ込めを左右します。復旧手順は事前に手順書化し、訓練しておくべきです。

ベンダー・MCPツール選定時に確認すべきセキュリティ要件

外部のエージェント基盤やMCPツールを採用する際は、記憶の安全性に関する要件を選定基準に含めます。確認すべき主な観点は次のとおりです。

• 記憶がテナント単位で分離され、他者から参照・汚染されない設計か
• 記憶への書き込み・読み出しを検査・記録する仕組みがあるか
• 未検証データの有効期限や失効の制御が可能か
• OWASP ASIやMITRE ATLASといった標準に沿った対策を公表しているか

これらに明確に答えられないベンダーは、記憶の安全性を設計に織り込んでいない可能性があります。選定段階での確認が、導入後の手戻りを防ぎます。

メモリポイズニングに関するよくある質問

メモリポイズニングについて、実務でよく寄せられる疑問に簡潔にお答えします。

メモリポイズニングとデータポイズニングは何が違うのですか？

汚染が起きるタイミングと対象が異なります。データポイズニングはモデルの学習・微調整の段階で訓練データを汚染し、モデル自体を作り変えます。メモリポイズニングは、すでに完成したモデルを運用するエージェントが保持する記憶（会話履歴やRAG索引など）を、運用中に汚染します。前者の対策はデータ供給網と学習基盤に、後者の対策は実行時のメモリ入出力に向きます。両者は別個のリスクであり、対策の所在も分かれます。

RAGを使っていればメモリポイズニングは防げますか？

防げるとは限りません。むしろRAGの索引やベクトルデータベースは、メモリポイズニングの主要な標的の一つです。エージェントは検索で取り出した内容を信頼して読み込むため、索引に不正なデータが紛れ込めば、そのまま汚染が成立します。RAGの導入自体は対策ではなく、索引へ書き込める経路の検証、データの来歴管理、テナント分離といった統制を併せて講じる必要があります。

個人向けAIアシスタントでもメモリポイズニングの被害は受けますか？

受けます。Microsoftが2026年に報告した「AI推薦汚染」は、まさに個人や一般利用者が使うアシスタントを標的にした事例でした。「AIで要約」ボタンの付いたリンクをクリックしただけで、アシスタントの記憶に推薦を偏らせる指示が書き込まれる手口です。心当たりのないリンクからアシスタントを起動しない、記憶機能の保存内容を時々見直すといった基本的な注意が、個人レベルでの防御になります。

メモリポイズニングはMITRE ATLASやOWASPでどう分類されていますか？

MITRE ATLASでは AML.T0080: Memory Poisoning という技術IDで分類されています。OWASPでは、2025年12月公開の「OWASP Top 10 for Agentic Applications（2026年版）」において「ASI06: メモリ＆コンテキストポイズニング」として独立した項目に位置づけられました。なお、訓練データやモデル自体の汚染は、別途「LLM04: データとモデルのポイズニング」で扱われます。これらの標準を共通言語にすると、社内での対策議論が整理しやすくなります。

自社でAIエージェントを内製する場合、最初に何から対策すべきですか？

まず記憶アーキテクチャの棚卸しから始めることをおすすめします。会話履歴・ベクトルDB・RAG索引など、どこに何が永続化され、誰が書き込めるのかを可視化します。そのうえで、外部から取り込んだコンテンツが記憶へ書き込まれる経路に検査層（I/Oゲーティング）を設け、テナント分離と来歴追跡を組み込みます。OWASPの参照実装「Agent Memory Guard」の検出観点を出発点にすると、設計の抜け漏れを減らせます。