macOS と Windows 両対応の Computer Use エージェントを比較検討したメモ — Hermes Agent・cua-driver を軸にした 2026 年 9 月時点の選定

チーム内で「デスクトップ操作を自動化する AI エージェントを本気で検証したいが、macOS と Windows のどちらでも動かないと社内配布に載せられない」という相談があり、Nous Research の Hermes Agent を第一候補に、trycua の cua-driver、ByteDance の UI-TARS Desktop、Simular の Agent S、Open Interpreter までまとめて比較検討しました。合わせて ChatGPT デスクトップアプリの Computer Use と Claude デスクトップアプリの Cowork も対象に含めています。

この記事は 2026-09-03 時点で公式ドキュメント・公式 GitHub・公開リリースを軸に調べた内容で、両 OS の実機で全候補を横並びに動かした比較ではありません。それでも、機能表を埋めた結果に載らない「背景操作の但し書き」「TCC・UIPI・Session 0 のような OS 側の壁」「マルチモニターと日本語入力の制約」あたりは、選定の初期段階で押さえておく価値があると思ったので、5 つの論点に整理して残します。

Computer Use には 2 種類の操作範囲がある

まず用語の整理から入ります。「Computer Use」と一言で言っても、実際にはっきり区別すべき 2 つの範囲があります。

1 つ目は「ブラウザの中だけ」を操作する範囲です。Claude in Chrome、Google Gemini 2.5 Computer Use、OpenAI Computer Use API の browser 環境などがここに入ります。ブラウザ内の DOM や Chromium プロセス経由でクリックや入力を発行するので、対象は Web アプリに限定されます。

2 つ目は「OS 全体」を操作する範囲で、ネイティブアプリまで含みます。ChatGPT デスクトップアプリの Computer Use プラグイン、Claude Cowork の Computer use、Hermes Agent、cua-driver、UI-TARS Desktop、Agent S などが該当します。ここでは Excel・Finder・Explorer・業務クライアントアプリを直接触れます。

社内システムに API が生えていないケースや、Microsoft Excel と業務アプリを跨いだデータ転記を任せたいケースでは、2 つ目の「OS 全体」でないと要件を満たせません。今回の比較は、この 2 つ目の範囲に候補を絞っています。

論点 1: 公式アプリで両 OS ＋ OS 全体を満たすのは ChatGPT と Claude だけ

2026-09-03 時点で、macOS と Windows の両方で OS 全体を操作できる公式アプリは、実質 2 つに絞られます。

ChatGPT デスクトップアプリの Computer Use は macOS・Windows 両方で提供されており、対象アプリを事前に許可した上で GUI 全般を操作できます。ただし、Windows 版はアクティブなデスクトップ上でポインタと入力を前面で乗っ取る方式が明記されています。同じマシンで別作業を並行させる想定なら、Windows 環境では実質的に「専用 PC ・仮想マシン」を用意することになります。

Claude デスクトップアプリの Cowork 内で提供される Computer use はベータ扱いで、macOS と Windows の両方に対応します。設定は「Settings > General > Enable computer use」のトグルで、macOS ではアクセシビリティと画面収録の権限を先に付与しておく必要があります。現行ヘルプの記載範囲は Pro / Max であり、Team / Enterprise は対象外です。Cowork とは別に Claude in Chrome が 2026 年に GA していますが、こちらはブラウザ内限定なので、今回の比較の範囲外です。

一方、Google の Gemini Computer Use は 2026 年 6 月に Gemini 3.5 Flash に統合され、現在は Gemini 3.8 Flash が推奨モデルです。ブラウザ・モバイルに加えデスクトップ環境（OS レベルのカーソル操作）も API 経由で提供されていますが、Gemini デスクトップアプリ側の Computer Use は 2026-08 時点でクローズドベータ扱いで、公式アプリとして両 OS ＋ OS 全体を触れる段階には達していません。Microsoft Copilot の Copilot Actions は Windows 11 で実験的プレビュー扱いで、macOS 版 Copilot に同等のエージェント機能は確認できませんでした。Apple Intelligence の次世代 Siri は汎用の「画面操作」ではなく、App Intents フレームワーク経由の構造化されたアプリ連携が中心で、モデル像が根本的に違います。

「両 OS ＋ OS 全体＋一般提供」という条件に絞ると、公式アプリ勢では ChatGPT と Claude の 2 択、というのが現時点の結論です。

論点 2: OSS では Hermes Agent と cua-driver、UI-TARS、Agent S、Open Interpreter が有力

