結論。AIエージェントに見せる範囲を「デスクトップ全体」から「対象ウィンドウ1つ」に絞ったところ、同じ電卓アプリの状態取得で応答の文字数が5,630字→678字、88%の削減になりました。
削減の中身は、タスクバーの全ボタン列挙や、操作と無関係な背面ウィンドウの情報でした。 文字数はトークン数そのものではありませんが、AIエージェントに渡すデータ量の目安として、この記事では一貫して「文字数」を単位に使います。
何を比べたか
Windowsの画面をAIエージェントに操作させるMCPサーバー(AIとアプリケーションをつなぐ仕組み)として、windows-mcpを使っていました。このSnapshotというツールは便利な反面、呼び出すたびにデスクトップ全体——今操作したいアプリだけでなく、タスクバーの全ボタン、裏で開いている他のアプリまで含めて——を走査して返します。
そこで、対象ウィンドウ1つだけに範囲を絞った軽量な代替(windows-mcp-liteのReadWindow)を作り、本番で実際に稼働している両方のサーバーへ、同じ電卓アプリのウィンドウについて1回問い合わせて比較しました。
結果
測定単位は応答の文字数です(トークナイザにかけた実測トークン数ではありません)。
| 応答の文字数 | |
|---|---|
windows-mcp Snapshot(デスクトップ全体) |
5,630字 |
windows-mcp-lite ReadWindow(電卓のみ) |
678字 |
| 削減率 | 88.0% |
同じ「電卓の状態を教えて」という問い合わせに対して、応答はおよそ9分の1になりました。
比較に使った2件の生の応答はそのまま公開しています。
windows-mcp Snapshotの応答・
windows-mcp-lite ReadWindowの応答
のテキスト長は、それぞれ5,630字・678字と一致します。
なぜこれだけ減るのか
Snapshotの生の応答を見ると、原因は一目瞭然でした。UIツリーの末尾には、電卓とは何の関係もないタスクバーの通知領域が、こういう調子で1個ずつ列挙されています(上記の生の応答からの抜粋)。
button "ネットワーク ネットワーク 3 インターネット アクセス"
button "ボリューム BenQ EX2710S (NVIDIA High Definition Audio): 100%"
button "時計 19:35 2026/08/03"
さらに、裏で開いていた他のアプリ(PowerShell・Excel・Claude・Edge・エクスプローラー)の情報や、名前を持たない空のウィンドウまで含まれていました。電卓の四則演算だけを行わせたいのに、AIはこれらを律儀に全部読み込むことになります。
windows-mcp-liteのReadWindowは、この走査範囲を対象ウィンドウ1つに絞っているだけです。特別な要約や圧縮はしていません。見せる範囲を絞るだけで、これだけの差が出ました。
この結果が言っていないこと
- 測定単位は文字数で、実際のトークン数(トークナイザで分割した数)ではありません。 使用モデルのトークナイザによって文字とトークンの対応は変わるため、88%という削減率はトークン数換算では変動しうる、応答量の目安です。
- 実測は電卓アプリ1本・1回きりです。UI要素数がもっと多い複雑なアプリでは対象ウィンドウ自体の情報量も増えるため、削減率はここまで出ない可能性があります。
- 測ったのは応答の情報量であって、AIエージェントが実際にタスクを完遂できたかの精度は別軸です。今回検証したのは電卓での四則演算という単純な操作です。
- 「対象を名前で探す」処理自体もwindows-mcp本体より薄くしたぶん、本体が持っていた救済ロジック(フォアグラウンドのウィンドウなら列挙外でも拾う)を最初は引き継げておらず、モーダルダイアログ表示中のウィンドウを検出できないバグを実際に発生させました。軽量化には、本体の細かな配慮まで見落とすリスクが伴います(このバグは原因を特定し、修正済みです)。
観測する量を絞るという方向は、生成を任せる場合と違って「返ってきた内容が正しいか」を別途検証し直す必要がありません。前回の記事で書いた「検証が要らない削減から先に取るべき」という教訓の、具体的な実装例です。