コンテキスト汚染とは何ですか?プロンプトインジェクションとどう違いますか?
プロンプトインジェクションは一回限りのその場限りの攻撃であり、悪意ある指示は一度のやり取りの中に現れ、通常セッションが終了すればその影響も終わる。一方コンテキスト汚染は、攻撃者がエージェントの永続的なストレージ層(ベクトルデータベース、RAGインデックス、長期記憶、会話の要約)に虚偽のデータを書き込むもので、そのエントリはセッションを跨いで存在し続け、その記憶断片を取得する将来のあらゆるやり取りで参照される可能性がある。しかも多くの場合、攻撃者が直接関与していない後の対話で発動する。
この違いは、両者の防御ロジックが根本的に異なることを意味する。プロンプトインジェクションは「入力時点」で防御するのに対し、コンテキスト汚染は「保存されている内容自体が信頼できるか」というレベルまで防御を拡張する必要がある。被害を受けるのは一回の会話ではなく、その後エージェントがこの記憶ストアに依存して行うすべての判断だからだ。
コンテキスト汚染はなぜ起こるのですか?何が原因ですか?
核心的な原因は、エージェントシステムが性能向上のために長期記憶やRAG検索の仕組みを広く採用している点にある——過去のやり取りを記憶し、過去に成功裏に処理した事例を参照できることは確かに精度と効率を向上させるが、同時にこの記憶層に書き込まれた内容は何であれ、信頼できる情報源として繰り返し利用されることを意味する。多くのシステムは設計段階で「この記憶が誰によって書き込まれ、どの程度信頼できるか」を追跡する仕組み(プロヴェナンス追跡)を欠いており、汚染されたコンテンツが一度混入すると、正当に書き込まれた内容と区別することが難しくなる。
もう一つの推進要因は、攻撃のハードルが実際には低いことだ。2025年のNeurIPSで発表された攻撃手法MINJAは、攻撃者が記憶ストアへの直接書き込み権限すら必要とせず、通常のやり取りクエリだけでエージェントの長期記憶に汚染コンテンツを植え付けられることを証明し、複数の本番環境エージェントアーキテクチャに対して95%を超える注入成功率を達成した。
コンテキスト汚染は具体的にどのように機能し、攻撃者は実際に何をするのですか?
典型的なパターンは、攻撃者が一見完全に正常なやり取りの中で、エージェントに正規の記録と全く同じ形式の捏造エントリを記憶に保存させることだ——例えば「過去に成功裏に処理された事例」や「検証済みの事実」を装う。このエントリは保存された時点では即座に異常を引き起こさない。まだどのクエリからも取得されていないからだ。将来、全く無関係な別のユーザーがこの記憶を取得するクエリを発行して初めて、エージェントはこの偽エントリを信頼できる根拠として扱い、それに基づいて行動する。この時点では植え付けからかなりの時間が経過している場合が多く、表面的にはエージェントが「理由もなく」突然おかしな判断をしたように見える。
攻撃対象領域は主に4つの入口に集中する。エージェントが自ら巡回・インデックス化する外部コンテンツ(RAGソース)、長期記憶ストレージ、改ざんされたツール説明(ツール汚染)、そしてマルチエージェントシステムにおける他のエージェントから渡されるメッセージである。RAGソースは最も過小評価されやすい部分で、パイプラインがコンテンツ検証を行っていなければ、攻撃者が影響を及ぼせるコンテンツは何でもデータベースにインデックス化されうる。ツール説明の汚染をテストしたあるベンチマークでは、主要な20のエージェントに対して70%を超える攻撃成功率が記録されており、より高性能なモデルほど指示(植え付けられたものも含む)に従うのが得意であるがゆえに、かえって影響を受けやすい傾向があった。
コンテキスト汚染は私にとってどういう意味があり、すでに影響を受けているかどう判断すればよいですか?
あなたのエージェントがRAG、ベクトルデータベース、会話の要約、セッションを跨いだユーザー設定など、何らかの形の永続的な記憶を使用している場合、このリスクは記憶が使用される期間が長くなるほど蓄積する——ストアが稼働している期間が長く、蓄積された内容が多いほど、検知されないまま汚染されている可能性が高くなり、汚染が発生した時点と症状が現れる時点の間隔は通常のセキュリティインシデントよりもはるかに大きいことが多く、事後の追跡は大幅に困難になる。
観察可能な警告兆候には、エージェントが好むツールに突然説明のつかない変化が生じる、意思決定の経路が過去に確立されたパターンから逸脱する、API呼び出しの失敗率が異常に上昇する、などがある。これらはモデル性能の単なる変動ではなく、コンテキストが汚染された行動シグナルである可能性がある。より根本的な防御としては、記憶にプロヴェナンス追跡(誰が、いつ書き込んだか、信頼度はどの程度か)を組み込み、信頼レベルごとにストレージを分割することが有効だ——例えば、システムレベルのポリシーや検証済みの事実は変更に人間のレビューを必要とする読み取り専用パーティションに保管し、ユーザーとの会話から生成される通常の記憶とは分離する。同時に、独立した信頼できる別のモデルを使って定期的に記憶ストアを監査し、形式は正常だが既知の事実と矛盾するエントリを洗い出す。
2025年のNeurIPSで発表された攻撃MINJAは、攻撃者が直接的な書き込み権限を一切必要とせず、通常のやり取りクエリだけでエージェントの長期記憶を汚染できることを証明し、複数の本番環境エージェントアーキテクチャに対して95%を超える注入成功率を達成した。2026年3月、OWASPはTop 10 for Agentic Applicationsにおいて、この種のリスクをASI06(メモリとコンテキストの汚染)として正式に独立項目に位置づけた。
Adding provenance tracking and trust-based partitioning to a memory store effectively limits how far poisoning can spread, but increases system design and operational complexity — every entry written to memory needs a tagged source, and every read requires a trust-level judgment, which adds response latency for latency-sensitive applications. Doing no tracking or auditing at all effectively lets poisoned content lie dormant indefinitely. The common industry approach is to apply strict tracking first to high-risk memory partitions (system policies, financial facts), while treating ordinary conversational memory more loosely but auditing it periodically.