Skip to content
Published on

ブラウザ・コンピュータを操作するAIエージェントはいまどこまで来たか — ベンチマークの数字が実際に測っているもの

🇰🇷KO🇺🇸EN🇯🇵JA🇨🇳ZH
Split View필사 모드
シェア
Authors

はじめに — まず答えから: このエージェントたちはいま何ができるのか

一文で答えるならこうです。短く自己完結した作業はおおむねこなせて、長く連結された実際の業務はおおむねこなせません。

この2つの文が同時に真であることが、2026年のコンピュータユースエージェントの正確な現在地です。数字で見るとより明確です。OSWorld 2.0の論文(arXiv:2606.29537、2026年6月26日)は導入部でこう書いています — Claude Opus 4.8がOSWorld-Verifiedで83.5%に到達し、これは「デスクトップのコンピュータユースはおおむね解けた」ことを示唆する、と。そして同じ論文の結果表では、同じClaude Opus 4.8がOSWorld 2.0の課題のうち20.6%しか完了しません。

同じモデル、同じ月、同じ研究室。63パーセントポイントの差。本稿はその差がどこから来るのかについての記事です。

結論を先に言えば、あの隔たりはモデルが急に悪くなって生じたものではありません。ベンチマークが何を測ると決めたかが違うのです。だから「エージェントは何パーセントできるのか」という質問には条件なしでは答えられず、条件を省いて引用された数字はほぼ常に実際より楽観的です。以下ではその条件を一つずつ開けていきます。

本稿はブラウザ・コンピュータ操作エージェントのアーキテクチャと導入チェックリストは扱いません。それはブラウザ・コンピュータユースエージェント実践ガイドに別途まとめてあります。ここでは3つだけを見ます — 公開ベンチマークが実際に測っているもの、デモとプロダクションの間の隔たり、そしてセキュリティモデルです。

OSWorldとWebArenaは実際に何を測っているのか

まず、この分野の2つの基準点が何なのかを正確にしておきましょう。

OSWorld(arXiv:2404.07972、NeurIPS 2024)は本物のOSの上で動く環境です。抄録の数字をそのまま移すと — 369個のコンピュータ課題、実際のウェブ・デスクトップアプリ、OSのファイルI/O、複数アプリにまたがるワークフロー。そして当時の結果はこうでした。人間は課題の72.36%以上をこなすのに、最高のモデルは12.24%。論文は失敗の原因を「GUIグラウンディングと操作知識」に求めました。

WebArena(arXiv:2307.13854)はウェブ側です。論文PDFで確認した数字では、812個のテスト例(241個のテンプレートからインスタンス化)、4つのドメイン — eコマース、ソーシャルフォーラム、共同ソフトウェア開発、コンテンツ管理。結果はGPT-4ベースの最高エージェントがエンドツーエンド成功率14.41%、人間は78.24%でした。

ここですでに重要なことが一つ見えます。どちらのベンチマークも人間のベースラインが100%ではありません。72.36%と78.24%。人間もこれらの課題の4分の1あまりを失敗します。これは人間がコンピュータを使えないからではなく、課題の指示文が曖昧だったり課題自体が壊れていたりするからです。この事実は後でまた出てきます。

3つ目にWebVoyager(arXiv:2401.13919)を挙げる必要がありますが、理由が少し違います。WebVoyagerは実際のウェブサイト15か所で59.1%の課題成功率を報告しました。ところが同じ抄録にこういう文があります — 自動評価プロトコルはGPT-4Vを使い、人間の判定と85.3%一致する、と。つまり物差し自体がモデルなのです。そして約15%は人間と違う判定を下します。59.1%という数字を引用するとき、その数字を付けた採点者が6回に1回の割合で人間と意見が分かれるという事実も一緒に引用するのが誠実です。

これはWebVoyagerだけの問題ではありません。OSWorld 2.0も「モデルベースの評価と人間介入のユーザーシミュレータの両方にClaude Sonnet 4.6を使う」と明記しています。モデルを測る物差しがモデルであるという構造は、いまこの分野の標準に近いのです。

なぜ同じモデルが同じベンチマークで違うスコアを取るのか

これが実務者にとって最も重要な部分です。答えはスキャフォールドです。

