LLMセキュリティとは、大規模言語モデル（LLM）アプリケーションを、それを提供するあらゆるレイヤー（モデル、プロンプトおよびモデルが参照するコンテキスト、モデルを実行する推論サーバー、モデルへのリクエストをルーティングするオーケストレーションソフトウェア、およびモデルが返す結果を処理するコード）にわたって保護する取り組みのことです。ここでいうLLMとは、大規模言語モデル（Large Language Model）のことであり、法学の修士号（LLM）を指すものではありません。
このトピックに関して公開されているガイダンスの多くは、モデル段階で終わっています。このページは、モデルが扱う範囲のその先から始まります。その下層にあるレイヤー、つまり推論サーバー、分散コンピューティングフレームワーク、検索ストア、そしてそれらを前段に置くゲートウェイは、通常のソフトウェアであり、通常のCVE識別子や修正済みバージョンがあり、いくつかのケースでは連邦政府による是正措置の期限も設定されています。これこそが、セキュリティチームが今週すぐに対処できる部分なのです。
大規模言語モデルとは、非常に大規模なテキストコーパスを用いて学習され、テキストの予測や生成を行うモデルのことです。企業での導入においては、このモデルが単独で動作することはほとんどありません。モデルはAPIの背後に配置され、取得したドキュメントを活用し、ツールを呼び出し、他のソフトウェアが利用する出力を返します。こうした各接続箇所は、何かしらの問題が発生する可能性のある箇所であり、そのうちのほんの一部しかモデル自体とは関係がありません。
これは、多くのガイダンスが曖昧にしてしまう違いです。モデルの安全性とモデルのセキュリティは重なり合っていますが、同じものではありません。2024年11月18日に公開された、LLMシステムのリスクに関するレッドハットの技術分析では、その境界線が明確に示されています。「LLMシステムがLLMの出力を使用し、それが機密性、完全性、または可用性に悪影響を及ぼす場合、そのシステムはセキュリティ上の脆弱性を生み出す」。 偏った回答や誤った回答を返すモデルには、安全性の問題があります。一方、その回答がエスケープ処理されずにシェルコマンド、データベースクエリ、または特権API呼び出しに渡されてしまうモデルには、セキュリティ上の問題があり、その問題は出力を信頼したコンポーネントに存在します。
このページでは、モデルを提供するスタックについて解説していますが、その範囲は意図的に限定されています。リスク分類体系全体は、GenAIセキュリティの範疇に属します。プロンプト注入の深さは prompt injectionに属します。包括的な対応範囲はAIセキュリティに、敵対的テストはAIレッドチーム活動に属します。ここでは、各レイヤーごとの一覧、それらのレイヤーに対して追跡されている脆弱性、セキュリティチームが活用できるアプリケーションからの出力情報、およびベンダーが提示する数値の読み解き方について解説しています。
LLMアプリケーションは、おおむね8層の深さがありますが、このトピックに関する既存の文献では、そのうち約3層についてしか扱われていません。開発者が関わる層については詳細なドキュメントが存在しますが、運用チームが担当する層については、ほとんど情報が公開されていません。
最初の4つは開発チームが担当します。次の3つはプラットフォームチームと運用チームが担当し、出力の処理は通常、それを実装したアプリケーションチームが担当します。この役割分担は重要です。なぜなら、CVEの対象となるレイヤーはほぼすべて運用側にあり、多くの場合、セキュリティ担当者が明確に定められていないままデプロイされてしまうからです。
Prompt injection、つまり巧妙に作成された入力を通じてモデルの挙動を操作する行為は、プロンプトおよびコンテキスト層において最もよく知られたリスクであり、これについてはここでは詳述せず、別のページで詳しく解説しています。自社環境内の管理されていない、あるいは承認されていない推論エンドポイントは、LLMの問題という以前に、「シャドウAI」の問題です。モデルが回答するだけでなく行動することが許可されている場合、ツールを呼び出す層は「エージェント型AI」のセキュリティ問題となります。
上記のすべてがアーキテクチャです。これは、あなたが手を加えることができる部分です。
サービングおよびオーケストレーション層においては、LLMのセキュリティ対策は、「インベントリ」「パッチ適用」「制限」という3つの馴染みのある動詞に集約されます。これらのコンポーネントにはCVE識別子、修正済みバージョン、公開されている脆弱性記録があり、その中には連邦政府による是正措置の期限が設定されているものもあります。これらに対処するために、機械学習の専門知識は必要ありません。
レイヤーおよびコンポーネント、CVE ID、評価者およびスコア、修正済みバージョンおよびステータス、推論サーバー、vLLM、CVE-2026-22778、2人のセカンダリ評価者が9.8（CRITICAL）と評価。 NVDプライマリースコアなし。0.8.3から0.14.1未満に影響、0.14.1で修正済み。KEVには含まれていない。推論サーバー、Ollama CVE-2026-7482同じCNAが、CVSS 4.0では8.8（HIGH）、CVSS 3.1では9.1（CRITICAL）を公表している。 NVDのプライマリースコアなし。0.17.1で修正済み。KEVInferenceサーバーには含まれない。NVIDIATriton CVE-2026-47627。NVIDIAがCNAであり、CVSS 3.1で9.8（CRITICAL）と評価されている。 NVDによる評価はまだ行われていない。バージョン0.0～26.05に影響。KEVには含まれていない。分散コンピューティング、Ray。CVE-2023-48022。NVDプライマリとしてNISTが指定、CVSS 3.1で9.8 CRITICAL。セカンダリとしてCISA-ADPが指定、CVSS 3.1で9.8 CRITICAL。正式に「係争中」とタグ付けされている。 2.52.0 以降でトークン認証が利用可能。KEVには含まれていない。SSVCの概念実証（PoC）が存在。分散コンピューティング、RayCVE-2025-62593。NISTがNVDのプライマリとして指定、CVSS 3.1で8.8（HIGH）。GitHubがCNAとして指定、CVSS 4.0で9.4（CRITICAL）。2.52.0で修正済み。 2026年8月17日にKEVに追加、2026年8月20日締切。MLライフサイクル、MLflow。CVE-2026-64849。GitHubはCNAとして、CVSS 3.1で9.3（CRITICAL）と評価。NVDはレコードを「Analyzed」とマークしているものの、プライマリスコアは公表していない。3.15.0で修正済み。 KEVに2026年8月19日に追加、期限は2026年9月2日。LLMゲートウェイ、LiteLLM。CVE-2026-42271。NISTがNVDプライマリとして指定、CVSS 3.1で8.8（HIGH）、ベクトルPR:L（認証済み呼び出し元を意味する）。バージョン1.74.2～1.83.6に影響、1.83.7で修正済み。 KEVに2026年6月8日に追加、期限は2026年6月22日。検索機能拡張型アシスタント。CVE-2025-32711。MicrosoftをCNAとして指定、9.3 CRITICAL。NISTをNVDプライマリとして指定、7.5 HIGH。KEVには未掲載、SSVCによる悪用例なし。
キャプション：2026年8月25日時点における、LLMのサービングおよびオーケストレーション層で追跡されている脆弱性。これは日付が記載されたサンプルであり、網羅的なリストではありません。 代替テキスト：8件のLLMインフラストラクチャの脆弱性を示す表。影響を受けるレイヤーとコンポーネント、CVE識別子、各評価機関とそのスコア、修正済みバージョンおよびKEVステータスが記載されている。
その表を活用するには、2つの点に留意する必要があります。まず、評価元を明記することです。CVE番号付与機関（CNA）による評価はNVDの評価とは異なり、このスタック上では両者の評価がしばしば一致しません。 CVE-2026-7482は、同じCNAによる評価でCVSS 4.0では8.8、CVSS 3.1では9.1となっていますが、NVDは当該レコードを「分析済み」とマークしているにもかかわらず、独自のベーススコアを公表していないため、「NVDによると9.1」という記述は誤りです。次に、見出しではなく説明文をよく読むことです。 CVE-2026-22778は単一のバグによるリモートコード実行ではありません。NVDはこれをCWE-209およびCWE-532（いずれも情報漏洩の脆弱性）に分類しており、その説明には「OpenCV/FFmpegのJPEG2000デコーダにおけるヒープオーバーフローと連鎖させることで、リモートコード実行が可能になる」ヒープアドレス漏洩について記載されています。
この層におけるボリュームは、ごくわずかなものでもなければ、静的なものでもない。ある NVDキーワード調査 2026年8月25日に実行し、 totalResults 各製品名のフィールドについて、Flowiseが129件、vLLMが70件、LangChainが68件、Triton Inference Serverが63件、Ollamaが36件、llama.cppが35件、LiteLLMが30件、SGLangが18件、TorchServeが4件のレコードが返されました。 その5日前には、これらの件数のうち3つが69、67、32と低く、高いものはなかった。集中度も見て取れる：2026年8月18日にはNVIDIA Triton Inference Serverに関するCVEが5件公開され、そのトップは CVE-2026-47627 9.8 CRITICALで、5つすべてがセカンダリースコアであり、NVDプライマリーは存在しない。
このレイヤーにおけるガバナンスの事例として最も明確なのは「Ray」です。2つの機関がCVE-2023-48022に「9.8 CRITICAL」の評価をつけていますが、NVDはこのレコードを正式に「係争中」としてタグ付けしています。これは、ベンダー側が「Rayは、そのドキュメントに記載されている通り、厳重に管理されたネットワーク環境以外での使用を意図していない」との立場をとっているためです。「係争中」のレコードは、一部の脆弱性管理ワークフローから除外されてしまいます。 このCVEはCISAの「既知の悪用済み脆弱性（KEV）」カタログには含まれておらず、CISAの「ステークホルダー別脆弱性分類」ではその悪用状況が「概念実証（PoC）」として記録されている一方、MITREはこれを悪用するキャンペーンを「C0045 ShadowRay」として追跡している。 一方、別の、議論の余地のない Ray の脆弱性である CVE-2025-62593 は、2026年8月17日に KEV に登録され、期限は 2026年8月20日となっており、その修正バージョンは 2.52.0 です。これは、議論の的となっている記録が、トークン認証が利用可能になったバージョンとして挙げているものと全く同じバージョンです。「導入によるセキュリティ」という前提は、制御策にはなりません。
KEVは、ここで取り上げる運用フィルターの中で最も精確です。2026年8月25日現在、カタログには1,675件のレコードが収録されており、そのうち10件がLLMスタックのコンポーネントです。内訳は、Langflowが6件、LiteLLMが2件、Rayが1件、MLflowが1件です。このトピックで通常挙げられる4つのCVEは、これらには含まれていません。繰り返し取り上げられている2、3つのブランドではなく、オーケストレーション層を中心にインベントリを再構築してください。
このレイヤーにおける露出は実際に存在するが、その測定は不十分であり、以下の調査結果のいずれも測定方法を明記していない。2026年5月にCyeraの報告を伝えたSecurityWeekは、その数を「現在、パブリックインターネット上に露出しているOllamaサーバーは約30万台」と推定した。2026年6月の盗まれたAIコンピューティングリソースに関する分析では、「130カ国以上にわたり、約17万5,000のOllamaインスタンスがパブリックに公開されている」と報告された。トレンドマイクロは、著者らが2024年11月と明記したスキャン期間において、「完全に開放されているサーバーが3,000台以上」を確認し、llama.cppについては「80台のサーバーが公開されており、そのうち57台は認証手段が一切ないようであった」と報告している。 2025年11月のRayキャンペーンに関するSecurityWeekの記事では、別の企業が「ウェブからアクセス可能なRayサーバーが23万台以上」と集計したことが報じられた。NVD自身のCVE-2026-7482に関する記録には具体的な数値は記載されておらず、「パブリックインターネットへの大規模な露出が確認された」とだけ述べられている。範囲、日付、および記載されていない手法については、調査結果として扱うこと。
パッチの検証は、パッチの適用とは別の作業であり、まさにここでAIレッドチームingの真価が発揮されます。この表は「期限付き」のものとして扱ってください。CVEの情報は急速に陳腐化し、KEVカタログは毎週更新されます。また、これはあくまで一例であり、完全な一覧ではありません。担当者を明確にし、レビューの頻度を定めてください。
モデルアーティファクトとは、データラッパー内の実行可能コードのことです。これが、この問題のすべてを一言で表したものです。
そのメカニズムは、処理順序の不一致によるものです。picklescan のようなスキャナは「まず Pickle ファイルの妥当性を検証し、検証に成功した場合にセキュリティスキャンを実行する」のに対し、Pickle の逆シリアル化は「インタプリタのように動作し、読み込まれたオペコードをその都度解釈する」ものです。 スキャンは読み込みの前に実行されます。実行は読み込み中に発生します。フレームワークによって読み込み可能でありながら、スキャナーに対して無効、見慣れない、または不正な形式に見えるものはすべて、その隙間をすり抜けてしまいます。
その差は単なる理論上のものではなく、これまでに3つの方法で測定されています。
2025年2月、ある公開モデルハブにおいて、「nullifAI」と呼ばれる手法を用いた悪意のあるモデルが、まさに2つ発見されました。この手法では、フレームワークが従来使用しているZIP形式ではなく、7z形式でアーティファクトを圧縮することで、スキャナーの検知を回避していました。2つ、それほど多くはありません。この事例の意義は、その数ではなく、その仕組みにあるのです。
2025年2月から3月にかけて、4件の別々のスキャナーバイパスにCVE識別子が割り当てられました。これらのスコアラー間の不一致は、前のセクションで取り上げたどの事例よりも大きくなっています。
CVE IDCNAスコア（CVSS 4.0）NVDプライマリースコア（CVSS 3.1）回避されたセキュリティ対策CVE-2025-17165.3 中程度 9.8 重大pip 安全でないグローバル変数として扱われなかったため、この変数を通じてパッケージを取り込んだモデルはスキャンを通過したCVE-2025-18895.3 中程度 9.8 重大 対象範囲には標準的なピックルファイルの拡張子のみが含まれていたため、非標準の拡張子は一切スキャンされなかったCVE-2025-19445.3 MEDIUM6.5 MEDIUMA 変更されたZIPヘッダーにより、フレームワークがまだモデルを読み込んでいる最中にスキャナーがクラッシュしたCVE-2025-19455.3 中程度 9.8 重大 ZIPフラグのビットが反転していたため、スキャナからはピックルファイルが隠されていたが、ローダーからは隠されていなかった
キャプション：広く使用されているモデルスキャナーのCVEに登録された4つのバイパス脆弱性。これらはすべて2025年2月から3月の間に公開されたもので、4つのうち3つではCVSSスコアに4.5ポイントの差がある。2026年8月25日現在、いずれもKEVカタログには登録されていない。 代替テキスト：4つのモデルスキャナー回避脆弱性をまとめた表。CNA CVSS 4.0スコア（5.3）と、NVDプライマリCVSS 3.1スコア（9.8、9.8、6.5、9.8）を比較し、それぞれの回避手法を記載している。
2026年7月、あるプレプリントが具体的な数値を提示した。ShadowPickleは3種類のステルス型ピクルス・デシリアライゼーション攻撃について解説し、この攻撃ファミリーが「10種類のSOTAスキャナーと4つのモデルハブを回避する」と報告している。その「Overwritten」亜種については、別途「スキャナー全体で63%の回避率を示し、既存の攻撃に比べて最大50%高い回避率を記録している」とされている。 この論文では、その63％という数値について、スキャナーの数やハブの数は明記されていない。これはプレプリントであり、査読を受けておらず、情報源も単一で、独立した再現実験も行われていないため、この数値を確固たる事実として受け止めるのではなく、懸念材料として捉えるべきである。重要なのはその方向性だ。すなわち、ほとんどのチームが依存しているスキャン対策には、推測に基づくものではなく、公表された回避率が存在するということである。
また、サプライチェーンはモデルファイルの範囲よりも広範に及んでいます。2026年7月16日に公開されたファーストパーティのモデルハブによるインシデント開示報告書によると、この侵害は悪意のあるモデルではなく、悪意のあるデータセットから始まったことが記録されています。「悪意のあるデータセットが、当社のデータセット処理における2つのコード実行経路（リモートコード実行可能なデータセットローダーと、データセット構成におけるテンプレートインジェクション）を悪用し、処理ワーカー上でコードを実行しました。」 そこから、同ハブの表現を借りれば、「攻撃者はノードレベルのアクセス権限を昇格させ、クラウドおよびクラスタの認証情報を収集し、週末の間に複数の内部クラスタへ横方向に移動した。」
ここで適用される制御策は、あまり華やかではありません。自身が管理するフォーマットについては、Pickleよりも安全センサーを優先し、管理していないアーティファクトについては出所の証明を求め、信頼できないモデルは、「読み込み＝実行」という前提に基づいて構築されたサンドボックス内で読み込むようにしてください。
ガードレールは、何を防いだかを教えてくれる。しかし、何を防げなかったかを教えてくれるものは、ほとんどない。
この非対称性こそが、このレイヤーにおける可視性の問題です。表を提示する前に、1つ注意点を述べておきます。LLMアプリケーションのテレメトリに関する権威ある公開インベントリは現時点では存在しないため、以下の表は実例を引用したものではなく、構成要素に基づいて推論されたものです。これを標準としてではなく、アーキテクチャの指針としてご利用ください。
イベント発信コンポーネント なぜセキュリティ上重要なのか それが欠如していることで隠されているもの プロンプトと応答の記録 アプリケーションまたはゲートウェイ 何が質問され、何が回答されたかに関する唯一の記録 モデルを介したデータの流出、 および正当なアカウントの悪用Guardrailの判定結果と一致したルールGuardrail何がどのルールに基づいてブロックされたかを表示Guardrailを通過したすべてのもの検索クエリと返されたドキュメント識別子検索およびベクトルストア回答をソースコーパスおよび権限セットに紐付けるユーザーが閲覧すべきでないドキュメントにアクセスしたかどうか引数付きツールまたは関数の呼び出しオーケストレーション層生成されたテキストがアクションとなるポイント権限の悪用、 およびインジェクション成功時の影響範囲ハッシュとソースを含むモデルアーティファクトの読み込みイベント推論サーバー読み込み時点での来歴を確立実際に実行されたアーティファクト、 かつそれが承認されたものだったか否か推論サーバーのエラー応答推論サーバーのエラー応答は攻撃対象領域となり、内部状態を漏洩させるサービング層に対する偵察エンドポイントでの認証および認可の決定ゲートウェイまたは推論サーバー認可された呼び出し元と開放されたエンドポイントを区別するモデルアップロードまたはジョブ送信パスへの未認証アクセストークン、 コスト、およびレートに関する異常ゲートウェイ盗まれた認証情報を使用したリソースの悪用や計算リソースの盗用を検出無制限の消費や、目立たないコストベースの攻撃
キャプション：LLMアプリケーションが生成しうるものについて、引用された規格ではなく、スタック内のコンポーネントに基づいて体系的に整理した一覧。これは、権威ある公開リストが存在しないためである。 代替テキスト：8つのLLMアプリケーションのテレメトリイベントをまとめた表。各イベントの発信コンポーネント、各イベントのセキュリティ上の重要度、およびイベントが収集されなかった場合にセキュリティチームが失う情報を記載している。
入手可能な唯一の権威ある指針は、エージェント型AIのケースを扱っています。英国国立サイバーセキュリティセンター（NCSC）は、2026年8月20日にエージェント型AIのサイバーリスク管理について述べた文書の中で、「エージェント型AIの活動は、ユーザー活動の一形態として扱われるべきである。したがって、24時間365日のセキュリティ運用監視およびインシデント対応の対象に含めるべきである」と述べています。 この表現は重要である。このガイダンスは24時間365日のセキュリティ運用監視に関するものであり、そのどこにも「LLM」や「SOC」という言葉は使用されていない。また、エージェントの実行中に何を収集すべきかを具体的に指定しており、エージェントからの思考の連鎖（chain-of-thought）のトレースやトランスクリプトに加え、アクセスログ、プロキシ、ネットワークトラフィックなど、より広範なサンドボックス環境からのイベントログを挙げており、それらのログが改ざんや削除から保護されるよう指示している。
この最後の節が検知の鍵となります。ガードレールとログの改ざんは、以下に対応します。 T1685 ツールの無効化または変更これは、MITRE ATT&CK の「TA0112 防御機能の阻害」の下位に位置し、「防御能力の可視性を損なう、または低下させる」ことを目的として、「セキュリティツールやアプリケーションを無効化、機能低下、または改ざんする」攻撃者を対象としています。このページで言及されている ATT&CK テクニックは、これだけです。
検知は、この分野の半分を占めるものと認識されていますが、実際にこの分野に取り組んでいる実務家はほとんどいません。2025年のLLMセキュリティに関する学術調査では、防御策を「予防型と検知型の2つの主要なカテゴリー」に分類しており、これは成熟したセキュリティプログラムがすでに採用しているのと同じ軸です。
このセクションでは、アプリケーションが発信する情報について意図的に解説を留めています。生成AIに関するSIEMとの連携、検知ルールの開発、およびSOCのワークフローについては「生成AIのセキュリティ」で、このシグナルへの分析の適用については「AIによる脅威検知」で取り上げています。アプリケーションが回答するのではなく、自ら動作を行う場合については、「エージェント型AIのセキュリティ」を参照してください。
これらのツールは機能に基づいて定義してください。ベンダーのカテゴリ名もオープンソースプロジェクトの所有権も、機能そのものよりも変化のスピードが速いからです。
カテゴリ 検査対象 配置場所 できないこと ガードレール プロンプトおよび応答テキスト アプリケーション内部、モデル境界上 下位のインフラストラクチャを把握できず、ブロックした内容のみを報告する LLMファイアウォール プロンプトおよび応答テキスト ネットワークリクエストパス内に組み込まれ、アプリケーションの前に配置 ガードレールと同様の死角があり、プロセス内の呼び出しに関する可視性は追加されない AIゲートウェイ リクエスト、ルーティング、 クォータ、認証情報アプリケーションと1つ以上のモデルプロバイダーの間モデルのアーティファクトを検査せず、モデルの挙動をテストしないモデルスキャナーシリアル化されたモデルアーティファクト（読み込み前）ビルドパイプラインまたはモデルハブで測定された回避率があり、実行時には何も検知しないレッドチーム・ハーネス敵対的入力下でのモデルおよびアプリケーションの挙動オフラインまたは本番前の環境制御ではなく所見を生成し、そのスコアはハーネス固有である
キャプション：LLMセキュリティツールの5つの機能カテゴリ。ベンダーのカテゴリ名ではなく、各ツールが検査対象とする内容とリクエストパスにおける位置に基づいて定義されている。 代替テキスト：ガードレール、LLMファイアウォール、AIゲートウェイ、モデルスキャナー、レッドチーム・ハーネスについて、それぞれが検査する対象、リクエストパスにおける位置、および主な制限事項に基づいて比較した表。
よく聞かれる質問に直接お答えすると、LLMガードとは「ガードレール」のようなものです。つまり、アプリケーションの境界でプロンプトや応答を検査し、それらをブロック、編集、または書き換える制御機能です。これは検知ではなく予防であり、基盤となるインフラではなく、境界を通過するテキストに対して動作します。
「LLMファイアウォール」という用語は定義しておく価値はあるが、あえて追及する価値はない。これは、ネットワーク上に配置されるガードレールを指すベンダー独自のカテゴリー名であり、アプリケーションプロセス内部ではなく、リクエストパス上にインラインで配置するという、明確な配置の選択肢を表している。
カテゴリの選択は、順位付けの問題ではなく、対象範囲の問題です。そのツールが実際にどのレイヤーをカバーしているか、リクエストパス上のどこに位置するか、障害が発生した際にどう動作するか、テレメトリを送信するのかそれとも判定結果のみを送信するのか、そしてそのレイヤーにおける唯一の制御手段であるかどうかを問う必要があります。ガードレールとモデルスキャナーは、カバーするレイヤーが異なるため、競合関係にはありません。AIレッドチームングツールは、どちらかを置き換えるものではなく、両方をテストするものです。また、その表の内容は、 prompt injection ことを完全に妨げるものはありません。
攻撃成功率（ASR）とは、あるハーネスがターゲットモデルに対して行った試行のうち、成功と判定された試行の割合のことです。これは、そのハーネス内部においては意味がありますが、それ以外の場面ではほとんど意味を持ちません。
この数値に影響を与える3つの変数は、プロンプトセット、評価プロトコル、そして「成功」の定義であり、これらは互いに独立して変動します。いずれか1つを変更するだけで数値は変化するため、たとえ同じ攻撃クラスを記述している場合でも、公表された2つの攻撃成功率を比較することはほとんど不可能です。StrongREJECTのベンチマーク論文は、この方向性を明示的に指摘しており、「脱獄開発者が自身の脱獄手法の有効性を大幅に誇張することは、むしろ一般的である」こと、また「既存の評価手法は、人間の判断と比較して脱獄の有効性を著しく過大評価している」と述べている。この方向性に留意するとともに、同論文が過大評価の程度について具体的なパーセンテージを提示していない点にも注意が必要である。パーセンテージを引用している人は、論文とは別の内容を引用していることになる。
ですから、どのベンダーの数字に対しても、次の4つの質問を投げかけてみてください。「どのハーネスを使ったのか」「どの審査員が評価したのか」「どのプロンプトセットを使ったのか」、そして「何が成功とみなされたのか」。これら4つの答えが得られない場合、その数値は測定結果というよりは、単なるマーケティング上の演出に過ぎません。
このページに掲載されているフレームワークのほとんどは、過去13か月間に更新されているため、名前よりもバージョンや日付の方が重要です。
2025 IDとタイトル2026 IDとタイトルMovementNoteLLM01:2025 プロンプト注入LLM01:2026 プロンプト注入変更なし両エディションを通じて首位を維持LLM02:2025 機密情報の漏洩LLM02:2026 機密情報の漏洩変更なし両エディションを通じて2位を維持LLM03:2025 サプライチェーンLLM04:2026 サプライチェーン1ランクダウン上記のモデル・アーティファクトセクションを網羅LLM04:2025 データおよびモデルのポイズニングLLM05:2026 データおよびモデルのポイズニング1ランクダウン番号が変更されたため、 そのため、2025年の識別子は現在誤解を招くLLM05:2025 不適切な出力処理LLM10:2026 不適切な出力処理5位下落リスト内で最大の単独変動LLM06:2025 過度なエージェンシーLLM03:2026 過剰なエージェンシー 3つ上昇 エージェンシー型展開への移行を追跡LLM07:2025 システムプロンプトの漏洩 LLM08:2026 隠れたコンテキストの露出 1つ下降、名称変更および範囲拡大 範囲がシステムプロンプトのみから、取得されたポリシーテキストやアプリケーションがモデルに公開するツールのスキーマを含むすべての隠れたコンテキストへと拡大された LLM08:2025 ベクトルおよび埋め込みの脆弱性LLM09:2026 ベクトルおよび埋め込みの脆弱性1ランクダウン検索およびベクトルストア層LLM09:2025 誤情報LLM07:2026 誤情報2ランクアップLLM10:2025 無制限の消費LLM06:2026 無制限の消費4ランクアップ
キャプション：LLMアプリケーションに関する2025年版と2026年版のOWASP Top 10の対応表。2026年の列は公式リポジトリから、2025年の列は旧リストページから、名称変更情報はHelp Net Securityの記事から引用したもので、いずれも2026年8月25日に確認したものです。 代替テキスト：2025年のOWASP LLM Top 10の各識別子を2026年の識別子にマッピングした対応表。2つの項目は変更がなく、他の8つは移動しており、そのうちの1つは名称が変更され、対象範囲も拡大されている。
2つの項目は順位を維持し、残りの8項目はすべて順位が変動しました。その8項目のうち1つは名称が変更され、対象範囲も拡大されました。Help Net Securityのリリースに関する記事には、「『System Prompt Leakage』は『Hidden Context Exposure』に名称変更され、対象範囲が拡大された」と記載されています。削除された項目はなく、完全に新しい項目もありません。これは、2025年の管理措置を2026年のリストに照合する際に重要な点です。2026年版は2026年8月4日に公開され、コミュニティの判断とインシデントデータが組み合わされています。同記事では、「投票が依然として75％の比重を占めていますが、残りの25％は、公開されている脆弱性データベースおよびAI被害データベースから抽出された6,639件の実在するインシデントのデータによって影響を受けています」と記録されています。ここではリストを再掲しません。 リスクごとの説明はGenAIセキュリティに属しており、2026年版リストはOWASPのリソースページから集計データとして入手可能です。バージョンの変動は仮定ではなく現実のものとなっています。公開から21日後でも、旧リストページには依然として2025年の識別子しか掲載されていなかったため、対照表では各列についてそれぞれの出典を明記しています。
フレームワークバージョン 時点 本ページでの対応項目 LLMアプリケーション向けOWASP Top 10 2026年版（2026年8月4日公開） 2026年8月25日 上記で対応表が示されているリスク分類体系 MITRE ATT&CK Enterprise v19.2、 15の戦術2026年8月25日テレメトリセクションにおける単一の手法の対応関係MITRE ATLAS 2026.07： 1つのマトリックス、16の戦術、101の手法、77のサブ手法、37の緩和策、68のケーススタディ 2026年8月25日 AI特有の攻撃者の行動、および以下の名称の重複 NIST AIリスク管理フレームワーク 1.0、2023年1月26日公開、改訂中 2026年8月25日 「Govern, Map、Measure、Manageの各領域にわたるプログラム・ガバナンスNIST AI 100-2 E2025（2025年3月最終版）2026年8月25日敵対的機械学習の分類法および用語EU AI法規則（EU）2024/1689、2026年7月27日統合版、規則（EU）2026/1744により改正2026-08-25透明性および高リスク義務、ならびにその適用日ISO/IEC 420012023年基本テキスト、EN ISO/IEC 42001:2026 欧州採用2026-08-25AIマネジメントシステム認証、日付（二次情報源のみ）
キャプション：このページのバージョン固定フレームワークのマッピング。2026年8月25日時点で検証済み。MITRE ATLASでは毎月カレンダー形式でバージョン管理が行われているため、要素数に依拠する前にリリースを再確認してください。 代替テキスト：7つのフレームワークを特定のバージョンと検証日に固定した表。各フレームワークが本記事内のどの項目に対応しているかについての注記も記載されています。
マッピングに関する落とし穴の一つを知っておく価値があります。 MITRE ATT&CK エンタープライズ v19.2には正確に15の戦術が含まれており、「防御回避」という名称の戦術は1つもない。TA0005は「ステルス」、TA0112は「防御低下」となった。 MITRE ATLAS リリース 2026.07 今でも「」という名前の戦術が用いられている AML.0007 「Defense Evasion」について、そのATLASレコードの攻撃参照フィールドはTA0005を指しています。これら2つのフレームワークは、同じマッピングされた概念の名称について不一致があるにもかかわらず、形式的には相互参照関係にあるため、「Defense Evasion」に関する記述を行う際には、それがどのフレームワークに属するかを明記する必要があります。
規制に関しては、EU AI法の第50条に定める透明性義務は2026年8月2日から適用され、延期はされなかった。規則（EU）2026/1744により、高リスクに関する義務の適用時期が変更された。すなわち、附属書IIIに規定される高リスクシステムについては2027年12月2日から、附属書Iについては2028年8月2日から適用される。統合テキストによれば、すでに市場に出回っている合成コンテンツを生成するシステムの提供者は、2026年12月2日までに第50条(2)を遵守しなければならず、第102条から第110条は2026年7月27日から適用される。これらは本ページの中で最も変更の可能性がある日付であるため、EUR-Lexと照らし合わせて再確認するとともに、追跡に利用しているAIガバナンスツールでも確認することを推奨する。
プログラムレベルの取り組みにおいて、さらに2つの指針が重要となります。1つは、2023年1月26日に公開され、現在は「ホワイトハウスのAI行動計画の一環として改訂中」であるNIST AIリスク管理フレームワーク、もう1つは、2025年3月に最終版が策定された、敵対的機械学習攻撃とその緩和策に関する分類体系「NIST AI 100-2 E2025」です。 ISO/IEC 42001はAIに関するマネジメントシステム規格であり、EN ISO/IEC 42001:2026は、同じ基本文書を基にした現在の欧州版規格であり、撤回された2025年の国内版規格に取って代わるものである。規格策定機関のページは一般に公開されていないため、その発行日はここでは二次情報源に基づいている。
予算はこの分野へとシフトしつつある。 Enterprise Technology Researchが発表した「2026年セキュリティ動向レポート」は、セキュリティ分野に注力する517人のテクノロジーリーダーを対象としており、調査実施期間は明記されていないが、同レポートによると、「組織の半数以上（59％）がこの分野への支出を増やす計画である」一方で、「組織の5分の1（20％）はエージェント専用のセキュリティ対策を導入していないと回答しており、本番環境全体に広く導入しているのはわずか3％に留まっている」ことが明らかになった。
OWASPプロジェクトのリーダーたちが2026年版に向けて提唱した設計方針は、「完全な防止」ではなく「影響範囲の制御」である。Help Net Securityによる本リリースの報道によると、彼らは冒頭で次のように述べている。「騙されないモデルを構築しようとする試みはやめよう」。実際には、これは3つの機能に集約される。AI環境全体にわたるポスチャー管理（AIセキュリティ・ポスチャー管理に含まれる）、サービング層における実行時検知、そしてモデルアーティファクトの来歴追跡である。 より広範なプログラムについては、NCSCの『セキュアなAIシステム開発のためのガイドライン』に、セキュアな設計、セキュアな開発、セキュアな導入、およびセキュアな運用・保守という観点から規定されている。一方、この先見的な取り組みはより限定的なものであり、現在セキュリティ責任者がいないオーケストレーションコンポーネントに対しても、資産管理とパッチ適用という同じ規律を適用することである。
Vectra AIは、現代のネットワークが単一の攻撃対象領域であり、LLMサービングスタックも今やその一部であるという立場から出発しています。 ここには、ID管理、クラウド、オンプレミスインフラと同様に、「侵害を前提とする」という姿勢がそのまま適用されます。プロンプトの境界での防御は必要ですが、それだけでは不十分です。運用上重要なのは、AIインフラセグメント全体の可観測性、実際の攻撃者の行動とモデルのノイズを区別するシグナル、そしてそのシグナルに基づいて行動する能力です。これこそが『Attack Signal Intelligence 』の背後にある方法論であり、多くの組織がまだ棚卸しを行っていないセグメントに適用されるものであり、AIセキュリティプログラムの次なる方向性でもあります。
LLMのセキュリティは、スタックを扱う分野です。自社が管理するレイヤーを把握し、CVE識別子やKEVの期限が設定されているコンポーネントにパッチを適用し、アプリケーションが出力する情報を監視し、すべてのベンダー番号を、それを生成したハーネスまで遡って確認してください。モデルについては誰もが論じていますが、その下にあるスタックこそが、実際に修正できる部分なのです。
これらのカテゴリは、同じスタックの異なるレイヤーをカバーしているため、唯一の最適な解決策というものは存在しません。ガードレールはプロンプトと応答の境界をカバーし、モデルスキャナーはアーティファクトをカバーし、AIゲートウェイはルーティングとポリシーをカバーし、レッドチーム・ハーネスはこれらすべてをテストします。製品の候補リストからではなく、レイヤーの棚卸しから始めましょう。
単純なリストではなく、階層的な視点で考える必要があります。具体的には、モデル、プロンプトと取得されたコンテキスト、検索ストア、ツール呼び出し、推論サーバー、オーケストレーション層、モデルアーティファクト、出力処理などです。現在の権威ある分類体系は、LLMアプリケーション向けの「OWASP Top 10」であり、その2026年版は2026年8月4日に公開され、集約リソースページから入手可能です。 公表されているリスクリストの多くは、上位4つのレイヤーについては十分に網羅しているものの、インフラストラクチャ層についてはほとんど触れていません。
prompt injection 攻撃は、モデルが入力として扱うテキスト（そのテキストがユーザー、検索された文書、またはツールからの応答のいずれからのものであっても）に敵対的な指示を埋め込むことで、モデルの挙動を操作するものです。これは2026年のOWASPリストで1位にランクインしています。 prompt injection を参照してください。
いいえ。レッドハットの技術分析では、次のように明確に述べられています。「Prompt injection の問題はLLMの本質に起因するものであり、完全に修正することはできません。パッチを当てることができないため、通常のセキュリティ脆弱性として扱うことはできません。」一般的な見解としては、入力を防止するのではなく、その影響を最小限に抑えることが重要であり、これについては prompt injectionで解説されています。
3つの手順を順に説明します。まず、すでに運用しているサービング層およびオーケストレーション層の棚卸しを行い、CVE識別子やKEVの期限が設定されているコンポーネントにパッチを適用し、LLMアプリケーションが出力する内容を監視・記録します。より広範な取り組みについては、NCSCの「安全なAIシステム開発のためのガイドライン」が、安全な設計から安全な運用・保守に至るまでの全ライフサイクルを網羅しています。
