AIエージェントのUI自動テストが遅い理由と改善設計3選

Claude CodeやAIエージェントにiOSシミュレータやブラウザの操作テストを任せている、あるいは検討しているSREやQAエンジニアに向けた内容です。エージェントが画面操作を「見て考えて動く」たびに待たされて困っている場合の、原因の切り分け方と改善の選択肢を整理します。

AIエージェントにUI操作をさせると、人間の操作に比べて明らかに遅いと感じる場面があります。これは推論性能の問題ではなく、知覚（画面の状態を把握する処理）の設計に原因があるケースが多いです。実際に、AIエージェントの計算機操作を対象にしたOSWorld-Human研究（Abhyankar・Qi・Zhang、MLSys 2026）では、計画と振り返りのためのモデル呼び出しがタスク全体の時間の75〜94%を占め、人間より1.4〜2.7倍多いステップ数を要すると報告されています。

なぜエージェントは「まばたき」するたびに遅くなるのか

典型的なAIエージェントの操作ループは、スクリーンショットを撮る、画像をモデルに送る、次の一手を推論する、操作を実行する、また撮る、という繰り返しです。この各サイクルの冒頭でスクリーンショットを撮る行為は、目を閉じてから開くまでの「まばたき」に例えられます。

問題は、この構造がコンパウンド（複利的）にコストを増やすことです。各ステップは会話履歴として過去の観測画像を引き継ぐため、後半のステップほど処理が重くなります。OSWorld-Humanの計測では、終盤のステップは序盤より最大3倍遅くなるとされています。

さらに、スピナー（読み込み中を示す回転アイコン）がまだ回っているか、画面遷移のアニメーションが終わったかといった単純な判定まで、最もコストの高いコンポーネントである言語モデルに任せてしまっている点も見逃せません。これはインフラ設計でいえば、ヘルスチェックのような軽量な監視処理を、本来ビジネスロジックを担うべき高コストなサービスに背負わせているようなものです。

判断軸1: 知覚と推論を分離できる構成か

エージェントの動作を「関数呼び出し」として捉えるか、「常駐プロセス」として捉えるかが最初の分かれ目です。

改善案として提示されているアーキテクチャは、常に最新フレームを保持し続ける観測プロセス（Eyes）、操作履歴を記憶する実行プロセス（Hand）、そして両者の記憶を管理するレイヤー（Memory）を分離する構成です。screenshot()を都度呼ぶのではなく、画面変化のシグナル（damage signal）を検知したときだけキャプチャする設計により、静止画面ではフレームを一切生成しないという発想に転換しています。

自社のテスト基盤やエージェント統合を検討する際は、まず「知覚処理をモデル呼び出しと分離できる余地があるか」を確認してください。CI/CDパイプラインにAIエージェントを組み込む場合、この分離ができないツールは後述のコスト増に直結します。

判断軸2: キャプチャ手段のレイテンシ実測値

同じ画面キャプチャでも、実装方式によってレイテンシ（応答遅延）が大きく異なります。iOSシミュレータでの計測例を見ると差は歴然です。

この数値が示すのは、ダウンスケール（画像縮小）処理自体が残りの6.7msの大半を占め、キャプチャそのものはボトルネックではないという事実です。自社の監視・テスト基盤でも、どの処理にレイテンシが集中しているかをプロファイリングで確認する価値があります。simctlのようなCLIラッパー経由の呼び出しは手軽ですが、高頻度実行が前提のアーキテクチャでは実測値を取ってから採用判断すべきです。

判断軸3: フレームレート固定か、イベント駆動か

もうひとつの判断軸は、キャプチャを一定間隔（例: 60fps）で回すか、画面変化イベントに応じて発火させるかです。

固定フレームレート方式は実装が単純ですが、静止画面でも無駄なキャプチャとトークン消費が発生します。イベント駆動方式は、シミュレータが「画面が変わった」と通知するシグナルを起点にするため、変化がない間は処理コストがゼロになります。

この切り替えでCI（継続的インテグレーション）のテスト設計にも影響が出ます。「フレームカウンタが増加していること」をアサーションにしていたテストは、アイドル状態の画面では正しく失敗するようになるため、既存のテスト前提そのものを見直す必要があります。イベント駆動への移行時は、こうした暗黙の前提が壊れていないか棚卸ししてください。

ケース別の推奨

• 単発のバグ確認やアドホックな動作確認: 標準のscreenshot()ループで十分です。数回の呼び出しコストは無視できます
• CI/CDに組み込む定常的なUI自動テスト: 知覚と推論を分離した常駐プロセス型の構成を検討する価値があります。ステップ数が多いほど複利的なコスト削減効果が出ます
• モバイルアプリのE2Eテストをエージェントに恒常的に任せる: framebuffer直接アクセスなど、プラットフォーム固有の低レイテンシAPIの調査を優先してください
• ブラウザ操作エージェントを運用する: Playwrightのようなブラウザ制御ツールがDOM変化イベントやネットワークアイドル検知を標準機能として持っているか確認し、独自実装を避ける選択肢も検討してください

あえて見送るべき条件

知覚プロセスの分離やframebuffer直接アクセスは、常に採用すべき最適化ではありません。

テスト実行頻度が低く、月に数回程度の手動確認で足りるプロジェクトでは、常駐プロセスを構築・保守するコストの方が高くつきます。また、シミュレータやOSのバージョンアップでframebuffer仕様が変わるリスクもあるため、標準APIより実装の脆弱性が上がる点は認識しておく必要があります。

チームにインフラ実装の専任リソースがない場合は、まず標準のscreenshot()ループのまま、ステップ数を減らす（一度のプロンプトで複数操作をまとめる、不要な確認ステップを削るなど）方向でコストを抑える方が現実的です。

まとめ

AIエージェントによるUI自動テストが遅いと感じたら、まずどこに時間を使っているかを計測してください。OSWorld-Humanの報告通り、多くの時間はモデルの計画・振り返りに費やされており、単純な「画面が変わったか」の判定まで高コストな推論に頼っている可能性があります。

判断の起点は、知覚と推論を分離できる構成か、キャプチャ方式のレイテンシは実測しているか、フレームレート固定かイベント駆動かの3点です。まずは自分の環境でキャプチャ処理の実測値を取り、標準API（simctl相当のコマンドやPlaywrightの標準機能）で十分か、独自の低レイテンシ実装が必要かを切り分けるところから始めてみてください。