エンタープライズAIセキュリティの評価：すべての購入担当者が答えられるべき質問

エンタープライズAIセキュリティは急速に進化していますが、多くの組織は依然として、ベンダーの主張を厳密に評価することに苦慮しています。F5、AWS、Microsoftとの共同で作成されたNSS Labsの本調査レポートでは、セキュリティ責任者や企業の購買担当者が、確信と根拠を持ってAIセキュリティに関する意思決定を行うために必要な、ベンダーへの具体的な質問、注意すべき危険信号、評価基準を提示します。

エグゼクティブサマリー

エンタープライズAIセキュリティには、購入者側の課題があります。組織はAIセキュリティの重要性を認識しているものの、ベンダーの主張を評価し、実効性のある対策と表面的な対策を見分け、実環境で得られた証拠に基づいてベンダーに説明責任を求めるための信頼できる枠組みを備えていないケースがほとんどです。

NSS LabsがF5、AWS、Microsoftと共同で作成した全2部構成のシリーズの第2部となる本書では、問題の定義から一歩進み、購入者が具体的な行動を取るために必要な情報を提供します。第1部ではAIモデルだけを保護しても不十分である理由を明らかにしました。第2部では、その知見を7つの重要な機能領域にわたる実践的な評価基準へと落とし込みます。

要点は、AIセキュリティの購入判断は単なる技術上の判断ではなく、ガバナンス上の判断でもあるということです。購入者は、アーキテクチャ図ではなく、測定可能な根拠を求めるべきです。つまり、検知の有効性、運用パフォーマンス、監査要件、フレームワークとの整合性について、定量的なベースラインが必要です。これらはすべて、限定的なテストシナリオではなく、実環境の条件に照らして検証されていなければなりません。

本書では、入力に関する脅威と命令の制御、出力とデータ流出のリスク、性能低下時のシステムレジリエンス、ポリシーとフィルターのガバナンス、エージェント型AIと権限委譲、可観測性とフォレンジック、統合と相互運用性という7つの機能領域を検証します。各セクションでは、中核となるリスクに加え、購入担当者がベンダーに確認すべき具体的な質問、効果的なソリューションの特性、注意すべき明確な危険信号を取り上げます。

本書は最後に、2つの明確な要件を示しています。購入前に独立した検証を求めること、そして、その検証を一度限りの確認ではなく、継続的な取り組みとして実施することです。実効性のあるテストを拒むベンダーの姿勢は、強みではなく未成熟さの表れです。

要点は、結論にある次の3つの重要な文に集約されます。AIセキュリティの購入は、長期的な影響を伴うガバナンス上の意思決定です。初期段階で厳しい問いを投げかける企業ほど、リスクを管理し、回避可能な失敗を防ぎやすくなります。そして、AIセキュリティの成功に必要なのは、目新しさや抽象論ではなく、説明責任、透明性、規律ある評価です。

目次

はじめに：認知から評価へ

定量的な評価基準の策定

重要な機能領域と購入者が確認すべき質問

• 入力脅威、命令制御、回避の検知
• 出力およびデータ流出のリスク管理
• レジリエンス、堅牢性、障害、性能低下への対応
• ポリシー／フィルターの有効性とガバナンスとの整合性
• エージェント型AI、ツール呼び出しのセキュリティ、委任された権限
• オブザーバビリティ、監査、フォレンジック
• 統合と相互運用性

購入前に買い手が求めるべきこと

独立した検証に向けた準備

結論：主張から説明責任へ

パート1をダウンロード： モデルだけではないAIセキュリティ：企業が重視すべきことと、その理由

はじめに：認知から評価へ

AIがさまざまな形で企業システムに浸透するにつれ、新たな脅威領域が生まれ、企業はAIのセキュリティリスクを考慮せざるを得なくなっています。取締役会、規制当局、経営陣は、AIシステムが脅威領域を拡大させるだけでなく、運用面、法務面、レピュテーション面で新たな種類のリスクをもたらすことを認識し始めています。その結果、こうしたリスクの軽減を目的とするAIセキュリティ製品が、企業のセキュリティチームにとって重要な検討事項となっています。

しかし、認識が高まっても、必ずしも準備が整うわけではありません。AIセキュリティの重要性が企業に広く受け入れられつつある一方で、この新興分野のベンダーが掲げる主張を適切に評価することに、多くの企業が苦慮しています。用語には一貫性がなく、デモンストレーションの対象範囲は限定的な場合が多いうえ、保証の根拠も実環境での証拠ではなく、アーキテクチャに置かれがちです。そのため購入担当者は、実効性のある制御と表面的な制御を明確に見分ける方法も、実際のカバー範囲がどの程度有効なのかを判断する方法もないまま、意思決定を迫られています。

NSS Labsは、前回のホワイトペーパー『AI Security Beyond the Model』で、AIモデルだけを保護しても不十分である理由と、企業のAIセキュリティをシステムレベルおよびガバナンス上の課題として捉える必要がある理由を説明しました。真のセキュリティ課題は、データの取得、ツールの呼び出し、自動化された意思決定の実行が行われる、モデルを取り巻くシステムで生じます。

