プロンプトインジェクション対策 一覧表 2026｜OWASP分類で整理
この記事の結論
- プロンプトインジェクションとは、AIが読み込む文章の中に指示を紛れ込ませ、本来の指示から逸脱させる攻撃のことです。
- 2026年時点で、入力の検査だけで防ぎ切る方法は確立していません。前提は「すり抜ける」で、権限の制限と人の承認を重ねて被害を抑えます。
- この記事は対策の一覧表です。分類は OWASP Top 10 for LLM Applications 2025 に沿い、出典は一次情報へリンクしています。最終更新 2026-09-10。
AIエージェントに外部の文章を読ませた瞬間、その文章に書かれた「指示らしき文」に従ってしまう危険が生まれます。これがプロンプトインジェクションです。この記事は、攻撃の型と対策、そして対策の限界を一覧表にまとめた早見です。
最終更新: 2026-09-10・読了目安 約9分
プロンプトインジェクションとは
プロンプトインジェクションとは、AIが読み込む文章の中に指示を紛れ込ませ、開発者が与えた本来の指示から逸脱させる攻撃です。利用者が直接打ち込む場合と、AIが読みに行った外部データ（Webページ、メール、ファイル、検索結果）に仕込まれている場合があります。
OWASP Top 10 for LLM Applications 2025 では LLM01 として先頭に挙げられています（一覧は LLM01 Prompt Injection / LLM02 Sensitive Information Disclosure / LLM03 Supply Chain / LLM04 Data and Model Poisoning / LLM05 Improper Output Handling / LLM06 Excessive Agency / LLM07 System Prompt Leakage / LLM08 Vector and Embedding Weaknesses / LLM09 Misinformation / LLM10 Unbounded Consumption）。
重要なのは、これがモデルの性能不足ではないという点です。AIは指示とデータを同じ文章として受け取るため、両者を完全に見分ける確実な手段が現時点で存在しません。したがって対策は「防ぐ」だけでなく「起きても被害が小さい形にする」を含みます。
攻撃の型を分けて考える
対策は攻撃の型ごとに変わります。まず型を分けてから対策を選びます。
| 型 | 入り口 | 起こること | 気づきにくさ |
|---|---|---|---|
| 直接注入 | 利用者の入力欄 | 内部の指示を上書きし、禁止した回答を出させる | 比較的気づきやすい |
| 間接注入 | AIが読みに行った外部データ | 閲覧した文章の指示に従い、無関係な操作を実行する | 攻撃者と利用者が別人のため気づきにくい |
| システムプロンプトの抜き出し | 誘導する質問 | 内部の指示文や設定が丸ごと出力される | 出力を見ないと分からない |
| 権限の踏み台化 | ツールを持つエージェント | AIの権限で送信・削除・購入などが実行される | 実行後に判明することが多い |
| 保存型の注入 | 保存された文書や会話履歴 | 後から読んだ別の利用者にまで影響が及ぶ | 時間差で発生し追跡が難しい |
対策一覧表 2026（対策・防げるもの・限界）
対策は「入口で減らす」「権限で被害を抑える」「出口で止める」「運用で気づく」の4層に分かれます。どれも単独では十分ではありません。
| 層 | 対策 | 防げるもの | 限界・注意点 |
|---|---|---|---|
| 入口 | 外部データを引用として囲い、データであると明示する | 素朴な直接注入 | 表現を変えた指示には効かない。効果は補助的 |
| 入口 | 利用者入力と外部データを別の枠で渡し、混ぜない | 文脈の取り違え | 仕組み上の分離であって、内容の判別ではない |
| 入口 | 注入らしき文字列の検出（既知パターン） | 公開されている典型的な攻撃文 | 未知の言い回し・多言語・符号化には弱い |
| 権限 | ツールを読み取り専用と書き込みに分ける | 誤操作の大半 | 読み取りだけでも機密の持ち出しは起こり得る |
| 権限 | 削除・送信・支払いに人の承認を必須にする | 取り返しのつかない被害 | 承認画面が要約だと、承認者が中身を見ずに押す |
| 権限 | AIに渡す権限を必要最小限へ絞る | 影響範囲の拡大 | 権限設計は定期的に見直さないと膨らむ |
| 権限 | 認証情報をAIの文脈へ入れない | 認証情報の漏えい | ログや中間出力にも入らないことを確認する |
| 出口 | 出力を実行・埋め込みする前に検証する | 出力経由の二次被害 | 検証ルールの網羅は難しい。危険な形式は許可制にする |
| 出口 | 出力に含まれる機密・個人情報を検出して止める | そのままの持ち出し | 言い換えられた情報は検出できないことがある |
| 運用 | 攻撃サンプルを評価セットに入れ、定期的に流す | 退行（直したはずの穴の再発） | サンプルは古くなる。事故のたびに追加する |
| 運用 | 呼び出しと出力を記録し、逸脱を後から追える状態にする | 被害範囲の特定 | 記録に機密が入らない設計が必要 |
| 運用 | 上限（呼び出し回数・費用・時間）を設ける | 資源の枯渇（LLM10） | 上限は事故の前に決めておく。事後では間に合わない |
この表で「限界・注意点」の列を空にできる対策は1つもありません。そこが、この問題を従来の入力値検証と同じに扱えない理由です。
効果が薄い・過信しやすい対策
よく提案されるものの、単独では頼れない対策も整理しておきます。
| よく見る対策 | 期待されがちなこと | 実際 |
|---|---|---|
| 「指示を無視するな」と内部の指示文に書く | 注入を無効化できる | 文面の勝負になり、書き換えの余地が残る |
| 禁止語のブラックリスト | 攻撃文を弾ける | 言い換え・多言語・符号化で回避される |
| より高性能なモデルへの変更 | 賢いモデルなら見抜ける | 逸脱率は下がり得るが、原理的な区別ができない点は変わらない |
| AIに「これは攻撃か」を判定させる | 自動で防げる | 判定するAI自身が注入の対象になる |
| 利用者の入力だけを検査する | 入口を塞げる | 間接注入は外部データから入るため素通りする |
効果が薄いから使うなという意味ではありません。単独で「対策済み」と宣言できない、という意味です。AIエージェントのセキュリティ：プロンプトインジェクションと過剰な権限では、権限側の考え方をより詳しく扱っています。
導入前チェックリスト
外部データを読むAIを業務に入れる前に、最低限そろえておく項目です。
- AIが読み込む外部データの経路をすべて書き出してある（Web・メール・ファイル・検索結果・過去の会話）
- AIが実行できる操作の一覧と、それぞれの取り返しのつきやすさが表になっている
- 削除・送信・支払いに人の承認が入っており、承認画面に実際の引数が出る
- 認証情報がAIの文脈とログのどちらにも入らないことを確認してある
- 攻撃サンプルを含む評価セットがあり、変更のたびに流している
- 事故が起きたときに、何が呼ばれ何が出たかを追える記録がある
- 上限（呼び出し回数・費用・時間）が事前に決まっている
導入全体の観点はAIコーディングエージェント導入時のセキュリティチェックリスト 2026、測り方はLLM評価の指標一覧表にまとめています。
参照した一次情報
この記事の分類と用語は、次の公開資料に基づいています。いずれも一次情報です。
| 資料名 | 発行元 | 分かること | リンク |
|---|---|---|---|
| Top 10 for LLM Applications 2025 | OWASP | LLMアプリで起きる代表的なリスク10種の分類 | genai.owasp.org/llm-top-10/ |
| LLM01:2025 Prompt Injection | OWASP | プロンプトインジェクションの定義と攻撃の型 | genai.owasp.org/llmrisk/llm01-prompt-injection/ |
| AI Risk Management Framework | NIST | AIのリスクを統治・特定・測定・管理する枠組み | nist.gov/itl/ai-risk-management-framework |
| AI 100-2 E2025（Adversarial Machine Learning） | NIST | AIへの攻撃と緩和策の用語・分類 | csrc.nist.gov/pubs/ai/100/2/e2025/final |
| 情報セキュリティ10大脅威 2026 | IPA（情報処理推進機構） | その年に社会的影響が大きかった脅威の一覧 | ipa.go.jp/security/10threats/10threats2026.html |
| Top 10 for LLM Applications 2025（資料ページ） | OWASP | 一覧の配布資料と各項目の解説 | genai.owasp.org/resource/owasp-top-10-for-llm-applications-2025/ |
| 安全なウェブサイトの作り方 | IPA（情報処理推進機構） | 入力値の扱いと出力時のエスケープの基本 | ipa.go.jp/security/vuln/websecurity/about.html |
| 中小企業の情報セキュリティ対策 | IPA（情報処理推進機構） | 組織として最低限そろえる対策の考え方 | ipa.go.jp/security/sme/index.html |
関連記事・用語
用語の定義はプロンプトインジェクション・ガードレール・レッドチーミングにまとめています。権限設計の考え方はAIエージェントのセキュリティ、ツール設計はAIエージェントのツール呼び出し設計チェックリスト、コード側の確認はAIが生成したコードのセキュリティ確認をご覧ください。
よくある質問
Q1. 入力のフィルタだけでプロンプトインジェクションは防げますか？
防ぎ切れません。既知の攻撃文は弾けますが、言い換え・多言語・符号化で回避されます。さらに、AIが読みに行った外部データから入る間接注入は利用者の入力を通らないため、入力フィルタでは触れられません。権限の制限と人の承認を重ねてください。
Q2. 社内利用だけなら対策は不要ですか？
不要にはなりません。社内で扱う文書やメールにも外部から届いた文章が含まれます。むしろ社内利用は権限が広いことが多く、AIが実行できる操作の範囲が広いぶん被害が大きくなりがちです。読み取りと書き込みの分離だけでも先に入れてください。
Q3. どこまで対策すれば「対策済み」と言えますか？
2026年時点では、入力の検査だけで「対策済み」と言える状態はありません。実務上の目安は、取り返しのつかない操作に人の承認が入り、認証情報がAIの文脈に無く、攻撃サンプルを含む評価セットを変更のたびに流し、事故時に追える記録が残っていることです。