AIモデルのリスクは、モデルがアクセスできる範囲で決まる

数千のエンタープライズ環境をスキャンしたSnykの最新調査から、高いモデルリスクスコアはトリアージの始まりを示すものであり、セキュリティチームがどう対応すべきかが明らかになりました。

同じAIモデルを参照する2つのアプリケーションを想像してください。一方は会議の議事録を要約し、もう一方はエージェントを使って顧客記録を照会し、業務ワークフローを実行します。どちらのアプリケーションでも、モデルの敵対的テストスコアは同じかもしれません。しかし、障害が起きた場合の影響は大きく異なる可能性があり、重要となる障害の種類も異なります。会議要約ツールでは、モデルが誤解を招く出力を生成するよう誘導されるかどうかを把握する必要があります。顧客記録を扱うエージェントでは、データ漏えいや不正な操作を引き起こされる可能性がないかを確認する必要があります。だからこそ、あらゆる攻撃を平均した単一のスコアよりも、攻撃の種類ごとのモデルスコアのほうが役立ちます。

この違いは、Snykの2026 State of Agentic AI Adoption, Volume IIIの中心的なテーマです。第1巻と第2巻では、エンタープライズAIは単なるモデルの集合ではなく、相互につながったソフトウェア環境であることを示しました。今回の分析では、特定可能なモデルのリスクスコアを加え、セキュリティリーダーが本当に知る必要のある問いを掘り下げます。どの検出結果に対応が必要で、どのような対策がリスクを低減するのでしょうか。

AIモデルのインベントリの約半数に、クリティカルスコアのモデル参照が含まれる

スコアの仕組み：Snykは、個人データの抽出やコマンドの実行など、29の攻撃者の目標に対して各モデルをテストし、それぞれを0～1,000でスコア化します。スコアは、攻撃の成功頻度と、その目標がもたらし得る損害の大きさを組み合わせたものです。500以上は高、750以上はクリティカルです。モデルは基本的なガードレールを適用した状態でテストされるため、スコアが示すのは防御されていないモデルではなく、防御されたモデルのリスクです。

モデル識別子が1つ以上検出された1,693の環境のうち、74.5%は少なくとも1つの攻撃者の目標で高スコア（500以上）を記録したモデルを参照し、49.2%はクリティカルスコア（750以上）のモデルを参照しています。このサンプルで確認されたクリティカルスコアの検出結果は、PIIの抽出とコマンドの実行に関するものでした。

この数字を受けて必要なのは、パニックではなく調査です。本調査では、コード内で見つかったモデル識別子を敵対的テストの結果と照合しています。すべてのモデルが本番環境で稼働していること、特定のツールやデータセットにアクセスできること、あるいは組織のアプリケーションで攻撃が成功したことを示すものではありません。

カバレッジの観点からも、正確な解釈が重要です。検出されたモデル参照のうち、リスクスコアが照合できたのは37.5%にすぎません。モデルを含む環境の約17%には、スコアが付いたモデルが1つもありません。スコアのない参照やバージョン不明の参照は、引き続き確認が必要な未知の要素として扱ってください。

インベントリの規模によって検出件数は変わりますが、内訳は変わりません。高スコアのモデルが1つ以上見つかる確率は、モデル数が最少の環境では34.6%、最多の環境では100%に上昇します。一方、高スコアのモデルに関連するモデル参照の割合は、どの規模でも21～25%、8つの業界全体でも18.9～25.5%にとどまります。件数は確認作業のバックログの規模を把握するために、割合は同業他社とモデルの選択を比較するために活用してください。どちらの数字も、稼働中のアプリケーションでモデルに何が許されているかを示すものではありません。

高スコアのモデルについて、まず確認すべきことは、稼働中か、何にアクセスできるか、障害が起きた場合に何が起こるかです。

エージェントとMCPサーバーを考慮すると、デプロイ環境を無視できない