本書では、その基盤を踏まえ、問題の理解から潜在的なソリューションの評価へと進み、企業の購入担当者がAIセキュリティベンダーを候補として絞り込む際に、より適切な質問を検討できるよう支援します。『AI Security Beyond the Model』と同様に、本書では主にランタイムガードレール（ポリシーを適用し、データを保護し、監査証跡を生成する、モデル外部の制御）に焦点を当てます。同時に、モデルセキュリティ／責任あるAIはモデル固有のリスクを低減するものの、それだけでは企業におけるインタラクションリスクを管理できないことも認識しています。AIシステムが企業のワークフローに組み込まれるにつれ、セキュリティ上の意思決定は、ガバナンス、リスク管理、規制上の説明責任とますます密接に関わるようになります。組織には、AIシステムの仕組みだけでなく、リスクをどのように制御、監視、監査しているかについても説明できることが求められます。

以下のセクションでは、AIセキュリティの中核的な機能領域を評価基準として捉え直します。特定のテクノロジーやアーキテクチャを規定するのではなく、本番環境向けのAIセキュリティ制御を選定する際に、購入者が理解、検証し、その選定根拠を説明できるべき事項に焦点を当てます。

定量的な評価基準の策定

AIセキュリティを評価するには、定性的な主張にとどまらず、測定可能な検証を行う必要があります。購入者は、ベンダーを客観的に比較できるよう、基準となる要件を設定する必要があります。

検出の有効性：ベンダーは、広く認められた独立系試験機関の標準化されたテストフレームワークと手法に基づき、検出能力を実証する必要があります。組織は、既知の攻撃パターンに対する測定可能な精度を求めるとともに、ベンダーにテスト手法、対象範囲の限界、誤検知とのトレードオフの開示を求める必要があります。機密データの漏えい防止では、構造化データ型と文脈に依存する機密情報を区別し、基盤モデルやプロンプトの複雑さが異なる場合でも、一貫した検出精度を維持する必要があります。

運用パフォーマンス：購入者は、セキュリティとユーザビリティのバランスを考慮して、レイテンシーのしきい値を設定する必要があります。システムのパフォーマンスは、限定的なテスト条件ではなく、本番環境と同等の負荷で実証されるべきです。誤検知率も重要です。誤検知が多すぎるとアラート疲れを招き、シャドーAIの利用を助長します。ベンダーには、十分な期間にわたる本番環境の指標を提供できることが求められます。

監査要件：規制遵守には、数か月後でもインシデントを再現できる十分な詳細を含む包括的なログ記録が必要です。イベントは、標準形式で遅延を最小限に抑えてSIEMにエクスポートできる必要があります。保持要件は、業界やユースケースによって異なります。

フレームワークとの整合性：ベンダーは、認定された独立試験機関が策定した確立済みのフレームワークに、各種制御を対応付ける必要があります。購入者は、標準化されたテストセットと本番トラフィックのサンプルを用いて、これらの機能を実証するようベンダーに求めるべきです。独立した第三者による検証は、制御の有効性を示す信頼性の高い証拠となります。

重要な機能領域と購入検討時に確認すべき事項

最も基本的なレベルでは、モデルのセキュリティ対策により、悪意のあるプロンプトのブロック、許可されていないコンテンツのフィルタリング、簡単な利用ルールの適用が可能です。これらの機能は必要ですが、企業に大きな影響を及ぼすAIの障害の多くは、ルールの不足ではなく、コンテキスト、レジリエンス、可視性の不足に起因します。

たとえば、AIシステムが定義済みのすべてのコンテンツポリシーに準拠していても、情報の集約や推論、不適切なコンテキストの混在によって機密情報が漏えいする可能性があります。同様に、通常時には適切なルールを適用できるシステムでも、高負荷時や部分的な停止、依存関係の障害が発生した際には、予測不能な形で機能しなくなる可能性があります。

入力脅威、命令制御、回避の検知

多くのAIセキュリティ制御は、「プロンプトをフィルタリングする」または「悪意のある入力をブロックする」とうたっていますが、この捉え方では問題が単純化されすぎることが少なくありません。多くのAIシステムでは、リスクはユーザーがシステムに直接入力する内容だけでなく、後続のシステムが取り込むコンテンツに埋め込まれた指示からも生じます。こうしたコンテンツには、文書、Webページ、チケット、メール、ナレッジベースなどがあり、信頼できるコンテキストとして扱うには、その内容が十分に信頼できるものでなければなりません。

著者

Bob Walder - NSS Labs シニアアナリスト
lan Foo - NSS Lab 最高技術責任者兼製品担当エグゼクティブバイスプレジデント

寄稿者

本調査は、業界をリードするセキュリティ、クラウド、AIの専門家との協力により実施されました。

Cameron Delano - シニアソリューションアーキテクト、F5
Jeanette Hurr - グローバルソリューションアーキテクト、F5
Riggs Goodman III - プリンシパルソリューションアーキテクト（AIセキュリティおよびプライバシー担当）、AWS
Raj Bagwe - シニアソリューションアーキテクト、AWS
Zachary Riffle - セキュリティアーキテクト、Microsoft

