2026年版 プロンプトインジェクション攻撃 完全ガイド

いま、なぜプロンプトインジェクションに注目すべきなのか

いまプロンプトインジェクションに注目すべき理由は、それが「実際に機能し、かつ未解決のまま」、すでに本番稼働しているAIシステムを狙う攻撃だからです。その被害は、恥ずかしいチャットボットの出力にとどまらず、データの窃取、認可されていないアクション、企業システムの侵害へと移っています。

2025年半ば、Aim Labsのセキュリティ研究者が「EchoLeak」を公表しました。これはMicrosoft 365 Copilotに対する、世界初のゼロクリック型データ持ち出し攻撃です。攻撃者は標的にごく普通のメールを送っただけでした。ユーザーはそのメールを一度も開いていません。Copilotが通常のバックグラウンド処理の中でそれを読み込み、後日行われた無関係なクエリが、漏洩の引き金となったのです。

これが、現時点の状況です。

より正確に言えば、もはやモデルが終着点ではありません。AIエージェントは、メールを読み、文書を要約し、Webを閲覧し、社内システムに問い合わせ、外部ツールを呼び出します。それらの入力のいずれもが、攻撃者が書き込んだ指示を運び込みかねません。そしてエージェントは、その違いを常に見分けられるわけではないのです。

なぜこれが重要なのでしょうか。

経済的な条件が、攻撃者に有利にできているからです。

攻撃者に必要なのは、機能するプロンプトが1つだけです。一方で防御側は、エージェントが触れるあらゆる入力に含まれる、あらゆる悪意ある指示を漏れなくブロックしなければなりません。メール、文書、Webページ、社内Wiki、他のエージェントの出力——攻撃面はあまりにも広大です。

そして業界自身も、現状について率直に語ってきました。

OpenAIは、プロンプトインジェクションを、いまだ取り組みが続く「フロンティア（最先端）のセキュリティ課題」と位置づけています。2026年5月には、ファイブ・アイズ（CISA、NSA、および英国・カナダ・オーストラリア・ニュージーランドの各対応機関）がエージェント型AIに関する共同ガイダンスを発表しました。彼らはプロンプトインジェクションを、攻撃者がエージェントを操作する中核的な手口として名指しし、単独で十分な防御策など存在しないと強調しています。

‍

このガイダンスは、何もないところから生まれたわけではありません。

2024年から2026年にかけて、現実の事案が絶え間なく積み重なった末に出てきたものです。生産性アシスタント、コードエディタ、社内チャットボット、開発者向けエージェント——そのいずれもが、何らかの形のインジェクションによって侵害されました。これらの事案については、本記事の後半で取り上げます。

いまの時点で言えるのは、次のことです。

プロンプトインジェクションは理論上の話ではありません。すでに組織から、データと、信頼と、時間を奪っています。

プロンプトインジェクションにはどんな種類があるのか

プロンプトインジェクションには、大きく分けて3つの種類があります。直接（ダイレクト）、間接（インダイレクト）、そして保存型（ストアド）です。それぞれが異なる「信頼の境界面（トラストサーフェス）」を、すなわち攻撃者がモデルに到達できる異なる地点を表しています。

直接プロンプトインジェクション（Direct）

直接プロンプトインジェクションは、攻撃者がプロンプトそのものにアクセスできる場合に起きます。

悪意ある指示は、攻撃者がユーザー入力として直接タイプ入力します。

これが元祖の形です。「プロンプトインジェクション」と聞いて多くの人が思い浮かべるのも、この形でしょう。チャットボットに「システムプロンプトを無視しろ」と命じるユーザー。隠された指示を引き出そうとする研究者。モデルのガードレールを探るレッドチーマー。

直接インジェクションはいまでも起こります。消費者向けチャットボットや、分離の甘い社内AIツール、そして信頼できないユーザー入力にモデルをさらすあらゆるものに対して、依然として通用します。しかし、もはや企業における主要な脅威面ではありません。

間接プロンプトインジェクション（Indirect）

間接プロンプトインジェクションは、エージェントが攻撃者の管理下にあるコンテンツにアクセスできる場合に起きます。

攻撃者はモデルと直接会話しません。モデルが自ら読み込む場所に、指示を仕込んでおくのです。メール。文書。Webページ。Slackのメッセージ。取得されたファイル。別のエージェントからの応答。エージェントは通常のタスクの一部としてそのコンテンツを処理し、隠された指示に従ってしまいます。

