約 5 分で読めます

MCPサーバーの本番運用設計——デプロイ・監視・バージョン管理の基本

by Kuu株式会社 エンジニアリング
MCPプロトコル本番運用デプロイ
テーマ全体像：Managed Agents 実装ガイド →

MCPサーバーを手元で動かすのは難しくない。しかし実際に社内ツールへ接続してAIエージェントに使わせようとした途端、「バージョンが合わない」「クライアントが増えると接続できなくなる」「何が起きているか見えない」という問題が立て続けに現れる。実装の次に来る本番運用の設計こそが、AIエージェントの安定稼働を左右する。

MCPサーバーの本番化でつまずく3つのポイント

MCPサーバーは実装後にtransport選択・バージョン管理・可観測性の3点で運用が停止するケースが多い。

transport選択のミス: stdioはサブプロセス起動でクライアントが1つに固定される。複数クライアントに対応するにはStreamable HTTPへの移行が必須で、この切り替えを後回しにすると設計全体の見直しを迫られる。

バージョン管理の不備: MCPプロトコルは急速に進化している。クライアントとサーバーでサポートするプロトコルバージョンが食い違うと、initializeフェーズで接続拒否が起きる。バージョンネゴシエーションの仕組みを理解せずに運用すると、クライアントアップデートのたびに障害が発生する。

可観測性の欠如: 「LLMがツールを呼んだか」「どのツールがエラーを返したか」「レイテンシはどれくらいか」——これが見えない状態では、本番障害の原因特定に何時間もかかる。

バージョンネゴシエーションはどう設計するか

MCP仕様はYYYY-MM-DD形式の日付で管理され、initializeフェーズでクライアントとサーバーが1つのバージョンに合意する。

MCPのプロトコルバージョンは2025-11-25のような日付文字列で管理される。後方互換の追加変更はバージョンを上げず、破壊的変更のみ新バージョンを宣言するルールだ。これにより、古いクライアントが新しいサーバーに接続しても動作を維持しやすい設計になっている。

バージョンネゴシエーションは接続の最初のinitializeリクエストで行われる。

``json
{
"jsonrpc": "2.0",
"method": "initialize",
"params": {
"protocolVersion": "2025-11-25",
"clientInfo": { "name": "my-agent", "version": "1.0.0" }
}
}
``

サーバーはサポートするバージョンの中から1つを選んでレスポンスする。合意できるバージョンがない場合、クライアントは接続を終了してユーザーにエラーを通知する。

2026年時点での注意点

  • サーバーは複数バージョンを同時サポートできる: 古いクライアントと新しいクライアントが混在する環境では、サーバー側で複数バージョンへの対応を維持するとスムーズに移行できる
  • 2026-07-28 RC（最新仕様候補）: セッションレス化が導入され、Mcp-Session-Idヘッダーがプロトコルレベルから削除された。任意のリクエストをどのサーバーインスタンスにも振り分けられるようになり、スティッキールーティングが不要になる
  • deprecated機能の移行期間: 仕様上、deprecated機能は最低12ヶ月は仕様に残り、その後に削除対象になる。定期的に仕様のrevisionsを確認し、移行計画を事前に立てることが重要だ

Streamable HTTPで本番デプロイするにはどうすればよいか

本番環境ではstdioを捨ててStreamable HTTPを選択し、コンテナ化してロードバランサー配下に置くのが基本設計です。

stdioとStreamable HTTPの使い分け

項目stdioStreamable HTTP
接続数1クライアント固定複数クライアント対応
スケーリング不可ロードバランサー配下でスケール
認証OS権限に依存OAuth 2.0/2.1で標準化
推奨用途ローカル開発・CI本番環境

stdioは開発ツールとして便利だが、本番での多クライアント対応・認証・スケーリングには対応していない。本番化の第一歩はStreamable HTTPへの移行だ。

コンテナ化と基本デプロイ構成

Streamable HTTPサーバーはDockerでコンテナ化し、ヘルスチェックエンドポイントを必ず実装する。

``dockerfile
FROM node:22-slim
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY dist/ ./dist/
EXPOSE 3000
HEALTHCHECK --interval=30s --timeout=3s \
CMD curl -f http://localhost:3000/health || exit 1
CMD ["node", "dist/server.js"]
``

ヘルスチェックはロードバランサーがルーティングの可否を判断するために使う。/healthは外部依存（DBなど）を含まない軽量チェックとし、/readyで外部依存を含む起動確認を分けると管理しやすい。

