モデルだけではないAIセキュリティ：企業が重視すべきことと、その理由

AIは急速に進化していますが、ほとんどの企業が保護できているのは、実際のリスク領域のごく一部にすぎません。F5、AWS、Microsoftの協力のもと作成されたNSS Labsの本調査レポートでは、AIを実験段階から本番環境へ移行する際に特に重要となる脅威ベクトル、ガバナンス上のギャップ、必要な能力領域について検証しています。

目次

はじめに：AIセキュリティが企業リスクの課題である理由

セキュリティにおける責任あるAIの中核的な柱

モデルのセキュリティだけでは不十分な理由

AIセキュリティに関する責任範囲の明確化

新たな脅威モデル：従来のセキュリティ上の前提が通用しない理由

真に重要な機能領域

入力の完全性と指示の制御

出力リスクとデータ流出の管理

システムのレジリエンスと堅牢性

ポリシーの精度とトレードオフの管理

セキュリティ上重要な意思決定のための決定論的検証

エージェント型AIと権限委譲

オブザーバビリティ、監査、フォレンジック

GRCを欠いたAIセキュリティが失敗する理由

結論：エンタープライズ規模でのAIガバナンス

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

エグゼクティブサマリー

人工知能（AI）は、企業環境全体で実験段階から本番環境への導入へと急速に移行しています。生成AIモデル、対話型アシスタント、自律性を高めつつあるエージェントベースのシステムは、顧客向けアプリケーション、社内ワークフロー、ソフトウェア開発パイプライン、意思決定支援プロセスに組み込まれるようになりました。その結果、AIシステムの障害はすでに、事業、法務、評判、運用に関する具体的なリスクとなっているだけでなく、効果的なガバナンスを実現するうえでの重大な課題にもなっています。

AIセキュリティに関する議論では、AIモデル自体に焦点が当てられることが多く、モデルがどのようにトレーニングされ、どのようなデータを含み、管理された条件下でどのように動作するかが重視されています。AIモデル内部のセキュリティが極めて重要であることは明らかですが、それがカバーするのはリスク領域の一部にすぎません。本番環境では、最も重大な脆弱性はモデルの外部、つまりモデルが接続するデータ、呼び出せるツール、継承する権限、そしてモデルの動作を制約するガバナンスの実践（またはその欠如）に現れることが少なくありません。

本稿では、AIセキュリティソリューションを評価する際に企業が特に重視すべき領域と、それらが重要である理由を概説します。特定の製品やテスト手法には焦点を当てず、エンタープライズリスク管理、ガバナンス、説明責任の観点から、能力を軸にAIセキュリティを捉えます。その目的は、現実のAI障害によって、規制当局、司法機関、顧客、取締役会の厳しい精査の下で望ましくない事実が明らかになる前に、最高情報セキュリティ責任者（CISO）、企業の購買担当者、ガバナンス・リスク・コンプライアンス（GRC）の責任者が確認すべき事項について、具体的な指針を示すことです。

はじめに：AIセキュリティが企業リスクの問題である理由

企業システムにおけるAIの活用が加速するなか、その管理を目的とした統制の導入を担う担当者は、大きな課題に直面しています。事業部門では、生産性の向上、意思決定の自動化、ソフトウェア開発の迅速化、顧客体験の差別化を図るため、AIを活用した機能を導入していますが、その多くは、正式なセキュリティ、リスク、ガバナンスのレビューに先行して展開されています。この急速な進展により、イノベーションと説明責任の隔たりが広がっています。

AIモデル自体のセキュリティを確保することは不可欠ですが、それだけでは十分ではありません。ほとんどの企業では、トレーニングデータの選定、安全性チューニングとアラインメント手法の活用、モデルにアクセスできるユーザーの制限、利用頻度の制限、組み込みのコンテンツフィルターと応答拒否動作の利用など、モデルレイヤーに直接制御を適用しています。これらの対策は、モデルの出力を調整し、明らかな悪用を減らすものですが、出力が稼働中のデータと連携してアクションをトリガーし、複雑な認可コンテキスト内で動作する実際の企業環境において、AIシステムがどのように稼働するかまでは対処できません。

