ハクソク

世界を動かす技術を、日本語で。

コンピュータの使用は構造化APIの45倍のコストがかかる

7時間前原文(reflex.dev)

概要

  • VisionエージェントとAPIエージェントによる管理パネル操作のコスト比較を実施
  • Visionエージェントはスクリーンショットとクリック操作、APIエージェントはHTTPエンドポイント呼び出し
  • Visionエージェントは明示的な手順指示なしではタスク完了不可
  • APIエージェントは一貫して高速・低コスト
  • API自動生成ツールの登場でAPI化の工数が大幅削減

VisionエージェントとAPIエージェントのベンチマーク比較

  • 目的：Webアプリを操作するAIエージェントのコスト構造の明確化
  • Visionエージェント：ブラウザ操作（スクリーンショット取得＋クリック実行）
  • APIエージェント：UIが呼び出すHTTPハンドラを直接叩く
  • 同一タスク：「Smith」という顧客の注文・レビュー管理操作
    • 顧客特定、注文検索、レビュー承認、注文完了処理
    • フィルタ、ページネーション、クロスエンティティ参照、読み書き操作
  • 比較条件：Claude Sonnetを利用し、データセット・タスクは同一
  • 唯一の変数：操作インターフェース（Vision or API）

Visionエージェントの課題と対応

  • 初回試行：Visionエージェントは1件のみレビュー承認し終了
    • ページネーション未対応：画面外レビューの存在を認識できず
    • モデル自体の限界ではなく、UIから得られる情報の限界
    • APIエージェントは全レビュー・注文情報を構造化データで取得
  • 明示的な14ステップ手順書を与えることでタスク完了
    • 14分間・50万トークン消費
    • 詳細な手順書作成自体が大きなコスト要因

実験結果の詳細

  • APIエージェント
    • 8回のAPIコールで一貫してタスク完了
    • トークン消費・処理時間ともに低く、ばらつきも小さい
  • Visionエージェント
    • 試行ごとに処理時間・トークン消費に大きなばらつき
      • 17分前後、40万〜75万トークン
      • スクリーンショット→推論→クリックの繰り返しで非決定性が高い
  • APIエージェントは常に同じ順序で処理、安定した結果

主要メトリクス比較

| メトリクス | Visionエージェント | APIエージェント (Sonnet) | APIエージェント (Haiku) | |--------------------|-------------------|--------------------------|-------------------------| | ステップ数 | 53 ± 13 | 8 ± 0 | 8 ± 0 | | 処理時間 | 1003s ± 254s | 19.7s ± 2.8s | 7.7s ± 0.5s | | 入力トークン数 | 550,976 ± 178,849 | 12,151 ± 279 | 9,478 ± 809 | | 出力トークン数 | 37,962 ± 10,850 | 934 ± 41 | 819 ± 52 |

  • VisionエージェントはAPIエージェントに比べて10倍以上のコスト

構造的なコスト差の理由

  • Visionエージェント
    • 画面レンダリング→画像推論→操作の繰り返し
    • 全中間状態を逐次画像で認識する必要
    • 1レンダリング＝数千トークン消費
  • APIエージェント
    • 構造化レスポンスを直接取得
    • 必要なデータを即座に取得・処理可能
  • モデルの精度向上は1ステップあたりのコスト低減には寄与
    • ステップ数自体はインターフェース仕様で決定

APIエンジニアリングコストの再評価

  • Reflex 0.9のプラグイン利用で
    • アプリケーションのイベントハンドラから自動でHTTPエンドポイント生成
    • API化の工数がほぼゼロに
  • VisionエージェントはAPI化できない外部SaaSやレガシーシステムで有効
  • 自社開発ツールではAPI化のコスト低下により、APIエージェントの方が圧倒的に有利

注意点・補足

  • Visionエージェントの結果はbrowser-use 0.12固有の挙動
  • APIエージェントは自動生成RESTエンドポイントを利用（30行程度）
  • データセットは小規模（顧客900件、注文600件、レビュー324件）
  • VisionエージェントはLangChain経由、APIエージェントはAnthropic SDK直利用
  • 全トークンカウントはキャッシュなしの生値

再現方法

  • リポジトリに
    • シードデータ生成スクリプト
    • パッチ済みreact-adminデモ
    • 両エージェントのスクリプトと生ログを同梱
    • 容易な再現性確保