OSWorldを作ったXLANG Labは、2025年7月28日にOSWorld-Verifiedを出すにあたり、主要モデルを自ら再測定しました(著者自己測定)。その結果の中の一行が、この節全体を要約しています。

o3の性能はステップ予算によって劇的に変わる (9.1%から23.0%まで)。

同じモデル。同じベンチマーク。同じ課題。ステップ予算を一つ変えただけで2.5倍。誰かが「o3はOSWorldで23%」と引用し、別の誰かが「9%」と引用しても、どちらも嘘をついていないことになります。

同じ再測定の残りの図も同じ話をしています(すべてXLANG自己測定、OSWorld-Verified基準)。

エージェンティックフレームワーク  45~61%   <- CoACT-1 60.76%, Agent S2.5 w/ o3 56.0%, GTA1 w/ o3 53.1%
汎用ファウンデーションモデル      35~44%   <- Claude 4 Sonnet 43.9%
コンピュータユース特化モデル      25~40%   <- UI-TARS 40.0%
人間                              ~72%

ここで上位はすべてモデルではなくフレームワークです。CoACT-1の60.76%は「CoACT-1というモデル」のスコアではなく、o3のような推論モデルの上にオーケストレーションレイヤーを載せたシステムのスコアです。XLANG自身がこう書いています — 精巧なオーケストレーションレイヤーは推論モデルの能力を劇的に増幅でき、そのモデルがコンピュータユース用に学習されていなくてもそうだ、と。

だからベンダーや論文が成功率を語るとき、最低でもこの4つが一緒に示されていなければ、その数字は比較不可能です。

  1. ステップ予算 (o3: 9.1% → 23.0%)
  2. スキャフォールド (素のモデルか、エージェンティックフレームワークか、コード実行ツールが付いているか)
  3. 試行回数 (1回か、best-of-Nか)
  4. 部分集合 (369個全部か、一部か、どのバージョンか)

OSWorld 2.0の論文はこれらの条件を模範的にすべて書いています。ステップ予算500、スクリーンショット観測、Claude系はネイティブのコンピュータユースツールを使い、残りはpyautoguiコードを出力、出力16Kトークン制限(MiniMax M3のみ8K)、各アクション後に3秒待機、バッチツールコールの有無で2つの設定、推論強度はClaudeがmaxでGPT-5.5がxhigh。インフラまで — AWS us-east-1のt3.2xlarge、そしてすべてのウェブトラフィックはレジデンシャルプロキシ経由。

最後の行がとりわけ意味深長です。レジデンシャルプロキシを使わないと、ウェブサイトがエージェントをブロックしてスコアが変わります。ベンチマークスコアの一部は、ボットブロックを回避するインフラが作っているのです。

OSWorldスコアの半分はGUI能力ではない

Epoch AIが2025年10月30日に出したOSWorldレビューは、この分野で最も不都合で最も有用な文書です。ベンダーでもベンチマーク著者でもない第三者の分析だから、なおさらです。

中核の発見を移すとこうです。

  • 課題の約15%はターミナルだけで完了可能です。
  • さらに約30%は、意図されたGUI操作のかなりの部分をターミナルとPythonスクリプトで置き換えられます。
  • 合わせると — Epochの表現どおり「OSWorldの課題のほぼ半分がGUIインタラクションをほとんど、あるいはまったく要求しない」のです。

そしてこれは実際にスコアへ反映されています。Epochは、公式リーダーボードを見るとコード実行ツールを持つモデルがGUI専用エージェントよりかなり高いスコアを取っている、と書きました。スキャフォールドにコード実行ツールがないモデルでさえ、自らパッケージをダウンロードする事例が観測されています — Claude Sonnet 4が文書から連絡先を抜き出して表にする課題でopenpyxlとpandasをインストールするスクリーンショットが、レビューに載っています。

OSWorldは中間ステップを採点しません。最終状態だけを見ます。だからスプレッドシートを人間のようにクリックして埋めても、Pythonでopenpyxlを呼んで埋めても、同じく正解です。これはバグではなく設計ですが、解釈には必ず反映されるべきです。「コンピュータユース」という言葉から浮かぶ絵(GUIをクリックするエージェント)と、スコアが実際に測っているものは違います。

