AIの「Computer Use」は構造化APIより45倍も高い？知っておくべきコストの現実

最新のAIモデルがPC画面を操作する「Computer Use」機能ですが、実は構造化APIを利用する場合と比べてコストが45倍も跳ね上がる可能性があることが分かりました。便利さと引き換えに支払う「代償」について、エンジニアとして冷静に見極める必要があります。

まさにその問題を解決するためのものを作ってるんだ[1]。まだランディングページでは宣伝してないけど、基本的にはアプリの画面構成を探索するためのツールセットと、macOSの一般的な機能（特にアクセシビリティ関連）を操作できるAPIをエージェントに提供してる。エージェントがアプリを探索して、繰り返し可能なワークフローを書き出すんだ。あとはCLI経由でinvoke chrome pinTabみたいにそのワークフローを実行できる。なぜアクセシビリティかって？結局、それがアプリの構造を記述するのにちょうどいいDOMみたいな役割を果たしてくれるからだよ。完璧に実装されてないアプリも多いけど、実用性には十分すぎるほどなんだ。[1] https://getinvoke.com - 注意点として、ランディングページは今のところクリエイター向けで、このユースケースについてはまだ触れてないよ。

完全に同意。最近AIビジュアルツールを作ってて両方のアプローチを試したけど、汎用的な「エージェント型」ブラウザ操作の遅延とコストは、リアルタイムなコンシューマーアプリにおいては致命的。構造化API（JSONスキーマを強制したLLMチェーンでもいいけど）を使う方が40倍安いし、何より決定論的（デターミニスティック）だから安定したプロダクトを構築できる。コンピュータ操作はデモとしては最高だけど、サーバー代を稼いでくれるのは構造化APIの方だよ。

多くの人がそこに取り組んでるよね :-) 今書かれているアプリも、必要に応じてMCPサーバーやAI互換性を持つようになるだろう。今解決すべき課題は、LLMを既存のあらゆるツールと効率的に連携させる方法だね（スクリーンショットを撮って読み取って…なんてやり方じゃなくて）。大抵の場合、それはアプリ自体やそのバックエンドAPIのリバースエンジニアリングを意味する。GitHubから（自分のではないプロジェクトだけど）：https://github.com/SimoneAvogadro/android-reverse-engineering-skill => APKからAndroidアプリのAPIをリバースエンジニアリング。https://github.com/HKUDS/CLI-Anything => OSSのGUIアプリをCLIに変換。https://github.com/kalil0321/reverse-api-engineer => トラフィックからAPIをリバースエンジニアリング（Claudeスキル）。同じ課題に対する自分の試み（まだ超初期段階）：トラフィックキャプチャからのAPIリバースエンジニアリングで、特にモバイルアプリと安全性、コミュニティによるMCP生成にフォーカスしてる。https://getspectral.sh https://github.com/spectral-mcp/spectral

ビジョンエージェントにUIを「マッピング」させて、APIっぽく見えるインターフェースのセットとして別エージェントに提示させることはできないかな？今のビジョンエージェントなら、「次ページ」でより多くの結果が表示されることと、そもそも結果を取得する必要があることの両方を理解できるはずだし。もし片方のエージェントがテスト環境とかでUIを探索して、UI要素やその挙動を構造化した記述として出力し、もう片方のエージェントにそれを渡せば、探索とタスク実行を同時にやるより効率がいいんじゃないかな？例えば、こんな感じで：『レビュー全取得：各ページへ移動し、ページ内の各レビュー要約にある「レビュー全文を表示」をすべてクリックする必要がある。各ページへ移動：レビュータブのデフォルトである1ページ目から開始。最終ページに到達して「次へ」ボタンがなくなるまでクリックし続ける。』こうすれば、2つ目のエージェントはすでにスキルを持ってるから移動方法を考える手間が省けるし、1つ目のエージェントはテスト環境で一度探索するだけでいい。……それとも何か根本的に勘違いしてるかな？たぶんそうだろうけど、面白いアプローチだと思う。的外れだったらごめん。

エージェントにWebサイトをスクレイピングさせないための素晴らしいヒントが隠されてるね。マウスの動きに合わせて画面要素を動かす、UIを動作させるために自然なマウスの動きを強制する、訪問するたびにJSのボタンラベルをランダムに変える、隠れたタスクをチェックさせるために画面最下部までスクロールを強制する……。ちょっと待てよ、それって今の企業のSaaSアプリそのものじゃないか。

「コンピュータ使用」というコンセプト全体にいつも懐疑的だよ。誰かを雇って自宅に招き、「どうぞ、ベッドで寝ていいし、トイレも使って、冷蔵庫の中身も食べて、テレビも見て……あ、金庫の暗証番号も教えるね」って言ってるようなもんだから。しかもその雇った相手はサルなんだぜ。

自分の「ベストプラクティス」は、「ビジュアル（コンピュータ使用）」ツールを極力使わず、APIやCLIを最大限活用すること。特にトークンを節約するためだね。トークンはリソースなんだから、ちゃんと管理しないと。

結局、決定論的なコードで何かをするのに比べて、LLMを呼び出す時点で構造化APIは10億倍くらいコストがかかるんだよ……計算資源の観点からして、そもそもこの状況が合理的なわけがない。

前提がわからなくなってきた。社内アプリなら、なんでエージェントにCLIやMCPを作らせるんじゃなくて「コンピュータ使用」なんてわざわざ使うの？もちろんコンピュータ使用の方が劣るし、最終手段でしょ。自分が所有するDBのステートに対しては使っちゃいけないよ。むしろ50倍の劣化で済んでることに感心するレベル。

たった1つのサンプルだからベンチマークとは呼べないかな。ただ、現実的な問題点を浮き彫りにはしてる。コンピュータ使用は現状では未熟で、言語エージェントには遠く及ばない。テキストとLLMのツールコールで『フルーツ忍者』をプレイさせてみてほしいよ。