OWASPの2026 LLM Top 10が示す新たな潮流
OWASP GenAI Security Projectは、Top 10 for LLMの2026年版が公開されました。順位は昨年と変わらず、１位がプロンプトインジェクション（Prompt Injection）、２位が機微情報の漏洩（Sensitive Information Disclosure）で、全体順位にも大きな動きはなかったように見えます。
しかし、その裏には注目すべき変化が隠されていました。OWASPプロジェクトの主導者たちは冒頭で「騙されないモデルを作ろうとするのはやめて、モデルが騙されたときに重要なものが壊れないようなシステムを作れ」と述べています。これはいったいどういう意味でしょうか。この2年間、LLM業界はAIモデルの最適化に注力してきました。しかし最新の順位表によれば、注力すべきは最適化ではなく「リスクの封じ込め」のほうです。完璧な防御ではなく、被害の範囲（blast radius）を抑えることへ、論点を移すべきだということです。
事実この見立ては現状を正しく反映しているように思われます。本ブログでは、最新の順位を注意深く読み解くことで見えてくる重要な示唆について、分析していきます。
注目すべき3つの変化
1. 実務者の投票とエビデンスの乖離：誤情報（Misinformation）はエビデンスベースで順位が上昇
今回の順位付けから、エビデンスデータが考慮されるようになりました。実務者の投票が配点の75%、残る25パーセントは、公開脆弱性データベースとAI被害データベースから集めた6,639件の実インシデントにかかわるエビデンスデータに依拠しています。
新たに採用された25%のエビデンスデータが最も効いた箇所があります。それが『誤情報（Misinformation）』です。実務者の投票では下位でしたが、インシデント記録によって順位を2つ挙げることになりました。
この「実務者投票とエビデンスデータ」の乖離そのものが一つの重要な示唆を含んでいます。AIの技術者やAIセキュリティ実務家は、得てして攻撃者起因のリスク（インジェクション、漏洩、ポイズニング）に着目しがちです。しかし実インシデントの記録は、最も重大なインシデントは攻撃者不在であった、という客観的な事実を示しています。「モデルが単純に間違え、後続の処理がそれを疑わずに受け取った」、ただそれだけのことが、報告対象となり、実際の被害を生んでいるのです。
OWASPは、なぜこれが単なる出力ミスだけでは済まず、システム全体の障害になる理由について次のように説明しています ―『モデルの出力が、ツールを呼び出し、コードを書き、システムの状態を推し量り、操作を許可し、エージェント同士をつなぐ。その起点で出力を間違えれば、それはもう「間違った出力」ではなく、システム全体を動かす判断になってしまう。』
2. モデルの出力よりも「実行」が被害額を左右する：『過剰権限（Excessive Agency）』『無制限の消費（Unbounded Consumption）』が実被害をもたらしている
『過剰権限（Excessive Agency）』は3位に上昇し、この項目では実務者の投票もインシデントデータも同じ傾向を示しました。エージェントに実作業を任せている領域で、実際の被害が出ているということです。『無制限の消費（Unbounded Consumption）』は実務者の投票によって4つ順位を上げました。リソースとコストの枯渇が、請求書に金額として目に見えるようになったためです。
この2つが大きく順位を上げていることから、起業に対して最も大きなインパクトをもたらすのは、決して見苦しい出力ではなく、実際に実行された操作、そして費やしたお金であることがわかります。
最小権限という、これらのリスクへの対策の大半は古くからサイバーセキュリティの領域で語られてきたものです。権限範囲の最小化、有効期間を短く絞った資格情報、レート制限と支出上限、不可逆な操作に対する人間の承認といった考え方は、AIであれ人間であれ変わらない対策です。そしてこうした対策は、AppSecの領域が20年以上培ってきた基本的な管理手法であり、AIにもそのまま応用が利くものです。 AIに特有の要素があるとすれば、「作業者の洗い出し」そのものがタスクとなる点だといえます。当然、管理の外にある作業者に権限範囲を設定することはできません。自社の環境にどんなAIコンポーネントがあり、どれが自律的に動き、何にアクセスでき、誰が立ち上げたのか——説明のつく形で把握し設計することで、ようやく「最小権限」の前提が整うことになります。
3. カテゴリの整理・統合：「プロンプト」だけではなく「コンテキスト全体」の管理がアジェンダに
『システムプロンプトの漏洩（System Prompt Leakage）』は、『隠しコンテキストの露出（Hidden Context Exposure）』に名前が変わりました。また、画像や音声に隠された『クロスモーダル攻撃（Cross-Modal Attack）』は、プロンプトインジェクションに取り込まれた。『ファインチューニングの悪用（fine-tuning subversion）』は、『データおよびモデルのポイズニング（Data and Model Poisoning）』に取りこまれた。『出力処理の不備（Output Handling）』は、5位から10位へ下がった一方でその適用範囲を広げた。
OWASPは新カテゴリの追加ではなく、既存カテゴリを合理的な形で統合と整理しました。統合の方向性は一つの示唆として理解すべきでしょう。
防御の対象は、もはやプロンプトの入力欄だけではなく、モデルが読み込むコンテキスト全体です。今回のカテゴリ整理は、コンテキストウィンドウに入るものはすべて、どんな形式で届いたにせよ、誰が入れたにせよ、信頼できない入力として扱うべきであることを示しています。
OWASPが突きつける、防御範囲に関する課題
2026年版は、LLM Applicationのリスト全体のスコープを明確化した点も特徴です。このリストのスコープは、アプリケーションの部品として組み込まれたモデルがもつ、LLMのセキュリティリスクであり、モデルが「自ら動く」主体である場合、すなわちモデル自身が呼び出せるツールを持ち、セッションをまたいで記憶を引き継ぎ、下流のシステムを動かすようになった瞬間、これらのリスクを洗い出すために参照すべきリストはTop 10 for LLM Applicationsではなく、Agentic Top 10へと変わるという点を明示しています。
2つの似た名前のリストがあるからといって、単に「どちらのリストに載っているか」だけで、リスクを捉えるべきではありません。AIにかかわるアプリケーションリスクを洗い出す際には、そのコンポーネントが「どんなことまでできるか」を考える必要があります。次の三点は、「どんなことまでできるか」を具体的に問うための観点です。
- セッションをまたいで状態を保持するか。
- ツールを呼び出したり、他のシステムを動かしたりできるか。
- 何に書き込めるのか、そしてその書き込み先の先には何があるのか。
この3点を確認することで、OWASPのどちらのリストを見ればいいのか、影響範囲はどこまで及ぶのか、封じ込めをどこに置くべきなのか、を把握できるはずです。
新しいOWASPを踏まえて、次の四半期にやるべきタスク
まずは、モデル、エージェント、MCPサーバー、リポジトリへの書き込み権限を持つコーディングアシスタント、そしてIT管理やセキュリティ関連部門に知らせないままチームが立ち上げたAI、そういったものを洗い出すことから始めるべきです。実際に権限を設定し、リスクの封じ込めができる情報でないならば、それはリスク管理とは到底呼べないものになってしまいます。
AIの関わるコンポーネントを洗い出したうえ、そのコンポーネントに「どんなことまでできるか」で分類します。AIリスクは、どのOWASPリストに載っているかを整理しても、ましてやベンダー別にコンポーネントをリスト化しても管理できるわけではありません。
多くの企業がアプリケーションのコーディングにAIを活用し始めていますが、「AIが示す提案や修正は、自社のツールが出したものも含めて、検証されていない入力として扱う。」「その内容に責任を持てないかぎり、修正方針の権限をパッチ適用エージェントに渡してはならない。」こうした原則を明文化できている企業が、どれほどあるでしょうか。
- 失敗が表に出ないまま進むことを検知できるよう、計測を仕込む。
- 受け入れ基準を「再現コードが動かなくなったか」から「脆弱な経路がまだ残っていないか」へ変える。
- 自社の品質確認、脆弱性管理基準を持つ。
- すでに修正済みのバグを対象に、自社のコードでベンチマークを回す
- 他社の平均値を前提に計画を立てるのはやめる
AIがアプリケーション開発を本質的に加速させるためには、こうした仕組みを取り入れることが不可欠です。
OWASP LLM Top10 2026 の示唆
「たとえAIモデルが失敗しても、致命的な被害につながらないような仕組みを作るべきである」これが、新たなOWASPから見えてくる示唆だといえます。では、そんな仕組みは誰が、どのようにしてつくることができるのでしょうか。
少なくとも「AIモデル自身がその仕組みをすべて担うことはありえない」とは言えるでしょう。ヒトがそうであるように、AIコンポーネントもまた、自分自身ではその影響範囲を適切に制御することができないからです。かといって、その出力を生み出したモデルのベンダーにすべてを委ねるべきでもありません。ベンダー自身が検査や評価に使われるモデルを作成すると、それらの判定の基準は出力を生み出すモデルと同じものになってしまいます。それでは、出力したモデルの見落としを、検査するモデルも同様に見落とすことになるでしょう。
「同じモデルが制御を担えない」というのは、性能が向上すれば解決する話でもありません。確かにフロンティアモデルの性能は改善を続けており、今日のモデルが間違えることを、半年後のモデルは間違えないということもあるでしょう。しかし、これはあくまでも「間違える確率が下がる」だけであり監査する者が作成者本人であってはならない、という構造の話を解決するものではありません。
Mend.ioは、アプリケーションコードを書きません。我々が行うのはあくまで検証であり、アシスタントが書いたコードも、それを生成したものが何であれ検証します。
現在Mendプラットフォームで提供しているのは、自社環境にあるモデル、エージェント、AIコンポーネントの検出とAI-BOM、モデルリスクとエージェント設定リスクのスキャン、システムプロンプトのハードニング、レッドチーミング、そしてアプリ内またはプロキシ経由でのランタイム保護です。あわせて、コードそのものに対するSCA、SAST、コンテナおよびIaCのスキャンも提供しております。 AIモデルが騙されるのは避けられません。それが問題になるかどうかは、その周りに何を作ったかで決まるのです。
出典：OWASP GenAI Security Project、Top 10 for LLM Applications 2026年版、Top 10 for Agentic Applications 2026年版
