何を監視すべきか
本番環境のMCPサーバーでは、4つの観点からの監視が必要です。可用性(サーバーが起動しているか)、パフォーマンス(応答速度はどうか)、正確性(結果が正しいか)、そしてリソース消費(CPU・メモリ・ネットワーク帯域をどれだけ使っているか)です。
可用性の監視はすべての基本です。サーバーが落ちたり応答しなくなったりすれば、他の指標は意味を持ちません。サーバーが起動して接続を受け付けられるかを確認するシンプルなヘルスチェックエンドポイントを置くだけでも、最も致命的な障害クラスを捕捉できます。
パフォーマンス監視ではツール呼び出しの応答時間を追跡します。開発時は200msで応答していたMCPサーバーが、本番負荷では5秒かかるようになるというのは、スケール時にしか現れない典型的なパフォーマンス問題です。応答時間のパーセンタイル(p50、p95、p99)を時系列で追えば、ユーザーに影響が出る前に劣化を察知できます。
ヘルスチェック
MCPサーバーのヘルスチェックは「プロセスが動いている」という確認だけでは不十分です。データベース、API、ファイルシステムといった外部依存に接続できているか、シンプルなツール呼び出しをエンドツーエンドで実行できるかまで確かめる必要があります。プロセスは生きていてもデータベースに繋がらないサーバーは実質ダウンしているのと同じであり、監視もそのように扱うべきです。
ヘルスチェックは問題を素早く検知できる程度の頻度で実行しつつ、リソースを過剰に消費しない頻度に保つのが理想です。多くの本番MCPサーバーでは30秒ごとが妥当な初期値となります。重要度の高いサーバーであれば、もっと短い間隔も検討する価値があります。
エラー率の追跡
本番環境のMCPサーバーには、必ず一定のベースラインエラー率が存在します。引数の不正、外部サービスの障害、エッジケースなどによってツール呼び出しは時折失敗します。エラー率を継続的に追跡してベースラインを把握しておけば、その水準を大きく超えた瞬間に「何かが変わった」と気付き、調査を開始できます。
エラーをタイプ別に分類すると診断が容易になります。認証エラーは資格情報の問題を、タイムアウトはパフォーマンス低下や外部サービスの遅延を、バリデーションエラーはAIモデルがツールを呼び出す方法の変化を示唆します。それぞれ原因が異なり、対処方法も異なります。
リソース監視
MCPサーバーはメモリとCPUを消費し、本番環境ではこれらを他のサービスと共有します。メモリリークがあるサーバーは徐々にRAMを食い潰し、最終的にはOSやコンテナオーケストレータに強制終了されます。メモリ使用量を時系列で追跡しておけば、リークが障害につながる前に発見できます。
CPU使用率の急上昇は、正当な高負荷によるものか、エラーハンドリングの無限ループのような病的な挙動によるものかのいずれかです。CPUスパイクとツール呼び出しのパターンを突き合わせることで、両者を見分けられます。
アラート戦略
効果的なアラートは、緊急性の高い事象(サーバー停止)と参考情報(エラー率が10%上昇)を明確に区別します。アラート疲れは現実の問題であり、緊急性の低い通知が大量に届くチームは、やがてすべてのアラートを無視するようになります。
呼び出しに値するアラート: サーバー停止、致命的閾値を超えたエラー率、外部依存への接続が完全に切れた状況。チケット起票に値する通知: 緩やかなパフォーマンス劣化、通常ベースラインを上回るエラー率の増加、リソース上限への接近。それ以外はダッシュボードで可視化するに留め、通知を発生させないのが望ましい運用です。
複数のMCPサーバーを管理するチームにとっては、各サーバーを個別に監視するよりも、全サーバーの健全性を一元的に表示するダッシュボードを用いる方がはるかに扱いやすくなります。Prometheus、Grafana、Datadogといった一般的な監視ツールは、他のアプリケーションメトリクスと並んでMCPサーバーのメトリクスも収集できるよう設定可能です。