AIセキュリティの文脈において、責任あるAI（RAI）とは、人工知能システムがライフサイクル全体を通じて安全性、セキュリティ、レジリエンス、信頼性を確保できるようにするための、包括的なガバナンスとライフサイクルのフレームワーク、ポリシー、技術的プラクティスを指します。単に攻撃を阻止するだけでなく、人間による監督を維持しながら、意図しない損害、プライバシー侵害、バイアスに対するシステムの堅牢性を確保します。

セキュリティにおける責任あるAIの中核原則

セキュリティの観点に絞ると、RAIフレームワークは、いくつかの実践的な管理領域に落とし込むことができます。具体的には、エラー、予期しない入力、意図的な敵対的攻撃に対するAIシステムのレジリエンスの確保、プライバシーとデータ保護を確保するためのトレーニングおよびデプロイメントパイプラインのセキュリティ確保、透明性と監査可能性の維持、ならびに許容される利用方法と説明責任を定めるガバナンスプロセスの確立です。

RAIフレームワークでは、モデル中心のセキュリティ機能により、機械学習に固有の次のような脆弱性をプロアクティブに緩和します。

• データポイズニング：モデルを破壊するためにトレーニングデータを操作すること
• モデルの反転／抽出： 独自モデルの窃取、または機密性の高いトレーニングデータの漏えい
• 敵対的攻撃：入力にわずかで検知できない変更を加え、誤った判断を引き起こす
• プロンプトインジェクション：生成AIを欺き、意図されたポリシーや指示の境界を回避させる攻撃

これらのモデルセキュリティ制御は、基本的な安全性を確保するために必要ですが、企業固有のコンテキストをほとんど考慮せずに機能し、通常、独立した検証や外部検証に対する透明性も欠いています。企業側では、これらの制御がどのように実装されているか、またエッジケースでどのように動作するかを十分に把握できないことが少なくありません。

エンタープライズレベルの導入環境では、AIモデルは大規模なシステムを構成する一要素にすぎません。このシステムには、検索レイヤー、企業データへのコネクター、アイデンティティおよび認可のシグナル、さらに下流システムの状態を大きく変える可能性があるツール呼び出しが含まれます。企業におけるリスク領域の大部分は、こうした統合と周辺のAIシステムコンポーネントに起因します。適切にアラインメントされたモデルであっても、不適切なデータに接続されている場合、過剰なツール権限が付与されている場合、ポリシーの適用に一貫性がない場合、または不正使用を検知するための監視が不十分な場合には、安全でない形で使用される可能性があります。

ここで、外部のランタイムAIセキュリティ制御（AIガードレール、AIファイアウォール、AI保護システムなどと呼ばれます）が不可欠になります。ランタイムガードレールは、企業リスクが顕在化するアプリケーションとのやり取りの時点で、セキュリティポリシーと動作上の境界を適用するために、モデルの外部に実装される具体的かつ技術的なリアルタイム制御です。これらの制御は、ユーザーID、データの機密性、アプリケーションの状態、ガバナンス要件など、システムレベルのコンテキストを使用してAIの動作を監視し、制約します。ランタイム制御によって監査可能性、レジリエンス、説明責任が確保され、エンタープライズグレードのAIセキュリティの基盤が形成されます。

ベンダーやフレームワークによって用語は異なりますが、実務上の要点は明確です。モデルセキュリティはモデル固有のリスクを低減し、ランタイムガードレールはインタラクションの時点で企業リスクを管理します。

モデルセキュリティだけでは不十分な理由

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

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

これらのリスクに対処するには、システム全体を把握し、ガバナンスの監督下で機能するランタイム制御が必要です。これには、役割とデータの機密性に基づくポリシーの適用、ツール呼び出しと委任権限の制限、障害モードの予測可能な処理、調査、監査、コンプライアンスを支える証拠の生成が含まれます。

ガバナンス、オブザーバビリティ、レジリエンスがなければ、モデルのセキュリティだけでは、エンタープライズ規模で稼働するAIシステムに求められるレベルの保証を提供できません。したがって、最も成熟した組織は、AIセキュリティをモデルだけの問題ではなく、システムとガバナンスの問題として捉えます。

執筆者

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

AIセキュリティの責任範囲の明確化

AIサービスを利用する組織が直面するリスクは、カスタムモデルを構築したり、ゼロからトレーニングしたりする組織とは根本的に異なります。実装範囲を把握することで、組織内で管理するセキュリティ制御と、プロバイダーが管理するセキュリティ制御が明確になります