参考：間接プロンプトインジェクションは、2024年以降のほぼすべての企業向けプロンプトインジェクション事案で見られる、支配的なパターンです。

保存型プロンプトインジェクション（Stored）

保存型プロンプトインジェクションは、システムが攻撃者の管理下にある「記憶（メモリ）」にアクセスできる場合に起きます。

指示は、モデルが動き出す前から、すでにそこに仕込まれています。長期記憶、埋め込み（エンベディング）、ナレッジベースのエントリ、インデックス化された文書、あるいはエージェントの設定ファイル——要するに、モデルが後から読み込むあらゆる場所に潜んでいます。

いったん埋め込まれると、それはセッションをまたいで存続し、将来の無関係なタスクに対して再び発動しかねません。

保存型インジェクションは、ロングテールのリスクです。最初のインジェクションの発生と、最終的な悪用とが時間的に切り離されているため、検知が難しいのです。そして、汚染されたレコードを見つけ出すには「何を探せばよいか」を知っていなければならないため、是正も難しくなります。

「種類」と「手法」の違い

これら3つの種類は、インジェクションがどのようにモデルに到達するかを表しています。

インジェクションを実際にどう構築するかは、それとは別の「手法（テクニック）」の問題です。手法には、難読化（obfuscation）、ペイロード分割（payload splitting）、敵対的サフィックス（adversarial suffixes）、マルチモーダルによる隠蔽、多言語による回避などが含まれますが、これらに限られません。

どの手法も、どの種類の中にも現れえます。マルチモーダルインジェクションは、ユーザーによるアップロード（直接）を通じても、取得されたコンテンツ（間接）を通じても成立します。ペイロード分割攻撃は、タイプ入力されることもあれば、仕込まれることもあります。

プロンプトインジェクションは実際どう機能するのか？

LLMは、命令とデータを区別しません。モデルの視点からは、どちらも自然言語のテキストとして届きます。攻撃者はモデルが処理するコンテンツの中に指示を隠し、モデルはそれに従います。たとえその指示が、開発者が本来与えた指示と矛盾していてもです。

これが、脆弱性のすべてです。

これが初めて実証されたのは2022年9月のことでした。研究者のRiley Goodsideが、翻訳プロンプトに「上記の指示を無視せよ（ignore the above directions）」と付け加えるだけで、モデルの挙動をそらせることを示しました。まもなく独立系研究者のSimon Willisonが「プロンプトインジェクション（prompt injection）」という語を作りました。翌年には、Kai Greshakeらが、同じ手法が、ユーザーがタイプ入力するコンテンツだけでなく、モデルが取得するコンテンツを通じて間接的にも機能することを実証しました。

それ以来、何が変わったのでしょうか。

もはやモデルが終着点ではありません。

いまや終着点はエージェントです。理由は次のとおりです。

AIエージェントは、ツール連携やModel Context Protocol（MCP）を通じて、ファイルを読み、Webを閲覧し、APIを呼び出し、データベースに問い合わせ、アクションを起動できます。かつてはチャットボットに恥ずかしい発言をさせるだけだったインジェクションが、いまやエージェントにメールを送らせ、データを持ち出させ、コードを実行させることができます。

現代のインジェクションの多くは、そもそもユーザー入力を通じて届くわけではありません。

それらは、エージェントが自ら読み込むコンテンツを通じて届きます。メール、文書、取得されたファイル、他システムのツール出力などです。このエージェントへのシフトこそが、間接インジェクションが支配的な攻撃パターンである理由です。

エージェントが構造的にリスクにさらされているかどうかを、きれいに見分ける方法があります。

3つの性質が同時に存在していなければなりません。機密データへのアクセス、信頼できないコンテンツへの露出、そして外部と通信する能力です。この3つをすべて備えたエージェントは、攻撃可能です。1つでも欠けているエージェントは、攻撃の経路が断たれます。

このパターンは、しばしば「致命的な三要素（lethal trifecta）」と呼ばれます。これは独立系研究者のSimon Willisonが2025年に提唱した枠組みです。記録に残るほぼすべての主要なプロンプトインジェクション攻撃を、この枠組みで説明できます。本ガイド後半の事案の解説では、これが実際に機能している様子を確認していきます。

現実世界でのプロンプトインジェクションはどう見えるのか？

