AIのComputer Use機能は構造化APIより45倍高コスト

 (reflex.dev)
1 ポイント 投稿者 GN⁺ 2 시간 전 | 1件のコメント | WhatsAppで共有
  • 同じ管理パネル作業において、ビジョンエージェントはスクリーンショットとクリックでUIを操作し、APIエージェントは同じアプリケーションハンドラーを構造化レスポンスとして呼び出し、インターフェースだけをコスト差の変数にした
  • 基本プロンプトではAPIエージェントは8回の呼び出しで作業を終えたが、ビジョンエージェントは表示領域の下にあった保留中レビュー3件を見落とし、4件中1件しか承認しなかった
  • 14段階のUI walkthroughを追加するとビジョンエージェントも完了したが、実行には約14分と約50万入力トークンを要し、このような具体的な案内自体が別途エンジニアリングコストになる
  • 全体結果ではSonnet基準でビジョン経路は平均53ステップ、1003秒、550,976入力トークンを使い、API経路は8呼び出し、19.7秒、12,151入力トークンで完了し、コストと時間の変動性もはるかに小さかった
  • コスト格差はモデル性能よりもインターフェース構造から生じており、Reflex 0.9のようにイベントハンドラーからHTTPエンドポイントを自動生成できれば、自前の内部ツールでは構造化API経路の費用対効果が有利になる

ベンチマークの目的と実験構成

  • ビジョンエージェント方式と構造化API方式で同じ管理パネルを操作させ、ブラウザ利用・コンピュータ利用方式のコストを測定した
  • APIを提供しないWebアプリをAIエージェントが操作する場合、ビジョンエージェントがデフォルトの選択肢になりやすい
  • チームごとに20個以上の内部ツールがある状況では、アプリごとにMCPやRESTのインターフェースを作る作業は別個のエンジニアリングプロジェクトになるため、多くのチームがビジョンエージェントを選ぶ
  • テスト用アプリは顧客、注文、レビューを管理する管理パネルで、react-admin Posters Galore demoをモデルにしている
  • 2つのエージェントは同じ実行中アプリ、同じClaude Sonnet、同じ固定データセット、同じタスクを使い、インターフェースだけを変数にした
  • タスクは「Smith」という名前の顧客のうち注文数が最も多い顧客を見つけ、その顧客の最新の保留中注文を探したうえで、保留中レビューをすべて承認し、注文を配送完了にすること
  • このタスクは3つのリソースにまたがり、フィルタリング・ページネーション・エンティティ間の参照・読み取りと書き込みをすべて含み、一般的な内部ツール業務に近い

2つの実行経路

  • 経路A: Vision agent

    • Claude Sonnetがbrowser-use 0.12をビジョンモードで使い、UIをスクリーンショットとクリックで操作する

  • 経路B: API agent

    • Claude Sonnetがツール利用方式でアプリのHTTPエンドポイントを直接呼び出す
    • 各ツールはアプリStateの1つ以上のイベントハンドラーにマッピングされ、ボタンクリックが呼び出すのと同じ関数が使われる
    • エージェントはレンダリング済みページの代わりに構造化レスポンスを受け取る

ビジョンエージェントが基本プロンプトで失敗した理由

  • 2つのエージェントに同じ6文のタスクを与えて実行した
  • APIエージェントは8回の呼び出しでタスクを完了した
    • 保留状態でフィルタリングした顧客レビューを一覧する
    • 各レビューを承認する
    • 注文を配送完了にする
  • どちらのエージェントも同じアプリケーションロジックを呼び出すが、APIエージェントはレンダリング済みページを見る代わりに構造化レスポンスを直接読む
  • ビジョンエージェントは同じプロンプトで保留中レビュー4件のうち1件しか見つけて承認せず、そのまま次の段階へ進んだ
  • 残りのレビュー3件はレビュー画面の表示領域より下にあり、エージェントにはスクロールすべきだというシグナルがなかった
  • この失敗はモデルの推論の問題ではなく、レンダリング済みページが全体を見せていないことを示せなかったために起きた
  • APIエージェントはUIが呼び出すのと同じハンドラーを呼ぶが、レスポンスには現在レンダリングされている行だけでなく、ハンドラーが返した結果セット全体が含まれる
  • APIエージェントはピクセルからページネーションコントロールを解釈するのではなく、「50件表示の4ページ中1ページ目」のような情報を直接読む

