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

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

プロンプトインジェクションは『AI が読む文脈を乗っ取る問題』です

プロンプトインジェクションとは、AI システムが参照する文脈の中へ意図しない指示を紛れ込ませ、元の安全方針や処理目的を崩す問題です。NIST の用語集でも、モデルの挙動を変えるために細工した入力を使う攻撃として整理されています。重要なのは、ここでいう入力が利用者の入力欄だけではないことです。今の AI システムは検索取得、Web 取得、ツール説明情報、メール要約、MCP 連携など多様な文脈を読むため、どこから指示が混ざるかを実装側が管理しないと境界が崩れます。

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

さらにプロンプトインジェクションは、単なるモデル品質の問題でもありません。もし外部コンテンツがツール呼び出しや外部送信と結びつく構成なら、影響は回答の誤りで終わらず、検索、取得、更新、通知、実行まで伸びます。だからプロンプトインジェクションは「変な回答が出るかもしれない」ではなく、AI による操作境界がずれる危険として見る必要があります。

直接型と間接型では、守るべき境界が違います

直接型のプロンプトインジェクションは、利用者が入力欄へ明示的に危険な指示を入れる型です。比較的イメージしやすく、テストもしやすい一方、最近の実装で問題になりやすいのは間接型です。これは外部文書、Web ページ、メール、チケット、ナレッジベース、ツール説明文など、利用者が「指示」と意識していない文脈の中に指示が入り、それが AI に実行可能な情報として読まれる型です。Microsoft の MCP 関連の注意喚起も、間接型を中心に警戒しています。

両者の違いは攻撃の見え方より、守るべき境界にあります。直接型では利用者入力の検査が中心になりますが、間接型では取得結果と文脈組み立ての設計が中心です。つまり対策はモデルの前段にあり、何を文脈へ載せるかを決める実装が最も重要になります。

危険な単語を止めるだけでは不十分です

この違いを理解していないと、開発チームは「危険な文言を遮断する」方向へ寄りがちです。しかし間接型では、危険な指示が丁寧な文書、注釈、よくある質問、HTML コメント、説明情報、MCP の応答のように見えることがあります。だから重要なのは禁止語の一覧単体ではなく、そもそも非信頼コンテンツを命令として扱わないことです。

もう一つ見落とされやすいのは、プロンプトインジェクションが「AI が勝手に危険になる」現象ではなく、開発側が文脈の役割を曖昧にした結果として起きることです。取得文書をそのままシステム指示の近くへ連結したり、ツール説明文を検証せず信頼済み案内として扱ったりすると、問題はモデルの賢さより前に始まっています。したがって対策は追加の禁止文だけでなく、入力の出所と役割を設計段階で固定することに向かうべきです。

なぜ MCP やツール説明情報、外部文書で危険が増えるのか

モデル自身より、周辺の文脈組み立てが複雑になっているからです

近年の AI システムは、単独の会話モデルより、検索取得、MCP、ブラウザ操作、チケット要約、ナレッジ参照、各種ツールを束ねた構成が主流になっています。するとモデルに渡る文脈は、人間が直接入力した短い文ではなく、複数の情報源をつないだ長いペイロードになります。このとき、信頼済みのシステム指示と非信頼の外部文書が同じ入れ物へ混ざると、プロンプトインジェクションが成立しやすくなります。

Microsoft の間接型プロンプトインジェクション注意喚起や OWASP の MCP Top 10 が強調しているのも、この文脈です。MCP ではツールやサーバーが返す説明情報、リソース説明、外部コンテンツがエージェントの判断材料になるため、単に入力欄を整形しても十分ではありません。危険なのはモデルそのものより、周辺システムが『何を信頼済みとして渡すか』を曖昧にしたまま組み合わせることです。

ツール説明文の汚染は『AI 向けの説明』がそのまま攻撃面になる問題です