現実世界では、プロンプトインジェクションは、ごく普通のメールやSlackメッセージ、設定ファイルの姿をしています。その中に、AIエージェントが読み込んで実行してしまう指示が隠されているのです。しかも通常、マルウェアも、突破されたログインも、どこにも見当たりません。

「モデルが 何を言うか」から「エージェントが 何をするか」へ——この転換は、理論上の話ではありません。過去2年間には、それを裏づける記録があります。

以下の事案は、企業のセキュリティチームがプロンプトインジェクションをどう捉えるかを、根本から変えました。順に並べると、明確なエスカレーションの軌跡が浮かび上がります。データの漏洩から、コードの実行、そしてAIそのものを攻撃者の道具に変えるところまでです。

すべては、従業員が既に使っていたアシスタントから始まりました。

Slack AIによるデータ持ち出し（PromptArmor、2024年）

攻撃経路： 攻撃者が自ら作成した公開Slackチャンネルに仕込んだ、悪意ある指示。

何が起きたか： その後、あるユーザーがSlack AIに情報の取得を依頼したところ、アシスタントは公開チャンネルとプライベートチャンネルを同時に検索し、ユーザーの機密データと攻撃者の指示を、同じコンテキストの中に取り込んでしまいました。アシスタントはその指示に従い、盗んだデータをエンコードしてリンクに埋め込み、それを自らの回答の中に配置したのです。

なぜ重要か： データが外部に流出したのは、ユーザーがそのリンクをクリックした瞬間でした。ここでひな型が確立されました。取得（リトリーバル）に支えられたアシスタントは、攻撃者のテキストを読み込み、それを命令として扱うのです——マルウェアもエクスプロイトもまったく見当たらないままに。

EchoLeak（Aim Labs、2025年）／Microsoft 365 Copilot

攻撃経路： ごく普通のメールに埋め込まれた、隠しプロンプト。

何が起きたか： Copilotが通常業務の中でそのメールをコンテキストに取り込み、自らの権限を侵害する方向へと誘導されました。これは「スコープ違反」であり、エージェントが正当に保持しているアクセス権を、攻撃者のために使ってしまう状態です。いわゆる「混乱した代理人（confused deputy）」として振る舞ってしまいます。

なぜ重要か： 機密データが、ゼロクリックでテナントの外へ流出しました。本番稼働している企業向けAIアシスタントからの、世界初の現実的なゼロクリック持ち出しです。指摘できるユーザーのミスもなければ、たどれるリンクもありません。露出は、その企業が導入し、信頼しているツールの内部で完結して起きます。Slack AIには、まだ被害者のクリックが必要でした。EchoLeakには、何も要りませんでした。

そして次に、攻撃面はソフトウェアが作られる場所へと移りました。

CursorのMCP経由RCE、CVE-2025-49150（2025年）

攻撃経路： 悪意あるModel Context Protocol（MCP）サーバー。Cursorがそれらの接続を処理する仕組みを通じて到達しました。

何が起きたか： インジェクションは、開発者のマシン上でのリモートコード実行（RCE）にまでエスカレートしました。これは、IDEsaster研究でカタログ化された30件超のコーディングアシスタント関連CVEの1つです。

なぜ重要か： ここで一気に賭け金が跳ね上がります。もはやアシスタントが機密を漏らすという話ではありません。アシスタントが、エンジニアのノートPC上で攻撃者のコードを実行するという話なのです。

GitHub MCPの「Toxic Agent Flow」（Invariant Labs、2025年）

攻撃経路： 公開リポジトリに登録された、罠を仕掛けたGitHub Issue。

何が起きたか： ある開発者のエージェントがGitHubのMCPサーバーを通じてそのIssueを読み込むと、埋め込まれた指示がエージェントをユーザーのプライベートリポジトリへ向かわせ、そこから公開リポジトリ上のプルリクエストを通じて外へ持ち出させました。サーバーのトークンが包括的なアクセス権を持っていたため、その境界を越えることを阻むものは何もありませんでした。

なぜ重要か： たった1件の公開Issueが、プライベートなコードへの経路になってしまいました。セキュリティチームが直接責任を負う、知的財産と信頼の境界が、盗まれた認証情報も侵害されたシステムもないまま越えられたのです。私たちがエージェントに接続する連携機能は、そのエージェントの到達範囲をそのまま引き継ぎます。

Rules Fileバックドア（Pillar Security、2025年）

