Windows Performance Analyzer MCPとは？WPA MCPとETW MCPの違いと導入判断

Windows Performance Analyzer MCP（WPA MCP）は、Windowsのトレース解析ツールであるWPAにGitHub Copilot CLIを組み込み、ETLトレースへの問いかけを自然言語で行えるようにするプレビュー機能です。Microsoftは同じデータ層を使うヘッドレス版のETW MCPを2026年7月21日に、WPA組み込み版を7月30日に公開しました。この記事では、両者の役割分担、Microsoft Store版WPAとNuGetパッケージそれぞれの導入手順、公開されている解析機能の内訳、そして受託開発の性能調査でどこまで任せてよいかを実装目線で整理します。仕様は2026年8月10日時点の公開情報に基づきます。

まとめ：WPA MCPを試す価値がある現場と見送るべき条件

WPA MCPとETW MCPが解こうとしているのは、ETLトレースという巨大なデータを人が表とグラフで手繰る作業の入り口部分です。「どのプロセスがCPUを食っていたか」「遅延の主因はどの区間か」といった一次切り分けを、自然言語の問い合わせに置き換えます。トレースの処理そのものはローカルのTraceProcessorが担い、モデルが受け取るのはツールが返した集計結果です。

試す価値が高いのは、ETLトレースを日常的に採取していて、しかもWPAの操作に習熟した人が1人か2人しかいないチームです。逆に、そもそもトレースを採る運用が定着していない現場では、MCPを入れても読ませる材料がありません。先に採取の手順を整えるほうが順序として先です。

見送るべき条件も明確に挙げておきます。GitHub Copilotの契約がない、あるいは顧客から預かった環境のトレースを扱う案件で第三者サービス経由の解析について合意が取れていないなら、導入しない。プレビュー段階の機能である以上、障害対応の本番フローに組み込むのも早すぎます。検証環境で性能調査の下ごしらえに使い、結論は必ずトレースの実データで裏を取る。この線を引ける現場だけが対象です。

WPA MCPとETW MCPが担うETLトレース解析の役割分担

名前が似た2つの発表が2週間の間隔で出たため、混同されやすい状態にあります。まず両者の位置づけを分けます。同じデータ層の上に、対話の入り口を2種類用意したという構図です。

WPA MCPがCopilotボタンから呼ぶ分析ペインの動作

WPA MCPは、Windows Performance Analyzerのウィンドウ内で完結します。トレースを開き、右上のGitHub Copilotボタンを押すと分析用のペインが開き、そこにトレースについての質問を書き込む。返ってきた分析は、根拠となるデータと並べて表示されます。表を自分で開いて絞り込む操作を、質問文が肩代わりする形です。

MCP（Model Context Protocol）そのものは、AIアシスタントが外部のデータやツールを呼び出すための共通規格です。規格側の仕組みはMCPの基本的な考え方で整理したとおりで、WPA MCPはその規格に沿ってトレース解析エンジンをツールとして差し出した実装だと捉えると理解が早くなります。

ETW MCPをヘッドレスで動かすdnx起動と接続設定の書き方

ETW MCPには画面がありません。標準入出力で待ち受けるMCPサーバとして動き、MCP対応のクライアントから呼ばれます。Microsoft Dev Blogsが示している設定は、サーバ種別をstdio、起動コマンドをdnx、引数にパッケージ名Microsoft.Windows.EventTracing.MCPと--yesを並べる形です。WPAをインストールしていないビルドマシンやCI環境でも動かせます。

この構成はMCPサーバ一般の作法どおりで、特別な独自プロトコルは使いません。自社のツールを同じようにエージェントへ差し出すときの設計はMCPで外部ツールを接続する実装手順と共通で、tool定義と権限設計の考え方をそのまま持ち込めます。

TraceProcessorを共有するデータ層と両者の使い分け基準

両者はTraceProcessorという同じ処理エンジンの上に立っています。WPAとXPerfが使ってきたものと同じ層です。Microsoftは両者を「補完関係にあり、置き換えるものではない」と説明しています。

使い分けの基準は単純です。トレースを目で追いながら気づいた点を掘り下げるならWPA MCP、複数のトレースをまとめて処理したり調査を自動化したりするならETW MCP。1本のトレースを腰を据えて読む作業と、何十本かを機械的に比較する作業は性質が違うため、両方を入れておいて場面で切り替える運用が現実的です。

