可観測性とモニタリングの違いは何か？

モニタリングは「既知のメトリクスを継続的に監視すること」。可観測性は「未知の障害が発生したとき、その原因を推論できる状態にすること」。MCPのような複雑な分散システムでは、既知のエラーだけでなく、未経験の障害パターンも発生するため、可観測性が特に重要だ。

小規模プロジェクトでも可観測性は必要か？

はい、必要だ。最低限trace_id付きの構造化ログを入れるだけで、障害解析時間を数時間から数分に短縮できる。Grafana Cloudの無料枠（50GBログ/月）で十分カバーできるため、初期コストはほぼゼロだ。

MCPログにはどこまでの情報を記録すべきか？

GDPRなどコンプライアンス上の理由から、MCPログにはPII（個人識別情報）を含めてはならない。tool_name・event・trace_id・latency_msのみを記録し、パラメーターの内容はハッシュ化または除外することを推奨する。業務データ（請求書内容・従業員情報等）はログに残さないこと。

実践ガイド 2026-04-24 14 min read

MCPサーバー可観測性入門ガイド 2026 — ログ・分散トレーシング・アラート設計の実践

MCPサーバーが本番環境で稼働し始めると、最初の壁は「ブラックボックス問題」だ——ツール呼び出しが失敗したとき、原因がMCPサーバー側にあるのか、クライアント側にあるのか、ネットワーク側にあるのかを特定できない。KanseiLinkが225サービスの実測データで観察したところ、成功率91%・平均レイテンシ163msを達成するトップ層のサービスに共通する特徴の一つが「可観測性への投資」だ。本記事では、30分で始められる実践的な可観測性設計を解説する。

91%

KanseiLink実測
トップ層成功率ベンチマーク

MCPに必要な
監視層の数

構造化ログの
最低必須フィールド数

1. なぜMCPサーバーに可観測性が必要か

従来のWeb APIとMCPサーバーの大きな違いは呼び出し元が人間ではなくAIエージェントという点だ。エージェントは障害発生時に「エラーメッセージを読んでデバッグする」ことができない——ただリトライするか、タスクを失敗させるだけだ。可観測性がなければ、エージェントが静かに失敗し続けても開発者は気づかない。

可観測性が特に重要な3つの理由を整理する。

① ブラックボックス問題の解消——エージェントのツール呼び出しがどの層で失敗したかを特定できる。MCPプロトコル層・APIバックエンド層・ネットワーク層を分離して観察できると、根本原因の特定が数時間から数分に短縮される
② コンプライアンス要件（GDPR・SOC2）——2026年現在、日本でもGDPR相当の個人情報保護規制が強化されている。MCPを通じてアクセスされた業務データの監査証跡は、コンプライアンス上の必須要件になりつつある
③ コスト最適化——どのツールが遅いか、無駄なリトライがどこで発生しているかを把握することで、LLMのトークン消費とAPIコスト削減に直結する。KanseiLinkの分析では、可観測性なしのMCP運用はリトライループによる余分なコストが平均15〜30%発生している

2. 3層監視モデル

MCPサーバーの可観測性は、以下の3層に分けて設計することを推奨する。各層を独立して監視することで、障害の伝播を正確に追跡できる。

Layer 1 — トランスポート層

MCPプロトコルそのものの健全性を監視する。

Handshake Success Rate——MCP接続確立の成功率。90%未満は設定問題を疑う
Session Duration——セッション継続時間の分布。異常に短いセッションはネットワーク断を示す
JSON-RPC Error Code Distribution——-32700（Parse Error）・-32601（Method Not Found）・-32603（Internal Error）の比率

Layer 2 — ツール層

個別ツール呼び出しのパフォーマンスと信頼性を監視する。

ツール別成功率——どのtool_nameが失敗しているかを特定。KanseiLinkのSlack MCPデータでは成功率91%・平均163ms
レイテンシヒストグラム（P50/P95/P99）——P95が3,000msを超えるとエージェントのタイムアウトリスクが上昇
エラータイプ分類——api_error / invalid_input / timeout / rate_limit の比率分析

Layer 3 — ビジネス層

上流のエージェントタスクへの影響を監視する。

エージェントタスク完了率——MCPツール失敗がどれだけエージェントタスクの失敗につながっているか
リトライバジェット消費率——エージェントが費やしたリトライ回数とトークンコストの相関
End-to-End Latency——ユーザー入力からMCPツール結果返却までの全体時間

3. 構造化ログ設計：5つの必須フィールド

MCPサーバーのログは必ず構造化JSON形式で出力すること。平文ログは正規表現でパースする必要があり、スケールしない。最低限以下の5フィールドを含める。

フィールド	型	説明	例
`trace_id`	string (UUID)	1リクエストを一意に識別。複数サービスにまたがるトレースの基点	`"a3f7b2c1-..."`
`session_id`	string	エージェントセッション単位の識別子。1セッションの全ツール呼び出しを紐付け	`"sess_x9k2m..."`
`tool`	string	呼び出されたMCPツール名。ツール別のパフォーマンス分析に必須	`"search_invoices"`
`event`	enum	イベント種別: call_start / success / error / timeout	`"success"`
`latency_ms`	number	ツール呼び出しのレイテンシ（ミリ秒）。P95/P99の計算に使用	`163.4`

重要：PIIをログに含めてはならない