攻撃経路： プロジェクトごとのAI設定ファイル。.cursorrules や copilot-instructions.md など、アシスタントが常時参照するガイダンスとして読み込むファイルです。

何が起きたか： これらのファイルに、隠された指示を密輸できることが示されました。感染したリポジトリをクローンし、それをAI搭載のIDEで開いた開発者は、汚染されたルールブックをアシスタントに手渡してしまいます。そのルールブックは、プロジェクトのセットアップを装ってシェルコマンドを発火させることができました。

なぜ重要か： 監査していない依存関係は、もはやライブラリだけの話ではありません。AIツールが、行動へと至る過程で参照するあらゆるファイルが、その対象になります。

そしてついに、インジェクションは単発の出来事ではなくなりました。

Web3 AIエージェントのメモリポイズニング（Singh Patlanら、2025年）

攻撃経路： 単一のプロンプトではなく、エージェントの長期記憶に書き込まれるインジェクション。

何が起きたか： 攻撃者は、あるセッションから次のセッションへと存続する偽の「記憶」を植え付け、後になってエージェントを、運用者が一度も認可していないアクションへと仕向けました。その中には、データの漏洩や、記録に残る事例では資産の移転も含まれていました。

なぜ重要か： ここでの失敗モードは、漏洩ではありません。誰も承認していない指示によって、お金が動くことです。インジェクションと被害とが、時間的に切り離されています。あるやり取りの中での静かな汚染が、後になって、発生源とは何の明白なつながりもないタスク上で炸裂したのです。

ZombAIs：プロンプトインジェクションからC2へ（Rehberger、2024年）

攻撃経路： マシンを操作できる手を持つエージェント（Claude Computer Use）を狙った、間接インジェクション。

何が起きたか： 仕込まれた指示が、エージェントを攻撃者の指令統制（C2）ループへと組み込み、アシスタントを、攻撃者が操作できるノードへと変えてしまいました。

なぜ重要か： ここでAIは、標的であることをやめ、武器になります。プロンプトインジェクション可能なエージェントは、敵対者にとって、単なる被害者としてではなく、インフラとして有用なのです。

‍

7つの事案すべてに共通するパターンは、まったく同じです。

指示は、エージェントが読み込むよう設計された入力を通じて届きます。エージェントはそれを正当な業務の一部として処理します。そして行動します。リンクを送り、プロセスを起動し、プライベートリポジトリへ越境し、送金を実行し、C2に接続します。ここで致命的な三要素が機能しています。機密データへのアクセス、信頼できないコンテンツへの露出、そして外部への通信手段です。

製品も攻撃面も異なりますが、構造は同じです。そしてどの事案でも、被害が生じたのは、モデルがだまされた時ではなく、エージェントが行動を起こした時でした。

プロンプトインジェクションとジェイルブレイクの違いは何か

プロンプトインジェクションは「仕組み」です。ジェイルブレイクは、その仕組みで達成しうる「目的」の1つにすぎません。

プロンプトインジェクションは、構造的な脆弱性です。

前述のとおり、LLMは命令とデータを確実に切り分けることができません。どちらも同じ種類のテキストとして届くからです。モデルが読み込むコンテンツを紛れ込ませられる攻撃者なら、誰でもモデルの動作をそらせる可能性があります。

ジェイルブレイクは、その攻撃経路の中にある1つの目的です。

しかも狭い目的です。すなわち、モデルに安全上の制約を回避させ、本来出力すべきでないものを生成させることです。

この区別が重要な理由は、次のとおりです。

ジェイルブレイクは、プロンプトインジェクションの用途の1つにすぎません。

まったく同じ仕組みで、データを持ち出し、エージェントのアクションを乗っ取り、記憶を汚染し、マルチエージェントシステム全体に指示を伝播させることができます。2024年から2026年にかけての主要な事案のほとんどは、ジェイルブレイクとはまったく無関係でした。

要点をまとめると、ジェイルブレイクは直接インジェクションの一部分であり、攻撃者が安全フィルターを回避するために指示をタイプ入力するものです。一方、取得されたコンテンツを通じて指示が届く間接インジェクションこそが、今日ではより大きく、より重大な影響を持つカテゴリです。

現在のプロンプトインジェクション防御が失敗し続ける理由

ここまでのプロンプトインジェクションの話が暗く感じられたなら、ここからはさらに正直に向き合う番です。

