OSWorld を導入する前に読む: 実マシン環境でマルチモーダルエージェントを評価するための構成
[NeurIPS 2024] OSWorld: Benchmarking Multimodal Agents for Open-Ended Tasks in Real Computer Environments
ひと目でわかる
- これは何？
- OSWorld は、GUI 操作を伴う開かれたタスクでマルチモーダルエージェントを測るためのベンチマーク兼実行環境である。VM プロバイダを差し替える設計と、評価の再現性をどこで担保しているかを README から読み解く。
- 誰に向いている？
- 採用すべきなのは、GUI 操作を伴うエージェントの評価を、実際のデスクトップ環境で回したいチームである。VMware か VirtualBox を前提にできるデスクトップ、ノート PC、ベアメタル環境が最も素直な出発点になる。
- 商用利用できる？
- できます。Apache-2.0 は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 1 日前です。
- 何の言語で書かれている？
- 主に Python です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
OSWorld が埋めようとしている穴は「GUI を含むタスクの採点」である
既存のエージェント評価の多くは、テキスト入出力や API 呼び出しの範囲で完結する。ところが実際の業務は、表計算ソフトを開き、セルを選び、書式を変え、保存するといった操作の連続でできている。OSWorld はこの層を対象にする。README が掲げるのは「Benchmarking Multimodal Agents for Open-Ended Tasks in Real Computer Environments」であり、実マシン上の開かれたタスクを測るという宣言になっている。対象読者は、GUI を操作するエージェントを開発していて、その成功率を第三者が再現できる形で示したい人である。ベンチマーク本体と実行環境が同じリポジトリに同居している点が特徴で、タスク定義だけを配るのではなく、VM の起動、初期状態のセットアップ、操作の実行までを Python 側から扱う。
DesktopEnv という抽象とプロバイダ差し替えの設計
リポジトリの構成から読み取れる中心は `desktop_env` パッケージである。README では `pip install desktop-env` により、ベンチマークタスクを含めずに環境部分だけを導入できると説明されている。つまり環境操作の層はベンチマークから切り離されており、`desktop_env/providers/` の下に VMware、VirtualBox、Docker、AWS、Azure、Modal といったプロバイダが並ぶ形になっている。2024-06-15 の更新では「環境部分のコードをリファクタリングして VMware 連携を分解し、VirtualBox や AWS、Azure などの他プラットフォームをサポートし始めた」と述べられており、プロバイダを差し替えられることが設計の主眼だと分かる。利用者側の接点は `DesktopEnv` の初期化引数で、Docker の場合なら `provider_name` に `docker`、`os_type` に `Ubuntu` か `Windows` を渡す。評価スクリプトの側から見ると、VM の起動方法が変わっても同じタスク記述を流せる、という形の抽象化である。
VMware と VirtualBox を前提にした導入手順
仮想化されていない環境、つまりデスクトップ、ノート PC、ベアメタル機では、README は VMware か VirtualBox の経路を案内する。手順は次のとおり。
git clone https://github.com/xlang-ai/OSWorld cd OSWorld pip install -r requirements.txt
Python は 3.10 以上が求められ、Conda での環境管理が推奨されている。次に VMware Workstation Pro（Apple チップの場合は VMware Fusion）を導入し、`vmrun` コマンドを設定する。設定が済んだかどうかは `vmrun -T ws list` で確認でき、成功していれば現在起動中の仮想マシンが表示される。ここまで終われば、付属のセットアップスクリプトが必要な仮想マシンのダウンロードと環境設定を自動で行う。VirtualBox も選べるが、README は並列実行や Apple チップ上の macOS については十分にサポートされない可能性があると明記している。評価を並列で回したいなら VMware 側を選ぶ理由がここにある。
Docker 経路は KVM が使えるかどうかで決まる
サーバ上で動かす場合、README は Docker を推奨する。ただし前提条件がはっきりしている。Linux で `egrep -c '(vmx|svm)' /proc/cpuinfo` を実行し、戻り値が 0 より大きければプロセッサが KVM を扱える見込みがある。macOS ホストは一般に KVM をサポートしないため、macOS で OSWorld を動かしたい場合は VMware を使うよう注記されている。実験を実行するときは `DesktopEnv` の初期化時に `provider_name` に `docker`、`os_type` に `Ubuntu` か `Windows` を渡す。注意点として、割り込みなどで実験が異常終了すると Docker コンテナが残留し、時間の経過とともにシステム性能に影響しうると README は述べている。その場合は `docker stop $(docker ps -q) && docker rm $(docker ps -a -q)` で掃除する。評価を大量に回す用途では、この残留コンテナの扱いを運用に織り込んでおく必要がある。
Modal 経路と、評価時間を短縮する AWS 並列化
Modal は VM Sandboxes の上で OSWorld を動かす経路である。`pip install 'modal>=1.5.0'` で SDK を入れ、`modal setup` で認証し、`python -m desktop_env.providers.modal.setup --os Ubuntu` でディスクイメージを Modal に配置したうえで、`python quickstart.py --provider_name modal --headless true` を実行する。詳細は `desktop_env/providers/modal/MODAL_GUIDELINE.md` に置かれている。もう一点、2025-07-28 の OSWorld-Verified の告知では、AWS 対応の強化により並列化を通じて評価時間を 1 時間以内に短縮できると説明されている。これは速さの主張であって、精度の主張ではない。時間短縮の恩恵を受けるには AWS 上で並列に回す構成を自分で組む必要があり、手元の 1 台の VM で同じ数字が出るわけではない。
初期状態の再現と、キャッシュという見えない依存
エージェント評価で難しいのは、タスク開始時点のマシン状態を毎回同じにすることである。OSWorld はこのために仮想マシンイメージと初期状態セットアップ用のファイルを配布している。README には、初期状態セットアップ用の事前ダウンロード済みファイルが Google Drive で提供されているという 2025-05-01 の告知と、ページ上部の Cache へのリンクがある。つまり評価の再現性は、リポジトリのコードだけでなく外部ホストに置かれたイメージとファイルに依存している。ネットワークが制限された環境や、外部ストレージへの取得が許可されていない環境では、この依存が導入の障壁になる。逆に言えば、イメージを社内にミラーできるなら再現性は確保しやすい。ここは README が明示していない部分であり、実際にどのファイルがどのタスクに対応するかは導入時に自分で確かめる必要がある。
向かないケースと、代わりに検討するもの
OSWorld が向かないのは、GUI を介さない評価で足りる場合である。コード生成や関数呼び出しの正しさを測りたいだけなら、VM を起動する必要はない。また macOS ホストしかなく KVM も使えない場合、README が示す Docker 経路は成立せず、VMware 経路に戻ることになる。比較対象として素直なのは、同じくコンピュータ操作を対象とする WebArena のようなブラウザ内に閉じたベンチマークである。違いは環境の範囲にある。ブラウザ内のベンチマークは DOM と HTTP の世界で完結するため、状態のリセットも観測も比較的素直に作れる。OSWorld は OS 全体を対象にする分、デスクトップアプリ、ファイルシステム、ウィンドウ管理まで含めた操作を測れる代わりに、VM イメージ、プロバイダ、初期状態ファイルという 3 層の依存を抱える。測りたい操作がブラウザ内で完結するなら、重い方を選ぶ理由は薄い。
Apache-2.0 で配布される環境と、更新の追い方
ライセンスは Apache-2.0 で、リポジトリのバッジにも明記されている。ベンチマークコードを自社の評価パイプラインに組み込むことはこの条件の範囲で検討できるが、同梱・配布する仮想マシンイメージや外部ホスト上のファイルが同じ条件で提供されているかは README からは読み取れない。ここは法務判断の領域なので、イメージの入手元ごとに条件を確認する必要がある。更新面では、PyPI の `desktop-env` が環境部分の配布チャネルになっており、リポジトリ側のリリースは v0.1.0（2024-04-11）と v0.1.16（2024-06-26）が記録されている。一方で README の更新告知は 2025 年まで続いており、リリースタグとドキュメントの更新が同期していない。導入時にバージョンを固定するなら、タグではなく特定のコミットを指すほうが安全である。
OSWorld-Verified 以降は、自分の数字をどの基準と比べるか
2025-07-28 の告知は、単なる機能追加ではなく比較基準の変更である。コミュニティから報告された問題を修正し、ベンチマークのシグナルをより有効にしたとされ、新しいモデル結果が公式サイトに更新されたうえで「最新版を実行する際は新しいベンチマーク結果と比較してほしい」と明記されている。つまり古い記事や古い論文の表と、手元の実行結果を並べても意味を持たない。評価を始める前に、参照する基準が Verified 以前か以降かを決めておく必要がある。これは導入の手間というより、結果の解釈に関わる制約である。ベンチマークを社内の意思決定に使うなら、比較対象の版を固定し、その版に対応する初期状態ファイルを使っていることを確認する作業が先に来る。
編集部の結論
採用すべきなのは、GUI 操作を伴うエージェントの評価を、実際のデスクトップ環境で回したいチームである。VMware か VirtualBox を前提にできるデスクトップ、ノート PC、ベアメタル環境が最も素直な出発点になる。逆に、macOS しか手元になく KVM も使えない場合や、評価を 1 時間以内に収める必要があるのに AWS 並列化を組めない場合は、Docker や Modal の経路を選んでも README が示す構成にはならないので向かない。導入前に確認するのは 3 点で、`vmrun -T ws list` が通るか、`egrep -c '(vmx|svm)' /proc/cpuinfo` の戻り値が 0 より大きいか、そして自分の結果を OSWorld-Verified の新ベンチマーク値と比較する前提でいるかどうかである。
コミュニティノート