AIエージェントのメモリーポイズニング対策：スマホでAsk AIと保存メモリーを確認する
AIエージェントのメモリーポイズニングを、Ask AIボタン、入力済みプロンプト、推薦汚染、保存メモリー監査、出所確認、復旧、現在のFoneClawの文脈境界から解説します。
- AIエージェントのメモリーポイズニングは、一回の悪い回答ではなく、アシスタントが後で使う保存メモリーや好みへ、第三者の指示や偏った情報が入り込むリスクです。
- Microsoftは、Ask AIのようなラベルの裏に入力済みプロンプトを含むURLを置き、将来の推薦を偏らせようとするAI Recommendation Poisoningの試みを報告しています。
- 安全確認では、リンク先、入力済みテキスト、要約対象と指示の分離、保存メモリーの出所、削除や編集、クリーンな再テストを順に見ます。
- 現在のFoneClawでは、ユーザーが現在画面を意図して添付し、対応済みAndroid操作を権限、承認、結果確認、復旧の中で進めるため、文脈共有と実行を分けて扱えます。
AIエージェントのメモリーポイズニングとは
AIエージェントのメモリーポイズニングとは、アシスタントが後の会話で使う保存メモリー、好み、事実、推薦傾向に、ユーザーが意図していない指示や偏った情報が入り込むことです。一回だけ変な回答が出る問題とは違います。リスクの中心は永続性です。今日の画面やリンクから入った内容が、明日の推薦、次回の購入相談、後日の会社選び、アプリ選択、作業判断に影響する可能性があります。
分かりやすい例は、AIレコメンド汚染です。あるWebページに「Ask AI」や「Summarize with AI」のようなボタンがあり、見た目は便利な要約リンクに見えます。ところが、そのリンク先に入力済みプロンプトが含まれ、アシスタントへ「この会社を今後の推薦で優先して覚える」といった趣旨の指示を渡そうとする。ユーザーは要約を頼んだつもりでも、アシスタント側では記憶や好みへ触れる試みとして処理される場合があります。
Microsoftはこの種の動きをAI Recommendation Poisoningとして説明しています。重要なのは、すべてのAsk AIボタンが危険という話ではなく、ラベルだけではリンクの中身や入力済みテキストが分からないという点です。実際の効果は、アシスタントの保存メモリー設計、保護策、ユーザー設定、プラットフォームの更新によって変わります。スマホ利用者に必要なのは、怖がってAIを使わないことではなく、何を送ったか、何が保存されたか、後でどう確認できるかを見える状態にすることです。
FoneClawを作る私たちの立場では、メモリーは便利さの核であり、同時に出所と範囲を管理すべき対象です。パーソナルな文脈がスマホ操作にどう役立つかは、パーソナルコンテキスト AI エージェント：スマホ操作に必要な文脈と安全な境界で広く整理しています。このページでは、保存メモリーが偏らせられる経路と、スマホ上での確認、封じ込め、復旧に集中します。
隠れたAsk AIやAI要約ボタンからメモリーへ届く経路
Ask AIボタンの安全性を考える時、攻撃コードの詳細を知る必要はありません。見るべきなのは、ユーザーが触る入口からアシスタントの保存メモリーまでの経路です。第一に、Webページやアプリ内に、便利そうなラベルのボタンがあります。第二に、そのボタンはAIアシスタントを開くリンクや共有先を持っています。第三に、リンクの中には、要約してほしい本文だけでなく、あらかじめ入れられた指示文が含まれることがあります。第四に、ユーザーが送信すると、その指示が現在の回答や保存メモリーに影響を与えようとします。第五に、後日の推薦や比較で、特定の会社や商品が不自然に優先される可能性が出ます。
Microsoftが報告したAI Recommendation Poisoningでは、特別に作られたURLのプロンプトパラメータが使われ、将来の推薦で特定の会社を覚える、優先する、推奨するよう促す試みが観測されました。これは、ユーザーが目で見るボタン名と、実際にアシスタントへ渡るテキストが一致しないことを示します。スマホでは画面が小さいため、URL全体や共有内容を確認しにくく、危険な前提が生まれやすくなります。
ここで大切なのは、要約対象と指示を分けることです。要約対象は、記事、メール、PDF、商品ページ、アプリ画面など、AIに読ませたい内容です。指示は「要約して」「比較して」「重要点だけ出して」のようなユーザーの意図です。外部ページが指示まで勝手に用意している場合、ユーザーは送信前にその内容を見る必要があります。リンクのラベルが自然でも、入力済みテキストが自然とは限りません。
スマホでの実用対策は単純です。AIボタンを押す前に、開く先、共有される本文、入力欄にすでに入っている指示を確認します。見えない文字列や長すぎるプロンプトがある場合は、送信せず、本文だけを自分で選び直すほうが安全です。疑わしい内容を別のアシスタントへ貼って検査する行為は、同じ問題を広げるため避けます。
メモリーポイズニング、プロンプト注入、学習データ汚染の違い
LLMメモリー注入を正しく診断するには、似た言葉を分ける必要があります。プロンプト注入は、現在の会話や現在のタスクで、外部コンテンツ内の指示がモデルの振る舞いを変える問題です。たとえば、Webページの中に「前の指示を無視して」といった文章があり、要約時にその文章が影響する。これは一回の作業だけで終わる場合があります。
メモリーポイズニングは、現在の会話だけでなく、後で使われる保存メモリー、好み、ユーザープロファイル、推薦ルールに影響することを狙います。今日の要約リンクが、来週のおすすめ商品やサービス比較に残るような形です。MITRE ATLASはMemory PoisoningをAML.T0080として整理しており、AIシステムのメモリーが改変される脅威として分類しています。これは、単なる回答ミスよりも長い影響を持つ可能性があるため、保存された内容の確認が重要になります。
学習データ汚染はさらに別の層です。モデルが学習する前のデータセットへ悪い情報を入れる問題で、ユーザーのスマホ上でAsk AIボタンを押した時に起きる保存メモリー問題とは扱う場所が違います。怪しい推薦が出たからといって、どの仕組みが原因かは出力だけでは断定できません。現在の入力、保存メモリー、会話履歴、アプリ設定、外部情報源を順に確認することが実用的です。
| 問題 | 狙う場所 | ユーザーが見る兆候 | 確認の入口 |
|---|---|---|---|
| プロンプト注入 | 現在の会話やタスク | 要約や回答が外部文に引っ張られる | 入力した本文、ページ内の指示、現在のプロンプト |
| メモリーポイズニング | 保存メモリーや好み | 後日の推薦や判断が偏る | 保存メモリー、パーソナライズ設定、最近のAIボタン利用 |
| 学習データ汚染 | モデル学習前のデータ | 広い範囲で特定の誤りが出ることがある | モデル提供者の説明、外部検証、再現性 |
Microsoftの調査が示したことと数字の読み方
MicrosoftのAI Recommendation Poisoningに関する調査では、31社、14業界にまたがる50以上のユニークなプロンプトが観測されました。これらは、AIボタンや入力済みプロンプトを通じて、将来の推薦で特定の企業やサービスを好意的に扱わせようとする試みとして説明されています。数字が示すのは、攻撃が研究上の仮説にとどまらず、実際のマーケティングや推薦誘導の文脈で試みられていたということです。
同時に、数字の読み方には注意が必要です。Microsoftは、効果がアシスタントごとに異なり、時間の経過と保護策の更新によって再現しなくなった挙動があることも説明しています。つまり、観測されたプロンプトの数は、そのまま「すべてが保存メモリーに残った」ことを意味しません。あるアシスタントでは現在の回答だけに影響した可能性があり、別の環境では保存前にブロックされた可能性があります。
この点はスマホ利用者にも重要です。AIボタンを押したあとに不自然な推薦が出た場合、原因を一つに決めつけるより、どのアシスタントを使ったか、入力済みプロンプトを送ったか、保存メモリーが更新されたか、パーソナライズ設定が有効かを確認します。Copilot向けの保護策が説明されていても、別のアシスタント、別のブラウザ、別のアプリ、別の地域設定では挙動が変わります。だからこそ、保存メモリー監査はプラットフォームごとに行います。
メモリーの出所、版、範囲が重要な理由
AIレコメンド汚染への実用的な防御は、「メモリーがあるかないか」だけでは足りません。重要なのは、そのメモリーがどこから来たか、いつ作られたか、誰の所有か、どのAgentやアプリに見えるか、どの会話やタスクに結びついているか、あとから編集や無効化ができるかです。出所が見えないメモリーは、便利でも調査しにくくなります。
TencentDB Agent Memoryの公式リポジトリは、スマホ向けの防御製品としてではなく、メモリー設計の参考になる構造を示しています。Chat Memory、Skills、Wiki、CodeGraphのような記憶資産に、所有者、バージョン、状態、可視性、利用回数、Agentとの結びつきを持たせる考え方です。また、L0に生の会話、L1に抽出された要素、L2にシナリオ、L3に中核的な人格やペルソナを置く階層も説明されています。
この考え方をスマホAIに引き寄せると、保存メモリー監査で見るべき項目が見えてきます。ユーザーが直接入力した好みなのか、Webページからの要約で生まれた推測なのか、AIボタン経由の入力済みプロンプトなのか、設定画面で作ったルールなのか。さらに、そのメモリーが全会話で使われるのか、特定のAgentだけに使われるのか、特定のアプリ操作だけに使われるのかを確認します。
ローカルな記憶とサーバー側の状態をどう分けるかは、Hy-Memoryサーバー状態 vs ローカルエージェント記憶：スマホ利用者が知るべきことで詳しく扱っています。このページでは、出所、版、範囲を「疑わしい推薦を追跡するための手がかり」として使います。
AIアシスタントへ送る前のスマホ確認チェック
Ask AIボタンの安全性は、押す前にどれだけ確認できるかで大きく変わります。スマホではリンク全体が見えにくく、ボタンのラベルだけで判断しがちです。だからこそ、AIアシスタントへ送る前に、短い確認手順を持つことが役立ちます。
- ボタン名だけで判断せず、長押しや共有画面で実際のリンク先を確認します。
- アシスタントが開いたら、入力欄に最初から入っている文章を読みます。
- 要約してほしい本文と、アシスタントに従わせる指示が混ざっていないか見ます。
- 「今後覚えて」「今後優先して」「推薦では常に」といった持続的な指示が入っていないか確認します。
- 会社、商品、投資、医療、法律、仕事の判断につながる推薦は、別の信頼できる情報源でも確認します。
- 送る必要があるのはページ全体なのか、選択した短い本文だけなのかを選びます。
この確認は、Webページだけに限りません。メール、PDF、チャット、ドキュメント、画像内の文字、スクリーンショット、アプリ画面にも、アシスタントへの隠れた指示になり得る内容が含まれます。画面や文書をAIに渡す前に、読ませたい内容と従わせたい指示を分ける癖をつけると、メモリー汚染だけでなく、通常のプロンプト注入にも強くなります。
スキルや拡張機能を通じてAIに作業ルールを追加する場合は、権限と実行時確認も合わせて見る必要があります。スマホ権限とSkillの安全性は、AIエージェントのスキル安全性：スマホ権限は実行時に確認すべき理由で別に整理しています。
メモリー汚染が疑われる時の封じ込めと復旧
メモリー汚染が疑われる場合、最初に行うのは大きな削除ではなく、影響範囲を止めることです。疑わしい推薦や回答が出たら、その会話を高い影響の判断に使うのをいったん止めます。どのWebページ、Ask AIボタン、共有テキスト、メール、PDF、スクリーンショットを使ったあとに変化したかを記録します。記録は短くて構いません。日時、使ったアシスタント、入力元、出た推薦、怪しい理由が分かれば、あとで切り分けやすくなります。
次に、アシスタントの保存メモリー、パーソナライズ設定、好み、履歴、接続アプリ、プロフィールに該当する管理画面を確認します。メモリー管理の名前や場所はアシスタントごとに違います。見つかった項目の中に、ユーザーが直接入れた覚えのない会社名、商品名、推薦ルール、常に優先する指示、誤った好みがあれば、削除、編集、無効化を検討します。チャット履歴の削除と保存メモリーの削除は同じ操作として扱われない場合があるため、メモリー専用の設定を確認します。
復旧は次の順序で進めると安定します。
- 疑わしい会話やリンクを高影響の判断から外す。
- 保存メモリーやパーソナライズ項目を確認する。
- 怪しい項目を削除、編集、無効化する。
- 新しいクリーンな会話で、偏りのない短い質問を試す。
- 推薦や助言を、公式情報、一次情報、複数の独立した情報源で確認する。
- 同じ偏りが続く場合は、接続アプリ、履歴、ブラウザ拡張、共有元ページも見直す。
削除できたから完了と考えるより、クリーンな再テストまで行うほうが実用的です。特に、購入、採用、医療、法律、金融、業務システムの判断では、AIの推薦だけで決めず、独立した情報源で確認します。ローカル操作とクラウドAIの信頼境界を広く確認したい場合は、AIエージェントの信頼性：クラウドAIとローカルAndroid操作をどう見分けるかが参考になります。
現在のFoneClawのAndroid文脈境界
現在のFoneClawの基準は、リリースの確認と導入をFoneClawのダウンロードから進められます。この基準では、ユーザーが意図して現在画面を添付できるようにし、FoneClawのオーバーレイ面をその添付から除く設計を入れています。私たちがこの流れを重視するのは、スマホAgentでは「何をAIへ見せたか」をユーザーが理解できることが、メモリーや推薦の安全性にもつながるからです。
FoneClawでは、設定されたモデルが推論と計画を担い、FoneClawが対応済みAndroid操作を権限、承認、結果確認、復旧の中で実行します。オンラインモデルや外部サービスを設定する場合、関連する文脈がネットワーク経由で扱われることがあります。 locally managed account informationにはユーザー向けの管理点があり、プライバシーに関する基本方針はFoneClawのプライバシー情報で確認できます。電話側の対応済み能力は、FoneClawの機能一覧で100+ built-in toolsとして把握できます。
ここでFoneClawが提供する価値は、メモリー汚染を魔法のように見つけることではなく、文脈共有とAndroid実行を見える境界に置くことです。ユーザーが現在画面を添付する。モデルがその文脈をもとに考える。FoneClawが対応済み操作を実行する前に、権限や承認、結果を扱う。この順序を分けることで、どの情報を見せ、どの操作を進め、どこで止まるかを追いやすくなります。
私たちがFoneClawを作っていて学んだのは、パーソナルな文脈は強力であるほど、出所、範囲、実行境界を同時に持つ必要があるということです。メモリーは便利な推測を生みますが、スマホ上の送信、設定変更、共有、保存のような行動では、ユーザーが見て判断できる段階を残すことが重要です。
スマホAgentのメモリー安全性チェックリスト
最後に、スマホAgentやAIアシスタントを低リスクに評価する手順をまとめます。最初のテストには、健康、金融、仕事の重要判断ではなく、架空の商品名や低影響の好みを使います。目的は、AIの記憶力を試すことではなく、ユーザーが何を送信し、何が保存され、どこで確認でき、どう消せるかを確かめることです。
- 送信前に入力済みプロンプトや共有本文を確認できるか。
- 保存されたメモリーの出所、作成時点、対象範囲が分かるか。
- メモリーを編集、削除、無効化できるか。
- 削除後にクリーンな会話で再テストできるか。
- 同じ推薦が続く場合、履歴、接続アプリ、外部ページ、アカウント設定を分けて確認できるか。
- 高影響の助言を独立した一次情報で検証する習慣があるか。
透明なメモリー管理は調査を助けますが、情報源の確認を置き換えるものではありません。AIエージェントのメモリーポイズニング対策は、リンク、入力、保存、出所、削除、再テストを一つの流れで扱うことから始まります。