Windowsアプリのテスト自動化ツール「Terminator（mediar-ai）」とは？

投稿日：

Rust言語で開発したWindowsアプリ（WinRemap）のGUIテストを自動化したくて調査したときの覚書。
Geminiでディープリサーチしてから、Claudeアプリで記事にしている。

環境： Windows 11 Pro 25H2

Webのテスト自動化にはPlaywrightという定番があるが、Windowsデスクトップアプリには決定打が乏しい。
 WinAppDriverは開発が停滞し、UI Automation（UIA）を生で叩くとCOMの作法に付き合うことになる。


Terminator（mediar-ai）とは？

Windowsデスクトップを対象としたオープンソースのGUI自動化基盤。
「Playwright for windows computer use」を掲げている。
参考： mediar-ai/terminator - GitHub

構成は主に2つ。

  • terminator-rs — Rust製のコアライブラリ。Python（terminator.py）とTypeScript（@mediar-ai/terminator）のバインディングもある
  • terminator-mcp-agent — MCPサーバー。Claude CodeやCursorから直接デスクトップを操作できる

対応プラットフォームは事実上Windows専用。

開発元はアメリカ・サンフランシスコのMediar.ai（Mediar Inc.）。


従来のComputer Useとの違い

AnthropicやOpenAIのComputer Useは、スクリーンショットをVLM（視覚言語モデル）に解釈させて座標をクリックするビジョン依存型。

  • 1ステップごとにVLM推論（Vision-Language Model：視覚言語モデル）が入るので遅い
  • 画像トークンを大量に消費するのでランニングコストが嵩む
  • 解像度やフォント描画の揺らぎで誤操作する（非決定論的）

TerminatorはOSのアクセシビリティツリー（Windows UI Automation）を直接読む。
スクリーンリーダーが使っているのと同じUIの「意味」が入ったツリー。

  • 座標ではなく role:Button, name:Save, window:WinRemap のような属性で要素を特定する
  • ウィンドウのサイズやDPIが変わっても壊れない
  • 画面全体のツリー走査が約80ms（公称値）
  • ロケータのチェイニングやリトライが用意されていて、Playwrightを触ったことがあれば違和感がない

設計思想は「決定論を主、AIを従」。

  • 定型処理は確定的なコードとして実行する
  • 応答遅延や画面構造の変化など、想定外が起きたときだけLLMを呼んでリカバリする
  • 従来のRPA（UiPath等）はUIが少し変わるだけで止まる。
    純粋なAIエージェントは遅くて高い。
    その中間を狙っている


操作対象アプリ側の条件

UIAベースなので、対象アプリがアクセシビリティツリーを公開していないと要素を掴めない。
ここが使えるかどうかの分かれ目になる。

  • WinUI 3 / WPF / Win32ネイティブ — 標準コントロールなら自動で対応する。最も相性がいい
  • egui / eframe — AccessKitが統合されており、そのWindowsアダプタがUI Automationを実装している。eframeではデフォルト有効。掴める
  • gpui（Zed） — GPUに直接描画する方式で、AccessKit対応は現在進行形。現状はツリーがほぼ出ない。掴めない


費用とライセンス

  • OSSコアはMITライセンスで無料 — terminator-rs、各言語バインディング、MCPサーバーすべて
  • ローカル実行なのでデータは外に出ない — OSS版を自前環境で回す限り、Mediar.aiに情報は送られない
  • マネージドホスティングとMediar IDEは商用製品 — こちらを使う場合はデータの扱いが別契約になる
  • LLM APIコストは別途かかる — ただしAI呼び出しをリカバリ時のみに限定すれば、ビジョン型と比べて大幅に安く済む


AIエージェントとの親和性

Terminatorの実質的な主役はMCPサーバーのほう。

  • MCPサーバーとして登録すれば、Claude CodeやCursorから自然言語でデスクトップを操作できる
  • 「アプリを起動して、設定タブを開いて、チェックボックスをオンにして保存し、メモ帳で動作を確認して」といった指示が通る
  • エージェントがアクセシビリティツリーを読んでセレクタを自分で試せるので、人間がインスペクタで探索するのと同じループを回せる
  • 探索して動く手順が固まったら、決定論的なワークフローやSDKコードに落とし込む

