Claudeが酔ったインターンのようにブラウザを使う理由とその修正方法

私たちは過去数年、カスタマーサポート向けのAIエージェントを構築してきました。最初のバージョンは基本的に、ドキュメント、チケット、過去の解決策、内部メモなどを対象としたエージェント検索でした。これでも驚くほど効果的ですが、サポート業務はすぐに製品の状態に直面します。回答は多くの場合、顧客のアカウント（設定、権限、請求状態、または3階層下に埋もれた管理設定）に依存します。そのため、エージェントは製品を検査し、時には変更する必要があります。

私たちは「ブラウザエージェントを構築しよう」と思って始めたわけではありません。「エージェントをAPIに接続する必要がある」というところから始まりました。では、なぜClaudeは酔ったインターンのようにブラウザを使うのでしょうか？おそらく、Comet、Claude、ChatGPT Atlas、Browser Useなど、少なくとも1つのブラウザエージェントをすでに使ったことがあるでしょう。そのループは常に同じです：ページを探索し、スクリーンショットを撮り、ターゲットを見つけ、マウスを動かし、クリックし、待ち、再びスクリーンショットを撮り、スクロールし、ドロップダウンを試し、モーダルから回復し、状態が変わったか推測する。これが私たちが得られる情報と露出する機能であることは理解していますが、それはひどく遅く、非常に非効率的です。

これは、音声エージェントに別の音声エージェントに電話して床屋の予約を取らせるようなものです。技術的には可能で、初めて使うときは魔法のように感じるかもしれませんが、両方のシステムが直接構造化データを交換できたと気づくと馬鹿げています。UIは人間向けに最適化されています：レイアウト、ラベル、段階的な開示、ホバー状態、レスポンシブブレークポイント、視覚的階層。それらは製品の実際の実行モデルではありません。

その背後では、フロントエンドはすでに構造化システムと通信しています。クリックはリクエスト、ミューテーション、RPC呼び出し、WebSocketメッセージ、サーバーアクション、署名付きリクエスト、永続的なGraphQL操作、または製品固有のコマンドになります。入力、出力、エラー、権限、副作用、状態遷移があります。それはエージェントが望むべきインターフェースであり、まさにMCPサーバーやCLIが存在する理由です。しかし、多くの製品にはまだMCPサーバーがないため、エージェントはどのボタンをクリックすべきかを画面を見て判断するという状況に留まっています。

明白な解決策は、エージェントがUIの下にある構造化インターフェースを使うことであり、ピクセルを使うことではありません。1回の操作で12のUIステップを置き換えられます。小さなスクリプトで脆弱なクリックパスを置き換えられます。モデルにスクリーンショットやレイアウトから意図を推測させる代わりに、オブジェクト、フィールド、メソッド、レスポンス、エラー、不変条件を与えるのです。これは現在のモデルにはるかに適しています。モデルはコード、構造化データ、ツール呼び出しに非常に優れています。一方、「このスクリーンショットを解釈し、適切なものをクリックし、UIが動いていないことを願う」というタスクでは信頼性がはるかに低くなります。

ピクセルは、すでにコードとして存在する動作にとってロスの多い伝送手段です。では、問題は簡単に見えます：なぜ直接基盤APIを使わないのか？それほど明白でない解決策は、難しい部分はインターフェースが存在しないことではないということです。UIは常にそれを使っています。難しいのは、それが構造的に公開または文書化されていないことです。通常、公開されておらず、安定していないこともあります。RESTエンドポイント、GraphQL操作、WebSocketメッセージ、署名付きリクエスト、WASMモジュール、Webワーカー、クライアントキャッシュ、サーバーアクション、フロントエンド限定の慣習に分散していることがよくあります。重要な動作の一部は、リクエストの順序付け、ID解決、バリデーション応答、キャッシュ無効化、権限依存の分岐に存在するかもしれません。「APIを使うだけ」では、エージェントがUIが依存している実際の契約を学習する部分が省略されます。

エージェントが知る必要があるのは：どのオブジェクトが存在するか、どの操作がそれらを作成/変更するか、認証の仕組み、サーバーサイドの言語がユーザー向けUI言語にどのようにマッピングされるか、さらにはステータスIDがユーザーの言語に依存する場合もあること（Zendeskなど）。その情報は多くの場合、フロントエンドコード、ネットワークトラフィック、ランタイム状態、キャッシュ更新、エラーハンドリングに暗黙的にしか存在しません。したがって、ブラウザは依然として重要です。実行時インターフェースとしてではなく、発見インターフェースとして。

