PerformanceMonitor MCP — ユースケース, インストール & ライブデモ

なぜ使うのか

主な機能

CPU、メモリ、待機、ブロッキング、デッドロック、ファイルI/O、プランにわたる50以上の診断ツール
一般的なクエリのアンチパターンを検出する30ルール内蔵のPlanAnalyzer
localhost専用のHTTPバインディング — ネットワーク上に公開されることはありません
SQL Server 2016〜2025、Azure SQL、AWS RDSに対応
読み取り専用の診断 — データ、スキーマ、サーバー設定の変更は不可

ライブデモ

実際の動作

performancemonitor.replay ▶ 準備完了

0/0

インストール

クライアントを選択

~/Library/Application Support/Claude/claude_desktop_config.json · Windows: %APPDATA%\Claude\claude_desktop_config.json

{
  "mcpServers": {
    "performancemonitor": {
      "command": "TODO",
      "args": [
        "See README: https://github.com/erikdarlingdata/PerformanceMonitor"
      ],
      "_inferred": true
    }
  }
}

Claude Desktop → Settings → Developer → Edit Config を開く。保存後、アプリを再起動。

~/.cursor/mcp.json · .cursor/mcp.json

{
  "mcpServers": {
    "performancemonitor": {
      "command": "TODO",
      "args": [
        "See README: https://github.com/erikdarlingdata/PerformanceMonitor"
      ],
      "_inferred": true
    }
  }
}

Cursor は Claude Desktop と同じ mcpServers スキーマを使用。プロジェクト設定はグローバルより優先。

VS Code → Cline → MCP Servers → Edit

{
  "mcpServers": {
    "performancemonitor": {
      "command": "TODO",
      "args": [
        "See README: https://github.com/erikdarlingdata/PerformanceMonitor"
      ],
      "_inferred": true
    }
  }
}

Cline サイドバーの MCP Servers アイコンをクリックし、"Edit Configuration" を選択。

~/.codeium/windsurf/mcp_config.json

{
  "mcpServers": {
    "performancemonitor": {
      "command": "TODO",
      "args": [
        "See README: https://github.com/erikdarlingdata/PerformanceMonitor"
      ],
      "_inferred": true
    }
  }
}

Claude Desktop と同じ形式。Windsurf を再起動して反映。

~/.continue/config.json

{
  "mcpServers": [
    {
      "name": "performancemonitor",
      "command": "TODO",
      "args": [
        "See README: https://github.com/erikdarlingdata/PerformanceMonitor"
      ]
    }
  ]
}

Continue はマップではなくサーバーオブジェクトの配列を使用。

~/.config/zed/settings.json

{
  "context_servers": {
    "performancemonitor": {
      "command": {
        "path": "TODO",
        "args": [
          "See README: https://github.com/erikdarlingdata/PerformanceMonitor"
        ]
      }
    }
  }
}

context_servers に追加。保存時に Zed がホットリロード。

claude mcp add performancemonitor -- TODO 'See README: https://github.com/erikdarlingdata/PerformanceMonitor'

ワンライナー。claude mcp list で確認、claude mcp remove で削除。

ユースケース

実用的な使い方： PerformanceMonitor

インシデント発生時に遅延しているSQL Serverをトリアージする

👤 DBA、データベース障害対応中のオンコールSRE ⏱ ~5 min intermediate

使うタイミング： ユーザーからタイムアウト報告が上がっており、60秒以内に何が何をブロックしているか把握する必要があるとき。

前提条件

PerformanceMonitorアプリがインストール済みで、対象サーバーに接続されていること — GitHubリリースページからダウンロードし、監視用DBに接続してください
対象ログインにVIEW SERVER STATEが付与されていること — GRANT VIEW SERVER STATE TO [monitor_login]
MCPがクライアントに登録されていること — claude mcp add --transport http --scope user sql-monitor http://localhost:5151/

フロー

ヘルスチェックの概要を取得する

ヘルスチェックを実行して — 現在、待機、ブロッキング、メモリプレッシャーに問題はある？✓ コピーしました

→ 異常値を示すメトリクスの一覧
最大の問題にドリルダウンする

ブロッキングが最大の問題なら、ヘッドブロッカーのチェーンとブロッキングセッションのSQLテキストを見せて。✓ コピーしました

→ 具体的なSPIDとクエリテキスト
推奨アクションを得る

そのSPIDをkillすべき？待つべき？それとも不足インデックスがあれば防げた？具体的に教えて。✓ コピーしました

→ 根拠付きの明確な推奨アクション1つ

結果： kill、待機、インデックス追加、エスカレーションなど、具体的な次のアクションが付いた診断結果を5分以内に取得できます。

注意点

コミット直前のブロッカーをkillすると、かえって被害が拡大する可能性がある — killする前に、必ず実行時間と未コミットのトランザクションを保持しているかを確認してください
監視DBのメトリクスは、コレクター間隔分だけ実サーバーから遅延している — リアルタイムの状況確認には、集約履歴ではなく「現在の状態」ツールを使用してください

組み合わせ： sentry

AI支援レビューで遅いクエリプランを分析する

👤 クエリチューニングを行うバックエンド開発者およびDBA ⏱ ~15 min intermediate

使うタイミング： クエリが遅く、プランが200オペレーターもあり、手動で読みたくないとき。

フロー

プランを取得する

クエリハッシュ0xA1B2C3の最新プランを取得して、PlanAnalyzerにかけて。✓ コピーしました

→ プラン＋ルールヒットの一覧
最も深刻なルールヒットを説明する

1位のルールヒットをわかりやすく説明して — 何が起きていて、なぜ問題なのか。✓ コピーしました

