OWASP LLM Top10 2026、専門家と実データの差

結論から書きます。LLMアプリのリスク順位表として定着した「OWASP Top 10 for LLM」が2026年版に更新され、10項目のうち8項目が順位を動かしました。そして今回初めて、順位づけに実際のインシデント記録が使われています。ところが、その作成メンバー自身が公開した査読前論文によれば、専門家投票による順位と、実インシデントデータから導いた順位はほとんど一致しませんでした（Cohen’s κ ≈ 0.20）。

これは「Top 10が間違っている」という話ではありません。「専門家が怖いと思うもの」と「公開記録に残るもの」は別物だという、リスク評価の実務にそのまま効く事実です。

この記事でわかること

  • OWASP LLM Top 10 2026年版で何が上がり、何が下がったのか（対照表つき）
  • 順位づけに使われた約7,700件のインシデントコーパスと、その集計方法
  • 専門家の順位と実データの順位が最も食い違った項目（プロンプトインジェクションは実データでは12位）
  • この乖離を情シスが自社のリスク評価にどう反映すべきか
  • 査読前研究としての限界と、鵜呑みにしてはいけない点

OWASP Top 10 for LLMとは何か

OWASP Top 10 for LLM Applicationsとは、大規模言語モデル（LLM）を組み込んだアプリケーションで特に重大なセキュリティリスクを10項目に絞って順位づけした、コミュニティ主導のリスク一覧です。ウェブアプリ向けの「OWASP Top 10」のLLM版にあたります。

使うのは、生成AIを業務に組み込む側です。社内チャットボット、社内文書を検索させるRAG、業務システムを操作させるAIエージェント——こうした案件のセキュリティ要件やレビュー観点を作るとき、「何を漏れなく見るべきか」のチェック軸として参照されます。情シスにとっては、開発部門やベンダーから上がってくるAI導入案件を審査する際の共通言語です。名前を知らなくても、提出された設計書のセキュリティ章がこの10項目に沿って書かれていることは十分あり得ます。2026年版は2026年8月4日にOWASP GenAI Security Projectから公開されました。

2026年版で何が変わったのか

10項目のうち8項目が順位を動かし、1項目が改名されました。最大の変動は「過剰な代理権（Excessive Agency）」がLLM06から3つ上がってLLM03になったことです。

2026年版 項目 2025年版の位置 変動
LLM01 プロンプトインジェクション LLM01 変化なし（3年連続1位）
LLM02 機密情報の漏えい LLM02 変化なし
LLM03 過剰な代理権（Excessive Agency） LLM06 3つ上昇
LLM04 サプライチェーン LLM03 1つ下降
LLM05 データ・モデルの汚染 LLM04 1つ下降
LLM06 無制限な資源消費 LLM10 4つ上昇
LLM07 誤情報（Misinformation） LLM09 2つ上昇
LLM08 隠れコンテキストの露出 LLM07 1つ下降・改名
LLM09 ベクトル・埋め込みの弱点 LLM08 1つ下降
LLM10 不適切な出力処理 LLM05 5つ下降

実務目線で押さえるべき変化は2つです。

ひとつは「過剰な代理権」の上昇。2025年時点の生成AI利用はチャット画面が中心でしたが、いまはツール実行権限・ファイルアクセス・API権限・永続メモリを持つエージェントが業務に入り始めています。モデルが「答えを返す」のではなく「作業を実行する」ようになった以上、攻撃面の性質そのものが変わった、という整理です（関連：AIエージェントの過剰権限を学習で抑制する研究）。

もうひとつはLLM08の改名です。旧「システムプロンプトの漏えい」が「隠れコンテキストの露出（Hidden Context Exposure）」に広げられました。守るべきは冒頭の指示文だけではなく、RAGで引いてきた社内規程の本文、ツールのスキーマ定義、業務ワークフローの手順——モデルの文脈に入る「見えていない社内情報」すべてだという趣旨です。社内文書をRAGに載せている組織には直接効きます。

今回の論文は何を調べたのか

一言でいうと「専門家の投票で決めた順位は、実際に起きた事故の記録と一致するのか」を検証した研究です。

