「午後になると業務システムが重い」。保守を請けている側にとって、いちばん困る報告のかたちです。
エラーは出ていない。ログにも異常はない。開発環境で同じ操作をしても再現しない。結局「様子を見ましょう」と返して、次の月にもう一度同じ報告が来る。性能の問題が放置されがちなのは、直せないからではなく、原因にたどり着く工程が重すぎるからです。
Windows のアプリケーションであれば、トレースを取るところまでは難しくありません。詰まるのはその先です。取れたトレースを Windows Performance Analyzer（WPA）で開くと、グラフと表が大量に並ぶ。どのテーブルを見ればいいのか、どのスタックが問題なのかを読み解けるのは、社内でも数人だけ。その数人が別案件で埋まっていれば、調査は止まります。
トレースに自然言語で質問する
マイクロソフトが、この読み解きの部分に手を入れました。Windows Performance Analyzer MCP（WPA MCP） のアーリープレビューです（Introducing WPA MCP — Microsoft Performance and Diagnostics Blog）。
やっていることは、WPA のトレース分析ワークフローに GitHub Copilot CLI を接続し、グラフや表を手作業でたどる代わりに、トレースの中身へ自然言語で問い合わせられるようにするというものです。
できるようになるのは、おおむね次の3つです。
- 「この時間帯にCPUを食っていたのは何か」といった平たい言葉で調査を始められる
- 見るべきWPAのテーブルやグラフに早くたどり着ける
- 重いCPU処理、コールスタック、入力の遅延といった症状の在りかを特定できる
現時点のアーリープレビューは GitHub Copilot のみの対応で、利用には有効な Copilot のサブスクリプションが必要です。あわせて、イベントトレースログ（ETL）に対して同種の分析を行う ETW MCP も開発されています。マイクロソフトはこの2つを補完関係として位置づけていて、視覚的にトレースを確認したい開発者は WPA MCP、自動化された仕組みからは ETW MCP、という使い分けを想定しています。
効くのは「分析」ではなく「入口」
この手のツールを見たときに期待しすぎると外します。AIが原因を断定してくれるわけではありません。トレースの解釈には、そのシステム固有の事情が要ります。夜間バッチが走る時間、ウイルス対策ソフトのスキャン設定、共有ストレージの構成。そこはAIの側にない情報です。
では何が変わるのか。調査の入口にたどり着くまでの時間です。
| 工程 | 従来 | MCPを挟んだ場合 |
|---|---|---|
| トレース取得 | 変わらない | 変わらない |
| 見るべき箇所の特定 | WPAに慣れた人が数時間 | 自然言語の質問から絞り込む |
| 原因の解釈と対策 | 変わらない（人の判断） | 変わらない（人の判断） |
真ん中の行だけが縮む、という理解が実態に近い。ただ、この真ん中の行こそが「特定の人しかできない」ために調査が止まっていた場所なので、効き方としては小さくありません。
保守契約に載せるなら、決めるのは「取る条件」
外部に保守を委託している立場でこの流れを活かすなら、ツールの導入より先に決めることがあります。トレースをいつ取るかです。
「重い」という報告が来てから取りに行くと、たいてい現象は終わっています。有効なのは逆で、利用者が重いと感じた瞬間に、利用者自身の操作でトレースが残る状態を作っておくこと。取得の手順を1つのショートカットにまとめて配っておくだけでも、再現待ちの往復が消えます。
そのうえで、保守の取り決めとして次の2点を明文化しておくと運用が回ります。
- 性能の申告を受けたときに、何をもって調査開始とするか（トレースが添付されていること、など）
- 調査の結果が「アプリ側の問題ではなかった」場合の扱い（端末やネットワーク側の所見をどこまで報告に含めるか）
2つめは軽視されがちですが、性能調査の結果はかなりの割合で「アプリの外」に着地します。ここを決めていないと、調べた側の作業が誰の成果にもならない形で終わります。
似た構造の切り分けとして、アプリが遅い原因がリージョン間のレイテンシだったケースや、常時プロファイリングで「遅い」を継続的に観測する構成も参考になります。MCP そのものの仕組みについてはMCP完全ガイドにまとめています。
いま試すべきかどうか
アーリープレビューであること、Copilot のサブスクリプションが要ること、対象が Windows のトレースであることを踏まえると、いま全社的に導入する種類のものではありません。
一方で、Windows 上で動く業務システムの保守を抱えていて、性能の申告に毎回時間を取られているなら、試す価値ははっきりあります。試すコストが低く、効く場所が明確だからです。
手を付けるなら、まず直近で「重い」と言われて未解決のまま残っている案件を1つ選び、それでトレースを取ってみるところからです。うまくいけばその案件が片づき、うまくいかなくても、何が足りなかったかが次の調査の設計に返ってきます。
業務システムの性能調査や保守の体制づくりについては、グリームハブの開発・AI・自動化のご相談で承っています。システムの構成や利用状況によって取るべき手順は変わるため、個別にお見積りします。お問い合わせからご相談ください。
Sources
- Introducing WPA MCP: Early Preview of AI-assisted trace analysis in Windows Performance Analyzer — Microsoft Performance and Diagnostics Blog
- アプリが遅い原因をAIがトレースログから分析してくれる「Windows Performance Analyzer MCP」、マイクロソフトがプレビュー公開 — Publickey
- Windows Performance Analyzer — Microsoft Learn
- Model Context Protocol
