MCP（Model Context Protocol）サーバーを本番環境で安定稼働させるには、開発時とは異なる視点での運用管理が求められます。本記事では、監視指標の設計から脆弱性対応、SLA 管理、コスト最適化まで、MCP サーバー運用の実務ノウハウを包括的に解説いたします。

実際の運用現場で直面する課題に対して、具体的な設定例やツールの使い方を交えながら、すぐに実践できる内容をお届けしますね。

背景

MCP サーバーの運用が重要視される理由

MCP サーバーは、AI アシスタントとさまざまなツールやデータソースを接続する中核的な役割を担います。開発環境では問題なく動作していたサーバーでも、本番環境では予期せぬ負荷やセキュリティリスクにさらされるため、適切な運用体制の構築が不可欠です。

特に以下の観点から、MCP サーバーの運用管理は重要になっています。

• 可用性の保証: AI アシスタントの機能が MCP サーバーに依存するため、障害時の影響範囲が広い
• セキュリティリスク: 外部ツールやデータソースへのアクセス権限を持つため、攻撃対象となりやすい
• パフォーマンス要件: リアルタイム性が求められる AI 応答において、レスポンス遅延は UX に直結する

以下の図は、MCP サーバーが AI アシスタントとツール群の間でどのように機能するかを示しています。

mermaidCopy codeflowchart TB
  client["AI アシスタント<br/>クライアント"] -->|MCP プロトコル| mcpServer["MCP サーバー<br/>（運用対象）"]
  mcpServer -->|ツール呼び出し| tool1["ファイルシステム"]
  mcpServer -->|データ取得| tool2["データベース"]
  mcpServer -->|API 連携| tool3["外部 API"]
  mcpServer -->|結果返却| client

  monitor["監視システム"] -.->|メトリクス収集| mcpServer
  logs["ログ管理"] -.->|ログ集約| mcpServer

この図から分かるように、MCP サーバーは複数のツールを束ねる中心的存在であり、その運用状態が全体のシステム品質を左右します。

運用で直面する主な課題

実際の運用現場では、以下のような課題に直面することが多いでしょう。

• 監視すべき指標が多岐にわたり、何を優先すべきか判断が難しい
• ログやトレース情報が分散し、障害時の原因究明に時間がかかる
• 脆弱性情報の収集と対応に専門知識が必要
• コスト削減と品質維持のバランスが取りにくい

課題

監視指標の選定と優先順位付け

MCP サーバーの運用では、サーバー自体のメトリクスに加えて、接続先ツールの状態や AI アシスタントからのリクエスト特性など、多層的な監視が必要になります。しかし、すべての指標を同等に監視するのは現実的ではありません。

以下の表は、MCP サーバー運用で監視すべき主要指標を優先度別に整理したものです。

#	指標カテゴリ	具体的な指標例	優先度	理由
1	可用性	サーバー稼働率、ヘルスチェック成功率	★★★	サービス停止の直接的影響
2	レスポンス性能	リクエスト処理時間、ツール呼び出しレイテンシ	★★★	UX への直接的影響
3	リソース使用率	CPU、メモリ、ディスク I/O	★★☆	パフォーマンス劣化の予兆検知
4	エラー率	HTTP エラー率、ツール呼び出し失敗率	★★★	品質指標として重要
5	セキュリティ	認証失敗回数、異常アクセスパターン	★★☆	セキュリティインシデント予防

ログとトレースの統合管理の難しさ

MCP サーバーは複数のツールと連携するため、以下のような図に示すように、ログやトレース情報が分散します。

mermaidCopy codeflowchart LR
  request["クライアント<br/>リクエスト"] --> mcpLog["MCP サーバー<br/>アプリケーションログ"]
  mcpLog --> toolLog1["ファイルシステム<br/>アクセスログ"]
  mcpLog --> toolLog2["DB クエリログ"]
  mcpLog --> toolLog3["外部 API<br/>アクセスログ"]

  mcpLog --> collector["ログ集約基盤"]
  toolLog1 --> collector
  toolLog2 --> collector
  toolLog3 --> collector

  collector --> analysis["分析・検索<br/>インターフェース"]

一つのリクエストが複数のツール呼び出しを伴う場合、トレース ID を使った追跡が必須ですが、ツール側がトレース対応していないケースも多く、実装負荷が高まります。

脆弱性対応のタイムライン管理

MCP サーバーは Node.js や Python などのランタイム、および多数の依存パッケージで構成されます。脆弱性が公開されてから対応完了までのタイムラインをどう管理するかが課題です。