購入者は、システムが実行時にシステム命令、開発者の意図、取得したコンテンツ、ユーザー入力をどのように区別するのかを確認する必要があります。検索拡張生成（RAG）を使用するアーキテクチャでは、この区別が極めて重要です。取得したコンテンツによってシステムポリシーが暗黙的に上書きされる可能性がある場合、明らかに悪意のあるクエリが一度も送信されなくても、システムは間接プロンプトインジェクションに対して脆弱です。

企業は、次のような質問に対する明確な回答を求めるべきです。

• ポリシーで禁止されているリクエストや指示を、システムはどの程度正確に検出、評価、ブロックできますか？
• システムは、入力プロンプトを通じて意図されたシステム動作を上書きしようとする試みを、どの程度検出して防止できますか？
• 意図が不明確な曖昧または判断の難しいプロンプトに対して、正当な利用への支障を最小限に抑えながら、システムはどの程度適切に対処できますか？
• 送信されたコンテンツに埋め込まれた指示が、意図しない形でモデルに影響を与えることを、システムはどの程度効果的に防止できますか？
• 通常とは異なる書式設定、エンコーディング、またはプロンプトの変換によって制御を回避しようとする試みに、システムはどの程度効果的に対処できますか？
• システムは、容易に回避できる経路を生じさせることなく、安全性と、役割に応じた正当なユースケース（トレーニングシミュレーション、レッドチーミング、クリエイティブ作業など）とのバランスをどの程度適切に保てますか？
• システムは、ユーザー（または外部コンテンツ）がシステムやエージェントへの指示、ルーティングルール、ツール使用上の制約、その他の「優先度の高い」制御に影響を与えたり、それらを上書きしたりすることを、どの程度効果的に防止できますか？
• システムは、モデルの不正使用やポリシーの範囲を超える過剰な使用とコストを防ぐために、モデルの利用状況を効果的に検知、特定、制御できますか？
• 命令が競合した場合、どの命令ソースが優先されたか（system、developer、retrieval、user）をログに表示できますか？

実際には、この領域の不具合は、明らかに悪意のあるプロンプトがなくても発生することが多く、信頼できないコンテンツがAIのコンテキストに取り込まれる過程で生じます。攻撃者は、複雑な複数ソースの検索パイプラインを通じて後からAIシステムに取り込まれる文書（ポリシー文書、社内Wikiページ、カスタマーサポート記事など）に、隠れた指示を埋め込む可能性があります。モデルがそのコンテンツを取得すると、埋め込まれた指示を信頼できない入力ではなく、信頼すべき指針として扱う可能性があります。社内コンテンツを幅広いユーザーが編集できる企業環境では、このような間接プロンプトインジェクションは特に検出が困難な場合があります。

たとえば、単一の情報源に変更を加えて警戒を招き、深刻な被害を直ちに与えられなくなるような手法は、必要ではなく、脅威アクターにとって必ずしも望ましいものでもありません。むしろ、複数のデータソースに小さな変更を加える方が効果的な戦略となる可能性があります。これにより、応答に関する制約の緩和、内部ワークフローの露出、システムポリシーよりも攻撃者が制御するコンテキストの優先といった、目立ちにくいものの持続的なシステム動作の変化が徐々に生じる可能性があります。最終的には、機密データがより大規模に抽出されるおそれがあります。

したがって、購入者は、AIセキュリティ制御が取得したすべてのコンテンツを潜在的に悪意のあるものとして扱っているか、また、指示の発信元にかかわらず、指示の境界が一貫して適用されているかを評価する必要があります。

効果的なソリューションは、ユーザー入力と取得したコンテンツを高い精度で区別します。ユーザープロンプトに指示の上書きを試みる内容が含まれている場合、システムはそれをブロックします。一方、正規のサポート記事に類似の表現が含まれている場合は、適切に処理します。検知はキーワードではなく意味上の意図に基づいて行われ、エンコーディングの操作やロールプレイのシナリオによって難読化された攻撃も検知します。ベンダーは、複数のソースから情報を取得する組織の実際のRAGアーキテクチャを使用して、検知機能を実証する必要があります。システムは、十分な期間にわたる本番環境の指標として、検知率、誤検知率、レイテンシーを提示する必要があります。

注意すべき兆候：汎用的なプロンプトフィルタリングへの依存、「モデルが対処する」という曖昧な説明、敵対的な条件下で命令の境界が適用されることを実証できないこと、十分な期間にわたる本番環境の指標を提示できないこと、自社のRAGアーキテクチャを使用した検出を実証できないこと、セマンティックな意図を分析せずキーワードのみに基づいて検出すること。

入力の完全性とは、悪意のある言語表現をブロックすることではなく、動的で信頼できない環境においてポリシーの権限を維持することです。

出力およびデータ流出のリスク管理

