テクノロジー

MCPを超えてMCPSへ：エンタープライズAIのためのセキュアプロトコルの必要性

Brant Hwang
CEO, Founder
Brantはコンピュータサイエンスの修士号を取得後、ソフトウェア分野で17年以上の経験を持つQueryPieの創設者兼CEOです。エンタープライズソフトウェア、組み込みシステム、インターネットポータル、コマースプラットフォームなど、様々な分野での経験を積み、起業前にはKakaoでプラットフォーム開発に携わりました。

2025年4月30日

MCPを超えてMCPSへ：エンタープライズAIのためのセキュアプロトコルの必要性

はじめに：革新的なMCP、しかしエンタープライズには不十分

最近、人工知能（AI）分野では、モデルコンテキストプロトコル（Model Context Protocol, MCP）が注目を集めています。[1] MCPは、AIアシストとデータが存在するシステム（コンテンツストア、ビジネスツール、開発環境など）を繋ぐ新しいオープンスタンダードであり、AIモデルがより正確で関連性の高いレスポンスを生成することを目的としています。[1] マジックなどのさまざまな周辺機器を標準化された方法で繋ぐUSB-Cポートのように、MCPはAIモデルをさまざまなデータソースやツールに繋ぐ標準化された方法を提供し、「AIのためのUSB-C」としても知られています。[4] すでにBlock、Apollo、Zapier、Cursorなど、多くの企業と開発ツールがMCPを導入して生態系を拡張しています。[1]

MCPアーキテクチャの概要

しかし、この革新的なMCPには、エンタープライズ環境での利用には致命的な欠点があります。それはセキュリティ機能の欠如です。現在のMCPは、はじめのHTTPのように、認証、権限付与、データ暗号化、監査ログなど、企業環境で不可欠なセキュリティメカニズムをプロトコルレベルで提供していません。これは、機密性の高いデータを扱い、厳格な規制遵守が要求されるエンタープライズ環境でMCP導入を躊躇させる最も大きな障壁です。

この記事では、MCPの基本的な概念と現在の状況を紹介し、エンタープライズ環境で発生するセキュリティ上の課題について深く分析します。そして、Web通信の標準であるHTTPSの発展過程を教訓として、MCPのセキュリティ強化のための仮想的なプロトコル、MCPS（Secured Model Context Protocol）の必要性と実現方法、そして予想される効果と課題について議論したいと思います。

MCP深層分析：概念、構造、現状

MCPは、AIアプリケーション（チャットボット、IDEアシスト、カスタムエージェントなど）が外部ツール、データソース、システムと相互作用する方法を標準化するために、Anthropicが提案したオープンスタンダードです。[1] 従来のフラグメント化された連携方法を単一のプロトコルに置き換えることにより、開発者は各データソースごとに別個のコネクタを維持する必要がなくなり、標準プロトコルに従って開発できるようになります。[1]

MCPの動作方法

MCPはクライアント-サーバーアーキテクチャに従います。[2]

ホスト: ユーザーが相互作用するアプリケーション（例：Claude Desktop、Cursor IDE、カスタムエージェント）。[2] 複数のクライアントインスタンスを管理し、セキュリティポリシー（権限、ユーザー同意）を担当します。[3]
クライアント: ホストアプリケーション内に存在し、特定のMCPサーバーとの1:1の連携を管理します。[2]
サーバー: 特定の外部システム（API、データベース、ローカルファイルなど）の機能をMCP仕様に従って公開する軽量プログラムです。[2] Python、TypeScriptなど、さまざまな言語で実装可能です。[1]

MCPサーバーは、クライアントと主に2つの送信方法（Transport）を通じて通信します[2]:

stdio（Standard Input/Output）: クライアントとサーバーが同じマシン上で実行されるときに使用されます。ローカル統合（例：ローカルファイルへのアクセス）は簡単で効果的です。[2]
HTTP + SSE（Server-Sent Events）: クライアントがHTTPを介してサーバーに接続します。初期設定後、サーバーはSSE標準を使用して、クライアントにメッセージ（イベント）をプッシュできます。[2]

MCPは3つの主要機能（Primitives）を定義します[2]:

ツール: LLMが特定の作業を実行するために呼び出すことができる関数（モデル制御）。天気APIの呼び出しなど、関数呼び出しと似ています。[2]
リソース: LLMがアクセスできるデータソース（アプリケーション制御）。REST APIのGETエンドポイントと似ていますが、副作用なしでデータを提供します。[2]
プロンプト: ツールやリソースを最適化するために事前に定義されたテンプレート（ユーザー制御）。[2]

MCPは、検証された技術である言語サーバープロトコル（LSP）とJSON-RPC 2.0に基づいて構築されており、詳細な仕様を提供するオープンスタンダードです。[1] Block、Apollo、Zed、Replit、Codeium、Sourcegraph、Zapier、Cursor、Claude Desktopなど、さまざまな企業とツールがMCPを採用して生態系を拡張しています。[1] しかし、まだ開発初期段階であり、一部の機能（例：Cursorでのリソースのサポートなし）は完全に実装されていません。プロトコル自体が活発に開発中です。[12]