以下の状態遷移図は、脆弱性対応のライフサイクルを示しています。

mermaidCopy codestateDiagram-v2
  [*] --> detected: 脆弱性検知
  detected --> assessed: 影響範囲評価
  assessed --> patching: パッチ適用
  assessed --> accepted: リスク受容
  patching --> testing: テスト実施
  testing --> deployed: 本番適用
  deployed --> [*]
  accepted --> monitoring: 継続監視
  monitoring --> [*]

特に重大度が高い脆弱性（CVSS スコア 7.0 以上）については、24 時間以内の対応が求められることもあり、自動化された検知と迅速な対応フローの確立が重要になります。

SLA とコストのトレードオフ

高い可用性（例: 99.9% の稼働率）を実現するには、冗長構成やスケールアウト、高性能インフラが必要となり、コストが増大します。一方で、過度なコスト削減は SLA 違反のリスクを高めるでしょう。

この課題に対しては、ビジネス要件に基づいた適切な SLA 設定と、コスト効率の高いアーキテクチャ選択が求められます。

解決策

監視指標の実装とアラート設計

MCP サーバーの監視基盤を構築する際は、Prometheus と Grafana の組み合わせが効果的です。以下、具体的な実装方法を段階的に解説いたします。

Prometheus クライアントの導入

まず、MCP サーバーに Prometheus のメトリクス収集機能を組み込みます。

typescriptCopy code// 必要なパッケージのインポート
import {
  Registry,
  Counter,
  Histogram,
  Gauge,
} from 'prom-client';

typescriptCopy code// Prometheus レジストリの初期化
const register = new Registry();

// カスタムメトリクスの定義
const requestCounter = new Counter({
  name: 'mcp_requests_total',
  help: 'Total number of MCP requests',
  labelNames: ['method', 'status'],
  registers: [register],
});

このコードでは、MCP サーバーへのリクエスト総数をカウントするメトリクスを定義しています。labelNames でメソッド名とステータスコードを分類できるようにしました。

typescriptCopy code// レスポンス時間を測定するヒストグラム
const responseDuration = new Histogram({
  name: 'mcp_response_duration_seconds',
  help: 'Response duration in seconds',
  labelNames: ['method'],
  buckets: [0.1, 0.5, 1, 2, 5], // レスポンス時間の分布を把握
  registers: [register],
});

ヒストグラムを使うことで、レスポンス時間の分布（P50、P95、P99 パーセンタイル）を把握できます。

typescriptCopy code// 接続中のクライアント数を測定するゲージ
const activeConnections = new Gauge({
  name: 'mcp_active_connections',
  help: 'Number of active client connections',
  registers: [register],
});

メトリクス収集のミドルウェア実装

次に、各リクエストでメトリクスを自動収集するミドルウェアを実装します。

typescriptCopy code// Express ミドルウェアの実装例
import express from 'express';

const app = express();

// メトリクス収集ミドルウェア
app.use((req, res, next) => {
  // リクエスト開始時刻を記録
  const start = Date.now();

  // レスポンス完了時の処理
  res.on('finish', () => {
    const duration = (Date.now() - start) / 1000; // 秒単位に変換

    // メトリクスを記録
    requestCounter.inc({
      method: req.method,
      status: res.statusCode,
    });
    responseDuration.observe(
      { method: req.method },
      duration
    );
  });

  next();
});

このミドルウェアは、すべてのリクエストに対して自動的にメトリクスを収集しますので、手動での記録漏れを防げます。

typescriptCopy code// メトリクス公開エンドポイント
app.get('/metrics', async (req, res) => {
  res.set('Content-Type', register.contentType);
  const metrics = await register.metrics();
  res.end(metrics);
});

Prometheus サーバーの設定

Prometheus サーバー側では、以下の設定で MCP サーバーからメトリクスを定期的に収集します。

yamlCopy code# prometheus.yml の設定例
global:
  scrape_interval: 15s # 15秒ごとにメトリクスを収集
  evaluation_interval: 15s # アラートルールの評価間隔

# MCP サーバーからのメトリクス収集設定
scrape_configs:
  - job_name: 'mcp-server'
    static_configs:
      - targets: ['localhost:3000'] # MCP サーバーのアドレス
    metrics_path: '/metrics' # メトリクス公開エンドポイント

アラートルールの定義

重要な指標に対してアラートルールを設定します。