ETW MCPが公開する解析ツール群と実行できる調査の守備範囲

プレビューの時点で何が答えられるのかを、機能単位で押さえます。ここを把握しないまま質問を投げると、答えられない領域まで自然言語で聞いてしまい、もっともらしい推測を受け取ることになります。

CPU使用率の集計とプロセス単位のフィルタで見える一次切り分け

基礎になるのはトレースの読み込みと、クエリ・フィルタ・集計です。プロセス単位で絞り込み、CPU使用率の上位を並べる。Dev Blogsが例示している問いかけも「このトレースではどのプロセスが動いていたか」「CPUを最も消費しているのはどれか」という粒度から始まっています。

この段階で分かるのは、あくまで「どこが忙しかったか」までです。忙しさの原因がアプリのロジックにあるのか、ディスクの待ちにあるのか、ドライバの割り込みにあるのかは、次の問いで詰める必要があります。一次切り分けの所要時間を縮める道具として見ておくと期待値を外しません。

クリティカルパス解析とRegions of Interestが答える遅延の所在

プレビューには2つの踏み込んだ機能が入っています。ひとつがクリティカルパス解析（CPA）で、遅延に対して最も寄与している実行区間を特定する機能。もうひとつがRegions of Interestで、名前付きの時間区間を採点し、多数のトレースをまたいで比較します。

この2つは、WPAの画面で人がやると手間のかかる作業です。とくにCPAは、待ちの連鎖をスレッド間で追う作業になるため、慣れた人でも時間を取られる。ここを問いかけ1回に置き換えられる点が、単なるログ要約との差になります。

ベースラインと試行版の複数トレース比較で性能退行を特定する手順

性能退行の調査では、基準となるトレースと、変更後のトレースを並べます。ETW MCPは複数トレースの比較を機能として持っており、Dev Blogsも「ベースラインと試行版のCPU使用量を比較する」問いかけを例に挙げています。

実務での使い方は次の順序になります。

1. 変更前の状態でトレースを採取し、基準として保管する
2. 変更後に同じ操作・同じ負荷でトレースを採取する
3. 2本を読み込ませ、プロセス単位・区間単位の差分を出させる
4. 差が出た区間に対してクリティカルパス解析を走らせる

採取条件を揃えないまま比較させると、差分の解釈がそのまま崩れます。機械に読ませるからこそ、入力側の条件統一は人が管理する領域として残ります。

シンボル解決を前提としたmodule単位のスタック分析の条件

スタックをモジュールと関数の粒度まで落として見るには、シンボルの解決が要ります。ETW MCPはシンボル対応の調査を機能として挙げていますが、シンボルパスの設定は利用者側の準備です。設定していなければ、返ってくるのはアドレスとモジュール名までの情報にとどまります。

自社製アプリを調べるなら、ビルド時のPDBを参照できる状態を先に作る。他社製のコンポーネントが絡む調査では、公開シンボルサーバの設定が必要になります。ここを整えずに「関数レベルで教えて」と聞いても、精度の低い答えが返るだけです。

導入手順とGitHub Copilot前提のライセンス条件の確認事項

導入で詰まりやすいのは、技術要件よりも契約要件のほうです。両方を並べて確認します。

Microsoft Store版WPAプレビューの入手と有効化の前提

WPA MCPは、Microsoft Storeで配布されているWPAのプレビュー版に含まれます。アプリIDは9N58QRW40DFWで、MCP機能を含む最新のプレビュー版を入れる必要があります。既存の安定版WPAをそのまま使っていても、Copilotボタンは現れません。

フィードバックの導線も用意されています。Copilotボタンの隣にあるボタンから送るか、Feedback Hub（WIN + F）の設定カテゴリから送る形です。プレビュー機能である以上、社内で試した結果の報告先を最初に決めておくと、検証が個人の作業で終わりません。

.NET 10 SDKとdnxコマンドで登録するETW MCPの設定手順

ETW MCP側の前提は3つです。Windows環境であること、.NET 10 SDKが入っていること、そしてMCPクライアントの設定ファイルにサーバ定義を書き込むこと。起動コマンドのdnxはSDKに同梱されており、パッケージはNuGet.orgから取得されます。

