インターフェースを無視してコンピューター利用を解決することはできない

Steelman Labs · Notes コンピューター利用はまだ解決されていない 2026年7月現在、エージェントによるコンピューター利用は、実世界へのAIの影響を最も大きく左右する要因の一つです。LLMベースのエージェントはソフトウェア開発を変革していますが、知的作業のほとんどはソフトウェア利用に依存しています。コーディングエージェントが非常に優秀であるならば、当然の疑問として、税務申告を政府ポータルで行ったり、テキストドキュメントを修正したり、ウェブサイトをテストしたりできるのか、と問うことになります。私たちはまだその段階には達していません。長期間にわたるコンピュータータスクの主要なベンチマークであるOSWorld-V2では、最高のモデルでも完了率はわずか20.6%しか達成できません。Agents' Last Examでは、最高の成績は26.2%です。チャットインタラクションにおけるLLMの印象的なパフォーマンスに慣れたユーザーは、コンピューター利用でも同様の結果を期待しますが、エージェントは信頼性が低く、遅く、高価であるというフラストレーションに直面します。現時点では、自分で作業を行う方が簡単です。 OSWorld-V2の完了率（バイナリ報酬）とタスクあたりの出力トークン数の関係を、モデルと推論努力の設定ごとに示しています。フロンティアは最大で約20.6%に達しており、報酬の増加1ポイントごとに、より多くのトークンが必要になります。 2024年から2025年にかけて、主要なAIラボはすべてコンピューター利用のプロトタイプを発表しました。当時、これらのプロトタイプは、OSWorld、WebArena、AndroidWorld、WebVoyagerなどのベンチマークで、60.76%から97.4%というタスク完了率を誇り、優れたパフォーマンスを示していました。これらのベンチマークはエージェントに適していました。例外はほとんどなく、各タスクは、ほとんど静的な環境、クリーンなテキスト表現、そして小さな事前定義されたアクション空間として提示されていました。これは、現実世界の雑然としたインターフェースとは全く異なります。そのため、リーダーボードは誇張され、ユーザーの期待と実際のパフォーマンスとの間にギャップが生じています。 これまでのところ、コンピューター利用を改善するための答えは、より大規模なモデルとより多くのトークンという、同じことの繰り返しでした。私たちの意見では、この方向性は行き止まりです。確立されたアプローチは、クッションされた環境ではうまく機能しますが、実際のGUI作業には汎化しません。 コンピューター利用の根本的な欠陥 コンピューター利用には、知覚、計画、長期間のタスクにおけるコンテキストの維持など、よく知られた難しい側面があります。これらの問題はコミュニティによって対処されており、一部は実際に、よりスマートなモデルを必要としています。しかし、より単純な問題はあまり注目されておらず、ボトルネックになっている可能性があります。それは、インターフェースを使用するエージェントが、ほとんどの場合、インターフェースを避けてしまうということです。 OSWorld-V2では、最高のモデルはUIを全く操作していないことがよくあります。タスク052（ホテルのスイートを予約する）では、GPT-5.5はJavaScriptを注入してサイトのソースを読み取り、内部APIエンドポイントを見つけて、予約をPOSTしました。タスク065（電車のチケットを購入する）では、GPT-5.5とClaude Opusの両方がウェブサイトをスキップし、直接APIにPOSTしました。タスク003（GIMPで2つの画像を合成する）では、GPT-5.5はPythonでスクリプトを作成しました。全体として、ほとんどのタスクは意図された通りには解決されず、代わりにバイパスされました。 OSWorldタスク068：Claude Opus 4.7は、UIを通じてゲームをプレイする代わりに、状態に直接アクセスします。「API経由でlast_scoreを150に更新する」と、スコアを獲得するのではなく、スコアをPOSTします。これは見過ごされる可能性があり、有利とさえ見なされるかもしれません。API呼び出しができるのに、なぜGUIに触れる必要があるのでしょうか？ しかし、一部の作業はUIを通じてしか実行できません。UIをバイパスすると、ソフトウェアはそのように使用されるようには設計されていないため、予期しない副作用が発生する可能性があります。さらに重要なのは、UIを通じて作業を行う方がはるかに簡単であるということです。これは、経済的に実行可能なコンピューター利用を実現するために重要です。ボタンをクリックしたり、フォームに記入したり、ウェブサイトをナビゲートしたりすることは、難しいタスクではありません。人間は無意識に行います。サイトのAPIをリバースエンジニアリングしたり、JavaScriptを逆アセンブルしたり、コンポジタをゼロからスクリプト化したりすることは、それが置き換えるクリックよりも複雑です。直接行う方が、安価で、速く、はるかに信頼性が高くなります。しかし、フロンティアモデルにとっては、それは選択肢ではありません。 WebGamesベンチマークは、平均的なウェブサイトユーザーの反応時間と運動能力を必要とする簡単なタスクを完了するようにモデルに挑戦します。人間の成功率は95%を超えていますが、モデルは、その知性にもかかわらず、はるかに遅れをとっています。このギャップは、より多くのトークンやパラメータを使用しても縮まりません。これが、長期間のタスクでモデルが困難な解決策に頼る理由です。それらは人間レベルでインターフェースを使用する能力を持っていないため、その制限を回避しなければなりません。 これは、最適化されていないコンピューティングリソースの割り当てにつながります。エージェントは、そのアクションのほとんどを知覚とアクションに費やします。OSWorld 2.0の図10は、アクション予算を分解しています。視覚的グラウンディング、低レベルの操作、およびツール使用のオーバーヘッドが残りの大部分を占めています。タスクを解決するための計画は、ボタンをクリックするよりも難しいはずですが、ほとんどの計算は、見てクリックすることに費やされます。推論、反省、エラー回復は、残ったものを受け取ります。 図10、OSWorld 2.0 — モデル全体のアクション予算のカテゴリ別シェア。知覚とアクションが支配的であり、推論、反省、修正は残されたものを受け取ります。 私たちの意見では、これがエージェントによるコンピューター利用の根本的な問題です。私たちは、クリックを回避するために、兆単位の推論エンジンを使用しています。適切な操作により、エージェントはインターフェースの制限を回避するのではなく、タスクの解決に労力を費やすことができるようになります。これにより、実行速度の向上、無駄になるトークンの削減、信頼性の向上、および長期間のパフォーマンスの向上が可能になります。 エージェントによるコンピューター利用のスティールマンに向けて これまでのコンピューター利用のすべての解決策は、スクリーンショット–ツールコールループに基づいて構築されてきました。環境のスクリーンショットとテキスト表現を取得します。それをLLMに推論させます。click(elem[#submit])のようなツールコールを出力します。実行します。繰り返します。これは、UIインタラクションへのコーディングエージェントのReActループの自然な拡張です。しかし、些細なUIアクションでさえ、これらのエージェントにとっては依然として困難です。なぜなら、それらはすべてを行うために同じ大規模モデルを使用しているからです。その結果、テキストに過度に依存し、すべての時間的情報を逃し、時間内に反応できないエージェントが生まれます。このアプローチは、UIがユーザーに対して行うすべての仮定と反対の方向に作用します。 パラメータとトークンをさらに追加しても、問題は解決しません。このループを10倍速く実行したとしても、LLMのコンテキストをより速く埋めるだけです。実用的なコンピューター利用エージェントを構築するには、コアの仮定に異議を唱える必要があります。 Steelman Labsでは、コア原則に基づいて取り組んでいます。コンピューター利用エージェントは、人間ができるあらゆるインターフェースを使用できなければなりません。この条件を満たすために、計画と実行を分離し、エージェントにシステム1を導入します。これは、モーターコントロールを担当するマニピュレーターです。私たちはビジョンファーストのアプローチを取り、画面を動的な環境として扱い、人間レベルの反応時間を追求します。 お使いのブラウザは埋め込みビデオを再生できません — デモをダウンロードしてください。デモ：ライブUIを操作するSteelman Labsのモデル — リアルタイムで知覚し、行動します。 お問い合わせ：hello@steelmanlabs.com