2026年版では、セキュリティ実務家による評価だけでなく、実際に発生したインシデントのデータを順位付けに取り入れた。OWASPは公開脆弱性データベースやAI被害のデータベースから7714件の実例を集め、そのうち十分な情報がある6639件を分類。最終的な順位では、コミュニティーによる評価を75％、インシデントデータを25％の重みで反映した。

　その結果、2025年版から順位も変化した。「Excessive Agency」（過剰なエージェンシー）は6位から3位に上昇し、「Unbounded Consumption」（無制限の消費）は10位から6位に上昇した。一方、「Improper Output Handling」（不適切な出力処理）は5位から10位に下がった。「System Prompt Leakage」（システムプロンプトの漏えい）は対象範囲を広げ、「Hidden Context Exposure」（隠れたコンテキストの露出）に再定義された。

第1位．プロンプトインジェクション

　LLMは、システムから与えられた「指示」と、ユーザーや外部システムから渡された「データ」を、アーキテクチャ上明確には区別しない。システムプロンプト、ユーザー入力、取得した文書、ツールの出力、会話履歴、メモリなどが同じコンテキスト内で扱われる。この性質を悪用し、開発者が意図しない動作をLLMにさせるのがプロンプトインジェクションだ。

　プロンプトインジェクションは、攻撃者がチャット画面から直接命令を入力する方法だけではない。Webページや電子メール、RAG（検索拡張生成）が取得する文書、ツールの出力などに命令を仕込む「間接プロンプトインジェクション」もある。

　OWASPは、現在の生成AIではプロンプトインジェクションを確実に防止する方法はないとしている。そのため、「侵入されないこと」だけに頼るのではなく、侵入された場合でも重大な処理につながらない設計が必要だ。LLMに与える権限を絞る、出力を後続システムが利用する前に検証する、重要な操作には人間の承認を挟むといった多層防御が重要になる。

第2位．機密情報の開示

　機密情報の開示で問題になるのは、LLMに入力した情報から顧客情報が漏れるケースだけではない。2026年版では、ツールを呼び出す際の引数、推論に伴う情報、RAGで取得したデータ、ログ、テレメトリー、「埋め込み」（エンベディング）なども情報漏えいの経路になり得るとしている。

　学習時にLLMがデータを記憶し、後から再現してしまう場合もあれば、推論時にシステムプロンプトやファイル、別セッションの情報などを意図せず出力する場合もある。対象となる情報には、個人情報、医療情報、財務データ、認証情報、APIキー、営業秘密、モデルの重みなどが含まれる。

　対策としては、LLMに渡す情報自体を最小化することが重要だ。RAGについても、文書を取得した後でアクセス権を確認するのではなく、検索する段階でユーザーが閲覧可能な文書やチャンクだけに対象を絞る。システムプロンプトに認証情報や秘密情報を格納しないことも基本となる。

第3位．過剰なエージェンシー

　2025年版の6位から3位へ上昇したのが「Excessive Agency」（過剰なエージェンシー）だ。OWASPは、この順位上昇を2026年版における最も重要な変化としている。背景には、AIエージェントを利用したシステムで実際の被害が顕在化していることがある。

　AIエージェントは、LLMの回答を表示するだけでなく、ツールを呼び出したり、APIを利用したり、他のシステムを操作したりできる。

　一方、AIエージェントに「機能」「権限」「自律性」を必要以上に与えることは問題になり得る。例えば、文書を読むだけでよいAIエージェントに、文書の変更や削除までできるツールを与えていれば、プロンプトインジェクションやハルシネーションをきっかけに、不要な処理まで実行する可能性がある。データベースを参照するだけの用途なのに、更新や削除の権限を持つアカウントで接続することも同様だ。

　その対策は、利用可能なツールとその機能、アクセス権限を必要最小限にすることだ。高い影響を伴う処理については、人間の承認を必須にする。LLM自身に「この操作を許可してよいか」を判断させるのではなく、独立した認可ロジックで検証することもOWASPは推奨している。

第4位．サプライチェーン

　LLMアプリケーションのサプライチェーンには、ソフトウェアのライブラリだけでなく、学習データ、事前学習済みモデル、ファインチューニング用のアダプター、モデルの変換・統合処理、実行基盤などが含まれる。

　例えば、AIモデルデータベース「Hugging Face」のような外部サービスからモデルを取得する場合、それ自体が攻撃経路になり得る。攻撃者がモデルやデータを改ざんしたり、正規のモデルと見せかけて悪意あるモデルへ差し替えたりする可能性があるためだ。

　そこで企業は、モデルやデータについて「どこから入手したのか」を追跡できるようにし、モデル、データ、アダプターなどの真正性を検証する必要がある。脆弱性スキャンだけを安全性の保証と考えず、来歴の確認や署名、バージョン固定などを組み合わせることが重要になる。

第5位．データとモデルのポイズニング

　攻撃者がデータやモデルに手を加え、バックドアや偏り、意図しない振る舞いをAIシステムに埋め込む。対象は従来の学習データに限らない。事前学習やファインチューニング、エンベディング作成、RAG、モデル配布など、データやモデルが取り込まれ、再利用されるさまざまな段階で発生する可能性がある。

　RAGのナレッジベースも攻撃の対象だ。攻撃者が特定の質問に対して検索されやすい文書を紛れ込ませれば、本来正しい情報が存在していても、汚染された文書をLLMに参照させられる可能性がある。

　対策として、データとモデルの来歴を記録すること、外部から入ってくるデータを検証すること、データセットの変更履歴を残すことなどがある。RAGでは、参照元の信頼度を評価するとともに、外部データとシステムからの指示を分離することも重要になる。

　後編は、第6位以降のリスクと、対策のまとめを紹介する。

本稿は、IBM Technologyが2026年3月7日に公開した動画「OWASP's Top 10 Ways to Attack LLMs：AI Vulnerabilities Exposed」と「OWASP Top 10 for Large Language Model Applications」を基に作成しました。