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

問題は、画面を見てパソコンを操作する AI が、一つひとつの操作は正しくこなせても、ソフトウェアを使う仕事を最後までやり遂げるところまでは届きにくいことである。こうした AI は「コンピュータ操作エージェント」と呼ばれ、人と同じようにボタンを押し、文字を入力し、画面を切り替えて作業を進める。

著者らは、個々の操作から複雑なソフトウェア作業へと規模を広げるには、判断と、作業全体の結果とを結びつけた「経験」が必要だと述べる[1]。ある場面でどのボタンを押したかという記録だけでは、その判断が最後に作業の成功につながったのかどうかが分からない。長い手順の途中の判断を、最終的な結果に照らして学べるだけの経験を、どう大量に用意するかが課題になる。

本記事が扱うのは arXiv に公開された技術報告で、査読前のプレプリントである。開発者自身が自分たちのシステムを説明した文書でもあるため、以下は著者らの主張と、著者らが報告した評価の範囲での結果として読む。

2. 何を提案しているか

芯は、課題を実行し、判断を記録し、結果を確かめ、確かめられた経験だけを学習に戻す、という循環を一つのシステムにまとめたことである。著者らはこの循環の供給側を「Experience Flywheel」、実行側を「NorthCUA Harness」と呼ぶ[1]。

Flywheel は、実行可能な多様な課題を Harness に渡す。Harness は長いやりとりを途切れずに続け、判断を記録し、課題の結果を確かめる。Flywheel はその記録から、結果が確かめられた操作の軌跡を選び出す。まだ解けていない課題については、再帰的自己改善によって使い回せる「スキル」を育て、確かめられた中間の到達点を保存し、次の試行がそれまでの進み具合の上に積み上がるようにするという[1]。

学習は段階を踏む。まず、こうした経験と、画面上の要素の位置を特定するためのデータを組み合わせ、途中段階の学習と、長い手順の教師あり微調整によって画面操作の力をつける。そのうえで、同じ Harness の中で新たに試行させ、デスクトップとウェブを合わせた強化学習で方針を改善する[1]。経験を作る側と方針を良くする側が、同じ実行環境でつながっている点が設計の中心である。

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

abstract が報告する結果は二つある。第一に、こうして作った Nano、Mini、Pro の三つの大きさのモデル群が、画面上の要素の特定、デスクトップでの作業の実行、ウェブでのやりとりの各分野で、オープンソースのモデルの中では最高水準の結果を得たという。著者らは、この結果に「報告した評価設定のもとで」という条件を付けている[1]。

第二に、反応の速さが求められるウェブ作業向けに、NorthCUA-Ultrafast を示した。これは強化学習の前段階の Nano を土台に、操作を直接選ぶ方式と自由な文章の生成を組み合わせたもので、品質と待ち時間の釣り合いを測定して示したとされる[1]。

読み取れないことも多い。abstract には、どのベンチマークで評価したのか、比べた相手がどのモデルか、差がどれほどかが書かれていない。「最高水準」は、オープンソースのモデルに限った比較であり、非公開のモデルを含めた順位ではない。Ultrafast の品質と待ち時間の関係も、どの程度の釣り合いなのかは abstract では分からない。

4. 具体例で見る

社内の文書管理システムで、承認済みの文書を所定の場所に登録し、台帳に記入し、関係者に通知する作業を、コンピュータ操作エージェントに任せる場面を考える。以下は説明のための仮定であり、論文の実験ではない。

操作の一つひとつで評価する

ファイルを選ぶ、登録ボタンを押す、台帳の欄に入力する、という各操作が正しかったかを確かめる。どの操作も正しく見えても、登録先の分類を一つ取り違えていれば、作業としては失敗している。途中で画面が固まって止まった場合、次の試行はまた最初からになる。

作業の結果と到達点で評価する