プロンプトインジェクションを考えるとき、利用者の入力だけに注目すると、ツール説明文の汚染を見落とします。ツールの名称、説明、利用案内、サーバーから返る指示、リソース説明は、AI から見ればすべて判断材料です。もしそこへ攻撃者が影響できると、AI はシステム方針より説明文を優先したり、外部送信や権限の強い操作へ誘導されたりする可能性があります。つまりこれは、人間向けの説明がそのまま AI 向けの命令面になる問題です。

既存の シャドーAPIとは？ や ソフトウェア供給網攻撃とは？ が API や配布物の公開面を主役にしているのに対して、プロンプトインジェクションの論点は「説明文や外部文書が命令として扱われる」ことです。ここを切り分けると、AI システムでは実装コードそのもの以上に、周辺の説明情報と文脈の扱いが重要だと分かります。

広い権限のツールがつながると、被害は回答ミスで終わりません

プロンプトインジェクションが怖いのは、変な回答が出ること自体ではなく、それが外部送信、記録更新、通知、実行へ届くことです。OpenAI のエージェント安全設計ガイドや Anthropic の Claude Code セキュリティ文書も、人手承認や最小権限が重要だと強調しています。つまり防御は「悪い指示を見抜く」だけでなく、誤った文脈が高権限操作へ伸びない構造を作ることにあります。

もし閲覧、検索、更新、送信、実行を同じ権限で束ねているなら、一つの汚染文脈がそのまま重大操作へ伸びやすくなります。プロンプトインジェクションを実務で怖いと感じるべき理由はここです。

企業で起きやすい攻撃シナリオは何か

検索取得型では『参考資料』に見える文書が命令へ変わります

企業システムで最も起きやすいのは、検索取得型のアシスタントです。社内文書検索、外部 FAQ 要約、サポート文書参照のような機能では、参考資料として読ませた文書の中に危険な指示が含まれていると、それが回答生成だけでなく次の操作判断へ影響します。特に「この文書を読んだら次に何をするか」を同じ流れで組んでいると、参照用の文書が実行命令へ化ける危険があります。

たとえば社内外の文書を統合して調べものをさせる場合、文書本文の中に「前の指示を無視せよ」「この操作を実行せよ」に相当する文字列が混ざっていても、人間の目には注釈や補足にしか見えないことがあります。ここで文脈分離をしていないと、AI はそれを同じ重みの指示として読んでしまいます。

メール、チケット、チャット要約では『日常業務の文面』が入口になります

メール要約、問い合わせ票の整理、社内チャット要約も危険です。これらは文章量が多く、外部から届く内容が混ざるため、危険な指示が自然文へ紛れ込みやすいからです。しかも担当者は「日常業務の文面」として読むため、不審な指示が紛れていても気付きにくく、運用に溶け込んだまま AI の判断へ入りやすいという特徴があります。

特に承認依頼、問い合わせ自動分類、返信草案作成のような業務では、AI が次の行動を提案したり、場合によっては外部送信の直前まで進んだりします。ここでは入力欄より、要約対象データの扱いと送信前確認の設計が重要です。

MCP 連携では、説明情報と接続先の権限が同時に論点になります

MCP では、サーバーが返す説明情報やリソース情報がエージェントの判断材料になります。そのため危険なのは、MCP サーバー自体が改ざんされている場合だけではありません。接続先が信頼済みと誤認され、広い権限のツール説明がそのまま判断材料になると、接続先の説明情報が命令面へ変わることがあります。

MCP を入れると開発効率は上がりますが、同時に「どのサーバーを許可するか」「どの説明情報をそのまま読ませるか」「承認なしで何を実行させないか」を詰める必要が出ます。ここを省くと、MCP 連携は便利な接続ではなく、新しい攻撃面になります。

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

最初に必要なのはモデルへの禁止文ではなく入力境界です

