UI-TARS-desktop と GUI エージェントの二つの分岐 — ByteDance が開いた OS レイヤーの亀裂
UI-TARS-desktop と GUI エージェントの二つの分岐 — ByteDance が開いた OS レイヤーの亀裂
GUI エージェントは API エージェントの補助カテゴリなのか、それとも結局 OS レイヤーそのものを書き換える別カテゴリなのか。そしてそのカテゴリがクローズドな SaaS ではなくデスクトップ・オープンソースとして先に定着するなら、いま評価すべきリスクは何か。
導入 — 33,599 個の星が意味するもの
2026年5月最初の週の GitHub トレンディング・ウィークリーの最上段を、ByteDance の UI-TARS-desktop リポジトリが占めた。2025年1月19日に公開されたこのリポジトリは、5月3日時点で 33,599 個のスターと 3,334 個のフォークを記録している。1年4か月での到達点である。同じ期間に GitHub に登場した数万件の AI エージェント・プロジェクトの中で、これほどの吸引力を見せたものは LangChain、AutoGPT、Claude Code 程度しかない。単なるデモ・プロジェクトではないという信号である。
リポジトリの一行説明は意図的に広い。「オープンソースのマルチモーダル AI エージェント・スタック — 最先端の AI モデルとエージェント・インフラを繋ぐ(The Open-Source Multimodal AI Agent Stack: Connecting Cutting-Edge AI Models and Agent Infra)」。しかし実際の提供物は二つに集約される。一つはビジョン・言語モデルの UI-TARS(現在 1.5-7B と非公開のフルサイズ)、もう一つはこのモデルをデスクトップ上で直接マウス・キーボード制御へ変換する Electron ベースのランタイム UI-TARS-desktop である。モデルは Apache 2.0 ライセンスで Hugging Face に公開され、ランタイムも同じライセンスのオープンソースだ。
この組み合わせが生み出すカテゴリは、これまでクローズドな SaaS としてしか存在していなかった。OpenAI Operator は2025年初頭の公開以来 ChatGPT Pro 加入者にのみ開かれており、Anthropic の Computer Use API は Claude モデルをクラウドからしか呼び出せなかった。両社ともモデルの重みを公開せず、ユーザーの画面キャプチャは自社インフラを経由して処理された。UI-TARS-desktop はこれらの前提をすべて反転させる。モデルをローカル GPU に立ち上げられ、画面キャプチャはユーザーのマシン内だけを流れ、どのアクションが実行されるかをコードレベルで監査できる。
問題はここから始まる。GUI エージェントがクラウド SaaS の安全なサンドボックスを離れ、ユーザーの OS に直接手を入れ始めると、過去18か月「エージェントの安全」と呼んで扱ってきたシナリオすべてが別の位相へ移る。プロンプト・インジェクションはもはやチャット欄の事故ではなく OS 権限の事故になり、誤ったクリックはもはや返金可能な取引ではなく回復不能なファイル削除になる。ByteDance が開いたこの亀裂は、したがって単なるオープンソース・マーケティングの成功ではなく、産業カテゴリの分岐点である。
本文 1 — UI-TARS-desktop の解剖:モデル、ランタイム、ベンチマーク
まず何が入っているかを整理する。リポジトリの README と Hugging Face のモデルカードを突き合わせると、UI-TARS-desktop は三つの層で構成される。
最下層は モデル だ。UI-TARS-1.5-7B は70億パラメータのビジョン・言語モデルで、2025年4月17日の v0.1.0 リリースとともに公開された。ベースは ByteDance 内部の Seed-VL シリーズであり、その上に GUI スクリーンショットの大規模データセットと強化学習が積まれている。論文「UI-TARS: Pioneering Automated GUI Interaction with Native Agents」(arXiv:2501.12326、Yujia Qin ほか34名)で著者らはこのモデルを「フレームワークではなくネイティブ・エージェント(native agent)」と呼ぶ。すなわち、GPT-4o を外部から呼び出しつつプロンプトとツール定義で GUI 作業をさせる従来方式ではなく、モデル自体がスクリーンショットを入力として受け取り、アクション・トークンを出力するように最初から学習されているという意味である。System 2 型の推論、タスク分解、マイルストーン認識、リフレクション思考が学習データに含まれていると明記されている。
ベンチマーク数値はカテゴリそのものの重心を揺るがす。OSWorld 100 ステップ基準で UI-TARS-1.5-7B は 42.5 点、OpenAI CUA は 36.4 点、Claude 3.7 は 28 点だった。ScreenSpot-V2 では 94.2 点で OpenAI 87.9、Claude 87.6 を上回った。グラウンディング難度が最も高い ScreenSpotPro では差はさらに劇的だ。UI-TARS 61.6 点に対し OpenAI 23.4 点、Claude 27.7 点である。Android 環境の AndroidWorld でも 64.2 点で従来最高 59.5 点を更新した。7B パラメータのオープンソース・モデルがクラウドのクローズド・モデル二社をまとめて押し退けた最初の事例である。
数値だけ見れば疑念も湧く。ベンチマークは取れるが実用では崩れるモデルはありふれている。しかし v0.3.0 リリースノート(2025年11月5日)とその後のベータ変更履歴を辿ると、このプロジェクトは単なるモデル・デモではなく運用のためのシステムだという点が明確になる。ストリーミング・ツール呼び出し、ランタイム・タイミング統計、Event Stream Viewer、AIO エージェント・サンドボックス対応、リモート・コンピュータ/ブラウザ・オペレーターまで — 項目自体が「デモ動画用の視覚効果」ではなく「本番でデバッグするために必要な機能」である。メインテナーの ulivz が単独で 677 コミットを記録し、上位5名のコミット合算は 1,000 件を超える。一人のサイドプロジェクトではなく、ByteDance 内部の正式チームが運用している。
二層目は ランタイム(UI-TARS-desktop 本体) である。Node.js 22 以上を要求し、Electron でパッケージングされ、npm/npx でグローバルにインストールする。中核の動作は単純だ。ユーザーが自然言語で作業を指示すると、ランタイムが画面キャプチャ → モデル推論 → 座標・キー・アクションの実行 → 次のキャプチャというループを回す。モデルはローカルに立ち上げてもよいし、ByteDance Volcengine、Anthropic、ユーザー独自のエンドポイントなど外部 API へも接続できる。すなわち、モデル提供者への依存を抽象化したマルチバックエンド構造である。この点が OpenAI Operator や Claude Computer Use API と決定的に異なる。後者はモデルとランタイムが分離不能な状態で束ねられている。
三層目は Agent TARS と呼ばれる上位フレームワークだ。CLI と Web UI の二つの入口を提供し、MCP(Model Context Protocol)サーバー連携を標準で備える。デモとして提示されたシナリオは、航空券比較予約、ホテル検索、VS Code 設定の自動化、GitHub Issue 追跡、チャート生成といった現実的なワークフローである。すなわち、一つのモダリティに縛られず、GUI・DOM・MCP をハイブリッドに混ぜられるブラウザ・エージェントとして設計されている。
この三層の組み合わせが意味するところは明白だ。ByteDance はモデルの重み、ランタイムのコード、上位フレームワークを一つのリポジトリで同時に公開した。どれか一層だけ取り出して他社のインフラに差し込むことが可能であり、逆に三層をそのまま受け取って自社のデスクトップ・エージェントとしてリリースすることもできる。クローズドな SaaS 陣営が一度も許してこなかったモジュラリティが、初めて産業に登場したのである。
本文 2 — 二陣営のトレードオフ:クローズド SaaS と オープン・デスクトップ
GUI エージェントは今や明確に二陣営へ分かれる。一方は OpenAI Operator と Anthropic Computer Use API に代表される クローズド SaaS 陣営、もう一方は UI-TARS-desktop とその派生(Open Interpreter、Self-Operating Computer など)が形成する オープン・デスクトップ陣営 だ。両者のトレードオフは単なる技術的選好の問題ではなく、責任とコストの分配の問題である。
クローズド SaaS の最大の強みは隔離だ。Anthropic の Computer Use API では、Claude はユーザーの実マシンに触れない。クラウドの Docker コンテナ内で仮想デスクトップを動かし、その画面をキャプチャしてモデルへ入力し、アクションはそのコンテナ内だけで実行される。OpenAI Operator も同様に自社クラウド・ブラウザを動かす。ユーザーのローカル環境は安全だ。誤ったクリックがユーザーのパスワード・マネージャーに触れることはなく、プロンプト・インジェクションが成立してもユーザーの git リポジトリを壊すことはできない。責任は SaaS 提供者が負う。SOC 2 報告書、データ処理約款、安全性評価 — そのすべてが契約という形で提供者に帰属する。
代価は明確だ。第一に、コスト。Anthropic の Computer Use は入力トークンあたりの標準 Claude 価格に画面キャプチャ処理コストが上乗せされる。平均的なタスク一件が数十回のスクリーンショット・推論ループを回るため、一作業で簡単に1ドルを超える。第二に、応答時間。クラウド往復+モデル推論+仮想デスクトップ・レンダリングが積み重なり、1アクションあたり5秒以上が普通だ。第三に、閉鎖性。ユーザーがどんなワークフローを持っているかがすべてクラウドに露出し、それが SaaS 提供者の学習データに使われるか否かは約款に依存する。第四に、限定された環境。ユーザーの実デスクトップ・ブラウザ拡張・ログイン・セッション・ローカル・ファイルにアクセスできないため、隔離された仮想デスクトップで実演可能なこと以外にはほとんど使い道がない。
オープン・デスクトップ陣営はこの四つの問題を正確に裏返す。UI-TARS-desktop をローカル GPU と組み合わせて運用すれば、トークン・コストは 0 に収束する。応答時間は画面キャプチャと推論を経由するがネットワーク往復が消えるため、1〜2秒水準まで下がる。ユーザーのワークフローはユーザーのマシンを離れない。そして決定的なのは、ユーザーの実ブラウザ・セッション、実ファイルシステム、実 IDE に直接手を入れられる点だ。デモ動画で UI-TARS が VS Code の settings.json を直接編集し、GitHub Issue を検索して返信できる理由はここにある。
このカテゴリのリスクを最も的確に表現しているのは GitHub トレンディングのコメントではなく、同じカテゴリにある別プロジェクトのメインテナーたちだ。Open Interpreter の Killian Lucas は早くから「あなたは LLM にシェルを与えているのではない、自分のシェルを自分が制御できない外部テキストの関数に変えているのだ(You are not giving the LLM a shell — you are making your shell a function of external text you do not control)」と書いた。UI-TARS-desktop の場合、この診断はさらに強く当てはまる。シェルではなくマウス・キーボードそのものだからだ。ユーザーが画面に表示している任意のテキスト(メール本文、Slack メッセージ、Web ページ広告、PDF 本文)がモデルの入力に流れ込み、その入力が次のアクション決定の根拠になる。すなわち、画面に映るあらゆる外部テキストが潜在的なインジェクション・ベクトルである。
ByteDance がこのリスクを知らないわけではない。README のセキュリティ勧告は短いが明確だ。「別のユーザー・アカウントまたは仮想マシン内での実行を強く推奨する(Strongly recommend running in a separate user account or VM)」。しかしこの勧告が実際に守られる比率は低いだろう。v0.1.0 のデモ動画はすべてユーザーのメイン・デスクトップで直接実演されており、Twitter/X のデモも同様だった。勧告と実使用の間のこの乖離が、クローズド SaaS 陣営が「だから我々はクラウドに閉じ込める」と語る根拠になっている。
ここで GitHub Actions のセキュリティ請求書が思い出される。先週の nesbitt.io の分析は、PyPI パッケージの 91% が可変タグで外部アクションを参照していると指摘し、その理由は GitHub Actions のデフォルト挙動が危険だからだと診断した。UI-TARS-desktop も同じ罠へ向かっている。デフォルト・インストールは権限分離を強制せず、仮想マシンによる隔離も強制せず、アクション・ホワイトリストもない。「推奨する(recommend)」という文は GitHub の permissions: {} 勧告と同じ運命を辿る可能性が高い。すなわち、ほとんど誰も従わない。
しかしこのリスクを理由にカテゴリそのものを否定することはできない。クローズド SaaS の隔離は、その隔離が生み出す無力さを抱えてもおり、ユーザーが本当に望むのは自分の IDE とブラウザを直接助けてくれるエージェントだ。ByteDance が 33,000 個のスターを集めた理由はマーケティングではなく、開発者がそれを望んだからである。
本文 3 — OS レイヤーの衝突:Recall、AppleScript、そしてエージェント・ランタイム
GUI エージェントがデスクトップへ降りてくると、すぐに別の OS 統合の試みと衝突する。最も直接的な衝突は Microsoft の Windows Recall だ。2024年に最初に発表されたあとセキュリティ懸念で延期され、2025年末に ARM・x86 の一部端末でオプトインとして再公開されたこの機能は、OS がユーザーの全画面を周期的にキャプチャしてインデクシングし、自然言語クエリで過去の作業を検索できるようにする。UI-TARS-desktop は同じマシン上でほぼ同一の前提を使う。画面キャプチャが動作の起点であるという前提だ。違いは、Recall が検索用インデックスを作って止まるのに対し、UI-TARS はキャプチャを見たうえでマウス・キーボードを動かす点である。
この二つが同じマシンで同時に動く未来を描くのは難しくない。Recall が作った過去画面のインデックスを UI-TARS がコンテキストとして受け取り、「先週火曜日に見たあの PR をもう一度開いてくれ」という命令を実行するシナリオだ。OS ベンダーから見れば二機能を分ける理由はない。しかしユーザーから見れば、画面キャプチャとアクション実行が同じ OS コンポーネントに統合された瞬間、「エージェントの誤り」と「OS の欠陥」の区別が消える。
macOS は別の経路を歩む。AppleScript と Accessibility API は25年近く OS 自動化の標準だったが、いずれも静的スクリプトと明示的な権限付与を前提とする。UI-TARS はこの両方を迂回する。Accessibility API の権限ダイアログを一度通過すれば、以降のすべての動作はモデルの推論に委ねられる。Apple は2025年6月の WWDC で「On-Device Foundation Model」を公開し Apple Intelligence を OS 次元に引き上げたが、そのモデルは外部アクションを直接実行しない。すなわち Apple は GUI エージェントの OS 統合を意図的に遅らせている。その空白を ByteDance のような外部プロジェクトが埋めている構図だ。
Linux デスクトップ側は最も自由で最も危険である。Wayland も X11 も画面キャプチャと仮想入力を遮断するというよりは許容する方向で設計されており、ユーザーが一度権限を与えれば終わりだ。UI-TARS-desktop の Linux ビルドが最も速く伸びている理由である。
この三 OS の絵を重ねると、GUI エージェントが事実上の新しい OS レイヤーになっているという結論が浮かぶ。OS 上で動くアプリケーションではなく、ユーザーと OS の間に割り込む中間レイヤーだ。この位置はかつてシェル、ウィンドウ・マネージャー、デスクトップ環境が占めていた場所である。そしてシェルがそうであったように、この位置を誰が占めるかが今後10年のユーザー体験を決定する。ByteDance がオープンソースで先に陣取ったということは、Microsoft・Apple・Google が自社 OS で同じ位置を別の方式で供給する前に、ユーザーがすでに ByteDance の抽象化に慣らされる可能性を作ったということだ。
実務者がいま評価すべき点は五つに集約される。第一に、隔離方針。UI-TARS-desktop をローカル・マシンに直接インストールするのか、別アカウントで実行するのか、仮想マシンやコンテナの中に閉じ込めるのか、まず決める必要がある。仮想マシンを推奨する。第二に、モデル・バックエンド選択。ローカル GPU に 7B モデルを載せるか、ByteDance Volcengine のフルサイズ・モデルを呼ぶか、Anthropic・OpenAI のモデルを同じランタイムで呼ぶか。それぞれコスト・遅延・データ・ガバナンスが異なる。第三に、アクション・ホワイトリスト。どのアプリケーション・ディレクトリ・URL に対するアクションのみ許可するかを明示的に定義する必要がある。README はこの機能を提供しない。自前で実装するか、外部サンドボックスに依存するしかない。第四に、監査ログ。v0.3.0 の Event Stream Viewer はこの領域の出発点だが、事故後の解析が可能な形式で保存されるかは別途確認が要る。第五に、ロールバック戦略。誤ったアクションが実行されたとき、何をどう戻すかのシナリオ。ファイルシステムのスナップショット、git stash、データベース・トランザクション — どれであれ、エージェントのアクション開始前に定義されていなければならない。
結論
冒頭の問いに戻ろう。GUI エージェントは API エージェントの補助カテゴリなのか、別カテゴリなのか。UI-TARS-desktop の 33,599 スターと OSWorld 42.5 点が答える。別カテゴリである。API エージェント(Claude Code、Cursor、Codex)はテキストとツール呼び出しという狭いインタフェースの中では強力だが、画面が本質となる作業 — デザイン、レガシー GUI アプリケーションの操作、非標準 Web インタフェース — では無力だ。GUI エージェントはこの空白を埋め、その埋め方は OS レイヤーそのものに沈み込む形で進む。
そしてそのカテゴリがクローズド SaaS ではなくデスクトップ・オープンソースとして先に定着するという点こそ、今回の ByteDance 事件の核心である。OpenAI と Anthropic が立てた安全性ガードレールはクラウドという隔離の上に成り立っていた。その隔離を離れた陣営が業界標準になれば、ガードレールはユーザー個人が自分でインストールし検証する必要が出る。GitHub Actions の 91% 未適用統計が教えてくれたのは、「推奨する」という文が実際の安全を作らないという事実だ。UI-TARS-desktop の仮想マシン勧告も同じ運命を辿る可能性が極めて高い。
いま評価すべきリスクは、したがって二層に分かれる。短期的には、隔離なしでメイン・デスクトップにインストールされた GUI エージェントがプロンプト・インジェクション・誤った推論・悪意ある画面コンテンツによって引き起こす事故。中期的には、OS ベンダー(Microsoft Recall、Apple Intelligence、Google の Gemini Nano)と外部エージェント・ランタイム(UI-TARS、Open Interpreter、Self-Operating Computer)の間の OS レイヤー争奪戦、そしてその過程でユーザーが背負わされるセキュリティ責任の再分配。この二層を同時に見なければ、我々は再び「デフォルトが危険な」インフラを18年分の請求書として受け取ることになる。ByteDance が開いた亀裂は、その請求書が届く前に隔離方針とアクション・ホワイトリストを自ら設計する時間を、しばし稼いでくれたに過ぎない。その時間がどれほど長いかは、次四半期の OpenAI Operator の価格表と Apple WWDC の自動化発表が決めることになる。