組織が大規模言語モデル（LLM）の導入が進むにつれ、もはやモデルの回答は「どうすべきか」だけでは不十分です。多くの環境で求められるのは、自発的に適切な文脈を把握し、ワークフローのシステムと連携することです。これにはソースコードリポジトリ・SaaSツール・データベースおよび社内サービスなどが含まれます。今日における真の課題は、単純に応答するだけの品質からAIエージェントを安全に運用することへ移行しています。
モデルコンテキストプロトコル（MCP：Model Context Protocol）が登場する前は、ツールを統合するたびに個別の異なるカスタムAPIを構築するようなもので、さらに各LLMベンダーが使用するプラグインが異なることもありました。MCPはコネクタとメッセージ形式を標準化したため、ツールは機能を一度定義するだけで済むようになり、複数のモデルが同じ方法で利用できるようになりました。その結果、開発が加速してカスタマイズ統合の障壁が低減して長期的なメンテナンスコストも削減されたため、システム全体への採用が広まっています。
2024年11月にAnthropicによって公開およびオープンソース化されて以来、モデルコンテキストプロトコル（MCP）はAIエージェントとそれが依存するツール・API・データとの接続層として急速に定着しました。MCPのコアはLLM駆動型アプリケーションに対して外部システムとの通信における標準化方式を提供します。MCPは、LLMとエージェントプログラムが使用する外部システムの間に位置します。MCPはモデルがデータベース・SaaSアプリケーションまたは内部サービスに直接アクセスするのではなく、承認された機能をツールとして公開し、標準的な呼び出し規約を提供します。LLMはリクエストを理解し、次のアクションを決定することに重点を置きます。MCPはツールの検出・実行および結果報告を予測可能な形式で処理します。
モバイルデバイスと同様に、従業員はますます「個人利用のAIツールの持ち込み（BYOAI：Bring Your Own AI）」を行い、個人アカウントを通じてAIにアクセスするようになっています。これらのアカウントは企業のセキュリティ管理の範囲外で動作するため、企業データの保存・保管・処理方法に関する可視性のギャップがさらに拡大しています。その結果、「シャドーAI」が発生します。つまり、IT部門が承認したことがなく、セキュリティチームが監視できず、コンプライアンスチームが監査できないAIが、企業環境内で業務活動を行ってしまうのです。
しかし、各MCPサーバーとエージェントの間には新たな信頼境界が存在します。エージェントにあらゆるリソースへのアクセスを許可することは、同時に新たな攻撃対象領域を生み出すことにもなります。米国国家安全保障局（NSA：National Security Agency）を含むセキュリティ研究機関は、未認証サーバーや過度に広範なツールの権限およびツールレスポンスへのプロンプト注入など、MCPのセキュリティリスクを指摘しています。MCPのセキュリティはデフォルトで各サーバーを信頼できないものと見なし、その出所を検証してツールのアクセス権限を適切な範囲に制限、隔離して実行、さらに操作ログを記録して、明確なポリシーに基づいて展開を管理する必要があります。
モデル開発元やアーキテクチャを選択する前に情報セキュリティチームが抱く懸念
・プロンプトとして入力されるデータは何か
・内部システムからどのようなデータが抽出されたか
・モデル開発元へ提供するデータ
・ベクトルデータベースにはどのようなデータが埋め込まれているか
・どのようなデータが記録されているか
・データの保存期限
・どの地域で処理または保存されるか
・どのベンダーや下請け業者が関与しているか？
コンプライアンスおよびガバナンスの要件としてEUのAI法第12条を満たすために、高リスクAIシステムの運用者に対しては、事後のシステム監査のためにシステムの入力/出力ログを保持することが求められます。一般的なエンドポイントセキュリティやSIEMログツールあるいはOSのアプリケーションイベントログでは、この要件を満たすことはできません。これらは確かにAIサービスプロバイダーのエンドポイントへのHTTPSリクエストを記録しますが、リクエストの内容やレスポンスの内容は記録されず、その内容に機密データが含まれているかどうかも記録されません。
ガバナンスはポリシーの文書化から始まる
新しいMCPサーバーを承認できるのは誰か、どのような審査が必要か、各エージェント展開の部門責任者は誰なのか。所有権が明確でない状況では、開発者は一時的にサーバーをインストールしてしまい、セキュリティチームはインシデントが発生してから初めてその事実を把握することになります。シンプルに提案→審査→承認→展開というワークフローに基づいていれば、情報漏洩が発生する前にサプライチェーンリスクの大部分を低減できます。
リソースの分類
リソースデータを「公開/内部/機密/制限付き」に分類し、エージェントおよびそのMCPサーバーがどのカテゴリにアクセスできるかを決めます。必要に応じて保存場所の管理を行い、EUや米国の規制の対象となるデータは特定地域外のサーバーに流れたりそこを経由しないようにします。
開発環境とネットワーク
開発用ローカルサーバーが同一ホスト上で動作する場合、開発は簡単ですがファイルシステムやネットワークを共有するため、情報漏洩のリスクが高まります。SSRF（Server-Side Request Forgery）や権限昇格の経路を防ぐため、URIパラメータやネットワークリクエストに対して厳格な制限を設けます。
リモートサーバーは独立して動作し、認証も可能で監査も容易に行えます。認証済みのリモートサーバーは、ネットワークセグメンテーション・適切な範囲に限定した権限付与・出口制御および一元化されたログと組み合わせることで、管理しやすくなります。
データ保護の観点から見ると、これは従来のDLPがさらに進化しなければならないことを意味しています。データはUSBやメールを通じて漏洩するのではなく、RAG（検索拡張生成）によって抽出されてベクトルデータベースに組み込まれ、MCPツールを介してSaaSサービスに送信され、さらにはエージェントによって自動的に別のワークフローへ連携されてしまうと、データ漏洩の「出口」はユーザー→エージェント→MCP→ツールで構成される一連のデータチェーンとなります。企業が管理すべき対象は、この一連のデータフローにおけるデータへのアクセスと転送です。