AIモデルリスクインテリジェンス：導入前に信頼できるモデルを見極める

EvoでAIモデルのリスクを可視化する方法を検討し始めたとき、最初に思い浮かんだのは、ほかのあらゆるものを評価する方法を応用することでした。問題を見つけ、深刻度を割り当て、可視化する。これで完了です。

新しいアプローチの中核は、セキュリティチームがすでにリスクを考える際に使っている方法、つまり「可能性 × 影響度」で算出する、実際のリスクスコアです。可能性は攻撃成功率（ASR）に基づきます。これは、実際の敵対的攻撃のうち、モデルに対して成功した割合です。影響度は、攻撃者の目的が達成されたときに生じる損害の大きさです。この2つを組み合わせ、0～1000の単一スコアにします（数値が低いほど良好です）。

2つの要素を掛け合わせるため、どちらか一方だけが結果を左右することはありません。発生頻度は低くても壊滅的な攻撃は、可能性が低いためスコアが抑えられます。頻繁に起きても無害な攻撃も、影響度が低いため同様です。上位に来るのは、最も重要な攻撃、つまり成功率が高く、成功した場合に実害をもたらす攻撃です。

新しいリスクスコアの算出方法

チェックリストやベンダーの安全性カードと異なるのは、ASRが実際の敵対的テストから導き出される点です。テストには、情報抽出プロンプト、複数ターンにわたるエスカレーション、ペルソナベースのジェイルブレイク、攻撃ツリー戦略などが含まれ、モデルベースの判定器が各攻撃の成否を確認します。

これらは理論上の攻撃ではありません。また、「むき出し」のモデルの数値でもありません。ベンチマーク内のすべての攻撃は、システムプロンプトを強化する基本的な防御策を適用した状態で実行されます。つまり、リスクスコアが示すのは、すでに標準的なガードレールを設けたうえで、それでも突破される攻撃です。ラボで成功するだけでなく、本番環境で通用する攻撃がわかります。

このスコアを実際の対策に結び付けられるのは、攻撃の成否だけでなく、攻撃が成功したときに何が起きるかを基準にしているからです。しかも、スコアを示すだけではありません。Evoは、各スコアを、その背景にある具体的な攻撃者の目的まで掘り下げます。PIIの抽出、インジェクションによるシステムプロンプトの抽出、安全でないコードの生成などです。これにより、各モデルの弱点を正確に把握し、適切なガードレールを構築できます。このレベルの詳細さが、導入を決定する前に必要な判断材料になります。

この情報は、セキュリティチームにとってすぐに役立ちます。モデルに対して失敗する具体的な攻撃者の目的ごとにリスクを確認でき、「安全／危険」という抽象的な判定だけに頼る必要がありません。モデルが一般的に安全かどうかではなく、これから構築しようとしているものに対して安全かどうかを検討できます。

問題を見つけ、深刻度を割り当てて次に進むという最初の発想には、重大な問題がありました。それは、お客様から直接聞かされていたことです。

モデルに「情報漏えい」の問題があると示されたセキュリティチームは、いつも同じ質問をしました。それは実際には何を意味するのか、何をすればよいのか。ラベルからは問題があることはわかります。しかし、どれほど深刻なのか、どのようなコンテキストで起きるのか、どんな攻撃が関係するのか、何を構築すれば解決できるのかはわかりませんでした。

そこで、私たちは作り直しました。何を変えたのか、なぜ変えたのかをご紹介します。

お客様との会話の中で、このギャップは何度も明らかになりました。具体的な数値を示し始めると、チームの反応が変わりました。GPT-3.5の「危険なコンテンツ」スコアは397/1000、GPT-4の「バイアスと公平性」スコアは317/1000。チームはモデルが安全かどうかを尋ねるのをやめ、モデル同士を比較し始めました。

問題はスコアではなく、コンテキストにあります。

多くのAIリスク評価では、モデルを静的な成果物として扱います。テストをいくつか実行し、カテゴリラベルを割り当て、安全性カードを公開する。チームはそれを見て、導入するかどうかを判断しようとします。

しかし、AIのリスクはそのようには捉えられません。同じモデルでも、導入方法によってリスクは根本的に異なります。コーディングエージェントは、認証情報の窃取、バックドア、攻撃者が制御するコマンド、依存関係のポイズニングにさらされます。顧客向けチャットボットには、ジェイルブレイク、有害なコンテンツの生成、プロンプトの抽出といったリスクがあります。メール、カレンダー、ドキュメントにアクセスできるパーソナルアシスタントは、まったく異なる攻撃対象領域を抱えます。

導入コンテキストを反映しないリスクスコアは、リスクスコアではありません。単なる推測です。Evoは影響度の重み付けに導入コンテキストを組み込むため、何もない状態でのモデルの振る舞いではなく、実際の使われ方を反映したスコアを算出できます。

