MCPって盛り上がっているけど、うちで使えるんだっけ？適用すると効果がありそうな組織は？

はじめに

Model Context Protocol（MCP）は、Anthropic社が2024年11月に発表したオープンプロトコルです。LLMと外部データソースやツールの連携を標準化し、GitHub Copilot、Cursor、Claude Desktopなど主要なAI開発ツールが採用を進めています。

しかし、「社内で導入できるのか」という問いに答えるには、技術・セキュリティ・組織の各面で検討すべき課題があります。本記事では、エンタープライズ環境でのMCP導入時に直面する具体的なハードルを整理します。

1. 技術面のハードル

1.1 ネットワーク構成

MCP公式仕様（2025-11-25版）では、STDIO（標準入出力）とStreamable HTTP（HTTP+SSE）の2つのトランスポートが定義されています。STDIOは同一マシン上でのプロセス間通信、Streamable HTTPはリモートサーバーとの通信を想定します。どちらを採るかで、以下の課題が発生します。

ローカル実行（STDIO）の場合

開発者端末上でMCPサーバーを実行する方式です。ネットワーク経由の通信が最小化される一方で、端末ごとの設定・更新・監査の統制が課題になります。また、MCPサーバーが外部APIを呼び出す場合は、端末からの外向き通信をどう許可・記録するかがハードルになります。

リモート実行（Streamable HTTP）の場合

MCPサーバーをクラウドや社内ネットワーク上にホストし、複数の開発者で共有する方式です。集中管理ができる反面、認証・認可、通信経路の設計、ログの記録、単一障害点化への備えが必要になります。Microsoft Learnの公式サンプルではAzure FunctionsでリモートMCPサーバーを構築する方法が提供されていますが、企業環境では運用基盤やネットワーク境界に合わせた設計が求められます。

閉域網から外部APIへの接続

Context7のようなドキュメント検索MCPサーバーやWeb検索機能を使う場合、外部APIへの接続が必須です。閉域網環境では、プロキシやFQDNフィルタリングで許可するエンドポイントの制限等を検討する必要があります。

1.2 MCPサーバー作成時の既存システムとの連携

自社システムと連携するMCPサーバーを開発する場合、MCP公式SDKが各言語向けに提供されています。

Azure Functionsを使用する場合は、Python、Node.js、Javaなどの言語がサポートされています。

既存の社内APIやデータベースとの連携では、MCPサーバーがそれらのシステムへのアクセス権を持つことになるため、後述する認証・認可の設計が重要になります。

2. セキュリティ・ガバナンス面のハードル

2.1 セキュリティ対策

MCPサーバーの利用には、以下のセキュリティリスクへの対策が必要です。これらの攻撃手法は、Invariant Labs、Elastic Security Labs、SentinelOne、CyberArk Labsなどのセキュリティ研究機関によって報告されています。

Tool Poisoning（ツール汚染攻撃）

悪意のある命令をMCPツールのメタデータ（説明文、パラメータ定義など）に埋め込み、LLMの動作を操作する攻撃です。例えば、ツールの説明文に隠された悪意のある指示がLLMに読み取られ、意図しない動作を引き起こす可能性があります。

Rug Pull（ラグプル攻撃）

ユーザーがMCPサーバーを承認した後に、サーバー側でツールの定義や動作を悪意のあるものに変更する攻撃です。例えば、初回インストール時は正常に動作し、信頼を得た後にツールの説明文を悪意のあるものに差し替える手法が考えられます。

多くのMCPクライアントは、初回承認後にツール定義の変更を再度ユーザーに確認しないため、この攻撃は検出が困難です。

Cross-Server Tool Shadowing（クロスサーバーツールシャドウイング）

複数のMCPサーバーを同時に接続している環境で、悪意のあるサーバーが他の信頼済みサーバーのツール動作を操作する攻撃です。例えば、悪意のあるMCPサーバーのツール説明文に、他のサーバーのツールの使い方を上書きする指示を埋め込むことで、信頼済みツールの動作が汚染される可能性があります。

2.2 認証・認可の設計

認証（Authentication）

MCP公式仕様（2025-11-25版）では、OAuth 2.1ベースの認証フレームワークが定義されています。主なポイントは以下の通りです。

• HTTPベースのトランスポートを使用する実装は、この仕様に準拠すべき

• STDIOトランスポートを使用する実装は、この仕様に従わず、環境変数から認証情報を取得すべき

• MCPサーバーはOAuth 2.0 Protected Resource Metadata（RFC9728）を実装しなければならない

• 認可サーバーはOAuth 2.0 Authorization Server Metadata（RFC8414）またはOpenID Connect Discovery 1.0の少なくとも一方を提供しなければならない

認可（Authorization）

