Terminator レビュー: Windows デスクトップを操作する MCP エージェントの実像
playwright for windows computer use
ひと目でわかる
- これは何？
- mediar-ai/terminator は Windows 専用の computer use 基盤で、MCP 経由で Claude や Cursor にデスクトップ操作を渡す。決定論的ワークフローと AI リカバリの分離という設計を、README とリポジトリ構成から読み解く。
- 誰に向いている？
- Windows 上で既存のブラウザセッションやデスクトップアプリをそのまま使いたいチーム、とくに録画した操作を決定論的なコードに落として繰り返し実行したい場合は検討に値する。macOS や Linux が対象環境に含まれるなら、このプロジェクトは選べない。
- 商用利用できる？
- できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 106 日前です。
- 何の言語で書かれている？
- 主に Rust です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
Terminator が埋めるのは「ブラウザの外」という空白
多くの computer use ツールはブラウザタブの中だけで完結する。Terminator が対象にするのはその外側で、GCP のインスタンス作成、Vercel のログ確認、CLI の操作といった、ブラウザとネイティブアプリをまたぐ作業が README のユースケースとして挙がっている。狙っている読者は二種類いる。ひとつは Windows のデスクトップアプリを自動化したい開発者で、もうひとつは業務プロセスを録画して非エンジニアでも回せる形にしたいチームである。後者向けに mediar.ai のワークフロービルダーとマネージドホスティングが用意されていると README は説明している。
ここで押さえておきたいのは、Terminator 単体が完結した製品ではなく、Rust のコアライブラリ、MCP エージェント、ワークフローレコーダー、Python と TypeScript の SDK が重なった構成だという点だ。crates.io には terminator-rs と terminator-workflow-recorder の2つが公開されており、README のバッジもこの2つを指している。どの層を自分で使うのかによって、導入の手順も運用の負担も変わる。
決定論的コードと AI リカバリを分けるという設計判断
README が繰り返し述べる中心的な主張は、ワークフローをあらかじめ決定論的なコードとして学習させ、AI を呼ぶのはリカバリが必要なときだけに絞る、という点である。これによって ChatGPT Agents や BrowserUse といった毎回モデルに判断させる方式より高速だとうたっている。README には「deterministic, CPU speed, with AI recovery」という表現があり、速度の根拠をモデル推論の回避に置いていることが読み取れる。
ただし、この説明だけでは具体的なアーキテクチャまでは見えない。README には「100x faster」「>95% success rate」という数値が書かれているが、条件、測定環境、比較対象のバージョンは示されていない。ベンチマークとして受け取るのではなく、プロジェクト側の主張として扱うのが妥当だ。確認できるのは、要素の特定に pixels、DOM、Accessibility tree の三つを併用するという方針で、これは単一の手段に頼らないという設計上の選択を示している。
MCP 経由で動かす: 実際の設定
Claude Code を使っている場合、README が示すのは次の一行だ。
claude mcp add terminator "npx -y terminator-mcp-agent@latest"
Cursor や VS Code、Windsurf などでは MCP の設定ファイルに JSON を書く。README の例では mcpServers の下に terminator-mcp-agent を置き、command に npx、args に -y と terminator-mcp-agent@latest を指定し、env で LOG_LEVEL を info、RUST_BACKTRACE を 1 に設定している。RUST_BACKTRACE が設定例に含まれているのは、Rust 実装のクラッシュ時にスタックトレースを出させるためだろう。
VS Code と Cursor 向けにはインストール用のバッジリンクも用意されている。ただし README の記述からは、MCP サーバーを起動したあとに Windows 側で何が常駐するのか、権限はどう扱われるのかまでは分からない。詳細は terminator-mcp-agent の README を参照するよう誘導されているので、実運用の前にそちらを読む必要がある。
Windows 専用という制約は曖昧ではなく明示されている
機能対応表は容赦がない。Core Automation の Element Locators、UI Actions、Application Management、Window Management、Advanced Features の Browser Automation、Workflow Recording、Monitor Management、Screen & Element Capture、いずれも Windows が Yes で macOS と Linux は No である。README の冒頭にも「Terminator currently supports Windows only. macOS and Linux are not supported.」と明記されている。
ライブラリの対応状況はもう少し複雑だ。TypeScript の @mediar-ai/terminator は Windows で Yes、Python の terminator.py は Partial とされている。pip install terminator というコマンドは示されているが、Partial が何を指すのかは README からは判断できない。Python から主要な操作を呼べるが一部の機能が欠けるのか、それとも別の意味なのかは、実際にパッケージの中身を確認しないと分からない。
macOS については「Use on macOS」というボタンが mediar.ai を指している。つまり macOS はこのリポジトリの機能としてではなく、ホスト型サービスの側で提供されるという整理になっている。セルフホストで完結させたい場合、macOS は選択肢に入らない。
カーソルを奪わないという主張と、その代償
README の「Why Terminator MCP?」には三つの利点が並ぶ。既存のブラウザセッションを使うので再ログインが不要で cookie と認証が保たれること、カーソルやキーボードを占有せずバックグラウンドで動くこと、pixels と DOM と Accessibility tree を組み合わせること。
一つ目と三つ目は理解しやすい。問題は二つ目だ。バックグラウンドでカーソルを奪わずに操作するということは、ユーザーの入力と自動化の入力が同じデスクトップ上で競合しうるということでもある。README はこの競合がどう調停されるのかを説明していない。人間が同じアプリを触っている最中の挙動は、導入前に自分で確かめるべき領域である。
もう一点、ブラウザ自動化は Chrome 拡張によって有効になると書かれている。つまりブラウザ側の操作には拡張のインストールが前提となり、拡張が動かない環境では DOM 経由の利点を活かせない。
Browser Use との違いは「毎回考えるか、一度決めてから考えるか」
比較対象として README 自身が挙げているのは BrowserUse と BrowserBase、そして ChatGPT Agents や Perplexity Comet である。違いはアプローチにある。BrowserUse 系は各ステップでモデルに次の行動を判断させる。Terminator はワークフローを決定論的なコードとして先に固定し、失敗した箇所だけ AI に判断させる。
この差は、安定した手順を何度も回す用途では効率に直結する。逆に、毎回まったく異なる画面を相手にする探索的なタスクでは、先に固定できるワークフローが存在しないため、この設計の利点は出にくい。README のユースケースが「GCP でインスタンスを作る」「Vercel のログを見る」「最近のコミットに基づいて新機能をテストする」と、いずれも手順が反復可能なものである点は、設計と整合している。
ただし BrowserUse がブラウザ内に閉じているのに対し、Terminator はデスクトップ全体を対象にする。守備範囲が違うので、単純な優劣の比較にはならない。ブラウザだけで足りるなら、Windows 依存を持ち込む理由は薄い。
維持コストとライセンス
ライセンスは MIT で、README も「fork it, ship it, no lock-in」と書いている。コアの Rust クレートを自分のプロダクトに組み込むことも、フォークして独自に保守することも、MIT の条件の範囲で可能である。ただし MCP エージェントは npx で @latest を取得する形が例示されている。この指定は毎回最新版を引くという意味であり、再現性を重視するならバージョンを固定する必要がある。
更新の頻度は低くない。直近のリリースは v0.24.30 が 2026-03-17、v0.24.31 が 2026-04-02、v0.24.32 が 2026-04-05 で、約3週間の間に3回出ている。パッチ番号が小刻みに上がる運用なので、@latest のまま使うと検証していない差分を日常的に取り込むことになる。crates.io の terminator-rs と terminator-workflow-recorder についても、利用するバージョンを固定してから導入するほうが安全だ。
ライセンスの解釈や、マネージドホスティング利用時の契約条件については、ここでは判断しない。必要ならリポジトリの LICENSE と mediar.ai 側の規約を直接確認してほしい。
編集部の結論
Windows 上で既存のブラウザセッションやデスクトップアプリをそのまま使いたいチーム、とくに録画した操作を決定論的なコードに落として繰り返し実行したい場合は検討に値する。macOS や Linux が対象環境に含まれるなら、このプロジェクトは選べない。導入前に確認すべきは、crates.io の terminator-rs と terminator-workflow-recorder のバージョンが v0.24.32 系と揃っているか、そして MCP クライアント側の設定ファイルに書く npx の引数が自分の環境で解決できるかである。
コミュニティノート