5つの実装範囲

1. 最も基本的なレベルでは、一般消費者向けAIアプリケーション（ChatGPT、Claude、Geminiなど）のセキュリティ責任は、ほぼすべてプロバイダーが担います。プロバイダーは、モデルのセキュリティ、インフラストラクチャの保護、基本的なガードレール、データ保護を管理します。組織は、適正利用ポリシーの策定、ユーザーアクセスの制御、ビジネスコンテキストに照らした出力の検証に重点を置きます。セキュリティ対策では、従業員による機密データの入力防止と、ポリシー違反の監視を重視します。
2. AI機能を備えたエンタープライズアプリケーション（Salesforce EinsteinやMicrosoft Copilotなど）では、責任共有モデルが採用されています。プロバイダーはモデルのセキュリティ、アプリケーションレベルの制御、統合のセキュリティを管理し、お客さまはロールベースのアクセス、データ分類、ワークフローの権限を管理します。セキュリティの重点は、ID統合、データガバナンス、適切な利用を証明する監査ログへと移ります。
3. Amazon BedrockやAzure OpenAIなどのプラットフォームを通じて事前トレーニング済みの基盤モデルを導入する組織は、セキュリティに関してより大きな責任を担います。プロバイダーがモデルのセキュリティとインフラストラクチャを管理する一方、お客さまはプロンプトエンジニアリング、検索アーキテクチャ、出力フィルタリング、ツールの権限を管理します。セキュリティの重点は、入力の完全性、出力リスクの防止、システム全体にわたる包括的なオブザーバビリティへと広がります。
4. ファインチューニング済みモデルでは、組織のセキュリティ負担がさらに増大します。プロバイダーが管理するのはインフラストラクチャとベースモデルのセキュリティのみであり、トレーニングデータの選定、ファインチューニングの安全性、デプロイ制御、実行時のすべてのセキュリティはお客さまが管理します。セキュリティ対策では、データポイズニングの防止、モデル評価、開発から本番運用までのライフサイクル全体にわたる包括的なガードレールに取り組む必要があります。
5. 最も複雑なレベルでは、独自にトレーニングしたモデルに関するセキュリティ責任のほぼすべてを組織が負います。プロバイダーが管理するのはインフラストラクチャのみであり、モデル開発、トレーニングパイプラインのセキュリティ、デプロイ、ランタイム制御のあらゆる側面はお客さまが管理します。セキュリティ対策では、データ収集から本番環境の監視、インシデント対応に至るまで、ライフサイクル全体を対象とします。

責任共有モデルを理解する

実装範囲によって、お客さまが負うセキュリティ上の責任が根本的に決まります。コンシューマー向けAIアプリケーションでは、セキュリティ上の責任の大半をプロバイダーが負い、組織は従業員によるサービス利用のガバナンスに注力します。エンタープライズアプリケーションでは、プロバイダーが基盤インフラストラクチャのセキュリティを確保する一方、ID統合とデータガバナンスに対するお客さまの責任が増します。事前トレーニング済みの基盤モデルでは、プロンプトエンジニアリング、検索アーキテクチャ、包括的なランタイム制御など、セキュリティ上の重要な責任が組織に移ります。さらに、ファインチューニング済みモデルと独自にトレーニングしたモデルでは、トレーニングデータのキュレーションから本番環境の監視、インシデント対応に至るまで、セキュリティ上の責任のほぼすべてをお客さまが負います。

この責任共有モデルは、既存のクラウドセキュリティの仕組みを反映しています。AIセキュリティの計画を進める前に、実装範囲を明確に特定することが不可欠です。これにより、社内で構築すべきセキュリティ機能、プロバイダーが管理する機能、共同での監督が必要な領域が決まります。範囲を明確に理解して適用しなければ、プロバイダーがすでに管理している制御に過剰投資したり、重大なギャップに対処しないまま放置したりする可能性があります。

新たな脅威モデル：従来のセキュリティ前提が通用しない理由

従来のアプリケーションセキュリティは、入力が一定の範囲に限定され、実行パスが予測可能で、結果が決定論的であることを前提としています。AIシステムは、こうした前提に反し、多くの場合、その前提を成り立たなくします。構造化されていない自然言語の入力を受け付け、非決定論的な応答を生成し、複数回にわたる対話のコンテキストを保持することも少なくありません。周辺のアプリケーションが適切に設計されていても、モデルには確率的な挙動が伴うため、従来の脅威モデリングだけで対処することは困難です。

