AIの挙動を監視することとガバナンスを行うことは同じではありません

Anthropicは今週、大きな発表を行いました。Claude Enterpriseが新しいClaude Compliance APIを通じて28のセキュリティおよびコンプライアンスパートナーと連携し、エンタープライズのセキュリティチームが会話内容、アップロードされたファイル、AIアクティビティイベントにプログラムでアクセスできるようになりました。これにより、既存のDLP、CASB、SIEM、電子証拠開示（eDiscovery）ツールと連携し、企業の技術スタックに組み込むことが可能です。

この発表が市場に与えるインパクトは、製品自体以上に重要です。AnthropicがコンプライアンスAPIを構築したのは、エンタープライズ顧客からの強い要望があるからです。KPMGの2025年AIガバナンス調査によると、企業の62%が「ガバナンス機能の不足」を機密性の高い業務プロセスでAI活用を拡大できない主な障壁として挙げています。企業はもはや、ガバナンス基盤なしに機密性の高いワークフローへAIを導入することを許容しなくなっています。それは正しい本能です。ここで問うべきは、「AIの行動を事後的に記録するガバナンス基盤」と「AIへのアクセスを事前に制御するガバナンス基盤」が同じものかどうか、という点です。

両者は異なり、この違いは規制業界にとって極めて重要です。

5つの重要ポイント

1. ClaudeのCompliance APIはエンタープライズAIにとって大きな前進

AnthropicのClaude Compliance APIは、Cloudflare、CrowdStrike、Microsoft Purview、Varonis、Wiz、Relativity、Datadogなど21社を含む28のエンタープライズセキュリティパートナーと連携し、規制対象企業に対して会話ログ、アップロードファイル、AIアクティビティイベントへのプログラムによるアクセスを提供します。これにより、既存のDLP、CASB、SIEM、電子証拠開示（eDiscovery）スタックにデータを取り込むことができます。これは、従来構造化されAPI経由でアクセスできる形では存在しなかった有意義な機能です。そしてこの市場へのメッセージは製品と同じくらい重要です。企業は機密性の高いワークフローへAIを拡大する前に、AIガバナンス基盤を求めています。

2. すべての連携は会話が終わった後に動作する

28のCompliance API連携はすべて事後的に動作し、このツールはガバナンスシステムではなく監視システムとなります。何が起きたかを記録するだけで、起きてはいけなかったことを防ぐことはできません。データは処理され、コンテンツはモデルに送信され、会話は成立します。APIは記録を作成しますが、結果を変えることはありません。規制対象コンテンツにおいて、この違いは単なるニュアンスではありません。これは、探知的コントロールと予防的コントロールの違いです。

3. アラートが発動する前に機密データがモデルに到達する

Compliance APIを完全に有効化したClaude Enterpriseを使う従業員は、CUIを貼り付けたり、PHIを添付したり、ITAR管理データを会話に入力したりできます。APIはそのアクティビティを記録しますが、ブロックはしません。モデル前のガバナンスレイヤーであれば、セッションに入る前にコンテンツをブロックできます。多くの規制フレームワークでは、アクセス制御が主要なコントロールとして求められており、規制データへの不正アクセスを記録するだけでは、不正アクセスの防止にはなりません。

4. ガバナンスのギャップは企業全体に存在し、ベンダー固有ではない

Kiteworks 2026年予測によると、組織の63%がAIエージェントの目的制限を強制できず、60%が不正動作するAIシステムを停止できず、AIガバナンスポリシーを完全に統合しているのはわずか18%です。Anthropicの発表は市場のギャップが現実であることを裏付けますが、それを解消するものではありません。これらは監視のギャップではなく、コントロールのギャップであり、より高度な監査証跡では解決できません。

5. モデル前コントロールが新たな規制ガバナンス標準を定義する

CMMCレベル2では「CUIへのアクセスを制御する」ことが求められており、アクセス制御こそが重要なフレーズです。HIPAAの技術的セーフガードでは「アクセス権を付与された者やソフトウェアプログラムのみがアクセスできるようにする」ポリシーの実装が義務付けられています。規制対象エンタープライズAIのコンプライアンス標準は、事後的な監視だけでなく、モデル前のコンテンツコントロールを要求することになるでしょう。CISOにとっての課題は、その標準に今から対応するのか、それとも規制当局の指摘を受けてから後付けで対応するのか、という点です。

事後監視の構造的限界

設計上、Compliance APIが解決できない構造的な限界があります。それは、28の連携すべてが会話終了後に動作するという点です。データは処理され、コンテンツはモデルに送信され、会話は成立します。Compliance APIは「何が起きたか」を記録しますが、「何が起きたか」を変えることはできません。

成熟したエンタープライズセキュリティアーキテクチャにおけるデータガバナンスの仕組みを考えてみてください。DLPシステムは、従業員が機密文書を個人アカウントにメール送信したことを記録するだけでなく、送信自体を防止します。コンテンツファイアウォールは、転送されたファイルを記録するだけでなく、転送時点でアクセス制御ポリシーを強制します。メール、ファイル転送、コラボレーションプラットフォームで実証されてきた有効なアーキテクチャは、「まず防止、次に記録」というモデルです。Compliance APIはAIに対して「まず記録、次にアラート」というモデルを適用しています。

