ハクソク

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

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

2026年5月6日原文(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と同じくらい自然に使えるモデルが出てくると思う。

Hacker Newsで議論の続きを見る