このようなMCPの設計は、セキュリティの観点から重要なシグナルポイントを持っています。

1つ目は、機能（Primitives）に対する制御主体が異なることです。[2] モデルが制御する「ツール」は、予測不可能なLLMによって実行される可能性があるため、最も高いセキュリティリスクを持ち、厳格な管理が必要です。[13] 一方、アプリケーションが制御する「リソース」は、主にデータ提供の目的があり、相対的にリスクは低いが、データプライバシーの問題を引き起こす可能性があります。[13] ユーザーが制御する「プロンプト」は、また別の信頼レベルを持っています。したがって、安全なMCPSは、これらの機能間の違いを認識し、それぞれ異なるセキュリティポリシー（例：ツールに対する厳格な承認、リソースに対するデータマスキング/フィルタリング）を適用する必要があります。

2つ目は、送信方法（stdio vs. SSE）の選択がプロトコル自体に完全に扱われていない直接的なセキュリティ影響を与えることです。 stdioはローカル環境内での通信を意味するため、比較的信頼境界が明確ですが[2]、HTTP+SSEはネットワーク境界を越えているため、本質的により強力なセキュリティが必要です。[2] 現在のMCP仕様は、メッセージング形式（JSON-RPC）しか定義していないため[13]、HTTP+SSEサーバーは外部セキュリティ対策（例：TLSをサポートするリバースプロキシ[14]）なしでは、ネットワーク上に暗号化されたり認証されたりするリスクがあります。MCPSは特にHTTP+SSE送信セキュリティを優先的に解決する必要があります。

3つ目は、MCPが標準化を目的とするが[1]、まだ開発中であり、一部の機能のサポートが不十分であること[12]は、セキュリティ標準化を考慮する前に、すでに潜在的なフラグメント化と相互運用性の問題を含んでいることを示唆しています。「AIのためのUSB-C」というビジョン[4]を達成するためには、セキュリティ標準化だけでなく、すべての主要なプロトコル機能の一貫した実装とサポートが生態系全体に必要です。MCPSは、このような進化する環境を考慮して設計する必要があります。

部屋の中の象（明らかにある大きな問題を見て見ぬふりする状況）：エンタープライズ環境におけるMCPのセキュリティ脆弱性

MCP仕様自体も、任意のデータアクセスとコード実行によるセキュリティ上の問題を認識しています。[13] しかし、明示的にプロトコルレベルでセキュリティ原則を強制していないため、ホスト、クライアント、サーバー開発者などの実装者（implementor）は、安全なアプリケーションを構築する責任があると明示しています。[13]

仕様で推奨される主要なセキュリティ原則は次のとおりです。[13] しかし、これは強制義務（MUST）ではなく、推奨レベル（SHOULD）です。

ユーザー同意と制御: ユーザーは、すべてのデータアクセスと作業について、明示的に同意し、理解する必要があり、共有されるデータと実行される作業についての管理権を維持する必要があります。明確なUI提供が推奨されます。
データプライバシー: ホストは、サーバーにユーザーデータを公開する前に、明示的なユーザー同意を得る必要があり、同意なしでリソースデータを他の場所に送信してはなりません。適切なアクセス制御が必要です。
ツールの安全性: ツールは任意のコード実行を意味するため、慎重に扱う必要があります。信頼できないサーバーから得たツールの説明は、信頼できないものとみなす必要があります。ホストは、ツールを呼び出す前に、明示的なユーザー同意を得る必要があります。
LLMサンプリング制御: ユーザーは、すべてのLLMサンプリングリクエストを明示的に承認する必要があり、プロンプトと結果の可視性を制御する必要があります。これらの推奨事項にもかかわらず、エンタープライズ環境では、次のようなセキュリティ機能がプロトコルレベルで不足しています。

MCPのセキュリティが実装されていない場合に発生する主な脆弱性

認証（Authentication）: クライアントがサーバーに接続するか、サーバーがクライアントに接続するとき（特にネットワーク接続時）、互いの身元を確認するための強制的なメカニズムがありません。サーバーは、合法的なクライアントが接続されているか、クライアントが合法的なサーバーに接続されているか、どのように知ることができるでしょうか？
承認（Authorization）: ツールの実行に対するユーザーの同意は推奨されますが[13]（一部のホストで実装されています[12]）、特定のユーザー/クライアントがどのリソースにアクセスするか、どのツールをどのパラメータで使用するかについての細分化されたアクセス制御を行うための標準化されたプロトコルメカニズムがありません。
データ暗号化（機密性と完全性）: 特にネットワーク（HTTP+SSE送信）を介して送信中のデータに対して組み込みの暗号化機能がありません。MCPを介して送信されるデータは、改ざんされたり、改ざんされたりする可能性があります（HTTPのリスクと同様[15]）。
ログ/監査（Logging/Auditing）: セキュリティ関連のイベント（接続試行、認証成功/失敗、承認決定、ツール呼び出し、エラーなど）を監視、フォレンジック、規制遵守のために標準化された形式でログを記録するメカニズムがありません。

