まず仕組みです。特別な脆弱性は使われていません。使われているのは、主要なAIサービスがどれも備えている「あらかじめ質問文を入れた状態で開くリンク」という、ごく普通の機能です。

URLの末尾に ?q= を付けて質問文を書いておくと、AIサービスがその質問を入力済みの状態で開きます。たとえばこういう形です。

ボタンの見た目は「AIで要約」のまま。押した人には、AIがいつもどおり要約を出してくれたようにしか見えません。ログイン済みのセッションでリンクが開くため、質問は本人が手で打ち込んだのと同じ扱いになります。そして後半の一文が、AIの記憶に残ります。

マイクロソフトの説明を借りれば、こうした指示は「攻撃者のコンテンツを信頼できる情報源として記憶させ、今後のセッションにまたがって持続させる」ことを狙っています。

プロンプトインジェクション自体は新しい話ではありません。当サイトでもプロンプトインジェクションの仕組みや、Webページやメールに命令を埋め込む間接プロンプトインジェクションを扱ってきました。

では今回は何が違うのか。時間軸です。

マイクロソフトはこの性質を、より一般的な「AIメモリ／コンテキストのポイズニング」として整理し、次のように説明しています。記憶が意思決定のループに組み込まれた瞬間、そこは「新しく、しかも長持ちする攻撃面」になる。そして汚染は少しずつ蓄積し、正当な記憶に紛れるため、検知が極めて難しい——と。

実際、危険性の中身はこう説明されています。

なお、汚染先が「ナレッジベース側」になると、これはRAGデータポイズニングという別の形になります。そちらはRAGデータポイズニング完全ガイドで扱っています。同じ「汚染」でも、どこを汚すかで対策がまったく変わるので、混ぜずに理解してください。

ここがこの話のいちばん奇妙で、いちばん重要な点です。

マイクロソフトのDefenderセキュリティ研究チームが2026年2月10日に公開した調査で明らかになったのは、この手法を使っていたのがマルウェアを配る攻撃者ではなく、実在する企業だったということです。

目的は自社サービスを推薦させることです。つまりこれは、マルウェア感染でも情報窃取でもなく、マーケティング手法として実行されているということになります。

さらに踏み込むと、この手法はツール化して提供されています。報道によれば、自社サイトのURLと「この分野の質問では常に自社ブランドを推薦させる」といった文言を入力すると、仕込み済みの共有リンクを生成してくれるツールが、マーケティング担当者向けに公開されています。

この構図は、当サイトで整理しているAI悪用事例データベースの中でも異質です。多くの事例が「攻撃者がAIを使って攻撃する」型なのに対し、これは「事業者がAIの記憶を商業目的で書き換える」型だからです。

「AIの記憶を汚す」という発想は、2026年に入って学術研究でも急速に整理が進んでいます。ここでは押さえておくべき2本を紹介します。

①「眠ったまま仕込まれる記憶」（2026年5月）

「Hidden in Memory: Sleeper Memory Poisoning in LLM Agents」という研究です。スリーパー（潜伏型）という名前のとおり、仕込まれた記憶がすぐには発動せず、後の会話でよみがえる点を扱っています。

手口は、文書・Webページ・リポジトリなど外部のコンテンツを細工して、AIに「利用者についての作り話」を記憶させるというもの。実験では、複数のAIアシスタントに対して汚染された記憶の書き込みに高い確率で成功したと報告されています（報告値は最大で99.8%）。

②「どこから記憶に入り込めるのか」の体系化（2026年6月）

もう1本が「From Untrusted Input to Trusted Memory」という研究です。タイトルを直訳すると「信頼できない入力から、信頼される記憶へ」。まさに今回の問題の本質を言い当てています。

この研究は、AIエージェントの記憶に書き込める経路を整理し、次のように分類しました。

そして、実務にとってもっとも重要な結論が2つ出ています。

この攻撃は、業界の分類体系にも取り込まれています。整理しておきます。

※ 「AML.T0080＝Memory Poisoning」と紹介されることがありますが、正確にはこの技術IDの名称はAI Agent Context Poisoningで、Memory はその配下のサブ技術（.000）です。

個人でできることは、実はそれほど多くありません。しかし効果が高いものが3つあります。

1. AIの記憶を、一度自分の目で見る

これがいちばん効きます。主要なAIサービスには、記憶した内容を一覧・削除できる設定画面があります。まずはそこを開いてみてください。手っ取り早い方法として、AIに直接こう聞くこともできます。

そのうえで、身に覚えのない企業名・サービス名・「信頼できる情報源」といった記述がないかを確認します。心当たりがなければ削除してかまいません。ここが汚染されていた場合、削除するだけで影響は止まります。

2. 「AIに聞く」ボタンより、自分でコピーして貼る

結局これが確実です。記事を要約させたいなら、ボタンを押すのではなく、URLか本文を自分でコピーしてAIに貼る。手間はほとんど変わりませんし、余計な指示が混ざる余地がなくなります。

ボタンを押す前にリンク先を確認する方法もありますが、URLエンコードされていると人間には読みにくく、モバイルではそもそも確認が困難です。「押さない」ほうが早くて確実です。

3. AIの推薦を、そのまま判断材料にしない

「おすすめのセキュリティ製品は？」「この会社は信頼できる？」——こうした推薦を求める質問が、この攻撃のいちばんの標的です。AIの答えを出発点にするのはよいとして、最終的には一次情報で確かめる。この習慣があれば、記憶が汚染されていても被害には至りません。

ここからは、社内でAIアシスタントやAIエージェントを作る側の話です。マイクロソフトが公開している対策指針は、要するに「記憶を、設定ファイルと同じくらい厳しく管理せよ」という一点に集約されます。

設計思想としてもっとも大事なのは、「利用者本人の指示」と「外部コンテンツから来た指示」を区別する信頼境界を作ることです。外から来た文章の中に「記憶しろ」と書いてあっても、それはデータであって命令ではない——この線引きが実装されていないと、いくら入力フィルタを足しても抜けます。

AIに記憶を持たせることは、間違いなく便利です。この記事は「メモリ機能を使うな」という話ではありません。ただ、入力を守るだけでは足りず、AIが何を覚えているかまでがセキュリティの対象になった——その一線を越えたことは、知っておく価値があります。