公式アプリではモデルもワークフローも固定になります。自社プロダクトに組み込みたい、モデルを自由に差し替えたい、あるいはローカル LLM で完結させたい場合は、OSS 側で候補を絞る必要があります。今回、両 OS でネイティブアプリを操作できる OSS として整理したのは以下の 5 つです。

Hermes Agent（Nous Research 製、MIT ライセンス）: 自律型 AI エージェントのオーケストレーション層。標準機能として computer_use ツールセットを持ち、内部で cua-driver を MCP 経由で呼び出す。モデル非依存で、Claude・GPT・Gemini・ローカル VLM を差し替えられる
cua-driver（trycua 製、MIT ライセンス）: エージェント側の計画層を持たず、画面取得・UI 要素取得・入力ディスパッチだけを提供する共通操作基盤。Python SDK・TypeScript SDK・MCP サーバー・CLI の複数入口を持つ
UI-TARS Desktop（ByteDance 製、Apache-2.0 ライセンス）: UI-TARS モデルを使った Electron ベースの GUI エージェント。アクセシビリティツリーに依存せず、スクリーンショットのみから座標を推論する「Pure Vision」方式
Agent S（Simular 製、Apache-2.0 ライセンス）: Python SDK 提供のエージェントフレームワーク。階層的計画とグラウンディングモデルを分離した構成で、ICLR 2025 で採択された論文が背景にある
Open Interpreter: OpenAI Codex をフォークして Rust ネイティブハーネスに載せ替えた現行版では、QA skill が Web に agent-browser、ネイティブアプリに trycua を呼び出す構成。旧 Python 版の OS mode の記事とは前提が変わっている

Open Interpreter が trycua を呼び出している点は、公式リポジトリ README の Computer Use セクション（rust-v0.0.40 タグ）に以下のように明記されています。

Open Interpreter ships with a QA skill that lets any model operate and test interfaces. It can drive web apps in a real browser with agent-browser, or operate and test native apps with trycua.

（訳: Open Interpreter は、任意のモデルにインタフェースを操作・テストさせる QA skill を同梱している。実ブラウザ上の Web アプリは agent-browser で、ネイティブアプリは trycua で操作・テストできる。）

このうち、cua-driver は「操作を担当する共通基盤」であり、Hermes Agent は「オーケストレーション層」なので、この 2 つは競合ではなく組み合わせて使う関係です。Hermes 公式ドキュメントの Computer Use ページにも、cua-driver に MCP over stdio で接続する構成が明記されています。

論点 3: 「no-foreground contract」の実際の運用範囲

Hermes Agent と cua-driver の紹介文で強調されるのが「カーソルやフォーカスを奪わない背景操作」です。ユーザーが同一マシンでコーディングや文章作成を続けたまま、背面でエージェントに別アプリを操作させるという触れ込みで、これは従来のフォアグラウンド占有型のエージェントに対する最大の差別化ポイントとして提示されています。

技術的には、cua-driver が OS ごとに以下の API を使い分けることでこれを実現しています。macOS では Accessibility API（AX）と非公開の SkyLight SPI を使ってウィンドウ階層をたどり、プロセス ID スコープで動作する SLPSPostEventRecordTo でシステムカーソルを移動させずに目的のウィンドウへイベントを注入します。Windows では UI Automation でコントロールツリーを走査し、SendInput と PostMessage を組み合わせてフォアグラウンドフォーカスを奪わずに入力を発行します。

ただし、この背景操作は無条件に成立するわけではありません。cua 公式ドキュメントの Best-effort background では明示的に best-effort background として説明されており、背景操作ができないケースでは前面で実行するフォールバックが必要と書かれています。具体的な非対応・注意対象として cua 側の Known Limits が挙げているのは、Blender や Unity のような独自描画のキャンバスアプリと、ほとんどのネイティブゲームです（管理者権限で起動したウィンドウについては、論点 4 で扱う Windows 側の elevated-integrity 制約が該当します）。

つまり、「Hermes を入れれば全アプリの操作が自分の作業に一切干渉しない」ではなく、「背景操作を優先するが、対象アプリと OS の状態次第では前面化する場面が残る」というのが正確な理解です。導入検討時は、実際に使うアプリで背景操作が成立するかを個別に確認する必要があります。

論点 4: macOS と Windows で発生する OS 側の壁

両 OS 対応と言っても、実際には OS の仕組み由来の壁が別々に存在します。ここは公式アプリでも OSS でも共通の制約になります。

