GUI操作を自動で行うコンピュータ操作エージェント（画面のクリックやキー入力を自律的に行うAIモデル）の学習基盤を自前で構築・評価しようとすると、必ずぶつかる壁があります。
エージェントが8ステップ目まで正しく操作を続けても、9ステップ目でドロップダウンの誤クリックからモーダル（画面に重なる操作確認用の小窓）を誤って閉じてしまうと、そこから状態が壊れます。10ステップ目には存在しないはずのファイルを探し、15ステップ目には無関係なターミナルコマンドを打ち続ける。こうした「崩壊したのに気づかず暴走する」挙動は、エージェント評価基盤を検討している開発者・QA・MLOps担当者にとって他人事ではありません。
この問題への対処法として、学術論文「CUA-Master」（MMLab CUHK・清華大学・HKUST(GZ)・JD Explore Academyの共同研究）が、VMスナップショットのロールバック（仮想マシンを過去の特定時点の状態に巻き戻す操作）を使う設計を示しています。27Bパラメータのモデルで OSWorld Verified 80.2点、OSWorld 2.0で36.9点、WeaveBenchで43.9点というスコアを出しており、巨大モデルでも大量の自己対戦データでもなく、環境側のインフラ設計が効いている点が注目に値します。自社でエージェント評価・学習基盤を組む場合に、この設計思想をどこまで取り入れるべきか、判断軸を整理します。
どんな場面でこの判断が必要になるか
この判断が必要になるのは、GUIを操作する自律エージェント（ブラウザ操作・デスクトップアプリ操作・RPA的な自動化など）を評価・学習・継続的テストする基盤を自分たちで持つ場面です。
例えば社内の管理画面を自動操作するエージェントをCI/CDパイプラインに組み込みたい、あるいはOSWorldのようなベンチマーク（AIのデスクトップ操作能力を測る評価環境）を使って自社モデルやプロンプト設計を評価したい、というケースが該当します。単発のAPI呼び出しのテストとは違い、マルチステップで状態が積み重なる操作には、失敗時の扱い方そのものが設計課題になります。
判断軸
復元コスト
1回の失敗で捨てるデータの価値を考えます。13ステップ正しく実行して14ステップ目で失敗した場合、全部やり直すと13ステップ分の正常な実行ログが無駄になります。
VMを最初から再起動し、依存関係を再インストールし、シードデータを復元して、同じ前半部分を再現させるのにかかる時間とコストが、復元コストです。タスクが長いほど、この無駄は大きくなります。
汚染耐性
失敗後もエージェントに動作を続けさせると、壊れた状態に対して辻褄合わせの行動を取り始めることがあります。存在しないウィンドウを操作しようとしたり、無関係な場所をクリックし続けたりする挙動です。
こうした「崩壊後の迷走ログ」を学習データや評価ログにそのまま混ぜると、モデルは壊れた状態に対して幻覚的な回復行動を学習してしまいます。汚染耐性とは、このノイズをどれだけ検出・除去できるかという軸です。
運用の複雑さ
スナップショット方式は、VMのメモリ状態・アクティブウィンドウ・ファイルディスクリプタ・レイアウト情報などを安定した操作の節目ごとに記録する仕組みが必要です。
さらに失敗時には、検証結果（verifier residuals）・実行履歴・最終状態の3つを突き合わせて「どのステップで逸脱したか」を特定する検出器も必要です。これを自前で持つのか、既存ツールに任せるのかで運用負荷が大きく変わります。
評価対象のタスク長とステップ数
タスクが3〜5ステップ程度の短い操作であれば、失敗時に最初からやり直しても大きなロスにはなりません。一方でCUA-Masterが扱うような、ブラウザ起動から管理画面遷移・CSVエクスポートまで十数ステップに及ぶタスクでは、話が変わってきます。
選択肢の比較
エージェント評価・学習基盤を組む際、主に3つのアプローチが考えられます。使い捨てVM方式、継続実行（回復試行）方式、スナップショットロールバック方式です。
| 方式 | 失敗時の挙動 | データ品質 | 運用コスト |
|---|---|---|---|
| 使い捨てVM | 全体を破棄し最初から再実行 | クリーンだが正常ステップも失う | 低い（単純な再起動のみ） |
| 継続実行・回復試行 | 失敗後もそのまま続行させる | 低い（辻褄合わせのノイズが混入しやすい） | 低いが後処理が必要 |
| スナップショットロールバック | 直前の安定点まで巻き戻し分岐探索 | 高い（正常プレフィックスを再利用） | 高い（検出器・スナップショット基盤が必要） |
CUA-Masterの「Resilient Trajectory Collection」（耐障害性のある軌跡収集）は3番目にあたります。失敗を検出すると、直前のスナップショットまでロールバックし、正常に進んだ部分（プレフィックス）は保持したまま、失敗ポイントから分岐探索を再開します。最終的に検証に通った最短・最も効率の良い経路だけを学習データとして採用し、それ以外の分岐は破棄する設計です。
ケース別の推奨
タスクが長く、1回の実行に数分〜十数分かかるなら、スナップショットロールバック方式を検討する価値があります。管理画面の多段階操作やファイル処理を伴うワークフローの自動化を自前で評価するケースでは、使い捨てVM方式だと正常ステップの再現に時間がかかりすぎ、学習サイクルが回らなくなります。
タスクが数ステップの短い操作が中心なら、使い捨てVM方式で十分です。失敗してもやり直しのコストが小さいため、検出器やスナップショット基盤を自前で構築する投資対効果が見合いません。
既存のベンチマーク（OSWorldなど）をそのまま使って自社モデルを評価したいだけなら、ベンチマーク側がすでに用意している実行環境を使うのが現実的です。自前でスナップショット基盤を組む必要はなく、公式リポジトリの環境構築手順（仮想マシンイメージ、検証スクリプトの仕様）を確認するところから始めます。
継続的インテグレーションの一部として、UI回帰テストにエージェントを使いたいなら、スナップショットよりも軽量な「ステップごとのチェックポイント検証」を優先した方が運用しやすい場合があります。失敗検出の精度よりも、テストの再現性と実行速度が優先される場面だからです。
あえて見送るべき条件
チームにインフラ担当が薄く、VMのスナップショット機構（KVMのqcow2スナップショットやクラウドのイメージスナップショット機能など）を運用した経験がない場合は、スナップショットロールバック方式は見送った方が無難です。検出器の実装難易度が高く、投資に見合うリターンが出るまで時間がかかります。
また、学習・評価対象のタスクが頻繁に仕様変更される段階では、精緻な失敗検出ロジックを作り込んでもすぐに陳腐化します。タスク設計が安定してから導入を検討する方が手戻りが少なくなります。
評価対象のモデルやエージェントがそもそも単純なAPI呼び出し中心で、GUI操作をほとんど伴わないケースも対象外です。状態が壊れるリスク自体が低いため、スナップショット管理の恩恵が薄くなります。
まとめ
エージェント評価・学習基盤の設計では、失敗時に「全部捨てる」か「そのまま続行させる」か「直前まで巻き戻す」かという3択があり、タスクの長さと運用体制によって最適解が変わります。
次の一歩として、まず自分たちが評価・学習させたいタスクの平均ステップ数と、1回の失敗がどれだけの正常ステップを無駄にしているかを計測してみてください。そのうえで、OSWorldやWeaveBenchといった公開ベンチマークの環境構築手順を確認し、自前でスナップショット基盤を組むべきか、既存環境を使い回すべきかの判断材料にすることをおすすめします。