最新のAI導入環境は、単に「プロンプトを入力し、応答を出力する」という仕組みよりも複雑です。実際の企業環境では、AIシステムは一般に、社内文書、データベース、API、外部サービスに接続されています。代表的なアーキテクチャの1つが検索拡張生成（RAG）です。これは、モデルが実行時に外部コンテンツ（ポリシー文書、ナレッジベースの記事、顧客記録など）を動的に取得し、モデルのトレーニングデータだけを使用する場合よりも複雑な質問に正確に回答できるようにする仕組みです。

多くの導入環境ではさらに進んで、人間が直接介入したり指示したりしなくても、次に実行すべき手順を判断できる自律型システムやエージェントベースのシステムが使用されるようになります。こうしたAIエージェントは、テキスト生成の枠を超えてAIの機能を拡張するプログラムインターフェースである外部ツールと連携し、実行するアクションを決定します。ツールとは、AIシステムが外部システムと連携し、データベースへのクエリ、REST APIの呼び出し、コードの実行、ファイルシステムへのアクセス、エンタープライズアプリケーションの起動などのアクションを実行できるようにする個別の機能です。レスポンスの生成に役立つコンテキスト情報を取得する検索拡張生成（RAG）とは異なり、ツールを使用すると、AIシステムはアクションを実行し、後続システムの状態を変更できます。

各ツールは、固有の権限と「影響範囲」を持つセキュリティ境界です。AIエージェントがツールにアクセスすると、そのツールで可能なあらゆる操作を実行できるようになります。こうした機能は効率と拡張性を高める一方、多くのセキュリティチームにとってなじみがなく、従来の制御では管理が難しい形で攻撃対象領域を拡大します。

「日の下に新しきものなし」という古いことわざがあります。これは、人生のほかのあらゆる事柄と同様にセキュリティ脅威にも当てはまります。つまり、AIセキュリティエンジニアは、AI固有の攻撃対象領域だけでなく、バッファオーバーフローやネットワークレベルの回避手法といった従来からある攻撃対象領域にも、同じように注意を払う必要があります。同時に、AIシステムに対する脅威が従来型のエクスプロイトをはるかに超えることも明らかです。

これには、命令の操作（プロンプトインジェクション）、取得したコンテンツを介したコンテキストポイズニング、生成された出力を通じたデータ流出、ツール対応システムに委任された権限の悪用、機密性ではなく信頼性を損なう劣化攻撃などがあります。たとえば、AIは社会保障番号（SSN）を何通りの方法でエンコードしたり難読化したりできるでしょうか。さらに、個人識別情報（PII）を抽出される本人になりきるよう求められる可能性があるシステムでは、そもそも何通りの方法でAIを欺き、そのような情報を漏えいさせることができるでしょうか。

これらの脅威パターンは、広く認知された独立系テスト機関が策定した標準化されたテストフレームワークと手法に記載されています。これらのフレームワークは、企業が理解し、対処すべきAI固有の脆弱性を体系的に分類しています。

真に重要な機能領域

エンタープライズ環境への導入を想定してAIセキュリティソリューションを評価する際は、現実のリスクに直結する少数の機能領域に重点を置く必要があります。これらの機能は、本番環境におけるAIシステムの利用方法と、実際に障害が発生する仕組みを反映したものであり、単独の制御ではなく、統合された多層構造として機能しなければなりません。

AIモデルだけでは、エンタープライズのセキュリティ境界を確実に適用できません。AIモデルは設計上、入力を指示として扱い、監査可能なアクセス制御のセマンティクスをネイティブに備えていないためです。単一レイヤーの防御には、悪用可能な隙が生じます。出力検証を伴わない強固な入力整合性では、RAGポイズニングによる間接的なデータ流出を許し、可観測性を伴わない出力フィルタリングでは、ポリシードリフトを検出できません。また、システムレジリエンスを伴わないエージェント型AIの制御は、ストレス条件下で機能しなくなります。各機能を個別に実装している組織では、攻撃者が1つのレイヤーを回避し、後段の防御がないことを悪用すると、連鎖的な障害が発生します。成熟したAIセキュリティアーキテクチャでは、これらの機能を統合防御システムの相互依存するコンポーネントとして扱います。