このようなプロトコルレベルの標準化の欠如は、さまざまな実装レベルのセキュリティに繋がります。例えば、Cursorは環境変数（env）を使用してAPIキーを管理し、ツール実行前にユーザーの承認を求めるワークフローを提供します。[12] しかし、これは実装レベルの制御に過ぎず、プロトコル保証ではありません。他のホストがこれを実装しない可能性もあり、Cursorの「Yoloモード」[12]のように、推奨される制御を回避する機能が存在する可能性もあります。Phil Schmidが言及したOAuth 2.0フロー[8]は、MCPの主要な要件ではなく、一部の実装パターンにすぎません。

このような技術的ギャップは、次のようなビジネス上のリスクに繋がります：

データ露出: 機密性の高い企業データ（リソースまたはツールパラメータ/応答内）が暗号化されていない状態で送信されるリスク。[15]
無断アクセス/操作: 悪意のあるクライアントがサーバーに接続するか、認証されていないサーバーが悪性のツール/データを提供する可能性。LLMが損傷したツールを介して無断作業を行う可能性があります。
規制遵守失敗: 暗号化、認証、監査機能の不足により、GDPR、HIPAA、PCI-DSSなどの規制要件を満たすことができません。[19]
責任追跡とフォレンジックの不可能性: 標準化された信頼できるログがない限り、セキュリティ事件の調査が困難です。
ブランドの損傷: セキュリティ侵害による信頼度とブランドイメージの低下。[21]

MCP仕様の「ユーザー同意」[13]の強調は、主に最終的なユーザーとホストアプリケーション間の相互作用に焦点を当てています。これは重要なユーザーセンターレベルのセキュリティですが、クライアントとサーバー構成要素間、特にネットワークを介した機械間（machine-to-machine）のセキュリティ要件は無視されています。サーバーが合法的なクライアントと通信しているかどうか（またはその逆）を確認し、それらの間のトラフィックを暗号化することと同様に、基本的なネットワークセキュリティの問題は、このような原則やプロトコル自体から直接的に扱われていません。このギャップは特にHTTP+SSE送信方式で顕著です。エンタープライズセキュリティは、ユーザーレベルのセキュリティとシステム/ネットワークレベルのセキュリティの両方を要求します。

さらに、ツールの説明は「信頼できるサーバーから得られない限り、信頼できないものとみなすべきである」[13]というガイドラインは、重要なブートストラップの問題を引き起こします。プロトコルレベルの認証がない限り、サーバーに対する信頼をどのように構築できるでしょうか？このガイドラインは、サーバーが信頼できるかどうかを判断するためのメカニズムが存在するという暗黙の仮定をしていますが、強制的なサーバー認証（HTTPS認証書と同様）がない限り、クライアントはサーバーの身元や提供するツールの説明の完全性を信頼する方法がありません。これは、信頼を得るために信頼が必要ですが、プロトコルはその初期信頼の基盤を提供していません。これは、循環的依存性を作り出します。

決定的に、セキュリティを実装者に依存する方法[13]は、初期インターネットプロトコルの問題を踏襲し、必然的に一貫性のないセキュリティ状態を引き起こします。これは、本当に相互運用可能で信頼できる生態系を構築しようとするMCPの目的[1]を妨げます。歴史は、セキュリティを実装者のモデル例にのみ依存することがしばしば失敗することを示しています（例：初期HTTP、さまざまなIoTプロトコル[21]）。HTTPSと同様の標準化は基準線を提供します。現在のMCPアクセス方式は、AベンダーのクライアントをBベンダーのサーバーに接続するときに両方が十分であり、互換性があるセキュリティ対策を実装していることを意味します。これは、プラグアンドプレイのビジョン[6]を弱めます。このような不一致は、予測可能なセキュリティが必要な企業にとって重要な障壁です。

歴史からの教訓：ウェブはいかにして自らを保護したか（HTTP → HTTPS）

World Wide Web（WWW）とHTTPは1989年から1991年の間にCERNのチームバーナースリによって発明されました。[25] 当初の目的は、研究者間の情報（ハイパーテキストドキュメント）の共有でした。[26] HTTP/0.9と同様の初期バージョンは非常に単純でした。[25]

HTTP vs HTTPS: 転送プロトコルのセキュリティの基本（出典：https://sslinsights.com/http-vs-https/）

しかし、当初のHTTPは平文（plaintext）プロトコルでした。[15] Webが単純な文書共有を越えて拡張されるにつれて、これは深刻なリスクをもたらしました。

盗聴（機密性侵害）: ネットワークを監視する人は、誰でも送信されるデータ（パスワード、フォームデータ、機密情報）を読むことができました。[15]
改ざん（完全性侵害）: データが送信中に変更される可能性がありました（例：悪意のあるコードや広告の挿入）。[16]
認証の欠如: ウェブサーバーの身元を確認する方法がなく、スプーフィング、中間者攻撃（Man-in-the-Middle, MitM）などのリスクに晒されていました。[16] 認証の欠如により、経路攻撃、DNSハイジャッキング、BGPハイジャッキング、ドメインスプーフィングなどが可能でした。[16]