AIが生成する出力には、明らかに重大なリスクがあります。人間ではないエージェントが回答を作成するために多数の異なるシステムからデータを取得し、その回答によって、当初の意図を超える情報が外部ユーザーに開示される可能性があるためです。影響の大きい障害の多くは、明示的に禁止されたコンテンツではなく、特定のユーザー、状況、時点では開示すべきでなかった情報が気付かれにくい形で漏えいすることに起因します。

攻撃者や権限のないユーザーが、一見無害に思える一連の質問を行う可能性があります。個々の質問では許可されたデータしか返されなくても、それらを組み合わせることで、機密情報を推測または再構成できる場合があります。たとえば、社内のチケット管理システムや文書管理システムに接続されたAIアシスタントが、運用上の問題、担当者の役割、システム構成などを要約することで、内部アーキテクチャや規制対象データを間接的に明らかにしてしまう可能性があります。このような問題がキーワードフィルターで検出されることはほとんどありません。むしろ、情報の集約とコンテキストによってリスクが生じます。購入を検討する際は、出力制御で累積的な情報漏えいが考慮されているか、また、応答が制限された理由をシステムが説明できるかを評価する必要があります。これは、ガバナンスと監査可能性に不可欠な要件です。

購入者は、次のような質問に対する明確な回答を求める必要があります。

• AIセキュリティ制御は、出力に現れる単語やフレーズだけでなく、文脈上どのような情報が実際に露出しているかをどのように判断しますか？
• システムは、公開情報、社内情報、規制対象データを区別できますか？
• ユーザーのリクエストが正当または曖昧に見える場合でも、システムはモデルが応答で機密データを開示することをどの程度効果的に防止できますか？
• 保護の対象となる機密データの種類（個人データ、財務データ、企業の機密情報など）と、組織に合わせたカスタマイズ方法
• 制御は、ユーザーの役割、管轄区域、データの発生元に応じて適用されますか？
• システムは、出力がブロックまたは変更された理由を説明できますか？
• システムは、拒否、編集、監査証跡を伴う安全な変換など、リクエストとレスポンスの両方に対する制御を適用できますか？
• モデルによる機密データの出力を防ぐために、システムではどのような措置（ブロック、編集、変換、警告、追加のレビュー／承認の要求）を講じることができますか？
• 実際の情報を含む「例」「テンプレート」「テストデータ」「要約」などを要求し、モデルを欺いて間接的にデータを開示させようとするプロンプト上の細工や回避手法を、システムはどの程度防止できますか？
• システムは、セッション間またはテナント間のデータ漏えいを防止および検出し、あるユーザーのセッション、コンテキスト、または取得したデータソースの情報が別のユーザーへの応答に含まれないようにできますか？
• システムは、モデルがシステムプロンプト、内部指示、非公開ポリシー、運用構成の詳細を開示することをどの程度効果的に防止できますか？
• トレーニングデータ、システムコンテキスト、ログ、コネクター、または取得したコンテンツに含まれる可能性のある認証情報やシークレット（APIキーやトークンなど）の漏えいを、システムはどの程度効果的に防止できますか？
• 特に、ユーザーがモデルを挑発するようなエッジケースにおいて、モデルが有害、侮蔑的、または著しく偏った出力を生成することを、システムはどの程度効果的に防止できますか？
• モデルが著作権で保護された長文をそのまま出力したり、その他の方法で保護対象のコンテンツを複製したりすることを、システムはどの程度効果的に防止できますか？
• モデルが社内コンテンツ（ドキュメント、Wiki、チケット管理システムなど）に接続されている場合、ユーザーに閲覧権限のない制限付き社内資料をモデルが再現することを、システムで防止できますか？
• 有害なワークフローをモデルがユーザーに「手順を追って説明」したり、セキュリティ上の脆弱性や安全でないシステム動作を引き起こす可能性のある運用アーティファクト（スクリプト、コマンド、コードなど）を生成したりすることを、システムはどの程度効果的に防止できますか？

AIシステムを稼働中の企業データソースに接続すると、こうしたリスクは大幅に高まります。また、AIシステムが複数のソースから得た情報を1つの回答にまとめる際に、出力に関連する障害が発生する可能性があります。

出力制御を評価するには、成熟したソリューションがコンテキストに応じたデータ露出をどのように処理するかを理解する必要があります。コンテキスト認識型システムは、キーワードだけでなく意味も理解します。これにより、構造化された個人識別情報（PII）はブロックされる一方、公開情報はコンテキストに基づいて許可されることが期待されます。ロールベースの制御により、同一のクエリに対しても、認可レベルに応じてユーザーごとに異なる出力が表示されます。システムは、個々には無害な質問でも、組み合わせると機密情報が明らかになるような、セッションをまたぐ累積的な情報露出を検出する必要があります。ブロックの判断には、具体的なポリシーの参照先、データ型、認可要件を含める必要があります。既存のデータ分類ポリシーと統合することで、設定の重複を解消できます。

注意すべき兆候：キーワードのみに基づくフィルタリング、不透明な適用判断、ロールベースの適用をシステムで実証できないこと（例：ユーザーの認可レベルにかかわらず、同じクエリに対して同じ出力が返される）、特定の出力がブロックされた理由をベンダーが人間に理解できる言葉で説明できないこと、監査証跡がないことなどが挙げられます。企業は、出力制御がコンテキスト、意図、説明責任に基づいて機能していることを示す証拠を確認する必要があります。

