あなたのデータとAIエージェントをつなぐ:見過ごされがちなガバナンスの盲点
現在AIエージェントを導入しているすべての組織は、しばしば自覚のないまま、同じ実験を行っています。それは、人間のように疲れたり迷ったりせず、素早く読み取り、迅速に行動できる新しいタイプのアクターに、機密データを保持するシステムへのアクセス権を与えることです。このアクセスこそがエージェントを有用にしています。AIエージェントがファイルや記録、社内ドキュメントを読めなければ、それらを要約したり、アクションを起こしたり、チームの業務を加速させたりすることはできません。
しかし、エージェントを価値あるものにしている同じアクセスが、組織が長年かけてコントロールを構築してきたデータへの新たな、そしてほとんど管理されていない経路にもなっています。これは深刻な問題です。なぜなら、セキュリティチームが長年培ってきたアクセスレビューの習慣は、接続先の相手が人間であることを前提としているからです。人間ならトレーニングができ、アカウントの不審な行動を監視でき、少なくともある程度は判断力や組織の規範に縛られます。AIエージェントにはこうした制約がなく、広範かつ無制限なアクセス権を持つエージェントは、誰も明確に許可を出していないにもかかわらず、どの従業員よりも多くの情報を読み取り、アクションを起こすことができてしまいます。
この記事を読み終える頃には、なぜAIエージェントの接続も他のAPIと同じレベルの精査が必要なのか、MCPのようなプロトコルが新しい技術カテゴリに見えてもその事実は変わらない理由、そしてKiteworksが既存のポリシー主導型ガバナンス(セキュアなMCPサーバーを含む)をAIエージェントのアクセスに適用し、例外扱いしない理由が理解できるはずです。
エグゼクティブサマリー
エンタープライズのチームは、AIエージェントやコーディングアシスタントを社内システムに迅速に接続していますが、その多くは他の統合を支えるAPIやMCPのようなプロトコルを通じて行われています。この接続がAIエージェントを有用にしていますが、同時にその接続が付与するアクセス権をエージェントが機械的なスピードで引き継ぎ、同じアクセス権を人間が得る場合よりも人の目によるレビューが少なくなりがちです。
本記事では、AIエージェントが管理されていない形で機密データにアクセスした場合に何が問題となるのか、そしてKiteworksがポリシー主導かつ監査可能なアクセス制御をAIエージェントの接続(自社のMCPサーバーを含む)にも拡張し、エージェントをガバナンスを回避する特別扱いにしない理由を解説します。
主なポイント
- データにアクセスできるAIエージェントは、人間と同じ範囲に手が届きますが、同じ判断力はありません。 役割外のデータへのアクセスを止めるためのアクセス制御は、その人の代理として行動するエージェントにも厳格に適用する必要があります。エージェントは、リクエストが意図を超えていることを自律的に認識できないためです。
- AIエージェントのスピードは諸刃の剣です。 エージェントに企業データを素早く読ませ、要約させ、アクションさせる効率性は、接続範囲が広すぎると危険にもなります。ミスや逸脱も高速で発生し、人間のレビュー担当者が気づくより早く問題が起こることもあります。
- MCPや類似プロトコルもAPIであり、同様のセキュリティが必要です。 AIクライアントをMCPのようなプロトコルで社内システムに接続する場合でも、認証・暗号化・アクセス制御は必須です。単にAPIの呼び出し元が変わるだけで、セキュリティ要件は変わりません。
- 管理されていないAIアクセスは、セキュリティだけでなくコンプライアンスの問題です。 AIエージェントが規制対象データにアクセスできる場合、組織は人間ユーザーと同様に、何にどのポリシーでアクセスしたかを証明できなければ、監査上のリスクが他の監視されていないアクセス経路と同様に発生します。
- Kiteworksは、AIエージェントの接続にも他の統合と同じポリシー主導型コントロールを適用します。 Kiteworks MCPサーバーをClaude Desktopや他のAIクライアントに接続するためのインストール・設定ガイドは、他のAPIプラットフォームと同じ認証・暗号化・Data Policy Engineガバナンスに基づいています。
AIエージェントがアクセスの前提を変える理由
AIエージェントをエンタープライズデータに接続することは、他のアプリケーションを接続する場合と異なります。その理由は、エージェントに与えられる役割の広さにあります。従来の統合は「このファイルを移動する」「このレコードを同期する」「このフィールドを更新する」など、明確で限定的なアクションを実行します。AIエージェントは、システム横断的にデータを読み取り、要約し、タスクに関連する内容を自ら判断して次のアクションを起こすなど、より広範な裁量を与えられることが多く、これこそがオープンエンドな業務に役立つ理由です。
この柔軟性こそがAIエージェントの有用性であり、同時にアクセス権の精査が必要な理由です。共有フォルダーへのアクセスを持つ人間は、判断力やトレーニング、手作業の手間などの制約があり、実際に触れるデータ量は自然と限定されます。しかし、同じフォルダーに接続されたエージェントは、その中身を一度にすべて読み取り、意図していなくても見つけたものに対して即座にアクションを起こせます。アクセス権の範囲やガバナンスが適切に設定されていなければ、エージェントの効率性が過剰露出の引き金となり、利便性が誰も意図しないうちにリスクへと転化してしまいます。
自社のセキュリティ、信じていますか?証明できますか?
Read Now
MCPはAPIであることに変わりない
現在のAIエージェント接続の多くは、Model Context Protocol(MCP)のようなプロトコルを介して行われています。これにより、Claude DesktopのようなAIクライアントがサーバー上のツールを発見し、呼び出すことができます。これは従来のAPIとは異なる新しい接続形態であり、AIを中心に据えているため、従来のAPIほど厳密な精査が不要だと考えがちです。しかし、構造的にはMCPサーバーもAPIです。呼び出し元の認証、定義済みアクションの公開、データの返却という流れは同じです。つまり、他のAPIに適用される問いはすべてここにも当てはまります。呼び出し元は適切に認証されているか?アクセス範囲はエージェントが本当に必要とする範囲に限定されているか?すべての呼び出しが監査に耐えうる形で記録されているか?データは転送中・保存中ともに暗号化されているか?
MCP接続を、呼び出し元がAIクライアントだからという理由でこうした問いから免除してしまうと、結果的にどの従業員よりも広範なアクセス権を持つエージェントが、何をしたかの記録も残らないまま運用される事態を招きます。このギャップは、AIツールが新しい機能として個々のチームに素早く導入され、セキュリティレビューが追いつく前に広まることで、特に見過ごされがちです。
KiteworksによるAIエージェントアクセスのガバナンス
KiteworksのDeveloper Portalには、Kiteworks MCPサーバーをClaude Desktopや他のAIクライアントに接続するためのインストール・設定ガイドが用意されており、他のAPIプラットフォームと同じ基盤の上に構築されています。つまり、AIエージェントがMCP経由でKiteworksに接続する際も、他の統合と同様にOAuth 2.0やJWT Assertionによる認証を行い、Data Policy Engineによるきめ細かなアクセス制御、暗号化、監査ログ管理の対象となります。
実際には、AIエージェントをKiteworks環境に接続する場合でも、エージェント専用の緩い経路で機密データにアクセスさせることにはなりません。エージェントは人間ユーザーと同じポリシーの枠内で動作し、同じ監査可能なアクティビティログを生成し、多層防御、強化された仮想アプライアンス、組み込みファイアウォールとWAF、アシュームブリーチアーキテクチャなど、プラットフォーム上の他のAPIコールと同じ保護を受けます。エージェントの接続範囲が特定のフォルダーやロールに限定されていれば、人間ユーザーと同様に、その範囲を超えてアクセスすることはできません。
データのコントロールを失わずにAIエージェントを接続
AIエージェントは、チームがエンタープライズデータとやり取りする際の標準的な存在になりつつあります。そのアクセスにも、他の統合と同じガバナンスが必要であり、「新しい技術だから」と例外扱いするべきではありません。Kiteworksは、MCPサーバーを含むAIエージェント接続にも、他のプラットフォーム同様のポリシー主導・監査対応のコントロールを適用し、安全で文書化された経路を提供します。
つまり、すべてのエージェント接続はOAuth 2.0またはJWT Assertionによる認証を経て、Data Policy Engineのきめ細かなロールベースアクセス制御を継承し、スコープ内のデータだけにアクセス可能となります。また、他のアクションと同じ中央集約型の監査対応アクティビティログを生成し、強化された仮想アプライアンス、組み込みファイアウォールとWAF、アシュームブリーチアーキテクチャの背後で保護されます。これにより、組織はClaude Desktopのようなエージェントをデータに接続する生産性向上の恩恵を受けつつ、新たな管理されていないアクセスカテゴリを許容することなく運用できます。KiteworksセキュアAPIプラットフォームを探索するか、Developer PortalでAIエージェントのセットアップガイドをご覧ください。
よくあるご質問
他のAPI統合と同様に、接続が認証され、スコープ設定され、暗号化され、ログ記録されていれば安全です。KiteworksのMCPサーバーは、Data Policy Engineによるガバナンスと多層防御を含むセキュアAPIプラットフォーム全体と同じ仕組みで接続されるため、AIエージェントのアクセスも人間ユーザーと同じポリシー制限の下で管理されます。
MCPは、Claude DesktopのようなAIクライアントがサーバー上のツールを発見し、呼び出すことを可能にするプロトコルです。構造的には他のAPIと同様に、呼び出し元の認証や定義済みアクションの公開を行うため、どんなに新しい技術であっても、同じレベルの認証・暗号化・アクセス制御が必要です。
はい。アクセス制御・認証・監査ログがプラットフォームレベルで強制され、各統合ごとに任せるのではなく一元管理されている場合、AIエージェントにも同じ制御が適用できます。Kiteworksは、Data Policy EngineによるガバナンスをAIエージェントの接続にも適用しているため、エージェントのアクセス範囲も明確にスコープ設定されます。
Kiteworks Developer Portalでは、Kiteworks MCPサーバーをClaude Desktopや他のAIクライアントに接続するためのインストール・設定ガイドを提供しています。これらは他のAPIプラットフォームと同じOAuth 2.0やJWT認証フローを利用するため、AIアクセス専用のセキュリティモデルを新たに設計する必要はありません。
組織がエージェントのアクセス内容や適用ポリシーを証明できない場合、リスクとなります。Kiteworksは、AIエージェントのアクティビティも他の統合と同様に監査対応・Data Policy Engineガバナンスのもとでログ記録するため、そのアクセスは監査人や規制当局にも証明可能であり、AI特有のツールにありがちなギャップを埋めます。
追加リソース
- ブログ記事 ゼロトラストアーキテクチャ:決して信頼せず、常に検証せよ
- 動画 Microsoft GCC High:防衛請負業者がよりスマートな優位性を求める理由
- ブログ記事 DSPMで機密データが検知された後のセキュリティ対策
- ブログ記事 ゼロトラストアプローチで生成AIの信頼性を構築する方法
- 動画 ITリーダーのための機密データ安全保管ガイド決定版