Reflexのブログ記事では、AIエージェントがWebアプリを操作する方法を2つ比べています。
vision agent
structured API
ここでのポイントは、同じアプリを相手にしていることです。
つまり、「モデルが違うから差が出た」のではなく、インターフェースの違いだけでコストがどう変わるかを見た実験なんですね。ここがかなり面白い。私はこの手の比較、いかにも“現場の本音”が出るので好きです。
課題は、管理画面の中で次の作業をすることでした。
このタスク、ただのクリック練習ではありません。
検索・ページ送り（pagination）・別エンティティの参照・読み取りと更新が全部入っています。
一般の人向けに言い換えると、
「画面のあちこちに散らばった情報を集めて、必要な更新までやる」仕事です。
社内ツールではわりとありがちな、地味だけど面倒な作業です。
最初に驚くのは、vision agent がタスクを完了できなかったことです。
記事によると、vision agent は最初の試行で：
原因はシンプルで、ページの下に隠れていたからです。
画面に表示されていない情報について、vision agent には「まだ下にあるからスクロールしよう」という十分な手がかりがなかったわけです。
ここ、かなり本質的だと思います。
vision agent は「見えているもの」を根拠に動くので、見えていない情報に弱い。
人間でも似たところはありますが、AIだとその弱点がもっと露骨に出る、という感じです。
API方式のAIは、画面を見ずに、アプリ内部の関数やハンドラを直接呼びます。
ハンドラというのは、ざっくり言うと「ボタンを押したときに裏側で動く処理」です。
この方式だと、AIは：
たとえば、UIなら「今のページに見えている10件」しか見えなくても、API側では
「page 1 of 4」「50 results per page」のような情報も含めて受け取れる。
これが大きい。
要するに、vision agent は絵を解読する仕事、API agent は整理された表を読む仕事をしているわけです。
そりゃ後者のほうが速くて安いよね、というのがこの実験のかなり率直な結論です。
比較を公平にするため、記事ではvision agent に14段階のUI手順書を与え直しています。
すると、今度は成功しました。
ただし代償として、
がかかりました。
ここで個人的に重要だと思うのは、成功したことより、その成功に“手順書”が必要だったことです。
つまり、vision agent を実運用するなら、
のどちらかになる、ということです。
どちらも現場ではなかなかつらい。
「AIで楽になるはずが、結局プロンプト設計の職人芸が必要になる」パターン、ありますよね。これはその典型例のひとつだと思います。
記事の主な結果は次の通りです。
記事タイトルの「45x more expensive」は、こうした差をまとめたものです。
もちろん単純比較には注意が必要ですが、少なくともこのベンチマークでは、API方式が圧勝と言ってよさそうです。
しかも面白いのは、vision agent は試行ごとのブレが大きいのに対して、API方式はかなり安定していたこと。
vision agent は 43 cycles のときもあれば 68 cycles のときもあったそうです。
これは現場運用だとかなり嫌な性質です。コスト見積もりが読みにくいからです。
記事もそこは雑に切っていません。
vision agent が向いているケースとして、たとえば：
こういう相手には、画面操作型のAIが必要です。
これはその通りだと思います。
APIがないなら、画面を見るしかない。とても現実的です。
ただし、自分たちで作る内部ツールなら話は変わる。
今回の記事の主張は、そこにあります。
「APIを作るのは別プロジェクトで大変」
という前提が、Reflexの仕組みでかなり崩れつつあるのではないか
Reflex 0.9 では、アプリのイベントハンドラからHTTP endpointを自動生成する仕組みがあり、API層をわざわざ一から書かずに済むとしています。
つまり、API化のコストがほぼゼロに近づくなら、vision agent を選ぶ理由は減る、というロジックです。
この記事で一番おもしろいのは、単に「APIのほうが速い」ではなく、
“見て考える”方式は、構造上どうしてもステップ数が増えると示しているところです。
モデルが賢くなれば、1回の判断ミスは減るかもしれません。
でも、スクリーンショットを何十回も見る必要があるという構造そのものは消えません。
ここはかなり本質的です。
性能改善の余地はあっても、土台のコストは残る、ということですね。
私はこの手の話を見ると、AIの進化は「何でもできます」ではなく、
どの層で情報を渡すかがますます重要になるんだな、と思います。
画像を渡すのか、JSONを渡すのか、イベントを渡すのか。
この差が、そのままコスト差になる時代です。
記事も注記していますが、この結果はあくまで次の条件付きです。
つまり、「すべてのvision agentが45倍遅い」と断言するのは早計です。
ただ、**“画面を見る”という設計が根っこから高コストになりやすい**という示唆はかなり強いと思います。
この記事が伝えたいのは、かなりシンプルです。
技術トレンドとして見ると、これからは「AIに操作させる」よりも、
AIに何をどう見せるかの設計がもっと重要になっていくのではないかと思います。
そしてその答えは、しばらくの間は「スクリーンショット」より「structured data」寄りである、というのがこの記事のかなり痛快な結論です。
