ETLトレースからCPU負荷の高いプロセスや関数を確認したいものの、毎回Windows Performance Analyzer（WPA）を開いて表やグラフを絞り込むのは手間がかかります。
最短手順は、.NET 10 SDKをインストールし、VS CodeまたはCopilot CLIのMCP設定へ、dnxで起動するMicrosoft.Windows.EventTracing.MCPを登録することです。設定後にクライアントを再起動し、ETLファイルの絶対パスと調べたい内容をCopilotへ伝えれば、CPU使用量、プロセス、時間範囲、シンボル、トレース間の差などを会話形式で掘り下げられます。
Microsoft.Windows.EventTracing.MCPは、2026年7月時点ではearly previewとして提供されている、ローカル・STDIO方式の読み取り専用MCPサーバーです。WPAを完全に置き換えるものではありませんが、ETLトレースの初動調査や比較分析を大幅に簡略化できます。(Microsoft for Developers)
ETW MCPで何ができるのか
Event Tracing for Windows（ETW）は、Windowsに組み込まれたトレース基盤です。プロセスの開始・終了、コンテキストスイッチ、メモリ割り当てなど、OSやアプリケーションの動作を構造化されたイベントとしてETLファイルへ記録できます。
従来は、ETLファイルをWPAで開いてグラフやテーブルを操作するか、.NET TraceProcessing APIを使った解析プログラムを作成する方法が中心でした。ETW MCPは、その解析機能をCopilotなどのMCPクライアントから呼び出せるようにします。(Microsoft Learn)
代表的な用途は次のとおりです。
| 調べたいこと | ETW MCPへの依頼例 |
|---|---|
| CPU負荷の全体像 | CPU使用量が多いプロセスを上位10件表示する |
| 特定プロセスの負荷 | MyApp.exeのCPU時間をPID別に集計する |
| 問題が起きた時間帯 | トレース開始後20～40秒だけを解析する |
| 関数単位のホットスポット | CPUを多く消費したmodule!functionを調べる |
| 改修前後の比較 | 2つのETLでCPU時間やホットスポットを比較する |
| 待ち時間の原因 | 利用可能なイベントからクリティカルパスを追跡する |
| WPPやマネージコード | シンボルを利用してスタックや関数名を解決する |
Microsoftの公式案内では、CPU使用量の集計、プロセスや時間範囲による絞り込み、複数トレースの比較、クリティカルパス分析などが示されています。シンボルパスが適切に構成されていれば、ネイティブのmodule!function表記、WPP、マネージシンボルを含む解析にも対応します。(Microsoft for Developers)
ただし、ETW MCPが解析できるのは、ETLファイルに実際に記録されているデータだけです。CPUサンプリングやスタック情報を取得していないトレースから、関数単位のCPU負荷を後から復元することはできません。
導入前に確認するもの
必要なものは次の4点です。
- .NET 10 SDK以降
- GitHub Copilotを利用できるVS Code、またはCopilot CLI
- 解析対象のETLファイル
- NuGetパッケージを取得できるネットワーク環境
特に注意したいのが、.NET Runtimeではなく.NET SDKが必要という点です。dnxは.NET 10 SDKで追加されたコマンドで、NuGetからMCPサーバーを取得して起動するために使われます。(Microsoft Learn)
PowerShellで次を実行します。
dotnet --info
dotnet --list-sdks
Get-Command dnxコマンドプロンプトを使用する場合は、次のように確認できます。
dotnet --info
dotnet --list-sdks
where dnxdotnet --list-sdksに10.0で始まるSDKが表示され、dnxのパスが取得できれば準備完了です。
global.jsonで古いSDKに固定されていないか確認する
.NET 10 SDKがインストール済みでも、VS CodeやCopilot CLIを起動したフォルダーの上位階層にglobal.jsonがあり、古いSDKへ固定されていると、dnxを解決できない場合があります。
公式案内でも、クライアントの起動フォルダーにあるglobal.jsonが古いSDKを指定している場合、dnxが見つからなくなる点が注意事項として挙げられています。(Microsoft for Developers)
現在選択されているSDKを確認します。
dotnet --versionリポジトリ直下にglobal.jsonがある場合は、内容も確認してください。
Get-Content .\global.json.NET 8や.NET 9などへ固定されている場合は、次のいずれかで対応します。
global.jsonの影響を受けないフォルダーからVS CodeやCopilot CLIを起動する- プロジェクトの互換性を確認したうえで
global.jsonを.NET 10へ更新する rollForwardの設定を見直す
既存プロジェクトのビルド環境を壊す可能性があるため、ETW MCPを使う目的だけでglobal.jsonを無条件に書き換えるのは避けてください。
VS CodeへETW MCPを追加する手順
VS Codeでは、ワークスペース単位の.vscode/mcp.json、またはユーザープロファイルのmcp.jsonへMCPサーバーを登録できます。
複数のプロジェクトでETL解析を行う場合はユーザー設定、チームで同じ設定を共有する場合はワークスペース設定が適しています。VS Codeでは、コマンドパレットから「MCP: Open User Configuration」や「MCP: Add Server」を実行する方法も用意されています。(Visual Studio Code)
.vscode/mcp.jsonを作成する
対象ワークスペースに.vscodeフォルダーを作成し、その中へmcp.jsonを保存します。
{
"servers": {
"etw": {
"type": "stdio",
"command": "dnx",
"args": [
"Microsoft.Windows.EventTracing.MCP",
"--yes"
]
}
}
}各項目の意味は次のとおりです。
| 項目 | 設定内容 |
|---|---|
servers | VS Codeで使用するMCPサーバーの一覧 |
etw | 任意のサーバー名 |
type | ローカルプロセスと標準入出力で通信するstdio |
command | MCPサーバーを起動するdnx |
args | NuGetパッケージ名と--yes |
--yes | 公式構成例に合わせ、初回実行時の対話を省略する指定 |
VS Code用の設定では、トップレベルがmcpServersではなく、serversであることに注意してください。
MCPサーバーを起動して確認する
設定を保存したら、確実に反映するためVS Codeを再起動します。その後、次の順で確認します。
- コマンドパレットを開く
- 「MCP: List Servers」を実行する
etwを選択する- サーバーの状態や提供されるツールを確認する
- 初回の信頼確認が表示されたら、パッケージ名と設定内容を確認して許可する
VS Codeは、MCP設定を変更した際にサーバーを再起動してツールを再検出する必要があります。問題がある場合は、「MCP: List Servers」から「Show Output」を選ぶと起動ログを確認できます。(Visual Studio Code)
Copilot Chatのツール一覧にetw由来のツールが表示されれば、VS Code側の設定は完了です。
Copilot CLIへETW MCPを追加する手順
Copilot CLIでは、copilot mcp addを使う方法が最短です。
PowerShellまたはコマンドプロンプトで次を実行します。
copilot mcp add etw -- dnx Microsoft.Windows.EventTracing.MCP --yes--より後ろが、ローカルのSTDIOサーバーを起動するコマンドとして登録されます。Copilot CLIのSTDIOサーバー追加構文は、次の形式です。(GitHub Docs)
copilot mcp add SERVER-NAME -- COMMAND [ARGS...]登録後にCopilot CLIを起動し、状態を確認します。
/mcp show etw現行のCopilot CLIでは、コマンドから追加したMCPサーバーは即時利用できる仕様です。ただし、.NET 10 SDKを直前にインストールした場合や、設定ファイルを手動編集した場合は、いったんCopilot CLIを終了して起動し直す方が確実です。(GitHub Docs)
設定ファイルを直接編集する場合
Copilot CLIのユーザー設定は、通常、次のファイルに保存されます。
~/.copilot/mcp-config.jsonWindowsでは、概ね次の場所に相当します。
%USERPROFILE%\.copilot\mcp-config.json手動で追加する場合は、次のように設定します。
{
"mcpServers": {
"etw": {
"type": "local",
"command": "dnx",
"args": [
"Microsoft.Windows.EventTracing.MCP",
"--yes"
],
"env": {},
"tools": [
"*"
]
}
}
}Copilot CLIではトップレベルがmcpServersです。VS Codeのserversと混同すると、設定が読み込まれません。
また、Copilot CLIではlocalとstdioは、いずれもローカルプロセスを標準入出力で接続する方式として扱われます。公式ドキュメントでは、手動設定の例にlocalが使用されています。(GitHub Docs)
最初に試すETL解析プロンプト
初回から「原因を調べて」とだけ依頼すると、対象範囲やCPU指標が曖昧になりやすくなります。
まずは次のプロンプトで、トレースの概要とCPU上位プロセスを確認してください。
ETW MCPのツールを使用して、次のETLファイルを解析してください。
対象:
C:\Traces\startup.etl
確認したい内容:
1. トレースの開始時刻、終了時刻、記録時間
2. 記録されている主要プロセス
3. CPU使用量が多いプロセス上位10件
4. プロセス名、PID、CPU指標、単位、集計区間
5. 解析に必要なデータが不足している場合は、その内容
結果は表で整理し、推測とETLから確認できた事実を分けてください。この段階で確認すべきなのは、「遅い原因」ではなく、次の基本情報です。
- ETLの記録時間が想定どおりか
- 問題のプロセスが記録されているか
- CPUデータが含まれているか
- プロセス名だけでなくPIDを識別できているか
- CPUの数値が、時間、割合、サンプル数のどれなのか
トレースの前提が間違っている状態で分析を深めても、正しい結論には到達できません。
CPU負荷を段階的に絞り込むプロンプト例
特定プロセスをPID別に調べる
同じ実行ファイルが複数起動している場合、プロセス名だけで集計すると結果が混ざります。
C:\Traces\startup.etlについて、MyApp.exeのCPU負荷をPID別に集計してください。
各PIDについて、次を表示してください。
- プロセス開始時刻と終了時刻
- CPU時間またはCPUサンプル
- トレース全体に占める割合
- CPU負荷が高かった時間帯問題が起きた時間帯だけを調べる
起動直後の処理とアイドル時間を一緒に集計すると、一時的な負荷が平均化されて見えにくくなります。
C:\Traces\startup.etlのトレース開始後10秒から30秒を対象に、
MyApp.exeのCPU負荷を解析してください。
CPU負荷が高いスレッドと、上位のモジュールを表示してください。
時間範囲外のデータは集計に含めないでください。関数単位のホットスポットを調べる
C:\Traces\startup.etlで、PID 1234のCPU使用に寄与した
module!functionを上位20件表示してください。
シンボルを解決できない項目は除外せず、
モジュール名、アドレス、未解決である理由を示してください。シンボル未解決の項目を除外させないことが重要です。未解決スタックが多い場合、表示された関数だけを見て原因を判断すると、実際の負荷箇所を見落とす可能性があります。
改修前後のETLを比較する
次の2つのETLを比較してください。
変更前:
C:\Traces\baseline.etl
変更後:
C:\Traces\optimized.etl
対象プロセス:
MyApp.exe
比較内容:
- トレースの記録時間
- CPU時間
- 記録時間で正規化したCPU負荷
- CPU上位のモジュールと関数
- 増加した処理と減少した処理
- 差分の絶対値と変化率
記録時間が異なる場合は、CPU時間の単純比較だけで結論を出さないでください。改修前後の比較では、絶対CPU時間だけでなく、記録時間や処理件数で正規化した値を見る必要があります。可能であれば、同じ端末、同じ入力データ、同じ操作手順で取得したETLを使用してください。
クリティカルパスを調べる
C:\Traces\ui-freeze.etlについて、トレース開始後25秒から28秒の
UI応答停止に関係するクリティカルパスを、利用可能なイベントから追跡してください。
対象プロセスはMyApp.exeです。
各待機区間について、実行中、待機中、ブロック元のスレッド、
関連モジュールを整理してください。
データ不足で特定できない箇所は、推測せず不足イベントを示してください。クリティカルパス分析では、CPUを使っているスレッドだけでなく、別スレッド、I/O、同期処理などを待っている時間が重要になります。
精度を上げるプロンプトの書き方
ETW MCPへの依頼には、次の6要素を含めると結果が安定します。
| 要素 | 指定例 |
|---|---|
| ファイル | C:\Traces\startup.etl |
| 対象範囲 | 開始後10～30秒 |
| 対象 | MyApp.exe、PID 1234 |
| 指標 | CPU時間、CPU割合、サンプル数 |
| 出力形式 | 上位10件を表で表示 |
| 不確実性 | データ不足やシンボル未解決を明記 |
特に、CPUの「割合」だけを求めるのは避けてください。CPU割合は、集計時間、論理プロセッサ数、トレース全体を分母にするか対象プロセス内を分母にするかによって意味が変わります。
次のように、算出条件も出力させると判断しやすくなります。
CPU割合を表示する場合は、分母、集計区間、論理プロセッサ数を考慮した値かどうかを説明してください。また、Copilotの説明とETLから得られた数値を区別させるため、次の一文も有効です。
ETLから直接確認できた事実、計算によって得た値、推測を分けて記載してください。ETW MCPとWPAの使い分け
ETW MCPを導入しても、WPAが不要になるわけではありません。両者は競合するというより、調査工程の異なる部分に向いています。
| 比較項目 | ETW MCP | WPA |
|---|---|---|
| 操作方法 | 会話、自然言語、CLI | GUI、グラフ、テーブル |
| 得意な作業 | 初動調査、定型集計、比較、絞り込み | タイムライン確認、複数テーブルの視覚的な相関分析 |
| 繰り返し分析 | 同じプロンプトを再利用しやすい | プロファイルやビューの保存が必要 |
| 大量トレース | 条件を定型化して処理しやすい | 1件ずつ視覚的に確認しやすい |
| 時間範囲の発見 | 時刻を指定して質問する | グラフ上で異常区間を探しやすい |
| 結果の検証 | 集計根拠を文章で確認 | 元イベントやスタックを目視しやすい |
| 向いている段階 | 原因候補の洗い出し | 最終確認と詳細な掘り下げ |
実務では、次の順序が効率的です。
- ETW MCPでトレース時間、CPU上位プロセス、異常区間を確認する
- 対象プロセス、PID、時間範囲を絞る
- モジュールや関数単位まで掘り下げる
- 必要な箇所だけWPAで視覚的に検証する
「最初からWPAですべてを見る」のではなく、ETW MCPで調査範囲を狭めてからWPAを使うことで、確認作業を短縮できます。
起動しない場合の確認ポイント
| 症状 | 主な確認ポイント | 対応 |
|---|---|---|
dnxが見つからない | .NET 10 SDK、PATH、global.json | SDKを確認し、ターミナルとクライアントを再起動する |
| MCPサーバーが一覧に出ない | JSONの構造、設定ファイルの場所 | VS Codeはservers、Copilot CLIはmcpServersを使う |
| サーバー起動時に終了する | NuGet接続、プロキシ、引数 | MCP出力ログを確認し、パッケージ取得可否を調べる |
| ツールがCopilotに表示されない | サーバーの有効化、信頼確認 | MCPサーバーを有効化し、クライアントを再起動する |
| ETLを開けない | パス、アクセス権、実行環境 | 絶対パスを使い、ローカルプロセスから読める場所へ移す |
| CPU情報が得られない | 取得したETWイベント | CPUプロファイルを含むトレースか確認する |
| 関数名が表示されない | スタック、PDB、シンボルパス | モジュール単位で確認し、シンボル設定を見直す |
| 解析に時間がかかる | ETLのサイズ、対象範囲 | 時間、PID、プロセスを先に限定する |
| WPAと数値が一致しない | 集計範囲、フィルター、単位 | 両方の時間範囲と分母をそろえる |
JSONのトップレベル名を混同しない
最も起きやすい設定ミスは、VS CodeとCopilot CLIの形式を混ぜることです。
VS Codeは次の形式です。
{
"servers": {}
}Copilot CLIは次の形式です。
{
"mcpServers": {}
}サーバー部分のcommandとargsが正しくても、トップレベル名が違えば認識されません。
VS Codeのログを確認する
VS Codeでは、コマンドパレットから次の操作を行います。
MCP: List Serversetwを選択し、「Show Output」を開きます。ここで、次のような原因を切り分けられます。
dnxが見つからない- NuGetパッケージを取得できない
- JSONの引数が不正
- MCPサーバーが起動直後に終了している
- ツールの検出に失敗している
VS CodeはローカルMCPサーバーが任意のコードを実行できる点について注意を促しており、初回起動時には信頼確認も行われます。発行元と起動コマンドを確認したうえで許可してください。(Visual Studio Code)
early previewとして運用する際の注意点
Microsoft.Windows.EventTracing.MCPはearly previewです。Microsoftのリポジトリでも、ETLパフォーマンスデータを解析するプレビュー版MCPツールとして案内されています。(GitHub)
本番運用へ組み込む場合は、次の点を考慮してください。
- ツール名、引数、応答形式が更新で変わる可能性がある
- 最新版を自動取得すると、同じプロンプトでも結果が変わる可能性がある
- 重要な判定はWPAや既存の解析手段でも検証する
- まず小さなETLで接続と出力内容を確認する
- 定型プロンプトと期待結果を保存し、更新後に再テストする
- 継続利用では、検証済みのパッケージバージョンへ固定することを検討する
dnxでは、パッケージ名に実在するバージョンを付けて固定する方法も利用できます。固定する場合は、NuGetで公開されているバージョンを確認し、検証済みのものを指定してください。(GitHub)
読み取り専用でも情報管理は必要
ETW MCPは、ETLデータへ構造化された読み取り専用アクセスを提供するローカルMCPサーバーです。ETLファイル自体を書き換える用途ではありません。(Microsoft for Developers)
ただし、「読み取り専用」や「ローカル実行」は、情報が一切外部へ渡らないことを意味しません。MCPサーバーが抽出したプロセス名、ファイルパス、スタック、コマンドラインなどの結果は、Copilotとの会話コンテキストとしてモデルへ送られる可能性があります。
機密性の高いETLを解析する場合は、次を確認してください。
- 組織のCopilot利用ポリシー
- 入力データと生成結果の取り扱い
- ETLに記録されているプロバイダーとイベント
- 個人名、ユーザーパス、サーバー名などの含有状況
- MCPサーバーが読み取れるファイル範囲
- 企業ネットワークのNuGet利用ルール
障害調査用のETLには、環境によってプロセス名、ユーザーフォルダー、コマンドライン、ファイルパスなどが含まれることがあります。外部サービスへ送信できない情報を扱う場合は、組織で承認されたCopilot環境とデータ処理条件を確認してから使用してください。
最短で解析を始めるための確認事項
ETW MCPによるETL解析は、次の順番で始めると失敗しにくくなります。
dotnet --infoで.NET 10 SDKを確認するGet-Command dnxまたはwhere dnxでコマンドを確認する- VS Codeの
mcp.json、またはCopilot CLIへSTDIOサーバーを登録する commandをdnx、argsをMicrosoft.Windows.EventTracing.MCPと--yesにする- クライアントまたはMCPサーバーを再起動する
- MCPツールが表示されることを確認する
- ETLの絶対パス、時間範囲、プロセス、指標、出力形式を指定して質問する
- 詳細な視覚確認が必要な箇所だけWPAで検証する
最初の質問では原因を断定させず、トレースの記録時間、主要プロセス、CPU上位プロセス、利用できるイベントを確認してください。その後、PID、時間範囲、モジュール、関数の順に絞り込むことで、WPAを最初から開かなくても効率よく原因候補へ到達できます。
コメント