MCP公式仕様では、スコープベースの認可が定義されています。

• scopes_supportedフィールドでMCPサーバーがサポートするスコープを公開

• WWW-Authenticateヘッダーで必要なスコープを通知

• Step-up Authorization Flow（段階的な権限昇格）により、追加のスコープが必要な場合は再認可を要求

ただし、「何のツールにアクセスできるか」「何のデータにアクセスできるか」といった細かい粒度の認可は、MCP仕様レベルでは定義されておらず、実装者に委ねられています。

2.3 監査ログ・トレーサビリティの確保

MCPサーバーの利用状況を監査するには、以下のレベルでのログ取得が考えられます。

• MCPサーバーレベル: ツール呼び出しのリクエスト・レスポンス

• ホストアプリケーションレベル: どのユーザーがどのツールを呼び出したか

• 接続先システムレベル: MCPサーバー経由でアクセスされたデータ

MCP仕様レベルでは、監査ログの標準は定義されていないため、実装ごとに対応が必要です。

3. 組織・運用面のハードル

3.1 利用者へのオンボーディングと教育

MCPを導入する場合、実際に開発者に使用してもらうために、下記のような教育が必要になります。

MCPの基本概念の理解

MCPはLLMと外部システムを接続するプロトコルであり、Tools（ツール）、Resources（リソース）、Prompts（プロンプト）の3つのプリミティブで構成されます。開発者がこれらの概念を理解し、適切に活用できるようになる必要があります。

セキュリティ意識の向上

前述のTool Poisoning、Rug Pull、Cross-Server Tool Shadowingといった攻撃手法の存在を認識し、信頼できないMCPサーバーを接続しないこと、ツール実行時に確認プロンプトを無視しないことなど、セキュリティ上の注意点を周知する必要があります。

利用可能なMCPサーバーのガイダンス

社内で承認されたMCPサーバーの一覧、各MCPサーバーの用途と利用方法、問題発生時の連絡先などをドキュメント化し、開発者に提供する必要があります。

3.2 費用対効果の説明責任

MCPの導入効果を定量的に示すことは、現時点では難しい課題です。

MCPは2024年11月に発表されたばかりのプロトコルであり、導入事例の蓄積が十分ではありません。また、MCPの効果はLLMの活用全体の一部として現れるため、MCP単独の効果を切り分けることが困難です。

導入検討時には、以下のようなアプローチが考えられます。

• 小規模なパイロットプロジェクトで効果を検証してから全社展開

• 既存のAPI連携開発と比較した開発工数の削減見込みを試算

MCPが効果を発揮しやすい組織の特徴

これまでの分析を踏まえると、MCPの導入効果が出やすい組織には以下の特徴があると考えられます。

既にLLM活用を推進している組織

GitHub Copilot、Cursor、Claude等のAI開発ツールを既に導入・活用しており、それらのツールと社内システムの連携ニーズがある組織。MCPはこれらのツールが採用しているプロトコルであり、連携の標準化による恩恵を受けやすい状況にあります。

社内システムへのAPI基盤が整備されている組織

MCPサーバーは既存のAPIを呼び出す形で実装されることが多いため、社内システムがAPI化されている組織ではMCPサーバーの開発が容易になります。

セキュリティ・ガバナンス体制が整っている組織

MCPの導入には認証・認可の設計、監査ログの整備、開発者教育などが必要です。これらを推進できるセキュリティ・ガバナンス体制が既に存在する組織では、スムーズな導入が期待できます。

まとめ

MCPは、LLMと外部システムの連携を標準化するプロトコルとして注目を集めています。しかし、エンタープライズ環境での導入には、ネットワーク構成、セキュリティ対策、認証・認可設計、監査ログ、利用者教育、費用対効果など、多くの観点からの検討が必要です。

特にセキュリティ面では、Tool Poisoning、Rug Pull、Cross-Server Tool Shadowingといった新しい攻撃手法への対策が求められます。MCP公式仕様でも「ツールのアノテーションは信頼できるサーバーからでない限り信頼すべきではない」と明記されており、信頼できるMCPサーバーのみを利用する運用が重要です。

認証・認可については、MCP公式仕様（2025-11-25版）でOAuth 2.1ベースのフレームワークが定義されており、Azure環境ではMicrosoft Entra ID連携やAzure API Managementによる認証・認可の実装が可能です。

導入を検討する際は、小規模なパイロットプロジェクトから開始し、効果とリスクを検証しながら段階的に展開することをお勧めします。

参考文献

• Model Context Protocol Specification (2025-11-25): https://modelcontextprotocol.io/specification/2025-11-25

• Authorization - Model Context Protocol: https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization

• Tools - Model Context Protocol: https://modelcontextprotocol.io/specification/2025-06-18/server/tools