2025.12.04

MCPの光と影｜AIエージェント実装で顕在化するセキュリティ課題と対策

AIエージェントと企業システムを標準的に接続するModel Context Protocol（MCP）は、データに閉じ込められたAIを解放する強力なインフラとして注目を集めています。しかし、その利便性の裏側では、組織の統制外で増殖する「シャドウMCPサーバ」や、過剰な権限を持つエージェントが既存のセキュリティ境界を静かに迂回するという新たなリスクが顕在化しつつあります。

本稿では、OWASPやMicrosoft、NISTなどの一次情報をもとに、MCPがもたらす「光」と「影」を分析し、経営層が今すべき対応策を提示します。真に対処すべき課題は「ガバナンス設計」にあることを論じます。

MCPがもたらす標準化という「光」

接続の断片化を解消する新しいインフラ

Anthropicが提唱するMCPは、AIアシスタントと企業システムを接続するためのオープン標準です[1]。従来、AIごとに個別のコネクタを開発する必要があったところを、単一のプロトコルで置き換えることで、スケーラブルで信頼性の高い接続を実現します。

この標準化により、CRM、ナレッジベース、Gitリポジトリなど複数のツールを横断しながら、AIエージェントがコンテキストを維持できるようになります。営業担当者が顧客情報を確認しながら、過去の提案資料を参照し、最新の在庫状況を把握するといった作業が、AIエージェントを通じてシームレスに実行できるのです。一度作成したMCPサーバは複数のエージェントから再利用できるため、開発生産性も大幅に向上します[1]。

企業内データ孤立の解消とビジネス価値

MCPは、AIエージェントが「認識」「推論」「行動」するための橋を標準化します[4]。カスタマーサポート部門では、顧客からの問い合わせに対してAIエージェントが過去の対応履歴、製品マニュアル、在庫データベースを横断的に検索し、最適な回答を即座に提示できます。製造業では、生産管理システム、品質管理データ、サプライチェーン情報を統合的に分析し、生産効率の改善提案をリアルタイムで行うことも可能です。こうした横断的なデータ活用は、これまで技術的ハードルが高く実現困難でしたが、MCPはこの障壁を大幅に下げます。

セキュリティの「影」── OWASPとMicrosoftが警告するリスク

統制外で増殖する「シャドウMCPサーバ」

OWASPが最も深刻なリスクとして挙げるのが、公式なガバナンスの外で立ち上げられる「シャドウMCPサーバ」です。これは、かつて問題となった「シャドウIT」のMCP版といえます。開発者が検証目的で勝手に立てたサーバが、デフォルト認証情報や緩い設定のまま放置されるケースが想定されます。便利さゆえに、組織の手続きを経ずにサーバを立てたくなる誘惑が強く、気づいたときには組織内に無数のシャドウサーバが乱立している可能性があります[2]。

過剰な権限付与による「権限膨張」

Microsoftは、MCPサーバへの過剰な権限付与を重大リスクと指摘します[3]。例えば、営業用アプリのMCPサーバに企業データストア全体へのアクセス権を与えてしまうケースです。AIの柔軟性を確保したいがゆえに、必要な権限の切り出しが難しく、結果として最小権限の原則が守られないことが多いのです。

当初は「営業データのみ」という限定的な権限だったはずが、いつの間にか人事情報や財務データにもアクセスできるようになる「スコープクリープ」が発生します[3]。一度付与した権限を後から削減することは困難なため、最初の設計段階で適切な権限設計を行うことが不可欠です。

トークン管理とコンテキスト過共有

ハードコードされた認証情報や長寿命トークンが、プロンプトインジェクションやデバッグトレースを通じて窃取されるリスクがあります[2]。また、タスクやユーザ間で本来隔離されるべき情報が漏れ出す「コンテキスト過共有」も警告されています。ある部署のプロジェクト情報が別の部署のエージェントセッションに漏れ出す、競合他社との交渉情報が社内の無関係な部門に可視化されてしまう、といったケースです。MCPの「文脈の利便性」が、そのままプライバシーと機密性のリスクに転化しているのです[2]。

認証・認可の未成熟さとツール汚染