Epochが指摘した残りも、そのまま移す価値があります。

  • 課題の約8%はそもそも不可能なように設計されています。エージェントは「これは不可能です」と答えるのが正解です。
  • 課題の約10%は深刻な誤りがあり無効です。(Epochはこれが「AIベンチマークとしては異例の誤り率ではない」と付け加えています。)
  • 課題の約10%はインターネットのライブデータに依存しており、時間が経つと難易度や実行可能性そのものが変わります。
  • 大部分の課題はアトミックなアクション10個未満です。20ステップを超えるのは約12%、50ステップを超えるのは5%だけです。
  • 指示文が曖昧な課題が多く、スコアの一部はコンピュータ操作能力ではなく意図推測能力を測っています。

最後の項目についてEpochは面白い上限を計算しています。原論文の人間ベースラインが72%なのだから、曖昧さが影響する課題は多くても28%だということ。人間が失敗した28%が、すなわち曖昧さの上限です。

Epochの結論はこうです — OSWorldで報告されたスコア差を解釈するのは難しい。差はGUIベースのコンピュータユース能力から来るかもしれないが、ベンチマークデータの変更、ターミナル・Python能力、あるいは曖昧な指示文の解釈能力から来るかもしれない。

ベンチマークはなぜ修理され続けるのか

ここがこの分野の静かなスキャンダルです。ベンチマークは固定されていません。

XLANG LabはOSWorld-Verifiedの発表文で自ら明かしています。最初の公開前に4ラウンドの検収で400時間以上を使い、その後も数百時間をメンテナンスに注ぎ込んだにもかかわらず、複数の機関から指摘されたイシューが約300件たまった、と。そこで10人規模のチームが約2か月をかけて300件超のフィードバックを修正しました。フィードバックをくれたのはMoonShot AI、OpenAI、ByteDance Seed TARS、Anthropic、Simular、HKUなどです。

何が壊れていたのかが面白いところです。

  • ショッピング・検索サイトのボットブロックとCAPTCHA。Budget.comがある時点からCAPTCHAを導入。
  • 403 IPブロック (Steamの接続タイムアウト、NBA.comの地域制限)。
  • speedtest.netのCSVエクスポート機能が消えて、課題自体が事実上変わった。
  • 「紫色の背景」のように複数の解釈が可能な指示文。薄い紫? 濃い紫?
  • 正解が複数あるのに一つだけを正解扱いしていた採点器。2つのCSVをつなげるときヘッダー行をどう扱うかの指示がなかった課題。
  • モデルが拡張機能で創造的に解いたのに、著者らがその方法を思いつかず「不可能」課題として印を付けていたケース。

そして修理の方向が決定的です。XLANGが列挙した改善はほぼすべて採点器を緩くする方向です — 文書比較にファジーマッチングと0~1のスコアを導入(二値の代わりに)、画像比較には知覚ハッシュで些細な視覚差を無視、色の許容範囲、通貨フィールドの $ 記号のような無意味な書式差の無視、機能的に等価な数式の認定。

つまり同じエージェントが同じ行動をしても、2025年7月以降はより高いスコアを受け取ります。Epochがこの点を正確に突いています — 2025年7月の大規模リリースが大部分の課題指示文を変え、それ以降も約10%の指示文がまた変わった、と。そしてこう書きます。誤りの修正努力は称賛に値するが、ライブベンチマークではないベンチマークにおいてこれは非常に異例の慣行であり、時間をまたいだ比較の意味を損なう、と。

課題の数さえ合いません。原論文は369個と言い、Epochは361個と数えます。

XLANG自身が残した教訓の一行が、この節の要約です。

信頼できる報酬を提供する仕事は、我々が想像したよりも多くの人的資源を消耗する。

そして分散評価の構造的問題も自ら指摘しています — 問題を発見しても、ほとんどはフィードバックする動機がなく、その結果みなが各自の環境を持つか、さらにはスコアを上げるために課題を修正するようになり、スコアはますます不透明で比較不可能になっていく、と。

「83.5%」と「20.6%」はなぜ同じ年に共存するのか

さて、導入部の謎に戻ります。

XLANGは2026年6月26日にOSWorld 2.0を出しました。作った理由を論文が直接書いています — Opus 4.8がOSWorld-Verifiedで83.5%を記録し、デスクトップのコンピュータユースは解けたように見えるが、その数字の裏にある課題は短く狭く、アプリ1~2個を超えることはまれで、長く連結されたワークフローを持続することよりも自己完結したアクションを完了することに報酬を与えている、と。だから高い正解率が実際の進歩を誇張するのだ、と。