14段階のUI案内を追加したときの結果

  • 公平な比較のため、ビジョンプロンプトを明示的なUI walkthroughとして書き直した
  • サイドバー項目、タブ、フォームフィールドなど、エージェントが各段階で操作すべきUI要素を名前で指定した
  • それまでエージェントが自力で見つけられなかったナビゲーション過程を、14個の番号付き指示として記述した
  • この案内を与えるとビジョンエージェントはタスクを完了した
  • ただし実行には14分かかり、約50万入力トークンを消費した
  • 各番号付き指示はトークン数には現れないが、実際のエンジニアリングコストを意味する
  • 内部ツールにビジョンエージェントを導入するには、このレベルの具体的なプロンプトを書くか、エージェントが静かに作業を取りこぼす可能性を受け入れる必要がある

実行方式と変動性

  • API経路は5回、ビジョン経路は3回実行した
  • ビジョン経路は1回の実行に14〜22分かかり、40万〜75万トークンを消費するため、3回に制限した
  • ビジョン経路は実行ごとのばらつきが大きかった
    • 3回の実行で実時間は749秒から1257秒まで開いた
    • 入力トークンは40.7万から75.1万まで開いた
    • 最短実行は43サイクル、最長実行は68サイクルかかった
  • スクリーンショット→推論→クリックの反復には十分な非決定性があり、単一実行だけでは代表的なコストを見積もりにくい
  • API経路にはこのような変動性がなかった
    • Sonnetは5回すべての実行で同じ8回のツール呼び出しを使った
    • 入力トークン数は全5回の実行で±27の範囲でしか変動しなかった
    • 構造化レスポンスがエージェントに逸脱する理由を与えないため、同じ順序で同じハンドラーを呼び出す

全体結果

指標 Vision agent (Sonnet) API (Sonnet) API (Haiku)
ステップ / 呼び出し 53 ± 13 8 ± 0 8 ± 0
実時間 1003秒 ± 254秒、約17分 19.7秒 ± 2.8秒 7.7秒 ± 0.5秒
入力トークン 550,976 ± 178,849 12,151 ± 27 9,478 ± 809
出力トークン 37,962 ± 10,850 934 ± 41 819 ± 52
  • 数値は平均 ± 標本標準偏差(n−1)で、API経路はn=5、ビジョン経路はn=3
  • 実行全体の詳細はリポジトリで確認できる
  • Haikuはビジョン経路を完了できなかった
  • 失敗はbrowser-use 0.12の構造化出力スキーマに限定され、Haikuはビジョンモードでもテキスト専用モードでもこれを安定して生成できなかった
  • API経路ではHaikuは8秒未満、1万入力トークン未満で完了し、テストした構成の中で最も安価だった

構造的なコスト格差

  • コスト差はアーキテクチャから直接生じる
  • 見てから行動するエージェントは、モデルが改善しても見るコストを常に支払う必要がある
  • より優れたビジョンモデルはスクリーンショットごとのエラー率を下げられても、関連データに到達するために必要なスクリーンショット数までは減らせない
  • 各レンダリングはスクリーンショットであり、スクリーンショットは数千入力トークンになる
  • 2つのエージェントは同じアプリケーションロジックを通る
    • どちらもUIと同じ方法でフィルタリング、ページネーション、更新を行う
    • 違いは各段階で何を読むかにある
  • ビジョンエージェントはピクセルを読み、あらゆる中間状態をレンダリングして解釈しなければならない
  • APIエージェントは同じハンドラーから得られる構造化レスポンスを読み、そのレスポンスにはUIが表示しようとしていたデータがすでに含まれている
  • より優れたモデルは段階ごとのコストを下げられても、段階数はインターフェースが決めるため減らせない

APIエンジニアリングコストが下がると変わる判断

  • このベンチマークはReflex 0.9のおかげで低コストに実行できた
  • Reflex 0.9には、ReflexアプリケーションのイベントハンドラーからHTTPエンドポイントを自動生成するプラグインが含まれている
  • 構造的な主張はReflexに依存しないが、ReflexによってAPI経路を別コードベースなしで実行可能にしている
  • APIインターフェースのエンジニアリングコストがゼロに近づくと、何が可能になるかが核心である
  • ビジョンエージェントは依然として、自分で制御していないアプリケーションに適している
    • サードパーティ製SaaS製品
    • レガシーシステム
    • 変更できないアプリケーション
  • 自前で構築する内部ツールでは、費用対効果の計算は逆方向に傾く