Webが電子商取引領域に拡張され、機密性の高いユーザーデータを処理するようになると、HTTPの不安定性はさらに許容できないものになりました。[17] 安全で信頼できる通信に対する必要性が高まっています。この問題に対する解決策として、SSL/TLSとHTTPSが登場しました。Netscapeは1994-1995年頃にSSL（Secure Sockets Layer）を開発し、[31] これはその後IETFによって標準化され、TLS（Transport Layer Security）に進化しました。[31] HTTPSは、本質的にHTTPをSSL/TLSの上に階層化したものです。[15] これらは、異なるポート（HTTP: 80、HTTPS: 443）を使用します。[18]

SSL/TLSは次のように接続を保護します。

暗号化（機密性）: ハンドシェイクプロセス中に非対称暗号化（公開鍵/秘密鍵）を使用して、共有対称セッションキーを設定し、その後、すべてのHTTPデータをこのセッションキーで暗号化します。[15] 横取りされたデータはランダムな文字列のように見えます。[16]
認証（サーバーの身元）: サーバーは、信頼できる認証機関（Certificate Authority, CA）から発行されたSSL/TLS認証書を提示します。[15] ブラウザは、この認証書を検証して、サーバーの身元とドメインの所有権を確認します。[15] ブラウザのアドレスバーのロックアイコンがこれを示しています。[15]
完全性: TLS暗号化プロセス内で使用されるメッセージ認証コード（MAC）を使用して、データが改ざんされていないことを保証します。[36]

結果的にHTTPSは、Web通信の標準となりました。[30] ユーザーの信頼を構築し、[15] 安全なオンライン取引とデータ交換を可能にし、SEOランキングにも影響を与えました。[15] HTTP自体もHTTP/1.1、HTTP/2、HTTP/3に進化しましたが、HTTPSはこれらのすべてのバージョンに適用されました。[15]

HTTPからHTTPSへの切り替えは、即時的であるか、困難ではありませんでした。基盤プロトコル（SSL/TLS）の開発、認証機関（CA）のインフラストラクチャの構築、ブラウザとサーバーのアップデート、そして初期コストと複雑さに対する懸念の克服などが必要でした。[31] これは、MCPSへの道も、技術的な障害物に直面することを示唆しています。

HTTPSの重要な価値は、暗号化だけではなく、暗号化と信頼できるサードパーティ（CA）システムを介したサーバー認証の組み合わせにありました。これは、機密性の高い相互作用に必要な信頼を構築しました。[15] 成功したMCPSは、クライアントとサーバー間の信頼を構築するために、同様のメカニズムが必要である可能性が高くなります。単にMCPに暗号化を追加するだけでは十分ではないかもしれません。MCPSに対する企業の信頼を構築するために、強力なメカニズム（おそらく相互TLS、セクションV参照）が重要であることを示しています。

標準化プロセス自体（SSLをIETFに移行してTLSに進化させたもの）は、広範囲にわたる採用と相互運用性に非常に重要でした。[31] MCPSが特定の実装を超えて成功するためには、類似したオープンな標準化の努力が不可欠です。このような歴史的な例は、MCPSがMCPが目標とする相互運用性と広範囲にわたる採用1を達成するために、公式であり、コミュニティ中心の標準化プロセスが必要であることを強調しています。

MCPS構想：エンタープライズAIのためのセキュアプロトコル

これで、MCPの不可欠な進化としてMCPS（Secured Model Context Protocol）を公式に提案します。MCPSは、HTTPSモデルから教訓を得て、エンタープライズセキュリティ要件を最初から組み込むように設計する必要があります。

MCPからMCPSへ：必然的なセキュリティの進化

MCPSの目的: すべてのMCP通信に対して、機密性、完全性、強力な認証を提供し、エンタープライズ環境に適した信頼基準線を構築することです。

MCPSがプロトコルレベルで不可欠なセキュリティ要素は次のとおりです。

1. 相互認証（クライアントとサーバー）:

重要性: 主に、サーバーの身元が重要なWebブラウジングとは異なり、MCPは潜在的に機密性の高い企業システム（サーバー）と強力なAIクライアント間の双方向の相互作用を含みます。両側が相手の身元を確認し、無断アクセス、スプーフィング、悪性のツール/リソースの注入を防ぐ必要があります。これはB2Bまたは内部企業シナリオに非常に重要です。[20]
提案メカニズム - 相互TLS（mTLS）: クライアントとサーバーが両方とも検証するために、mTLSを提案します。[19] 標準TLSとのハンドシェイクの違いを簡単に説明し、[50] MitM、スプーフィング、クリデンシャルスタッフィング回避、およびAPIセキュリティ強化などmTLSの利点を強調します。[19] クライアント認証書と潜在的な内部CAまたは信頼ストア管理の必要性について議論します。[20]

2. 必須の暗号化（機密性と完全性）:

必須性: すべてのMCPデータ（リクエスト、レスポンス、ツールパラメータ、リソースコンテンツ）は、特にネットワーク（HTTP+SSE送信）を通過するときに盗聴と改ざんから保護する必要があります。
提案メカニズム - TLS（最新のセキュリティバージョン）: すべてのネットワークベースのMCPS通信に最新のセキュリティTLSバージョン（例：TLS 1.2、TLS 1.3[31]）を使用することを義務付けます。これは、確立されたTLSのセキュリティを利用します。[15] 強力な暗号化スイートと潜在的に全方向の機密性（Forward Secrecy）の必要性を強調します。[35]