レジリエンス、堅牢性、障害および性能低下への対応

企業では通常、正常なネットワーク条件下での有効性に基づいてセキュリティ対策を評価しますが、AIセキュリティには異なる考え方が求められます。特に重大な障害の中には、システムが直接攻撃されたときではなく、処理量や複雑さ、依存関係の障害、予期しない相互作用のパターンによってシステムに負荷がかかったときに発生するものがあります。

確認すべき主な質問：

• 通常より長時間または複雑なユーザー操作（例：「マラソン」セッション）の間、システムは可用性と応答性をどの程度維持できますか？
• 長時間にわたるセッションや複数ステップのエージェントワークフロー全体で、制御が一貫して適用されていますか？
• 反復的な入力、不正な形式の入力、または意味をなさない入力が短時間に集中した場合、システムはどのようにリソースの枯渇やサービス品質の低下を防ぎますか？
• AIセキュリティ制御の機能が低下すると、どうなりますか？
• ポリシーチェックはタイムアウトするか、また適用時にフェイルオープンとフェイルクローズのどちらになるか？
• 依存先で障害が発生した際、システムはセキュリティと稼働時間のバランスをどのように取りますか。また、その動作は設定および監査が可能ですか？

実環境のAIシステムは、利用のピーク、上流システムの停止、IDプロバイダーの応答遅延、検索サービスの性能低下など、さまざまな状況下で稼働します。このような状況では、制御を適用するコンポーネントが完全に停止するのではなく、部分的に機能しなくなる場合があります。たとえば、ポリシー評価サービスがタイムアウトしたり、応答性を維持するために分類処理が省略されたりする可能性があります。こうした障害を慎重に処理しないと、システムが運用担当者に通知せず、デフォルトで許容的な動作に移行するおそれがあります。また、エージェント型ワークフローでは、適切なチェックを経ずに処理が進む可能性があります。これは仮定上のまれなケースではなく、分散システムでよく見られる障害モードです。そのため、購入を検討する際は、依存先の性能が低下した場合にAIセキュリティ制御がどのように動作するか、また障害モードが予測可能か、可視化されているか、企業のリスク許容度に合致しているかを実演で確認するよう求める必要があります。

レジリエントなシステムは、問題が発生した際にすべてを一律にブロックしたり、安全でない動作を通知せずに許可したりすべきではありません。代わりに、予測可能な形で機能を縮退させ、エラーを明確に報告し、状況が悪化しても十分な保護を継続して提供する必要があります。

適切に設計されたシステムでは、すべての依存関係について明確な障害モードを文書化する必要があります。サービスがタイムアウトした場合、システムは適切にフェイルし、イベントをログに記録してセキュリティチームに通知するとともに、ユーザーに明確なメッセージを表示する必要があります。ストレステストでは、高い検知精度を維持し、レイテンシを許容範囲内に抑え、リクエストがセキュリティチェックを回避できないようにしなければなりません。機能低下は通知を伴って予測可能な形で発生する必要があり、通知なしに進行してはなりません。また、サーキットブレーカーは制御不能なプロセスを速やかに終了させる必要があります。ベンダーは、適用機能の可用性目標と障害時の動作を説明できることが求められます。適用がミッションクリティカルな場合、購入者は契約上の確約を求めることがあります。

注意すべき兆候：障害モードを説明できないこと、ストレステストが実施されていないこと、または「実際の運用ではシステムに障害が発生していない」と主張すること、アラートを発することなくサイレントに機能が低下すること、暴走プロセスに対するサーキットブレーカーがないこと、ストレステスト時にも高い検出精度が維持されることを実証できないこと、機能低下時にリクエストがセキュリティチェックを回避できるシステムなどが挙げられます。

ポリシー／フィルターの有効性とガバナンスとの整合性

技術的に高度であっても、運用面で整合していないAIセキュリティ制御は、最前線であるビジネスの現場ではほとんど機能しません。エンタープライズ環境におけるポリシー上の判断は、通常、二者択一でも固定的でもなく、最終的にはガバナンス上の判断となります。

購入担当者が確認すべき点：

• ポリシーの定義、承認、バージョン管理、監査はどのように行われますか？
• ポリシーの適用範囲を、役割、データの機密性、地域、またはビジネスコンテキストに基づいて設定できますか？
• システムは、判断が下された理由を説明できますか？
• 組織固有のコンプライアンス方針（業界規則、社内ポリシー、許容される利用に関する制約）を反映したポリシーを、システムはどの程度適用でき、それらのポリシーは長期的にどのように維持されますか？
• このシステムは、法的リスクやコンプライアンス上のリスクにつながる可能性のある応答（例：適用される規則や基準に違反する助言やガイダンス）を防止するうえで、どの程度効果的ですか？