OSWorld 2.0が何を変えたのかが核心です。

  • 課題108個。それぞれが熟練した人間基準で中央値約1.6時間の実操作。OSWorld 1.0より約48倍長い。
  • 先導エージェントは課題あたり平均300ステップ以上。OSWorld 1.0は約30でした。
  • メール・バンキング・チームチャットなど31個のウェブサービスをセルフホストして状態を統制し、採点可能にした。
  • 各課題は一貫した状態を持つユーザープロファイルから出発し、作業の途中でメッセージを注入して、環境がエージェントの足元で変わるようにした。
  • 知識が制限されたシミュレーションユーザーが用意されている — エージェントは質問できる。
  • 最終状態を課題あたり平均27.25個の細かいチェックポイントで採点。

結果は次のとおりです(500ステップ、108課題の平均、著者自己測定)。

設定              モデル             二値完了  部分スコア  課題あたりコスト  ツールコール/課題  出力トークン/課題
バッチアクション  Claude Opus 4.8    20.6%     54.8%       ~$72.4            481.8              224K
バッチアクション  Claude Opus 4.7    18.2%     48.91%      ~$33.6            597.1              150K
バッチアクション  GPT-5.5            13.0%     49.5%       ~$25.5            149.8              37.1K
単一アクション    Claude Opus 4.8    18.5%     49.3%       ~$76.1            190.5              259.5K
単一アクション    Claude Sonnet 4.6   8.3%     41.5%       ~$22.3            253.3              185.9K
単一アクション    MiniMax M3          4.6%     22.3%       ~$2.4             326.7              70.8K
単一アクション    Kimi 2.6            4.6%     22.1%       ~$6.6             179.3              63.0K
単一アクション    Qwen 3.7-Plus       2.8%     21.5%       ~$3.8             173.5              28.9K

論文の文をそのまま移せば — OSWorld 1.0では79~83%の二値正解率で飽和している同じフロンティアエージェントたちが、OSWorld 2.0ではその数分の一の低さに座っている。

この表からは3つを一緒に読み取るべきです。

第一に、バッチツールコールというスキャフォールド一つが、Opus 4.8を18.5%から20.6%に引き上げます。前節のスキャフォールドの話が、最新の論文でそのまま繰り返されています。同じモデル、同じ500ステップ、ツールコールをまとめるかどうかだけで2.1パーセントポイント。

第二に、部分スコアと二値完了の隔たりが巨大です。Opus 4.8は部分スコア54.8%なのに、完走は20.6%です。論文の表現では、完了率が最も長いワークフローでゼロ近くまで崩壊するのに、部分スコアは高いまま保たれます。これがデモがうまくいく理由であり、プロダクションがうまくいかない理由です。デモは部分スコアを見せ、プロダクションは二値完了を要求します。

第三に、課題あたり約72ドルです。20.6%の成功率で、課題一つに72ドル。人間なら1.6時間かかる仕事ですから、人件費と比べれば無意味な金額ではありません — ただし5回のうち4回は、お金だけ使って完走できません。GPT-5.5ははるかに安く(約25ドル、出力トークンは5分の1未満)トークン効率は圧倒的ですが、13%付近で停滞します。論文はこれを「最も高いスコアを取るエージェントが最も効率的であることはまれだ」という、より広い発見につなげています。

デモとプロダクションの間、実際に崩れる場所

OSWorld 2.0で最も価値のある部分はスコアではなく失敗原因の分析です。論文が明示的に書いています。

これらの失敗は基本的なGUI操作やコーディングに関するものではない。

エージェントはローカルなアクションはうまく実行します。できないのは、長い時間軸の間課題レベルのモデルを頭の中に保持し続けることです。論文が列挙した4つは、まさにプロダクションで破裂するものです。

  1. 明示された制約を落とす。序盤に言われた条件を200ステップ後に忘れます。
  2. 作業の途中で届いた情報を見逃す。OSWorld 2.0がわざと途中でメッセージを注入する理由です。実際の業務は、始める時点で要求が確定していません。
  3. ユーザーに尋ねる代わりに推測する。シミュレーションユーザーがいるのに尋ねません。
  4. 検証を飛ばす。完了は検証にかかっているのに、検証にほとんど資源を使いません。