論文は Incident-Data Robustness Analysis of the OWASP Top 10 for LLM Applications (2026)（Kyriakos “Rock” Lambros、Steve Wilson、2026年8月18日 arXiv投稿）。著者はいずれもOWASP側のワーキンググループメンバーで、Wilson氏はGenAI Security Projectの共同議長です。ただし論文自身が「2名による探索的分析であり、公式リリースではない。公式の一覧やプロセスに取って代わるものではない」と明記しています。査読前のプレプリントである点も踏まえて読む必要があります。

手法はおおむね次の通りです。

  • コーパス：CVE、GHSA、OSV、およびAIAAIC（AI関連の事故・被害データベース）から7,714件を収集し、うち6,639件を20項目のタクソノミーに分類。内訳はセキュリティ系が6,297件、AIハーム系が342件。
  • 補正：分類はLLM分類器に行わせたうえで、分類器の適合率・再現率のズレをベイズの測定誤差モデルで補正し、各カテゴリの件数を推定。
  • 合成：最終的な2026年候補リストは専門家投票0.75、データ0.25の固定比率で合成。データが専門家の合意を「修正はするが覆さない」設計です。

この0.75:0.25という重みづけ自体が、今回の結果を先取りした判断だったと言えます。

専門家とデータはどこで食い違ったのか

両者の一致度はCohen’s κ ≈ 0.20、90%区間は−0.16〜0.57でゼロをまたぎます。統計的に「一致している」とは言えない水準です。論文が挙げる乖離の大きい項目は次の通りです。

項目 専門家投票 実データ 論文の説明
プロンプトインジェクション 1位 12位 攻撃面は依然巨大だが、稼働中のシステムは能動的に防御しており、公開報告される成功事例は相対的に少ない
誤情報（Misinformation） 13位 2位 AIAAICのディープフェイク・AI生成偽情報が大量に含まれる
兵器化されたLLM悪用（新設候補） 17位 8位（863件） 定義が広く、合成メディア悪用やディープフェイク被害を吸収してしまう
永続メモリの汚染（新設候補） 4位 16位 新興の脅威で、公開されたインシデント記録がほぼ存在しない
MCPツールインタフェースの悪用（新設候補） 7位 16位 同上

なぜプロンプトインジェクションが実データで12位なのか

「起きていないから」ではなく「公開記録に残りにくいから」です。プロンプトインジェクションは多くが個別サービス上で完結し、CVE番号が振られる形の脆弱性として世に出るとは限りません。攻撃が成功しても、被害企業が詳細を公表する動機は乏しい。結果として、脆弱性データベースを数えるとカウントが伸びないわけです。

逆に誤情報が2位に来るのは、ディープフェイク被害が報道されやすく、記録に残りやすいからです。つまりこの乖離の相当部分は、脅威の実在量ではなくデータソースの写り方の偏りを表しています。似た構図は、フィードごとに見えている脅威が重ならないというCTI 20年分の研究でも指摘されていました。

また、新設候補である永続メモリ汚染やMCPツール悪用が実データで最下位付近に沈むのは、単にまだ事例が公開されていない新しい脅威だからです。ここでデータを優先すれば、これから増える脅威を軒並み過小評価することになります。0.75:0.25という重みづけは、この「新興脅威をデータが見落とす」問題への安全弁と理解できます。

情シスの実務にどう効くのか

1. リスク評価を「件数」だけで決めない。社内でリスクアセスメントをすると、どうしても「実際に何件起きたか」を根拠に優先度を決めがちです。しかし公開件数は「起きた量」ではなく「表に出た量」です。件数の少なさを「対策不要」の根拠に使わない——これを運用ルールとして明文化しておく価値があります。

2. 新しい脅威ほどデータが存在しない。AIエージェントに業務権限を渡す案件を審査するとき、「その攻撃の実例はあるんですか」と聞かれることがあります。永続メモリ汚染やMCP経由の攻撃は、まさに実例が公開記録にほぼ無い領域です。ここは実績ではなく構造（権限設計・監査ログ・人間の承認点）で判断するしかありません。

3. Top 10は「順位」より「10項目の網羅」で使う。順位が専門家投票7.5割で決まっている以上、1位と3位の差にこだわる意味は薄い。それより、AI案件のレビューで10項目すべてに一度は目を通したかを担保するチェックリストとして使うほうが実用的です。2026年版はAppendix AでNIST・MITRE・CSA等の既存標準への対応表を備えたとされており、社内の統制文書に接続しやすくなっています。