ポリシーの不備は、意図の問題ではなく、技術的な適用とビジネスの実態との乖離によって生じることが少なくありません。たとえば、AIシステムが特定のデータカテゴリーへのアクセスを適切にブロックしていても、その方法が正当な業務フローを妨げる場合、ユーザーが未承認のツールを使用して制御を完全に回避する可能性があります。反対に、定義が緩すぎるポリシーでは、規制上または契約上の義務に違反する状況で機密情報の露出を許してしまう可能性があります。苦情に対処するための場当たり的な調整を重ねると、ポリシーの整合性と説明責任が徐々に損なわれかねません。そのため、購入を検討する際は、文書化された承認、バージョン履歴、適用結果をレビューする機能など、体系的なポリシーガバナンスをAIセキュリティプラットフォームがサポートしているかを評価する必要があります。こうした規律がなければ、ポリシーの正確性は主観的なものとなり、セキュリティインシデントの発生後にその妥当性を説明することが難しくなります。

過度な適用は業務の混乱を招き、不満を抱いたユーザーが未承認の「シャドーAI」システムを導入するきっかけとなる可能性があります。一方、適用が不十分な場合は、規制上および評判上のリスクにつながるおそれがあります。いずれもモデルの不具合ではなく、ガバナンス上の問題です。

効果的なポリシー管理では、ポリシーをコードとして扱い、バージョン管理、承認ワークフロー、監査証跡を適用する必要があります。ポリシーを変更する場合は、本番環境へのデプロイ前に、セキュリティ、法務、事業部門の各関係者から文書化された承認を得る必要があります。すべての適用判断は、具体的なポリシー条項、バージョン、セクション、認可ロジックまで追跡できるようにする必要があります。可能な場合は、誤検知の傾向や影響の大きいブロック、さらに可能であればチューニングの推奨事項など、システムダッシュボードから得られる情報に基づいてポリシーを改善する必要があります。

危険信号には、次のようなものがあります。不透明な意思決定、場当たり的なチューニング、説明責任を伴わないポリシーの「自己学習」という主張、ポリシー変更に対するバージョン管理や承認ワークフローの欠如、特定のポリシー条項まで追跡できない適用判断、文書化された解決ルールがないポリシー間の競合。

エージェント型AI、ツール呼び出しのセキュリティ、委任された権限

AIシステムが受動的な支援の枠を超え、ユーザーや他のシステムに代わって動作するようになると、「権限委譲」と呼ばれる新たなリスクが生じます。エージェント型AIシステムは、他のツールを呼び出し、レコードを変更し、複雑なワークフローをマシン速度で実行できます。

エージェント型AIのセキュリティを評価する際は、以下の主要な制御領域を確認する必要があります。

• システムはどのようなアクションを自律的に実行できますか？
• 権限はどのように制限されていますか？
• ユーザーに代わって行動する権限を委任されたエージェントに対し、許可される操作と許可されない操作を、システムはどの程度適切に適用していますか？
• 明確な制限がなければ小さなエラーが複数のシステムに急速に波及する可能性があるため、リスクやコンテキストに応じて自律性を段階的に設定できますか？
• システムが外部のツールやエージェントと連携したり、それらを活用したりできる場合、プロンプトによってシステムが意図した範囲外のアクションへ誘導されることを、システム制御はどの程度防止できますか（ユーザーが「丁寧に頼んだ」場合も含む）。
• システムは、エージェントが目標を達成しないまま動作し続ける再帰ループや「暴走」動作を効果的に防止または抑制できますか？
• このシステムは、ツールの不正使用、API／アクションのエスカレーション、過度な自律動作やループ、安全でないツール間の連鎖をどの程度効果的に防止できますか？
• マルチエージェントアーキテクチャにおいて、あるエージェントが取得または生成した機密データが、関連タスクを実行する後続のエージェントやツールに不必要に伝播することを、システムはどの程度効果的に防止できますか？
• マルチエージェントアーキテクチャでは、権限がシステム境界を越えて適切に引き継がれることが極めて重要です。システムはエージェントチェーン全体でアイデンティティコンテキストをどの程度効果的に維持し、後続のエージェントやツールが昇格されたシステム権限ではなく、元のユーザーの権限の範囲内で厳密に動作するようにできていますか？

委任された権限に関する不備は、自動化を実現するために、適切な制約を設けずAIシステムに広範なツールへのアクセス権を付与した場合に生じることが少なくありません。たとえば、サポート上の問題解決を担うAIエージェントには、データベースの照会、レコードの更新、ユーザーへの通知が許可されている場合があります。指示の誤解や想定外のコンテキストにより、データが誤って変更されたり、顧客への連絡が時期尚早に行われたりする可能性があります。こうした処理は機械的な速度で実行されるため、人間による監督が介入する前にエラーが波及しかねません。複雑なワークフローでは、個々にはリスクの低い処理でも、組み合わさることで重大な結果を招く可能性があります。購入を検討する際は、AIセキュリティ制御によって最小権限が適用されているか、機密性の高い処理に確認が必要とされているか、自律性を動的に制限または取り消す仕組みが備わっているかを評価する必要があります。エージェント型の動作をガバナンス上の課題として扱うことは、気付かないうちに権限が拡大する事態を防ぐうえで不可欠です。

