AIエージェントを自社のサービスや社内業務に入れるとき、セキュリティの提案書はたいてい入口の話から始まります。プロンプトインジェクション対策、入力のフィルタ、危険な指示の検知。項目としては正しく、反対する理由もありません。
ただ、点検には順番が必要です。予算も時間も有限で、全部を同時には進められません。そこで「実際に起きた事故は何が原因だったのか」を見たくなります。
事故の記録を並べたものとして、OWASP GenAI Security Project のサイトに四半期ごとのレポートが公開されています。2026年の第3四半期を扱った回には9件の事例が収録され、それぞれにリスクの分類が付いています。その分類を数え直すと、繰り返し現れるのは入力の側ではありませんでした。
ただし、この資料には先に確認しておくべき制約があります。制約を飛ばして数字だけを取り出すと、原典が持っていない精度を足してしまう種類の資料です。順番に見ていきます。
30秒で要点
- 参照した四半期レポートは、網羅的なレポートでも OWASP の公式刊行物でもないと自ら述べている。「OWASP の統計では」と引用することはできない
- 2026年第3四半期の回では、収録9事例に付けられた分類のうち、過剰な権限（LLM03 Excessive Agency）が7件、ID と権限の悪用（ASI03）が7件、ツールの誤用（ASI02）が6件、暴走するエージェント（ASI10）が6件で現れた。プロンプトインジェクション（LLM01）は1件
- その1件は研究として実証されたもので、実環境での悪用は報告されていない。入口として成立しないという話ではない
- 割合では読めない。 レポート自身が独立した攻撃として数えるなと明記し、概要部の7件と本文一覧の9件も一致していない
- 同じ偏りは2026年第1四半期を扱った回にも現れる。ただし両レポートは四半期比較をしておらず、増減のトレンドは言えない
- レポートから読めるのは「与えられた仕事を遂行する過程でエージェントが害をなし得る」「プロンプトレベルの指示だけでは安全な境界は成立しない」という2点。点検の順番は、ここから先はこちらの判断になる
この資料が何であって、何でないか
先に制約を置きます。ここを飛ばすと、この後の数字がすべて誤用になります。
参照したのは次の2本です。2026年10月8日公開の「GenAI and Agentic AI Exploit Roundup Q3 2026」（対象期間は2026年7月1日から9月30日、本文の事例一覧は9件）と、2026年4月14日公開の「OWASP GenAI Exploit Round-up Report Q1 2026」（対象期間は2026年1月1日から4月11日、収録8件、プロジェクト共同リードの Scott Clinton による署名記事）です。
このうち Q3 の回には、次の一文が置かれています。
It is not an exhaustive report or an official OWASP publication. （網羅的なレポートではなく、OWASP の公式刊行物でもない）
Q1 の回にも、網羅的であることを意図していないという記述があります。
この一文が効く範囲は広いです。母集団の作り方が示されていない資料は、母集団を前提とした推論に使えません。 「世の中のAI関連事故のうち何割が」という形の主張は、この資料からは出てきません。出てくるのは「この収録のされ方では、こういう分類が繰り返し付いている」という、もっと狭い事実です。
狭いからといって使えないわけではありません。点検の順番を決めたいだけなら、順位の手がかりがあれば足ります。必要なのは、手がかりを結論のように扱わないことです。
事例に付いた分類を数え直すと、同じIDが繰り返し現れる
Q3 の回に収録された9件の事例には、それぞれ OWASP の2つの体系（LLM アプリケーション向けと、エージェント向けの ASI）から複数のリスクIDが割り当てられています。そのIDを事例側から数え直すと、次のようになります。
表が収まらない場合は、横にスクロールできます
| 分類 | 付与された事例の数 |
|---|---|
| LLM03 Excessive Agency（過剰な権限） | 7 |
| ASI03 Identity and Privilege Abuse（ID と権限の悪用） | 7 |
| ASI02 Tool Misuse（ツールの誤用） | 6 |
| ASI10 Rogue Agents（暴走するエージェント） | 6 |
| LLM02（第3四半期の回での名称は未確認） | 4 |
| LLM04 Supply Chain / ASI04 | 各3 |
| LLM01 Prompt Injection（プロンプトインジェクション） | 1 |
2026年第1四半期を扱った回でも、方向は同じでした。こちらは8件の事例に対し、過剰な権限（この回の採番では LLM06）が5件、機密情報の漏えい（LLM02）が6件、出力の不適切な扱い（LLM05）が5件、サプライチェーン（LLM03）が4件。プロンプトインジェクション（LLM01）は1件です。
読み方を1つ補っておきます。この表が示しているのは「実際の攻撃の内訳」ではなく「レポート作成者が付けた分類の内訳」です。 同じ事故でも、分類する人が違えば割り当ては動きます。ここで見ているのは、事故そのものの性質というより、事故を記述した人がどの枠に入れたかです。
それでも手がかりにはなります。記述した人が繰り返し「権限が広すぎた」「ツールを呼べてしまった」という枠を選んだということは、被害の説明にその枠が必要だったということです。
なぜこの件数を割合にしてはいけないのか
ここが、この資料を扱う上でいちばん滑りやすいところです。
Q3 の回の概要部には、収録項目について次の趣旨の記述があります。7件の項目には OpenAI のキャンペーンの3つの構成要素、Anthropic の3件、研究で実証された Copilot の悪用系統1件が含まれる、と。そして続けて、それらを7件の独立した攻撃として数えてはならないと明記しています。
一方で、本文の事例一覧は9件あります。概要の「7件」に含まれていない項目が2件あり、レポート内部で数が一致していません。
つまり分母が定まりません。9で割るのか7で割るのか決められず、しかもレポート自身が独立計数を禁じています。この状態で「9件中1件、つまり約11%」と書けば、原典が持っていない精度を足したことになります。
同じ種類のずれは、CVE の扱いにも現れます。Q3 の回の「Related Published CVEs」という節には、該当する CVE は1件だけで他にはないと書かれています。ところが本文の事例1の説明には、別の製品の CVE 番号が複数並んでいます。節の記述と本文の記述が食い違っているわけです。
これは資料の質が低いという話ではありません。速報的にまとめられた一次資料には、こうした不整合がしばしば残ります。引用する側がやるべきことは、整合していることを期待するのではなく、どの節から取った記述かを記録することです。 「レポートに書いてあった」ではなく「レポートのこの節に書いてあった」まで降りておくと、後から矛盾が見つかったときに、どちらを直せばよいかが分かります。
したがって本記事では、割合もパーセントも使いません。使えるのは「同じ分類が繰り返し現れた」という定性的な言い方までです。
なぜ対策の話は入口に寄りやすいのか
分布が権限とツールの側を指しているのに、提案や社内の議論は入口に寄ります。理由は注意力の不足ではなく、構造の側にあります。
第一に、入口は絵にしやすいからです。 「悪意のある文章を読み込ませると、AIが指示に従ってしまう」という筋書きは、1枚の図で説明できます。一方「このエージェントは本来参照する必要のない資産に到達できる権限を持っていた」は、権限の一覧と呼び出し経路を見せないと伝わりません。説明しやすさが、対策の優先順位に混ざります。
第二に、入口はAIに固有の話として新しく、権限は昔からある話だからです。 プロンプトインジェクションは、AIを入れたからこそ生まれた入口です。対して過剰な権限や認可の設計は、AIの前から存在した論点です。新しいものは検討の議題に上がりやすく、既にあったものは「済んでいること」として扱われます。 済んでいるかどうかは、エージェントを足した後に変わります。
第三に、入口の対策は完了を宣言できるからです。 フィルタを入れた、検知を有効にした、という形で終わりが見えます。権限の最小化は終わりが見えません。ツールが増え、連携が増えるたびに、確かめ直す対象が増えます。完了を宣言できる作業のほうが、先に着手されます。
この3つが重なると、入口の対策が手厚くなり、権限の設計が後回しになります。事故の記述に繰り返し現れていたのは、後回しにされた側でした。
入口が成立していないわけではない
ここで逆の誤読を止めておきます。「プロンプトインジェクションは1件だったのだから、優先度は低い」という読みは、この資料からは出てきません。
その1件は、研究として実証された事例です。実環境での悪用は報告されていません。つまり入口としては成立しており、まだ悪用の報告がないという状態です。報告がないことは、成立しないことの証明ではありません。
そもそもサンプルは網羅的ではなく、IDの割り当てはレポート作成者の判断です。「現れなかった」ことから「起きていない」を導くには、母集団と収録の基準が必要で、どちらも示されていません。
レポート自身の総括として置かれているのは、次の2文です。
The incidents in this roundup show how an AI agent can cause harm while pursuing an assigned task. （この収録事例は、AIエージェントが与えられたタスクを遂行する過程で害をなし得ることを示している）
Prompt-level instructions alone do not establish a secure boundary. （プロンプトレベルの指示だけでは、安全な境界は成立しない）
2文目は、入口の対策を否定していません。指示や入力の層だけでは境界にならない、と言っています。 境界は権限の側で引くもので、入力の検査はその上に重ねる層だという読み方になります。
したがって正確な言い方は「プロンプトインジェクションは怖くない」ではありません。入口としては成立しているが、収録された事例で被害の大きさを決めていたのは、入力ではなく権限とツールの側だった、です。
確かなことと、まだ確かではないこと
確かなこと： 参照した2本のレポートが、網羅性を自ら否認していること（Q3 の回は OWASP の公式刊行物でもないと明記）。Q3 の回の収録9事例に付いた分類で、過剰な権限・ID と権限の悪用がそれぞれ7件、ツールの誤用・暴走するエージェントがそれぞれ6件、プロンプトインジェクションが1件であること。その1件が研究実証であり実環境の悪用報告がないこと。Q1 の回の8事例でも過剰な権限が5件に対しプロンプトインジェクションが1件であること。レポートが独立計数を禁じ、概要の件数と本文一覧の件数が一致していないこと。総括として上記2文が置かれていること。
まだ確かではないこと： 世の中のAI関連事故全体における分布（この資料は母集団を示していません）。四半期ごとの増減（両レポートは四半期比較をしておらず、間の期も確認していません）。個別事例の攻撃手順・被害範囲（本記事は事例の表題と分類の割り当て、総括文までを確認対象としており、各事例の技術的詳細には立ち入っていません）。分類の割り当てが別の評価者でも同じになるか（レポート作成者による分類です）。
なお、同じ番号が版によって別のリスクを指す点には注意が必要です。第1四半期の回と第3四半期の回では参照している Top 10 の版が違い、たとえば LLM03 は前者ではサプライチェーン、後者では過剰な権限を指します。この論点自体はOWASPの番号を覚えても資料を取り違える理由で扱っているので、そちらに預けます。
点検の順番を、分布に合わせて置き直す
ここからは本記事の判断です。レポートは事故の記録と分類であり、対策の推奨順序を示した文書ではありません。 以下はレポートの結論ではなく、分布を見たうえでのこちらの提案です。
- 権限の範囲 — そのエージェントが到達できる資産の一覧を、実際に使うものだけに絞れているか
- ツールの呼び出し可能性 — 呼べるツールのうち、業務上必要なものはどれか。必要でないものが呼べる状態になっていないか
- ID と認可の設計 — エージェントが誰として動いているか。人の権限を借りているなら、借りる範囲が業務単位で切れているか
- 入力の検査 — そのうえで、入力側の検知とフィルタを重ねる
この順番は、「権限を最小にせよ」という結論を繰り返すためのものではありません。その結論は既に広く共有されています。ここで確かめたかったのは、事故の記述がその優先順位を支持しているかどうかでした。収録された事例に繰り返し付いていた分類は、1から3の層に集まっていました。
順番の根拠がこれで十分かというと、そうではありません。網羅的でない資料の、作成者による分類です。だから「決まり」ではなく「仮の順番」として置き、自社のデータで確かめ直すのが妥当な扱いになります。エージェントに与える権限の線引きそのものについてはAIエージェントに「どこまで任せるか」の境界設計、組織としての枠組みの整理はAIエージェントのセキュリティが近いところにあります。
自社のエージェントで、過剰さを1日で測る
仮の順番を自社で確かめる最小の手順を置きます。測るのは「権限の過剰さ」です。
分母と分子を先に固定します。
- 分母： エージェント1体が呼び出せるツール・到達できるデータソースの数
- 分子： 直近30日間に実際に呼び出した・到達したものの数
- 単位： 使用率（％）
手順は4つです。
- エージェントを1体選び、設定上呼び出せるツールと到達できるデータソースを列挙する。 一覧が出てこないなら、それ自体が最初の発見です
- 実行ログから、直近30日に実際に使われたものだけを数える。 ログに残っていないなら、残す設定を入れるところが先になります
- 使用率を出す。 使っていないものが多いほど、事故が起きたときに広がる範囲が実際の業務より広い状態です
- 使っていないものを1つ外し、業務が回るかを1週間観察する。 外して困らなかったなら、それは必要な権限ではありませんでした
この測り方は、入力の検査と競合しません。分母を小さくしておくと、入口を破られたときの影響範囲が小さくなるという関係です。順番の話であって、どちらかを捨てる話ではありません。
最初に見るべきは使用率の水準ではなく、一覧とログがそろって出てくるかどうかです。どちらも出てこない状態では、どの層の対策も効果を確かめられません。
判断の土台として押さえておくこと
- 参照した四半期レポートは網羅的でも公式刊行物でもないと自ら述べている。引用時はその旨を併記し、「OWASP の統計」として扱わない
- 収録事例に付いた分類では、過剰な権限・ツールの誤用・ID と権限の悪用が繰り返し現れ、プロンプトインジェクションは1件だった
- その件数を割合にはできない。レポートが独立計数を禁じ、概要と本文一覧で件数が一致していない
- 一次資料の内部に不整合が残ることはある。引用は「どの節から取ったか」まで記録する
- プロンプトインジェクションの優先度が低いという結論は出ない。入口としては成立しており、報告がないことは成立しないことの証明ではない
- 読み取れるのは「指示や入力の層だけでは境界にならない」まで。点検の順番はこちら側の判断であり、仮のものとして自社のデータで確かめ直す
- 自社で測るなら、権限の使用率（分母＝呼び出せる数、分子＝実際に使った数、単位＝％）から始める。一覧とログが出てこないこと自体が最初の発見になる
参考資料・引用元
- OWASP GenAI Security Project, "GenAI and Agentic AI Exploit Roundup Q3 2026"（2026年10月8日公開、対象期間 2026年7月1日〜9月30日）. https://genai.owasp.org/2026/10/08/genai-and-agentic-ai-exploit-roundup-q3-2026/ （2026年10月17日確認・HTTP 200）
- OWASP GenAI Security Project, "OWASP GenAI Exploit Round-up Report Q1 2026"（2026年4月14日公開、Scott Clinton 署名、対象期間 2026年1月1日〜4月11日）. https://genai.owasp.org/2026/04/14/owasp-genai-exploit-round-up-report-q1-2026/ （2026年10月17日確認・HTTP 200）
- OWASP GenAI Security Project（プロジェクトサイト）. https://genai.owasp.org/ （2026年10月17日確認・HTTP 200）