Alibaba Token Hub(MAI-UIチーム)が公開したOpenGCUAは、「コンピュータを操作するAI」をつくるのに必要なものすべてをコミュニティに開くというプロジェクトの、最初のレポートだ。何が変わるのかから言えば、二つある。
一つ、エージェントに画面をクリックさせる代わりにコードを書いてコンピュータを操作させると、タスクのスコアが上がり、ステップ数が減る。二つ、これまでハーネス(エージェントを包み、実行を制御する骨組み)がルールで決めていた判断を、モデル自身に選ばせると効率がよくなる。
前提が一つある。今回のレポートには新しく学習したモデルは登場しない。既存のモデルをこの設計の上に載せて動かした結果であり、実験に乗せたモデルすべてで改善が現れた。モデルが賢くなったからではなく、働き方を変えたことで生まれた変化だ、という意味である。
コンピュータ操作エージェント(CUA、コンピュータを代わりに操作するAI)の研究は、長いあいだ一つの絵に縛られてきた。モデルにスクリーンショットを見せ、マウス・キーボードで画面を操作させる、というものだ。人がコンピュータを使う様子をそのまま真似る。これをGUI専用エージェントと呼ぶ。
このやり方は、画面を行き来する作業が繰り返されるほど遅くなる。たとえば、複数のExcelファイルに散らばった売上をまとめて、別の業務用アプリに入力する作業を考えてみよう。GUI専用エージェントは、ファイルを一つ開いて画面を撮り、値を目で読み、アプリにウィンドウを切り替えて入力し、次のファイルに戻って同じことを繰り返す。ファイルが増えるほど「見る―判断する―入力する」の往復がそのまま膨らみ、そのたびにモデルを呼び直さなければならない。同じ作業をコードでやれば、ファイルをまとめて読み込んで結合し、アプリに入れるスクリプト一片で済むことが多い。
そのため、最先端のシステムはGUI操作にシェルコマンド(ターミナルに入力するコンピュータへの命令)、アクセシビリティツリー(画面要素を座標ではなく、役割・名前・値の構造として読む通り道)、各種APIを混ぜ始めた。OpenAIもGPT-6 Astraを出すにあたり、コンピュータ操作のガイドを「GUI操作をコードとして書き、計算と束ねて一度の出力で処理せよ」という方向へ変えた。問いが変わったのだ。「モデルはGUIをどれだけうまく扱えるか」から、「システムはどんな手段を使おうと、実際のコンピュータで仕事をどれだけうまくやり遂げるか」へと。
問題は、こうした代表的な実装がほとんど閉じている点だ。GPT-6 Astra一つとっても、モデルの重みはもちろん、プロンプト構成全体も、実機ハーネスも、デバイス制御SDKも、実行ログも、どれ一つ公開されていない。だからコミュニティは、このシステムを再現することも、別の設計と比較することも、どの設計上の選択がコストと成功率をどう変えるのかを検証することもできない。OpenGCUAは、その閉じた部分を開いて一緒に研究しようという提案だ。
著者らは、優れたエージェントを部品の数で定義しない。モデル、画面認識、タスク調整、ツール、実行環境まで構成要素をすべて揃えても、シェルコマンド一行で済むことを画面の十回クリックで処理してしまえば意味がないからだ。そこで「汎用コンピュータ操作エージェント(GCUA)」を、一手ごとに下す三つの判断として定義する。
行動と観察は四つの通り道を通る。GUI(画面クリック)、アクセシビリティツリー、CLI(コマンドでコンピュータを操作する方式)、APIだ。それぞれ強みが異なる。GUIはピクセルが見える場所ならどこでも通じるが遅く、アクセシビリティツリーは座標なしで要素を直接つかむ。CLIはファイルやデータを大量に扱うのに強く、APIは画面でもコマンドでも届かない機能に届く。どれか一つが常に最善なわけではないので、一手ごとに適した通り道を選び、必要なら混ぜるのが肝心だ。
一つ目の判断軸はコード実行だ。モデルがpyautogui.click()のような画面操作、bash()で実行するシェルコマンド、Pythonの計算を、一つのプログラムの中に混ぜて使う。
従来の「バッチ動作」方式と比べると違いがはっきりする。バッチ動作は、モデルが一度呼ばれるときに行う動作をあらかじめ決め、まとめて送り出す。最初のクリックの結果を見る前に、その次のクリックまで全部決めなければならない。コード実行は、プログラムが走っている途中で次の行動を決める。一度の呼び出しの中で、条件分岐(「ダイアログが見えたら閉じろ」)、反復(「各行ごとに三つのフィールドを埋めろ」)、検証(「状態が『保存済み』かどうか確かめろ」)が可能になる。十二回行き来するはずの作業が一度で終わる。著者らは、自分たちの以前の仕事であるバッチ動作を「制御フローのないプログラム」と呼び、終着点ではなく踏み石だったと評している。
利点は二つある。中間結果が次の動作を決めるのでモデルを呼び直す回数が減り、モデルがすでに持っているプログラミング能力をコンピュータ操作にそのまま引き出せる。著者らがGPT-6 Astraの実際の実行ログを解析した事例では、繰り返し現れるパターンが五つ見つかった。ある通り道で得た情報を別の通り道が受け取って使うクロス連携、25枚の画面を一枚のコンタクトシート(複数の画面を一枚にまとめて貼った画像)に束ねて次の観察として使うこと、背景画像と透明度をassert(条件が成り立つか検査するコード)で確認すること、などだ。
二つ目の判断軸は、ハーネスが握っていた判断をモデルに委ねることだ。従来のハーネスは「一手ごとにスクリーンショットを撮る」のように、多くの判断をルールで固定する。OpenGCUAはこうした判断をモデル自身にさせる。現在の実装では、モデルはスクリーンショットがいつ必要かを自ら要求し、作業状態をどう追跡するかを決め、プログラムを実行する前にそのプログラムの目的をまず明らかにする。
これがなぜコストと結びつくのか。AIは入力をトークン(文字や画像を細かく分けた処理単位)に変えて処理し、処理量が多いほどコストがかかる。キャッシュは、入力の前半(プレフィックス)が前回とまったく同じときに、その部分を再計算せず再利用する仕組みだ。新しいスクリーンショットを入力の末尾に付け足すだけなら、すでに積み上がったプレフィックスは壊れない。再利用が壊れるのは、文脈を減らそうとして過去のスクリーンショットを消したり差し替えたりし、プレフィックス自体が変わってしまうときだ。論文の実装は、一手ごとにスクリーンショットを撮り続けるが、それをモデルに入れるかどうかだけを選ぶ。モデルが「今は画面を見る必要がない」と判断して画面を挿し込む回数を減らせば、文脈がゆっくりとしか膨らまず、過去の観察を消したり差し替えたりする必要が減り、その分プレフィックスが保たれて再利用が生き、コストが下がる。
同じ枠(三つの判断)で既存の系譜を並べてみると違いが見える。GUIエージェントは三つの判断をすべて固定する。常にスクリーンショットだけを見て、一度にGUI動作を一つだけ行い、文脈は「直近の数枚」のようなルールに従う。CLIエージェントは画面を見られない代わりに、シェルで反復・分岐・変数を使えて柔軟だが、グラフィックでしか扱えないアプリには手が出ない。マルチエージェントのハイブリッドは、指揮役が課題を切り分けてGUI担当とプログラマに振り分けるが、通り道の選択はサブ課題ごとに一度、しかも指揮役からしか起こらない。
著者らの以前の仕事であるQwen-UI-Agentは、GUIとCLIを一つの行動空間に入れつつ動作をバッチで束ねた、GCUAの制限された特殊ケースだ。GCUAはその制約をすべて外す。固定された動作順序の代わりに四つの通り道にまたがるプログラムを使い、一手ごとにスクリーンショットを受け取る代わりに何を見るかを自ら決め、ハーネスのルールの代わりに作業状態をモデルが管理する。この研究の新しさは、新しい通り道を発明したことにあるのではない。散らばっていたアプローチを「誰が判断を下すか」という一本の軸で整列させ、その判断をモデル側に押しやった再構成にある。
評価の舞台はOSWorld-v2のオフラインセットだ(コンピュータ作業の遂行能力を測るベンチマーク)。比較対象は八つの先行モデルで、GPT-6 AstraとClaude Opus 5が明記されている。著者らは自分たちのGCUA設計をOpenGCUAハーネスで実装し、既存のモデルがコード実行と判断の委譲を使えるようにしたうえで動かした。この段階では自前の学習モデルがないため、この実験が測るのはモデルの能力ではなく、「同じモデルをどのハーネスに載せるか」、すなわち設計の効果である。
効率は成功率一つでは片づけない。著者らはタスクあたりのステップ数(一ステップ=モデル呼び出し一回)、出力トークン、推論トークン(出力トークンに含まれるが別途報告)、コストも併せて見る。委任は、人が自分でやるより速く結果を出してこそ初めて見合うからだ。ただしこれらの指標はベンチマーク内の効率を測るだけで、実際のユーザーのコンピュータのあらゆる条件を捉えるわけではない。その隔たりは後ろの実機パートで扱う。
| 比較条件 | 有効にした機能 | スコアの変化 | ステップ・効率の変化 |
|---|---|---|---|
| フルGCUA構成 vs バッチGUI専用 | コード実行 + 判断の委譲 | 平均部分スコア +19.6点 | タスクあたりステップ −53.0% |
| コード実行単独 vs GUI+CLIベースライン | コード実行のみ | 平均部分スコア +6.1点 | ステップ −14.8% |
| Qwen3.8-Max vs ハイブリッドCUAベースライン | コード実行 | 平均タスクスコア +5.2点 | ステップ −17.0% |
| オンデマンド観察(二モデル) | 判断の委譲のみ | タスクスコア維持 | キャッシュヒット率 +10.5pt、+14.4pt |
平均部分スコア(mean partial score)は、課題を最後までやり遂げられなくても、部分的にどれだけ達成したかまで反映したスコアだ。
表の一行目が核心だ。コード実行と判断の委譲をどちらも有効にしたフル構成は、最も弱いベースラインであるバッチGUI専用に対してスコアを大きく上げ、ステップを半分以上減らした。改善は八モデルすべてで現れ、最も強いモデルと弱いモデルのあいだのスコア差を半分以上縮めた。差の縮小は、弱いモデルほど設計改善の恩恵を大きく受けた可能性を示している。
二行目・三行目はコード実行だけを取り出した寄与だが、二つの数値は比較の基準が異なる。6.1点はGUI+CLIベースライン比の平均で、5.2点はQwen3.8-Max一モデルの結果だ。すでにシェルを使っているシステムにコード実行を加えたときに期待できる分は、こちらに近い。
四行目の判断の委譲は、より慎重に提示されている。オンデマンド観察(モデルが必要なときだけスクリーンショットを要求する)だけを有効にしたとき、二つのモデルでキャッシュヒット率が上がりつつも、タスクスコアは落ちなかった。効率は稼ぎつつ性能は守った、という意味であり、これは特定の二モデルのキャッシュヒット率という限られた観察だ。
実機の結果は性格が異なる。実際のmacOS課題四つで、モデル間の差がベンチマークよりはるかに大きく開いた。ハーネスを固定したまま、Qwen3.8-MaxはGPT-6 Astraに対して推論トークンを19.4倍、出力トークンを5.7倍使ってなお、やり遂げた課題は少なかった。ケーススタディは原因をモデルの振る舞いに求める。単純な操作に過剰な推論を注ぎ、実機条件への適応に苦労し、コード実行能力で差が出る、というのだ。ハーネスをいくら上手に組んでも埋められない差がモデル自体に残るという意味であり、OpenGCUAが次の段階として自前モデルの学習をロードマップに載せた理由だ。
著者らが挙げる限界ははっきりしている。今回のリリースには学習されたモデルがない。実機ハーネスとクロスデバイスSDKは予備(preliminary)版だ。実機評価はmacOS課題四つだけなので傾向を押さえるには小さな標本であり、著者ら自身もこれを決定的なベンチマークではなく事例として扱っている。
さらに検討すべき点もある。第一に、フル構成の19.6点向上はバッチGUI専用という弱いベースライン比だ。すでにコード実行を使っているシステムと比べれば、純粋な利得をこの数字だけで断定するのは難しく、コード実行単独の6.1点がその問いにより近いが、こちらもGUI+CLIベースライン限定だ。第二に、コード実行はモデルに任意のシェルコマンドとPythonを走らせる権限を与える。これをユーザーの実機に載せるときの安全境界はこのレポートの焦点ではないので、製品に持ち込む側が別途設計しなければならない。第三に、「何を見るかをモデルが決める」という設計には代償がある。モデルが観察を飛ばしたあいだにファイル保存が失敗したり、画面状態が変わったのを見落としたりすると、誤った前提の上で次のコードを走らせ、誤りが大きくなる。呼び出しを減らす利得と、誤りを早く見つける機会が減る損失を併せて見てこそ、設計のトレードオフが見える。
ONTLEは、AIプロジェクトマネージャーを派遣するサービスだ。人を採りにくい小規模企業や一人起業家の反復業務を軽くするのが仕事である。毎週月曜にAI PMがつくる週次運営レポートを例にとろう。在庫スプレッドシートから先週の販売量を集計し、取引先のPDF精算書から金額を抜き出し、ショッピングモールの管理画面でレビュー評価を確認して報告テンプレートを埋める作業だが、ここには先に見た「複数の画面を行き来する反復」がそのまま入っている。コード実行なら、集計をスクリプトで処理し、精算書の合計と管理画面の売上が合っているかをassertでその場で検証して、ウィンドウを十二回行き来するはずの作業を一つのプログラムの中で終わらせられる。
まだONTLEにこの設計を適用したわけではない。ただし適用するなら、何が残るべきかははっきりしている。実行前にプログラムの目的をまず明らかにする方式は、入力として使った資料・実行結果・照合で食い違った記録が一緒にログとして残ってこそ、はじめて監査可能性になる。レポートが間違っていたとき、どの判断で食い違ったかをたどれなければならないし、精算書の合計と管理画面の売上が合わないように照合が崩れる瞬間には、AIが止まって人に引き継ぐよう境界をあらかじめ定めておかなければならない。どのモデルをエンジンに載せるかも併せて測るべきだ。実機の結果が示したように、同じハーネスでもモデルによっては単純な操作に推論トークンを19倍以上多く使うからである。
コンピュータ・ブラウザ・携帯に一つのプログラミングインターフェースを与えようとする予備ツールです。すべての操作を特定のデバイス・アプリ・ウィンドウ・タブに明示的に結びつけ、アクセシビリティとビジョンを観察・操作の別々の手段として保ち、一つのプログラムが一つの課題の中で複数のデバイスを調整できるようにします。複数デバイスにまたがる作業を一つの流れで扱おうとする設計です。
推論トークンは出力トークンに含まれますが、モデルが「考える」ことにどれだけ資源を注ぐかを別に示す量です。実機でどのモデルが単純な操作に過剰な推論を注ぐかがコスト差を分けた以上、出力に混ぜておくと見えないこの分を切り出して見てこそ、同じハーネスでもなぜコストが開くのかが明らかになります。