Web Agents Should Use Typed Actions Instead of Click-Based Browsing
本ポジションペーパーは、より信頼性が高く、監査可能で、再現可能なエージェント型ウェブシステムを構築するために、脆弱で低レベルなクリックベースのウェブインタラクションを、型定義された「ウェブ動詞」によるセマンティックレイヤーへと置き換えることを提唱するものである。
原論文は CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) でライセンスされています。 これは以下の論文のAI生成解説です。著者が執筆または承認したものではありません。技術的な正確性については原論文を参照してください。 免責事項の全文を読む
大きなアイデア：クリックをやめて、「動詞」を話し始めよう
ロボットにピザの注文方法を教えようとしている場面を想像してみてください。
旧来の方法（クリックベースのブラウジング）：
現在、ほとんどのウェブエージェント（AIロボット）は、人間がボタンをクリックする様子を見ることで、ピザの注文方法を学ぼうとしています。ロボットはこう考えなければなりません。「よし、マウスを右に400ピクセル動かして、赤いボタンをクリックして、画面の読み込みを待って、3インチスクロールして、『ペパロニ』と入力しよう」。
これは、誰かに運転を教える際に、筋肉の動き一つひとつに対して指示を出しているようなものです。「頭を左に向けて、足を2インチ動かして、ペダルを踏んで」。これでも機能はしますが、非常に脆（もろ）いです。もしピザ屋が「注文」ボタンを左に2インチ動かしたり、メニューの色を変えたりすると、ロボットは混乱してクラッシュしてしまいます。そのたびに、一連のダンスを最初から学び直さなければならないのです。
新しい方法（タイピングによるアクション / ウェブ動詞）：
この論文の著者たちは、ロボットに「クリック」を教えるのはやめるべきだと主張しています。代わりに、**「ウェブ動詞（Web Verbs）」**というメニューを与えるべきだと言っています。
ウェブ動詞とは、**「魔法のボタン」や「コマンドカード」**のようなものです。ロボットに「どうやってクリックするか」を教えるのではなく、明確で構造化されたコマンドを使って「何をすべきか」を伝えます。
- 旧コマンド: 「マウスをX, Yへ移動し、クリックせよ」
- 新動詞:
hotel_search(destination="Anchorage", check_in="2026-06-01")
このコマンドは、パッケージ化された食事のようなものです。ロボットは「玉ねぎを刻んだりステーキを焼いたりする方法（複雑なクリックやスクロール）」を知る必要はありません。ただ「ホテル検索」という食事を注文すれば、システムが裏側ですべての面倒な詳細を処理してくれるのです。
なぜこれが必要なのか？
論文では、「クリック」によるアプローチが抱える3つの問題点と、それらを「動詞」がいかに解決するかを指摘しています。
1. 信頼性（「脆い家」の問題）
- 問題点: ロボットがボタンをクリックするとき、それは「トランプの家」を建てているようなものです。ウェブサイトのレイアウトが少し変わる（ボタンの位置が変わるなど）だけで、家全体が崩壊します。ロボットは迷子になります。
- 動詞による解決策: 動詞は「頑丈なレンガ」のようなものです。たとえウェブサイトの塗装が変わったり家具の配置が変わったりしても、「ホテル検索」というレンガは、内部でそれらの変化を処理するように作られているため、依然として機能します。ロボットは単にそのレンガを要求するだけでよく、そのレンガがどのように作られたかを知る必要はありません。
2. 効率性（「ストップ・アンド・ゴー」の問題）
- 問題点: 旅行の予約のような単純なタスクを行うために、クリック型のロボットは50もの小さなステップを踏む必要があります。ここをクリック、待機、スクロール、入力、あそこをクリック……。ステップごとに「考え」、画面を「見る」必要があります。これは遅く、コストもかかります。
- 動詞による解決策: 動詞を使えば、ロボットは「ホテルを探して」「飛行機を探して」「予約して」と言うことができます。50の小さなステップではなく、3つの大きなステップで仕事を完了できます。これは、材料を一つずつ調理するのではなく、レストランでフルコースを注文するようなものです。
3. 検証可能性（「ブラックボックス」の問題）
- 問題点: クリック型のロボットがミスをしたとき、なぜそうなったのかを判断するのが困難です。ボタンを押し間違えたのか？ テキストを読み間違えたのか？ それとも、一連のアクションの跡が複雑すぎてチェックが難しいのか？
- 動詞による解決策: 動詞は「レシート」のようなものです。ロボットが動詞を使用すると、明確で構造化された回答（例：「価格付きのホテルのリストはこちらです」）が得られます。入力（何を求めたか）と出力（何を得たか）を簡単に確認できます。もし問題が発生しても、どの特定のピクセルをロボットがクリックしたかではなく、どの「レンガ」が失敗したのかを正確に特定できます。
実生活での動作例（具体例）
論文では、これらを2つの例でテストしています。
旅行プランニング: ユーザーが美術館の近くにあるホテルを探し、距離順にランク付けしたい場合。
- クリック型ロボット: 混乱します。美術館とホテルのすべてを一本の線で結ぼうと試みますが、これでは距離を正しく計算できません。クリックの最中に数学的な処理を見失ってしまうのです。
- 動詞型ロボット:
get_directions（経路取得）という動詞を使用します。リストをループさせ、動詞に対して各ホテルと美術館の距離を問い、それらを足し合わせ、ソートします。距離が「視覚的な推測」ではなく「明確な数値」であるため、数学的に完璧に処理できます。
家具のショッピング: ユーザーが予算1,000ドル以内で、評価を最大化するようにベッド、デスク、ランプを購入したい場合。
- クリック型ロボット: アイテムを一つずつ強欲に（グリーディに）選びます。素晴らしいベッドを選び、次に素晴らしいデスクを選んだ後、突然「ランプを買うお金が残っていない」ことに気づくかもしれません。全体的な目標を見失うのです。
- 動詞型ロボ理: 動詞を使って、価格と評価が付いた全アイテムのリストを取得します。その後、予算内に収まる最適な組み合わせを見つけるために、単純なコンピュータプログラムを実行します。パズルを論理的に解くのです。
行動への呼びかけ
著者たちは、AIモデルがより「賢くなる」必要があると言っているのではありません。**「インターフェース」**を変える必要があると言っているのです。
彼らは、ウェブサイトがこれらの「動詞」を世界に公開すべきだと提案しています。
- 開発者へ: 単に人間のためのウェブサイトを作るのではなく、ロボットのための「動詞レイヤー」を構築してください。これはシンプルなAPI（サーバーへの直接ライン）であったり、ブラウザのクリックを自動化するスクリプトであったりしても構いません。
- コミュニティへ: ウェブサイトの見栄えに関する標準（HTML）があるように、ロボットがウェブサイトと対話するための標準が必要です。ロボットがどのようなコマンドを利用できるかを正確に把握できるよう、ユニバーサルな「ウェブ動詞」の辞書が必要です。
まとめとしての比喩
- 現在のウェブエージェント: 車を運転する際、地図を見ながら、手動でハンドルを切り、アクセルを踏み、ブレーキをポンプのように踏み込んでいる人のようです。道が変われば、衝突します。
- 提案されているウェブエージェント: 自動運転車の乗客のようなものです。彼らはただ車に「空港まで連れて行って」と言うだけです。車（動詞）が、ステアリング、ブレーキ、ナビゲーションを処理します。その方が安全で速く、目的地も明確です。
論文は、もし「エージェンジェント・ウェブ（ロボットが私たちのために動いてくれるウェブ）」を信頼できるものにしたいのであれば、ロボットにハンドルを渡すのではなく、目的地を伝えるべきだと主張しています。
自分の分野の論文に埋もれていませんか？
研究キーワードに一致する最新の論文のダイジェストを毎日受け取りましょう——技術要約付き、あなたの言語で。