標準的な対策リストにある主要な緩和策は、いずれも明確な限界（天井）を抱えています。有用なものもあります。ですが、問題を解決するものは1つもありません。そしてほとんどは、攻撃者が適応してくると、予測可能な形で破られてしまいます。

以下の表で、それぞれを整理します。

次に、研究コミュニティが見出していることを検討しましょう。

最も洗練された防御でさえ、その隙間を完全には塞げていません。

インジェクションへの耐性を持つようモデルを訓練するファインチューニング系のアプローチは、日常的な攻撃に対して確かに実質的な進歩を見せます。ですが、圧力がかかると崩れてしまいます。公開されている最強の防御である「SecAlign」でも、最適化ベースの攻撃——モデルを通り抜ける最も弱い経路を見つけ出すために作られた攻撃——をおよそ10回に1回は取りこぼします。他の有力なアプローチでは、より広い隙間が見られ、最強の最適化ベース攻撃に対して攻撃成功率が40%を超えるものもあります（Chenら「SecAlign: Defending Against Prompt Injection with Preference Optimization」2025年）。

さらに、近年の研究はより根深い問題を明らかにしています。適応型攻撃——攻撃者が防御側の挙動を把握している攻撃——は、十分な最適化の時間を与えれば、公開された防御の90%以上を回避してしまいます（Nasrら「The Attacker Moves Second: Stronger Adaptive Attacks Bypass Defenses Against LLM Jailbreaks and Prompt Injections」2025年）。

この分野の現状についての、正直な見立ては次のとおりです。

これが防御側にとって意味するところは、次のとおりです。

予防は必要です。それは攻撃面を減らし、容易なケースをブロックし、時間を稼ぎます。これらの防御を重ねることは役に立ちます。しかし、各層はそれぞれ固有の失敗モードを次の層へと持ち越します。そして、適応型の手法に投資をいとわない攻撃者は、いずれ通り抜ける経路を見つけ出します。

これが転換点です。予防は答えの一部です。ですが、答えのすべてではありません。

多層的なプロンプトインジェクション防御を分解する

予防だけではプロンプトインジェクションを解決できないなら、真の防御とはどのようなものでしょうか。

それは「多層的」です。

3つの層が、それぞれ他の層にはできない仕事を担います。モデルとエージェントのレベルでのアーキテクチャによる予防、アクションのレベルでのランタイム検知、そしてプログラムのレベルでのガバナンスです。どれ1つとして、単独では十分ではありません。

これらを組み合わせることで、どの単一のアプローチにもできない形でリスクを削減できます。

アーキテクチャによる予防

アーキテクチャによる予防は、エージェントにできることを制限することで、インジェクションが成功しても攻撃者が使えるものを少なくします。悪意ある指示を見つけ出したり、フィルターで除去したりしようとはしません。信頼できないコンテンツを、設計として最初から信頼できないものとして扱います。

仕組み：

• 能力ベース（capability-based）のアーキテクチャは、計画と実行を分離します。エージェントは、攻撃者の管理下にあるコンテンツに触れる前に、どのツールを使うかを確定させます。
• デュアルモデル設計は、アクションを実行する特権を持つモデルを、外部データを読み込む隔離されたモデルから切り離します。
• 情報フロー制御は、信頼できる指示と信頼できない入力との間で何が受け渡し可能かについて、厳格なルールを強制します。

とらえるもの： 影響範囲（ブラストラジアス）です。インジェクションが成功しても、アーキテクチャが既に許可している範囲にしか到達できないため、攻撃者ははるかに小さなアクションの範囲に閉じ込められます。

取りこぼすもの： インジェクションそのものです。よく設計されたエージェントの内部にも、それは依然として着弾します。設計は、それができることに上限を設けるだけです。しかも、これらのパターンは最初から作り込んでおく必要があり、既存のエージェントに後付けするのは困難です。

ランタイム検知

ランタイム検知は、エージェントが稼働してから実際に何をするかを監視することで、予防が取りこぼしたものをとらえます。インジェクションそのものは目に見えません。それはモデルのコンテキスト内で起きるため、システムコールレベルの計装では見えないからです。しかし、インジェクションはアクションを生み出し、アクションはシステムに触れます。

仕組み：

