Claude Code のデスクトップ操作、内蔵の computer-use ではなく Windows-MCP を使っている理由

Claude Code のデスクトップ操作には computer-use という仕組みがある。画面のスクリーンショットを撮り、その画像から目的の要素の位置を推定してピクセル座標でクリックする方式だ。一方、Windows-MCP は Windows の UI Automation API を使い、画面上の要素を構造化されたツリー（要素名、役割、座標を持つ）として取得する MCP サーバー。同じタスク（メモ帳に Hello from Claude Code と入力）を両方に実行させると、computer-use は操作5回（スクリーンショット→座標推定→クリック→全選択→削除→入力）、Windows-MCP は操作2回（ツリー取得→入力）で終わる。減ったのは「位置を画像から確かめるための往復」だ。

ここで引っかかるのは「画像から位置を推定する」という前提の脆さだ。デスクトップの解像度が変わったら、スケーリング設定が変わったら、ウィンドウが1ピクセルずれたら——推定は外れて隣の要素を押す。computer-use は便利だが、この種の「見た目依存」の脆さを抱えている。それに対して Windows-MCP は「この要素の名前は『Text editor』で座標は(806, 635)」という構造情報を取るので、推定ゼロ。実装の正確さではなく「構造を読む」という根本的に別の戦略で、ずっと堅牢になる。テクノロジー選択は「どれが便利か」で決まりやすいが、本当に見るべきは「どれが不確実性に強いか」だ。

AI ツールを使うとき、「画像認識で雑に判定する」より「構造として理解させる」ほうが、うっかりミスが確実に少ない。会社の業務システムを自動化したくなるとき、GUI ベースの自動化（RPA）は解像度変更で壊れる。一方、API や外部連携、データベース直接操作など「構造」を通す自動化は、環境が変わっても堅牢に動く。急ぎの自動化のために GUI ベースの短期的ツールを作る気持ちは分かるが、本番運用を考えるなら最初から「構造を通す設計」を心がけること。後々の保守の手間が格段に減る。