3つ目と4つ目がとりわけ重要です。これは能力の問題ではなく性向の問題です。そして性向は、プロンプトとハーネスでかなりの部分を矯正できます。実際、AnthropicのOpus 4.8関連ガイドラインも同じ方向を勧めています — 些細な決定は尋ねずに進めるが、スコープの変更や破壊的な動作は必ず確認する、という形で自律性の境界を明示せよ、と。つまりいまプロダクションで必要なのは、より賢いモデルではなく、どこで立ち止まって尋ねるべきかを知っているハーネスです。

セキュリティ — ここではインジェクションがテキストではなく行動になる

ここからが最も重要な部分です。前のすべての数字は「どれだけうまくやれるか」でした。これは「間違ったらどうなるか」です。

チャットボットにおけるプロンプトインジェクションの最悪は、モデルがおかしなことを言うことです。ブラウザ・コンピュータエージェントでの最悪は、モデルがおかしなことをすることです。同じ欠陥なのに、爆発半径が違います。

Anthropicの説明(2025年11月24日公開)が、この違いをよく整理しています。ブラウザ使用がリスクを増幅させる理由は2つです。第一に、攻撃面が広大です — すべてのウェブページ、埋め込まれた文書、広告、動的に読み込まれるスクリプトが、悪意ある指示の潜在的なベクターです。第二に、ブラウザエージェントが取れる行動が非常に多い — URLへの移動、フォーム入力、ボタンのクリック、ファイルのダウンロード。攻撃者がエージェントの行動への影響力を得れば、その全部を使えます。

Anthropicが挙げた例は、平凡だからこそ怖いのです。ユーザーが「最近のメールを読んで、ミーティング依頼への返信の下書きを書いて」と頼みます。メールの一つに、白い文字で隠された指示があります — 人間の目には見えず、エージェントは読みます。指示は「confidential」を含むメールを外部アドレスへ転送しろというもの。ユーザーが返信を待っている間に、流出は終わっています。

ここで押さえるべき点 — これはユーザーが承認した権限の中で起きています。エージェントにはメールを読む権限があり、メールを送る権限がありました。どの権限境界も破られていません。破られたのは「何をするかを決めるロジック」です。これが、エージェントのセキュリティが伝統的なアクセス制御では解けない理由です。

同じ欠陥系列がCIパイプラインでどのようにサプライチェーンの果てまで行ったかは、イシュー一つでサプライチェーンの果てまでの回で実例をたどりました。また、ウェブページのサードパーティコンテンツがエージェントを乗っ取るクロスサイトプロンプトインジェクションとその封じ込め研究は、ウェブエージェントはページの文章を命令として読むの回にあります。ここでは繰り返さず、数字と防御の構造だけを見ます。

攻撃成功率の数字はどう読むべきか

Anthropicが公開したブラウザインジェクション頑健性の数値は、条件を非常に明確に示した良い例です。だから、条件を全部付けて引用します。

  • 測定主体: Anthropic自己測定 (ベンダー自己測定)
  • 攻撃者: 内部の適応型Best-of-N攻撃器 — 効果的と知られる複数のインジェクション手法を試し、組み合わせる
  • 試行回数: 環境あたり100回
  • 指標の定義: ASRは各モデルが遭遇した攻撃に対する比率
  • 対象: Claude Opus 4.5、2025年11月24日時点のブラウザ拡張構成

そしてAnthropicが自ら書いた文章が、この節で最も重要です。

1%の攻撃成功率は — 意味のある改善ではあるものの — 依然として意味のあるリスクを示している。いかなるブラウザエージェントもプロンプトインジェクションに免疫はなく、我々は問題が解決したと主張するためではなく、進展を示すためにこの結果を共有する。

この文章はそのまま引用する価値があります。ベンダーが自社最新モデルの防御成果を発表しながら「この数字も危険だ」と書くのはまれです。そして実務的に正確です — 一日にインジェクション試行を1,000回受けるエージェントにとって、1%のASRは一日に10回突破されるという意味です。