もう1つの問題は、間接攻撃です。多くのモデル評価では、直接的なプロンプトに焦点を当てます。ユーザーが悪意のある内容を入力し、モデルが抵抗できるかを確認する方法です。これは重要ですが、エージェント型システムを狙う、より危険な種類の攻撃を見落としています。間接的なプロンプトインジェクションでは、取得したドキュメント、ツールの実行結果、コードコメントなど、エージェントが読むデータに悪意のある指示を埋め込みます。ユーザーには見えません。エージェントはそれをコンテキストとして処理します。モデルがその指示に従うと、機密データを漏えいしたり、ツールを悪用したり、許可されていない操作を実行したりする可能性があります。モデル単体のテストでは、この攻撃を検知できません。

これは理論上の懸念ではありません。ある大企業では、LLMモデルのリスクが直接の原因となった緊急インシデントについて、当社に相談がありました。また、あるグローバル銀行では、類似の問題がCEOにまでエスカレーションされました。ある国内金融機関は、MCPの利用状況を可視化し、ガードレールを適用したいと考えていました。これらのチームが尋ねていたのは、抽象的なモデルの安全性ではなく、特定のエージェント型コンテキストにおける振る舞いでした。

私たちがRisk Intelligenceで答えたいと考えたのは、別の問いでした。「実際に予定している導入方法で、このモデルは攻撃を受けたときにどう振る舞うのか？」

構築したもの：攻撃者の目的まで掘り下げる、影響度ベースのリスク

1. コードベース全体で、どのモデルやAIスキルが使われているか？ セキュリティチームは、AIがどこで使われているか、どのモデルが呼び出されているか、システムの一部としてどのスキルやツールが使われているかを把握する必要があります。

2. 各モデルは攻撃を受けたときにどう振る舞うか？ チームに必要なのは、静的な主張や一般的な安全性ドキュメントではなく、敵対的テストに基づくリスクプロファイルです。

3. 検出結果をどのように活用できるか？ スコアが役立つのは、チームがモデルを比較し、ガードレールの優先順位を決め、アプリケーションやリポジトリ全体にポリシーを適用できる場合に限られます。

主な出力は、攻撃者が達成できることの実際の影響度を重み付けした、0～1000の単一リスクスコアです。その算出の根拠となる指標が、攻撃成功率です。

スコアからはモデルがどの程度攻撃にさらされているかがわかります。分類体系からは、そのスコアにつながった攻撃と、導入においてそれが重要な理由がわかります。

Evoは、実際に何が起きるかという影響度を基準に、3階層の分類体系で検出結果を整理します。最上位の影響カテゴリ（たとえば情報漏えい）は、サブカテゴリへと分かれ、さらに最も詳細な階層である具体的な攻撃者の目的（たとえばPIIの抽出）へと掘り下げられます。直接攻撃と間接攻撃は、必要な防御策が異なるため、分類体系全体で別々の攻撃対象領域として追跡されます。コードコメントを介した間接インジェクションのASRが高いコーディングエージェントには、ジェイルブレイクのASRが高いチャットボットとは異なるガードレールが必要です。この分類体系により、その違いが明確になります。

さらに、攻撃者の目的はすべて、チームがすでに報告に使っているフレームワークに対応付けられます。OWASP LLM Top 10、OWASP Agentic、MITRE ATLAS、NISTです。つまり、検出結果は翻訳が必要なSnyk独自のラベルではなく、すでに準拠している標準にそのまま当てはめられます。この対応関係は、スコアとあわせてリスクプロファイルタブで確認できます。

この詳細さがあるからこそ、チームはスコアの確認から修復計画の策定へと進めます。また、別のワークフローを設けることなく、リスク検出結果をポリシー適用へと直接つなげられます。

モデルだけでなくスキルのカバレッジも把握

大まかなリスクラベルだけでは不十分です。モデルに「情報漏えい」や「危険なコンテンツ」の問題があると伝えれば、注意を促すことはできるかもしれません。しかし、何を修正すればよいのかはわかりません。役立つリスクインテリジェンスでは、検出結果を具体的な攻撃者の目的まで掘り下げます。たとえば、インジェクションによるシステムプロンプトの抽出、許可されていないツールの実行、有害なコンテンツの生成、安全でないコードの生成、機密データの持ち出しなどです。

ここまで詳しい情報があれば、チームはどのようなガードレールを構築するか、どのポリシーを適用するか、特定のユースケースにモデルが適しているかを判断できます。また、リーダーはさまざまなレベルでリスクを把握できます。上位カテゴリからは、組織がどこでリスクにさらされているかがわかります。より詳細な攻撃対象領域からは、攻撃が直接的か間接的かを確認できます。具体的な攻撃者の目的からは、何が失敗したのかをエンジニアリングチームが正確に把握できます。