Hackerたちの意見

今、まさにこの問題を解決するものを作ってるんだ。ランディングページではまだ宣伝してないけど、要するに、エージェントにアプリの表面を探索するための小さなツールセットを提供して、共通のmacOS機能、特にアクセシビリティに関連するAPIを用意してるんだ。エージェントはアプリを探索して、繰り返し使えるワークフローを書いて、そのワークフローをCLIで実行できるようにする。例えば、`invoke chrome pinTab`みたいにね。なんでアクセシビリティかっていうと、一般的に良いDOMだからなんだ。アプリの構造としてね。完璧に実装してるアプリは少ないけど、十分に役立つアプリはたくさんあるよ。 [1] https://getinvoke.com - 現在、ランディングページはクリエイター向けにターゲットされていて、このユースケースについてはまだ触れてないから注意してね。
└
これはいい解決策だね。みんなが同じコンピュータ作業を繰り返してトークンを無駄にするのではなく、ワークフローを共有する方法を考えた方がいいと思う。ユーザー情報（パスワード）を抽出するようなワークフローが共有されないようにする必要があると思うけど。
└
それ、ブレイルって呼んだらいいんじゃない？
└
エージェントが良いアクセシビリティを実現するために必要なら、それを受け入れるよ。文句は言うけど、受け入れる。
└
それってブラウザベースの基本的な機能じゃない？ブラウザを使う上で一番難しいのは、まずはステルス、その次がクライアントの変更管理、最後にブラウザの理解（これは新しいモデルが出るたびに良くなるけど）だと思う。
└
https://github.com/webmachinelearning/webmcp は重複してる？
完全に同意だね。最近AIのビジュアルツールを作ってて、両方のアプローチを試してみたんだけど、一般的な「エージェント的」なブラウザの使用は、リアルタイムの消費者向けアプリには致命的な遅延とコストがあるんだ。構造化されたAPI（厳密なJSONスキーマを持つ連鎖したLLMコールでも）は、40倍安いだけじゃなくて、実際に安定した製品を構築できるほど決定論的なんだ。コンピュータの使用は素晴らしいデモだけど、構造化されたAPIがサーバー代を払ってくれるんだよね。
└
「エージェント工学」なんて、トークン提供者の収益を増やすための流行に過ぎなかったよ。もしLLMが何かに役立つと思ったら、その目的のためにOpenrouterの上にしっかり定義された、非常に決定論的な「ミドルウェア」を作るよ。
コンピュータの使用？それともブラウザの使用？個人的には大きな違いだと思う。問題は、過去のすべてがAPIを通じてアクセスできるわけじゃないってこと。面白い時代だったよね - Prismを覚えてる？ [1] あれを実行して、すべてのAPIコールをいい感じのフォーマットで取得して、繰り返し再生していろいろなことを連続してやってたんだ。新しい世界ではOpenAPI.jsonなどにアクセスできるけど、OpenAPIや仕様、ベストプラクティスがなかった時代に作られたものの世界では…ちょっと自信がないな！(その時代に生きてた世界もたくさんあるし) 残念ながら、これは多くのことに対してはうまくいくけど、すべてには当てはまらないんだ。だから他の技術が存在するんだよね。 [1] https://stoplight.io/open-source/prism
ビジョンエージェントにUIを「マッピング」させて、別のエージェントにAPIに似たインターフェースのセットとして公開することは可能かな？今のビジョンエージェントは「次のページ」がもっと結果を表示することを知っていて、そもそももっと結果を得る必要があることも理解しているべきだと思う。もし一つのエージェントがUIを探索して、テスト環境でさまざまなUI要素とその動作の構造化された説明を出力したら、別のエージェントがその説明を与えられた場合、UIを探索しつつ与えられたタスクを同時に達成しようとするエージェントよりもパフォーマンスが良くなるのかな？例えば、私が考えたUIでは、説明（APIのようなインターフェース定義）はこんな感じになるかも：すべてのレビューを取得するには、各ページに行って、そのページのレビュー要約ごとに「完全なレビューを表示」をクリックする必要がある。各ページに行くには：ページ1から始める（レビュータブにいるときのデフォルト）。「次へ」ボタンをクリックして、「次へ」ボタンがもう利用できなくなるまで続ける（最後のページに達したから）。だから、2番目のエージェントはナビゲートの方法を考える必要がなくなるんだ、すでにそのスキルを持っているから。最初のエージェントは、テスト環境があれば心配せずに一度だけUIを探索できる。もしくは、この記事を完全に誤解しているのかな？多分そうだろうけど、面白いことには変わりないよ。意味がわからなかったらごめんね。
└
あなたの言う通りだと思う。エージェントに私たちがやること、つまりウェブサイトの動作を学ばせることができる。そしてそのモデルをシンプルなAPIとして公開する。ナビゲーションには視覚的なタスクがまだあるけど、それはただの視覚的なタスクで、考える必要はないよ。
現在、Claude Codeや他のAIエージェントをブロックしているウェブサイトは、負け戦をしてるね。コンピュータの使い方はまだ初期段階で、普及を妨げているのはトークンの数みたい。エージェントは、動かない10個のCLIコマンドを試してから正しいものを見つけるまで手間取るけど、私たちはほとんど気づかない。でも、他のビジュアルエージェント（ブラウザ利用やコンピュータ利用など）は結局正しいものにたどり着くけど、ボタンをクリックするのに20分待つのは我慢できないよね。トークンが安く早くなれば、UIインターフェースをCLIと同じくらい自然に使えるモデルが出てくると思う。
└
トークンが安くなる？それは違うと思うな… VCが資金を提供したトークンはユーザーベースを構築するためにあったし、成長から収益性に切り替わるとトークンの価格は上がるよ。
└
そして致命的なトリフェクタ、でも今のところはすべてのエージェントに当てはまるね。すべてのAIプロバイダーは、ブラウザ内でAIにPIIにアクセスさせることについて大きな警告を出してる。
└
> 大規模な普及を妨げているのは、必要なトークンの数みたいだね。途方もない費用や、生成された電気や使える水の無駄遣いを考えてみてよ。
テキストベースのウェブブラウジング？その比較が見てみたいな。たくさんのシステムにはDOM翻訳レイヤーがあるよね。私は、ウェブページをエージェントが直接使えるテキストに変換するというコンセプトで構築してる。実際、精度の問題ではなく、人間が何をしているのか追いかけられないくらいブラウザを速く操作するから、haikuから離れなきゃいけなかったんだ。ここでの本当の損失は、figmaやGoogleドキュメントのような特注のウェブアプリで、DOMを通して何をしているのか見るのがほぼ不可能なんだよね。私にとってブラウザは翻訳レイヤーなんだ。ブラウザを直接操作するのは難しいけど、互換性の大きな利点をもたらす。今のところ、やりたいことリストにあるのは、ブラウザ内の画像をテキストに変換するOCRなんだけど、APIがあればそれを実現する必要がある。純粋なAPIベースの最大の損失は、データをどこから得るかってこと。人間の作業を再現するには、それを見ないと無理だよね。人間はUIの中で作業してる、それだけなんだ。コンピュータの利用は、人間がやるエンドツーエンドのアクションを再現できるという約束だと思う。理論的にはAPIでそれができるけど、それを適切に集めるのはほぼ不可能なんだよね。
ここには、エージェントがあなたのウェブサイトをナビゲートするのを高くつけるための素晴らしいガイダンスが隠れてるね。マウスが動くときに画面上の要素を移動させたり、UIを機能させるために自然なマウスの動きを強制したり、毎回訪問するたびにJSでボタンのラベルをランダムに変更したり、隠れた追加タスクをチェックするために画面の一番下までスクロールさせたり… ちょっと待って、それって一般的な企業のSaaSアプリみたいだね。
そんなのありえないでしょ。場合によっては、コンピュータの使用の方が安上がりだと思う。まず、存在しないAPIについては、そもそも話にならない。次に、ほとんどのAPIはエージェント向けに設計されてなくて、無駄に長いし - DTO全体や不要なプロパティがたくさん返ってくるから、トークンを消費しちゃう。あと、コンピュータの使用は思ってるほどトークンを食わないよ - 一回のスクリーンショットが1000トークンくらいで、実際には競争力があって、APIのワークフローよりも優れてることが多い。
銀行みたいな機関がちゃんとしたAPIを提供してくれたらいいのにね。