実験範囲と注意点

  • ビジョン結果はbrowser-use 0.12のビジョンモードに限定され、他のビジョンエージェントでは異なる挙動を示す可能性がある
  • 経路Bのランナーは、自動生成エンドポイントを約30行規模の小さなRESTツールインターフェースに加工した
  • エージェントはこれをlist_customers、update_orderのようなツールとして見る
  • データセットは固定されており小規模
    • 顧客900人
    • 注文600件
    • レビュー324件
  • 本番規模データでの挙動は測定していない
  • ビジョンエージェントはLangChainのChatAnthropicを通じて実行された
  • APIエージェントはAnthropic SDKを直接使って実行された
  • 報告されたトークン数はキャッシュされていない入力トークンである

再現資料

  • リポジトリにはシードデータ生成、パッチ適用済みreact-adminデモ、2つのエージェントスクリプト、生の結果が含まれる

関連記事

1件のコメント

 
GN⁺ 2 시간 전
Hacker Newsの意見

  • エージェントによるWebサイト閲覧を高コストにする方法がここに隠れている。マウスが動くたびに画面要素を移動させたり、自然なマウス移動を強制しないとUIが動かないようにしたり、アクセスのたびにJSでボタンラベルをランダムな名前に変えたり、隠れた追加作業を確認するために画面の一番下までスクロールさせればいい
    ちょっと待って、これってよくある企業向けSaaSアプリっぽい

    • 以前は信じていなかった人たちが、AIのせいで突然、優れたソフトウェアエンジニアリングの実践、とくに仕様書作成に熱心になっているのが妙だ
      人間のためにはこうしたことをやる気がなかったのに、AIが必要とすると皆が飛びつくのは、興味深い反面ちょっと憂うつでもある。結局、抽象的な未来の誰かよりも、自分たち個人に利益があると感じるからAIのためにだけやっているように見える
    • 要点は、人間がやりたくなるものにすることだ。[0]のように、インタラクティブ要素を動かし、状況に応じて環境と相互作用するようにできる
      [0] https://www.cs.unm.edu/~dlchao/papers/p152-chao.pdf
    • 結局のところ、ASP WebFormsこそ私たちがずっと必要としていた技術だったのかもしれない
    • 以前、あるデスクトップアプリが、すべてのグリッドコントロールの内容をWindowsアクセシビリティAPIから意図的に隠し、アクセシビリティAPI経由でチェックボックスやラジオボタンを選んでも反映されないようにし、データのエクスポート機能はすべてCAPTCHAで保護していたプロジェクトがあった
      生成AIが存在する以前の時代だったが、それでもアプリを動かしてデータをエクスポートするために、OCR、シミュレートしたユーザー入力、印刷キャプチャを組み合わせる必要があった。開発者たちが、画面キャプチャを防ぐWindows DRM APIや、PostScriptファイルから最小限の書式付きでテキストを簡単に復元できることを知っていたら、何をしていたかわからない
      皮肉なことに、これを置き換える前のプロセスは、安価な海外人材にシステム内の全データへの読み取り専用リモートアクセス権を与える方式で、信頼できるベンダーのローカルツールで承認済みの従業員がネットワークアクセスなしに業務を自動化するより、はるかに深刻なセキュリティリスクだった

  • まさにこの問題を解決するものを作っている[1]
    ランディングページではまだ前面に出していないが、本質的にはエージェントに、アプリの表面を探索するための小さなツールセットと、とくにアクセシビリティ関連の一般的なmacOS機能APIを提供している
    エージェントがアプリを探索したあと、繰り返し可能なワークフローを作成し、その後はCLIから invoke chrome pinTab のように実行できる
    アクセシビリティを使う理由は、結局それがアプリにとっての良いDOMだからだ。すべてのアプリが完璧に実装しているわけではないが、十分な数のアプリが実装しているので非常に有用だ
    [1] https://getinvoke.com - 現在のランディングページはクリエイター向けで、まだこのユースケースは扱っていない

    • エージェントのおかげで優れたアクセシビリティ(a11y) が確保されるなら受け入れられる。文句は言うだろうが、それでも受け入れる
    • macOSでこの分野に関心があるなら、システム標準のAccessibility Inspector.appを開いて、アプリやブラウザを直接触ってみることを強く勧める
      緑色のセルを見ると、LLMに画面の特定部分だけを読ませたりOCRさせたりするためにどう誘導できるか、アクセシビリティエンジンに既にどれほど多くのテキストが標準搭載されているか、そしてこれがMCPだけでなく、ワークフローのアクセシビリティ層をクロールするスクリプトを自分で作って実行するコードジェネレータにもつながり得ることがわかる
      これは非常に肥沃な領域だと思う。大手研究所は複数プラットフォームや任意のワークフローで動くアプローチを採らざるを得ず、全面的な画面ビジョンは最小公倍数になっている。プラットフォーム別のアプローチは本当に興味深いオープンスペースだ
    • 皆が同じコンピュータ操作タスクを繰り返してトークンを浪費する代わりに、ワークフロー共有の仕組みを作るのは良い解決策だ
      ただし、パスワードのようなユーザー情報を抜き出すワークフローが共有されないよう、必ず保証しなければならないだろう
    • 面白い。似たようなものを始めたことがあるが、完成度はずっと低く、かなり違うものの、同じくアクセシビリティUI要素を使っている
      大きな問題は、こうした要素の露出があまりに多くのアプリでひどいことだ。私のアプローチは、UIAccessまたはビジョンモデルの1回パスを使ってUIテンプレートを作る方法だった: https://github.com/willwade/app-automate?tab=readme-ov-file#...
      これに対するredditでの反論は、実体験はむしろ逆に近いというものだ。UIAは文書上は均一に見えるが、WPF、WinForms、Win32はいずれも異なるコントロールパターンを公開するため、結局はツールキットごとのハンドラを書くことになる。QtはQAccessibleがコンパイルされ、アクセシビリティプラグインが実行時にロードされないと何も公開しないが、配布バイナリではほとんどそうならない。ElectronはWindowsでもmacOSと同じくらい不透明で、結局は同じChromiumがキャンバスに描画しているからだ。本当の区別はOS対OSではなく、ネイティブツールキット対それ以外すべてだ

  • アプリごとにMCPやRESTの表面を作るのが別個のエンジニアリングプロジェクトだという話は、バックエンドがフロントエンドと十分に分離されていて、サーバー側の操作が慎重かつ汎用的に設計されていれば、必ずしもそうではない

  • ビジョンエージェントにUIを「マッピング」させ、それを別のエージェントにもっとAPIらしいインターフェース群として公開できるのか気になる
    現在のビジョンエージェントは、「次のページ」がより多くの結果を表示することと、そもそももっと多くの結果を取得すべきだということの両方を理解しなければならないと認識している
    あるエージェントがテスト環境のような場所でUIだけを探索して、複数のUI要素や動作についてある程度構造化された説明を作り、別のエージェントがその説明を受け取るなら、UI探索と課題遂行を同時に行うエージェントよりもうまくいくのではないかと思う
    例えば「すべてのレビューを取得する」は、各ページに行って各レビュー要約ごとに「全文レビューを見る」をクリックすること、といった具合で、「各ページに移動する」はレビュータブのデフォルトである1ページ目から始めて「次へ」ボタンが消えるまで押すこと、と定義できる
    そうすれば2番目のエージェントはすでにその技術を持っているので探索方法について考える負荷を減らせるし、1番目のエージェントはテスト環境でミスを心配せず一度だけUIを探索すればよい。記事を完全に読み違えているかもしれないが、それでも面白い

    • 同じことを先に考えた。最近のWeb開発はコード生成に大きく依存し、その上に難読化と圧縮を重ね、さらにその上でクライアントサイドJavaScriptがすべてを再構成する
      結局、複雑なHTML/CSS/JavaScriptをかき分ける必要がある。良し悪しは別として、1つのWebアプリが5～10MiBあるのも珍しくない
      ブラウザエンジンがしていることを事実上逆向きになぞるように「下から上へ」進むより、人間のように視覚表現を見て「上から下へ」進むほうが簡単そうだ
    • その通りだと思う。エージェントに、私たちがやるようにWebサイトの動作を学習させ、そのモデルを単純なAPIとして公開すればよい
      探索にはまだ多少のビジョン作業が残るだろうが、それは思考を必要としない単純なビジョン作業になるはずだ
    • ビジョンエージェントに「マッピング」を頼むのは難しいと思う。ほとんどのビジョンモデルは画像→テキストを行う際、一度に画像の一部分に集中する
      画像→画像では画像全体を使う

  • 前提がよくわからない。内部アプリなら、なぜコンピュータ操作を持ち出して、エージェントにCLIやMCPを作らせないのかがわからない
    当然ながらコンピュータ操作のほうが悪い。それは最後の手段だ。自分が所有するDB内の状態を扱うときに使うべきではない
    むしろ50倍しか悪くないのが印象的だ

  • 完全に同意する。最近AIビジュアルツールを作る中で両方のアプローチを試したが、汎用的な「エージェント風」ブラウザ利用のレイテンシとコストは、現時点のリアルタイム消費者向けアプリには致命的だ
    構造化API、さらには厳格なJSONスキーマを使ったLLM呼び出しチェーンだけでも40倍安いだけでなく、実際に安定した製品を出せるほど決定的だ。コンピュータ操作はクールなデモだが、サーバー費用を払ってくれるのは構造化APIだ

    • 「エージェント風エンジニアリング」は、トークン提供者の売上を増やすための流行にすぎなかった
      LLMが何かに向いていると思うなら、その目的に合わせてOpenrouter上に、よく定義され、非常に決定的なミドルウェアを作る

  • 構造化APIには本当の思考が必要だが、最近は考えることが好まれていない

  • 数か月前、kubectl に着想を得て、GUIアプリを制御するdesktopctl CLIを作った
    MacでOCRとAccessibility APIを組み合わせ、UIをMarkdownで表現し、マウスとキーボード操作を公開する
    中核となるアイデアは、「高速な」認識ループは完全にローカルでUIのトークン化と変更検出をGPU最適化し、「低速な」制御ループはLLMとの往復を必要とし、CLI出力にはトークン効率のよいMarkdownインターフェースを使うことだ
    コントロールには比較的安定した識別子を使うため、エージェントは desktopctl pointer click --id btn_save のような一般動作をスクリプト化でき、UIトークン化ループを必要としない
    https://github.com/yaroshevych/desktopctl/tree/main

    • APIと比べると、人間向けインターフェースは遅くて雑然としているが、その背後にもかなり多くの科学があることを学んだ
      優れたアプリは情報をうまく提示し、クリックやタイピングなどに最適化されている
      最高のGUIは筋肉記憶をうまく活用するので、CLIでスクリプト化する完璧な候補になる。例えば「Notesアプリを開く、Cmd+Fを押す、検索語を入力する、結果一覧を読む」といった単純なシーケンスは、AIエージェントが呼び出す1つのBashコマンドになり得る

  • 「コンピュータ使用」という概念全体にずっと懐疑的だ。誰かを雇って家に入れ、ベッドで寝て、トイレを使って、冷蔵庫の食べ物を食べて、テレビを見て、金庫の暗証番号もここにあると伝えるようなものだ
    しかも雇ったその誰かがサルなのだ

    • 自分がおかしいのかと思う。一つのソフトウェアが別のソフトウェアに問い合わせたり命令したりする方法を作る能力がなくて、AIにマウスをうろうろさせてあれこれクリックさせるのが本当に正しいのかと驚く
    • 公平に言えば、自分でやりたくないサル仕事をそのサルにやってほしいということだ

  • 現在Claude CodeやほかのAIエージェントをブロックしているWebサイトは、負け戦をしている
    コンピュータ使用はまだ初期段階で、普及を妨げているのは必要なトークン数に見える。エージェントが正しいコマンドを見つけるまでCLIコマンドを10個空振りしても、私たちはほとんど気にしない
    しかしブラウザ使用やコンピュータ使用のようなビジュアルエージェントでは、最終的に正しい場所にたどり着けたとしても、ボタン1つをクリックするのに20分待つ忍耐はない。トークンがもっと安く速くなれば、UIインターフェースをCLIと同じくらい自然に扱うモデルが出てくる可能性は高い

    • トークンがもっと安くなるとは思いにくい。ベンチャー資金で補助されたトークンはユーザーベースを作るためのもので、最終的に成長から収益性へ移行すればトークン価格は上がると思う
    • それに致命的な三重苦もある。少なくとも今のところ、すべてのAIプロバイダはブラウザ内でAIに個人情報へのアクセスを許すことについて強い警告を出している
    • 実際のところ、LLMプロバイダを止めることは誰にもできない。コンテンツをスキャンするために偽装リクエストを使い、ときには家庭用プロキシまで利用する
    • 100%効果的である必要はない。アカウント停止が怖くて試す気をなくす程度に脅せれば十分だ
    • 普及を妨げているのはトークン数よりも、莫大なコスト、増え続ける電力の浪費、そして利用可能な水の浪費に近い