RecreationWorld：GUI探索と実装・検証を統合するコンピュータ操作エージェント環境

近年のAIエージェント研究は、主に二つの異なる方向で進展してきた。一つは画面を見てマウスやキーボードで操作を行う「GUIエージェント」であり、もう一つは端末上でコードを書いて実行やデバッグを行う「コーディングエージェント」である。しかし両者は互いの得意領域に対して盲目であった。GUIエージェントは画面の背後にあるソフトウェアを構築できず、コーディングエージェントは自らが生成したコードが画面上にどのようなインターフェースをもたらすかを直接見ることができない。

現実のソフトウェア業務を考えてみよう。例えば、仕様書がなく「実際に動く旧ツール」だけを手渡されて社内システムの刷新を任されたエンジニアの状況である。エンジニアは旧ツールの画面を開いてボタンを押し、数値を入力して挙動を観察する。その仕様を踏まえて新しいコードを書き、アプリをビルドして起動し、旧ツールと同じように操作して結果を確かめる。不具合があればコードを修正し、再び動かす。

この作業例は、画面の観察とコード実装、成果物の再実行と確認が不可分であることを示している。ただし、この比較には注意すべき境界がある。現実の業務開発では既存のデータベース定義を参照したり、利用者にヒアリングを行ったり、社外APIと通信したりすることが多い。対して本研究が扱う領域は、外部ネットワークや人間との対話を遮断し、単一環境内で完結するローカルアプリの探索・実装・検証に焦点を当てている。

従来のコード生成評価が抱えていた限界は課題の与え方にあった。自然言語の要件定義はどれほど詳細でも解釈の曖昧さや抜け漏れを排除できず、プロンプトから単発でコードを生成させるだけでは、エージェントが自ら画面を動かして隠れた仕様を発見する能力を測定できない。

この課題を克服するために論文arXiv:2609.22000v1（2026年9月18日提出、著者Shuai Baiら32名）が提案したのが、フレームワーク「RecreationWorld」である。中核アイデアは、稼働するオープンソースアプリケーション（参照アプリ）をそのまま「実行可能なオラクル（正解判定基準）」兼「仕様書」として提示する「再現（Recreation）」という設計である。

RecreationWorldにおいてエージェントに決まった作業手順は与えられない。いつ参照アプリを操作して仕様を確かめ、いつコードを書き、いつ候補アプリを立ち上げて確認するかはエージェント自身が自律的に判断する。提出物はプラットフォームごとのビルド・起動契約を満たす完全なソースコードであり、内部実装ではなく外部から観察可能な挙動が参照アプリと一致しているかによって採点される。

実用的なソフトウェア開発は単一のOSにとどまらない。RecreationWorldは、Ubuntu、macOS、Windows、Android、Webの5つのプラットフォームにまたがる再現可能な固定環境を提供する。

エージェントを支える統一ハーネスには、プラットフォーム固有のネイティブGUI制御ツール（画面キャプチャ、マウス操作、キーボード入力、アクセシビリティツリー取得など）と、共通のコーディングツール（ファイル編集、シェルコマンド実行、ビルドツールの呼び出しなど）が統合されている。

エージェントは以下の手順を任意の順序で自律的に反復する。

1. 実行中の参照アプリをGUIで操作し、画面配置や入力への応答を観察する。
2. 観察した仕様に基づき、端末やエディタを用いてゼロからソースコードを実装する。
3. コードをビルドし、候補アプリを起動する。
4. 候補アプリを実際に操作し、挙動や見た目が参照アプリと一致しているかを確認する。
5. エラーがあればコードを修正し、再ビルドと確認を行う。

フレームワークの評価用データセットとして「RecreationBench」が導入された。5つのプラットフォームから各50件、合計250件の再現課題が収録されている。

評価の客観性を担保するのが「参照アプリに根ざしたテスト生成」である。初期状態、入力操作シーケンス、期待観測を定義したテストスクリプトを作成し、参照アプリ上での動作確認と人間のレビューを経て確定させた「凍結テスト群」を候補アプリへ同一条件で適用する。

テストスクリプトは単なる起動確認にとどまらない。5プラットフォームのマクロ平均で、操作後の結果を検証するテスト（Outcome）が94.2%を占め、起動直後の確認（Start）は22.8%である。完全一致検査（Exact）は40.7%を占める。さらに操作の深さでは、1回の操作結果を検証するテスト（1 hop）が53.2%、画面遷移や複数回入力を伴う深いテスト（2+ hops）が24.1%含まれ、多段階の状態遷移が厳密に検証される。

候補アプリの適合度は、内部コードの比較ではなく観察可能な挙動で測定される。評価系はプログラム検査と視覚検査の二軸で構成される。