適切に設計されたシステムでは、アーキテクチャ上の制御によってこれらのリスクを軽減します。適切な制約を設けたシステムでは、文書化された権限境界に基づき、ツールごとに最小権限を適用します。段階的な自律性を実現するには、中程度の影響を伴うアクションには確認を、影響の大きいアクションには人による承認を必須とする必要があります。また、アイデンティティコンテキストを維持することで、エージェントがシステムレベルの権限ではなく、ユーザー権限を継承するようにします。ユーザーが機密性の高い操作を要求した場合、エージェントは不正アクセスをブロックしながら、許可された情報のみを取得する必要があります。サーキットブレーカーは、制御不能なループを速やかに停止する必要があります。また、エージェントによるすべてのアクションについて、推論、認可チェック、結果を含む完全なログを記録する必要があります。

これらの制御は、アーキテクチャ上の制約と行動上の制約の重要な違いを反映しています。アーキテクチャ上の制約では、エージェントが特定のツールを呼び出したり、特定のアクションを実行したりすることをシステムが技術的に防止します。一方、行動上の制約では、エージェントはそのアクションを実行できるものの、実行しないよう指示されます。セキュリティ上重要な境界には、行動上の指示だけに頼るのではなく、可能な限りアーキテクチャ上の制御を適用する必要があります。

危険信号には次のものがあります。エージェント型AIのガバナンスが脆弱であることを示す兆候として、すべてのツールへの一律のアクセス許可や、不正利用の防止をモデルのアラインメントのみに依存していること、ツールごとの権限境界が文書化されていないこと、エージェントがユーザー権限を継承できるようにするアイデンティティコンテキストが維持されていないこと、チェーン分析によって安全でない一連のアクションを検出できないこと、エージェントのアクションに関するログに推論や認可チェックが完全に記録されていないことが挙げられます。

可観測性、監査、フォレンジック

AIシステムで問題が発生した場合、どのように、なぜ発生したのかを実証し、場合によっては再現できることが重要です。

購入者は、入力、コンテキスト、ポリシー、出力、アクション、呼び出されたツール、アクセスされたデータを含め、AIとのやり取りをエンドツーエンドで再構築できるかどうかを確認する必要があります。効果的なシステムは、継続的な監視とアラートにも対応し、インシデントが深刻化する前に、セキュリティチームが異常な動作、安全でない一連のアクション、予期しないエージェント間のやり取りを検出できるようにする必要があります。システムの動作を十分に可視化できなければ、インシデント対応は推測に頼ることになり、ガバナンスへの信頼性も損なわれます。

AI関連のインシデントが発生した場合、組織には説明ではなく証拠の提示が求められることがあります。入力、取得したコンテキスト、適用されたポリシー、出力、アクションに関する詳細な記録がなければ、インシデント対応チームは事実ではなく推測に基づいて事象を再構成せざるを得ません。非決定性により動作を再現できない可能性があるAIシステムでは、これは特に大きな問題となります。たとえば、規制当局や内部監査担当者から、特定の情報が開示された理由や自動アクションが実行された理由を問われることがあります。しかし、エンドツーエンドのオブザーバビリティがなければ、組織は意図、比例性、統制の有効性を立証できません。そのため、購入を検討する際は、AIセキュリティプラットフォームが、インシデント対応、コンプライアンス報告、インシデント後の学習を支援するために必要なレベルの可視性を提供しているかどうかを評価する必要があります。

包括的なログ記録により、元のプロンプト、取得したコンテキストとそのソース、ID／認可のコンテキスト、評価されたポリシーとそのバージョン、モデルの出力、加えられた変更、ユーザーへの最終応答、後続のアクションを含め、リクエストをエンドツーエンドで再構築できる必要があります。AIセキュリティイベントは、最小限の遅延でSIEMシステムと連携し、ネットワークトラフィックや認証イベントとの相関分析を可能にする必要があります。重大な違反については、即時対応に十分なコンテキストとともにアラートを速やかに発する必要があります。また、傾向分析を用いてセキュリティ、パフォーマンス、品質の指標を追跡できる統合ダッシュボードも必要です。

GRCの観点では、可観測性のないシステムをガバナンスの対象とすることはできません。

統合と相互運用性

個別に動作するAIセキュリティ制御では可視性にギャップが生じ、連携した対応が妨げられます。多層防御アーキテクチャには、テレメトリを共有し、セキュリティレイヤー間で適用を連携させる制御が必要です。

アイデンティティおよびアクセス管理：認可の境界は、ユーザー認証からデータ取得、最終出力まで一貫して適用する必要があります。組織は、システムとアイデンティティプロバイダーの連携方法、およびロールの変更が適切に反映されるかどうかを評価する必要があります。AIエージェントがユーザーに代わって動作する場合、システムは追跡可能な権限チェーンとともに認可コンテキストを維持する必要があります。また、アクセス ポリシーは、設定を重複させることなく既存のRBACモデルから継承する必要があります。取得レイヤーでは、要求元ユーザーの認可レベルに基づいてドキュメントをフィルタリングし、最小権限を適用する必要があります。