MCPログには業務データ（請求書内容・従業員情報・顧客氏名等）を含めてはならない。param_keys（パラメーター名のみ）は記録してよいが、パラメーターの値はハッシュ化または除外すること。GDPRおよび個人情報保護法の要件だ。

4. Pythonによる構造化ログ実装サンプル

以下のコードを既存のMCPサーバー実装に追加するだけで、5フィールドの構造化ログが始まる。

import logging, json, time, uuid

logger = logging.getLogger("mcp_server")
logging.basicConfig(level=logging.INFO)

def mcp_tool_call(tool_name: str, params: dict, session_id: str) -> dict:
    trace_id = str(uuid.uuid4())
    t0 = time.time()
    base_log = {
        "trace_id": trace_id,
        "session_id": session_id,
        "tool": tool_name,
    }

    logger.info(json.dumps({
        **base_log,
        "event": "call_start",
        "param_keys": list(params.keys()),  # 値ではなくキー名のみ
        "timestamp": t0,
    }))

    try:
        result = _execute_tool(tool_name, params)
        logger.info(json.dumps({
            **base_log,
            "event": "success",
            "latency_ms": round((time.time() - t0) * 1000, 2),
        }))
        return result
    except Exception as e:
        logger.error(json.dumps({
            **base_log,
            "event": "error",
            "error_type": type(e).__name__,
            # エラーメッセージにPIIが含まれる可能性があるため除外
            "latency_ms": round((time.time() - t0) * 1000, 2),
        }))
        raise

5. アラート設計：KanseiLink実測ベンチマーク基準

KanseiLink が225サービスの実測データから導出したアラート閾値を参考値として提示する。自社のサービス特性に応じて調整すること。

メトリクス	Warningしきい値	Criticalしきい値	評価期間
ツール別成功率	< 80%	< 70%	直近5分
P95レイテンシ	> 3,000ms	> 8,000ms	直近10分
Handshake失敗率	> 5%	> 10%	直近5分
rate_limitエラー率	> 3%	> 10%	直近15分
timeout発生率	> 2%	> 5%	直近10分

KanseiLink実測のトップ層ベンチマーク（Slack MCP参考値）は成功率91%・平均レイテンシ163ms。これらを「目標値」として使用できる。BBB以下の評価を受けているサービスは概して成功率60〜75%・P95レイテンシ5,000ms以上の水準にある。

6. 推奨ツールスタック比較

ツール	最適なケース	無料枠	MCPログ対応
Datadog	エンタープライズ。APM・ログ・アラートを一元管理したい場合	なし（トライアル14日）	APMトレース + カスタムメトリクス対応 ✅
Grafana Cloud	スタートアップ・OSSスタック好み。Prometheus+Loki+Tempo連携	50GB logs/月・10K metrics	Lokiでのログ検索 + Tempoでのトレース ✅
Sentry	エラートラッキング特化。リリース相関・スタックトレース分析	5,000 errors/月	error_typeの集計・アラートに最適 ✅
New Relic	フルスタック可観測性。APM+インフラ+ブラウザ統合	100GB/月（Free Tier）	NerdGraph APIでカスタム分析可 ✅

初めてMCP可観測性を導入する場合はGrafana Cloud（無料枠）+ Sentry（無料枠）の組み合わせが最もコストパフォーマンスが高い。本番トラフィックが増えた段階でDatadogへの移行を検討するとよい。

7. 30分クイックスタート

構造化JSONロガーを設定（5分）

上記Pythonサンプルを既存のMCPハンドラーに追加。logging.basicConfigのフォーマットをJSON出力に変更する。既存のprint()デバッグ文は全て削除すること。

Grafana Cloudアカウント作成（10分）

Grafana Cloudの無料枠（50GB logs/月）でアカウントを作成。Loki（ログ収集）とTempo（トレース）を有効化。Promtailエージェントをサーバーにインストールしてログを転送するだけで設定完了。

最初のアラートを設定（10分）

GrafanaでLogQLクエリ rate({job="mcp-server"} |= "error" [5m]) を作成し、5分間のエラー率が80%成功率を下回った場合にメール通知を送るアラートを設定する。

KanseiLinkスコアと照合（5分）

自社サービスのAEOスコアをKanseiLinkランキングで確認し、成功率・レイテンシの実測値と対照させる。BBB以下の評価を受けている場合、可観測性データが改善のロードマップ策定に直接活用できる。

開示事項： 本記事のアラート閾値はKanseiLinkの225サービス実測データベースに基づく参考値です。実際の閾値はサービスの特性・トラフィックパターン・SLA要件によって大きく異なります。本記事の推奨事項を実装する前に、自社の要件を十分に検討してください。KanseiLinkは特定ツールベンダーとのパートナーシップは持っていません。

情報源・検証状況： 3層監視モデル ✅（Zeo.org）、構造化ログベストプラクティス ✅（Merge.dev、MCP Manager）、GDPR・PIIログ除外要件 ✅（Red Hat Blog）、Slack MCPの91%成功率・163ms ✅（KanseiLink実測データ、2026-04-13更新）、Grafana Cloud無料枠50GB ✅（Grafana公式）。

自社MCPサーバーのAEOスコアを確認する

225+サービスのMCP成功率・レイテンシ・AEOスコアは無料ランキングページで閲覧可能。可観測性改善の目標値設定にご活用ください。

AEOランキングを見る