yamlCopy code# アラートルールの定義（alert.rules.yml）
groups:
  - name: mcp_server_alerts
    interval: 30s
    rules:
      # エラー率が 5% を超えた場合のアラート
      - alert: HighErrorRate
        expr: |
          sum(rate(mcp_requests_total{status=~"5.."}[5m]))
          /
          sum(rate(mcp_requests_total[5m])) > 0.05
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: 'MCP サーバーのエラー率が高い'
          description: '過去 5 分間のエラー率が 5% を超えています'

この設定により、5 分間のエラー率が 5% を超える状態が 5 分間継続すると、クリティカルアラートが発火します。

yamlCopy code# レスポンス時間が遅い場合のアラート
- alert: SlowResponseTime
  expr: |
    histogram_quantile(0.95,
      sum(rate(mcp_response_duration_seconds_bucket[5m])) by (le)
    ) > 2
  for: 10m
  labels:
    severity: warning
  annotations:
    summary: 'MCP サーバーのレスポンスが遅延'
    description: 'P95 レスポンス時間が 2 秒を超えています'

yamlCopy code# サーバーダウン検知
- alert: ServerDown
  expr: up{job="mcp-server"} == 0
  for: 1m
  labels:
    severity: critical
  annotations:
    summary: 'MCP サーバーがダウン'
    description: 'MCP サーバーからメトリクスを取得できません'

構造化ログとトレーシングの実装

ログとトレースを統合管理するには、構造化ログの採用と分散トレーシングの実装が効果的です。

構造化ログの実装

Winston ライブラリを使った構造化ログの実装例を示します。

typescriptCopy code// Winston のインポート
import winston from 'winston';

typescriptCopy code// ログフォーマットの定義
const logFormat = winston.format.combine(
  winston.format.timestamp({
    format: 'YYYY-MM-DD HH:mm:ss',
  }),
  winston.format.errors({ stack: true }),
  winston.format.json() // JSON 形式で出力
);

JSON 形式でログを出力することで、ログ集約ツール（Elasticsearch、Loki など）での検索や分析が容易になります。

typescriptCopy code// Logger インスタンスの作成
const logger = winston.createLogger({
  level: process.env.LOG_LEVEL || 'info',
  format: logFormat,
  transports: [
    // コンソール出力
    new winston.transports.Console(),
    // ファイル出力（エラーログは別ファイル）
    new winston.transports.File({
      filename: 'logs/error.log',
      level: 'error',
    }),
    new winston.transports.File({
      filename: 'logs/combined.log',
    }),
  ],
});

typescriptCopy code// ログ出力のヘルパー関数
export function logRequest(
  traceId: string,
  method: string,
  params: any
) {
  logger.info('MCP request received', {
    traceId, // トレース ID で追跡可能に
    method, // MCP メソッド名
    params, // リクエストパラメータ
    timestamp: new Date().toISOString(),
  });
}

分散トレーシングの実装

OpenTelemetry を使った分散トレーシングの実装例です。

typescriptCopy code// OpenTelemetry のインポート
import { NodeSDK } from '@opentelemetry/sdk-node';
import { getNodeAutoInstrumentations } from '@opentelemetry/auto-instrumentations-node';
import { JaegerExporter } from '@opentelemetry/exporter-jaeger';

typescriptCopy code// トレーシング SDK の初期化
const sdk = new NodeSDK({
  traceExporter: new JaegerExporter({
    endpoint: 'http://localhost:14268/api/traces', // Jaeger サーバー
  }),
  instrumentations: [
    getNodeAutoInstrumentations(), // 自動計装
  ],
});

// SDK の起動
sdk.start();

自動計装により、HTTP リクエストやデータベースクエリなどが自動的にトレースされます。

typescriptCopy code// カスタムスパンの作成例
import { trace } from '@opentelemetry/api';

const tracer = trace.getTracer('mcp-server');

export async function callTool(
  toolName: string,
  params: any
) {
  // 新しいスパンを開始
  const span = tracer.startSpan(`tool.${toolName}`);

  try {
    // ツール呼び出しの実行
    span.setAttribute('tool.name', toolName);
    span.setAttribute(
      'tool.params',
      JSON.stringify(params)
    );

    const result = await executeToolCall(toolName, params);

    span.setStatus({ code: 0 }); // 成功ステータス
    return result;
  } catch (error) {
    // エラー情報をスパンに記録
    span.setStatus({ code: 2, message: error.message });
    span.recordException(error);
    throw error;
  } finally {
    span.end(); // スパンを終了
  }
}

このコードにより、各ツール呼び出しが個別のスパンとして記録され、処理時間やエラー情報を追跡できます。

ログとトレースの相関付け

ログとトレースを関連付けるには、トレース ID をログに含めます。