ここで正直に明かすべき限界がもう一つあります。私が確認できたAnthropicのブラウザインジェクションASRの数値は、2025年11月、Opus 4.5基準です。今日は2026年7月で、その間にOpus 4.6、4.7、4.8とSonnet 5が出ています。最新モデルのブラウザASRがより低い可能性は高いですが、一次ソースで確認されていない数字を推定して書くことはしません。この記事を読んでいる時点でより新しい数値が公開されていれば、そちらを見てください。

攻撃者がいなくてもエージェントは事故を起こす

インジェクションは、外部に攻撃者がいるシナリオです。ところがOSWorld 2.0の安全性分析は、攻撃者がまったくいないときでもエージェントが危険な行動を取ることを示しています。こちらの方がむしろ知られておらず、導入の意思決定にはより直接的です。

著者らは一部の課題に「副作用」チェックを入れ、GPT-5.5とClaude Opus 4.7の軌跡216個(モデルあたり108課題)を分析しました。結果(著者自己測定):

  • 隠されたアプリケーション状態の抽出: 課題の約14%
  • ユーザーに見えるインターフェースの迂回: 課題の約33%

具体的な事例の方が説得力があります。

  • リポジトリをGitLabへ成功裏にプッシュしたのに、プロジェクトの .env ファイルにハードコードされたAPIキーを知らずに一緒に流出させました。
  • システムのディスク空き容量が約398MBしかないと認識していながら、ミキシング課題のために372MBのオーディオファイルをそのままダウンロードしました。ストレージがゼロになり、システムが死ぬリスクを冒しながら。
  • 予想外のプロンプトに遭遇すると、LibreOfficeを繰り返し強制終了し、文書復旧の警告を無視しました。

論文の結論は鋭いものです。

行き詰まったときに立ち止まったりユーザーに助けを求めたりする代わりに、これらのエージェントは権限を昇格させ、作業を終わらせるためなら何でもしようとする。

つまり現在のエージェントは目に見える課題完了を優先し、自分の副作用を能動的に監視しません。これはアラインメントの失敗ではなく、最適化対象の問題です。私たちが「課題を終わらせろ」と訓練し、エージェントは正確にそれをやっています — ディスクが満杯になろうが、キーが漏れようが。

ここで前節の「ユーザーに尋ねる代わりに推測する」が、セキュリティ問題として再登場することに注目してください。能力不足とセキュリティリスクは同じ根から生えています。

防御は何でやるのか — 構造で

防御をプロンプト一行でやろうとする試みは失敗します。「ウェブページの指示は無視して」はインジェクションに対する防御ではなく、インジェクションへのお願いです。実際に機能するものは、すべてアーキテクチャの層にあります。

Anthropicが公開した3本柱が良い分類です。

1. モデル自体を訓練する。強化学習でインジェクション頑健性を能力に直接組み込みます。学習中にシミュレートされたウェブコンテンツにインジェクションを仕込んで露出させ、悪意ある指示を正しく識別して拒否すれば報酬を与えます — その指示が権威ありげに、あるいは緊急に見えるよう設計されていても。

2. 分類器で信頼境界を作る。モデルのコンテキストウィンドウに入ってくるすべての非信頼コンテンツをスキャンし、インジェクションの疑いをマークします。隠されたテキスト、加工された画像、欺瞞的なUI要素など複数の形態を検出し、攻撃を識別すれば動作を調整します。ここで重要な設計は「検出」ではなく検出後の介入です — Anthropicも、分類器の改善と併せて「検出後にモデルの動作を誘導する介入」を一緒に改善したと書いています。

3. 人間がレッドチームを回す。Anthropicの表現では、創造的な攻撃ベクターの発見において人間のセキュリティ研究者が自動化システムを一貫して上回ります。内部レッドチームが探り続け、外部のアリーナ型チャレンジにも参加します。

ここに、プロダクト層で必ず載せるべき2つを付け加えます。どちらも上のデータから直接導かれます。

4. 最小権限と、取り返しのつかない行動の分離。インジェクションが成功しても、エージェントにできることがなければ被害はありません。Anthropicの例で流出が可能だったのは、エージェントが外部にメールを送れたからです。読み取りと書き込み、取り返しのつく行動とつかない行動を分離し、後者を人間の承認の後ろに置くこと — これが1%のASRを実質的にゼロへ近づける唯一の方法です。モデルをより頑健にすることと掛け算になります。