企業でプロンプトインジェクション対策を始めるとき、多くのチームはシステム指示の追加ルールや禁止文言の列挙から入ります。もちろん必要ですが、最初に置くべき防御線はそこではありません。先にやるべきなのは、利用者入力、外部文書、Web 取得、ツール説明情報、内部ポリシー、システム指示を分けることです。どの入力を信頼済みとし、どれを非信頼とするかが決まっていないと、後段のルールはすべて場当たりになります。

NIST AI 100-2 でも、AI の安全な開発ではシステム境界と依存関係の境界を明確にすることが重視されています。プロンプトインジェクションに置き換えると、それは「どの文脈が命令になり、どの文脈が参照専用なのか」を分けることです。つまり最初の対策は、AI に入る文脈の役割を分離する設計です。

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

プロンプトインジェクションが怖いのは、回答が変わること自体ではなく、外部送信、更新、削除、実行などの操作へ届くことです。だから対策では、モデルの出力品質よりも、ツールの権限と実行条件を先に見直す方が効果が大きくなります。検索、参照、要約、通知、作成、更新、実行を同じ権限で束ねると、一つの汚染文脈がそのまま高権限操作へ伸びやすくなります。

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

構造化された受け渡しができる箇所は、自由文を減らした方が安全です

OpenAI のエージェント安全設計でも、外部入力をそのまま自由文として次の処理へ流すのではなく、列挙値や検証済みの構造化項目へ落とすことが勧められています。これは、危険な指示が長文の一部へ紛れ込んでも、次のノードやツールがそれをそのまま命令として扱わないようにするためです。つまり、自由文でつながっている部分ほど危険が広がりやすいと考えると整理しやすくなります。

もちろん構造化だけで完全に防げるわけではありませんが、「参照用の文書は要約だけ渡す」「外部入力から取り出すのは検証済みの項目だけにする」といった設計は、被害の伸び方をかなり抑えます。モデルの賢さに期待するより、不審な文脈がそのまま次段へ渡らない構造を作る方が再現性のある対策です。

実装と運用でどこを監査すべきか

監査対象は入力欄ではなく、取得結果と文脈組み立て全体です

企業でよくある失敗は、プロンプトインジェクションのテストを「危険な文を入力欄へ打ち込むこと」だけにしてしまうことです。これでは間接型の多くを見落とします。実際のテストでは、URL 先の文書、添付ファイル、よくある質問、チケット本文、ナレッジベース、ツール説明文のどこに指示が混ざると挙動が変わるかを見る必要があります。つまり点検対象は入力欄ではなく、文脈組み立て全体です。

そのため監査では、どの取得元が非信頼か、どの変換工程を通るか、どこで切り捨てや構造化を行うかまで残しておく必要があります。これがないと、事故が起きても再現性を持って原因をたどれません。

とくに社内の複数チームが別々に検索取得や MCP 連携を足していく構成では、どこで文脈が混ざったのかを後から見失いやすくなります。監査対象を最初から一覧化し、文脈の通り道ごとに責任分界を決めておくと、事故後の切り分けと再発防止を同じ資料で回しやすくなります。

ログでは『どの文脈から判断が変わったか』を追える必要があります

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

特にメールや問い合わせの要約では、元文書、要約結果、使われたツール、送信前の確認履歴をつないで見られると、誤作動の再現と是正が格段に早くなります。プロンプトインジェクション対策は、遮断だけでなく事後分析のしやすさも重要です。

AI チームだけでなく、アプリケーション担当と運用担当が同じ境界表を見るべきです

プロンプトインジェクションをモデル担当だけの課題にすると、検索取得、MCP、ブラウザ、サポート運用側の設計が盲点になります。実際には、アプリケーション担当、運用担当、セキュリティ担当が同じ入力境界表を参照し、どのソースが非信頼かを共有しておく必要があります。そうしないと、モデル側が注意しても周辺システム側で危険な文脈がそのまま流れ込みます。