3. 強力な承認とアクセス制御:

必要性: 誰が接続しているかを知ることだけでは十分ではありません。MCPSは、彼らが何をするかを制御する必要があります。これは、MCPツールを介したAI作業の潜在的な影響を考慮するときに非常に重要です。
提案メカニズム（統合ポイント）: MCPSが承認コンテキストを伝達するか、または既存のエンタープライズ承認システムと統合するための標準的な方法を定義することを提案します。可能なものは次のとおりです。
- セキュリティMCPSチャンネル内で標準化されたトークン（例：OAuth 2.0 Bearerトークン、JWT）を伝達します（RPCセキュリティのためにOAuth/JWTを言及する53からのインスピレーション）。mTLS接続はトークンの送信を保護します。
- 承認決定のためにクライアント認証書（mTLSで）の属性を使用します。
- 接続/ツール/リソースと関連するプロトコルレベルの役割または権限の定義（より複雑）。

4. 包括的な監査ログ:

必要性: セキュリティ監視、サイバーセキュリティ対応、規制遵守報告、および責任追跡のために不可欠です。
提案要件: MCPS仕様は、監査可能なイベントの標準セットと最小限の必須ログデータフィールド（例：タイムスタンプ、ソース/ターゲット識別子、イベントタイプ（接続、認証成功/失敗、ツール呼び出し、リソースアクセス）、状態、関連するパラメータ）を定義する必要があります。ログはMCPS接続のライフサイクルとその中の重要な作業を包括する必要があります。OWASP Top 10を参照してください。[56]

MCPSにmTLSを義務付けることは、現在の「実装者の注意」アプローチ[13]からプロトコルによって強制され、検証可能な身元モデルによる信頼モデルの根本的な変換を行います。これは、企業の採用に不可欠です。現在のMCPは、実装者に依存しています。[13] HTTPSはサーバー認証書に依存しています。[16] mTLS[20]は、クライアント認証書を追加することで、双方向認証を提供します。MCPを介して相互作用する企業システム（クライアントAIとサーバーデータソースの両方が機密性が高いか、重要である可能性がある場合）の場合、両端を確認することが最も重要です。MCPS内でmTLSを義務付けると、セクションIIIで確認された認証のギャップを直接解決し、後続の承認に必要な強力な身元ベースを提供します。

MCPSへの統合は複雑です。承認ロジックは、しばしば異なる状況に応じて異なります。既存の企業IDとアクセス管理（IAM）システムとの連携が必要です。RPC呼び出しのセキュリティのためにTLSと共にOAuth/JWTを使用することについての議論[53]は、送信セキュリティ（TLS）とアプリケーションレベルの承認（トークン）を分離するパターンを示しています。企業の承認要件の多様性を考慮すると、MCPSがTLS/mTLSを義務付けることで、セキュリティチャンネルを提供し、そのチャンネル内で既存のトークン（例：JWT）がどのように標準化されるかを検討することが、新しいプロトコル別の承認体系を作成するよりも、はるかに実現可能で、柔軟であることを示しています。MCPSは、独自の一般的な承認モデルを定義するよりも、承認トークン/コンテキストを安全に送信することに焦点を当てる必要があります。

MCPSプロトコル仕様内で標準化された監査ログを定義することは、異種クライアントとサーバー生態系全体にわたる一貫性のある可視性を確保するために重要です。「セキュリティログと監視の失敗」はOWASP Top 10のリスクの1つとして掲載されており、[56] 機密性の高いアプリケーションには、詳細なログが必要であることが強調されています。[57] ログを個別の実装に依存すると、一貫性のないデータと形式が発生し、効果的なセキュリティ監視を妨げます。MCPSがエンタープライズレベルのプロトコルを目標とする場合、プロトコル仕様自体に最小限の必須ログイベントとデータフィールドを標準化することで、ベンダーに関係なく、すべての規格遵守実装が基準レベルの監査可能性を提供することを保証します。これは、機能的相互運用性だけでなく、セキュリティ運用の観点からも相互運用性をサポートします。

経路設定：潜在的なMCPS実装戦略

重要な課題は、不可欠なセキュリティ要素（mTLS、TLS暗号化、承認コンテキスト、ログ）をMCPに組み込むか、その隣に配置する方法です。

アプローチ1：TLS/mTLS上にMCP階層化（「HTTPS」モデル）

