1. この論文は何を問題にしているか

Web エージェントに予定の登録や連絡を任せるとき、作業が要件どおりに終わったかを判定する仕組みが要る。毎回人が確かめるわけにはいかないので、判定はプログラムに任せることが多い。この判定役を検証器（verifier）と呼ぶ。この論文が問うのは、一度書いた検証器を使い回してよいか、である[1]。

要件は変わる。担当チームや宛先が変われば、合格の条件も変わる。検証器を凍結したまま使うなら、変わった要件を正しく判定できるか、その判定に従ってエージェントが動いたとき正しい成果物が届くか、の二つを確かめなければならない。abstract は、再利用できる検証には、変わる要件に追随し、その後の実行を支えるルールが要る、と書く。

この論文は arXiv に公開された査読前のプレプリントで、以下はすべて著者らの主張として読む。

2. 何を提案しているか

芯は、凍結した合否のルールを、要件の側と実行の側の両方から試し、二つの試験を結びつけることである。要件の側では、同じルールを要件の変わった状態に当てる対の試験を行う。実行の側では、保存しておいた同じ開始状態（saved openings）からエージェントを動かし、検証器の判定が成果物の受け渡しにどう効いたかを見る[1]。

規模は 97 タスク、79 の系統（families）、四つの Web サービスである。公開リポジトリによれば、対象は Linear、Slack、Box、カレンダーの作業で、著者らは指示、状態、プログラム、参照ルール、実行の軌跡をすべて公開している[2]。実験に使ったモデルは DeepSeek Flash と Pro である。

3. 何を示したか ── abstract に書かれた範囲だけ

二つ目の区間はどちらも 0 を含む（Pro は上端がちょうど 0）。abstract の範囲では、使い回しが作り直しより明確に劣るとは言えない、という読み方になる。三つ目の結果は、試験での正しさと実行での正しさが一緒に見られた、という関連である。パネルを直せば成果物が良くなるという因果までは、abstract は示していない。誤りのある群が 11 件と少ないことも割り引いて読む必要がある。

4. 具体例で見る

社内の業務ツールで、エージェントが会議を登録し、関係チームに通知する作業を考える。検証器は「正しいチームに通知されたか」を判定する。組織が変わり、通知先のチームが変わった。

検証器を凍結して使い回す

判定のプログラムは書き直さない。変更後の状態を対にして試験し、新しい通知先でも正しく合否を出せるかを確かめてから使い続ける。試験に落ちた検証器だけを直す。

要件が変わるたびに作り直す

変更のたびに判定のプログラムを書き直す。旧い前提は残らないが、作り直した検証器が正しいかを、また一から確かめる手間がかかる。

品質保証の担当者:「通知先が変わったのに、検証器は前のままですね」
システム担当者:「変更前と変更後の状態を対にして試験し、両方で正しく判定できました。判定を誤った検証器のもとでは、エージェントの成果物も崩れやすいので、そこは先に確かめています」
品質保証の担当者:「では試験の記録を、変更管理の記録に添付してください」

5. 何が新しくないか／限界はどこか

Web エージェントを実際に近い環境で評価する試みは、WebArena などで既に行われている[3]。要件が段階的に変わる中での評価も、同じ束に入った FeatureArc がコーディングエージェントについて扱っている[4]。この論文の新しさは、評価の対象をエージェントから検証器に移し、検証器の正しさを要件の変化と実行の結果の両方に結びつけた点にある。

6. この主題が今なぜ束になっているか

この論文は大きさ 2 の束の代表である。もう一本は FeatureArc で、機能が段階的に拡張されるとき、コーディングエージェントが自分の以前のコードの上に正しく積み上げられるかを評価する[4]。二本は対象が違うが、「一度合格したものが、要件が変わった後も正しいか」という問いを共有している。

signal は束の厚みで立った。HF Daily Papers での upvote は 13、コメントは 2 件、GitHub のスターは 0 である。束も 2 本と薄く、この数字は主張の正しさを示さない。話題性と正しさは別の物差しである。著者らが一式を公開しているので[2]、他のグループが別のモデルで再現できるかが次の確かめどころになる。

7. 製薬・規制の現場から見ると何が接続するか

製薬企業のコンピュータ化システムでは、要件が変わると影響を評価し、必要な範囲で再検証する。そのとき、既存のテストスクリプトを流用するか作り直すかは、いつも判断が要る。この論文の対の試験は、その判断の材料をそのまま与える形をしている。変更前と変更後の状態を並べ、同じ判定のルールが両方で正しく働くかを記録すればよい。

もう一つは、検証器そのものを検証する必要である。著者らの結果では、判定パネルに誤りのある検証器のもとで、成果物の退行や差し控えがすべて起きていた。エージェントを業務に入れるとき、エージェントの試験と同じ重さで、合否を出すプログラムの試験を求めるべきだということになる。また、関門を挟まない継続が最も良かったという結果は、確認の手順を足せば安全になるとは限らないことを示す。手順を足すなら、その効果を測ってからにする。この論文の範囲で言えるのは、試した Web サービスとモデルについての結果までである。

合格の判定を出す仕組みも、変更のたびに試験される対象である。エージェントを任せる前に、判定の側の記録を残せるかが問われる。