MCP本番運用：スケールする統合パターン

デモとデプロイメントの間のギャップ

MCPのデモは魔法のように見える。過去4ヶ月間、3つの企業環境でMCPベースのアーキテクチャをデプロイしてきた。プロトコル自体はエレガント。本番の課題はすべてその周辺にある：トランスポートの信頼性、認証、オブザーバビリティ、そして複数のMCPサーバーを同時にオーケストレーションするという驚くほどトリッキーな問題。

トランスポート選択：stdio vs. SSE vs. WebSocket

stdioはデフォルトのトランスポートでローカル開発に最適。問題：サーバーのライフサイクルがクライアントプロセスに紐づく。HTTP+SSEは本番の主力——プロセスの独立性と水平スケーリングを提供。WebSocketはサーバーがプロアクティブにメッセージ送信する必要がある場合のみ。

認証と認可

3層認証モデルを使用：トランスポート認証（mTLS）、セッション認証（セッショントークン）、ツールレベル認可（ツールごとのACL）。3層すべての実装はサーバーごとに約2〜3日の追加開発コスト。

マルチサーバーオーケストレーション

ルータープロキシパターンで解決。MCPルーターがツールリストを集約し、呼び出しをルーティングし、ヘルスチェックを処理。各バックエンドサーバーを30秒ごとにping——連続3回失敗でルーティングテーブルから削除。

スケールしたエラーハンドリング

エラー率：通常運用で3〜8%、インシデント時に15〜20%。一時的なネットワークエラー（約40%）は自動リトライ。検証エラー（約25%）はリトライせず、明確なエラーメッセージを返す。AIには失敗の事実だけでなく理由を伝える必要がある。

オブザーバビリティ

ツール呼び出しレイテンシ、エラー率、サーバー健全性を追跡。トレースIDをクライアントからルーター経由でバックエンドサーバーに伝搬。

ツールスキーマの進化

ツール名にバージョン番号を付与（query_customers_v2）。ルーターがバージョニングルーティングを処理。少なくとも1リリースサイクルは後方互換性を維持。

MCPはAIツール統合の正しい抽象化だ。しかし本番MCPにはプロトコル仕様を超えたインフラ構築が必要だ。