AIツール

browser-harnessのdomain skills機構：AI Agentが同じブラウザ自動化の罠を繰り返さないために

browser-harnessのdomain skills機構を解説し、Amazon、GitHub、ArXiv、LinkedIn、Shopifyなどのサイト操作経験を再利用可能な知識に変える考え方を整理します。

browser-use/browser-harness で面白いのは、AI Agentに実際のChromeを操作させるだけではない点です。Web操作の経験を再利用可能な domain skills に変える仕組みがあります。

これは重要です。ブラウザ自動化で本当に難しいのは、単にボタンをクリックできるかどうかではありません。各サイトには固有の細部があります。

  • どのページでログインが必要か。
  • どのデータはAPIで直接取得できるか。
  • どのボタンは通常のDOMクリックでは反応しないか。
  • どのiframe、shadow DOM、ポップアップがフローを妨げるか。
  • どのselectorが安定しているか。
  • どの操作がアカウント、支払い、取り消せない変更に関わり、人間の確認が必要か。

これらの経験が一回のタスクログにしか残らないと、Agentは次回また同じ罠を踏みます。domain skills は、その経験を残し、Agentが毎回初めてサイトを開く状態にならないようにするためのものです。

domain skillsとは

domain skills は、Agent向けのサイト操作マニュアルと考えるとわかりやすいです。

通常のユーザードキュメントでも、一回限りのスクリプトでもありません。実測済みのサイト知識に近いものです。

  • そのサイトはブラウザ操作に向いているか。
  • APIがあるなら、どのAPIを優先すべきか。
  • Web操作が必要なら、どのURLから入るべきか。
  • どのDOM構造、aria-label、ボタン挙動が確認済みか。
  • どの一般的な方法が失敗するか。
  • どの場面で停止し、人間の介入を求めるべきか。

この内容は人間がレビューでき、Agentもタスク中に読めます。現場での手探りを、保守できる経験に変える仕組みです。

盲目的にクリックさせるものではない

良いブラウザAgentは、すべての問題をWebページを開き、スクリーンショットを見て、ボタンを押す作業に変えるべきではありません。

domain skills の重要な経験の一つは、いつブラウザを使わないかをAgentに伝えることです。

たとえばArXivでは、論文検索、メタデータ、要約をAtom APIやHTML metaタグから直接取得できます。HTTPリクエストの方がブラウザを開くより速く、安定し、解析もしやすいです。

GitHubも似ています。リポジトリ、ユーザー、releaseデータはREST APIを優先します。ファイル内容は raw.githubusercontent.com を優先します。GitHub Trendingのように等価なAPIがないページだけ、ブラウザ操作が必要になります。

つまりbrowser-harnessの考え方は「ブラウザ万能」ではありません。API、HTTP、静的ページで解決できないときに、実ページ操作をAgentに任せるということです。

サイト単位の知識を記録する

従来の自動化スクリプトは、よく一つのタスクを中心に書かれます。

1

ページを開く -> キーワードを入力 -> ボタンをクリック -> ファイルをダウンロード

このスクリプトはタスクを完了できますが、経験はコードの中に散らばりがちです。サイトが変わるとスクリプトが壊れ、別のタスクでは経験を再利用しにくくなります。

domain skills の粒度は、サイト単位の知識ベースに近いです。関心があるのは次のような点です。

  • Amazon検索結果でどのコンテナselectorが安定しているか。
  • GitHubのどのデータをREST APIで取るべきか。
  • LinkedIn招待管理ページのボタンの aria-label がどう違うか。
  • Shopify Adminのどのページがembedded appか。
  • Shopify Polarisの入力欄が普通のJS value設定だけでは動かない理由。
  • Browser Use Cloudのブラウザインスタンスをどう作成、一覧、清理するか。

これらは一回のタスク手順ではなく、多くの今後のタスクで使う判断材料です。

例：Amazonの商品検索

Amazonの商品検索で重要なのは、どう検索するかだけではなく、どの経路が安定しているかです。

信頼しやすい方法は、毎回トップページを開いて入力を模擬するのではなく、検索URLを直接使うことです。検索結果は [data-component-type="s-search-result"] のようなコンテナから取得できます。タイトル、価格、評価、レビュー数、スポンサー表示も、それぞれ安定しやすいDOMの取得元があります。

この経験はAgentにとって価値があります。なければAgentはスクリーンショットからボタンを推測し、selectorを何度も試すかもしれません。あれば、より安定した抽出経路に直接進めます。

さらに、skillは罠も記録できます。使えそうに見えるselectorが、スポンサー枠や関連推薦で誤読することがあります。これは実測して初めてわかる種類の問題です。

例：LinkedInの招待管理

LinkedInのようなサイトは実アカウントのワークフローに近く、リスクも高くなります。

招待管理ページでは、AcceptとIgnoreボタンの aria-label 形式が異なります。一方からもう一方を単純に推測することはできません。招待カードによってはAcceptが <button> ではなく <a> としてレンダリングされ、通常のCDPクリックで受諾が発火しないこともあります。

これは、実Web自動化が「要素を見つければ終わり」ではないことを示しています。ボタンラベル、イベントバインディング、ソフトナビゲーション、コンポーネント実装が、操作の成否に影響します。

