プロンプトインジェクションとは？生成AI利用時のリスクと対策

プロンプトインジェクションとは"生成AIを標的にした"新たな脅威

プロンプトインジェクションとは、意図的に細工した指示を生成AIに読み込ませ、本来想定されている指示やルールとは異なる動作をさせようとする攻撃手法を指します。例えば、社内の問い合わせに答える生成AIに、問い合わせ文に見せかけた別の指示を混入させ、利用者に見せるべきでない社内情報まで回答させるといった手口です。

従来のサイバー攻撃では、標的型メールなどで利用者の判断・行動を誘導するものや、システムの脆弱性を突いてその動作を変えるものなどが知られてきました。これに対し、プロンプトインジェクションの特徴は、利用者の入力や生成AIが外部から取り込んだ情報を通じて、LLM（大規模言語モデル）の応答や処理を攻撃者の意図する方向へ変えようとする点にあります。

生成AIの中核となるLLMは、あらかじめ与えられた指示だけでなく、利用者の入力も、応答や処理に用いる文脈として一続きに扱います。さらに、Web検索や文書の読み込みなどの機能を使っている場合は、そこから取り込んだ外部の情報も、指示や入力とまとめて処理します。そのため、取り込んだ情報のなかに攻撃者が指示を仕込んでいると、LLMがそれを本来の指示と同じように受け取り、従ってしまう恐れがあります。

攻撃の目的はさまざまですが、企業にとって特に検討が必要なのは、機密情報の漏えいや、AIと連携した業務システムへの不正な操作など、実害につながり得るケースです。こうした攻撃は専門機関でも主要なリスクのひとつとして扱われており、例えばアプリケーションのセキュリティに関する知見を公開している国際的な非営利団体OWASP（Open Worldwide Application Security Project）が公表する、大規模言語モデル（LLM）を用いたアプリケーション向けのリスク一覧（「OWASP Top 10 for LLM Applications 2025」LLM01: Prompt Injection）では、代表的なリスクの第1位（LLM01）にプロンプトインジェクションが挙げられています。これは、生成AIを組み込んだシステムを設計・運用するうえで、入力内容だけでなく、AIに接続するデータ・機能・権限まで含めてリスクを検討する必要があることを示すものです。

参考：OWASP Foundation「LLM01:2025 Prompt Injection」

プロンプトインジェクションの主な2つの侵入経路

プロンプトインジェクションは、不正な指示がどこから入り込むかによって、「直接型」と「間接型」の2つに大別されます。

このうち間接型は、利用者自身が不正な指示を入力していなくても攻撃が成立し得る点に特徴があります。AIにファイルやWebページを読み込ませて処理させる過程で、外部データに含まれた不正な指示が、AIの出力や動作に影響を及ぼす場合があるためです。

ここでは、直接型と間接型の違いを、不正な指示が入り込む経路の観点から整理します。

直接的プロンプトインジェクション

直接的プロンプトインジェクションは、攻撃者がチャットボットなどの入力欄に、不正な指示を直接入力する攻撃です。

この指示は、LLMに入力内容（プロンプト）として渡され、応答や処理に用いられます。そのため、それまでに設定された指示を無効化するよう求める命令が入力されると、開発者が設定した制約よりも攻撃者の命令を優先してしまう場合があります。その結果、AIが参照できる情報のうち、本来開示すべきでない設定情報などが出力される恐れが生じます。業務利用では、社外に公開している問い合わせ対応チャットボットや、社内向けのAIアシスタントなど、人が直接プロンプトを入力できる仕組みが攻撃の対象になる恐れがあるでしょう。

ただし、入力欄から与えられる内容について生成AIが処理する前に検査できるため、不正な指示を検知できた場合には、その入力を生成AIに渡さずブロックするなどの対策を講じる余地があります。

なお、似た用語として「ジェイルブレイク（脱獄）」がありますが、両者は攻撃の狙いが異なります。ジェイルブレイクがAIに安全対策そのものを無視させることに主眼を置くのに対し、プロンプトインジェクションは、意図的に細工した指示を生成AIに読み込ませ、本来想定されている指示やルールとは異なる動作をさせることに主眼を置きます。