macOS 側で最初に当たるのは、TCC（Transparency, Consent, and Control）による権限管理です。エージェントプロセスが動くためには「システム設定 > プライバシーとセキュリティ」で「画面収録」と「アクセシビリティ」の両方を明示的に手動許可する必要があり、この操作は GUI 対話を前提としています。CI/CD やヘッドレスサーバーへのプロビジョニングを自動化しづらいのはここが理由です。加えて、cua-driver が使う AX や SkyLight は SPI で、macOS のバージョンアップで挙動が変わる可能性が残ります。Hermes のプラットフォーム対応表では、macOS の Tier 1 が Apple Silicon のみで、Intel Mac は Unsupported として扱われている点も配布対象を絞る際に効きます。

Windows 側の壁は、UIPI（User Interface Privilege Isolation）と Session 0 分離の 2 つが主戦場です。UIPI により、一般ユーザー権限（Medium Integrity）で動くエージェントは、管理者権限（High Integrity）で起動されたアプリや UAC 昇格ダイアログに対して UI Automation 操作やキーストロークを送れません。cua 公式の対応表でも、elevated-integrity 境界は未対応・未検証事項として扱われています。Session 0 分離は、SSH でログインしたセッションからは通常のユーザーデスクトップが見えない、という制約です。cua 公式には Windows SSH での運用手順が別途用意されており、GUI を操作するドライバーは対話セッション内で起動し、SSH 側はそこへ接続するという二段構えが必要になります。

もうひとつ、両 OS で共通に地雷になりやすいのがマルチモニターです。UI-TARS Desktop と Agent S は単一モニターを前提にした挙動が公式ドキュメントに明記されており、PyAutoGUI も主モニターのみを扱います。複数画面が業務前提なら、この時点で選択肢が絞られます。

論点 5: 日本語 IME・全角文字・DPI スケーリングの制約

デモ動画では英語 UI に対して英語入力を流すだけで完結しがちですが、国内業務アプリを本格的に触らせる場面では、日本語入力周りの実装差が効いてきます。

まず、日本語入力は IME 経由の合成入力（composition）を伴うため、SendInput や SLPSPostEventRecordTo が発行する生の仮想キーコードでは、期待どおりに文字列が確定しない場面があります。エージェント側がクリップボード貼り付けにフォールバックする実装になっているかどうかで、日本語文の入力成功率が大きく変わります。公式ドキュメントで日本語 IME の扱いに触れているエージェントは、今回の調査範囲では見当たりませんでした。

全角スペース・全角括弧・記号のバリアントは、業務システムの入力バリデーションで弾かれることがあり、モデル側のトークナイズと OS 側の文字コード変換で綴りがずれる場面が出ます。ここも「英語での成功率」から素直に外挿できない領域です。

DPI スケーリングと座標系のずれも軽視できません。4K ディスプレイ + 200% スケーリングの環境で Pure Vision 方式のエージェントを動かすと、モデルが受け取る画像の解像度と、実際にクリックすべき論理座標との対応が崩れやすくなります。cua-driver のようにアクセシビリティツリーで要素の bounds を取れる構成の方が、この点では素直です。

これらは英語のデモや OSWorld のスコアからは読み取れない部分なので、国内業務アプリで採用する前に、必ず自分の環境で日本語文の入力・保存・再読込を含む短いタスクを試して確認する必要があります。

Hermes Agent を選ぶ場合の初期構成

上記の論点を踏まえたうえで、Hermes Agent を軸に据える場合の初期構成として妥当だと判断したのは以下の形です。あくまで公開ドキュメントから判断した構成であり、実測で最適化したものではありません。

オーケストレーション層: Hermes Agent（Hermes Desktop または CLI）
操作層: Hermes に組み込まれた computer_use ツールセット経由で cua-driver を MCP over stdio 接続
推論モデル: 用途と機密性に応じて Claude・GPT・Gemini のいずれか、または vLLM・LM Studio・Ollama 経由のローカル VLM
Web 主体のタスク: computer_use ではなく Hermes の browser toolset（ヘッドレス Chromium ベース）を使い分ける
権限モード: 本番運用前は必ず bounded モード（能力マニフェストで許可対象を事前定義）から入り、YOLO / unrestricted は使い捨て VM 内に限定する

Hermes 側の導入は公式インストールガイドに従います。macOS と Windows 両方に公式インストーラーがあり、Windows は WSL を必須にせずネイティブ版を使えます。設定ディレクトリは OS 共通で ~/.hermes/（root 実行時は /root/.hermes/ または $HERMES_HOME）に置かれます。既存環境なら hermes update で更新できます。