初期のMCP実装の多くは、サーバ側で独自に認証ロジックを実装していたため、誤実装やトークン盗難のリスクが生じやすいとMicrosoftは指摘します[3]。さらに、MCPツールの説明文に埋め込まれた悪意のある指示が、ユーザには見えない形でAIモデルに解釈され、意図しない行動につながる「ツール汚染」攻撃も懸念されています[3]。これはサプライチェーン攻撃の新しい形態です。

リスクの本質は「ガバナンス設計」にある

プロトコルではなく運用が問題

OWASPとMicrosoftの分析を俯瞰すると、MCPにおける主要なリスクは暗号プロトコルや実装バグではなく、「誰が、どこで、どのようにサーバを立て、どんな権限を与えるのか」という統制の問題に集中しています[2][3]。これは技術部門だけでなく、経営層、IT部門、法務・コンプライアンス部門が一体となって取り組むべきガバナンスの課題です。Microsoftも「MCPはそれが構築される環境のセキュリティ姿勢をそのまま継承する」と指摘しており[3]、組織のセキュリティ文化そのものが問われています。

AIエージェント── 新しい「中間者」の挑戦

MCPを介したAIエージェントは、人間の代わりにGUIを操作し、サービスアカウントの代わりにAPIを叩くという特異的な存在です[4]。従来のセキュリティモデルでは、「人」には人としてのID管理、「サービス」にはサービスアカウントとしての管理が適用されていました。しかしMCPエージェントはその両方の性質を帯びつつ、どちらの枠にも収まりきりません。エージェントは人間のように「意図」を持ちながら、サービスのように24時間365日稼働し、大量の処理を高速で実行します。この特性を踏まえた新しいセキュリティフレームワークが必要です。

経営層が今すべき4つのアクション

1. MCPサーバの立ち上げ権限を制御対象に

「誰がMCPサーバを立てられるか」を明確に制御し、立ち上げをIT資産としての登録と紐づけます[2]。MCPサーバの申請・承認プロセスを確立し、承認されたサーバのみが組織内ネットワークで動作できるようにします。定期的な棚卸しを実施し、使われていないサーバや管理者不在のサーバを特定して廃止することも重要です。

2. エージェントを「第一級のID」として扱う

MCPサーバとエージェントに、人間ユーザと同じレベルでアイデンティティを割り当てます[3]。これにより、「誰が(どのエージェントが)、いつ、何をしたか」を追跡可能にし、エージェントのライフサイクル管理も厳格に行います。

3. 権限は「ツール単位」「データドメイン単位」で最小化

「とりあえずフルアクセス」を認めるのではなく、「どのユースケースに、どの権限が本当に必要か」という視点から設計します[2][3]。営業支援エージェントであれば、顧客情報と製品カタログへのアクセスのみを許可し、財務データや人事情報へのアクセスは明示的に禁止します。権限の定期的なレビューとクリーンアップも重要です。

4. コンテキストと監査を明示的に設計

「共有する単位」と「共有しない単位」を事前に決め、エージェントの行動を説明可能にするためのログと監査を設計します[2]。部門間、プロジェクト間でのコンテキスト共有ルールを明確にし、機密情報が意図せず漏洩しないようにします。すべてのエージェント操作を監査ログとして記録し、定期的にレビューする体制を整えます。

まとめ── 光を最大化し、影を最小化するために

MCPは企業システムとAIの接続を標準化し、データ孤立を解消する強力な変革のツールです。しかし、その利便性の裏側で、統制外のサーバや過剰な権限が既存のセキュリティ境界を静かに迂回するリスクが顕在化しています。

Microsoftのセキュリティレポートでは、サイバー侵害全体の98%は堅牢なセキュリティ衛生によって防げたとされており[3]、MCP特有のリスクの多くも、既存のセキュリティ原則の延長線上で対処可能です。必要なのは、明確なポリシーと一貫した運用です。

重要なのは、MCPを単なる技術的なブリッジとしてではなく、組織のID、権限、ゼロトラストアーキテクチャの一部として明示的に設計することです。経営層が「誰がMCPサーバを立てられるか」「エージェントにどの権限を与えるか」「コンテキストをどう管理するか」といった問いに、設計段階から真剣に向き合う必要があります。MCPの光を最大化し、影を最小化するための鍵は、プロトコルの改良ではなく、ガバナンスレイヤーの構築にあるのです。