つまりプロンプトインジェクション対策は、AI 単体の調整ではなく、周辺システムまで含む設計レビューとして回すべきです。ここまでやると、危険な文書が紛れ込んだときも、どの境界で止めるかをチーム間で共有しやすくなります。

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

ASM診断 PRO はプロンプトインジェクションを直接検知する製品ではありませんし、AI ゲートウェイや方針エンジンの代替でもありません。それでも導線として意味があるのは、AI システムが参照する公開ホスト、ドキュメント、検証環境、API、管理画面が外からどう見えているかを先に整理できるからです。プロンプトインジェクションの多くは、利用者の入力欄より、外部から取り込む文脈の出所が曖昧なまま増えていくところから始まります。

たとえば公開ドキュメント、古いサポートページ、用途不明の API ホスト、検証用サブドメインが残っていると、AI エージェントや検索取得システムはそれらを「参照できる文脈」として取り込みやすくなります。ASM診断 PRO を起点に外から見える接点を整理しておくと、「どの公開面は検索取得対象から外すべきか」「どのホストは非信頼文脈として扱うべきか」を決めやすくなります。つまり価値は、プロンプトインジェクションを広く恐れるのではなく、AI が取り込みうる外部文脈を棚卸しできることにあります。

既存の シャドーAPIとは？、外部接続点は見えているか？、シャドーAIとは？ と合わせて見ると、プロンプトインジェクションをモデル内部の話で終わらせず、外部接点、未承認利用、公開ドキュメント、API 露出を横断して見直せます。AI システムの入力境界を実務へ落としたいなら、まずは外から見える公開接点の整理から始めてください。

よくある質問（FAQ）

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

重なる部分はありますが同じではありません。プロンプトインジェクションは外部文書やツール説明情報を通じてシステムの境界を崩す問題も含むため、利用者入力だけを想定したジェイルブレイクより広い実装課題です。

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

それだけでは不十分です。間接型では、よくある質問、HTML、注釈、説明情報、外部文書の中に指示が紛れ込むため、入力境界と文脈分離が必要です。

検索取得を使わなければ安全ですか

安全性は上がる面がありますが、ツール説明情報、MCP の応答、URL 要約、外部メールなど別の文脈からも成立するため、検索取得を外すだけでは十分ではありません。

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

入力欄の入出力だけでなく、取得結果、ツール呼び出し、外部送信、MCP 経由の説明情報、承認を経ずに実行された操作を見てください。

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

信頼済み入力と非信頼入力を分け、書き込みや送信を行うツールを最小権限化し、外部文書を命令として扱わない設計を最初に置くことです。

まとめ

プロンプトインジェクションは、危険な文章を入力欄へ入れる問題だけではありません。今の AI システムでは、検索取得、URL、公開ドキュメント、チケット、メール、MCP、ツール説明情報のような周辺文脈がモデルの判断材料になり、それらが同じ文脈へ混ざることで間接型の攻撃が成立しやすくなっています。だから本質は「AI がだまされる」ことより、どの入力を信頼済みとみなしてシステムの内部へ入れているかが曖昧なことにあります。

実務で最初にやるべきなのは、危険な単語一覧を増やすことではなく、利用者入力、外部文書、取得結果、ツール説明、システム指示を分けることです。その上で、書き込みや送信につながるツールを最小権限化し、重要な実行判断に確認フローを置き、取得結果と文脈組み立てを監査対象にします。こうするとプロンプトインジェクションを完全にゼロにできなくても、誤った文脈が重大操作へ伸びる経路はかなり削れます。

さらに、プロンプトインジェクションはモデル担当だけの問題ではありません。公開ドキュメント、API、検証環境、サポート運用、MCP サーバー、ナレッジベースなど、AI が参照する外部接点の整理と一緒に見直す必要があります。つまり対策は、プロンプト設計単独ではなく、入力境界、ツール権限、公開面の可視化をつないだ設計と運用の問題です。そこまで整理できると、AI システムを便利さだけでなく、境界を持った業務基盤として扱いやすくなります。