Dev Blogsは、GitHub MCP Registryへの掲載は準備中だと記載しています。つまり現時点では、レジストリ経由のワンクリック追加ではなく、設定ファイルへの手書きが標準の入れ方。シンボルパスの設定は任意ですが、前述のとおりスタック分析の精度に直結します。

GitHub Copilot契約とサポート対象アシスタントの制約

WPA MCPを動かすには、GitHub Copilot CLIと有効なGitHub Copilotのサブスクリプションが要る。Dev Blogsは、現時点で他のAIアシスタントやモデルプロバイダには対応していないと明記しています。社内で別のアシスタントを標準にしているなら、WPA MCPのためだけにCopilotを契約する判断が必要になります。

CLIの動作モードや料金体系はGitHub Copilot CLIの解説にまとめたとおりで、権限の与え方や実行の承認フローはそちらの前提がそのまま効きます。一方でETW MCPはMCP対応クライアントであれば接続でき、この制約を受けません。組織の標準アシスタントがCopilot以外なら、ヘッドレス側から検証を始めるのが素直な順序です。

受託開発の性能調査でWPA MCPに任せてよい範囲と見送る条件

ここからは判断を言い切ります。プレビュー機能を業務に入れるかどうかは、精度の話だけでは決まりません。

LLM出力のばらつきを前提に置いた検証工程の組み込み方の指針

Microsoft自身が、生成される応答は実行ごとに変動し、不完全だったり誤っていたりする可能性があると明記しています。最終的な診断ではなく出発点として扱い、トレースの実データで検証せよという但し書きです。この前提は運用手順に落とす必要があります。

具体的には、AIの回答をそのまま報告書に転記しない。回答が指した区間・プロセス・スタックを、WPAの表で開いて数字を確認し、確認した数字のほうを成果物に書く。裏取りの工数を織り込んでも一次切り分けが速くなるなら採用、裏取りのほうが長くかかるなら使わない。判断の基準はここに置けます。

顧客環境のETLトレースを外部へ渡す前に確認すべき契約上の論点

受託の現場で最初に潰す論点がこれです。トレースの処理はローカルのTraceProcessorで行われ、モデルが受け取るのはツールが返す集計結果ですが、その集計結果には顧客環境のプロセス名、ファイルパス、モジュール名が含まれます。社内システムの構成が読み取れる情報だと考えたほうが安全です。

確認すべきは3点です。秘密保持契約の第三者提供の定義に、AIサービスへの問い合わせが該当するか。採取したトレースと問い合わせ履歴の保管期間を自社で管理できるか。案件終了時にトレースファイルと会話ログを破棄する手順を、手順書に書けるか。この3点に答えられないなら、合意を取るまで導入は保留にします。

プレビュー段階の機能を本番の障害対応へ組み込まない判断の理由

もうひとつの見送り条件が、障害対応フローへの組み込みです。プレビュー機能は仕様も配布形態も変わりうるため、緊急時の手順に組み込むと、機能変更がそのまま対応の遅れに変わります。深夜の障害対応中に「Copilotボタンが消えている」という事態は避けたい。

順序としては、平時の性能調査や退行検証で使い込み、どの質問なら安定して当たるかを社内で蓄積する段階が先です。安定して当たる質問の型が溜まってから、正式版のタイミングで手順書に載せる。この順番を守れば、プレビューの不安定さを実務のリスクに変えずに済みます。

既存のオブザーバビリティ運用とETWトレース解析の使い分けの線引き

ETWトレースは、アプリケーション側の計装で得られるデータとは見ている層が違います。両方を持っているチームほど、どちらを先に見るかで迷いが出ます。

分散トレースが届かないOS層の待ち事象を拾う場面の切り分け方

分散トレースは、リクエストがサービス間をどう渡ったかを追う道具です。対してETWは、CPUスケジューリング、ディスクI/O、割り込みといったOS層の事象を記録します。アプリのスパンでは「処理に3秒かかった」までしか分からない待ちの中身が、ETW側では何を待っていたかまで見えます。

使い分けの順序は、まず分散トレースで遅い区間を特定し、その区間がアプリのロジックで説明できないときにETWへ降りる、という流れになります。分散トレース側のデータ設計はトレースサンプリングの考え方で整理しており、サンプリング率の設定次第では遅いリクエスト自体が記録に残らない点も併せて押さえておくと、ETWへ降りる判断が早くなります。監視全体の枠組みについてはオブザーバビリティの3本柱を前提に置くと、ETWがどの穴を埋める道具なのかを位置づけやすい。