typescriptCopy code// トレース ID をログに含める実装
import { context, trace } from '@opentelemetry/api';

export function logWithTrace(message: string, data: any) {
  // 現在のスパンコンテキストを取得
  const span = trace.getSpan(context.active());
  const traceId = span?.spanContext().traceId;

  logger.info(message, {
    ...data,
    traceId, // トレース ID を付与
  });
}

この実装により、ログ検索時にトレース ID をキーにして、関連するすべてのログとトレースを一括で確認できるようになります。

脆弱性スキャンと自動対応フロー

脆弱性管理を効率化するには、自動スキャンと対応フローの仕組み化が重要です。

依存パッケージのスキャン

Yarn を使ったプロジェクトでは、以下のコマンドで脆弱性をスキャンできます。

bashCopy code# 脆弱性スキャンの実行
yarn audit

このコマンドは、package.json に記載された依存パッケージの既知の脆弱性をチェックします。

bashCopy code# JSON 形式で詳細レポートを出力
yarn audit --json > audit-report.json

JSON 形式で出力することで、後続の自動処理に利用できます。

自動スキャンの CI/CD 統合

GitHub Actions を使った自動スキャンの設定例です。

yamlCopy code# .github/workflows/security-scan.yml
name: Security Scan

on:
  schedule:
    - cron: '0 0 * * *' # 毎日 0 時に実行
  push:
    branches: [main]

jobs:
  audit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3

      - name: Setup Node.js
        uses: actions/setup-node@v3
        with:
          node-version: '18'

yamlCopy code# 依存パッケージのインストール
- name: Install dependencies
  run: yarn install --frozen-lockfile

# 脆弱性スキャン実行
- name: Run security audit
  run: |
    yarn audit --level moderate || true
    yarn audit --json > audit-report.json

yamlCopy code# 重大な脆弱性がある場合は失敗させる
- name: Check for critical vulnerabilities
  run: |
    CRITICAL=$(cat audit-report.json | jq '[.advisories[] | select(.severity == "critical")] | length')
    if [ "$CRITICAL" -gt 0 ]; then
      echo "Critical vulnerabilities found: $CRITICAL"
      exit 1
    fi

この設定により、クリティカルレベルの脆弱性が検出された場合、CI/CD パイプラインが失敗し、開発者に通知されます。

Trivy によるコンテナイメージスキャン

Docker イメージに対する脆弱性スキャンには Trivy が効果的です。

bashCopy code# Trivy のインストール（macOS の場合）
brew install trivy

bashCopy code# Docker イメージのスキャン
trivy image mcp-server:latest

このコマンドは、OS パッケージとアプリケーション依存関係の両方をスキャンし、脆弱性レポートを出力します。

bashCopy code# 重大度 HIGH 以上のみ表示
trivy image --severity HIGH,CRITICAL mcp-server:latest

bashCopy code# JSON 形式でレポート出力
trivy image --format json --output trivy-report.json mcp-server:latest

自動パッチ適用の実装

Renovate を使うと、依存パッケージのアップデートを自動化できます。

jsonCopy code{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": ["config:base"],
  "packageRules": [
    {
      "matchUpdateTypes": ["patch"],
      "automerge": true,
      "automergeType": "pr"
    },
    {
      "matchUpdateTypes": ["minor"],
      "automerge": false,
      "labels": ["dependencies"]
    },
    {
      "matchUpdateTypes": ["major"],
      "automerge": false,
      "labels": ["dependencies", "breaking-change"]
    }
  ],
  "vulnerabilityAlerts": {
    "labels": ["security"],
    "automerge": true,
    "schedule": ["at any time"]
  }
}

この設定では、パッチバージョンのアップデートは自動マージし、マイナー・メジャーバージョンは手動レビューを必要とします。脆弱性対応のアップデートは最優先で自動マージされます。

SLA 定義とコスト最適化戦略

適切な SLA を設定し、コストを最適化するための具体的なアプローチを解説します。

SLA 指標の定義

MCP サーバーの SLA として以下の指標を定義します。

#	SLA 指標	目標値	測定方法	ビジネス影響
1	可用性（Availability）	99.5%	稼働時間 ​/​ 総時間	サービス利用不可による機会損失
2	レスポンス時間（Latency）	P95 < 1 秒	Prometheus ヒストグラム	UX 低下によるユーザー離脱
3	エラー率（Error Rate）	< 1%	エラー数 ​/​ 総リクエスト数	機能不全によるユーザー不満
4	スループット（Throughput）	> 100 req/s	リクエスト処理数 / 秒	ピーク時の処理能力