• ツール呼び出しとシステムコールは、タスクに合わないアクションにフラグを立てます。たとえば、普段は文書を要約しているエージェントが、突然API呼び出しを発火させるような場合です。
• ファイルとデータへのアクセスは、エージェントが触れる用のないデータに手を伸ばすのをとらえます。
• **ネットワークの外向き通信（egress）**は、一見正当に見えるチャネルを通じてデータが外部へ出ていく様子を浮かび上がらせます。
• 行動ベースラインは、各アクションをエージェントの通常パターンと照らし合わせて計測し、逸脱を際立たせます。

とらえるもの： インジェクション成功後の結果を、それが起きているその瞬間にとらえます。異常なツール利用、あるべきでない場所へのデータ移動、静かな持ち出しなどです。被害がシステムに触れるからこそ、被害が可視化されます。

取りこぼすもの： インジェクションそのもの、モデルの推論、そして誤ったアクションの背後にあるアテンション（注意）パターンです。ランタイム検知が見るのは結果であって、意図ではありません。とらえられるのは被害であって、それを引き起こした操作ではないのです。

ガバナンス統合

ガバナンスは、プロンプトインジェクションが「誰もがリスクだと認めているのに、誰も責任を負わない」状態になるのを防ぎます。AIのために別立ての体制を立ち上げるのではなく、この脅威を、既に運用している説明責任の構造の上に対応づけます。

その対応づけは、すでに存在しています。

• OWASP Top 10 for Large Language Model Applicationsは、プロンプトインジェクションを最上位のLLMリスクに位置づけています。
• MITRE ATLASは、これに技術ID（AML.T0051）を割り当てており、チームが既に行っている脅威モデリングに組み込めます。
• NISTのAI RMFと、ファイブ・アイズの「Careful Adoption of Agentic AI Services」ガイダンスは、これを、いまや企業が運用を期待されているAIリスクプログラムの中に組み込んでいます。

その見返りが「責任の所在（オーナーシップ）」です。プロンプトインジェクションが、監査・統制の責任者・報告ラインを備えたフレームワークの中に位置づけられれば、それは他のあらゆる追跡対象リスクと同じように扱われます。すなわち、割り当てられ、計測され、解決されます。これを特異なものとして扱えば、明確な責任者のいないまま複数のチームに分散してしまいます。つながったものとして扱えば、あなたが責任を負う他のすべてと同じように解決されていきます。

プロンプトインジェクション防御プログラムを運用に乗せる方法

プロンプトインジェクション防御プログラムを運用に乗せるとは、次のことを意味します。

• 説明責任のギャップを埋めること
• エージェントが何を、なぜ行ったのかを再構成できるよう、エージェントを計装すること
• そのテレメトリを、リスクを他と同じように割り当て・計測・解決するプログラムで包み込むこと

出発点として最も適切なのは、説明責任のギャップです。

これこそ、ファイブ・アイズのガイダンスが中核的な問題として指摘しているものです。エージェントに何か問題が起きたとき、セキュリティチームは、それが何を、なぜ、どんな権限で行ったのかを再構成する必要があります。従来型の監査ログは、それを捕捉できません。エージェントの意思決定は確率的な推論の連鎖を経て進み、その連鎖は、SOC（セキュリティオペレーションセンター）が前提とする「いつ・誰が・何をしたか」という記録にきれいには対応しないのです。

実際には、あるエージェントが機密データに触れるアクションを起こすとします。それを再構成するには、監査担当者は次を知る必要があります。

• どの入力がその意思決定の引き金になったか
• どのツールが、どのリソースに対して呼び出されたか
• その時点で、そのアクションが認可されていたか

しかし、エージェントは自らを説明できないかもしれず、ログにはツール呼び出しが記録されていても、その背後の推論は残っていないかもしれません。その連鎖を再構成するには、従来のインシデント対応が想定していなかった労力がかかります。

行動の可観測性（オブザーバビリティ）は、このギャップを狭めます。ただし、完全に閉じることは決してありません。

エージェントが起こすあらゆるアクション——ツール呼び出し、データアクセス、そして取得可能な範囲での推論ステップ——をログに記録すれば、SOCと監査担当者に、手がかりとなるものが与えられます。そのうえでベースラインが、異常検知を扱いやすくします。

• このエージェントは通常、どのツールを呼び出すか？
• どんな順序で？
• どのデータに対して？

