Foundry エージェントサービスの memory poisoning 対策

Microsoft Foundry Blog は 2026年6月23日、Microsoft Foundry エージェントサービスにおける memory poisoning 対策を扱う記事を公開しました。AIエージェントが保持する記憶を、悪意ある入力や誤った文脈からどう守るかが主題です。

要点

• memory poisoning は、AIエージェントの記憶や長期文脈に不正・不適切な情報を混入させ、将来の判断を歪める攻撃・障害パターンです。
• Foundry エージェントサービスのようにエージェントが文脈を保持するサービスでは、記憶の登録、参照、更新、削除、監査が重要になります。
• セキュリティ対策はプロンプト保護だけでは足りず、記憶そのものの信頼境界と承認フローが必要です。
• エージェントを業務に入れるチームは、誰が何を記憶させられるか、どの記憶が後続タスクに影響するかを確認する必要があります。

今回のブログ記事で語られていること

今回の Microsoft Foundry Blog は、AIエージェントが長期的な文脈や記憶を持つときに発生する memory poisoning のリスクを扱っています。エージェントは、利用者の好み、業務ルール、過去の会話、手順、顧客情報、プロジェクト文脈を覚えるほど便利になります。一方で、記憶に誤った情報や悪意ある指示が入り込むと、その後のタスクで繰り返し参照され、回答や実行内容を歪める可能性があります。公式記事は、Foundry エージェントサービスの文脈で、この記憶をどう守るかを説明するものです。

memory poisoning の難しさは、攻撃がその場の1回の回答だけで終わらない点にあります。プロンプトインジェクションであれば、その会話の中で不正な指示を無視する対策が考えられます。しかし記憶が汚染されると、後日の別タスク、別利用者、別ツール呼び出しにも影響が残ります。たとえば、ある顧客に関する誤った制約、偽の承認済み手順、外部リンク、危険なコード実行ルールが記憶されると、エージェントはそれを正しい前提として扱うかもしれません。

実務では、記憶を「便利なメモ」としてではなく、権限と監査の対象として扱う必要があります。誰が記憶を追加できるのか、エージェントが自動で記憶してよい情報は何か、機密情報や一時的な指示を長期記憶に残さないための条件は何か、記憶を後から確認・修正・削除できるかを決める必要があります。Foundry エージェントサービスを使う場合も、モデルの安全性だけでなく、記憶ストア、ツール接続、認証、ログを一体で見なければなりません。

この発表は、AIエージェントが業務に深く入るほど、セキュリティの対象がプロンプト、モデル、ツールだけでなく、エージェントの記憶へ広がることを示しています。エージェントに長期文脈を持たせる組織は、利便性と安全性の境界を明確にし、記憶がどの判断に使われたかを追跡できる設計を持つ必要があります。

今回のブログ記事が関係する人

Azure AI / Microsoft Foundry を使うAIアプリ開発者、エージェント基盤担当、セキュリティ担当、ガバナンス担当に関係します。長期記憶や社内文脈をAIに持たせる組織では特に重要です。

実務で確認したいポイント

• エージェントが自動で記憶する情報と、人間承認が必要な情報を分ける。
• 記憶の追加、更新、削除、参照に関するログと監査手順を確認する。
• 外部入力、Web、チケット、チャットから得た情報を長期記憶へ入れる条件を厳しくする。
• 誤った記憶が下流タスクへ影響した場合の検知、修正、再実行手順を用意する。

結局、今回のブログ記事をどう読むべきか

この発表は、AIエージェントの記憶をセキュリティ対象として扱う必要があることを示しています。Foundry エージェントサービスを使うチームは、長期文脈の便利さだけでなく、記憶の信頼性、権限、監査、削除を導入設計に入れておく必要があります。