→ 専門用語を避けた2〜3文の説明
修正を提案する

最小限の変更で修正する方法を提案して：インデックス、クエリの書き換え、統計の更新のいずれか。影響度の見積もりも。✓ コピーしました

→ 具体的なDDLまたは書き換え案

結果： プランの証拠とPlanAnalyzerルールの両方に裏付けられた、具体的なチューニングアクションが得られます。

注意点

プランが異なるパラメータースニッフィングパスでキャッシュされていた可能性がある — プランの形状を信頼する前に、OPTION(RECOMPILE)を付けてプランを再生成してください

週次のSQL Serverヘルスサマリーを作成する

👤 ライブのオンコールではなく、受動的な監視を求めるデータベースオーナー ⏱ ~20 min beginner

使うタイミング： 金曜日の午後の振り返り。ユーザーから言われる前に把握しておきましょう。

フロー

週次比較の統計を取得する

今週と先週のトップ待機およびトップクエリを比較して。大幅に悪化した項目をフラグして。✓ コピーしました

→ パーセンテージ付きの差分
チーム向けの読みやすいサマリーを作成する

エンジニアリングチャンネル向けに、Good/Bad/Uglyの1ページヘルスサマリーを書いて。✓ コピーしました

→ そのまま貼れるMarkdown形式の投稿

結果： 来週のトラッキング項目が具体的に記載された、共有可能な週次ヘルスレポートが得られます。

組み合わせ： sentry

組み合わせ

他のMCPと組み合わせて10倍の力を

performancemonitor + sentry

Sentryがタイムアウトの急増を検知した場合、同じタイムスタンプのSQL Serverブロッキングと照合する

14:03 UTCのSentryイベントでSqlExceptionが出ている。14:02〜14:04の間にDB側でブロッキングや待機のスパイクはあった？✓ コピーしました

performancemonitor + github

遅いクエリを発生させたコミットを特定する

クエリハッシュ0xA1B2が2026-03-22からトップ10に入り始めた。その前後でデータアクセス層に対するGitHubコミットを探して。✓ コピーしました

ツール

このMCPが提供する機能

ツール	入力	呼び出すタイミング	コスト
get_top_waits	server_name?: str, hours_back?: int	トリアージの最初のステップ — サーバーが実際に何を待っているかを確認する	1 SQL query on the monitoring DB
get_active_blocking	server_name?: str	ライブのブロッキング調査	1 query
get_deadlocks	server_name?: str, hours_back?: int	「デッドロックが発生した」と報告されたとき	1 query
analyze_query_plan	plan_handle: bin, or xml: str	特定の遅いクエリをチューニングするとき	1 query + 30 rule evaluations
get_memory_clerks	server_name?: str	メモリプレッシャーの調査	1 query
get_tempdb_usage	server_name?: str	tempdbの容量逼迫やプラン内のスピル発生時	1 query

コストと制限

運用コスト

APIクォータ: 外部クォータなし。監視DBの容量に依存します
呼び出しあたりのトークン: ほとんどのツールは200〜2000トークンを返します。プランXMLは10k以上になる場合があります
金額: 無料、オープンソース（LiteエディションとFullエディション）
ヒント: 単一インスタンスの環境であればLiteエディションで十分です。Fullエディションではクロスサーバー監視が追加されます。

セキュリティ

権限、シークレット、影響範囲

最小スコープ： VIEW SERVER STATE on the target instance

認証情報の保管： 監視DBの接続文字列はアプリの設定で管理され、ローカルマシン上に保持されます

データ送信先： MCPはlocalhostにのみバインドされます。MCPプロセスからの外部通信は発生しません

絶対に付与しない： sysadmin or db_owner — VIEW SERVER STATE is enough

プランXMLとクエリテキストには機密データが含まれる場合があります — 共有チャットログへの貼り付けにはご注意ください。
コレクターは個人アカウントではなく、専用のログインで実行してください。

トラブルシューティング

よくあるエラーと対処法

Cannot connect to http://localhost:5151/ — アプリが起動していないか、MCPが無効になっています

アプリを開き、設定でMCPを有効にして、ポートを確認してください。

確認： curl http://localhost:5151/

Login failed for user — 監視DBの認証情報が正しくありません

アプリで認証情報を再入力し、VIEW SERVER STATEが付与されていることを確認してください。

確認： sqlcmd -S <server> -U <user> -P <pwd> -Q 'SELECT 1'

Plan analyzer returns no findings on clearly slow query — プランがキャッシュにない可能性があります

OPTION(RECOMPILE)を付けてクエリを再実行し、もう一度お試しください。

確認： SELECT plan_handle FROM sys.dm_exec_query_stats WHERE ...

Port 5151 already in use — ポートが既に使用されています

設定でMCPポートを変更し（範囲: 1024〜65535）、クライアントに再登録してください。

確認： netstat -an | grep 5151

代替案

PerformanceMonitor 他との比較

代替案	代わりに使う場面	トレードオフ
sp_BlitzFirst / Brent Ozar scripts	アプリなしでT-SQLプロシージャを直接実行したい場合	MCPなし — 出力を自分でチャットに貼り付ける必要があります
SentryOne / Redgate SQL Monitor	商用モニタリングツールが既に導入されているエンタープライズ環境	有料。ほとんどの製品はMCPインターフェースを公開していません
postgres MCP	SQL ServerではなくPostgresを使用している場合	データベースエンジン自体が異なります

その他

リソース

📖 GitHub の公式 README を読む

🐙 オープンな issue を見る

🔍 400以上のMCPサーバーとSkillsを見る