OWASPは、LLMアプリケーションの主要なセキュリティリスクをまとめた「Top 10 for LLM Applications 2026」を公開した。同レポートが明らかにした10個のリスクとは。
プロンプトインジェクション対策を講じても、自社は安全とは限らない。RAGの参照データが汚染されていたり、AIエージェントに過剰な権限を与えていたりすれば、被害は別の経路から入り込む。
ソフトウェアのセキュリティ向上を目的に活動する非営利組織Open Worldwide Application Security Project（OWASP）は2026年8月4日（米国時間）、最新版「Top 10 for LLM Applications 2026」を公開した。本稿は前編に続き、IBMのディスティングイッシュトエンジニア、ジェフ・クルム氏の解説と併せて、残る5つのリスクと対策を紹介する。
第6位の「Unbounded Consumption」（無制限の消費）は、2025年版の10位から4つ順位を上げて6位となった。OWASPによると、計算資源やコストを枯渇させるリスクを実務家が以前より重く評価したことが順位上昇につながったという。
LLMは一般的なアプリケーションよりも大量の計算資源を使用する場合がある。攻撃者が大量のリクエストを送ったり、極端に処理量の多い要求を繰り返したりすれば、サービスを利用不能にするだけでなく、APIやクラウド基盤の利用料金を膨らませることもできる。
そのため従来型のDoS対策に加え、ユーザーごとのトークン数や費用、AIエージェントの実行回数などに上限を設け、異常なリソース消費を監視する必要がある。
LLMが自信ありげに誤った情報を生成し、それを人間や後続システムが正しいと信じることで被害が発生する。単なる回答ミスではなく、財務上の損失やセキュリティインシデント、安全上の問題、業務停止などにつながればセキュリティ上のリスクとなる。
例えばAIコーディングエージェントが実在しないパッケージ名を生成し、攻撃者があらかじめ同じ名前で悪意あるパッケージを登録していれば、開発者がその出力を信じてインストールすることで侵害につながる可能性がある。
そこで、重要な判断では、LLMが生成した内容の正しさをうのみにせず、情報源との整合性を検証する。重大な処理には承認フローを設け、LLMの出力を根拠として自動実行する範囲を限定する必要がある。
隠れたコンテキストの対象となるのは、システムプロンプトだけではない。開発者からの指示、RAGから取得したポリシー、ツールや関数のスキーマ、アクセス権限、ワークフローの判定条件など、本来ユーザーから見えないコンテキストが抽出、推測、再構築されることを指す。
これらが漏れれば、攻撃者は「どのような条件ならLLMが拒否するのか」「どのツールが利用可能なのか」「どのような権限体系なのか」といった情報を把握し、次のプロンプトインジェクションなどに利用できる。
OWASPは、LLMから見えるコンテキストはユーザーにも発見され得るという前提で設計するよう求めている。認証情報やAPIキーなどをシステムプロンプトに保存せず、認可やアクセス制御もプロンプトの秘密性に依存させないことが重要だ。
RAGでは文書を数値化したエンベディングを利用し、質問との類似度を基に参照する情報を選ぶ。この検索処理にも、アクセス制御やデータの検証といったセキュリティ対策が必要になる。
例えば複数のテナントのデータを同じベクトルインデックスに保存し、検索した後でアクセス権を確認する設計では、攻撃者が検索結果の件数や類似度、応答時間などから他社のデータの存在を推測できる可能性がある。また、保存されたエンベディングから元の文章を復元する「埋め込み逆変換」（Embedding Inversion）もリスクになる。
そこで企業には、ベクトルデータを「元文書より安全なデータ」と考えないようにすることを薦める。OWASPは、ベクトルデータベースのバックアップや第三者サービスに渡したエンベディングが流出した場合も、元文書が漏れたのと同様に扱う必要があるとしている。
「不適切な出力処理」（Improper Output Handling）は、2025年版の5位から順位を下げた。
まずは、LLMの出力を「信頼できるデータ」として扱わないことが重要だ。LLMが生成したHTMLやSQL、プログラムコード、コマンドなどを検証せずに別のシステムへ渡せば、クロスサイトスクリプティングやSQLインジェクション、任意コード実行などにつながる可能性がある。
そこで、出力先に応じたエンコードや検証を実施し、データベース操作ではパラメーター化されたクエリを使うなど、従来のアプリケーションセキュリティ対策を適用することが基本になる。
全リスクを見ると、LLMセキュリティに単一の対策は存在しないことが分かる。
例えばプロンプトインジェクションへの対策を講じても、RAGの参照データが汚染されていたり、AIエージェントに過剰な権限が与えられていたりすれば、別の経路から被害が発生する可能性がある。そこで重要になるのが多層防御だ。入力からデータ、権限、出力後の処理まで、攻撃や誤動作が起こり得る各段階に対策を講じる。以下は具体的な対策だ。
クルム氏は監視、検証の手段として、AIファイアウォールやAIゲートウェイをLLMの前後に配置し、悪意あるプロンプトを遮断したり、出力に含まれる機密情報をマスキングしたりする方法を挙げる。
外部から入手したモデルや学習データ、RAGの参照データについて、提供元を評価し、どのような経路で入手したのかを追跡できる状態にする。脆弱性スキャンやレッドチームによるテストも実施し、攻撃者の視点からシステムを検証する。
モデルや学習データ、RAGのデータを誰でも変更できる状態にせず、アクセスできる利用者を限定する。AIエージェントについても、利用できるツールやAPI、操作できるシステムを業務上必要な範囲に絞る。
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」を基に作成しました。
Copyright © ITmedia, Inc. All Rights Reserved.
瞬時にM365が乗っ取られる――全社員に周知すべき“新フィッシング”の教訓
MFA（多要素認証）を入れたから安心という常識が崩れ去っている。フィッシング集団「Tycoon2FA」が摘発されたが、脅威が完全になくなったというわけではない。
「サイト内検索」＆「ライブチャット」売れ筋TOP5（2025年5月）
今週は、サイト内検索ツールとライブチャットの国内売れ筋TOP5をそれぞれ紹介します。
「ECプラットフォーム」売れ筋TOP10（2025年5月）
今週は、ECプラットフォーム製品（ECサイト構築ツール）の国内売れ筋TOP10を紹介します。
「パーソナライゼーション」＆「A／Bテスト」ツール売れ筋TOP5（2025年5月）
今週は、パーソナライゼーション製品と「A／Bテスト」ツールの国内売れ筋各TOP5を紹介し...
ITmediaはアイティメディア株式会社の登録商標です。
