MCPサーバーを監視しないことの隠れたコスト

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

この断絶は誰もが認めるよりずっと一般的だ。HTTPステータスコードは重要なことを測定していない。ツールはデータを返した——でもそれは正しいツールだったか？レスポンスは有用だったか？LLMは実際にそれを使ったか？

MCPデプロイメントでツール呼び出しの40%が完全に間違ったツールだったケースを見たことがある。サーバーはすべての従来メトリクスで健全だった。レイテンシ200ms以下。5xxエラーゼロ。99.99%アップタイム。なのにほぼ半分の時間、LLMはユーザーの質問に答えられないツールを呼んでいた。

サーバーは知らなかった。チームも知らなかった。ユーザーはただAIが悪いと思っていた。

これがサイレント障害の問題だ。MCPサーバーは何を測定するかによって、同時に「完璧に動作している」と「完全に壊れている」の両方になり得る。そして今、ほとんどのチームは間違ったものを測定している。

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

MCPサーバーにとって「動く」とは、少なくとも4つのことが正しく起こる連鎖だ。LLMが正しいツールを選び、正しいパラメータを送り、有用なレスポンスを受け取り、それを正しく回答に組み込む。各ステップが独立して失敗し得る。そしてこれらの障害はどれも従来の監視には現れない。

LLMが間違ったツールを選んだ？サーバーは200を返す。パラメータは技術的に有効だが意味的に間違っている？サーバーは200を返す。レスポンスは正確だがLLMがそれを無視した？サーバーは200を返す。

ダッシュボードで100%の成功率を示しながら、本番では40%の実際の成功率ということがあり得る。このギャップにユーザーのフラストレーションが住んでいる。人々が「AIが動かない」と言うとき、本当に言いたいのは「ツールが重要な障害を捕捉するよう計装されていない」ということだ。

従来のメトリクスが不十分だと受け入れたら、次の問いは：代わりに何を測るべきか？

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

パラメータ妥当性率。「パラメータがスキーマ検証を通ったか」ではない——それは当たり前だ。パラメータは意味的に理にかなっていたか？

レスポンス利用率。誰も追跡していないが、おそらく最も重要なもの。LLMはレスポンスを実際に使ったか？50行のデータを返してLLMがすべて無視したなら、何かがおかしい。

エラー回復率。ツール呼び出しが失敗したとき、LLMは修正したパラメータで再試行するか、別のツールを試すか、単に諦めるか？

成功した呼び出しあたりのコスト。呼び出しあたりのコストではない——成功した呼び出しあたりのコストだ。間違ったツール選択や無駄な呼び出しを含めると、実際のコストはAPIの生コストが示す3〜5倍になることが多い。

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

何を考えているかわかる。「もうDatadogがある。オブザーバビリティはある。」おそらくそうだろう。そしておそらくこの用途には無意味だ。

Datadog、New Relic、Grafana——やっていることに関しては優秀だ。レイテンシ分布、エラー率、スループット、リソース使用率を追跡する。呼び出し元が確定的なリクエストを行うWebブラウザであるAPIには完璧だ。

しかしツールを呼ぶLLMはWebブラウザではない。意思決定を行う推論エンジンだ。障害モードは「リクエストがタイムアウトした」ではなく「モデルがこれが正しいツールだと判断したが、そうではなかった」だ。これはレイテンシの問題ではない。意思決定品質の問題だ。そして従来のAPMツールで意思決定品質を測定するよう設計されたものはない。

車がなぜ常に間違った目的地に行くのかを速度計で診断するようなものだ。速度計は正常に動く。ただ、本当に壊れているものを測定していないだけだ。

LLMとツールの間に新しいオブザーバビリティ層が必要だ。ユーザーの意図、ツール選択、パラメータ、レスポンスの間の意味的関係を理解するものだ。従来のAPMは土台だ。しかしMCPサーバーにとっては、全体像の半分にも満たない。

では具体的にどうするか？すべてを一度に変える必要はない。3つのことから始めよう。

第一に、すべてのツール呼び出しを完全なプロンプトコンテキストとともにログに記録する。ツール名とパラメータだけではなく、呼び出しに至った会話全体だ。このコンテキストなしには、選択が正しかったかどうか評価できない。

第二に、選択されたツールと意図されたツールを追跡する。これにはグラウンドトゥルースが必要だ——手動ラベリング、ユーザーフィードバックシグナル、ヒューリスティックルール。粗いヒューリスティックでもないよりましだ。ユーザーが請求書について質問してLLMが連絡先ツールを呼んだら、それは自動検出できるツール選択エラーだ。

第三に、レスポンス利用率を測定する。ツールが返したものとLLMのレスポンスに実際に現れたものを比較する。大きなギャップがあれば——多くのデータが返されて、ほとんど使われていない——シグナルを見つけたことになる。

これら3つのシグナル——呼び出しコンテキスト、選択精度、レスポンス利用率——は、すべての従来メトリクスを合わせたものよりMCPサーバーの実際のパフォーマンスについて多くを語る。サーバーが稼働していることを知ることと、サーバーが本当にユーザーを助けていることを知ることの違いだ。

このオブザーバビリティ層を今構築するチームは、圧倒的な優位性を持つことになる。技術が難しいからではない——難しくない。提供される洞察が、他の全員が見ているものよりはるかに豊かだからだ。競合がレイテンシダッシュボードを眺めてファイブナインのアップタイムに満足している間に、あなたはツールが本当に機能しているかどうかを知ることになる。