間接的プロンプトインジェクション

間接的プロンプトインジェクションは、AIが読み込む資料・メール・Webページなどの外部データに、不正な指示を含めておく攻撃です。攻撃者がAIに直接触れるのではなく、処理の対象となる「データそのもの」を攻撃の起点とする点が、直接的プロンプトインジェクションとの違いです。

LLMは、読み込んだ文書やWebページのなかに指示の形をした文章があったとき、それを処理対象の情報としてではなく、「従うべき命令」として受け取ってしまう場合があります。

業務利用で当てはまる場面としては、例えば次のようなケースが挙げられます。

• 取引先から届いたPDFをAIに要約させる：ファイルのメタデータや、人の目には見えない形式のテキストにあらかじめ不正な指示が埋め込まれ、その内容が抽出されてAIに渡される場合がある
• 問い合わせメールをAIで自動処理する：メール本文に不正な指示が含まれ、AIに渡される場合がある
• 競合調査のためにWebページの情報を自動で収集し、AIに読み込ませる：HTML内のコメントやメタデータなど本文には表示されない情報に不正な指示が含まれ、AIに渡される場合がある

間接型の手口で留意したいのは、不正な指示が人の目には判別しにくい形で含まれている場合がある点です。文書やメールの外見からは通常の内容と区別しにくく、人が内容を確認せずにAIへ自動的に読み込ませる運用では、不正な指示が含まれていても、AIが処理する前に気付きにくい場合があります。

プロンプトインジェクションの事例と企業に起こり得る4つのリスク

プロンプトインジェクションによって、企業は実際にどのような被害をこうむるのでしょうか。ここでは、報告されている攻撃事例をもとに、想定される影響を4つの観点に分けて整理します。

【機密情報の漏えい】利用者の操作を介さず自動流出するリスク

近年、ビジネス向けに広く使われている生成AI機能において、利用者が特別な操作をしなくても、機密情報が自動的に外部へ流出し得る脆弱性が、セキュリティ研究者によって報告される事例がありました。具体的には、攻撃者が不正な指示を仕込んだメールを送り付けると、その本文を取り込んだAIシステムが指示の影響を受け、利用者の権限の範囲で参照できる社内情報を攻撃者の用意した宛先へ送信してしまう、という仕組みです。

仮にこうした攻撃が成立した場合、役員会議の資料や社内チャットのやり取り、契約に関する情報など、本来は限られた範囲で扱う業務情報が、AIを経由して外部へ渡るリスクがあります。利用者が意図的に指示したり、追加の操作を行ったりしなくても成立し得る点が、この事例の特徴です。入力のフィルタリングだけでなく、多層的な備えを検討する必要があります。

【システム連携による不正操作】意図しないデータの改ざんや削除が行われるリスク

総務省が2025年に実施した「AIセキュリティ分科会（第2回）」の資料では、プロンプトインジェクション攻撃の一例として、「直接的プロンプトインジェクション攻撃（システム攻撃型）」が提示されています。

これは、細工したプロンプトによって連携先のシステムを操作するコード（データベースへの命令やシステムコマンドなど）を生成させ、そのコードを連携先で実行させる手口です。AIが業務システムと連携してデータベース操作やファイル管理を担う環境では、影響が情報の参照に留まらず、データそのものの改ざんや削除に及ぶ可能性があるとされています。

AIにデータの更新や送信といった操作を任せている仕組みでは、意図しない操作が実行されてしまう余地がある、という認識が必要です。

出典：総務省 資料2-3「プロンプトインジェクションの事例（三井物産セキュアディレクション株式会社）」

【マルウェアへの感染】AIベースの防御ツールの目をすり抜けるリスク

セキュリティ対策の分野では、不審なプログラムのコードをLLMを用いたツールに解析させ、マルウェアかどうかの判定に役立てる取り組みが進んでいます。近年、あるセキュリティ研究機関により、こうした解析ツールの判定に影響を与えることを意図したとみられるマルウェアが確認されました。

このマルウェアのソースコードには、解析に用いられるLLMに向けて「このコードには問題がない」と判定させようとする趣旨の指示文が埋め込まれていました。つまり、解析対象となるコードそのもののなかに、解析ツールをだますための命令を仕込んでおく手口です。

