人間のようにコンピュータを操作するAIを「コンピュータ使用エージェント(CUA)」と呼ぶ。この種のAIを教えるには、実際に触って操作できるソフトウェアが大量に要る。ところが、そのソフトウェアを用意すること自体が常にボトルネックだった。SoftwareGymは発想をひっくり返す。訓練に使うソフトウェアそのものを自動で量産してしまうのだ。こうして合成した環境で身につけた操作能力だけで、あるモデルは実アプリのベンチマークOSWorldの成功率を41.39%から56.97%まで引き上げた。ここでの成功率はPass@3、つまり3回試して1回以上成功した課題の割合である。OSWorldに含まれるアプリも、課題も、行動の記録も、学習には一つも使わずに得た結果だ。
コンピュータ使用エージェントを教える作業は、自動車教習に似ている。教科書を読むだけでは運転は覚えられない。実際に道路に出てハンドルを切り、ブレーキを踏んでみて初めて体に染みつく。CUAも同じだ。実行されるソフトウェアの中でボタンを押し、メニューを開き、ファイルを保存してみた行動の記録 — この分野では「軌跡(trajectory)」と呼ぶ — が積み上がって、ようやく腕が上がる。問題は、この「道路」を確保すること自体がボトルネックだという点にある。
これまでの道は大きく二つあり、どちらも限界がはっきりしていた。
一つめは、すでにあるデスクトップ・モバイルアプリをそのまま訓練場に持ち込む道だ。GIMP、VLC、Thunderbirdのような本物のプログラムなので、状態も現実的でワークフローも複雑になる。しかし、アプリ一つを「いつ動かしても同じように再現される訓練環境」へ統合するコストが大きい。だから扱えるアプリの数は少なくなり、同じアプリで繰り返し学習するうちに「そのアプリだけに通じるコツ」を丸暗記してしまう過学習のリスクが残る。OSWorld、Windows Agent Arena、AndroidWorldがこの系統だ。
二つめは、ブラウザの上にソフトウェア環境を建て増しする道だ。配布が楽で、状態を制御しやすい。その代わり、すべてがブラウザ・HTML・DOMという同じ土台の上に載るため、ネイティブアプリ特有の構造や、複数の段階にまたがって状態がつながる深いワークフローを盛り込みにくい。相互作用が浅くなるということだ。
著者らは、よいCUA訓練環境は次の三つを同時に備えるべきだと考える。画面と操作方法が十分に多様であること(多様性)、複雑でありながら最後まで動く軌跡を取り出せること(信頼性)、少ない手間で環境を増やし続けられること(拡張性)だ。既存の二つの道は、この三つを一度に満たせなかった。多様性を解き放てば同じカテゴリの中でレイアウトが似通って収束してしまい、信頼性を担保しようとすれば、明示した機能が画面全体の流れの中で最後まで動くかを一つずつ確かめねばならず、これを大規模にやると人手では到底こなせない検証負担が積み上がる。
SoftwareGymの選択は、「借りてくる」でも「ブラウザで真似る」でもない。検証ループを中に組み込んだまま、ネイティブのデスクトップアプリを新たに合成し、ソフトウェアの分布そのものを広げるという道だ。
SoftwareGymは、複数のAIエージェントが役割を分担する自動パイプラインである。ソフトウェアを設計し、実装し、自ら触って検証する。合成は三つの段階で流れていく。一つの機能を追いかけながら見てみよう。「ファイル名を変更して、アプリを閉じて開き直しても、その名前がそのまま残っている」という、どのアプリにもあるありふれた機能だ。
第1段階 設計。 ソフトウェアの種類と参考資料さえ渡せば、パイプラインが詳細な機能仕様と複数のUI設計を描き出す。先ほどの例の機能なら、ここで「ユーザーが名前を直す地点はどこか、どんな動作をすれば名前が変わるのか、変わった後に画面に何が見えるべきか、そして開き直したときに名前が保たれているかを何で確認するか」まで、あらかじめ文章で釘を刺しておく。この「確認方法」を設計段階で定めておくのが核心だ。機能仕様がそのままテスト基準になるので、作る目標と採点する目標が最初から一致する。同じ設計段階で多様性も強制する。同じ「名前変更」の機能でも、メニューの位置や画面構造を互いに変えた複数のバリエーションを作り、モデルが一つの見た目だけに慣れてしまわないようにする。
第2段階 実装と評価。 受け取った設計どおりにアプリを実際に実装する。だが、コードがそれらしく見えても、押したときに本当に動く保証はない。そこで評価段階が「実行中のアプリ」を別途テストする。先ほどの例なら、テスト担当エージェントがアプリを立ち上げてファイル名を実際に変更し、アプリを閉じて開き直したあと、名前が残っているかを画面で確認する。通らなければどこで詰まったかを記録して実装段階へ差し戻して直させ、すべてのケースを通過するか、定められたバージョン予算を使い切るまで、この修理ループを回す。
第3段階 課題の合成。 最後に、このアプリでエージェントが解く課題を作る。このとき「証拠ゲート」が働く。前の段階で実際に押して動作が確認された機能だけを課題の材料に使う。テストを通せなかった機能や失敗した機能は課題から外れる。ふるいにかけた機能を難易度別にまとめ、易しい課題は目標一つで、難しい課題は前の段階の結果が次の段階の出発点になる多段階作業として構成する。ユーザーに見せるときは、座標や操作経路、内部識別子のような正解のヒントを隠した、自然な依頼文へと言い換える。
🔧 実装ボックス — 中をのぞくと - 設計: FunctionDesignerが機能を四歩(成熟した製品の機能ベースライン → 複数条件検索・一括操作・履歴・設定の保持・入力検証といった専門機能の追加 → モジュール間の状態・依存・障害復旧をつなぐワークフロー → 「実装・評価の契約」として仕様化)で拡張する。契約には、ユーザーの入口、ユーザーの動作、期待される状態変化、目に見えるGUIの反応、合格チェックポイントが盛り込まれる。 - 多様性の仕掛け: StyleDesignerが同じ機能を、製品のポジション・情報構造・相互作用・視覚的アイデンティティが異なる複数のスタイルで作り分ける。バリエーション同士は最低でも二つのレイアウト次元で異なっていなければならず、各設計を窓・領域・パネル・コントロールのレイアウト木に変換し、木どうしの編集距離(tree-edit distance)で類似度を測る。最小距離がしきい値を下回れば、最も区別のつかない設計を再生成する。IconDesignerは、アイコンが色だけ違うのではなく構造的に異なるよう制約する。UI技術はAvaloniaで、生成したXAMLをすべてコンパイルして実行可能性を確認する。 - 実装・評価: CoderがAvaloniaアプリを実装し、DevCoderが機能マニュアルと突き合わせて監査・補完する(ここまでがソースレベルの検証)。EvalTaskGenerateAgentがテストケースを作り、GUIAgentがマウス・キーボードで実行して、軌跡・チェックポイントの証拠・最終状態・失敗箇所・修理の提案を残す。評価ラウンドごとに、実装物とUI設計図の間の視覚忠実度スコアを計算し、しきい値を下回った箇所を狙って修理する。
ここで三つの層を区別しておくと、後で出てくる数字を取り違えずに済む。
何で学習したか。 ベースモデルはQwen3.5-9Bだ。ここで9Bはパラメータ90億個の規模という意味で、いまの基準では小さい部類に入る。これにSoftwareGymのアプリから集めた軌跡だけで、マルチモーダルSFT(教師あり微調整)を回した。OSWorldのアプリ・課題・軌跡は一粒も使っていない。
どこで評価したか。 二つのベンチマークを用いた。一つはOSWorldで、Chrome・GIMP・Calc・Impress・Writer・Thunderbird・VLC・VS Codeの8ドメイン244課題だ。もう一つは著者らが自作したSoftwareGym-Benchで、12カテゴリからカテゴリごとにアプリ一つ、アプリごとに手動検証した課題を10個ずつ、計120課題である。
二つの評価がそれぞれ何を示すか。 両者は測るものが違う。OSWorldは「学習に使っていない実アプリへの転移」を、同じ12カテゴリの中で競うSoftwareGym-Benchは「学んだカテゴリ内での実力(ドメイン内)」を見る。ここで一つ、誤解を正しておく必要がある。OSWorldが学習カテゴリと「カテゴリそのものが重ならない」ベンチマークだというわけではない。論文§4.2によれば、合成アプリのうち121個がOSWorldに対応する8カテゴリに属する。転移が成立するというのはソフトウェアのカテゴリが重ならないという意味ではなく、学習に一度も使っていない実アプリへ操作能力が移っていくという意味だ。だから二つのスコアを足して一つの成果のように読んではいけない。とりわけSoftwareGym-Benchには罠をわざと仕込んである。課題ごとに、触ってはいけない保護オブジェクトと、紛らわしい攪乱要素を入れ、決まった手順を機械的に踏むのではなく、何を直し、何を無視し、何を守るかを判断させる。単なる操作の再現ではなく、状態を読んで分別する能力を測っているのだ。
結果。 OSWorldで、この9Bモデルは全ドメインでベースを上回り、全体のPass@3が41.39%から56.97%へと15.58ポイント上がった。OSWorldのどれも学習に使っていないのだから、合成環境で身につけた操作能力が本物のアプリへ移ったという直接の証拠である。同じ表(Table 1)で、このモデルは自分よりはるかに大きいオープンウェイトのベースラインたちと肩を並べる水準にまで到達する。
SoftwareGym-Bench(Table 2)では、同じ9Bモデルが25.8%から40.0%へと14.2ポイント上がった。Qwen3.7-Plusを上回り、かなり大きい専門CUAのいくつもを追い抜く。ただしGPT-5.5(73.3%)やGemini 3.1 Pro(70.8%)のような大型の基盤エージェントとは、まだ大きな差がある。したがってこの結果は「SOTAを打ち負かした」ではなく、小さなモデルが合成環境の学習だけで、自分の体重を超えるモデルたちと重なり合う区間を作り出した、という方向で読むべきだ。
合成の規模と信頼性も数値で裏づけられている。182個のアプリの平均GUI課題通過率は91.5%だ。Figure 4によれば、8つの整合カテゴリの121個のアプリで、GUIの証拠が49個の主要モジュールのすべてと、具体的なネイティブ機能の78.8%をカバーする。生成されたソフトウェアが見かけだけの張りぼてではなく、実際に押せる機能で満たされているという意味だ。
📎 再現用の情報。 合成では、GPT-5.5を載せたCodex CLIエージェントが設計・実装・評価ケースの生成を担い、各アプリは最大3バージョンまで仕上げた(全ケース通過時は早期終了)。生成したアプリのGUI評価は、Seed 2.1 PがUbuntu 22.04.3の仮想マシン上で、ケースあたり最大50ステップで実行した。最終モデルの評価条件は、温度1、相互作用予算100ステップ、課題ごとに独立したロールアウト3回だ。設計・実装モデルと評価モデルを分けたのは、作った側が自分の結果を採点する偏りを減らすためである。
何が転移するのか — 仮説。 著者らは「転移可能なGUI相互作用」を学ぶと結論づける。何が移っていくのかを具体的な能力の仮説として書き下すと、こうなる。① 見慣れない画面で目当ての機能を見つけ出す能力、② 複数の作業にまたがってアプリの状態がどう変わったかを追う能力、③ 保存したり再実行したりしたあとに結果がきちんと残っているかを確認する能力。この三つは特定のアプリの手順ではなく、アプリを横断して通じる能力なので、OSWorldへの転移を説明できる。
残る問い — 何が成果を生んだのか。 この転移がレイアウトの多様性のおかげなのか、検証の品質のおかげなのか、単に学習量のおかげなのかは、まだ切り分けられていない。三つの要因を一つずつ外して比べる実験があって初めて、「何が効果の源なのか」を言える。
残る問い — 現実の泥くささ。 SoftwareGymは、設計契約とチェックポイントできれいに検証できるソフトウェアを作る。そのきれいさが強みであり、弱みでもありうる。実際の業務ソフトウェアは、遅いネットワーク、壊れた状態、曖昧なエラーメッセージ、レガシーUIの不統一で満ちている。だとすれば、検証できる地点も狭まる。ネットワーク遅延が割り込んだ状況、操作が一度失敗したあとに復旧しなければならない状況で、このモデルが持ちこたえるかを、別途評価してみる必要がある。
設計上の制約。 合成の対象はAvaloniaベースの独立したデスクトップアプリケーションだ。ブラウザアクセスの浅い相互作用を避けるための選択だが、裏を返せば、生成できるソフトウェアがこの技術スタックとデスクトップのパラダイムに縛られる。ウェブ専用のワークフローや、モバイル特有のジェスチャーがこのパイプラインで自然にカバーされるのかは、抜粋の範囲では確認できない。
上位モデルへの依存。 合成に、GPT-5.5やSeed 2.1 Proのような上位モデルを設計者・評価者として動員する。つまり、より強いモデルの判断を蒸留して小さなモデルを育てる形に近い。この方式が評価者モデル自体の性能上限を超えられるのか、評価者が見逃す失敗の型がデータにそのまま残るのかは、検討すべき点だ。ただし、設計・実装・評価の主体を分けて自己採点の偏りを減らした設計が、この懸念をいくらか和らげてくれる。
ONTLE(온틀)は、小さな企業や一人の起業家が、人を増やしにくい繰り返し業務を軽くできるよう「AI PM」を付ける サービスだ。AI PMは、顧客企業の業務ツールを自ら操作して、決められた繰り返し業務を処理するエージェントである。
一つの場面に絞ってみよう。ONTLEがある小企業にAI PMを付ける。その会社は自前で作った在庫管理の管理画面を使っている。メニュー構造も、ボタンの位置も、保存の流れも、この会社だけのものだ。AI PMが「入庫した新規品目を分類し、重複するSKUには手を触れず、月末の在庫レポートを書き出せ」といった仕事を引き受けるには、まさにその管理画面に手が馴染んでいなければならない。ところが、この管理画面向けの訓練データは世の中に存在しない。顧客企業のソフトウェアをそのまま吸い上げて学習させる道は、PII・機密の問題でふさがれている。
SoftwareGymから借りる原則は一つに絞られる。「修正すべきデータと、保存すべきデータを一緒に評価する」ということだ。SoftwareGym-Benchが保護オブジェクトと攪乱要素で「触るべきものと守るべきもの」を判断させた、まさにその設計が、「重複するSKUには手を触れるな」という業務指示とぴたりと同じ形をしている。決まった手順を機械的に踏むエージェントではなく、状態を読み、何を守るべきかを知るエージェントであってこそ、繰り返し業務の軽減が事故なく回る。
適用の仮説はこうだ。顧客企業の管理画面を直接吸い上げて使う代わりに、そのカテゴリと機能仕様から出発して、構造の異なる「練習用の管理画面たち」を合成し、そこでまず学習させる。そのうえで、実際の顧客環境で在庫の修正・重複の保存・レポートの生成がきちんとできるかを検証する。練習場で身につけ、本番で確かめるというわけだ。ONTLEの居場所は、人を置き換えることではなく、採りたくても採れない人手を埋めることであり、合成環境と実環境のあいだの隔たりは、結局この最後の検証で埋めるしかない。
実行されるプログラムだ。各機能が入口から状態の保存・画面の反応まで備えて実装され、立ち上げて押してみるGUI検証を経る。182個のアプリの平均GUI課題通過率が91.5%であることが、その根拠だ。ただしこの数値が、すべての機能の完璧な動作を保証するという意味ではない。
違う。OSWorldのアプリ・課題・軌跡は学習にはいっさい使わず、評価にのみ使った。だからこそ、41.39%から56.97%への上昇が「学んだことのないアプリへの転移」の証拠として読める。
違う。SoftwareGym-Benchで9Bは40.0%と、Qwen3.7-Plusやいくつもの大型専門CUAは上回ったが、GPT-5.5(73.3%)・Gemini 3.1 Pro(70.8%)とは依然として大きな差がある。要点は全面的な優位ではなく、「小さなモデルが合成環境の学習だけで、体重が上のモデルと重なる区間を作った」ということだ。
設計・実装・評価・修理を最小限の人の入力で自動化し、バッチ単位でアプリを生成する。ただし、合成にGPT-5.5(Codex CLI)やSeed 2.1 Proのような上位モデルを動員する点は、コストとして念頭に置くべきだ。詳しい資源の所要は論文のFigure 5で扱われる。