プロンプトインジェクションとは？間接攻撃・MCP悪用・対策を徹底解説

プロンプトインジェクションとは何か

prompt injection は『AI が読む文脈を乗っ取る問題』です

prompt injection とは、AI system が参照する文脈の中へ意図しない instruction を紛れ込ませ、元の安全方針や処理目的を崩す問題です。NIST の glossary でも prompt injection は、model の挙動を変えるために crafted input を使う攻撃として整理されています。重要なのは、ここでいう input が利用者の入力欄だけではないことです。今の AI system は retrieval、Web 取得、tool metadata、メール要約、MCP 連携など多様な文脈を読むため、どこから instruction が混ざるかを実装側が管理しないと境界が崩れます。

既存の シャドーAIとは？ が未承認利用を主役にしているのに対して、本記事の主役は AI system の内部境界です。つまり「AI を使うべきか」ではなく、「使うならどこを信用し、どこを不審入力として扱うべきか」を整理する記事です。この切り分けをしないと、AI security を broad に語るだけで、どこに最初の防御線を置くべきか が見えません。

さらに prompt injection は、単なる model quality の問題でもありません。もし external content が tool invocation や外部送信と結びつく構成なら、影響は回答の誤りで終わらず、検索、取得、更新、通知、実行まで伸びます。だから prompt injection は「変な回答が出るかもしれない」ではなく、AI による操作境界がずれる危険として見る必要があります。

direct と indirect では、守るべき境界が違います

direct prompt injection は、利用者が入力欄へ明示的に instruction を入れる型です。比較的イメージしやすく、テストもしやすい一方、最近の実装で問題になりやすいのは indirect prompt injection です。これは外部文書、Web ページ、メール、チケット、ナレッジベース、tool description など、利用者が「指示」と意識していない文脈の中に instruction が入り、それが AI に実行可能な情報として読まれる型です。Microsoft の MCP 関連 guidance も、indirect attack を中心に警戒しています。

両者の違いは、攻撃の見え方より、守るべき boundary にあります。direct 型では user input validation が中心になりますが、indirect 型では retrieval と context assembly の設計が中心です。つまり prompt injection 対策は model の前段にあり、何を context に載せるかを決める実装 が最も重要になります。

この違いを理解していないと、開発チームは「危険な文言を block する」方向へ寄りがちです。しかし indirect 型では、危険な instruction が丁寧な文書、FAQ、説明文、注釈、HTML comment、metadata、MCP payload のように見えることがあります。だから重要なのは blacklist 単体ではなく、そもそも untrusted content を command として扱わないことです。

もう一つ見落とされやすいのは、prompt injection が「AI が勝手に危険になる」現象ではなく、開発側が context の役割を曖昧にした結果として起きることです。たとえば取得文書をそのまま system prompt の近くへ連結したり、tool description を検証せず信頼済み guidance として扱ったりすると、問題は model の賢さより前に始まっています。したがって対策は追加の禁止文だけでなく、入力の出所と役割を設計段階で固定することに向かうべきです。

なぜ MCP や tool metadata、外部文書で危険が増えるのか

LLM 自身より、周辺の context assembly が複雑になっているからです

近年の AI system は、単独の chat model より、retrieval、MCP、browser、ticket、knowledge base、agent tool を束ねた構成が主流になっています。すると model に渡る context は、人間が直接入力した短い文ではなく、複数の情報源をつないだ長い payload になります。このとき、trusted な system instruction と untrusted な外部文書が同じ入れ物へ混ざると、prompt injection が成立しやすくなります。

Microsoft の indirect injection guidance や OWASP MCP Top 10 が強調しているのも、この文脈です。MCP では tool や server が返す metadata、resource description、external content が agent の判断材料になるため、単に prompt 欄を sanitize しても十分ではありません。危険なのは model そのものより、周辺システムが『何を信用済みとして渡すか』を曖昧にしたまま組み合わせることです。

たとえば URL 要約、文書検索、チケット要約、メール triage のような業務は、実務上とても便利です。しかし便利さの代わりに、AI は「利用者が見ている文書」ではなく「system が取得してきた文書」をもとに判断するようになります。ここで retrieval content の扱いが曖昧だと、AI は参考資料と命令文を同列に扱い、想定外の tool 呼び出しや情報送信へ進む可能性があります。