これは価値がありますが、アーキテクチャ的には防止とは異なります。規制対象コンテンツ（CUI、PHI、ITAR管理データ、弁護士・依頼人間の特権情報など）に関しては、規制フレームワークは主要なコントロールとして「記録とアラート」モデルを認めていません。アクセス制御が求められます。規制データへの不正アクセスを記録するだけでは、不正アクセスの防止にはなりません。

Compliance APIが検知する前に起こりうること

Compliance APIを完全に有効化・設定したClaude Enterpriseを使う従業員は、管理対象の非分類文書のテキストを会話プロンプトに貼り付けたり、保護対象保健情報（PHI）を含むファイルをClaudeタスクの文脈として添付したり、ITAR管理の技術仕様をチャットメッセージに入力したり、他システムでアクセス可能な機密性の高い財務データセットについてClaudeに問い合わせたりできます。

これらのケースでは、Compliance APIはアクティビティを記録します。下流で適切なDLPルールが設定されていれば、アラートが発動します。しかし、起こらないこともあります。コンテンツがClaudeに届くのをブロックすることはできません。会話自体も防止されません。データはモデルに入る前のアクセス制御境界で止められることはありません。Compliance APIは露出を記録しますが、防止はしません。

規制業界のセキュリティチームにとって、これは重要です。なぜなら、多くの規制フレームワークは探知的コントロールだけでなく予防的コントロールを求めているからです。CMMCレベル2では「CUIへのアクセス制御」が求められ、HIPAAの技術的セーフガード要件では「アクセス権を付与された者やソフトウェアプログラムのみがアクセスできるようにする」ポリシーの実装が義務付けられています。求められるのはアクセスの記録ではなく、アクセスの制御です。

モデル前ガバナンスレイヤー：異なるアーキテクチャ

モデル前ガバナンスレイヤーは、根本的に異なる原則に基づいて動作します。AIセッションが始まる前に、どのコンテンツが入力として許可されるかを判断します。コントロールロジックは、ユーザーのIDと役割、リクエストされたコンテンツの分類、特定のAIユースケースや目的、そのコンテンツに適用されるコンプライアンスフレームワークに基づいています。ユーザーがAIセッションを開始すると、ガバナンスレイヤーはこれらの要素を明確なポリシーに照らして評価し、特定のコンテンツをセッションに入れるか、制限するか、ブロックするかを決定します。

Kiteworks Secure MCP Serverは、エンタープライズデータシステムとAIモデル（Claudeを含む）の間に位置し、インターフェースでコンテンツガバナンスポリシーを強制します。ユーザーの役割、セッションの目的、コンテンツの分類が明確なポリシー要件をすべて満たした場合のみ、機密コンテンツはAIセッションで利用可能となります。監査記録には、アクセスされたコンテンツだけでなく、リクエストされたものやブロックされたものも記録されます。AI Data Gatewayは、同じガバナンスをRAGパイプラインや自動化ワークフローにも拡張します。すべてのリクエストは認証され、属性ベースアクセス制御（ABAC）で認可され、改ざん検知可能な監査証跡に記録されます。すべてのデータ経路はFIPS 140-3認証済み暗号化で保護されます。

このアーキテクチャにより、規制対象企業は防衛調達、医療業務、金融アドバイザリーなどの機密性の高いワークフローにもAIアクセスを拡張できます。事後監視では記録しかできないコンプライアンスリスクを、未然に防ぐことが可能です。Kiteworks Private Data Networkは、メール、ファイル共有、マネージドファイル転送（MFT）、SFTP、Webフォーム、APIまで、1つのポリシーエンジンと統合監査ログで一元管理します。

規制対象エンタープライズAI導入への意味

エンタープライズAIプラットフォームを評価するセキュリティ・コンプライアンス責任者は、すべてのベンダーに「従業員がコンプライアンスレイヤーが検知する前に制限コンテンツをモデルに送信した場合、どうなりますか？」と質問すべきです。

「記録してアラートを出します」という答えなら、それは監視システムです。これはフォレンジック、インシデント対応、監査記録には有用ですが、機密データに関する多くの規制フレームワークが求めるアクセス制御要件を満たしません。「防止します」という答えなら、それはガバナンスシステムです。この違いが、AI導入が規制義務に準拠しているか、事後的に非準拠として記録されるだけかを決定します。

コンプライアンスフレームワークは、時間とともに最も保護的な解釈へと進化します。クラウドストレージ、モバイルデバイス管理、セキュアメールでも同じパターンが見られ、ガバナンス標準は検知・記録から防止・アクセス制御へと成熟してきました。AIも同じ道をたどっています。今から成熟した標準を見据えてアーキテクチャを設計し、AIモデルがアクセスできる機密コンテンツを制御するモデル前ガバナンスレイヤーを構築する組織は、規制ガイダンスが技術に追いついたとき、最小限の後付けコストで対応できます。

AIワークフローのガバナンスについて詳しく知りたい方は、カスタムデモを今すぐご予約ください。

追加リソース

• ブログ記事
  ゼロトラスト戦略で実現する手頃なAIプライバシー保護
• ブログ記事
  77%の組織がAIデータセキュリティで失敗している理由
• eBook
  AIガバナンスギャップ：2025年に91%の中小企業がデータセキュリティでロシアンルーレットをしている理由
• ブログ記事
  あなたのデータに「–dangerously-skip-permissions」は存在しません
• ブログ記事
  規制当局は「AIポリシーがあるか」ではなく「機能している証拠」を求めている