AIエージェントの記憶を汚染させない｜保存前検証・tenant分離・期限・出所を分ける設計【2026】

会話をまたいで「好みを覚える」「前回の調査を使う」AIエージェントは便利です。一方で、Webページ、tool出力、利用者入力に混ざった命令文を長期記憶へ書くと、次回以降もmodelの判断材料になります。これがmemory poisoning（記憶汚染）の厄介さです。

結論は、記憶を文章の箱ではなく、出所・権限・期限を持つ、将来のuntrusted input（信用しない入力）として設計することです。保存前検証、user/tenant/sessionの分離、読出し時の再認可、保持期限を別々に置きます。

「記憶に書く」と「次回の命令に渡す」を分離する

OWASPは、agent memoryに悪意あるデータが永続化され、将来sessionや他利用者へ影響することをmemory poisoningとして挙げます。問題は、攻撃者らしい文だけではありません。modelが作った誤要約、古い業務ルール、toolが返した未検証の自然言語も、次回にはもっともらしい前提になります。2026年の研究でも、queryだけで長期記憶を汚染し将来の応答を変え得ること、少数のpoisoned recordが経験検索の大部分を占め得ることが報告されています。ただし、研究の成功率を自社製品の侵害確率として転用してはいけません。構成、retrieval、攻撃者の権限は異なります。

最小の対策は、書込み対象を三つに分けることです。第一にsession scratchpadは、今の実行だけに使い、短いTTL（保持期限）で消す。第二にuser preferenceや継続タスクは、利用者が明示した事実だけを構造化して保存する。第三に共有の業務知識は、会話から自動昇格させず、承認済みのsource revisionを持つ文書として管理します。いずれも「保存した本文」をsystem instructionへ昇格させず、retrieval後も引用付きの参考情報として渡します。

保存時は候補化し、検証を飛ばさない

エージェント、tool、利用者のいずれもmemory storeへ直接writeさせません。candidate → deterministic validation → policy判定 → commitという短い経路にします。候補には本文だけでなく、少なくともtenant_id、user_idまたは共有scope、session_id、source種別、作成者、作成時刻、TTL、機密区分、source revisionを付けます。モデル自身が返したtenant_idや「管理者が承認済み」という文字列は使わず、認証済みsessionから付与します。

validationは万能な危険語フィルタではありません。型・最大長・許可した保存先・個人情報やcredentialらしさ・明示的な保存同意を機械判定し、共有記憶への書込みだけはより狭いschemaと承認を要求します。AWSのAgentic AI Lensも、すべてのwrite pathを検証し、read時のtamper detectionと履歴を持つよう推奨します。原文を無期限に残すのではなく、最小の出所と判定結果をversion化します。

読出し時に再認可し、共有を既定にしない

保存時にtenant_idを付けただけでは不十分です。read時に現在のactorとtenantからnamespaceを組み、該当scopeだけを検索します。session、user、tenant、agent、共有knowledgeを別namespaceにし、cross-tenantやcross-userを「必要なら許す」のではなく、明示的な共有仕様がある場合だけ許可します。Microsoftも、memoryをuser・tenant単位で隔離し、保存分類・保持・削除・access controlを適用するよう案内しています。

読出し結果には、origin、trust_level、expires_at、source_revisionを添えます。未検証のメール由来メモなら「命令ではない外部データ」と明示し、tool選択や権限判断には使いません。特に「この利用者は送信を承認済み」「この宛先は安全」といった権限・承認に関わる記憶は、現在のserver-side policyで再確認します。署名やhashは保存後の改変検知には役立ちますが、内容が真実か、危険な命令でないかまでは証明しません。

日本で先に決めるべき保持・越境の境界

日本では、便利だからと会話・プロフィール・要約を長期保存する前に、利用目的、保持期限、削除手順、提供先をデータflowとして確定します。個人情報保護委員会は、外国にある第三者への個人データ提供について原則として本人同意と事前の情報提供を求める場面を示しています。一方、クラウド利用が直ちに「第三者提供」になるかは、委託関係、providerが個人データを取り扱うか、契約と実際の処理で変わります。法令適用をサービス名だけで判断せず、法務・個情法担当と確認してください。

海外model APIやmemory SaaSを使う場合は、アプリの記憶、providerのapplication state、監査ログ、backupを別々に棚卸しします。たとえばOpenAIのResponses APIは既定でapplication stateを少なくとも30日保存する場合があり、Zero Data Retentionではstoreがfalse扱いになります。これは自社memoryの保持期限を自動で消す機能ではありません。利用者の削除要求を受けたときに、どのstore・provider object・logへ及ぶかを運用に落とします。

限界と反証

記憶を厳しくすると、継続支援の品質や個別最適化が下がることがあります。共有knowledgeも、更新頻度の低い公開規程のように出所と管理者が明確なら、全員から隔離する必要はありません。反対に、曖昧な会話要約を長期保存しても、暗号化やhashだけでpoisoningは防げません。初期段階では長期記憶を設けず、session単位の状態だけにする選択が、最も単純で安全な場合があります。

導入時の最小チェックリスト

session、user、tenant、共有knowledgeのnamespaceと、cross-scopeを許す条件を定義したか
各recordに出所、信頼度、保持期限、削除対象、source revisionを付けたか
read時に現在のactorから再認可し、記憶内のrole・承認文を権限根拠にしていないか
memory poisoning、誤要約、期限切れ、他tenant混入、削除要求を含む再現試験を用意したか

情報図解

図版仕様（1200×675px）: 左に「user入力・Web・tool結果・agent message」の4入力、中央にcandidateの灰色ボックス、そこから「schema/PII検査」「scope付与」「保存承認」の3ゲートを直列で描く。右側は4色のnamespace（session=灰、user=青、tenant=緑、shared=黄）へ分岐し、各recordにorigin / trust / TTL / revisionのタグを表示する。下段にread pathとして「現在のactorから再認可 → 出所を表示 → untrusted contextとしてmodelへ」を戻し矢印で示し、tool認可へは渡さないを赤い禁止記号で明記する。

既存記事との差分・内部リンク

RAG検索のアクセス制御は、検索時に権限外文書を候補から外す設計を扱う。本稿は、会話やtool結果が長期記憶へ保存され、将来sessionへ再注入される経路を扱う。
AIエージェントのtool検証設計は、tool実行直前のschema・認可・業務制約を扱う。本稿は、その前段で記憶内の命令や承認文を権限根拠にしない設計へ限定する。
AIエージェントのレッドチーム設計は、権限・tool・実行環境を横断する試験境界を扱う。本稿はmemory poisoning、tenant越境、保持・削除の再現試験を深掘りする。

主検索意図は「AI agent memoryを汚染・越境からどう守るか」であり、RAG文書検索やtool認可そのものとは分離される。CTAも実際のmemory write/read/delete dataflowレビューに限定する。

CTA

会話、tool結果、長期記憶、削除要求の実際のデータflowを棚卸ししたい場合は、AIエージェント記憶の安全設計を相談する。

一次根拠

一次情報と確認範囲

確認日：2026年9月14日。製品仕様・制度は更新されるため、導入時はリンク先の最新版を再確認してください。海外の制度・職業規範は日本へ直接適用せず、相違点と限界を本文に明記しています。