これらの機能はガバナンス上の課題にも自然に対応し、何が許可され、何が禁止され、何が監視され、何がログに記録されるのか、また、事後に何を根拠として正当性を主張できるのか、といった問いへの答えを提供します。

入力の完全性と指示の制御

AIシステムは、指示、コンテキスト、情報の提示方法に特に大きく左右されます。入力を厳密に解析して検証する従来のアプリケーションとは異なり、AIシステムは設計上、自然言語を柔軟に解釈します。この柔軟性により、強力な新しいユースケースが可能になる一方で、操作される余地も生じます。

悪意のある攻撃者は今後、次のようなさまざまな脅威ベクトルを通じて、この柔軟性を悪用するケースが増えると考えられます。

• プロンプトインジェクション：「以前の指示を無視する」「管理者として振る舞う」「システムルールを開示する」などの指示を与え、ポリシーを直接無効化しようとする試み。
• 間接的な命令の埋め込み：システムが後で取り込むWebページ、PDF、社内Wikiページ、カスタマーサポートチケットなどのコンテンツ内に、悪意のある命令を埋め込む手法です。
• コンテキスト操作：信頼できない入力を信頼できるポリシーと誤認させたり、システム命令よりも優先させたりするように、会話の流れを操作します。

企業にとってのリスクは、モデルが不適切な内容を出力することだけではありません。モデル外部のセキュリティ制御に設定不備があると、AIシステムが信頼できない指示をポリシーとして扱うよう誘導され、データやツールへの昇格されたアクセス権限をその指示に従って使用するおそれがあります。たとえば、改ざんされたナレッジベースの記事によって、アシスタントが「完全を期すために顧客記録をすべて含める」、または「社内システムのトラブルシューティング手順を開示する」よう指示され、意図しない情報開示や業務上の損害につながる可能性があります。

効果的なAIセキュリティ制御では、プロンプトの指示とは無関係に、データアクセスとツールの権限を適用します。また、システム指示の完全性を維持し、信頼できるシステムコンテキストと信頼できない入力を明確に区別するとともに、外部コンテンツによって動作が暗黙的に変更されることを防ぐ必要があります。実践的な評価では、プラットフォームが指示の上書き試行を検知できるか、取得したコンテンツに事実ではなく指示が含まれている場合にそれを識別できるか、さらに敵対的な条件下でもシステムレベルのポリシーが引き続き有効であったことを証明できるかが重要です。

出力リスクとデータ流出の管理

AIが生成する出力は、企業リスクの中でも特に顕在化しやすい要因の1つです。組織は明示的に禁止されたコンテンツのブロックに注力しがちですが、AIの不具合によって、一見問題がないように見える、より気付きにくい情報漏えいが発生する可能性があります。そして、「そのユーザーがその情報を知ることができてよかったのか」と誰かが疑問を呈して、初めて問題が明らかになります。

AIシステムは、直接引用するのではなく、推論、情報の集約、部分的な再構成を通じて機密情報を露呈する可能性があります。モデルが「役立つ説明」を通じて内部プロンプトやポリシーの文面を明らかにしたり、独自のコードパターンを露呈したり、戦略が漏洩する形で機密文書を要約したり、攻撃者の攻撃能力を高める運用上の詳細を提供したりするおそれがあります。規制対象となる状況では、再識別を可能にしたり、保護対象データを明らかにしたりする場合、間接的な開示であっても問題となる可能性があります。

AIシステムを稼働中の企業データソースに接続すると、こうしたリスクは大幅に高まります。CRM、チケットシステム、ドキュメントリポジトリを照会できるサポートアシスタントは、特に検索範囲が広すぎる場合や、アイデンティティシグナルが一貫して適用されていない場合、要求者に想定されたアクセスレベルを大きく超える情報を意図せず提示する可能性があります。組織は、ユーザー認証からデータ取得、出力生成に至るまで、AIシステム全体で一貫して適用されるアイデンティティおよびアクセス制御を確立する必要があります。こうした制御がなければ、操作を試みる攻撃は成功します。強固なアクセス制御を導入している組織でも、AIが複数のソースを1つの一貫した回答にまとめることで、境界が曖昧になる可能性があります。