Computer Use を有効化する手順は、Hermes 公式ドキュメントの Computer Use ページに沿って以下のようになります。

hermes computer-use install
hermes computer-use status
hermes computer-use doctor
hermes -t computer_use chat

hermes computer-use doctor は不足しているドライバーや権限をレポートするので、macOS では doctor が示すアプリに対してアクセシビリティ・画面収録の権限を先に付与しておきます。

初回の確認タスクには、業務にありがちな「メモ用アプリを開く → 日本語の短い文章を入力する → 指定した検証用ファイルに保存する → 保存結果を確認する」のような、入力・保存・再確認までを 1 サイクル回す短いタスクが向いています。単にクリックを 1 回発行するデモよりも、日本語入力の合成、ファイルダイアログの操作、保存後の再読込という運用に近い工程を含められるので、両 OS 間の差が見えやすくなります。

開発用ライブラリ・SDK として見た場合の位置づけ

自社プロダクトへ組み込む前提で SDK 選定をする場合は、以下のような棲み分けで見ています。

共通の操作基盤として最有力: cua-driver。Python の cua_driver、TypeScript の @trycua/cua-driver、MCP サーバーの 3 系統から選べる。エージェント側の計画とモデルは自前で持ち込む前提
Node.js / Electron 系の GUI エージェントを自作: UI-TARS SDK（@ui-tars/sdk）。公式に Experimental と明記されているが、NutJSOperator でクロスプラットフォームに動く
Python で研究・精度比較: Agent S（gui-agents）。主モデルとは別にグラウンディングモデルを設定できる階層構成
最小限のマウス・キー操作: PyAutoGUI または nut.js。AI による意味理解・計画は別途載せる前提
API 直叩き: OpenAI Computer Use API または Anthropic Computer Use ツール。API 自体はユーザー PC を直接操作しないので、画面取得・入力実行・反復・結果確認のループを実装する必要がある

Electron で自社アプリへ組み込むなら、まず cua-driver の TypeScript SDK か、別プロセスの MCP 接続のどちらから入るかを比較するのが素直です。画面認識モデルと操作ループも自分で持ちたいなら UI-TARS SDK を追加評価する順番になります。

セキュリティ境界と権限モードの設計は避けて通れない

OS 全体を操作できるエージェントを常駐させる構成は、そのままでは OS の広範な攻撃面を露出させます。特に「間接的プロンプトインジェクション」への対策は避けて通れません。Web ページに埋め込まれた不可視の悪意ある指示をエージェントが視覚的に読み取り、そのまま端末上でシェルコマンドを実行してしまう、という筋書きは実際に議論されています。

Hermes Agent がドキュメント上で提示している 3 段階の権限モードは、この設計を素直に扱っています。standard モードは操作ごとに対話的な承認を要求する既定動作、bounded モードは事前に定義した能力マニフェスト（許可アプリ識別子・許可 Web オリジン・指定ツール）だけを実行可能にするフェイルクローズ運用、unrestricted / YOLO モードは対話確認を全廃する高速モードで、使い捨て VM 内での限定運用が推奨されています。

破壊的操作（click・type・drag・scroll・key・focus_app）は既定で承認必須になっており、sudo rm -rf / や curl | bash、fork bomb などの入力はハードブロックされる、といった防御も組み込まれています。ゴミ箱を空にする・ログアウトするような危険なキー操作も同様にブロック対象です。

商用アプリ側では、ChatGPT の Computer Use がターミナルアプリの直接操作を遮断する挙動や、金融系サイトでの入力確認といった画一的な制限を持ちます。Claude 側は、Cowork の Computer use が新規権限承認の仕組みを持ち、macOS ではアクセシビリティ・画面収録の権限承認を明示的に必要とします。

いずれのツールでも、物理ホスト OS に無制限モードのエージェントを直接常駐させるのは避け、権限モードを bounded に絞るか、Lume や Windows Sandbox のような隔離環境にエージェントの活動範囲を閉じ込める設計を先に決める必要があります。

ローカル実行とクラウド実行を分けて考える

「Computer Use をローカルで動かす」と言うとき、実は 2 つの独立した選択が絡んでいます。1 つは操作の実行場所、もう 1 つは推論の実行場所です。