tool poisoning は『AI への説明文』がそのまま攻撃面になる問題です

prompt injection を考えるとき、利用者の入力だけに注目すると tool poisoning を見落とします。tool の name、description、usage hint、server から返る guidance、resource metadata は、AI から見ればすべて判断材料です。もしそこへ攻撃者が影響できると、AI は system policy より tool metadata を優先したり、外部送信や権限の強い操作へ誘導されたりする可能性があります。つまり tool poisoning は、人間向けの説明がそのまま AI 向け command 面になる問題です。

既存の シャドーAPIとは？ や ソフトウェアサプライチェーン攻撃とは？ が API や package の公開面を主役にしているのに対して、prompt injection の論点は「説明文や外部文書が instruction として扱われる」ことです。ここを切り分けると、AI system では code そのもの以上に、周辺の metadata と context の扱い が重要だと分かります。

だから設計では、tool description をそのまま model へ渡してよいか、server から返る guidance をどの権限で信頼するか、外部 document を参照用に留めるか、という実装判断が要になります。prompt injection の対策は、良い system prompt を書くことだけではなく、AI に渡す説明文と外部文書の権限を分けることにあります。

企業で最初に置くべき防御線は何か

最初に必要なのは model rule ではなく input boundary です

企業で prompt injection 対策を始めるとき、多くのチームは system prompt の追加ルールや禁止文言の列挙から入ります。もちろん必要ですが、最初に置くべき防御線はそこではありません。先にやるべきなのは、利用者入力、外部文書、Web 取得、tool metadata、内部ポリシー、system directive を分けることです。どの入力を trusted にし、どれを untrusted にするかが決まっていないと、後段の rule はすべて場当たりになります。

NIST AI 100-2 でも、AI の secure development では system boundary と dependency boundary を明確にすることが重視されています。prompt injection に置き換えると、それは「どの文脈が command になり、どの文脈が参照専用なのか」を分けることです。つまり最初の対策は、AI に入る文脈の役割を分離する設計です。

ここが曖昧なまま tool や RAG を増やすと、開発者自身がどの入力を信用しているのか説明できなくなります。その状態では、prompt injection テストをしても再現性がなく、事故時の切り分けも困難です。入力境界をドキュメント化しておくことは、対策であると同時に運用の出発点でもあります。

tool の最小権限化と確認フローが、被害の伸び方を抑えます

prompt injection が怖いのは、回答が変わること自体ではなく、外部送信、更新、削除、実行などの action へ届くことです。だから対策では、モデルの出力品質よりも、tool の権限と handoff 条件を先に見直す方が効果が大きくなります。検索、参照、要約、通知、作成、更新、実行を同じ tool privilege で束ねると、一つの injection がそのまま高権限操作へ伸びやすくなります。

既存の フロントエンドのAPIキー露出とは？ や サービスアカウントのセキュリティとは？ が示すように、権限が強い接点は最小化しなければ事故時の被害範囲を抑えにくくなります。prompt injection でも同じで、agent や tool の権限を狭めることが、AI の境界事故を business impact へ伸ばさない防御線になります。

実務では、読取り系と書込み系を分け、重要操作は明示確認を挟み、外部送信は別承認を通す、といった段差を作るのが現実的です。そうすると injection が完全に防げなくても、回答の誤りと実際の操作を切り離しやすくなります。prompt injection 対策は、完璧に防ぐことだけではなく、誤作動が重大操作へ変わる瞬間を止めることでもあります。

さらに、出力の確認も「内容が自然かどうか」だけでは足りません。AI がどの文脈を根拠にその提案を出したのか、外部文書由来なのか、tool metadata に依存していないかを追えるようにしておくと、誤った誘導が起きたときに原因を再現しやすくなります。つまり防御線は block だけでなく、どの文脈から判断が変わったかを追跡できる可観測性も含みます。

red team 的な点検は prompt だけでなく retrieval を中心に行います

企業でよくある失敗は、prompt injection テストを「危険な文を入力欄へ打ち込むこと」だけにしてしまうことです。これでは indirect 型の多くを見落とします。実際のテストでは、URL 先の文書、添付ファイル、FAQ、チケット本文、knowledge base、tool description のどこに instruction が混ざると挙動が変わるかを見る必要があります。つまり点検対象は prompt 欄ではなく、context assembly 全体です。