プログラム検査はアクセシビリティAPIや自動化APIを介し、ボタンのラベル、テキスト、リスト要素数、トグル状態などUI要素のプロパティや計算出力を機械的に読み取り、二値（合格／不合格）で判定する。視覚検査は固定チェックポイントでスクリーンショットを撮影し、参照画像と対比させる。判定器には視覚言語モデル「Qwen3.7-Plus」がサンプリング温度0で使用される。

総合スコアは両検査の通過率を均等平均して算出される。

ここで $S_{\text{overall}}$ は総合スコア、$S_{\text{prog}}$ はプログラム検査の合格率、$S_{\text{vis}}$ は視覚検査の合格率を表す。

この評価が明らかにできるのは固定テスト手順での機能と配置の一致度であり、テスト未網羅の操作経路における振る舞いや、コードの保守性・安全性までは保証できない。

RecreationWorldは合成データ生成環境としても機能する。著者らは5プラットフォームから高得点の実行軌跡を各7,000件、合計35,000件選定し、均衡な教師ありファインチューニング（SFT）データセットを構築して2種類の初期モデル系列を学習させた。

学習効果を検証するため、再現課題とは異なる5つの分布外（OOD）ベンチマーク（ProgramBench、GameCraft-Bench、Vision2Web、OSWorld 2.0、WeaveBench）で転移性能が測定された。

RecreationBenchの主評価では、主要10モデルを標準Direct MCP構成、各課題1試行、20時間上限で比較した。総合スコアの首位はGPT-6 Astra（58.06%）で、Claude Opus 5（44.16%）、GPT-5.6 Sol（42.06%）が続いた。

しかし詳細な分析はモデルの重大な弱点を示している。最も顕著なのは、アプリ単位ですべてのプログラム検査に合格した割合（Prog=100%率）である。最高得点のGPT-6 Astraでも全検査に合格できた課題は2.8%にとどまり、他9モデルはいずれも最大0.8%であった。

失敗の原因はカテゴリ別の通過率に現れている。ネイティブ環境において、ボタン操作や値計算を伴う最も弱い動的カテゴリの通過率は、静的配置を検証する「構造（structure）」より9.1〜34.4ポイント低かった。Webでも静的コンテンツの通過率がインタラクションより28.2〜36.7ポイント高かった（カテゴリごとのアサーションと対象アプリは同一ではない）。エージェントは静的な見た目の枠組みを配置できても、操作に応じた状態変化や計算出力を苦手としている。

生成物の内部構造を分析すると、参照ソースと比較可能なネイティブ4環境において、89.4%の生成アプリが参照より総コード行数（LOC）が少なく、中央値LOC比率は16.9%であった。また92.3%の課題でソースファイル数が参照より少なかった。エージェントは多階層なモジュール設計ではなく、少数のファイルにロジックを凝縮したモノリシックなコードを生成しやすい。ただし、この構造的圧縮が低い動作忠実度の直接の原因であるとは確定していない。

運用の補助実験として、Windowsの50課題でClaude Opus 4.8を用い、永続プログラマブルGUIランタイムを導入したところ、1課題あたりの所要時間は4.12時間から3.04時間に短縮された（39ペアに基づく）。タスク品質を維持しつつ実行時間を短縮できる可能性が示されたが、構成全体の1試行比較であり、ランタイム単独の因果効果ではない。

また5つの分布外ベンチマークにおける訓練転移実験では、2つのモデル系列ともに全ベンチマークで最初のチェックポイントを上回って終了し、最大改善幅は17.9パーセントポイントであった。ただし推移は一様な単調増加ではなく、各チェックポイント1試行の限定的な測定である。

RecreationWorldの知見を実務へ応用する際は、前提と限界の把握が欠かせない。

第一に、環境の固定性と閉鎖性である。厳密な再現性を保つため、外部ネットワーク通信、ライブサービス、人間との対話、認証処理を除外している。刻々と変化する外部APIや複数ユーザーの協調を要するシステムの評価にはそのまま適合しない。

第二に、隠しテストの網羅性の限界である。凍結テスト群は有限の操作経路しか覆わず、全テスト通過も参照アプリとの完全な意味的同値性を保証しない。

第三に、事前学習データの汚染リスクである。公開オープンソースを参照しているため事前学習での記憶を完全には排除できない。行単位の一致度検査では、識別子変更や制御フロー変更を伴う再利用は検出できない。

第四に、判定器の不確実性と因果関係の未立証である。視覚検査のQwen3.7-Plus（温度0）には判定器固有の不確実性が残る。またGUI利用率や最終確認率のログ分析は記述的相関であり、それらが高得点を生んだ因果関係は示されていない。

したがって本成果が適合するのは、「参照が存在し、ローカルで決定論的に再生・検証できるアプリの再実装」や「GUI探索とコード修正を往復する訓練」である。外部サービス依存の強いシステムや、厳密な安全性保証が求められる用途には適していない。