リスクはモデルだけに存在するのではありません。モデル、そのモデルが呼び出せるツール、そして使用するスキルの組み合わせにも存在します。単体では良好なスコアのモデルでも、ファイルシステムツール、コード実行環境、機密データストアと組み合わせると、振る舞いが大きく変わる可能性があります。

Evoはモデルのリスクとあわせてスキルのカバレッジをマッピングし、どのスキルが使われているか、どのモデルに結び付いているか、組み合わせた場合の攻撃対象領域がどのようになるかを明確に示します。これは、セキュリティチームが確信を持って導入を判断するために必要なインベントリビューです。

この点は、特にコーディングエージェントで重要です。同じモデルが、あるときはプルリクエストをレビューし、次の瞬間にはデプロイコマンドを実行することもあります。モデルが何をしているか、実行時にどのツールへアクセスできるかによって、リスクプロファイルは大きく変わります。

証拠からポリシー適用へ

Evoは、モデルを本番環境で信頼する前に、攻撃を受けたときの振る舞いをチームが把握できるよう設計されています。Evoがコードベースをスキャンすると、使用中のAIモデルとスキルを特定し、敵対的テストに基づくリスクプロファイルを付与します。これらのプロファイルは、実際の敵対的攻撃に対して測定した攻撃成功率を影響度で重み付けして算出します。そのため、攻撃の件数だけでなく、結果として生じる影響をスコアに反映できます。

Risk Intelligenceでは、広いカテゴリから具体的な攻撃者の目的まで、詳細な分類体系に沿って検出結果を整理します。 それぞれの項目は、OWASP LLM Top 10、OWASP Agentic、MITRE ATLAS、NISTに対応付けられています。これによりチームは、概要スコアから、成功した具体的な攻撃パターンを特定し、すでに報告に使っているフレームワークと照合できます。Risk IntelligenceはEvoのポリシーエンジンと連携しているため、得られた知見をポリシー適用につなげられます。モデルを採用する前に比較し、特定の導入コンテキストで最もリスクの高いモデルを確認し、すぐに使えるポリシーから始めて、自社のリスク許容度に合わせてしきい値をカスタマイズできます。

リスクスコアとポリシー適用の間にあるギャップこそ、多くのAIセキュリティプログラムが停滞する原因です。チームは検出結果を受け取っても、それをどう活用すればよいかわかりません。

EvoはRisk Intelligenceをポリシーエンジンに直接連携させ、このギャップを埋めます。特定の攻撃者の目的や攻撃パターンに対するモデルのリスクスコアが高い場合、同じワークフロー内でしきい値を設定してポリシーを適用し、機密性の高いコンテキストで高リスクモデルが使われないようにできます。

Snykのお客様にとって、これはおなじみのアプローチを拡張するものです。開発者が作業する場所でリスクを検出し、重要なものを優先し、一貫してポリシーを適用する。その違いは、ポリシーの適用対象がコードだけでなく、AIモデルの選択やエージェントの設定にも広がったことです。

今、これが重要な理由

AIセキュリティを推測に頼ることはできません。モデルやエージェントが実際のアプリケーションに導入されるにつれ、チームは攻撃を受けたときにそれらのシステムがどう振る舞うかを把握する必要があります。

AIモデルリスクインテリジェンスにより、組織はモデルの振る舞いを測定し、ユースケースごとにリスクを比較し、修復の優先順位を決め、AIの導入を大規模に管理できます。もはや単に「このモデルは安全か？」と問うだけではありません。より重要なのは、「予定している導入方法で、このモデルは攻撃を受けたときにどう振る舞うのか」という問いです。

私たちが話を聞くチームの多くは、自ら明示的に選んだわけではないAIモデルを運用しています。ベンダーから引き継いだもの、開発者向けツールを通じて導入したもの、監査の途中で見つかったものなどです。Snykの「State of Agentic Adoption」レポート第2巻では、3,044の組織から匿名化されたAI-BOMテレメトリを収集しました。そこから見えてきた傾向は一貫しています。チームが把握しているモデル1つにつき、約2.8個のAIコンポーネント、ライブラリ、MCPサーバー、SDKが管理されないまま稼働しており、保有するAI資産の全容を把握できている組織はほとんどありません。あるチームが必要な作業を見積もったところ、AI資産の完全な棚卸しには4～5週間と10～12人の関係者が必要でした。リスクスコアリングの検討を始める前から、モデルの棚卸しは現実の課題となっています。

こうした機能への需要は急速に高まっています。AI-SPMの強化機能は、既存のお客様に現在ご利用いただけます。実際の敵対的テストに基づくAttack Success Rateを用いた、影響度ベースのリスクスコアは2026年8月末に提供予定です。詳細はぜひデモをご予約ください。