社内の性能調査ナレッジをMCP経由で共有する運用への発展余地

WPA MCPとETW MCPが示しているのは、社内に閉じた解析エンジンをMCPサーバとして差し出せば、エージェントがそれを道具として使えるという構図です。同じ形は自社の運用データにも当てはまります。障害履歴、構成管理データベース、独自フォーマットの計測ログ。これらをMCPサーバ化すれば、調査の入り口を自然言語に寄せられます。

ただし、差し出すツールの粒度と権限設計を誤ると、エージェントが答えを組み立てられなかったり、逆に見せてはいけないデータへ到達したりします。当社の生成AI導入支援では、社内データをエージェントへ接続する際のツール設計と権限の切り分けを含めて支援しています。

よくある質問

WPA MCPとETW MCPの検証でよく挙がる疑問に、2026年8月10日時点の公開情報をもとに答えます。

Windows Performance Analyzer MCPは無料で使えますか？

WPA自体はMicrosoft Storeから無料で入手できますが、MCP機能を動かすには有効なGitHub Copilotのサブスクリプションが別途必要です。分析の問い合わせはGitHub Copilot CLI経由で処理されるため、Copilotの契約がない環境では機能が動きません。ヘッドレス版のETW MCPはNuGetパッケージとして配布されており、こちらは接続するMCPクライアント側の契約条件に従います。

GitHub Copilot以外のAIアシスタントでも使えますか？

WPA MCPについては、Microsoft Dev Blogsが現時点で他のAIアシスタントやモデルプロバイダには対応していないと明記しています。一方でETW MCPは標準入出力で通信する一般的なMCPサーバとして配布されており、MCP対応のクライアントであれば接続を試せる。組織の標準アシスタントがCopilot以外の場合は、ETW MCP側から検証を始める形になります。

ETW MCPを動かすのに必要な環境は何ですか？

Windows環境と.NET 10 SDKが前提です。SDKに含まれるdnxコマンドでNuGet上のパッケージを起動し、MCPクライアントの設定ファイルにサーバ定義を書き込みます。スタックをモジュールと関数の粒度で見る場合は、シンボルパスの設定も併せて必要。GitHub MCP Registryへの掲載は準備中と記載されているため、当面は設定ファイルへの手書きが標準の導入方法になります。

トレースの中身はそのままAIモデルへ送られますか？

トレースの処理はWPAやXPerfと同じTraceProcessorが担い、モデルが受け取るのはツール呼び出しが返した集計結果です。ETLファイル全体をモデルへ読み込ませる設計ではありません。ただし集計結果にはプロセス名やモジュール名といった環境の情報が含まれるため、顧客から預かった環境のトレースを扱う案件では、秘密保持契約の条項に照らして事前に可否を確認しておく必要があります。

AIが出した分析結果はそのまま報告書に使えますか？

使わないほうが安全です。Microsoftは、生成される応答が実行ごとに変動し、不完全または誤っている可能性があると明記したうえで、最終的な診断ではなく出発点として扱い、元のトレースデータで検証するよう求めています。実務では、AIが指した区間やプロセスをWPAの表で開き直し、確認できた数値のほうを成果物に記載する手順にします。

関連記事

• MCP（Model Context Protocol）とは？AIと外部ツールをつなぐ標準規格の仕組みをわかりやすく解説：WPA MCPが従っている規格そのものの仕組みを解説しています。
• GitHub Copilot CLIとは？Autopilot・Planなど動作モードと料金・インストールを解説：WPA MCPの前提となるCLI側の動作モードと契約条件をまとめています。
• AIエージェントにMCPで外部ツールを接続する実装手順とは？tool定義・権限・認可の設計を解説：自社の解析ツールを同じ形でエージェントへ差し出すときの設計指針です。
• Prompt Engineeringとの違いで理解するContext Engineeringの本質と全体像：エージェントへ渡す文脈をどう設計するかという一段手前の考え方を扱います。
• トレースサンプリングとは？ヘッドベースとテールベースの仕組み・OpenTelemetry/X-Ray実装・サンプリング率の決め方を実装目線で解説：分散トレース側でどこまで見えるかを押さえ、ETWへ降りる判断を早めます。