第6位．無制限の消費

　第6位の「Unbounded Consumption」（無制限の消費）は、2025年版の10位から4つ順位を上げて6位となった。OWASPによると、計算資源やコストを枯渇させるリスクを実務家が以前より重く評価したことが順位上昇につながったという。

　LLMは一般的なアプリケーションよりも大量の計算資源を使用する場合がある。攻撃者が大量のリクエストを送ったり、極端に処理量の多い要求を繰り返したりすれば、サービスを利用不能にするだけでなく、APIやクラウド基盤の利用料金を膨らませることもできる。

　そのため従来型のDoS対策に加え、ユーザーごとのトークン数や費用、AIエージェントの実行回数などに上限を設け、異常なリソース消費を監視する必要がある。

第7位．誤情報

　LLMが自信ありげに誤った情報を生成し、それを人間や後続システムが正しいと信じることで被害が発生する。単なる回答ミスではなく、財務上の損失やセキュリティインシデント、安全上の問題、業務停止などにつながればセキュリティ上のリスクとなる。

　例えばAIコーディングエージェントが実在しないパッケージ名を生成し、攻撃者があらかじめ同じ名前で悪意あるパッケージを登録していれば、開発者がその出力を信じてインストールすることで侵害につながる可能性がある。

　そこで、重要な判断では、LLMが生成した内容の正しさをうのみにせず、情報源との整合性を検証する。重大な処理には承認フローを設け、LLMの出力を根拠として自動実行する範囲を限定する必要がある。

第8位．隠れたコンテキストの露出

　隠れたコンテキストの対象となるのは、システムプロンプトだけではない。開発者からの指示、RAGから取得したポリシー、ツールや関数のスキーマ、アクセス権限、ワークフローの判定条件など、本来ユーザーから見えないコンテキストが抽出、推測、再構築されることを指す。

　これらが漏れれば、攻撃者は「どのような条件ならLLMが拒否するのか」「どのツールが利用可能なのか」「どのような権限体系なのか」といった情報を把握し、次のプロンプトインジェクションなどに利用できる。

　OWASPは、LLMから見えるコンテキストはユーザーにも発見され得るという前提で設計するよう求めている。認証情報やAPIキーなどをシステムプロンプトに保存せず、認可やアクセス制御もプロンプトの秘密性に依存させないことが重要だ。

第9位．ベクトルとエンベディングの弱点

　RAGでは文書を数値化したエンベディングを利用し、質問との類似度を基に参照する情報を選ぶ。この検索処理にも、アクセス制御やデータの検証といったセキュリティ対策が必要になる。

　例えば複数のテナントのデータを同じベクトルインデックスに保存し、検索した後でアクセス権を確認する設計では、攻撃者が検索結果の件数や類似度、応答時間などから他社のデータの存在を推測できる可能性がある。また、保存されたエンベディングから元の文章を復元する「埋め込み逆変換」（Embedding Inversion）もリスクになる。

　そこで企業には、ベクトルデータを「元文書より安全なデータ」と考えないようにすることを薦める。OWASPは、ベクトルデータベースのバックアップや第三者サービスに渡したエンベディングが流出した場合も、元文書が漏れたのと同様に扱う必要があるとしている。

第10位．不適切な出力処理

　「不適切な出力処理」（Improper Output Handling）は、2025年版の5位から順位を下げた。

　まずは、LLMの出力を「信頼できるデータ」として扱わないことが重要だ。LLMが生成したHTMLやSQL、プログラムコード、コマンドなどを検証せずに別のシステムへ渡せば、クロスサイトスクリプティングやSQLインジェクション、任意コード実行などにつながる可能性がある。

　そこで、出力先に応じたエンコードや検証を実施し、データベース操作ではパラメーター化されたクエリを使うなど、従来のアプリケーションセキュリティ対策を適用することが基本になる。

「LLMそのものを守る」だけでは不十分

　全リスクを見ると、LLMセキュリティに単一の対策は存在しないことが分かる。

　例えばプロンプトインジェクションへの対策を講じても、RAGの参照データが汚染されていたり、AIエージェントに過剰な権限が与えられていたりすれば、別の経路から被害が発生する可能性がある。そこで重要になるのが多層防御だ。入力からデータ、権限、出力後の処理まで、攻撃や誤動作が起こり得る各段階に対策を講じる。以下は具体的な対策だ。

1．LLMへの入力と出力の監視、検証

　クルム氏は監視、検証の手段として、AIファイアウォールやAIゲートウェイをLLMの前後に配置し、悪意あるプロンプトを遮断したり、出力に含まれる機密情報をマスキングしたりする方法を挙げる。

2．モデルやデータの出所の確認

　外部から入手したモデルや学習データ、RAGの参照データについて、提供元を評価し、どのような経路で入手したのかを追跡できる状態にする。脆弱性スキャンやレッドチームによるテストも実施し、攻撃者の視点からシステムを検証する。

3．アクセス制御と最小権限の徹底

　モデルや学習データ、RAGのデータを誰でも変更できる状態にせず、アクセスできる利用者を限定する。AIエージェントについても、利用できるツールやAPI、操作できるシステムを業務上必要な範囲に絞る。

4．人間による確認の徹底

　LLMは攻撃を受けていなくても誤情報を生成する可能性がある。特に重要な業務判断や外部システムの変更につながる処理では、LLMの回答をそのまま実行するのではなく、人間によるファクトチェックや承認を組み込む必要がある。

　LLMの利用範囲が広がれば、守るべき対象も増える。学習データ、RAG、モデル、プロンプト、出力、AIエージェントの権限、API、ツール、接続先システムまでを一つのAIシステムとして捉えることが必要だ。

　生成AIが「質問に答えるツール」から「自律的に業務を実行するシステム」へ変わるほど、攻撃や誤動作による影響範囲も広がる。企業には、LLMだけを守ろうとするのではなく、LLMがだまされる可能性を前提として、重大な被害につながらないシステムを設計、運用することが求められる。

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