出力リスクの管理には、単純なキーワードフィルタリングだけでは不十分です。制御では、どのデータが公開されるのか、なぜそのデータが機密性の高い情報に該当するのか、どのような条件下であれば開示が許容されるのかを把握する必要があります。企業は、制御が適切な粒度（カテゴリー、機密性レベル、法域）で機能しているか、ポリシーがロールを考慮しているか、出力がブロックまたは変更された場合にシステムが妥当性を説明できるかを確認する必要があります。ガバナンスの観点では、機密データに対する制御が存在し、一貫して機能していることを実証できる能力が求められます。

システムのレジリエンスと堅牢性

AIの障害がすべて劇的な形で現れるとは限りません。特に深刻な被害をもたらす障害の中には、負荷によってシステムの機能が低下するにつれて、目立たないまま発生するものもあります。長時間にわたるセッション、不正な形式の入力（処理不可能なほど巨大な入力を含む）、クエリの繰り返し、または極めて複雑なタスクは、明らかな停止を引き起こすことなく、適用の一貫性を損なう可能性があります。このような状況でもシステムは動作し続けますが、安全性に問題が生じたり、パフォーマンスが低下したりする可能性があります。

性能が低下したシステムは、フェイルクローズではなくフェイルオープンになることが少なくありません。安全性分類器がタイムアウトして迂回されたり、検索ステップが意図した範囲より広い結果を返したり、レート制限が一貫して適用されなかったり、ポリシーチェックに失敗してもツールの呼び出しが続行されたりする可能性があります。複数のステップを連鎖させるエージェント型システムでは、小さな性能低下が連鎖し、後続の処理で安全でないアクションにつながる可能性があります。

レジリエンスは、単なるエンジニアリング上の品質ではなく、ガバナンス上の課題でもあります。理想的な条件下でしか機能しない制御は、制御とはいえません。セキュリティチームは、理想的でない条件下でAIセキュリティ制御がどのように動作するか、また障害を早期に検出し、予測可能な形で対処できるかを評価する必要があります。これには、処理量の急増や悪意のあるクエリパターンに対するストレステスト、

長いコンテキストでのやり取りや、IDプロバイダーの遅延、検索機能の停止、コネクターエラーなどの依存関係の障害も対象となります。

成熟したAIセキュリティプラットフォームには、攻撃モードだけでなく、障害モードの把握と管理にも役立つことが求められます。これには、安全なデフォルト設定、明確なエラー処理、サブシステムの機能低下時にも一貫した適用動作、さらに、ビジネス上の問題に発展する前にセキュリティチームが機能低下を認識できる運用テレメトリが含まれます。

ポリシーの精度とトレードオフの管理

技術的に有効であっても、運用に支障をきたすセキュリティ制御を持続させることは困難です。AI環境では、ポリシーの境界が二者択一ではなく、状況に応じて変わることが多いため、この相反関係が特に顕著になります。たとえば、同じリクエストでも、ある役割には正当と認められる一方、別の役割には禁止される場合があります。また、公開情報に基づく回答は許容されても、社内データに基づく回答は許容されない場合があります。最終的に「適切な」ポリシーを決定するのは、純粋な技術上の判断ではなく、ガバナンス上の判断です。

過度に制限的な制御は、正当な事業活動を妨げ、「シャドーAI」システムの利用を助長する可能性があります。一方、適用が不十分であれば、組織は法的リスクや評判リスクにさらされます。適切なバランスを取ることは、単なる調整作業ではなく、リスク許容度、ビジネス上の状況、説明責任の要件を踏まえたガバナンス上の意思決定でもあります。

AIセキュリティプラットフォームには、誤検知と見逃しを可視化し、判断の理由を説明するとともに、体系的な変更管理の下でポリシーを更新できる機能が必要です。システムがリクエストをブロックした場合、組織は、その理由が機密データの含有、命令の上書きの試みと見なされたこと、ユーザーに権限がなかったこと、または高リスクのパターンとの一致のいずれであるかを把握する必要があります。こうした明確性がなければ、チームは責任を持って制御を調整することも、経営陣や外部監査人に結果の妥当性を説明することもできません。

GRCの観点では、ポリシーの精度も成熟度を示す指標となります。不透明で予測できず、調整も不可能な制御は、効果的な監査や妥当性の説明ができないため、組織にとって負担となります。一方、調整可能であっても規律を欠く制御は、場当たり的な例外措置によって弱体化するおそれがあります。成熟したプラットフォームは、バージョン管理、承認、ロールに基づく適用、リスクが時間の経過とともに低減しているかを経営層が確認できるレポートなど、体系的なポリシー管理をサポートします。