SLA 監視ダッシュボードの構築

Grafana を使った SLA 監視ダッシュボードの構築例です。

jsonCopy code{
  "dashboard": {
    "title": "MCP Server SLA Dashboard",
    "panels": [
      {
        "title": "Availability (30 days)",
        "targets": [
          {
            "expr": "avg_over_time(up{job=\"mcp-server\"}[30d]) * 100"
          }
        ],
        "thresholds": [
          {
            "value": 99.5,
            "color": "green"
          },
          {
            "value": 99.0,
            "color": "yellow"
          }
        ]
      }
    ]
  }
}

このダッシュボード設定により、30 日間の可用性をリアルタイムで監視し、目標値（99.5%）を下回った場合に視覚的に警告できます。

オートスケーリング設定

Kubernetes を使用する場合、HPA（Horizontal Pod Autoscaler）でコスト効率の高いスケーリングを実現できます。

yamlCopy code# hpa.yaml - オートスケーリング設定
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: mcp-server-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: mcp-server
  minReplicas: 2 # 最小レプリカ数（可用性確保）
  maxReplicas: 10 # 最大レプリカ数（コスト上限）

yamlCopy codemetrics:
  # CPU 使用率ベースのスケーリング
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70 # CPU 70% でスケールアウト

  # カスタムメトリクス（リクエスト数）ベース
  - type: Pods
    pods:
      metric:
        name: mcp_requests_per_second
      target:
        type: AverageValue
        averageValue: '50' # Pod あたり 50 req/s でスケール

この設定により、負荷に応じて自動的にインスタンス数が調整され、コストと性能のバランスが最適化されます。

リソースリクエストとリミットの最適化

Pod のリソース設定を適切に行うことで、コストを削減できます。

yamlCopy code# deployment.yaml - リソース設定
apiVersion: apps/v1
kind: Deployment
metadata:
  name: mcp-server
spec:
  template:
    spec:
      containers:
        - name: mcp-server
          image: mcp-server:latest
          resources:
            # リソース要求（最低限必要なリソース）
            requests:
              memory: '256Mi'
              cpu: '250m' # 0.25 コア
            # リソース上限（最大使用可能リソース）
            limits:
              memory: '512Mi'
              cpu: '500m' # 0.5 コア

requests と limits を適切に設定することで、ノードのリソース利用効率が向上し、インフラコストを削減できます。

コスト分析とレポート

Prometheus のメトリクスを使って、コスト分析を行う PromQL クエリ例です。

promqlCopy code# 時間あたりのリクエスト処理コスト
sum(rate(mcp_requests_total[1h])) /
sum(kube_pod_container_resource_requests{container="mcp-server"})

このクエリにより、リクエスト数あたりのリソースコスト効率を可視化し、スケーリング設定の改善ポイントを特定できますね。

具体例

実運用シナリオ：高負荷時の障害対応

実際の運用現場で発生した高負荷時の障害対応事例を通じて、監視・ログ・アラートの活用方法を具体的に見ていきましょう。

シナリオ概要

以下の図は、障害発生から復旧までの流れを示しています。

mermaidCopy codesequenceDiagram
    participant User as ユーザー
    participant MCP as MCP サーバー
    participant Monitor as 監視システム
    participant Ops as 運用チーム

    User->>MCP: 大量リクエスト
    MCP->>MCP: レスポンス遅延発生
    MCP->>Monitor: メトリクス送信<br/>（P95 > 2秒）
    Monitor->>Ops: アラート通知
    Ops->>Monitor: ダッシュボード確認
    Ops->>MCP: ログ・トレース調査
    Ops->>MCP: スケールアウト実行
    MCP->>User: 正常レスポンス復旧

障害検知フェーズ

Prometheus のアラートが以下のように発火しました。

textCopy codeAlert: SlowResponseTime
Severity: warning
Description: P95 レスポンス時間が 2 秒を超えています
Labels:
  job: mcp-server
  severity: warning
Annotations:
  current_value: 2.43s
  threshold: 2.0s

このアラートにより、運用チームは即座に異常を認識できました。

原因調査フェーズ

Grafana ダッシュボードで以下の指標を確認します。

promqlCopy code# リクエスト数の推移
rate(mcp_requests_total[5m])

このクエリにより、通常時の 3 倍のリクエストが発生していることが判明しました。

promqlCopy code# メソッド別のレスポンス時間分布
histogram_quantile(0.95,
  sum(rate(mcp_response_duration_seconds_bucket[5m])) by (method, le)
)

特定のメソッド（searchFiles）のレスポンス時間が突出して長いことが特定できました。

