プロンプトインジェクションは、AIが処理する文章などに指示を紛れ込ませ、本来の目的から外れた動作を誘う攻撃です。利用者が直接入力する場合だけでなく、AIが読みに行ったWebページや文書を通じて起きる場合もあります。
文章を要約するつもりが、資料に混ざった別の指示へ引っ張られる。その影響は、AIが読める情報と、実行できる操作によって変わります。「AIを使ったら必ず漏れる」という話ではありません。どこから指示が入り、どこまで動けるかを見ることが大切です。
プロンプトインジェクションはAIに別の指示を紛れ込ませる攻撃
プロンプトは、AIへ渡す指示や入力のことです。インジェクションには、何かを注入するという意味があります。この攻撃では、本来従うべき依頼とは別の指示を、入力の中へ入り込ませます。
たとえば、あなたがAIに「この商品の説明を要約して」と頼んだとします。参照した説明文に、商品とは関係のない別の作業をAIへ求める内容が混ざっていたらどうでしょうか。
本来、その文章は読む対象です。あなたからの新しい依頼ではありません。それでもAIが命令として扱ってしまうと、頼んでいない回答や操作につながる場合があります。これは仕組みを説明する架空の例です。
何をしてほしいか。本来の作業の目的。
読む対象。ここに別の指示が混ざる場合がある。
送信・編集など、AIが実際に使える機能。影響の範囲に関わる。
「資料に書いてあること」と「利用者が頼んだこと」は別です。資料を読む許可は、その中の指示を実行する許可ではありません。
人なら、資料中の「こうしなさい」と、自分が頼まれた仕事を分けて読めます。生成AIでは、指示と資料の文章を厳密に分け続けられるとは限りません。英国NCSCの解説も、この境界を当然に守れるものとしてシステムを作らないよう説明しています。
AIが間違えることとは、何が違う？
AIが事実と異なる内容を作る「ハルシネーション」は、外部から攻撃されなくても起こります。プロンプトインジェクションは、入力に含まれた指示が本来の動作を変えてしまう問題です。
結果として誤った回答になる点は重なることがあります。ただし、変な回答が出たことだけで、攻撃されたと断定することはできません。
直接型・間接型のプロンプトインジェクションの違い
分かれ目は、攻撃のための入力がどこから届くかです。
| 種類 | 指示が入る経路 | 利用者から見た違い |
|---|---|---|
| 直接型 | AIへの入力欄などから直接与える | 悪意のある利用者が、システムのルールを外すよう働きかける場合がある |
| 間接型 | AIが読むWebページ、文書、メールなどへ混ぜる | 普通に要約や調査を頼んだ人が、攻撃文を自分で入力しなくても影響を受け得る |
OWASPのプロンプトインジェクション解説では、外部からの情報を通る間接型や、画像などを通じる可能性も説明されています。人に見える文字だけが入口とは限りません。
「自分は変なお願いをしていないから関係ない」と言い切れないのが、間接型の難しいところです。取引先から届いた資料や検索結果など、AIに読ませる対象の中に、誰が書いた情報が含まれるかも関わります。
一方、外部資料を読むたびに攻撃が成功するわけではありません。AIやサービスの防御、入力の扱い、与えた権限などによって結果は異なります。
AIがメールやファイルを操作できると被害はどう変わる？
文章を返すだけのAIと、ほかのサービスを操作できるAIでは、起こり得る影響が違います。AIエージェントのように、目的に合わせて道具を使う仕組みでは、その道具の権限も確認する必要があります。
| AIが使えるもの | 考えられる影響の例 |
|---|---|
| 渡された文章を読み、回答する機能 | 要約や比較が誘導され、誤った判断につながる |
| 非公開の資料を読む機能 | 読める範囲の情報が、不適切な回答などへ含まれる |
| 外部へ情報を送る機能 | 宛先や送信内容を誘導され、情報が意図しない相手へ渡る |
| ファイルを変更・削除する機能 | 許可された範囲で、望まない書き換えなどが起きる |
これは可能性の整理で、すべてのAIがこれらの機能を持っているという意味ではありません。メール送信の道具がないAIが、指示を読んだだけで突然その道具を獲得するわけでもありません。
ただし、「読み取り専用」なら何も心配ない、とまでは言えません。読める資料が回答に混ざる、誘導された回答を人が信じて行動する、といった問題は残ります。
APIやMCPは、外部の機能やデータとつながる場面で登場します。接続の仕組みの名前だけで安全性は決まらず、どの相手へ、何を読ませ、何を許したかを確かめます。
プロンプトインジェクション対策は渡す情報と権限から考える
「悪い指示には従わないで」と書くことは、防御を考える一部にはなります。しかし、その一文だけで、すべての入力を安全に扱える保証にはなりません。
利用する側は、次の三つを分けて確認すると、見直す場所が分かります。
- 読ませる情報：その作業に必要な資料だけか。関係のない秘密や、他人の個人情報まで渡していないか。
- 実行できる操作：読むだけで足りるのに、送信・編集・削除まで許していないか。
- 実行前に見える内容：重要な操作の前に、対象、宛先、送る内容、変更点を確認できるか。
たとえばメールの下書きが目的なら、最初から自動送信まで許す必要があるかを考えられます。確認画面があっても、何を送るか分からないまま「許可」を押すだけでは、確認の意味が薄くなります。
作る側にも、AIの判断だけに任せない仕組みが必要
サービスの提供側には、資料を指示と区別して扱う設計、操作権限の制限、入出力の検査、記録と監視などを組み合わせる対策が必要です。利用者が文章を注意深く読むことだけでは、サービス全体の安全を支えきれません。
特に重要な操作は、AIが「許可されている」と判断しただけで通すのではなく、システム側でも対象や権限を確かめることが大切です。対策の目的は、指示に影響される可能性と、影響されたときの被害の両方を小さくすることです。
頼んでいない操作をAIが提案したら
そのまま承認せず、何をしようとしているかを確認します。外部への送信や設定変更が実行された疑いがあるなら、履歴を残して、サービスの運営元や職場の管理担当へ相談してください。追加の秘密情報を渡して原因を試す必要はありません。
まずは、使っているAIについて「読める情報」と「できる操作」を別々に書き出してみてください。便利な機能を全部なくさなくても、今の作業に不要な権限を減らす余地が見つかります。