セキュリティ上重要な意思決定のための決定論的検証

確率的AIガードレールは、ほとんどのポリシー違反を効果的に検出します。しかし、セキュリティ上極めて重要な意思決定の中には、統計的な信頼度ではなく、数学的な確実性が求められるものがあります。認可ポリシー、規制遵守の検証、セーフティクリティカルなインフラストラクチャの制御では、機械学習システムに内在する不確実性は許容されません。

自動推論は、形式検証の手法を用いて特定の制御ポイントの正しさを証明することで、確率的ガードレールを補完します。信頼度スコアを割り当てるMLベースの検出とは異なり、自動推論では、考えられるあらゆる条件下でポリシーが成立するかどうかを数学的に証明します。

決定論的検証は、次のような状況で重要です。

• 認可の判断：すべてのユーザーロールとデータ分類にわたり、アクセス制御ポリシーが正しく適用されていることを検証
• コンプライアンス検証：導入前に規制要件（GDPRのデータ所在地要件、HIPAAのアクセス制限）を満たしていることを証明
• セーフティクリティカルシステム：物理インフラや金融取引を制御するAIシステムが、安全上の制約に違反しないようにすること

組織は、検出で対応する制御と、証明が必要な制御を見極める必要があります。コンテンツフィルタリングや一般的なガードレールにはMLの柔軟性が有効ですが、認可の適用やコンプライアンス検証には形式検証による確実性が求められます。成熟したAIセキュリティプラットフォームは、広範な脅威をカバーする確率的検出と、決して失敗が許されない制御のための決定論的検証を統合しています。

組織は、証明が必要な制御と検出が必要な制御を見極める必要があります。コンテンツフィルタリングや一般的なガードレールにはMLの柔軟性が有効ですが、認可の適用やコンプライアンス検証には形式検証の確実性が求められます。成熟したAIセキュリティプラットフォームは、広範な脅威をカバーする確率的検出と、決して失敗が許されない制御のための決定論的検証という、両方のアプローチを統合しています。

エージェント型AIと委任された権限

AIシステムが受動的なアシスタントから組織のワークフローに能動的に関与する存在へと進化するにつれ、新たな種類のリスクが生じます。それが「権限委譲」です。エージェント型AIシステムは、外部ツールの起動、APIの呼び出し、レコードの変更、ワークフローのトリガーを自律的に実行できます。実質的には、幅広いアクセス権を持ち、高速に動作するデジタル従業員として機能します。

これは、なじみのない状況において、従来からあるガバナンス上の問題を提起します。システムには、どのような条件下で、どのような操作を実行する権限が与えられているのでしょうか。権限はどのように制限されているのでしょうか。権限昇格はどのように防止されているのでしょうか。職務分掌はどのように維持されているのでしょうか。自律性に明確な制限がなければ、小さなミスが複数のシステムに急速に波及する可能性があります。ユーザーの意図を誤って解釈したモデルが、誤った宛先にメールを送信したり、機密情報を含むチケットを作成したり、本来はレビューが必要な操作を承認したり、後続の運用に影響を及ぼすようなレコード変更を行ったりする可能性があります。

有効な制御では、最小権限を適用し、ツールの不正使用を防止するとともに、説明責任を確保する必要があります。具体的には、ツールの権限を明示的に管理すること、影響の大きいアクション（特にシステムの状態を変更するもの）を制限すること、中程度の影響を伴うアクション（外部向けの連絡内容を作成するが送信はしない、構成変更を提案するが適用はしない、データクエリを準備するが実行はしないなど）には確認を必須とすること、機密性の高い操作（財務記録の変更、アクセス権限の変更、特権インフラストラクチャコマンドの実行、組織を代表した外部への連絡の開始、取引の承認など）には人による承認を必須とすることが含まれます。また、個々には許可されている一連のアクションが、監督なしでは決して生じてはならない結果をもたらす「安全でない連鎖」を検出することも含まれます。