つまりAIは「テストを書く側」に使い、「テストを実行する側」は決定論的コードに任せる。
CIで毎晩回すことを考えると、この分業が現実的だと思う。


Terminatorのセキュリティ上の懸念

Terminatorが強力な理由は「AIエージェントにデスクトップ全体の操作権限を渡すこと」であり、リスクはその裏返しとして存在する。


1. プロンプトインジェクション

最大のリスク。
エージェントは画面上のUIテキストを読んで判断する。
ということは、画面に表示された文字列が実質的に指示として機能しうる。

  • 悪意あるWebページ、受信メールの本文、開いたドキュメント、処理対象のCSVの中身
  • そこに「これまでの指示を無視して〜」と書き込まれていた場合、エージェントが従う可能性がある

これはTerminator固有の欠陥ではなく、Computer Use系エージェント全般に共通する未解決問題。
ただしTerminatorはOS全体を操作できるぶん、成功したときの被害範囲がブラウザ内に閉じない。


2. ブラウザの既存セッションを継承する設計

「再ログイン処理を書かなくていい」という利便性として紹介される機能だが、セキュリティ観点では警戒すべき特性。

  • 専用Chrome拡張経由で、既存のCookieやSSO認証情報をそのまま利用する
  • エージェントが乗っ取られた場合、攻撃者は認証済みセッションを持った状態で動くことになる
  • 1のインジェクションと組み合わさると、情報の持ち出しまで一直線につながる


3. 権限の粒度がない

UIAには「このアプリだけ操作可」といった細かい制限をかける仕組みがない。
そのユーザーが操作できるものは、エージェントも操作できる。

なおUIPI（User Interface Privilege Isolation）により、非昇格プロセスから管理者権限のウィンドウは操作できない。
これは防御機構として機能するので、エージェントを管理者権限で起動するのは避けたい。
「動かないから管理者で実行」が最悪の解決策になる。


4. 画面録画機能と機微情報

ワークフロー録画は便利だが、録画中に画面に映っていたものはすべて取り込まれる。

  • 認証情報、個人情報、顧客データ
  • 顧客情報が映り込む可能性のある画面では使えない

録画対象の画面は事前に選別する必要がある。


5. サプライチェーンと名前の衝突

npx -y terminator-mcp-agent@latest という起動方法は手軽だが、実行のたびに最新版を取ってくることを意味する。
パッケージが侵害されれば、それがそのままデスクトップ操作権限を持って動く。
本番ではバージョンを固定すべき。

さらに厄介なのが名前の衝突。
エコシステム内に同名・類似名の無関係なプロジェクトが複数ある。

  • rkuklik/terminator — Rustのエラー整形ライブラリ
  • steipete/Terminator — macOSのターミナル制御MCP
  • Terminator-Qwen3-8B — LLMの推論終了制御フレームワーク

単に紛らわしいだけでなく、タイポスクワッティング（Typosquatting）の温床でもある。
crate名が terminator-rs、リポジトリが mediar-ai/terminator であることを毎回確認する。


実務上の落としどころ

最低限こう構える。

  • 専用のWindows VMで動かす。ホストの本番環境では動かさない
  • 標準ユーザー権限で実行する。管理者権限を与えない
  • そのVMのブラウザプロファイルに業務アカウントをログインさせない。顧客データを置かない
  • バージョンを固定し、更新時は差分を確認する
  • ワークフローYAMLはGit管理してレビュー対象にする
  • 不可逆な操作（削除・送信・購入）には人間の承認を挟む
  • AIの出番はエラーリカバリ時のみに限定し、通常時は決定論的コードで回す


テスト自動化という用途は、この点でかなり有利。
テスト対象は隔離環境の自作アプリであり、機微情報も本番認証も関与しない。
Terminatorを最も安全に使える用途のひとつだと思う。

逆に「業務PCで日常業務を丸ごと代行させる」という使い方は、現時点ではリスクに見合わない。


▼ 関連記事