操作をローカルで動かしても、モデルをクラウド API に接続すれば、判断に必要なスクリーンショットとツール結果はモデル側へ送信されます。機密情報を含む画面を触るワークフローでは、モデル側の推論もローカルで完結させないと、実質的にデータが外に出ることになります。この観点だと、UI-TARS モデルをローカル GPU 上で動かす構成、あるいは Hermes Agent と vLLM / LM Studio / Ollama 経由のローカルビジョンモデルを組み合わせる構成が、外部送信を最小化する現実解になります。

API 経由で使う場合の費用も、モデル料金だけで比較すると足りません。モデル推論、画面画像、操作結果、再試行、そして専用 VM を使う場合はその実行費用まで積み上げて考える必要があります。OpenAI 側は実行環境をユーザーが用意する方式を明示しており、Anthropic 側は画像・ツール結果を含むトークン課金の内訳を公式ドキュメントで説明しています。

cua には、ローカルの cua-driver とは別に、sandbox・fleet・VM 関連の仕組みもあります。これらを使ってクラウド上の Windows・Linux を操作する場合、それは手元の macOS / Windows のアプリを操作することとは別の構成であり、要件と費用の両方を分けて評価する必要があります。

選定指針

以上を踏まえた選定指針は、大きく 3 つのステージに分けて考えると迷いにくいです。

まず、両 OS で最短に「まずエンドユーザーとして試す」段階なら、ChatGPT デスクトップアプリの Computer Use プラグインか、Claude デスクトップアプリの Cowork > Computer use を触るのが最短距離です。既に ChatGPT・Claude の有料プランがあれば、追加コストは実質的に発生しません。Windows で Claude Cowork を使う場合はエディション条件と仮想化基盤の要件が別途あるので、そこは事前確認が要ります。

次に、「自社プロダクトに組み込む」段階なら、モデルを固定せず柔軟に組みたい場合は cua-driver を共通操作層に据え、その上にオーケストレーション層として Hermes Agent を載せる構成が有力です。ブラウザ業務に閉じるなら Browser Use や Skyvern のような専用ツールを別途評価するのが素直で、OS 全体エージェントを持ち込む必要はありません。

最後に、「機密データを外に出さない」段階まで踏み込むなら、UI-TARS Desktop をローカル LLM で動かす構成、あるいは Hermes Agent とローカルビジョンモデル（vLLM / LM Studio / Ollama）を組み合わせる構成が第一候補です。ここはモデルサイズ・GPU 要件・推論レイテンシの実測が本命の意思決定材料になります。

そして、どの構成を採るにしても、両 OS で共通の 3 タスクを最初に用意して測ることをおすすめします。

日本語の短い文章を入力してファイル保存し、再度開いて内容を照合する
ネイティブアプリの設定を 1 つ変更し、変更後の状態を確認する
2 つのアプリを跨いで短い情報を転記し、転記結果を照合する

各タスクを複数回実行して、成功率・所要時間・モデル費用・手動介入回数・カーソルとフォーカスへの干渉度合いを記録する、という原始的なやり方が結局は一番役に立ちました。ベンダーのベンチマーク順位（OSWorld のスコアなど）は参考にはなりますが、日本語 UI での実運用可否を保証するものではないので、採用判断の主軸には置かない方が安全です。

調査上の留保

この記事の内容は 2026-09-03 時点の公式ドキュメント・公式 GitHub・公開リリースを軸にまとめたもので、両 OS の実機で全候補を横並びに動かした比較ではありません。デイリースタンドアップやチームミーティングでの議論の起点にする前提のメモとして、以下は明示的に留保しておきます。

ドキュメントの main 版は公開パッケージより先行する場合があり、導入時には利用バージョンを固定し、対応するリリース情報も改めて確認する必要がある
OSWorld などのベンチマークスコアはバージョン差（original / Verified / 2.0）とステップ数差があり、大半がベンダー自己申告であるため、単純な順位比較には利用していない
Gemini デスクトップアプリ内の Computer Use（クローズドベータ）、macOS 版 Copilot のエージェント機能、Apple の次世代 Siri は、いずれもプレビュー・テスト・未提供の段階で、一般提供時期と詳細は本記事の範囲では確認できていない
日本語 UI・IME・全角文字・表示倍率については、今回の調査範囲では横並び比較ができておらず、国内業務アプリで採用する場合は必ず実機で確認する必要がある

以上、macOS と Windows の両方でネイティブアプリまで操作できる Computer Use エージェントを Hermes Agent と cua-driver を軸に整理した、現場からお送りしました。

サイト内検索