ゼロダウンタイム更新

MCPサーバーの更新時はブルーグリーンデプロイが有効だ。新バージョンを並行環境に立ち上げ、疎通確認後にロードバランサーを切り替える。問題が発生したら旧バージョンに即座に戻せる。最新RC（2026-07-28）のセッションレス設計が普及すると、インスタンスをまたいでリクエストを振り分けられるため、ローリングアップデートもより容易になる。

Kuuのエージェントガバナンス支援では、MCPサーバーのデプロイ設計から運用体制構築まで一貫してサポートしている。

可観測性はどこから整えるか

W3C Trace ContextをMCPの_metaフィールドで伝播することで、OpenTelemetryのトレースにLLM呼び出しを統合できます。

最低限のログ設計

まず押さえるべきログ項目は以下の4つだ。

  1. ツール呼び出しログ: tool_name・input（PII除去後）・レイテンシ・成否
  2. エラーログ: エラーコード・スタックトレース・リクエストID
  3. 認証ログ: クライアントID・スコープ・承認/拒否の結果
  4. 起動/停止ログ: バージョン情報・設定サマリ

W3C Trace Context統合

MCP 2025-11-25仕様では_metaフィールドにW3C Trace Contextの伝播が定義されている。

``json
{
"jsonrpc": "2.0",
"method": "tools/call",
"params": {
"name": "search_products",
"arguments": { "query": "在庫確認" },
"_meta": {
"traceparent": "00-0af7651916cd43dd8448eb211c80319c-b7ad6b7169203331-01",
"tracestate": ""
}
}
}
``

traceparentを受け取ったMCPサーバーは、自分が行う外部API呼び出しにもこのトレースIDを引き継ぐ。これにより、LLMがツールを呼び出してからDBアクセスまでの全スパンを1本のトレースツリーで可視化できる。

メトリクス設計

最低限収集するメトリクスは以下の4つだ。

  • mcp.tool.call.count: ツール呼び出し回数（ツール別・クライアント別）
  • mcp.tool.call.duration: ツール実行レイテンシ（p50/p95/p99）
  • mcp.tool.call.error.rate: エラー率（ツール別）
  • mcp.server.connection.count: 同時接続数

エラー率の急増やレイテンシの外れ値をアラートとして設定することで、LLMがツール呼び出しのリトライループに入っている状態をいち早く検知できる。

アクセス制御の最低ラインを決める

MCPのOAuth 2.0認証でスコープを設定することで、ツール単位のアクセス制限が実装できます。

MCP仕様はOAuth 2.0/2.1ベースの認証を定義している。Streamable HTTP transportではHTTPヘッダーでBearerトークンを受け取り、スコープによってどのツールを呼び出せるかを制御する。

``
Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...
``

最小権限原則のスコープ設計

ツールに対応するスコープを定義し、クライアントには必要最小限のスコープのみ付与する。

``json
{
"scopes": {
"tools:search_products": "商品検索ツールの呼び出し権限（読み取り）",
"tools:update_inventory": "在庫更新ツールの呼び出し権限（書き込み）",
"tools:admin": "全ツールの呼び出し権限（管理者専用）"
}
}
``

書き込みや副作用を持つツール（update_inventory等）は専用スコープを分離し、読み取り専用スコープとは必ず別に管理する。これにより、参照系のAIエージェントが誤って書き込み操作を実行するリスクを構造的に排除できる。エージェントガバナンスの基本である最小権限の原則をMCPのスコープ設計に直接反映する形だ。

参考

まとめ

MCPサーバーの本番運用で押さえるべきポイントは4点だ。①stdioからStreamable HTTPに切り替えてコンテナ化する、②YYYY-MM-DD形式のプロトコルバージョンをinitializeで正しくネゴシエーションする、③W3C Trace ContextをMCPの_metaに伝播してOpenTelemetryに統合する、④OAuth 2.0スコープで最小権限のアクセス制御を実装する。この4点が整うと、LLMがMCPツールを呼び出す経路全体を計装・制御できる本番基盤が完成する。

運用基盤の設計からエージェントガバナンス体制の整備まで、継続したサポートが必要な場合はKuuのエージェントガバナンス支援にご相談ください。

関連記事

MCP 2026-07-28 RC：ステートレス化と移行手順MCPとA2Aの違い——補完するプロトコルを正しく使い分けるMCPとFunction callingの使い分け——ツール設計の選択基準MCP Streamable HTTP移行設計——セッション管理・後方互換・水平スケール
← ブログ一覧へ戻る