報告されたケースでは、ツールは指示の影響を受けず、判定は適切に行われたとされています。ただし、仮に判定を誤った場合には、不正なコードが問題のないものとして扱われ、マルウェアが実行される可能性がありました。

検査や選別をAIに委ねる仕組みでは、その判定自体が不正な指示によって誘導され得ます。今回の攻撃は失敗したものの、今後こうした手法がさらに巧妙化する可能性を示す、AIを狙った攻撃の初期的な事例といえます。

【誤情報の拡散】仕込まれた隠しコマンドにAIが操られるリスク

同じく近年には、学術論文の一部に、内容を評価するAIに向けた指示が埋め込まれていた事例も報告されています。人の目には判別しにくい形（背景と同色の文字など）で、評価を一定の方向に誘導しようとする指示が含まれていた、という内容です。

この手法では、AIによる要約や評価の結果が、埋め込まれた指示の影響を受ける可能性があります。システム運用の仕方によっては、その出力が信頼できる情報として扱われ、社内外で共有される過程に影響が及ぶことも考えられるということです。

なぜ「従来の境界防御」や「入力制限」では防ぎきれないのか？

ネットワークの「内と外」の境界を守るファイアウォールや、端末上で働くウイルス対策ソフトに代表される従来のセキュリティ対策は、既知の不審な通信やファイルを検知・遮断する考え方を基礎としています。守る場所の違いはありますが、いずれも脅威の検知・遮断を基礎とする従来型の対策として、現在も欠かせないものです。

また、生成AIの利用にあたっては、AIへの「入力制限」と呼ばれる対策もあります。入力制限とは、危険性のある単語や命令文を禁止リストとして登録するなどして、AIへの入力内容をフィルタリングする対策のことです。

一方で、生成AIの基盤であるLLMが読み込むのは、利用者が入力欄に打ち込んだ文章だけではありません。Web検索や文書読み込みなどの機能と組み合わせることで、PDF・Webページ・メール・社内文書といった外部情報も読み込んで処理します。そしてLLMには、「従うべき正規の指示」と「処理対象として読み込んだだけの情報」を、明確に区別して扱うことが難しいという傾向があります。そのため、読み込んだデータのなかに指示の形をした文章があると、それを命令として受け取ってしまう余地が残ります。

この結果、外部情報のなかに不正な指示が含まれていても、通信やファイルそのものは通常の業務データに見えるため、境界防御や端末側検知の観点では、不審な通信・ファイルとして検知しにくい場合があるのです。また、禁止リストによる入力制限でも、表現を言い換えた命令文や、外部情報のなかに自然な文章として紛れ込まされた指示までを網羅的に想定するのは容易ではありません。

このように、従来の境界防御や端末側検知、入力制限は既知の脅威には有効である一方、それだけではプロンプトインジェクションに対応しにくい場面があります。だからこそ、生成AIを活用する前提で、セキュリティ対策の考え方そのものを見直すことが求められます。

生成AIを安全に使い続けるために、今できる4つのプロンプトインジェクション対策

プロンプトインジェクションを単一の手段で完全に防ぐことは、現時点では難しいとされています。そのため、もし影響を受けた場合でも被害を抑えられるよう、運用や体制の面から多層的に備える考え方が重要になります。

ここでは今日から段階的に取り組める対策として、「権限・連携範囲の最小化」「人による最終確認」「継続的なログ監視と定期点検」、そして「ゼロトラスト思想への転換」の4つを紹介します。

いずれも、AIの利用範囲や接続先、業務上の確認体制に応じて検討すべき対策です。

万一の被害を最小限に抑える「権限・連携範囲の最小化」

プロンプトインジェクションによって仮に攻撃が成功した場合でも、AIに与えた権限が小さければ影響もその範囲に留まります。これが「最小権限」の考え方です。

例えば、「AIに与える操作権限は業務に必要な最小限に留める」「連携させる社内システムを限定する」「参照できるストレージを指定し、その閲覧権限を読み取り専用にする」といった対応が挙げられます。