SIEM統合：AIセキュリティイベントは、より広範なセキュリティテレメトリと相関付ける必要があります。そのため、システムはOCSFやCEFなどの標準形式で、遅延を最小限に抑えてイベントをSIEMプラットフォームにエクスポートする必要があります。独自のログ形式では、ネットワークトラフィック、認証イベント、データアクセスパターンとの相関付けができません。組織は、AIセキュリティイベントに基づいてカスタム検知ルールを作成できるか、またアラートを既存のインシデント対応ワークフローと統合できるかを確認する必要があります。

コンプライアンスフレームワークとの整合：ソリューションでは、具体的な統制の適用範囲と監査証跡を示したうえで、統制を確立されたフレームワークに対応付ける必要があります。また、コンプライアンスレポートは、個別の規制要件に合わせてカスタマイズできる必要があります。具体的な統制との対応付けを伴わない一般的なコンプライアンスの主張では不十分です。

APIと自動化のサポート：最新のセキュリティ運用にはプログラムによる制御が必要であり、システムはPolicy as CodeのワークフローとInfrastructure as Codeの統合をサポートする必要があります。文書化されていないAPIや頻繁に変更されるAPIは、統合を不安定にします。

購入前に買い手が求めるべきこと

企業は、アーキテクチャ図や見栄えのよいマーケティング資料よりも証拠を、洗練されたデモよりも再現性を、自己主張よりも独立した検証を求めるべきです。

購入者はベンダーに対し、制限事項を説明し、現実的なテストを支援するとともに、精査に耐え得る成果物を提供することを求めるべきです。

テストや説明ができないセキュリティ対策を、ビジネスクリティカルなAIシステムの保護において信頼すべきではありません。

独立した検証に向けた準備

AIセキュリティの評価は困難ですが、それを検証しない理由にはできません。独立したテストは、制御機能や各種機能が説明どおりに動作することについて、企業が確信を得るための数少ない手段の1つです。

購入者は、敵対的入力、性能低下のシナリオ、ガバナンス要件など、実環境の条件を反映した検証手法を求めるべきです。意義のある検証への参加に消極的なベンダーの姿勢は、強みではなく未成熟さの表れです。

また、検証を一度限りの作業として扱うべきではありません。初期評価で良好に機能したAIセキュリティ対策も、脅威の進化、モデル機能の高度化、新たな攻撃手法の出現に伴い、効果が低下する可能性があります。脅威を取り巻く状況は急速に変化しており、AIセキュリティインシデントでは、これまで確認されていない攻撃手法が用いられる可能性もあります。そのため、組織は初期テストに加えて、継続的な検証要件を定める必要があります。

脅威インテリジェンスの統合： 組織は、脅威インテリジェンスベンダーやセキュリティ研究機関が新たに開示した脆弱性を取り込む際の、ベンダーの更新頻度を評価する必要があります。ベンダーは、過去のトレーニングデータだけでなく、最近公表された攻撃を検知できることを実証する必要があります。脅威インテリジェンスを自動で取り込むことで、手動のレビュープロセスよりも迅速に対応できます。

モデル進化への対応：基盤モデルの機能は急速に進化するため、セキュリティ制御もそれに適応する必要があります。組織は、さまざまな基盤モデルについて、モデルごとの検知有効性データを求めるとともに、死角を覆い隠す可能性がある、定量的な根拠を伴わない一般的な主張に注意する必要があります。ベンダーは、新しいモデルバージョンの認定時期を明示し、認定までの空白期間における暫定的な緩和策を提示する必要があります。

購入者主導の検証：組織はベンダーによる検証だけに依存せず、セキュリティ制御を継続的にテストする必要があります。購入者は、定期的なレッドチーム演習、継続的な自動バイパステスト、本番環境におけるポリシー変更のA/Bテストを実施する契約上の権利について交渉すべきです。顧客によるテストを制限したり、詳細なテレメトリを開示しなかったりするベンダーは、成熟度が不十分である可能性があります。

脅威の状況が変化する中でも有効性を維持するには、組織は検証を一度限りの評価ではなく、継続的なパートナーシップとして捉える必要があります。こうした取り組みを行わなければ、適切に設計された対策であっても、新たな攻撃手法に対していずれ不十分となる可能性があります。

結論：主張から説明責任へ

AIセキュリティの導入は、単なる技術上の判断ではなく、長期的な影響を伴うガバナンス上の判断です。

難しい問いに最初から向き合う企業は、リスクを管理し、意思決定の妥当性を説明し、回避可能な失敗を防ぐうえで、より有利な立場に立てます。

AIセキュリティを成功に導くのは、目新しさや抽象論ではなく、説明責任、透明性、そして規律ある評価です。

© 2026 NSS Labs®。無断転載を禁じます。本書のいかなる部分も、NSS Labs（以下「当社」）の明示的な書面による同意なく、複製、コピー／スキャン、検索システムへの保存、電子メールでの送信、その他の方法による頒布または送信を行うことはできません。