モデル単体でも安全でない回答を生成する可能性があります。ツール、データ、ワークフローに接続されると、その回答に基づいて動作することもあります。これが、テストで判明するモデルのリスクと、モデルを取り巻くシステムが及ぼす影響範囲の違いです。

MCPへの参照があった米国の1,051アカウントのうち、744（70.8%）では、SDKを使用してMCPサーバーを構築している証拠が確認されました。残りはクライアント接続または設定の参照のみでした。サーバーの構築、設定、運用はそれぞれ異なるシグナルであり、最後の運用を確認できるのはランタイム検証だけです。

エージェントまたはMCPのシグナルが検出されなかった環境のうち、49.1%が高スコアのモデルを参照していました。一方、エージェントの指標とMCPサーバー構築コードの両方が確認された環境では、その割合は96.6%でした。

後者のグループでは、モデルのインベントリの中央値もはるかに大きく、104モデルに対し、前者は4モデルでした。モデル数が5～19の環境を比較すると、その差は47ポイントから26ポイント（62.1%対87.8%）に縮まります。このパターンは相関関係を示しています。エージェントとMCPサーバーが変えるのは、モデルのスコアが及ぶ範囲です。だからこそ、まず確認すべき対象となります。

セキュリティチームが次にすべきことは検証です。どのエージェントとMCPサーバーが稼働中か、どのツールを公開しているか、どのデータを取得できるか、そしてモデルの出力が重大な操作につながるまでにどのような承認が必要かを確認してください。モデルスコアだけでは、これらの問いには答えられません。

AIの弱点すべてに同じ対策を当てはめない

モデルが何にアクセスできるかを把握したら、次は障害に適した対策を考えます。有効なモデルリスク管理プログラムは、重大度の区分を確認するだけでは終わりません。アプリケーションにとってどの攻撃者の目標が重要か、その目標に対して別のモデルが実質的に優れているかを見極めます。対策は大きく2つに分かれます。

• モデルの切り替えが有効なケース。コマンド実行では、テスト対象モデルの77%がスコア0でしたが、最悪のモデルは834に達しました。コードへのバックドア埋め込みでは、57%がスコア0でしたが、最悪のモデルは695でした。

• アプリケーション側の制御が必要なケース。誤情報では、モデルのスコアの中央値が最高値に達しました。人種差別的なバイアスでは、テスト対象のモデルにスコア0のものはありませんでした。

スコア0は、そのテストでは攻撃が一度も成功しなかったことを意味します。また、ある目標で優れたモデルが別の目標では劣る可能性もあるため、置き換えるモデルがワークロードに関わるすべての目標で適切かどうかを検証してください。結果に大きな差がない場合は、アプリケーション側で防御します。アクセスを制限し、出力を検証し、承認を必須にし、利用状況を監視し、生成されたコードと依存関係をビルドに取り込む前にスキャンしてください。

アラートのしきい値だけでは、全体像を把握できません。攻撃者の目標29項目のうち18項目は、デフォルトのアラートしきい値である500に達することがありません。各目標がもたらし得る損害によって、最高スコアが500未満に制限されるためです。アラートキューが静かなときでも、こうした障害は重要です。

モデル間に差がある場合は、代替モデルをテストしましょう。差がない場合は、アプリケーションのアクセス権と権限を制限しましょう。

モデルの切り替えで実際に対処できる目標はどれか、アラートが決して上がらない目標はどれか。全29項目をグラフで確認できます。 レポート全文をダウンロード。

承認済みモデルのリストを見直す必要があるかもしれません

知名度、ライセンス、価格は、個々のモデルを詳しく評価する代わりにはなりません。

能力が低いモデルから優先的に見直す

スコアが付いたモデルでは、能力が低いモデルほど、個人データの漏えい、意思決定の上書き、安全でないコードの生成において成績が悪くなりました。意思決定の上書きでは、Epoch Capabilities Index（ECI）が130未満のモデルの平均スコアは501でしたが、ECIが150以上のモデルでは45でした。能力が最も低いモデルは、スコア比較対象のモデル参照の約3分の1を占めます。つまり、この結果は例外的なケースにとどまりません。