ログ調査

Elasticsearch で該当時間帯のログを検索します。

jsonCopy code{
  "query": {
    "bool": {
      "must": [
        {
          "match": {
            "method": "searchFiles"
          }
        },
        {
          "range": {
            "@timestamp": {
              "gte": "2025-01-18T14:00:00",
              "lte": "2025-01-18T15:00:00"
            }
          }
        }
      ],
      "filter": [
        {
          "range": {
            "duration": {
              "gte": 2000
            }
          }
        }
      ]
    }
  },
  "sort": [
    {
      "duration": {
        "order": "desc"
      }
    }
  ]
}

このクエリにより、2 秒以上かかったリクエストを抽出し、共通パターンを分析できます。

検索結果から、大量のファイルを対象とした検索リクエストが原因であることが判明しました。

jsonCopy code{
  "traceId": "abc123def456",
  "method": "searchFiles",
  "params": {
    "pattern": "**/*",
    "maxResults": 10000
  },
  "duration": 3542,
  "timestamp": "2025-01-18T14:23:15Z"
}

トレース分析

Jaeger でトレース ID abc123def456 を検索し、処理の内訳を確認します。

textCopy codeTrace: abc123def456
Total Duration: 3542ms

Spans:
  ├─ mcp.searchFiles (3542ms)
  │  ├─ fs.readdir (1200ms)
  │  ├─ fs.stat × 1000 (2100ms)  ← ボトルネック
  │  └─ filter.match (242ms)

トレース分析により、大量の fs.stat 呼び出しがボトルネックであることが明確になりました。

即時対応：スケールアウト

Kubernetes で手動スケールアウトを実行します。

bashCopy code# Pod 数を 2 から 5 に増やす
kubectl scale deployment mcp-server --replicas=5

bashCopy code# スケールアウト完了の確認
kubectl get pods -l app=mcp-server

textCopy codeNAME                          READY   STATUS    RESTARTS   AGE
mcp-server-7d8f9b5c4d-abc12   1/1     Running   0          5m
mcp-server-7d8f9b5c4d-def34   1/1     Running   0          5m
mcp-server-7d8f9b5c4d-ghi56   1/1     Running   0          30s
mcp-server-7d8f9b5c4d-jkl78   1/1     Running   0          30s
mcp-server-7d8f9b5c4d-mno90   1/1     Running   0          30s

スケールアウト後、P95 レスポンス時間が 0.8 秒に改善され、アラートが解消されました。

恒久対策：レート制限の実装

将来的な再発を防ぐため、レート制限を実装します。

typescriptCopy code// express-rate-limit を使ったレート制限
import rateLimit from 'express-rate-limit';

typescriptCopy code// リクエスト数制限の設定
const limiter = rateLimit({
  windowMs: 60 * 1000, // 1 分間
  max: 100, // 最大 100 リクエスト
  standardHeaders: true,
  legacyHeaders: false,
  message: {
    error: 'Too many requests',
    retryAfter: 60,
  },
});

typescriptCopy code// 特定メソッドにのみレート制限を適用
const searchLimiter = rateLimit({
  windowMs: 60 * 1000,
  max: 10, // 検索は 1 分あたり 10 回まで
  keyGenerator: (req) => {
    // クライアント ID でレート制限
    return req.headers['x-client-id'] || req.ip;
  },
});

app.post(
  '/mcp/searchFiles',
  searchLimiter,
  handleSearchFiles
);

この実装により、過度なリクエストを事前に防ぎ、サーバー負荷を制御できます。

脆弱性対応の実例：CVE-2024-XXXXX への対応

実際の脆弱性対応フローを、具体的な CVE を例に解説します。

脆弱性検知

自動スキャンで以下の脆弱性が検出されました。

bashCopy code# yarn audit の出力例
┌───────────────┬──────────────────────────────────────────────────┐
│ Moderate      │ Prototype Pollution in lodash                    │
├───────────────┼──────────────────────────────────────────────────┤
│ Package       │ lodash                                           │
├───────────────┼──────────────────────────────────────────────────┤
│ Patched in    │ >=4.17.21                                        │
├───────────────┼──────────────────────────────────────────────────┤
│ Dependency of │ express                                          │
├───────────────┼──────────────────────────────────────────────────┤
│ Path          │ express > lodash                                 │
├───────────────┼──────────────────────────────────────────────────┤
│ More info     │ https://github.com/advisories/GHSA-xxxx-xxxx-xxx │
└───────────────┴──────────────────────────────────────────────────┘

影響範囲評価