登録が正しい分類にされたか、台帳と登録内容が一致したか、通知が届いたかを最後に確かめ、確かめられた試行だけを学習に使う。登録までは確かめられたが台帳で止まった試行は、その到達点を保存し、次の試行は台帳の記入から始められる。

業務担当:「エージェントの作業記録には、何が残りますか」
システム担当:「各場面での判断と、課題の結果を確かめた記録です。確かめられた到達点も残ります」
業務担当:「その確かめ方は、誰が決めたものですか。社内の手順書の確認項目と同じですか」
システム担当:「そこは別です。仕組みが用意した確認なので、手順書の確認項目と一致しているかは、こちらで突き合わせる必要があります」

右の列は、NorthCUA の「判断を記録し、結果を確かめ、到達点を保存する」という設計を、業務の言葉に置き直したものである。ただし、ここで言う「確かめる」の中身を、abstract は説明していない。

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

実際の計算機環境でエージェントに作業をさせて評価する、という考え方は新しくない。OSWorld は、複数の OS の上で開かれた課題をエージェントに実行させる環境を示し、当時の最良のモデルでも成功できた課題は人に比べてわずかだったと報告していた[3]。操作の軌跡から学ぶこと、強化学習で方針を改善することも、それぞれ広く使われてきた手法である。NorthCUA の位置づけは、課題の供給、実行、記録、検証、学習を一つの循環として組み上げ、その規模を広げた点にあると読める。

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

この論文は束を作っていない。選定の記録では束の大きさは 1 で、立った系統は読者の票と実装の二つだった。Hugging Face の Daily Papers での upvote は 30、コメントは 1、GitHub のスターは 37 である。upvote やスターは研究者や実装者の目に留まったことを示す話題性の目安であって、内容が正しいこと、重要であることを示すものではない。

公開されたリポジトリは実在し、デスクトップとウェブ向けのエージェント実行環境のコードが Apache ライセンスで置かれている。リポジトリの説明によれば、モデルの重みはこのリポジトリには含まれず、Hugging Face で別に公開されている[2]。実装が手に取れる形で出ていることは、外部の検証が始まりうる条件ではあるが、検証が済んだことを意味しない。

主題の位置づけとしては、基盤モデルと、それを動かす実行環境（ハーネス）を組み合わせ、状態を持つ作業空間で検証可能な仕事をさせる「ワークエージェント」を一つの枠組みで整理したサーベイがある[4]。NorthCUA の、モデルとハーネスを同じ循環の中で一緒に育てる設計は、この流れに沿う一本と読める。ただし、これは選定で作られた束ではなく、本記事による位置づけである。

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

接続するのは、画面からしか操作できない既存のシステムと、作業の記録を残すという要請である。製薬の現場には、文書管理、安全性情報の管理、教育記録の管理など、決められた画面の手順で入力するシステムが多い。コンピュータ操作エージェントは、こうしたシステムに手を入れずに作業を自動化する手段として検討されうる。

NorthCUA の設計で目を引くのは、判断を記録し、結果を確かめ、確かめられた到達点を残すという点である[1]。これは、誰が、いつ、何を行い、それが確認されたかを残すという、規制下の作業記録の考え方と形が近い。ただし、学習のための記録と、規制上の記録は目的が違う。前者はモデルを良くするための材料であり、後者は第三者が後から作業の正しさを確かめるための証拠である。

この論文から立てられる確認項目は三つある。エージェントが行う「結果の確認」は、業務の手順書が定める確認と一致しているか。自己改善で育ったスキルが変わったとき、その変更を把握し、評価し直せるか。そしてエージェントの操作の記録は、学習用とは別に、改ざんされない形で保存されるか。この論文は製薬の業務を対象にしておらず、規制上の要件も検討していない。オープンソースで最高水準という報告から、規制下の業務に使えると判断することはできない。

操作が正しかったかではなく、作業が正しく終わったか。そしてその「正しく」を、誰の基準で確かめたのかを問う。