「システムが遅い」という報告に対して、発注側は何も検証できない。ベンダーの説明を受け入れるか、疑いながら受け入れるかの二択しかない。この構図が変わる可能性がある。
Publickeyの報道によれば、Microsoftは2026年8月、アプリが遅い原因をAIがトレースログから分析する「Windows Performance Analyzer MCP」（WPA MCP）をプレビュー公開した。関連する報道では、Windowsの「重い・遅い」の性能分析に専門知識がもう不要になるのではないか、という文脈で伝えられている。
**この製品そのものが、中堅企業の日常業務にすぐ影響するわけではない。**取り上げる理由は、示されている方向にある。**これまで専門家しか読めなかった技術的な記録を、AIが読んで説明する。**この方向が進むと、発注側と受注側の情報の非対称が縮む可能性がある。
**ただし、そのためには前提がある。**読ませる記録が存在していなければ、AIが読めるようになっても何も変わらない。そして、この前提を満たしていない中堅企業が多い。
この記事を読むべき人
- システムの保守を外部に委託しており、内部の状態を把握できていない中堅企業
- 「遅い」「重い」という現場の声に対して、原因を確認する手段がない会社
- ベンダーからの「サーバーの増強が必要です」という提案を検証できずにいる会社
- 障害が起きるたびに、原因の説明を受けるだけで終わっている会社
- システムの記録がどこに、どれくらい残っているか把握していない会社
AI ASSESSMENT
PoC の前に「そもそも使えるか」を30分で見極めませんか？
対象業務、データ、権限、ログ、運用責任を確認し、PoC前に失敗要因と本番化条件を整理します。
「遅い」に対して発注側ができないこと
システムが遅いという問題が起きたとき、発注側が置かれる状況を整理する。
現場から「最近システムが遅い」という声が上がる。情報システムの担当が保守を委託しているベンダーに連絡する。ベンダーが調査し、報告が返ってくる。その報告に対して、発注側ができることは限られている。
できないこと1：原因の妥当性を判断する。「データ量の増加が原因です」という説明が正しいかを、独自に検証する手段がない。
できないこと2：対策の必要性を判断する。「サーバーの増強が必要です」という提案に対し、増強以外の選択肢がないのかを確認できない。
**できないこと3：改善の効果を確認する。**対策を実施した後、実際に改善したのかを客観的に確認できない。現場の体感に頼ることになる。
**できないこと4：時間の経過に伴う変化を把握する。**半年前と比べてどうなっているかが分からない。問題が顕在化してから初めて状況を知る。
**この4つは、いずれも技術力の不足に見えるが、実際には記録の不足に起因する。**記録があれば、AIであれ第三者の専門家であれ、読んで説明することができる。記録がなければ、誰も読めない。
AIが読める記録と、読めない記録
AIによる分析が実用化される方向にあるとしても、**分析できるのは記録されているものだけである。**この当たり前の前提が、実務では見落とされる。
記録の状態を3段階に分けて整理する。
**段階1：記録がない。**問題が起きた時点の状況が、どこにも残っていない。**この状態では、いつ何が起きたかを再現できない。**原因の特定は、問題を再現できるかどうかに依存する。
段階2：記録はあるが、期間が短い。数日分しか保存されておらず、問題が判明した時点で既に消えている。「先月から遅い」という報告に対して、先月の記録がない。
**段階3：記録があり、必要な期間保存されている。**この段階で初めて、分析が可能になる。
**多くの中堅企業は段階1か段階2にある。**そして、段階2の会社は「記録は取っている」と認識しているため、問題が起きるまで不足に気づかない。
**段階3へ進むために必要なのは、高度な仕組みではない。**保存期間の設定を変更することと、保存先の容量を確保することである。費用は発生するが、大きな額にはならないことが多い。
FREE DOWNLOAD
AI導入チェックリスト（PoC 失敗要因 10項目）
情シス部門が PoC 前に押さえるべき失敗要因を10項目に整理した無料チェックリスト。
記録しておくべき5種類
システムの状態を把握するために、記録しておくべき種類を挙げる。すべてを一度に整える必要はなく、上から順に価値が高い。
**種類1：応答時間の記録。**主要な画面や処理が、どれくらいの時間で完了しているか。**これが記録されていれば、「遅くなった」を数値で示せる。**現場の体感に依存しなくなる。
**種類2：エラーの記録。**いつ、どの処理で、どんなエラーが発生したか。利用者が報告しないエラーも記録に残る。
種類3：資源の使用状況。サーバーの処理能力、メモリ、ディスクの使用率の推移。「増強が必要」という提案の妥当性を判断する材料になる。
**種類4：利用状況。**どの機能が、いつ、どれくらい使われているか。負荷が集中する時間帯や、使われていない機能が分かる。
**種類5：変更の記録。**いつ、何を変更したか。問題の発生時期と変更の時期を突き合わせられる。
**このうち種類1と種類5は、費用がほとんどかからずに始められる。**種類5に至っては、システム側の仕組みではなく、変更の記録を人が残すだけで足りる。そして、障害の原因究明で最初に確認されるのは、「直前に何を変更したか」である。
保守契約に書いておくこと
記録を残し、必要なときに参照できる状態を作るには、**保守契約の内容に反映しておく必要がある。**書いておくべき項目を挙げる。
横にスクロールして確認できます
| 項目 | 決めておく内容 |
|---|---|
| 記録の種類と保存期間 | 何を、どれくらいの期間保存するか |
| 記録の所在 | どこに保存され、発注側がアクセスできるか |
| 定期的な報告 | 応答時間や資源使用率の推移を、定期的に報告するか |
| 分析の依頼 | 問題が起きた際の調査が、契約の範囲内か追加費用か |
| 記録の引き渡し | 契約終了時に、蓄積された記録を引き渡すか |
**2行目が実務上重要である。**記録がベンダーの環境にしかない場合、**発注側は自分で確認することも、第三者に見せることもできない。**セカンドオピニオンを取ろうとしても、材料がない。
3行目は、問題が起きる前に効く。定期的に推移を見ていれば、悪化の傾向を早期に把握できる。「遅くなった」と現場が言い出す前に、数値では既に悪化が現れていることが多い。
**4行目は、費用の予見性に関わる。**調査のたびに追加費用が発生する契約では、調査を依頼すること自体が躊躇される。その結果、原因が分からないまま放置される。
属人化を解消する順序
システムの状態を把握できない状態は、**技術の属人化として整理できる。**この解消には順序がある。
**順序1：記録を残す設定にする。**技術的な作業だが、設定の変更で済む場合が多い。
**順序2：記録を発注側でも見られるようにする。**閲覧できる権限を得る。**内容を理解できなくてもよい。**アクセスできることが先である。
**順序3：定期的に見る習慣を作る。**月に一度、応答時間とエラー件数の推移を確認する。数値の意味が分からなくても、増減の傾向は分かる。
**順序4：異常を判断する基準を持つ。**平常時の数値を知っていれば、異常が分かる。基準は、平常時のデータが蓄積されて初めて作れる。
**順序5：説明を求め、記録と突き合わせる。**ベンダーからの説明を、記録と照らして確認する。
**順序3が、最も費用がかからず、最も飛ばされる。**見る習慣がなければ、記録があっても意味がない。そして、見る習慣を作るのに必要なのは、月に15分の時間だけである。
現場の「遅い」を数値にする
記録を整える前に、費用をかけずに始められることがある。現場の体感を、数値として集めることである。
方法は単純で、遅いと感じた場面を記録してもらう。記録する内容は3つで足りる。
**内容1：いつ（日付と時刻）。**時間帯による傾向が見える。
**内容2：どの画面・どの処理か。**特定の処理に集中しているのか、全体的なのかが分かる。
内容3：どれくらい待ったか。体感でよい。「10秒くらい」で十分である。
**この3つを2週間集めるだけで、相当のことが分かる。**特定の時間帯に集中していれば、他の処理との競合が疑われる。特定の処理に集中していれば、その処理の作りが問題である可能性が高い。全体的かつ常時であれば、資源の不足が疑われる。
そして、この記録は委託先への相談の材料としてそのまま使える。「遅いです」という相談と、「毎日10時から11時に、この画面で10秒以上待つ事象が20件記録されています」という相談では、返ってくる回答が違う。
**この作業に必要なのは、共有の表計算ファイルを1つ用意することだけである。**システム投資も、技術知識も要らない。
「増強が必要」という提案を検証する
システムの性能に関する提案で最も多いのが、サーバーの増強である。この提案を検証するための観点を整理する。
**観点1：現在の使用率はどれくらいか。**処理能力、メモリ、ディスク。これらの使用率が示されていない増強提案は、根拠が確認できない。
**観点2：使用率が高いのは常時か、特定の時間帯か。**特定の時間帯だけであれば、処理の実行時刻をずらすことで解決する場合がある。増強せずに済む可能性がある。
観点3：増強によって、どの程度改善する見込みか。「速くなります」ではなく、どの処理がどれくらい改善するかの見込みを聞く。
**観点4：増強以外の選択肢は検討されたか。**処理の見直し、不要なデータの削除、実行時刻の分散。これらが検討されたうえでの増強提案かを確認する。
**観点5：増強後の費用はどうなるか。**クラウドであれば月額が増える。一度増強すると、下げる判断は行われにくい。
**観点4が最も重要で、最も省略される。**増強は実施が容易で確実に効果が出るため、提案として選ばれやすい。**一方、処理の見直しは工数がかかり、効果も確実ではない。**したがって、検討されないまま増強が選ばれる構造がある。
**発注側が観点4を問うだけで、他の選択肢が検討される。**そして、その結果として増強が最適だと確認できれば、判断に納得感が伴う。
AIによる分析が実用化されたときに備える
本稿の出発点である「AIが技術的な記録を読んで説明する」という方向が進んだ場合、準備ができている会社とそうでない会社の差が開く。
**準備ができている会社。**記録が十分な期間保存され、発注側がアクセスでき、平常時の状態が把握されている。**この状態であれば、AIによる分析をそのまま適用できる。**ベンダーの説明を検証する材料も揃う。
**準備ができていない会社。**記録がない、あるいは保存期間が短い。分析の道具が手に入っても、読ませるものがない。
**この差は、技術投資の差ではなく、設定と習慣の差である。**そして、後から埋めることはできる。**ただし、過去の記録は遡って作れない。**平常時のデータが必要なら、平常時に取り始めるしかない。
**したがって、AIによる分析の実用化を待つ必要はない。**待つ間にできることが、記録を残し始めることである。そして、記録があれば、AIを使わなくても第三者の専門家に読ませることができる。
「見られていること」の効果
記録を発注側が見られる状態にすることには、分析以外の効果もある。委託先との関係の質が変わる。
これは委託先を疑うという話ではない。見られている状態と、見られていない状態では、報告の粒度が自然に変わるということである。
具体的には、次のような変化が生じる。
変化1：報告が具体的になる。「問題ありません」ではなく、数値を伴う報告になる。
**変化2：悪化の傾向が早く共有される。**発注側も数値を見ているため、隠す意味がなくなる。むしろ、先に説明したほうが自然である。
変化3：提案の根拠が示される。「増強が必要」という提案に、根拠となる数値が添えられるようになる。
**変化4：発注側の質問が具体的になる。**数値を見ているため、「なぜここが増えているのか」といった問いが出る。
**これらの変化は、委託先にとっても悪いことではない。**説明の材料が共有されていれば、提案が通りやすくなる。根拠を示せない状態で「増強が必要」と言うより、数値を見せて説明するほうが、双方にとって楽である。
よくある質問
Q. 記録を残すと、システムの動作が遅くなるのではないか。 A. 記録の種類と量による。**詳細な記録を常時取得する構成では影響が出る場合があるが、応答時間やエラーの記録程度であれば、通常は問題にならない。**懸念がある場合、委託先に影響の有無を確認する。
Q. 記録を見ても、数値の意味が分からない。 A. 最初は分からなくてよい。**必要なのは、平常時の数値を知っておくことである。**平常時に応答時間が2秒であることを知っていれば、5秒になったときに異常だと分かる。絶対値の意味は分からなくても、変化は分かる。
Q. 委託先が記録の開示に応じない。 A. 理由を確認したい。契約に定めがないためか、技術的に困難なためか、他の顧客の情報が混在しているためか。**理由によって対応が変わる。**契約の問題であれば、次回の更新時に条項を追加する交渉ができる。
Q. 保存期間はどれくらいが適切か。 A. 一律の基準は示せないが、判断の材料はある。**問題が顕在化するまでの期間を考えると、「遅くなった」という報告は、悪化が始まってから数週間から数か月後に出ることが多い。**その時点で原因の時期を遡れる期間が必要になる。
Q. 記録を保存する場所は、どこにすべきか。 A. 対象システムとは別の場所に置くことを勧める。**システム自体に障害が発生した場合、そのシステム内にしか記録がなければ、参照できない可能性がある。**加えて、委託先の環境だけでなく自社側からも参照できる場所に置くことで、前述の確認1が実行できるようになる。
Q. すべてのシステムで記録を整えるべきか。 A. 優先順位をつけるほうが現実的である。業務が止まると影響が大きいシステム、利用者が多いシステム、外部からアクセスされるシステムから始める。
Q. 記録を見られるようにすると、委託先との関係が悪くなるのではないか。 A. 依頼の仕方によって受け取られ方は変わる。**「監視したい」ではなく「説明を受けたときに理解できるようにしたい」と伝えると、多くの委託先は協力的である。**むしろ、状況を共有できる発注側のほうが、委託先にとっても話が早い。関係が悪化する懸念があるなら、定例の報告に数値を含めてもらうところから始められる。
Q. 古いシステムで、記録を取る仕組みが入っていない。 A. システムそのものに手を入れなくても、外側から取得できる記録がある。**サーバーの資源使用率、ネットワークの通信量、応答時間の外形的な計測。**これらはシステムを改修せずに取得できる場合が多い。まずは外側から取れるものを確認し、それで不足する部分についてシステム側の改修を検討する順序が現実的である。
Q. AIによる分析を、いま導入すべきか。 A. 記録が整っていない段階で導入しても、分析する対象がない。**先に記録を整えることを勧める。**記録が整えば、AIを使うか専門家に依頼するかは、その時点で選べる。
システムの状態を把握できるようにしたいとき
システムの内部が見えない状態は、**技術の問題である以前に、記録と契約の問題である。**そして、この2つは技術者でなくても手を入れられる。
現在のシステムでどんな記録が取得され、どこに保存されているかを確認し、把握できる状態にしたい場合は、システム開発・DX推進の相談で受け付けている。記録を集めて分析できる形にしたい場合はデータ基盤・BIの相談、記録の保全やアクセス制御の観点から扱いたい場合はセキュリティ関連の相談が該当する。
保守契約の内容そのものを見直したい、あるいはベンダーからの提案を第三者の視点で確認したい場合も、お問い合わせから相談できる。自社の現在地を整理する段階であればDX成熟度診断から始められる。
なお、保守運用の委託範囲と費用の考え方は保守契約の範囲と責任の決め方、監視の仕組みの選び方は中小企業の監視・オブザーバビリティ導入ガイドで別途扱っている。本稿は、記録を残すことと発注側が見られることに絞っている。
参照した情報
- Publickey「アプリが遅い原因をAIがトレースログから分析してくれる『Windows Performance Analyzer MCP』（WPA MCP）、マイクロソフトがプレビュー公開」（2026年8月5日）: https://www.publickey1.jp/blog/26/aiwindows_performance_analyzer_mcpwpa_mcp.html
- ITmedia「『Windowsの重い・遅い』の性能分析に専門知識はもう不要？ Microsoftが新ツール」（2026年8月10日）: https://kn.itmedia.co.jp/kn/articles/2608/10/news034.html
Windows Performance Analyzer MCPがプレビュー公開されたこと、アプリが遅い原因をAIがトレースログから分析する機能であることは、上記報道の記載に基づく。
**本稿執筆時点で、Microsoftの公式ドキュメントは取得できていない。**したがって、対応する環境、必要な前提条件、利用方法、正式提供の時期については本稿では扱っていない。**本稿は特定のツールを推奨するものでも、その機能を評価するものでもなく、示されている方向を出発点として、発注側が事前に整えておくべき前提を整理するものである。**発注側ができないこと4項目、記録の3段階、記録すべき5種類、保守契約の5項目、属人化解消の5順序、関係の質に生じる4つの変化は、GXOが中堅企業の実務に合わせて整理したものであり、Microsoftが示した枠組みではない。記録の取得が既存システムの性能に与える影響は、システムの構成と記録の内容によって異なるため、実際の適用にあたっては委託先への確認を経てほしい。
