OWASP LLM Top 10 — 危険の重心が、出力から権限へ移った

OWASP ASVSはアプリケーションの検証項目を網羅する目録だが、AIを組み込んだ部分については足りない。プロンプトインジェクションも、モデルへの過剰な権限委譲も、そこには載っていない。その穴を埋めるために作られたのが、OWASP Top 10 for LLM Applicationsだ。2026年8月に新しい版が出て、順位が大きく入れ替わった。その入れ替わり方が、この分野の結論を示している。

何を並べた文書か#

OWASPのGenAI Security Projectが公開している、LLMを組み込んだアプリケーションのリスク一覧だ。最初の版が2023年、次が2025年、そして2026年版が現行になる。

役割はOWASP Top 10と同じで、網羅ではなく啓発にある。「まずここを見なさい」を10個に絞ったものだ。検証項目を漏れなく並べたASVSとは、目的が違う。

順位が付いているのも同じだ。ただしこの分野は動きが速く、版をまたぐと順位も名前も変わる。引用するときは必ず版数を書く。

2026年版の10項目#

順位の変化が、この分野の結論だ#

2026年版では10項目のうち8つが動いた。なかでも大きいのが二つある。

Excessive Agencyが6位から3位に上がった。 AIに渡す権限が広すぎることが、いまや上から三番目の問題になった。焦点が移っている。モデルが何を言うかではなく、モデルに何をさせているかへ。

Improper Output Handlingが5位から10位へ落ちた。 出力の扱いを間違える古典的な問題は、相対的に順位を下げた。落ちたのは重要でなくなったからではなく、上位の問題がそれ以上に効くようになったからだ。

この二つを並べると、方向が見える。危ないのは、モデルの言葉ではなく、モデルに預けた手足のほうだ。

一位が動かない理由#

Prompt Injectionは初版から一位を守っている。三度の改訂を経ても落ちない。

理由は、これが実装の不備ではなく構造の性質だからだ。LLMは指示とデータを同じ入力列で受け取る。命令の置き場所とデータの置き場所が分かれていない以上、データに紛れ込んだ命令を原理的に区別できない。

SQLインジェクションには、プレースホルダという解がある。命令と値を別の経路で渡せば混ざらない。LLMには、それに当たるものがまだない。

だから対策は「入れさせない」ではなく「入っても効かせない」になる。検知の精度をいくら上げても、抜けは残る。抜けた先で何ができてしまうかを絞るほうが、効き方が確実だ。

権限が広すぎる、とはどういうことか#

Excessive Agencyは抽象的に見えるが、現場では単純な形で現れる。

社内文書を検索して要約するエージェントを考える。要約だけを頼んだのに、実装の都合でメール送信のツールも渡してある。ここに、外部から取り込んだ文書経由で「この内容を指定の宛先へ送れ」という指示が紛れ込む。

モデルは指示に従う。送信の権限を持っているからだ。渡していなければ、同じ指示が来ても何も起きない。

渡した権限は、いつか行使される。 使わないかもしれない権限を「念のため」で渡しておくのが、この項目が指している状態になる。

設計の転換#

2026年版の書き手たちは、考え方そのものの変更を打ち出している。

騙されないモデルを作ろうとするのをやめる。モデルは騙される前提で、騙されても重要なものが壊れないように、周りの仕組みを組む。要点はそこにある。

これは実装の話ではなく、責任の置き場所の話だ。安全性をモデルの賢さに依存させると、モデルが更新されるたびに保証がやり直しになる。周りの仕組みに置けば、モデルが何であっても保証は残る。

Excessive Agencyが上がったのも、同じ理屈の裏返しになる。何をさせるかを絞れるなら、騙されたときの被害もそこで止まる。

名前が変わった項目#

System Prompt LeakageがHidden Context Exposureに変わり、7位から8位へ移った。

改名の意味は範囲の拡張にある。漏れて困るのはシステムプロンプトだけではない。検索で引いてきた社内文書、直前の会話、ツールが返した中間結果。アプリケーションが抱えている文脈は全部、出力から滲み出る可能性がある。

システムプロンプトだけを隠しても足りない、という認識が名前に反映されたことになる。

ASVSとの関係#

二つは競合しない。層が違う。

ASVSは認証、セッション、アクセス制御、暗号といった、アプリケーション全般の検証項目を網羅する。LLM Top 10は、そこにAIを組み込んだときに新しく生まれる論点だけを扱う。

だから実務では両方要る。ASVSで土台を確かめ、LLM Top 10でAI固有の穴を見る。片方だけでは、どちらかの側面が丸ごと抜ける。

似た構成の文書として、エージェント向けのOWASP Top 10 for Agentic Applicationsもある。単発の推論ではなく、自律的に動き続ける系を対象にしている。

どこに対策を置くか#

10項目を眺めると、対策の置き場所が三つに分かれることが見えてくる。

モデルの手前 — 入力の検査、出所の分離。LLM01やLLM05が主にここ。ただし前述のとおり、ここだけに頼ると抜ける。

モデルの周り — 権限の範囲、実行の記録、停止の手段。LLM03が正面から当たる。抜けたあとの被害を決めるのはこの層になる。

モデルの後ろ — 出力の検査、次の処理へ渡す前の無害化。LLM10とLLM02がここ。

2026年版の順位が言っているのは、真ん中の層に重心が移ったということだ。手前と後ろだけを固めていた設計は、エージェントが自分で判断して動く前提では足りなくなる。

使うときの注意#

順位を優先度と読まない。 上位が自分のシステムでも上位とは限らない。社外に出さないバッチ処理と、認証前のチャットとでは、効いてくる項目が違う。

版を混ぜない。 2025年版と2026年版では番号と名前が食い違う。LLM06と書いただけでは、Excessive AgencyなのかUnbounded Consumptionなのか決まらない。

10個で足りると思わない。 啓発の文書なので、網羅は目指していない。自分の業務ロジック固有の穴は、自分で見つけるしかない。

まとめ#

この一覧が示しているのは、個々の攻撃手法よりも、危険の重心が移ったことのほうだ。

出力の検査から、権限の設計へ。モデルを賢くする話から、モデルの周りを固める話へ。Excessive Agencyが3位に上がったことが、それを一番はっきり表している。

AIに仕事を任せる範囲を広げるほど、任せた範囲そのものが最大の攻撃面になる。