この機能を実践的に評価するには、システムが段階的な自律性を適用できるかを確認します。たとえば、無害なアクションは自由に許可し、中程度の影響を及ぼすアクションには確認を求め、影響の大きいアクションは禁止するか、上位の承認者に判断を委ねられるかを確認します。ガバナンス責任者は、エージェント型AIをモデルの問題ではなく、権限委譲の問題として捉える必要があります。若手従業員に特定のアクションを単独で実行する権限を与えないのであれば、AIエージェントにも与えるべきではありません。

オブザーバビリティ、監査、フォレンジック

AIシステムで問題が発生した場合、最も重要なのは単に何が起きたかではなく、それがどのように、なぜ起きたのかを組織が明確に示せるかどうかです。エンタープライズ環境では、問題について確かな証拠を提示できるかどうかが、説明して収束できるインシデントと、長期化するガバナンス上の問題に発展するインシデントを分けます。

十分な可視性がなければ、セキュリティチームはインシデントへの対応時に、不完全なログや推測、直感に頼らざるを得ません。ポリシーや制御の動作を事後に検証・測定できなければ、その有効性を実証したり、妥当性を説明したり、改善したりできないため、ガバナンスの取り組みに支障が生じます。これは、非決定性やコンテキストによって結果の再現が困難、場合によっては不可能になるAIシステムに特に当てはまります。

AIセキュリティプラットフォームには、詳細なログ記録、明確な帰属情報、適時のアラート通知が求められます。また、企業は、受信した入力、適用されたIDおよび認可のコンテキスト、取得したコンテンツ（該当する場合）、有効なシステム指示、モデルの出力、トリガーされたツールや後続処理を含め、AIとのやり取りをエンドツーエンドで再構築できる必要があります。制御機能がリクエストのブロック、出力の変更、アクションの防止などを行った場合は、その理由と適用したポリシーを記録する必要があります。

GRCの観点では、監査可能性が不可欠です。組織には、統制が整備され、意図したとおりに機能していたこと、例外が適切に処理されたこと、変更が継続的に追跡されていたことを実証することが求められます。

GRCを欠いたAIセキュリティが失敗する理由

AIシステムは、従来のガバナンスプロセスでは追いつけない速度と規模で稼働します。障害が発生した場合、組織は、統制、意図、説明責任を実証できるかどうかで評価されます。このような環境では、ガバナンス、リスク、コンプライアンスから切り離されたAIセキュリティは、構造的に脆弱です。

規制当局や取締役会は、リスクが特定されていたか、統制がリスクに見合っていたか、意思決定について説明できるかを確認する必要があります。意図のいかんにかかわらず、証拠を提示できないセキュリティチームは、その結果の正当性を主張することが困難になります。

GRC機能は、技術的な統制を、妥当性を説明できる企業慣行へと落とし込むうえで重要な役割を果たします。これには、許容される利用方法の定義、リスクに関する意思決定の文書化、統制の有効性の検証に加え、変更が継続的に追跡・レビューされ、監査可能な状態を確保することが含まれます。

まとめ：エンタープライズ規模でのAIガバナンス

AIはもはや周辺的なテクノロジーではありません。企業の業務運営、競争、意思決定のあり方を形作る中核インフラになりつつあります。

AIシステムがビジネス上重要なプロセスに組み込まれるようになる中、企業は実験段階から説明責任を果たす段階へと慎重に移行しなければなりません。そのためには、制約に関する透明性、独立した検証への対応、一度限りの保証ではなく継続的な改善への取り組みなど、AIセキュリティベンダーに求める要件をより明確にする必要があります。

説明責任を果たすには、社内の足並みをそろえることも必要です。セキュリティ、IT、法務、リスク管理、事業部門の関係者は、インシデントが発生する前に、リスク許容度、エスカレーション経路、対応戦略について合意しておく必要があります。AIセキュリティは単一のチームだけが担うものではなく、企業全体で共有すべき責任です。

AIで成功を収めるのは、イノベーションと規律を両立させる組織です。イノベーションだけでは持続的な優位性は生まれません。システムの拡大に伴うリスクを理解し、可視化する仕組みを整え、適切に管理することが、持続可能な成功につながります。効果的なAIセキュリティとは、不確実性を排除することではなく、透明性と責任をもって、検証に耐え得る方法で管理することです。

© 2026 NSS Labs. All rights reserved. NSS Labsの利用規約および著作権・引用ポリシーはこちらでご確認いただけます：https://nsslabs.com/terms-of-service/