MCPサーバーは黙って壊れる。ダッシュボードは教えてくれない。

MCPサーバーはすべてのリクエストに200 OKを返す。ダッシュボードはグリーン。ユーザーはフラストレーションを感じている。

ここではHTTPステータスコードは重要なことを測っていない。ツールはデータを返した。それは正しいツールだったか？レスポンスは有用だったか？モデルは実際にそれを使ったか？

Anthropicが公開したエージェントのツール利用評価（MCP Bench、2025年後半）では、6つ以上のツールを持つ人気のMCPサーバーで、ツール選択エラー率は28%から46%の間だった。本番でも同じパターンが出る。アップタイム完璧、200ms以下のレイテンシ、5xxエラーゼロ——なのにモデルはほぼ半分の時間、間違ったツールを呼んでいる。

サーバーは知らない。チームも知らない。ユーザーはただAIが悪いと言う。

それがサイレント障害だ。MCPサーバーは従来のヘルスチェックをすべてパスしながら、すべての呼び出しで間違った質問に答え得る。

REST APIにとって動くとは、有効なリクエストを受け付け正しいレスポンスを返すことだ。それを検証するツールは何十年も存在する。

MCPサーバーにとって動くとは、4ステップの連鎖だ。モデルが正しいツールを選ぶ。正しいパラメータを送る。有用なレスポンスを受け取る。それを回答に組み込む。各ステップは独立して失敗する。従来の監視にはどれも現れない。

間違ったツール？200。スキーマ検証は通るがユーザーの意図を外したパラメータ？200。レスポンスが無視された？200。

ダッシュボードでは100%成功、本番では40%成功ということがあり得る。そのギャップでユーザーは「AIが動かない」と言う——そしてSREメトリクスが何と言おうと、彼らは正しい。

従来のメトリクスが不十分と認めたら、問いは代わりに何を測るかになる。5つある。

**ツール選択精度。** `search_invoices`と`list_documents`があって、ユーザーが「先月の請求書」を求めたら、どちらが呼ばれる？意図された選択と実際の選択のギャップを追跡せよ。MCPオブザーバビリティで最も明らかにするメトリクスだ。

**パラメータ妥当性。** パラメータがスキーマ検証を通ったかではない——それは当たり前だ。日付範囲はユーザーの要求と一致したか？検索クエリは意図を捉えたか？

**レスポンス利用率。** モデルは実際にレスポンスを使ったか？50行返してモデルが回答でどれも参照しなければ、ツールの説明が悪いか、フォーマットが悪いか、データが的外れだ。

**エラー回復率。** 呼び出しが失敗したとき、モデルは修正したパラメータで再試行するか、ツールを切り替えるか、諦めるか？回復パターンはエラーメッセージが役立つかを示す。

**成功した呼び出しあたりのコスト。** 呼び出しあたりのコストではない。有用な回答を生んだ呼び出しあたりのコストだ。無駄なリトライと誤ツール呼び出しにより、実コストはAPI原価の3〜5倍になることが多い。

この5つは、従来のすべてのメトリクスを合わせたものよりMCPサーバーの健全性について多くを語る。

Datadog、New Relic、Grafanaは得意分野で優秀だ。レイテンシ分布、エラー率、スループット、リソース利用率を追跡する。呼び出し元がブラウザやモバイルアプリで、確定的なリクエストを送るAPIには正しい形だ。

MCPサーバーの呼び出し元は確定的ではない。推論時に決定を下すモデルだ。障害モードは「リクエストタイムアウト」ではない。「モデルがこれが正しいツールだと判断し、実際は違った」だ。これは意思決定品質の問題であり、従来のAPMはそれを測るようにはできていない。

具体的には、エージェントに`get_customer`と`search_customers`があり、モデルが常に推測IDで`get_customer`を選ぶなら、p99はフラットのまま、エラー率もフラット、そしてあらゆるユーザー対話が失敗に終わる。既存のツーリングには発する信号がない。

モデルとツールの間にオブザーバビリティ層が必要だ——ユーザー意図、ツール選択、パラメータ、レスポンス利用率を相関付けられる層だ。従来のAPMは床だ。MCPサーバーにとっては全体像の半分にも満たない。

始めるための具体的な3つ。すべてを一度に変える必要はない。

**1. すべての呼び出しを完全なプロンプト文脈付きでログに記録する。** ツール名とパラメータだけではない。呼び出しに至った会話、システムプロンプト、ユーザーの直前のメッセージ。文脈なしには選択が正しかったか評価できない。

**2. 意図されたツールと選択されたツールを追跡する。** グラウンドトゥルースが必要だ——サンプルへの手動ラベル、ユーザーの👍👎シグナル、ヒューリスティックルール（「請求書|課金|支払い」にマッチするユーザー質問が`list_contacts`呼び出しで終わっていたら、それは欠陥だ）。粗いヒューリスティックでも何もないよりましだ。

**3. レスポンス利用率を測る。** ツールが返したものとモデルの最終回答に現れたものを比較する。大きなギャップは、レスポンスフォーマットが悪いか、データが的外れか、ツール説明がモデルの利用を助けていないかだ。

これら3つのシグナル——呼び出し文脈、選択精度、レスポンス利用率——は、MCPサーバーが本当にユーザーを助けているかを教える。ファイブナインのアップタイムダッシュボードはプロセスが生きているかを教える。違う問いだ。