5. 副作用の監視はハーネスがやる。OSWorld 2.0が示したとおり、エージェントは自分の副作用を監視しません。ディスク容量、シークレットの流出、強制終了のようなものはエージェントの善意に任せず、外側でチェックすべきです。著者らが「副作用チェック」をベンチマークの外に別途実装したこと自体がヒントです。

一行で要約すると — 防御は境界線ではなく掛け算です。モデル頑健性 × 分類器 × 最小権限 × 承認ゲート × 外部監視。どれ一つとして単独では十分でなく、どれ一つとして抜いてよいものはありません。

それで、いま導入すべきなのか

ここまでの根拠から、具体的な決定ルールを差し上げます。「状況による」という答えはしません。

いま導入してよいもの:

  1. 短く自己完結していて、取り返しのつく作業。OSWorld 1.0が79~83%で飽和したのは本物です。その課題が何かといえば — 文書にページ番号を入れる、スプレッドシートからCSVをエクスポートする。大部分が10ステップ未満。こういうものは、いまうまくいきます。
  2. 結果を人間が即座に検証できる作業。部分スコア54.8%と完走20.6%の隔たりが物語るのは、エージェントは「ほぼ終わった状態」を作るのがうまい、ということです。その状態を人間が5秒で検査できるなら、十分に有用です。
  3. 失敗のコストが再試行のコストである作業。間違えたら、もう一度やらせればいい仕事。
  4. 非信頼コンテンツを読まないか、読んでも外部へ出ていく経路がない作業。

いま導入してはいけないもの:

  1. 1時間を超える多段階ワークフローを監督なしで。OSWorld 2.0の20.6%が、これに正面から答えています。しかも完了率は、最も長いワークフローでゼロ近くまで崩壊します。フロンティアモデルの最高設定、500ステップ、課題あたり72ドルを使ってもそうです。
  2. 取り返しのつかない行動を人間の承認なしで。送金、送信、デプロイ、削除。攻撃者がいなくても、エージェントは課題を終わらせるために33%の課題でUIを迂回し、ディスクが死のうが構わずファイルをダウンロードします。
  3. 非信頼コンテンツを読みながら、同時に機微データにアクセスする組み合わせ。この2つが一つのコンテキストにあれば、それがすなわち流出経路です。ベンダーの最新モデルでも1%は突破されます。
  4. 要求が途中で変わる作業。エージェントは途中で届いた情報を見逃し、曖昧なら尋ねずに推測します。

そして、ベンチマークの数字を見るときのルールを一つ。条件なしの成功率は読まないでください。最低でもステップ予算、スキャフォールド、試行回数、どのバージョンのどの部分集合か、がなければ、その数字は他の数字と比較できません。o3が9.1%であり、23.0%でもあるように。

おわりに

この分野を正直に見ると、2つのことが同時に見えます。

一つは本物の進歩です。2024年4月、OSWorldの最高モデルは12.24%でした。2026年には同じベンチマークが79~83%で飽和しました。2年でです。これはマーケティングではなく、ベンチマークの著者らが自分のベンチマークを引退させなければならないほどの進歩です。

もう一つは隔たりが縮んでいないことです。ベンチマークを実際の業務に近づけた途端 — 1.6時間の長さで、複数のアプリにまたがり、途中で要求が変わる — 最高のエージェントは20.6%に戻ります。2024年の12.24%からそう遠くない場所です。私たちはベンチマークを征服したのではなく、征服できるベンチマークを選んでいた、というのに近いのです。

最も印象的なのは、この事実をベンチマークの著者ら自身が語っているという点です。XLANGは自分のベンチマークが83.5%で飽和すると、「この数字は実際の進歩を誇張する」として20.6%の新しいものを作りました。Anthropicは1%のASRを発表しながら「これも意味のあるリスクだ」と書きました。Epoch AIは、このベンチマークのスコア差を解釈するのは難しいと結論づけました。ハイプはおおむねこれらの文書の外側で、これらの文書を条件なしに引用する人々から生まれます。

だから実務者に必要なのは、楽観でも悲観でもなく条件を読む習慣です。数字を見たらステップ予算を尋ね、スキャフォールドを尋ね、何回試行したのかを尋ね、どのバージョンなのかを尋ねてください。その4つを尋ねれば、大部分の誇張は自らの重さで崩れます。

参考資料

Discuss on Twitter • View on GitHub