新着研究 / AI Agent / VLM
過去の画面操作を毎回見極めて再利用、DeltaReplayが値の差し替えと記憶の放棄を選ぶ
DeltaReplay
DeltaReplayの原論文から掲載した図です。細部はクリックして拡大できます。
原論文の図の説明を読む
Figure 1: Reusing partly matching memory step by step. (Top left) The old and new tasks share their first steps but differ in one value and in the later steps. (Top right) Existing methods use or discard a stored record as a whole and fail here. (Bottom) DeltaReplay aligns the two task descriptions and decides at each step whether to replay the step, re-ground it with the new value, or discard it.
概要
- 成功した操作を画面と行動の遷移グラフとして保存し、現在の画面と依頼に照らして使い方を選ぶ。
- そのまま再実行、タスク固有の値を交換、基本エージェントへ戻る三経路を持つ。
- 同じ基盤モデルでAndroidWorldの成功率を最大10.3ポイント、SPA-Benchを最大25.0ポイント改善した。
補足:編集した模式図で仕組みを確認する
VISUAL EXPLAINER
図でつかむ、DeltaReplayの仕組み
- 01現在の画面と依頼
- 02記録との対応確認
- 03再実行・値交換・放棄
- 04現在の画面で操作
原論文の説明をもとにした模式図です。処理の細部は省略しています。
研究の背景
DeltaReplayは、携帯端末の画面操作エージェントが過去の成功手順を再利用する方法だ。新しい依頼は、日付や名前だけが違う場合も、一部の操作だけ同じ場合も、記録と全く関係がない場合もある。
古い手順を無理に使うと誤った値を入力し、全部捨てると再利用できる操作まで考え直すことになる。著者らは記録全体の採否ではなく、一操作ごとに現在の依頼へ使える部分を判断する。
手法
成功記録を、画面を節点、操作を辺とする遷移グラフへ保存する。画面のUIツリーの構造や文章を照合し、記録上の対象に対応する現在の要素を探す。要素番号が変わっていても、構造上の役割を使って対応付ける。
旧依頼の値を含まない操作は検証して再実行する。入力名や日付など旧依頼に依存する操作は、新旧の説明を照合して値を差し替え、曖昧なら基本エージェントへ戻る。画面が対応しない場合にはLLMが候補の適用可否を選び、すべて拒否することもできる。例えば同じ入力画面でも旧予約の日付をそのまま使わず、現在の依頼の値に置き換える。
新規性
特徴は、記憶の有用性を記録そのものの属性とせず、新しい依頼と現在の画面との関係で決める点だ。実行できる対象があることと、その操作が今回の目的に役立つことを別に扱う。
確認して直接使える部分ではモデル呼び出しを省き、値の交換や適用判断に限って追加処理を行う。記憶は読み取り専用で変更せず、利用の判断を実行時に行うため、過去の成功を上書きして新しい依頼へ合わせる方式とは異なる。
従来手法との違い
同じ基盤モデルの記憶なしエージェント、記録をプロンプトへ追加するRAG方式、遷移知識を使うGUI-explorerなどと比較した。専用のGUI-Owl-1.5もAndroidWorldで比較対象に含む。
Qwen3.8-Flashでは直接再利用により一操作の待ち時間も減った。一方、もともと速いQwen3-VL-30Bでは照合処理が追加の負担となった。成功率の改善と高速化は別の結果であり、記憶を使えば常に速くなるわけではない。
実験結果
AndroidWorldの116課題と、実機のSPA-Benchから選んだ60課題で評価した。Qwen3-VL-30Bでは成功率が43.1%から53.4%、23.3%から48.3%へ向上した。Qwen3.8-Flashでは49.1%から56.9%、41.7%から58.3%だった。
AndroidWorldの後者の一操作時間は24.8秒から19.7秒に短縮した。各課題は一回ずつ実行し、成功はLLM判定器で評価した。動くルール判定器との一致は91.5%であり、判定器と実行の揺らぎも残る。
応用の可能性
編集上の応用案 · 論文が実証した用途とは区別しています。
編集上の応用案:同じ社内アプリで入力値を変えて繰り返す作業の、検証済み操作を再利用する。入力は新しい依頼、現在画面、成功記録で、出力は今回の画面に対応した次の操作とする。
共通の画面遷移は使い、名前や日付などの値は新しい依頼で置き換える。適用できない記録を捨てた理由も残し、担当者が失敗を確認できるようにする。実アプリでの送信や確定の扱いは業務の承認条件に合わせる想定だ。
導入時の検証
導入時の検証案 · 対象データでの再評価が必要です。
導入時の検証案:送信を伴わない試験用アプリで成功手順を記録し、同じ作業、値だけ違う作業、一部共通、無関係の四条件を作る。記憶なしを基準に成功率と一操作時間を比較する。
古い値の残存、対象要素の誤対応、記憶の拒否、モデル呼び出し数を記録する。画面順やラベルを変えた条件も加え、変化を検知して基本エージェントへ戻れるかを確かめる。試行を反復し、一回の成功差と通常の変動を分けて測る。
限界と課題
著者らは成功記録のある群ほど元から易しい課題と相関するため、記憶の種類が違う群の成功率を直接比べられないと明記する。SPA-Benchでは評価された基本エージェントの成功記録を記憶に含む点にも注意が必要だ。
一回の実行には揺らぎがあり、値の照合や画面対応が曖昧なら再利用できない。編集上の確認点は、未知アプリへの転移、複雑な値変更、誤った成功記録である。記憶の量だけでなく、正確さと適用範囲を管理したい。
出典
元のタイトル・要旨を確認する(英語)
DeltaReplay: Task-Relative Memory Reuse for Mobile GUI Agents
Memory-augmented mobile GUI agents store successful execution trajectories and reuse them in later tasks, but a stored trajectory rarely matches a new task exactly. The new task may use different parameters, share only some of its steps with a stored trajectory, or have no relevant record in memory. Forcing the agent to use irrelevant memory can mislead it, whereas discarding memory that may still be useful deprives it of guidance from past experience. To address this dilemma, we propose DeltaReplay, a step-level memory reuse framework that decides how to use existing memory without modifying it. We observe that the reusable part of a stored record is determined not by the record itself but by its relation to the new task, mainly through two factors: page-level consistency and action-level generality. We therefore store execution trajectories as paths in a transition graph, whose nodes (pages) and edges (actions between pages) capture these two factors. At reuse time, the action on each edge is split into a task-independent operation and task-specific parameters. DeltaReplay then compares each recorded step with the new task and the current screen, and decides whether to follow it, execute it after replacing its parameters, or leave it to the base agent. On AndroidWorld and SPA-Bench, DeltaReplay improves the task success rate over a base agent with the same backbone by up to 10.3 and 25.0 percentage points, respectively. These results indicate that deciding at each step how to use retrieved memory lets agents benefit even from partially matching trajectories.
論文本体の取得範囲に基づく解説。AIが作成した未校閲の記事です。性能の数値は著者の評価条件に依存します。応用例と検証計画は編集上の提案です。収集:2026-10-09