まず、該当パッケージの使用箇所を特定します。

bashCopy code# lodash の使用箇所を検索
grep -r "from 'lodash'" src/
grep -r "require('lodash')" src/

typescriptCopy code// 検出された使用箇所の例
import { merge } from 'lodash';

// ユーザー入力をマージする処理（脆弱性の影響を受ける可能性あり）
function updateConfig(userInput: any) {
  const config = merge({}, defaultConfig, userInput);
  return config;
}

このコードは外部入力を受け取るため、プロトタイプ汚染の脆弱性が悪用される可能性があります。

パッチ適用

依存パッケージを更新します。

bashCopy code# 特定パッケージのアップデート
yarn upgrade lodash@^4.17.21

bashCopy code# yarn.lock の確認
cat yarn.lock | grep -A 5 "lodash@"

textCopy codelodash@^4.17.21:
  version "4.17.21"
  resolved "https://registry.yarnpkg.com/lodash/-/lodash-4.17.21.tgz"
  integrity sha512-v2kDEe57lecTulaDIuNTPy3Ry4gLGJ6Z1O3vE1krgXZNrsQ+LFTGHVxVjcXPs17LhbZVGedAJv8XZ1tvj5FvSg==

セキュリティテストの実施

脆弱性が修正されたことを確認するテストを実装します。

typescriptCopy code// セキュリティテストの例
import { merge } from 'lodash';
import { describe, it, expect } from '@jest/globals';

describe('Prototype Pollution Protection', () => {
  it('should not pollute Object prototype', () => {
    const maliciousInput = JSON.parse(
      '{"__proto__":{"polluted":"yes"}}'
    );
    const config = merge({}, maliciousInput);

    // プロトタイプが汚染されていないことを確認
    expect(({} as any).polluted).toBeUndefined();
  });

  it('should not pollute via constructor', () => {
    const maliciousInput = JSON.parse(
      '{"constructor":{"prototype":{"polluted":"yes"}}}'
    );
    const config = merge({}, maliciousInput);

    expect(({} as any).polluted).toBeUndefined();
  });
});

bashCopy code# テストの実行
yarn test security.test.ts

デプロイと検証

更新をステージング環境にデプロイし、動作確認を行います。

bashCopy code# ステージング環境へのデプロイ
kubectl set image deployment/mcp-server mcp-server=mcp-server:v1.2.1 -n staging

bashCopy code# デプロイ完了の確認
kubectl rollout status deployment/mcp-server -n staging

bashCopy code# 脆弱性スキャンで修正を確認
trivy image mcp-server:v1.2.1 --severity MEDIUM,HIGH,CRITICAL

問題がないことを確認後、本番環境にデプロイします。

bashCopy code# 本番環境へのデプロイ（段階的ロールアウト）
kubectl set image deployment/mcp-server mcp-server=mcp-server:v1.2.1 -n production
kubectl rollout pause deployment/mcp-server -n production

# 一部の Pod で動作確認後、再開
kubectl rollout resume deployment/mcp-server -n production

コスト最適化の実例：月額コストを 30% 削減

実際のコスト最適化プロジェクトの事例を紹介します。

初期状態の分析

Kubernetes クラスタのコスト内訳を分析しました。

#	リソース	月額コスト	使用率	改善余地
1	MCP サーバー Pod（常時 5 インスタンス）	$450	CPU: 35% / Mem: 45%	★★★
2	データベース（固定インスタンス）	$200	CPU: 60% / Mem: 70%	★☆☆
3	ロードバランサー	$50	N/A	☆☆☆
4	ストレージ（ログ保存）	$100	80%	★★☆
5	ネットワーク転送	$80	N/A	★☆☆

合計月額コストは $880 で、MCP サーバー Pod の低い使用率が最大の改善ポイントでした。

最適化施策 1：適切なリソースサイジング

実際の使用量に基づいてリソース設定を見直しました。

yamlCopy code# 最適化前のリソース設定
resources:
  requests:
    memory: '512Mi'
    cpu: '500m'
  limits:
    memory: '1Gi'
    cpu: '1000m'

Prometheus のメトリクスを分析し、実際の使用量を確認します。

promqlCopy code# 過去 30 日間の最大メモリ使用量
max_over_time(container_memory_working_set_bytes{container="mcp-server"}[30d]) / 1024 / 1024

結果: 平均 200Mi、最大 300Mi

promqlCopy code# 過去 30 日間の最大 CPU 使用量
max_over_time(rate(container_cpu_usage_seconds_total{container="mcp-server"}[5m])[30d:])

