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

表計算を開いて数字を整え、ファイルを保存し、別のアプリに貼り付ける。こうした作業をまるごと引き受ける仕組みが、コンピュータ操作エージェントである。評価の場では、作業の終わりにできたファイルを機械的に照合し、条件を満たせば成功、満たさなければ失敗として数えてきた[2]。

著者らが問題にしているのは、この採点が通した情報の細さである。何百もの操作を重ねた末の最終形だけを見ても、途中で何が起きたかは残らない。キーボード入力を打ち間違えたエージェントと、画面上の狙った場所を押し損ねたエージェントは、採点表の上では同じ「失敗」になる。しかし直すべきところはまるで違う。失敗の中身が見えないままでは、次に何を改めるかの手がかりが取れない ── これが出発点である。この論文は査読を経ていないプレプリントであり、以下はすべて著者らの主張として読む必要がある。

何を提案しているか

提案の芯は一点に絞られている。作業を小目標（サブゴール）の連なりとして書き下し、その一つひとつが満たされたかを採点することだ。著者らはこの考えを OSWorld-Pro という課題集として実装した。abstract によれば、300 を超える課題に 2800 を超える小目標が与えられ、その土台として 67,000 を超える人手の注記が集められている。

小目標の達成判定には、人の判断に合わせて調整した大規模言語モデルの判定器を使う。小目標は前のものが終わっていないと次に進めない形で並んでいるため、どこまで進んでどこで止まったかが、採点の副産物として残る。最終成果物の照合を捨てるのではなく、その手前に工程の記録を足す、という位置づけである。

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

abstract が挙げる結果は二筋ある。一つは難しさの確認である。既存の最終成果物ベースの課題集では 83.4% に届く上位のモデルが、同じ系列の工程ベースの課題集では 75.7% にとどまったという。もう一つは失敗の分類で、著者らは小目標と関係のない操作を挟む型、画面上の位置を押し損ねる型といった、工程に現れる失敗の型を取り出したとしている。

abstract が示していないことも多い。課題がどの領域からどう選ばれたか、小目標をだれがどう書き下したか、判定器と人の判断がどの程度ずれたとき何が起きるか、注記を集めた手順に偏りが入っていないか。いずれも abstract の範囲では条件が示されていない。ここを推測で埋めるべきではない。

具体例で見る

工程で採点するとは、実務の言葉でいえば、成果物の検収から作業記録の点検に軸足を移すことである。

成果物だけを見る採点

提出されたファイルを開き、決められた条件に合うかを照らす。合えば合格、合わなければ不合格。落ちた理由は、見る人の推測に委ねられる。

工程を見る採点

どの手順まで進み、どこで止まり、途中で何を余計にしたかが残る。不合格の理由が、手順の名前で言えるようになる。

作業の引き継ぎに置き換えると

依頼者:「頼んだ資料、条件を満たしていませんでした」
担当者:「どこからやり直せばいいですか」
依頼者:「……分かりません。とにかく違っていました」

やり直しの起点が言えない引き継ぎは、次に同じ失敗を呼ぶ。工程単位の採点が埋めようとしているのは、この空白である。

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

中身を段階に分けて採点する発想そのものは新しくない。作業手順を書き下し、各段階に合否をつける点検は、人の仕事ではむしろ古い型である。この論文の新しさは発想ではなく、それを操作エージェントの評価基盤として組み、人手の注記を土台に据えた点にある、と読むのが妥当だろう。

限界も見える。第一に、小目標の書き下し方が採点結果を決めてしまう。細かく割れば失点が増え、粗く割れば工程を見る意味が薄れる。どの粒度が適切かを決める外の基準は、abstract には示されていない。第二に、判定器そのものが言語モデルであり、人の判断に合わせたと書かれていても、合わせ方の限界がそのまま採点の限界になる。第三に、工程が見えることと、失敗を直せることは同じではない。失敗の型を数え上げても、その型を消す手当ては別の仕事として残る。

なぜいま、工程を見る評価が束になっているのか

この主題は単独で立ち上がったわけではない。同じ時期に、自己改良を続けるエージェントを終点の成績ではなく過程の水準で評価しようという論文が並んで出ている[3]。扱う対象は違うが、問いは重なっている。終点の数字が上がっても、その上がり方が説明できなければ次の改良につながらない、という同じ不満である。

ただし、束になっていることは、この方向が正しいことの証明ではない。同じ不満を複数の研究者が抱えている、という以上のことをこの事実から読み取ってはいけない。なお本稿が扱う論文は、公開の場での投票や実装の追随がまだ立っていない段階にある。注目の数字は話題の大きさであって、正しさの目盛りではない。

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

規制下の業務では、成果物が正しいことと、正しく作られたことが別々に問われる。記録が残らない作り方でできた正しい成果物は、点検の対象として扱いにくい。資材の作成や審査の工程に操作エージェントを差し込もうとするとき、最初に詰まるのはここである。出力の当否だけを見る仕組みは、監査で問われる「どの手順を、どの順で、誰の判断で通したか」に答えられない。

工程単位の採点は、この問いに部分的に近づく形をしている。どの小目標まで進んだかという記録は、監査証跡の骨格と形が似ている。もっとも、研究の評価用に作られた記録と、規制で求められる記録は目的が違う。前者は改良の手がかりを取るためのもので、後者は責任の所在を示すためのものだ。似た形をしているからといって、そのまま持ち込めるわけではない。

実務として取り出せるのは、むしろ順序のほうだろう。エージェントを入れるかどうかを決める前に、その作業を小目標に書き下せるかを確かめる。書き下せない作業は、導入しても点検ができない。査読前の主張をそのまま信じる必要はないが、この順序は自前の業務でも試せる。