本番環境でのMCP：Transport、認証、スケーリングの課題を解決する
Engineering Team
プロトタイプから本番環境へ：何が変わるか
ラップトップで動作するMCPサーバーを構築するのは比較的簡単です。分散インフラストラクチャ全体で数千のAIエージェントセッションを同時に処理するサーバーを運用するのは、まったく異なるエンジニアリング上の課題です。本番環境のMCPデプロイメントは、プロトタイプでは無視できる5つの問題に対処する必要があります：トランスポートのスケーラビリティ、認証と認可、スケールでのセッション管理、監査証跡、マルチサーバーオーケストレーション。
この記事は、MCPサーバーを開発から本番環境に移行するエンジニアリングチーム向けの技術ガイドです。少なくとも1つのMCPサーバーを構築し、プロトコルの基本を理解していることを前提としています。まだの場合は、初めてのMCPサーバー構築に関する関連記事から始めてください。
トランスポートのスケーラビリティ：stdio vs SSE vs Streamable HTTP
MCPは3つのトランスポートメカニズムを定義しています。本番環境に適したものを選択することが、最初のアーキテクチャ上の決定です。
stdioトランスポート
stdioトランスポートは標準入出力ストリームを介して通信します。HostアプリケーションがMCPサーバーを子プロセスとして起動し、stdin/stdoutを介してJSON-RPCメッセージを交換します。
利点：
- ネットワーク設定不要
- プロセスレベルの分離
- ポート競合なし
- 最低レイテンシ（ネットワークスタックなし）
制限：
- サーバーはHostと同じマシン上で実行する必要がある
- Clientセッションごとに1つのサーバープロセス
- ロードバランシング不可
- 水平スケーリング不可
最適な用途： ローカル開発ツール、IDE拡張機能、シングルユーザーデスクトップアプリケーション。
SSE（Server-Sent Events）トランスポート
SSEトランスポートは、クライアントからサーバーへのメッセージにHTTPを使用し、サーバーからクライアントへのメッセージにServer-Sent Eventsを使用します。サーバーはHTTPサービスとして動作します。
利点：
- ネットワーク経由でアクセス可能（リモートサーバー）
- 既存のHTTPインフラストラクチャと互換性
- 複数のクライアントを同時にサポート
- ファイアウォールやプロキシを通過
制限：
- 単方向ストリーミング（SSEはサーバーからクライアントのみ）
- セッションアフィニティが必要（ステートフル接続）
- 一部のロードバランサーが長寿命SSE接続で問題
- プロトコルに組み込みの再接続セマンティクスなし
最適な用途： 小〜中規模のデプロイメント、内部ツール、既存HTTPインフラストラクチャを持つチーム。
Streamable HTTPトランスポート
Streamable HTTPは最新のトランスポートで、本番環境のデプロイメント向けに特別に設計されています。すべてのメッセージに標準HTTP POSTを使用し、長時間実行操作にはオプションのSSEストリーミングを使用します。
利点：
- 完全にステートレスなリクエスト/レスポンスモデル
- 任意のHTTPロードバランサーで動作
Mcp-Session-Idヘッダーによる組み込みセッション管理- ストリーミングと非ストリーミングの両方のレスポンスをサポート
- CDNやプロキシと互換性
制限：
- サーバーサイドのセッションストレージが必要（Redis、データベース）
- stdioよりメッセージごとのオーバーヘッドがわずかに高い
- 新しいトランスポート — エコシステムツールが少ない
最適な用途： 本番クラウドデプロイメント、マルチテナントプラットフォーム、エンタープライズ環境。
トランスポート比較マトリックス
| 特性 | stdio | SSE | Streamable HTTP |
|---|---|---|---|
| ネットワーク対応 | いいえ | はい | はい |
| 水平スケーリング | いいえ | 限定的 | はい |
| ロードバランシング | いいえ | セッションアフィニティ必要 | 標準HTTP LB |
| セッション管理 | プロセスごと | サーバーメモリ | 外部ストア |
| レイテンシ | 最低 | 低 | 低 |
| ファイアウォール互換 | N/A | はい | はい |
認証と認可
OAuth 2.0統合
本番MCPサーバーは、クライアントが自己を認証し、特定のツールやリソースへのアクセスを制限する方法が必要です。MCPプロトコルは、リモートサーバー向けにOAuth 2.0をサポートしています。
フローは次のようになります：
- MCP clientがサーバーに接続し、
initializeリクエストを送信 - サーバーが
401 UnauthorizedとOAuthメタデータURL付きのWWW-Authenticateヘッダーで応答 - Clientが
/.well-known/oauth-authorization-serverからOAuth設定を取得 - Clientがブラウザベースの認可フローを使用してアクセストークンを取得
- その後のリクエストにはBearerトークンを
Authorizationヘッダーに含める
ツールレベルの認可
認証だけでは不十分です。本番システムには、ユーザーがどのツールを呼び出し、どのリソースにアクセスできるかを制御する細かい認可が必要です。
推奨アプローチ：
- ロールベースアクセス制御（RBAC）：ロールにツール権限を割り当て。例：
analystロールは読み取り専用クエリツールにアクセスでき、adminロールは書き込み操作にアクセス可能。 - スコープベース制御：OAuthスコープを使用してツールアクセスを制限。例：
mcp:tools:query:readスコープはSELECTクエリのみ許可。 - 動的ツールフィルタリング：認証されたユーザーの権限に基づいて、利用可能なツールリストをフィルタリング。
Redisによる水平スケーリング
ステートレスなStreamable HTTPトランスポートを使用すると、複数のMCPサーバーインスタンスをロードバランサーの背後で実行できます。セッション状態はRedisに保存され、すべてのインスタンスで共有されます。
Client → Load Balancer → MCP Server 1 ↔ Redis
→ MCP Server 2 ↔ Redis
→ MCP Server 3 ↔ Redis
各リクエストにはMcp-Session-Idヘッダーが含まれ、任意のサーバーインスタンスがRedisからセッション状態を取得して処理を続行できます。
Kubernetes上のオートスケーリング
MCPサーバーをKubernetesにデプロイすると、アクティブセッション数やCPU使用率に基づいてPodを自動的にスケーリングできます。Horizontal Pod Autoscaler（HPA）でカスタムメトリクスを使用します。
監査ロギング
エンタープライズデプロイメントでは、AIが外部ツールを呼び出すたびに詳細な監査証跡が必要です。各ツール呼び出しについて以下を記録します：
- タイムスタンプ：呼び出しの時刻
- ユーザーID：AIアクションを開始したユーザー
- ツール名：呼び出されたMCPツール
- 入力パラメータ：ツールに送信されたデータ
- 出力結果：ツールが返したデータ
- 実行時間：ツール呼び出しにかかった時間
- エラー：発生したエラー
構造化ロギング（JSON形式）を使用し、ログを集中ログ管理システム（ELK Stack、Datadog、CloudWatch）に送信します。
ゲートウェイアーキテクチャ
大規模デプロイメントでは、MCPゲートウェイパターンの実装を検討してください。ゲートウェイはMCP clientとバックエンドMCPサーバー間のリバースプロキシとして機能します。
ゲートウェイの責任：
- 認証の一元化：すべてのOAuth検証をゲートウェイで処理
- レート制限：ユーザーごと、ツールごとのレート制限を適用
- ルーティング：ツール名に基づいてリクエストを適切なバックエンドサーバーにルーティング
- 監査ログの収集：すべてのツール呼び出しをゲートウェイレベルで記録
- サーキットブレーカー：バックエンドサーバー障害時のフォールバック処理
FAQ
Q：本番環境でstdioトランスポートを使用できますか？ A：はい、ただし限定的なシナリオでのみ。各ユーザーが独自のローカルMCPサーバープロセスを実行するデスクトップアプリケーションには適しています。共有サーバーインフラストラクチャにはStreamable HTTPを使用してください。
Q：MCPセッションの永続化は必要ですか？ A：はい、Streamable HTTPを使用する場合。セッション状態にはクライアントの機能、ネゴシエートされたプロトコルバージョン、登録された通知が含まれます。Redisは推奨されるセッションストアです。
Q：MCPサーバーのバージョン管理はどうすべきですか？
A：initializeレスポンスのサーバーバージョンフィールドを使用します。破壊的変更（ツールの削除、スキーマの変更）の場合、メジャーバージョンをバンプし、移行期間中は古いバージョンと新しいバージョンの両方をサポートします。
Q：MCPの最大メッセージサイズは？ A：プロトコルは最大サイズを定義していませんが、実際の制限はトランスポートに依存します。Streamable HTTPの場合、レスポンスを10 MB以下に保ちます。stdioの場合、システムパイプバッファ（通常64 KB）により大きなレスポンスにはチャンキングが必要な場合があります。