そのベースラインができれば、パターンを崩すものはすべて、調査する価値のあるものとして際立ちます。ただし、限界は知っておくべきです。エージェントの推論の一部は、まだ追跡できません。可観測性は近いところまで連れて行ってくれますが、少なくとも研究が追いつくまでは、答えのすべてではありません。

プログラムは、その土台の上に構築されるものです。

成熟度を示す最も明確なシグナルは、どの統制が導入されているかではありません。それは、プログラムが、理論上の発見事項の長大なバックログ——減るより速く増えていくもの——ではなく、解決されていく短く確度の高いリスクのリストを生み出しているかどうかです。

実際には、成熟したプログラムには一貫した特徴の集合が現れます。

• エージェント型システムの脅威モデリングが、エージェントのリスク向けに作られた手法を用いて、デプロイ前に行われています。
• エージェントのアイデンティティ・アクセス・ツール権限が、人間向けIAMの後付けではなく、独立したアクセス管理のカテゴリとして扱われています。
• テレメトリが、エラーだけでなく、エージェントのアクション連鎖の全体を捕捉しています。
• 本番稼働するすべてのエージェントについて、行動ベースラインが存在しています。
• アクション層での検知が、単独のツールとしてではなく、既存のSOCワークフローに組み込まれています。
• 発見事項が、組織が既に答えを出すべきガバナンスフレームワークに対応づけられています。
• クラウドセキュリティ、アプリケーションセキュリティ（AppSec）、AIプログラムの責任者、そしてSOCが、足並みをそろえ続けています。

これらは目印であって、チェックリストではありません。1つを満たしていても未成熟なプログラムはありえますし、逆にほとんどを欠いていれば、まだ運用可能な段階には至っていません。

プラットフォームは土台であり、プログラムはその上に築かれます。

どちらも単独では仕事を完遂できません。プログラムのないプラットフォームは、誰も責任を負わないツールです。プラットフォームのないプログラムは、誰も強制できないポリシーです。両者がそろって初めて、組織は、エージェントを責任を持って導入し、何か問題が起きたときに対応するために必要なものを手に入れます。

プロンプトインジェクションはどう進化しているのか？

プロンプトインジェクションは、より広い攻撃面へと、そして安易な解決策から遠ざかる方向へと進化しています。エージェントがより多くのツールと、そして互いにつながるにつれ、そこへ到達する手段は増殖します。そして防御研究は、進歩しているとはいえ、依然としてそれを完全には止められません。

プロンプトインジェクションは静的なものではありません。攻撃面は拡大し、防御研究は前進しており、今後12〜24か月にとって最も重要な変化が3つあります。

MCPが攻撃面を増殖させています。

Model Context Protocol（MCP）は、いまやエージェントをツールやデータに接続する支配的な方法です。エージェントが会話するあらゆるサーバーが、潜在的な露出になります。ツールの説明文、サーバーの応答、メタデータ——そのすべてがモデルに読み込まれ、モデルが実行してしまう指示を運びかねません。

CursorのRCEは、その早期のシグナルでした。悪意あるMCPサーバーを、リモートコード実行へと変えたのです。導入が加速するにつれ、エージェントはより多くのサーバーに到達するようになり、そのほとんどはインジェクションについて精査されないでしょう。

マルチエージェントシステムが、信頼の問題を複雑にします。

エージェントが他のエージェントを呼び出すとき、信頼の連鎖が伝播します。侵害された1つの上流エージェントは、その出力を権威あるものとして扱うすべての下流エージェントを汚染します。

脅威モデルは、「攻撃者が私のエージェントに到達する」から、「攻撃者が私の依存グラフの中のどれか1つのエージェントに到達する」へと変わります。そこには、誰も監査していないサードパーティ製のエージェントも含まれます。インジェクションは、サプライチェーンの問題になるのです。

研究の最前線は、アーキテクチャへとシフトしています。

防御は、フィルターからアーキテクチャへと移りつつあります。それは正しい方向ですが、完成した答えではありません。

プロンプトインジェクションは、賭け金の高い環境で完全に自律したエージェントにとっては、依然として未解決です。だからこそファイブ・アイズは、重大な意思決定の場面では人間による監督を伴う段階的な導入を助言しています。その足跡（攻撃面の広がり）は、防御よりも速く拡大しています。これを見越して計画するチームは、次のモデルが解決してくれるのを待つチームよりも、はるかに有利な立場に立つでしょう。

‍

‍

プロンプトインジェクションに関するFAQ