Agentにとって、この経験には安全上の意味もあります。ソーシャルアカウント、招待、メッセージ、投稿に関わる操作は完全委任すべきではありません。skillは経路と罠を記録できますが、招待の一括承認、外部への送信、アカウント情報変更は人間の確認を残すべきです。

例：Shopify Admin

Shopify Adminは、バックエンド管理画面が単一ページではなく、embedded appと複雑なコンポーネントの集合であることを示します。

多くのShopify appはiframe内で動作します。Polaris React入力欄、Web Components、embedded appはそれぞれ操作方法が異なります。一部の入力欄は element.value = ... だけでは反映されず、実際のキーボード入力に近いCDP keystrokesが必要です。

この種のskillの価値は、Agentがまず現在のUI種類を判断し、その上で適切な操作方法を選べる点にあります。

Shopifyの経験は「ブラウザを使わずに済むなら使わない」ことも強調します。

  • 読み取り専用の商品や在庫データはStorefront APIを優先する。
  • Admin API tokenがあるならAdmin APIを優先する。
  • テーマコード編集はShopify CLIを優先する。
  • APIがない、一回限りの設定、管理画面探索の場合だけブラウザを使う。

これが成熟したAgentのツール選択です。

例：Browser Use Cloud

domain skills はWebページのクリックだけを扱うものではありません。ブラウザランタイム周辺のAPI経験も記録できます。

Browser Use Cloudの経験では、REST APIでcloud browserを作成し、稼働中ブラウザを一覧し、zombie browserを清理し、liveUrl や cdpUrl を取得する方法などを記録できます。

つまりskillは「あるWebボタンをどう押すか」に限られません。安定した方法がある反復タスクなら、skillにできます。

  • API呼び出し方式。
  • 認証ヘッダー形式。
  • リクエストとレスポンス構造。
  • 検証済みステータスコード。
  • よくある失敗パターン。
  • リソース清理と回収方法。

Agentにとって、これらはすべて再利用可能な能力です。

なぜ場当たり推論より信頼できるのか

多くの人は、大きなモデルが毎回Webページを自分で理解できると期待します。しかし実タスクでは、場当たり推論だけでは安定しません。

理由は単純です。

  • Web UIはよく変わる。
  • 同じボタンに複数の実装がある。
  • 見えていることとクリックできることは違う。
  • クリックできても操作が本当に成功したとは限らない。
  • そもそもAPIを使うべきタスクもある。
  • 人間の確認が必要な操作をモデルだけで決めるべきではない。

これらの経験をファイルにすることで、次の利点があります。

  • 人間がレビューできる。
  • 間違った経験を修正できる。
  • 同じサイトの知識を継続的に蓄積できる。
  • 新しいAgentが過去の経験を継承できる。
  • 一時的な発見を長期知識にできる。

すべてをpromptやチャット文脈に詰め込むより安定します。

チームでの使い方

チームでbrowser-harnessを使うなら、domain skills は軽量な自動化知識ベースになります。

記録に向いている内容は次の通りです。

  • 社内管理画面のログイン後パス。
  • レポート出力フロー。
  • よくあるポップアップ処理。
  • どのボタンに人間の確認が必要か。
  • どのページにAPI代替があるか。
  • 実測済みの信頼できるselector。
  • Agentに自動実行させてはいけないタスク。

最初から完全である必要はありません。現実的には、低リスク、高頻度、巻き戻し可能なフローから始めます。読み取り、ダウンロード、整理、確認のようなタスクを先に任せ、安定したら経験をskillにします。

チーム管理者にとって、skillファイルは自動化の境界を可視化します。Agentが何を知り、何をでき、どこで止まるべきかを確認できます。

注意すべき境界

domain skills はAgentの成功率を高めますが、高リスク操作を完全自動化するためのものではありません。

守るべき境界は次の通りです。

  • パスワード、Cookie、token、顧客データ、内部の機密URLを記録しない。
  • 支払い、削除、一括送信、アカウント変更、外部公開には人間の確認を残す。
  • skillには検証日と適用範囲を書く。
  • サイト改版後はskillが失効することを前提に再検証する。
  • 風控回避やプラットフォーム制限の回避を目的にしない。

つまり、domain skillはAgentをより安定させるためのもので、無制限に行動させるためのものではありません。

まとめ

browser-harnessの domain skills 機構は、AI Agentのブラウザ自動化がモデルの場当たり対応だけでは成り立たないことを示しています。

使えるブラウザAgentには、少なくとも3つの層が必要です。

  • 低レベル制御：スクリーンショット、クリック、入力、ダウンロード、CDP、HTTP。
  • サイト単位の知識：API優先順位、安定selector、コンポーネントの罠、ログイン境界。
  • 人間の安全ルール：認証情報をモデルに渡さない、高リスク操作は確認する、機密情報をskillに書かない。

domain skills が補うのは2番目の層です。Agentが毎回手探りするのではなく、検証済みの経験を持ってWebタスクに入れるようにします。

参考資料：

© 2022 - 2026 KnightLiブログ
记录并分享
Hugo で構築されています。
テーマ Stack は Jimmy によって設計されています。