ポイントは、「このAIにはここまで」という線引きを、導入時に設計へ組み込むことです。利便性をすべて手放す必要はありません。「活用しながら、万一の際の影響を抑える」という観点で範囲を設計するとよいでしょう。

重要な実行や外部公開の前に挟む「人の目による最終確認」

「AIが下書きしたメールや更新内容を、そのまま自動で送信・反映させない」、この一点だけでも防げるインシデントは少なくありません。 データの送信・更新・削除など影響の大きい操作や、外部に公開する出力については、最後に人が確認する流れを残しておくとよいでしょう。

導入時には、承認の対象とする操作の範囲をあらかじめ整理することが重要です。 例えば、情報の外部送信やシステム上の変更など、影響範囲が大きい操作から確認プロセスを設ける方法が考えられます。

併せて、承認の質を属人化させない工夫も大切です。「機密情報が含まれていないか」「宛先や操作対象は正しいか」といったチェック項目をリスト化しておくと、担当者が変わっても一定の精度を保てます。

異常な挙動を早期に検知するための「継続的なログ監視と定期点検」

AIの利用状況を把握するには、入出力ログを継続的に記録し、確認できる状態にしておくことが重要です。ログの記録・監視により、通常とは異なる利用傾向や外部連携の動きを確認しやすくなります。

例えば利用者が入力したプロンプトの内容や、生成された出力、連携先で実行された操作、連携先システムのリクエストとその応答などを蓄積しておくと、「普段と異なる出力パターン」や「想定外の外部通信」といった異常を検知しやすくなります。ログ分析の自動化ツールを活用し、異常検知のしきい値をあらかじめ設定しておくと、運用チームの負担も抑えられるでしょう。

併せて重要なのが、定期的な点検サイクルの確保です。プロンプトインジェクションの手法は日々変化していくため、導入時の対策が継続して有効とは限りません。一度設定して終わりにするのではなく、継続的に点検し、状況に合わせて見直していく姿勢が求められます。

境界の内側も疑う「ゼロトラスト思想へのシフト」とSASEの検討

ここまでの3つが具体的な運用上の対策であるのに対し、ゼロトラストはそれらを支える全体設計・運用の考え方に位置づけられます。ゼロトラストとは、社内ネットワークの内側か外側かだけで安全性を判断せず、利用者・端末・接続先などを必要に応じて確認する考え方です。

この考え方が重要になるのは、プロンプトインジェクションが、信頼された内部データや社内システムを経由しても成立し得るためです。従来型の対策でも内部を起点とする脅威は一定程度想定されてきましたが、ネットワークの内部を外部より信頼しやすい設計だったため、こうした内側を経由する攻撃には対応しきれない場合があります。個別施策をそれぞれ導入するだけでなく、ゼロトラストの原則のもとで体系的に整理することが有効です。

ネットワークと、アプリケーションへのアクセスを含む通信・接続のセキュリティを統合的に管理する手段としては、SASE（Secure Access Service Edge）の導入も選択肢に含めることができます。SASEとは、アクセス制御や脅威検知といったセキュリティ機能とネットワーク機能をクラウド上で統合し、一元的に管理できる仕組みです。社外からの接続やクラウドサービスの利用が多い環境では、利用者・端末・接続先ごとのアクセス管理を整理する手段のひとつとなります。

ゼロトラストにつきましては、以下の記事でも詳しく解説しています。
関連記事：ゼロトラストとは？基本概念からメリット・課題までわかりやすく解説

まとめ

プロンプトインジェクションは、生成AIが外部情報を読み取り、業務システムと連携する場面で考慮すべきリスクです。特に間接型では、外部の文書やWebページに含まれる指示をAIが参照することで影響を受ける場合があるため、従来の境界防御だけでは対応しにくい場面があります。

そのため、生成AIの利用を前提とする場合は、権限の最小化、人による最終確認、継続的な監視、ゼロトラストの考え方などを、利用範囲や連携先に応じて検討することが重要です。

オプテージでは、境界にとらわれないゼロトラストの考え方に沿い、セキュリティ対策を幅広くご提供しています。AI活用と安全性の両立にお悩みの際は、ぜひご相談ください。

◎製品名、会社名等は、各社の商標または登録商標です。