現場目線の所感

この論文でいちばん刺さったのは「プロンプトインジェクション：専門家1位、データ12位」の一行でした。現場の肌感覚と数字が合わない、という経験そのものだからです。社内で生成AI利用のルールを作るとき、「間接プロンプトインジェクションが怖い」と説明しても、経営層や事業部門から返ってくるのは「で、実際に被害は出ているんですか」。そこで出せる公開事例は驚くほど少ない。かといって「危険ではない」わけがない。この板挟みは多くの担当者が味わっているはずです。

OWASPの中の人たちが自分たちのデータで同じ壁にぶつかり、それを論文として公開したこと自体に価値があると思います。「データがないことは、安全であることを意味しない」を、社内説明で引用できる根拠つきで持てるようになったのは実務上の収穫です。

一方で、限られた人員で社内のあちこちに広がるAI利用を10項目すべての観点から見きるのは、率直に言って厳しいというのが実感です。まずは「権限を持つエージェント」と「社内文書を読ませているRAG」の2つに絞り、LLM03とLLM08から手を付けるのが現実的な落としどころだと考えています。

この研究の限界（重要）

査読前の探索的分析であり、論文自身が複数の限界を認めています。数字を独り歩きさせないために明記しておきます。

  • 正解データの作成者が1名：約1,200件の判定を単一の評価者が担当し、評価者間信頼性が測定されていません。しかもその評価者のブラインド判定は、合議の結果と553件で食い違ったとされています。分類の揺れは小さくありません。
  • 「対象外」を分類器が選べない：どのカテゴリにも当てはまらない事例が約38%あり、それらが無理にどこかへ振り分けられています。件数の多いカテゴリが実際より膨らむ方向のバイアスです。
  • データ層の不均衡：適合率の手検証はセキュリティ系のみ。AIハーム系（342件）の精度は前提を置いた推定に依存しており、誤情報カテゴリの高順位はこの影響を受けます。
  • κの区間がゼロをまたぐ：一致度が弱いことは示せても、「明確に不一致だ」と断定できる強さではありません。
  • 4つのフロンティア分類器を比較しても勝者は出ず、どれも基準線のバランス精度0.863を超えませんでした。ただし正解データに対する順序の相関はSpearman ρ = 0.918と高く、順位そのものは頑健だったと報告されています。

要するに「専門家の順位は当てにならない」という結論の論文ではありません。「データで検証しようとしたが、データ側の質と網羅性のほうが先に限界に達した」と読むのが妥当です。

まずどこを見るか（公的指針への接続）

AI利用のリスク評価を組み立てるなら、いきなり自前でチェックリストを作らず、公的な整理から入るのが早道です。

  • IPA「中小企業の情報セキュリティ対策ガイドライン」：リスクアセスメントの手順と社内規程への落とし方の型。AI利用ルールもこの枠組みに乗せるのが管理上ラクです。
  • IPA「対策のしおり」：エンドユーザ啓発の教材。誤情報（LLM07）や機密情報の投入（LLM02）は、技術的制御より利用者教育で減らせる部分が大きい領域です。
  • OWASP GenAI Security Projectの2026年版本体（Appendix Aの標準対応表）：NIST・MITRE系の管理策と紐づけて社内の統制文書に接続します。

まとめ

  1. 2026年版（2026年8月4日公開）は10項目中8項目が変動。「過剰な代理権」がLLM06→LLM03へ上昇し、「システムプロンプトの漏えい」は「隠れコンテキストの露出」へ拡張された。エージェントとRAGを抱える組織はここから着手を。
  2. 初めて実インシデント7,714件が順位づけに使われたが、専門家投票との一致はκ≈0.20と弱い。プロンプトインジェクションは専門家1位・データ12位、誤情報は専門家13位・データ2位。
  3. 乖離の主因は脅威の実在量ではなくデータの写り方の偏り。「公開事例が少ない＝安全」ではない。ただし本研究は査読前の探索的分析であり、分類の揺れなど限界も大きい。

出典

関連記事

タイトルとURLをコピーしました