能力はセキュリティとは別の指標であり、能力の高いモデルでも、実行するタスクに対するテストが必要です。承認済みの低能力モデルやバージョンを見直し、現在利用中のプロバイダーの代替モデルをテストしてください。この傾向は、個々のプロバイダーのモデル群の中にも見られます。

プロバイダーは最初の判断材料として有用ですが、最先端モデルでは参考になる度合いが下がります。中程度の能力を持つモデルでは、プロバイダーごとの平均スコアは113～356でした。一方、最も能力の高いモデルでは、主要3プロバイダーのスコア差は22ポイント以内でした。承認済みモデルのリストが特定のプロバイダーに偏っている場合は、レポート全文でそのプロバイダーのモデルが優れている点と劣っている点を確認できます。データの持ち出しから出力の操作まで、7種類の攻撃について6つのプロバイダーを横並びで比較しています。このサンプルでは、高価格帯のモデルに一貫したセキュリティ上の優位性は見られませんでした。主な理由は、高価格帯のモデルの大半が古く、能力の低いモデルだったことです。

オープンウェイトモデルとトレーニングデータの来歴

レポートでは、スコアが付いた16のオープンウェイトモデルは、プロプライエタリモデルよりも個人データの漏えいスコアが高いことも明らかになりました。平均スコアは562対274です。サンプル数が少ないため、個人データを扱うワークロードでは、調査に値する兆候として捉えてください。

来歴の可視性にも同じ違いが見られます。モデルを含む1,693の環境のうち904では、トレーニングデータの来歴がスキャンで確認できませんでした。主な理由は、プロプライエタリモデルのプロバイダーがトレーニングデータセットを公開していないことです。そのため、確認すべき証拠はモデルの種類によって異なります。プロプライエタリモデルのベンダーには文書化された保証を求め、オープンウェイトモデルが公開するデータセットの来歴を確認してください。

セキュリティリーダーが取るべき4つのアクション

1. 未知の要素をインベントリ化し、評価する：モデル識別子、バージョン、オーナー、稼働中の用途、エージェント、ツール、MCPサーバー、確認可能な来歴を追跡します。照合できないモデルも可視化し、低リスクとして暗黙に扱わないでください。

2. アクセス範囲を検証する：稼働中のモデルから機密データ、認証情報、ツール、後続の操作に至るランタイム経路を確認します。サーバー構築コードと設定、実際の接続を区別してください。

3. 目標に応じた修正を行う：ビジネスへの影響に基づいて障害の優先順位を付けます。敵対的テストの結果に差がある場合は、具体的な代替モデルをテストします。差がない場合は、最小権限、出力チェック、承認、コードスキャンを活用します。

4. 意思決定をガバナンスにつなげる：モデルとバージョン、テスト結果、オーナー、承認済みの制御策、その根拠、見直し日を記録します。モデル、権限、ファインチューニングデータ、アプリケーションが変わったときは、改めて評価してください。

Volume IIIの要点：モデルのスコアはそのリスクを示し、周囲のシステムが影響範囲を決めます。両方に対処し、モデル間に差があれば切り替え、差がなければ制御を強化しましょう

方法：2026年9月から、Snykを利用する組織のAI部品表（AI-BOM）スキャンデータを匿名化・集計。対象は3,023の環境で、そのうち1,693にはモデル識別子が1つ以上含まれていました。モデルレベルの検出結果は米国アカウントを対象としています。

セキュリティリーダーは、自社のビジネスに影響し得る障害と、その結果を変える制御策を把握する必要があります。自社の環境にはどのようなエージェントとMCPのパターンがあり、プロバイダーは7種類の攻撃に対してどのような成績を示すのでしょうか。レポート全文では、これらに加えて、業界別・価格帯別の結果や、ガバナンスリーダーが答えられるようにしておくべき6つの質問を詳しく解説しています。 「2026 State of Agentic AI Adoption, Volume III」をダウンロード

自社のAI環境を評価しませんか？ Evo AI-SPMを見る。