説明: 従来のMCPプロトコル（stdio/SSEを介したJSON-RPCメッセージ）をアプリケーション階層のペイロードとして扱います。ネットワーク通信（HTTP+SSE）の場合、基本HTTP接続がTLS（サーバー認証）またはmTLS（相互認証）を使用している場合は、必ず保護する必要があると規定されています。これはHTTPSがHTTPをTLSで包む方法と似ています。
動作方法: 標準的なTLS/mTLSハンドシェイクは、ネットワーク通信を介してMCPメッセージが交換される前にセキュリティチャンネルを設定します。[36] stdioの場合、このアプローチは関連性が低いか、別の処理方法（おそらくOSレベルのセキュリティに依存）が必要な場合があります。
既存技術の活用: 検証されたTLS/mTLSライブラリとインフラを活用します。[55] 既存のMCPサーバーの前にTLS/mTLS終了を処理するために、リバースプロキシ（例：[14]で言及されたNginx）を使用することができます。
承認/ログ: 承認トークンはTLSツールのHTTPヘッダー（例：Authorization: Bearer...）を介して送信できます。[53] ログはTLS/mTLS階層（接続/認証イベント用）とMCPアプリケーション階層（ツール/リソースイベント用）に依存し、相関分析が必要です。

アプローチ2：MCPプロトコル仕様の強化（セキュリティ統合）

説明: MCP基本プロトコル（JSON-RPCメッセージと状態マシン）を直接変更して、セキュリティメカニズムを組み込みます。
動作方法（予想）: 認証ハンドシェイク（潜在的に認証書情報またはチャレンジポイントを含む）、MCPセッション内の暗号化パラメータネゴシエーションコマンド、承認トークンとログイベントに対する標準化されたメッセージ形式を定義します。これは、他のRPCプロトコルのセキュリティ機能からのインスピレーションを得ることができますが、MCPのJSON-RPC構造に組み込まれます。
潜在的な利点: プロトコルロジックとセキュリティの密接な統合、潜在的に最適化されたハンドシェイク、stdioとネットワーク通信の両方でのセキュリティの統合処理。
課題: 相当な標準化の努力が必要、既存MCP実装との下位互換性の中断、既存TLS/mTLS使用に対する「車輪の再発明」の可能性。

アプローチ3：ハイブリッドモデル

説明: 2つのアプローチの要素を組み合わせます。例えば、転送階層にmTLSを義務付け（アプローチ1）、標準化された承認トークンまたはより豊富なログ情報を伝達するための特定のMCPメッセージを定義します（アプローチ2の要素）。
根拠: 既存のセキュリティ（TLS/mTLS）を活用しながら、承認と監査と同様のアプリケーションレベルのセキュリティ問題のより良い統合を目的としてプロトコルを改善します。

実装戦略の比較

機能	アプローチ1：階層化（MCP over TLS/mTLS）	アプローチ2：プロトコル強化	アプローチ3：ハイブリッド
説明	MCPを標準TLS/mTLSで包む	セキュリティをMCP仕様に組み込む	TLS/mTLS通信 + MCP承認/ログメッセージ
暗号化	標準TLS	カスタマイズ/統合	標準TLS
認証	標準TLS/mTLS認証書	プロトコル定義メカニズム	標準TLS/mTLS認証書
承認	外部（例：HTTPヘッダーのトークン）	プロトコル定義メカニズム	MCP内の標準化されたトークンの伝達
ログ	別のTLSとアプリケーションログ、相関分析が必要	統合プロトコルログ	TLSログ + 標準化されたMCPログメッセージ
利点	既存技術/インフラの活用、迅速な標準化	密接な統合、統合送信処理	両方の利点の活用、バランスのとれた努力
欠点	"付加的"な感覚、stdio処理の明確さがない	互換性の中断、高い努力、設計のリスク	複雑さの増加、依然として努力が必要
生態系への影響	既存インフラへの入り口の低さ、ライブラリTLS/mTLSのサポートが必要	全体的なクライアント/サーバーの再作成が必要	TLS/mTLS + 部分的な再作成が必要
主要な関連資料	[14]	（概念的 - 直接的サポートが不十分）	（概念的組み合わせ）

「階層化」アプローチ（MCP over TLS/mTLS）は、最も実用的であり、既存のインターネットセキュリティの慣行（HTTPS）と最も一致し、潜在的な非効率性にもかかわらず、安全なソリューションへの最速の道を提供する可能性が高いです。HTTPSはHTTPをTLSの上に階層化します。[15] 多くの既存のRPCセキュリティに関する議論は、TLSの追加に重点を置いています。[14] これは、数十年にわたるTLS/PKI開発とインフラを活用することを意味します。プロトコルを強化すること（アプローチ2）は、よりスッキリ見えるかもしれませんが、MCP自体の内部で新しいセキュリティメカニズムを設計、標準化、実装するためにかかる努力、リスク、そして時間は、安全なソリューションの可用性を遅らせることになります。実用主義は、検証された基盤の上に構築することを提案しています。

アプローチに関係なく、mTLSに必要なキーと認証書を管理すること[20]は、MCPSを採用する組織にとって、プロトコル実装自体よりもはるかに重要な運用上の課題になる可能性があります。mTLSは、クライアントとサーバー両方が認証書を持つことを要求します。[44] 認証書の生成、管理、検証、更新、および廃止は、重要なステップであり、潜在的な課題として明示されています。[51] OpenSSLを使用したステップも詳しく説明されています。[20] このようなインフラ（潜在的に内部CAを含む）と、特に多くのAIエージェントやIoTと同様のシナリオで、大規模にクライアント認証書を配布し、管理するプロセスは、プロトコル設計とともに考慮する必要がある、かなりの運用オーバーヘッドを示しています。

