Article by: Sasha Blumenfeld, Miguel Betegón
本日（2025/8/14）より、MCP SDK 実装に計測コードを1行入れるだけで、サーバーサイド JavaScript SDK ベースの MCP サーバーの多くを計測できるようになりました。
これを導入すれば、MCP 実装全体にわたって、プロトコルの利用状況、クライアントの利用状況、トラフィック、ツールの利用状況、パフォーマンスといった詳細を確認できるようになります。
2025年の初めに私たち自身の MCP（Model Context Protocol）サーバーを公開した際の目的はシンプルでした。AI エージェントが Sentry のコンテキストを使って、ユーザーのアプリケーション上の問題をリアルタイムにデバッグできるようにすることです。
共同創業者の David Cramer も、有名な辛口コメントをシェアしているように、標準が頻繁に変わる新技術を前提に開発するのは簡単ではありません。
ここ数か月の間に、MCP が Streamable HTTP に標準化され、OAuth サポートが改善され、新しい仕様（spec）が導入されるなど、（控えめに言っても）多くの「調整」が行われていくのを見てきました。
ユーザーが簡単に導入できること、そしてユーザーベースが直面する複雑なユースケースをサポートすることを念頭に、MCP サーバーを「最先端」で構築してきました。リモートホストされるステートフルな MCP サーバー、OAuth のサポート、Seer や自然言語検索といった機能の追加など、最先端の要素に踏み込むことには、モニタリングとオブザーバビリティの面で固有の課題が伴いました。
それに加えて、Sentry の規模もあり、MCP サーバーの利用は非常に速いペースで増加しました。数千のユーザーが利用し、月間 5,000 万リクエスト（そして増加中）に達しています。
Sentry MCP サーバーを構築する中で、MCP サーバー監視におけるギャップがどこにあるのかを把握し始めました。エラーの詳細や MCP 内で現れる厄介なエッジケースの詳細を捉えるのは容易ではありません。ツール呼び出しにおけるパフォーマンス問題は診断が難しく、さらにツール呼び出しの特定の入力・出力に関する課題も、MCP の監視という観点では現時点で未成熟な領域です。
加えて、上流システム側でのプラットフォーム障害という、よくある「楽しさ」も経験しました。最も厄介なケースでは、ユーザーがタイムアウトするというランダムな報告を受け始めました。リクエストが結果もエラーもなく突然終わってしまうのです。私たちの側から見る限り何も問題がないように見え、可視性がない状態では、頼れるのは連絡してきたユーザーだけでした。どれだけのユーザーが影響を受けたのか、どの MCP クライアントから来ているのかすら、把握する術がありませんでした。
MCP サーバーを作る中で、監視するための独自ツールも作り始めました。そうしている間に、MCP は「一大ムーブメント」になり、自分たちの用途のために作ったツールは、MCP を前提に AI ツールを作っている開発者にとっても有用だということが分かりました。
そこで私たちは、MCP サーバー監視を作り、MCP サーバーが抱えるあらゆるエッジケース、誰がそれを使っているのか、どのように動いているのか（あるいは動いていないのか）を可視化でき、そして壊れたときにはユーザーから連絡が来るのを待つことなく、アラートを受け取れるようになります。
MCP server monitoring はベータ版で、サーバーサイドの JavaScript SDK を利用している方なら誰でも使えます。必要なのは Sentry アカウントと、span を送信し始めるための数行のコードだけです。
MCP サーバーに設定すれば、次のようなものが得られます。
- MCP サーバーのパフォーマンスをさまざまな観点から俯瞰できる明確な概要と、そこからさらに深掘りできる導線（組み込みの探索パス）です。たとえば、クライアントのセグメンテーション、トランスポート別の分布、エラーが最も多いツール、最も多く読み取られているリソース、最も遅いツールなど、ほかにも確認できます。
- 各 JSON-RPC リクエスト単位までトレースできます。ツール呼び出しの引数と結果も含まれます。
- エラー。MCP プロトコルはエラーを投げずにサーバー内で処理し、「何か問題がありました」といったメッセージを返すようになっています。これは良いことですが、それがエラーである以上、私たちはログに残し、原因となったサーバー内の該当箇所に紐づけたいと考えています。
また、Sentry は OpenTelemetry をサポートしているため、別の MCP サーバーライブラリを使っていても、そのライブラリが MCP の OpenTelemetry semantic conventions に従っていれば、これらの機能を追加設定なしですぐに利用できます。
ユーザーは実際に MCP サーバーを何に使っているのか
MCP サーバーを構築した。ツールは動き、リソースも流れ、いくつかのクライアントも接続している。でも、先週ノリで追加した新しい tool call のたびに、不安になるはずです。そもそも誰か使ってるのかと。
適切に計測できていなければ、それは推測でしかありません。
誰がサーバーを呼び出し実際に何を使っているのか
MCP サーバーは複数のトランスポート（stdio、HTTP、SSE）を横断して、1分あたり数千リクエストを処理することもあります。ログにはメソッド名は出ますが、コンテキストがありません。tools/call は至るところで見えるけれど、どのツールなのか、どのクライアントからなのか。、どのトランスポート経由なのかが分からない。
MCP インストルメンテーションがなければ、ログを解析して推測するしかありません。
- Claude Code は VS Code よりも計算ツールを使用していますか？
- HTTP クライアントは STDIO クライアントとは異なる方法でサーバーを使用していますか？
- 実際に読み取られているリソースはどれですか？
当社の MCP モニタリングにより、明確な内訳が得られます。
これで分かります。Cursor が STDIO 経由で file_search を大量に使っていること、さらに信頼性の統計まで確認できます。
クライアントがサーバーを見限る前に壊れた連携を検知する
MCP サーバー v1.2.0 をリリースし、リソースのキャッシュを改善しました。ローカルテストでは問題なし。CI でもエラーは出ていない。ところが 3 日後、自作のリクエスト集計を見ていると、何かおかしいことに気づきます。
デプロイ以降、resources/read のボリュームが 60% 減っている。
適切に計測できていないと、疑問だけが残ります。
- クライアントがリソースをまったく使わなくなった？
- サイレントに失敗するモードがある？
- 別のエンドポイントにフォールバックしている？
- 新しいキャッシュロジックが原因？
MCP の計測が入っていれば、これは即座に検知され、Sentry からメールが届きます。
CacheKeyError: undefined cache namespace in method “resources/read”.
UI を見ると、streamable HTTP transport で起きていることが分かります。つまり、新しいキャッシュ変更によって HTTP transport での resource 読み取りが壊れていた一方で、STDIO と SSE は影響を受けていませんでした。キャッシュの namespace の扱いを修正すると、resources/read のボリュームはクライアントが見切りをつけて別ツールへ移行する前に、通常どおりに戻りました。
ボットの悪用でサーバーが焼ける前に止める
インフラのメトリクス上は「すべて正常」。CPU は高いのに 5XX エラーは出ていません。サーバーは技術的には、ゴミみたいなリクエストに対しても含めて、すべてに応答してしまっているのです。
不明なクライアントが HTTP transport 経由で、ツール subtract にリクエストを送っており、失敗率が 100% になっていることが分かります。ここまで分かれば、適用すべき緩和策を検討できます。
使われない機能に何週間も費やす前に、次に作るべきものを把握する
あなたには 4 つの機能要望があるとします。
- 通知のための webhooks サポートを追加する
- file_search ツールのパフォーマンスを改善する
- 大きなレスポンスのストリーミングを追加する
- プロンプトテンプレートを実装する
利用データがなければ、どれが最もインパクトがあるかは推測するしかありません。誰も使わない webhooks を 2 週間かけて作ってしまう一方で、file_search のパフォーマンス問題が最もアクティブなクライアントを苛立たせ続けるかもしれません。
この問題は、Sentry の MCP 監視チャートを見ることで解決できます。どのツールが最も使われているかが分かるので、そのツールのパフォーマンス改善に集中できます。
MCP server monitoring は今後どう進化していくのか
MCP は成長を続ける仕様でありサービスでもあります。新しい機能や機能性が継続的に追加されており、その上、クライアントもより高度化しています。Cursor が 1.0 をリリースし、その中で Streamable HTTP と OAuth のサポートを標準化したのは、そう昔のことではありません。
さらに、多くの開発者は MCP サーバーをこれまでとは違う新しい形で動かし始めています。Cloudflare は Workers プラットフォーム全体にわたって MCP とエージェントのサポート機能を追加し続けており、Vercel は Next.js と併用できるツール群をリリースしました。また、ゼロから自前で MCP サーバーを実装することも、以前よりずっと簡単になっています。
今後数か月で、MCP server monitoring にはさらに中核的な監視機能を追加していきます。たとえば Trace Propagation です。これにより、MCP サーバーの下流にあるサービスへトレース識別子を引き継げるようになり、パフォーマンスの可視性をより高められます。
また、プラットフォーム対応も拡張したいと考えています。たとえば Cloudflare の McpAgent への対応です。
最後に、MCP サーバーの言語対応を拡張し、Python も対象にしていく予定です。
これまで通り、コミュニティで起きていることを注視し、ユーザーが向かう新しい領域へ柔軟に舵を切れるようにしていきます。MCP も例外ではありません。
試してみませんか？
始めるには、MCP のドキュメントに沿ってサーバーを wrap し、その後に Insights > AI > MCP へ進んでください。追加の設定は不要で、手動でダッシュボードを作る必要もなく、ユーザーから「壊れている」と言われるのを待つ必要もありません。
もし Sentry アカウントをお持ちでない場合は無料で始められます。
Original Page: You built the MCP server. Now track every client, tool, and request with Sentry.
IchizokuはSentryと提携し、日本でSentry製品の導入支援、テクニカルサポート、ベストプラクティスの共有を行なっています。Ichizokuが提供するSentryの日本語サイトについてはこちらをご覧ください。またご導入についての相談はこちらのフォームからお気軽にお問い合わせください。
