UI-TARSを使いこなせませんでした。すみません。
UI-TARSを使いこなせませんでした。すみません。
出典: note.com / 2026-05-22
見えている。でも、押せない
UI-TARSでMacを自律操作させる実験をした。結論から書くと、期待していた「一発でSNS投稿まで完走するGUIエージェント」には届かなかった。
これはUI-TARSが駄目だった、という話ではない。むしろ画面を読む能力はかなり高い。問題は、画面を読むことと、実際に正確な操作を完遂することの間に、想像以上に深い谷があったことだ。
UI-TARS 7Bは画面の意味をかなり読める。どこにボタンがあり、何の画面で、次に何をすべきかを推測する力はある。Discordの画面、Xの投稿画面、noteの編集画面。人間が見れば「ああ、ここを押すのね」とわかる場面で、UI-TARSもだいたい同じ理解を返してくる。
しかし問題は、その次だった。
ボタンを押す段階になると、座標がズレる。ほんの少しならまだいい。だが実運用では、数十pxから百px単位のズレが致命傷になる。投稿ボタンの横を押す。入力欄の少し下を押す。何も起きない。するとモデルは「押せていない」と判断して、もう一度押す。
このループが始まると、Macからクリック音が連続で鳴る。ガガガッと、壊れたのかと思うような音がする。あれは人間の操作ではない。VLMが「変化しない、再試行する」を繰り返している音だ。
画面は読めている。だが、手元が危ない。
UI-TARS単独運用の限界
今回の実験では、X投稿をUI-TARS Desktopに任せようとした。note記事はAPIで投稿できた。アイキャッチもアップロードし、記事も公開できた。そこまでは安定していた。
問題はXだった。x-post.shはBUTTON_DISABLEDで失敗。次にUI-TARS Desktopに任せた。さらにChromeを前面に出し、Xの投稿画面を開き、テキストも入力済みにした。それでも最後のPostボタン確定が安定しなかった。
ここで見えたのは、UI-TARSが「人間のように画面を見て操作する」ことの危うさだ。
人間はボタンが押せなければ、理由を一瞬で切り分ける。カーソルがズレているのか、ボタンが無効なのか、入力欄に文字が入っていないのか、モーダルが被っているのか。UI-TARSはそこを曖昧にしたまま、同じ種類のクリックを繰り返す。
つまり、UI-TARSは作業者としてはまだ怖い。
本当に使えたもの
一方で、別の経路はうまくいった。
note投稿はAPIで成功した。最初は画像アップロードAPIのエンドポイントを間違えたが、正しい手順に戻したら通った。先にスケルトン記事を作り、note_idを取得し、アイキャッチをアップロードし、最後にeyecatch URLを含めて公開する。これは安定していた。
Discordの新規サーバー作成も、AXハイブリッドでは成功した。UI-TARSの座標クリックではなく、cua-driverでAX treeを読み、element_indexで「サーバーを追加」「オリジナルの作成」「自分と友達のため」「新規作成」を押した。これはかなり正確だった。
Developer Portalでも、Application作成からBot設定ページ到達まで進めた。hCaptchaのチェックボックスもAXで押せた。
ここで見えたのは、UI-TARSよりもAXの強さだった。
macOSのAccessibility treeは、画面上のボタンを「座標」ではなく「意味のある要素」として扱える。ボタン名、入力欄、チェックボックス、リンク。それらをelement_indexで指定すれば、少なくとも座標ズレの問題は消える。
UI-TARSは主役ではなく偵察兵
今回の判断はこうだ。
UI-TARSは使える。ただし主役ではない。
UI-TARSは画面の意味理解、つまり偵察に使うべきだ。いま何の画面か。どのボタンを押すべきか。次のステップは何か。そこを読む役としては価値がある。
しかし実行は別の手段に任せた方がいい。Macアプリならcua-driverのAX操作。WebならAPI、CDP、Playwright。Xなら本来はxurlや公式API。どうしてもGUIしかない場合だけ、最後の補助としてUI-TARSを使う。
「VLMが画面を見て、そのままクリックして完走する」という夢は、まだ安定運用には遠い。少なくとも僕の環境では、UI-TARS単独を投稿基盤にする判断はできない。
Codex computer useの方がマシか
正直に言えば、たぶんCodex computer useの方が運用には向いている。
理由は、Codexの方が道具の切り替えに強いからだ。座標クリックが駄目ならAXを使う。AXが駄目ならAPIを探す。APIが駄目ならCDPを使う。そういう失敗時の分岐ができる。
UI-TARSは、画面操作に特化した作業者に近い。画面は見る。クリックもする。だが、失敗時に「そもそも別の手段に切り替えよう」という判断が弱い。
この差は大きい。
GUI自動化で本当に必要なのは、クリック能力ではない。失敗したときに、なぜ失敗したかを切り分け、別ルートへ逃げる能力だ。
反省と設計の変更
今回の反省は、UI-TARSに期待しすぎたことだ。
画面を読めるなら操作もできるはずだ、と思った。だが実際には、画面理解と操作完了の間には、AX、DOM、API、イベント、フォーカス、モーダル、認証、ボタン状態という細かい地雷がある。
VLMはそれらを一枚のスクリーンショットから推測する。人間なら一瞬で違和感に気づくが、モデルはクリック音を連発するまで止まらないことがある。
だから設計を変える。
UI-TARSは目。AXは手。APIは高速道路。Codexやpi-agentは管制官。
この分業が現実的だ。
これからの方針
noteはAPIで投稿する。アイキャッチは必ず先にアップロードし、公開時にeyecatchフィールドへ明示的に入れる。
Xはxurl認証を通す。ブラウザ投稿にこだわるならPlaywrightかCDPで制御する。BUTTON_DISABLEDのようなReact由来の問題は、座標クリックではなくDOMイベントか公式APIで解決する。
DiscordやMacアプリ操作はcua-driverのAX treeを本命にする。UI-TARSは画面の意味理解だけに使う。
今回、UI-TARSを使いこなせなかった。そこは認める。
ただし失敗では終わらない。UI-TARSを万能の手として扱う設計を捨て、偵察兵として配置し直す。その判断ができたことが、今回の収穫だった。
UI-TARSは魔法の手ではなかった。
でも、目としては使える。
そしてGUI自動化に必要なのは、目だけではない。手と、逃げ道と、失敗したときに立ち止まる判断だ。
この記事は note.com から KTBLOG に移行されました。元記事: https://note.com/famous_prawn2009/n/n162ad33ed1ea