実装戦略の選択は、標準化プロセスとスケジュールに直接的な影響を与えます。階層化は、既存のTLS/mTLS標準を参照して、より迅速な標準化を可能にする一方、プロトコルの強化は、MCP仕様の内部で完全に新しいセキュリティメカニズムを定義する必要があります。ハイブリッドアプローチはその間にあります。コミュニティの合意（IoTプロトコルセキュリティ標準化の難しさ[21]）に達する速度と実現可能性は、可能な場合は、既存の標準を活用することを好む可能性が高くなります。

報酬：MCPS導入のメリット

MCPSは、セクションIIIで確認された重要なギャップを解決し、信頼、セキュリティ、および規制遵守が最も重要な機密性の高いエンタープライズ環境でMCP展開を可能にすることです。[3]

不可欠な暗号化と認証（特にmTLS）は、データの機密性、完全性、および参加者の身元に対する検証可能な保証を提供し、相互作用するシステムとそれを運用する組織間の信頼を構築します。（HTTPSの信頼信号と同様[15]） MCPS機能は、強力な認証、暗号化、および監査追跡を要求する規制および産業規制遵守要件（例：HIPAA、GDPR、PCI-DSS [19]）を直接サポートします。これは、リスクを軽減し、監査を簡素化します。

MCPSは、現在の不安定なMCPでは、機密性の高いデータ（例：金融取引記録、顧客PII、独占コード）を含むアプリケーションにMCPを使用できるようにします。標準化されたセキュリティ階層（MCPS）は、さまざまな実装全体にわたる一貫性のあるセキュリティ基準線を保証し、現在のフラグメント化されたアクセス方法（セキュリティが個別の実装者の選択によって異なる-セクションIII参照）に比べて、はるかに安全で、信頼できる相互運用性を促進します。これは、より広範囲で確信のある採用を促進します。初期実装には努力が必要ですが、標準的なMCPSは、各開発者/組織がMCPの上にカスタマイズされたセキュリティ階層を開発し、実装する必要性を排除し、長期的に重複する努力とエラーの可能性を減らします。（開発者がすべてのHTTPSアプリケーションに対してTLSを再実装しないことと同様）

MCPSの主な利点は、セキュリティ機能を追加するだけではなく、それを標準化することです。この標準化は、MCPの元の約束である信頼できるものとして、大規模に実現することをMCPの目的とすることです。[1] MCPの目的は標準化であり、[1] セクションIIIでは、セキュリティ標準化の不足がどのようにフラグメント化とリスクにつながるかを強調しました。MCPSは、不可欠なセキュリティ基準線を定義することで、すべての規格遵守クライアントがすべての規格遵守サーバーと安全に相互作用できるようにすることを保証し、企業が信頼できる方法で相互運用性の約束を実現します。これは、ポイントツーポイントセキュリティソリューションを超えて、生態系全体のセキュリティに進みます。

さらに、MCPSは、エンタープライズでより進化しているAIエージェントのための可能な要因として機能する可能性があります。現在の信頼の欠如は、エージェントがMCPを介して実行できる作業範囲を制限します。MCPがエージェントの行動を可能にするという議論がありますが、[7] セクションIIIで説明したセキュリティリスク（無断作業、データ露出）は、企業が不安定なMCPを使用するエージェントに対して、重要な自己決定を与えることを深刻に制限します。MCPSは、強力な認証と承認制御を提供することで、企業がAIエージェントにプロトコルを介してより複雑でリスクの高い作業を実行できるようにする信頼を与えることができます。その結果、より進化した使用例を開くことができます。

障害を乗り越える：MCPSが直面する課題

MCPS実装には、さまざまな課題が予想されます。

技術的複雑さとパフォーマンスオーバーヘッド:
- 強力なセキュリティ実装は簡単ではありません。暗号化、TLS/mTLS、認証書管理などに関する専門知識が必要です。[56]
- 暗号化/復号化とハンドシェイクプロセス（特にmTLS）は、遅延時間と計算オーバーヘッドを発生させます。[22] これは、パフォーマンスに敏感なAIアプリケーションやリソース制約環境（例：一部の潜在的MCPクライアント/サーバーシナリオ、IoT課題と同様[21]）で慎重に検討する必要があります。
標準化プロセスとコミュニティの合意:
- MCPSの定義は、主要な利害関係者（Anthropic、OpenAI、ツールベンダー、企業利用者）間のセキュリティ要件と技術的アプローチに関する合意が必要です。[21]
- セキュリティ厳格性、実装容易性、下位互換性（存在する場合）の間のバランスをとることは、議論の余地があるかもしれません。急速に進化する分野では、合意を引き出すことは難しいかもしれません。[31]
生態系への採用と移行:
- 既存のMCPホスト、クライアント、サーバーをMCPSをサポートするように更新する必要があります。
- 移行処理方法（切り替え期間？非セキュアMCP共存？）についての計画が必要です。[59]
- ライブラリとSDK[1]が使用しやすいMCPSサポートを提供することが、採用に重要です。
運用上の課題（特にmTLS関連）:
- 認証書管理: 大規模なクライアント認証書のプロビジョニング、配布、更新、および廃止は、複雑で費用がかかる場合があります。[44] 強力なPKIインフラ（潜在的に内部CA）とプロセスが必要です。
- 信頼ストア管理: サーバーは、信頼できるクライアントCAまたは個別のクライアント認証書が含まれた信頼ストアを維持し、更新する必要があります。[44]
- 統合: MCPS（特にmTLSクライアントID）を既存のエンタープライズIAMとセキュリティモニタリングツールと統合する必要があります。
ポリシーとガバナンス:
- 信頼モデルの定義：誰が認証書を発行するか？MCPSを使用する他の組織間の信頼はどのように構築されるか？
- MCPSを実装し、使用する開発者と管理者のための明確な使用ポリシーとセキュリティベストプラクティスの開発。[23]
- 誤った構成の可能性：セキュリティ機能が誤って構成されると、脆弱性が生じる可能性があります。[22]