フロントエンドがアクションを実行すると、製品契約が明らかになります。オブジェクトを取得し、操作を送信し、入力を検証し、エラーを受け取り、状態を更新します。エージェントはソースコードをチェックし、何が起こるかを観察し、ワークフローの形状を抽出できます：ルート、操作、メッセージパターン、リクエストとレスポンスの形状、必須フィールドとオブジェクト関係、バリデーション、認可、成功状態。では、どうやってエージェントにそこから学習させるのでしょうか？スキルを構築することによって。

シンプルなループがすでにかなりうまく機能します：エージェントに自分のセッションを与え、何がうまくいったか、どこで苦戦したか、何を新しく発見したかに基づいてスキルを更新するよう指示します。この学習はユーザー間で行われるため、機密データには細心の注意を払う必要があります。幸い、私たちは過去3年間、ユーザーデータを危険にさらさずにエージェントが過去のサポートチケットから安全に学習する方法を模索してきました。同じ原則がここでも適用されます。このアプローチを使用して、私たちはすでに4,300を超えるWebアプリ向けの製品固有スキルコレクションを蓄積しています。

これらのスキルには、APIパス、コードスニペット、ワークフローロジック、ドメイン知識、有用なエッジケース、製品の実際の動作に関するメモが含まれます。抽出プロセスには改善の余地が多くありますが、最も単純なアプローチである「エージェントにセッションから有用なスキルを生成させる」だけでも、驚くほど効果的です。スキルができれば、完璧なMCPサーバーを持っているようなものです。エージェントはコードから直接APIと通信し、複数ステップのワークフローを実行するスクリプトを書き、抽象的なツールの説明からは決して知ることのない製品固有の事項を理解できます。

スキルが製品間で存在するようになると、ワークフローも1つのタブに縛られなくなります：あるツールからデータをエクスポートし、変換し、別のツールを更新し、結果を検証する。Claudeがコンピュータ使用経由でVS Codeを使うのではなく、Claude Codeがファイルを直接扱うことを想像してください。それがPlunoと他のブラウザエージェントの速度の違いです。

私たちはベンチマークを作成しましたが、それは不公平かもしれません。しかし、製品学習の効果を示す他の方法がわかりませんでした。24のツール（HubSpot、Notion、Stripe、Linearなど）にわたる312の実タスクでPlunoと他のブラウザエージェントを比較しました。比較は不公平です：Plunoはそれらの製品を事前に学習しており、API、ワークフロー、オブジェクトモデル、権限、奇妙なエッジケースを知っていました。他のエージェントはほとんどそれらを新しいウェブサイトのように扱っていました：ページを検査し、次のクリックを推測し、試し、失敗したら回復する。これは学術的にクリーンな比較ではありませんが、私たちが構築しようとしている製品体験です。ユーザーは毎朝Stripe、Notion、Linear、Salesforce、HubSpotを再発見するエージェントを望んでいません。彼らはすでに基盤ソフトウェアを知っており、そのために10倍速いエージェントを望んでいます。

主な差は速度になると予想していました。直接実行はスクリーンショット、カーソル移動、リトライ、ページが落ち着くのを待つことを回避します。しかし、信頼性にも大きな違いがありました。多くのブラウザエージェントは単に遅いだけでなく、UIで詰まり、行き止まりをクリックし、状態を失い、あきらめました。インターフェースは速度のボトルネックだけでなく、成功のボトルネックでもありました。したがって、その警告付きで数値を読んでください：Plunoが未見の製品の使用に優れていることを証明するものではなく、エージェントが製品を学習し、その知識を次のタスクに使用したときに何が起こるかを示しています。

ピクセルが依然として重要なケースもあります。初回の探索はしばしばブラウザを必要とします。ビジュアル製品は視覚的なコンテキストを必要とします。キャンバスツール、デザインツール、ダッシュボード、マップ、曖昧なワークフローは画面を見る必要があるかもしれません。一部の製品は使用可能なバックエンド契約を公開しないかもしれません。一部のタスクは視覚的な確認を必要とします。ポイントは、エージェントが決してUIを使うべきでないということではなく、UIが繰り返しのSaaS操作のデフォルト実行層であるべきではないということです。ピクセルはブートストラップ層であるべきで、ランタイムではありません。

ブラウザエージェントが遅い主な理由は、モデルの推論能力が低いからではありません。間違ったインターフェースを使っているからです。私たちは、コードと構造化データにますます長けているモデルを、スクリーンショット、ボタン、ドロップダウン、レイアウトシフト、モーダル状態に強制しています。それは逆です。ソフトウェアはすでにUIの下に構造化された動作を持っています。難しいのは、その動作を安全にエージェントに公開することです：契約を学習し、トレースを編集し、スキーマを検証し、権限を制限し、副作用の確認を要求し、必要なときに視覚検査にフォールバックすること。未来は、ボタンをクリックするのが上手くなるエージェントではなく、UIの下の契約を学び、それを直接使うエージェントです。試してみたい場合は、ブラウザ拡張としてエージェントを提供しています。