そのため、AI 実装の監査では application team と security team が同じ入力境界表を参照し、どのソースが untrusted かを共有しておく必要があります。prompt injection を model team だけの課題にすると、retrieval、MCP、browser、support workflow 側の設計が盲点になります。結局、対策は AI 単体のチューニングではなく、周辺システムまで含む設計レビューとして回すべきです。

AI システムの接点管理を ASM診断 PRO で始めるなら

ASM診断 PRO は prompt injection を直接検知する製品ではありませんし、LLM gateway や policy engine の代替でもありません。それでも導線として意味があるのは、AI system が参照する公開 host、docs、staging、API、管理画面が外からどう見えているかを先に整理できるからです。prompt injection の多くは、利用者の入力欄より、外部から取り込む文脈の出所 が曖昧なまま増えていくところから始まります。

たとえば公開 docs、古い support page、用途不明の API host、検証用 subdomain が残っていると、AI agent や retrieval system はそれらを「参照できる文脈」として取り込みやすくなります。ASM診断 PRO を起点に外から見える接点を整理しておくと、「どの公開面は retrieval 対象から外すべきか」「どの host は untrusted context として扱うべきか」を決めやすくなります。つまり価値は、prompt injection を broad に恐れるのではなく、AI が取り込みうる外部文脈を棚卸しできることにあります。

既存の シャドーAPIとは？、外部接続点は見えているか？、シャドーAIとは？ と合わせて見ると、prompt injection を model 内部の話で終わらせず、外部接点、未承認利用、公開 docs、API exposure を横断して見直せます。AI system の入力境界を実務へ落としたいなら、まずは 外から見える公開接点の整理 から始めてください。

よくある質問（FAQ）

プロンプトインジェクションは jailbreak と同じですか

重なる部分はありますが同じではありません。prompt injection は外部文脈や tool metadata を通じて system の境界を崩す問題も含むため、利用者入力だけを想定した jailbreak より広い実装課題です。

危険な単語を block すれば防げますか

それだけでは不十分です。indirect 型では FAQ、HTML、注釈、metadata、外部文書の中に instruction が紛れ込むため、input boundary と文脈分離が必要です。

RAG を使わなければ安全ですか

安全性は上がる面がありますが、tool metadata、MCP payload、URL 要約、外部メールなど別の文脈からも成立するため、RAG を外すだけでは十分ではありません。

最初に見るべきログはどこですか

prompt 欄の入出力だけでなく、retrieval 結果、tool 呼び出し、外部送信、MCP 経由の metadata、承認を経ずに実行された action を見てください。

企業で一番効果が大きい対策は何ですか

trusted input と untrusted input を分け、書込みや送信を行う tool を最小権限化し、外部文書を command として扱わない設計を最初に置くことです。

まとめ

プロンプトインジェクションは、危険な文章を入力欄へ入れる問題だけではありません。今の AI system では、retrieval、URL、docs、チケット、メール、MCP、tool metadata のような周辺文脈が model の判断材料になり、それらが同じ context へ混ざることで indirect attack が成立しやすくなっています。だから本質は「AI がだまされる」ことより、どの入力を trusted とみなして system の内部へ入れているかが曖昧なことにあります。

実務で最初にやるべきなのは、危険な単語一覧を増やすことではなく、利用者入力、外部文書、retrieval 結果、tool description、system instruction を分けることです。そのうえで、書込みや送信につながる tool を最小権限化し、重要な handoff に確認フローを置き、retrieval と context assembly を監査対象にします。こうすると prompt injection を完全にゼロにできなくても、誤った文脈が重大操作へ伸びる経路はかなり削れます。

さらに、prompt injection は model team だけの問題ではありません。公開 docs、API、staging、support workflow、MCP server、knowledge base など、AI が参照する外部接点の整理と一緒に見直す必要があります。つまり対策は、prompt engineering 単独ではなく、入力境界、tool 権限、公開面の可視化をつないだ設計と運用の問題です。そこまで整理できると、AI system を便利さだけでなく、境界を持った業務基盤として扱いやすくなります。