大規模なmTLS認証書管理の運用複雑さ[44]は、広範囲にわたるMCPS採用に伴うプロトコル設計の課題を上回る、最も大きな実質的な障壁になる可能性があります。プロトコル設計[セクションVI]と標準化は複雑ですが、1回限り（または稀）の努力です。潜在的に数百万のAIクライアント/エージェントに対する認証書ライフサイクル管理は、継続的な運用負担です。関連するステップが詳しく説明されています。[20] 企業は、これを解決するために、拡張可能なソリューションが必要であり、これはPKIインフラと自動化に相当な投資を必要とする場合があり、ツールとベストプラクティスによって適切に解決されない場合は、採用速度を遅らせる可能性があります。

IoTセキュリティプロトコルでよく言及される「制限されたデバイス」問題[21]は、一部のMCP展開シナリオ（例：軽量クライアントまたはサーバー）にも適用される可能性があり、これはMCPSの暗号化アルゴリズムや実装戦略の選択に影響を与える可能性があります。制限されたデバイス機能（CPU、メモリ、帯域幅）は、IoTでTLSと同様の強力なセキュリティ実装の難しさと、明示的に連結されていることを意味します。[21] 一般的なMCPホスト/サーバーは、強力なシステムで実行できますが、プロトコルの柔軟性[2]は、特定のツール/リソース提供者の役割を果たすために、より弱いパワーのデバイスでの実装を許可する可能性があります。MCPS設計は、このようなシナリオでのパフォーマンスオーバーヘッド[32]が金科玉条的になるかどうかを検討する必要があり、おそらく暗号化スイートの慎重な選択[35]や最適化された実装が必要な場合があります。

MCPS標準化と採用を達成するためには、AnthropicとOpenAIと同様の主要な主体が主導し、ツールビルダーと企業コンシューマーの広範囲のコミュニティの同意が必要な強力なリーダーシップと協力が必要です。MCP自体は、Anthropicによって開始され、[1] OpenAIと同様の他の企業によって受け入れられました。[7] HTTPS/TLSの歴史は、主要な産業プレイヤーと標準化機関との関連があることを示しています。[27] MCPSが標準になるためには、標準化の技術的、政治的課題を探求し、生態系への採用を主導するために、類似した協力リーダーシップが必要です。これがない場合、MCPSは隙間のソリューションになるか、競争的な「セキュアMCP」変種に繋がり、標準化の目的を破壊する可能性があります。

おわりに：AIの未来のための安全な基盤構築

MCPは、AI統合のための革新的な可能性を持っていますが、現在の状態では、エンタープライズ環境での使用には重要なセキュリティギャップが存在します。Web通信を安全にするHTTPSの歴史は、標準化されたセキュリティの重要性を明確に示しています。

そこで、エンタープライズ要件を満たすために、相互認証（mTLS）、必須の暗号化（TLS）、強力な承認メカニズムの統合、包括的な監査ログを重要要素とするMCPSの必要性を提案しました。MCPSは、セキュリティ機能を追加するだけでなく、標準化されたセキュリティを通じて、信頼できるものとして、安全なAI生態系を構築するために不可欠です。

もちろん、MCPSの開発、標準化、導入プロセスには、技術的複雑さ、パフォーマンスオーバーヘッド、生態系への合意の引き出し、運用上の課題など、解決する必要がある課題があります。特にmTLSのための認証書管理は、重要な運用負担になる可能性があります。

しかし、このような課題にもかかわらず、強力で標準化されたセキュリティは、MCPがエンタープライズ環境で潜在的な力を最大限に発揮し、責任感を持って使用するために不可欠な前提条件です。セキュリティは、もはや選択ではありません。そこで、AIとセキュリティコミュニティ（開発者、ベンダー、標準化機関、企業）は、MCPS定義、標準化、および実装のための議論と協力の努力に積極的に参加することを呼びかけます。オープンソースプロジェクトへの貢献や、潜在的なワーキンググループへの参加は、良い出発点になるかもしれません。

AIインフラの基礎となるMCPと同様のプロトコルにセキュリティを最初から組み込むことは、非常に重要です。これにより、次世代AI統合が強力であり、安全に実現できるようにすることが保証されます。MCPSは、このような安全な将来のための重要な足場になるでしょう。