結果: 平均 0.15 コア、最大 0.35 コア

yamlCopy code# 最適化後のリソース設定
resources:
  requests:
    memory: '256Mi' # 512Mi → 256Mi
    cpu: '250m' # 500m → 250m
  limits:
    memory: '512Mi' # 1Gi → 512Mi
    cpu: '500m' # 1000m → 500m

この変更により、1 Pod あたりのコストが約 50% 削減されました。

最適化施策 2：オートスケーリングの導入

固定 5 インスタンスから、需要に応じたスケーリングに変更します。

yamlCopy code# HPA 設定（再掲）
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: mcp-server-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: mcp-server
  minReplicas: 2 # 最小 2（高可用性確保）
  maxReplicas: 8 # ピーク時の最大
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70

時間帯別の負荷パターンを分析すると、以下のような傾向が見られました。

• 営業時間（9-18 時）: 平均 4 Pod 必要
• 夜間（18-9 時）: 平均 2 Pod で十分

オートスケーリング導入により、平均 Pod 数が 5 → 3 に削減され、コストが 40% 削減されました。

最適化施策 3：ログ保存期間の最適化

ログストレージのコストを削減するため、保存ポリシーを見直します。

yamlCopy code# Elasticsearch のインデックスライフサイクル設定
PUT _ilm/policy/mcp-logs-policy
{
  "policy": {
    "phases": {
      "hot": {
        "actions": {
          "rollover": {
            "max_size": "50GB",
            "max_age": "1d"
          }
        }
      },
      "warm": {
        "min_age": "7d",
        "actions": {
          "allocate": {
            "number_of_replicas": 1
          }
        }
      },
      "delete": {
        "min_age": "30d",
        "actions": {
          "delete": {}
        }
      }
    }
  }
}

この設定により、以下の効果が得られました。

• 7 日以降のログはレプリカ数を削減（高速ストレージから低速ストレージへ移行）
• 30 日以降のログは自動削除
• ストレージコストが $100 → $60 に削減（40% 削減）

最適化結果のまとめ

各施策によるコスト削減効果を以下の表にまとめます。

#	施策	削減額	削減率
1	リソースサイジング最適化	$225	50%
2	オートスケーリング導入	$90	20%
3	ログ保存期間最適化	$40	40%
4	合計削減額	$355	40%

最終的な月額コストは $880 → $525 となり、目標の 30% 削減を上回る 40% の削減を達成しました。

重要なのは、これらの最適化によって SLA（可用性 99.5%、P95 レスポンス < 1 秒）は維持されており、品質を損なわずにコスト削減を実現できたことです。

まとめ

MCP サーバーの運用管理は、監視・ログ・セキュリティ・コストの各側面を統合的に最適化することが成功の鍵となります。

本記事では、以下の実務ノウハウをご紹介しました。

監視指標とアラート設計では、Prometheus と Grafana を活用し、可用性・レスポンス性能・エラー率といった重要指標を優先的に監視する方法を解説しました。適切なアラートルールにより、障害を早期に検知し、迅速な対応が可能になります。

ログとトレーシングの統合管理については、Winston による構造化ログと OpenTelemetry による分散トレーシングの実装方法を示しました。トレース ID でログとトレースを相関付けることで、複雑な処理フローの追跡が容易になるでしょう。

脆弱性対応フローでは、Yarn Audit や Trivy を使った自動スキャン、Renovate による自動パッチ適用、そして実際の CVE 対応事例を通じて、セキュリティリスクを最小化する運用体制を構築する方法を説明しました。

SLA 管理とコスト最適化では、適切な SLA 指標の定義、Kubernetes のオートスケーリング、リソースサイジングの最適化により、品質を維持しながらコストを削減する手法をお伝えしました。実例では 40% のコスト削減を達成しています。

これらの運用ノウハウを組み合わせることで、MCP サーバーを安定的かつ効率的に運用できる基盤が整います。まずは監視とログの整備から始め、段階的にセキュリティ対策やコスト最適化に取り組んでいくことをおすすめいたします。

運用は継続的な改善活動ですので、メトリクスを定期的にレビューし、ビジネス要件の変化に応じて柔軟に調整していくことが大切ですね。

関連リンク

• Prometheus 公式ドキュメント
• Grafana ダッシュボード作成ガイド
• OpenTelemetry Node.js SDK
• Winston ロガー
• Trivy セキュリティスキャナー
• Renovate 自動アップデート
• Kubernetes HPA ドキュメント
• Elasticsearch ILM ポリシー
• CVSS 脆弱性評価基準
• Express Rate Limit