AIブラウザエージェントには専用のブラウザが必要
自律型エージェントに普段使いのブラウザを渡すと、あなたのCookie、ログイン、デバイスまで渡すことになります。エージェントを分離したプロファイルに置くべき理由と、その用意の仕方を解説します。
AIエージェントにウェブ上での実際の能力を与える最速の方法は、ブラウザを操作させることです。そして後悔する最速の方法は、あなたのブラウザを操作させることです。普段使いのブラウザには、これまでにログインしたすべてのセッションが残っており、クリックできるエージェントは、それらのセッションが届くあらゆるものをクリックできます。
影響範囲の問題
サプライヤーを調べるよう頼まれたエージェントは、あなたの銀行のタブを開くつもりはありません。しかし、動作しているブラウザは区別をしません。Cookieの保管場所は一つ、保存済みログインは一式、マシンのIDも一つです。エージェントが移動できる場所はどこでも、すでに認証済みです。多くの人が最初に思いつく緩和策、つまり別のChromeプロファイルやシークレットウィンドウは、Cookieを動かすだけで、他は何も動かしません。
分離が実際にカバーすべきもの
- ストレージ：専用のCookie保管場所、Local Storage、IndexedDB。他に何も書き込まないディレクトリに置く
- 認証情報：そのプロファイルに意図してログインしたものだけで、それ以外は含まない
- ネットワーク：専用の経路。エージェントのトラフィックとあなたのトラフィックが同じアドレスにならない
- デバイスID：そのプロファイルで安定していて、あなたが作業するマシンのコピーではない
- 拡張機能：エージェントに必要なものだけ。パスワードマネージャーは入れない
この一覧は、分離されたブラウザプロファイルがすでに満たしているものと同じです。ブラウザから見れば、エージェントは、あなたの他の作業を見るべきではない、同じマシンの別のユーザーにすぎません。
エージェントにプロファイルを与える
PowerOpsでの手順は短いものです。エージェント用のプロファイルを作り、トラフィックを流したい経路を与え、そのタスクに必要なアカウントにだけログインします。次にLocal APIから起動すると、ブラウザのデバッグエンドポイントが返ってくるので、エージェントのフレームワークを、自分で起動したブラウザではなくそのエンドポイントに向けます。
# Start the agent's profile and take the endpoint it returns.
curl -s -X POST http://127.0.0.1:50326/v1/browsers/start \
-H "Authorization: Bearer $POWEROPS_KEY" \
-H "Content-Type: application/json" \
-d '{"profileId": "agent-research-01"}'Chrome DevTools Protocolを話せるものなら何でも、この呼び出しが返すものに接続できます。PuppeteerでもPlaywrightでも、どちらかをラップするエージェントフレームワークでも同じです。エージェントのコードは何も変わらず、変わるのは、たどり着くブラウザです。
エージェントごとではなく、タスクごとに1つのプロファイル
つい、エージェントにプロファイルを与えたくなります。より良い単位はタスクです。サプライヤー調査用のプロファイル、投稿を許可するアカウント用のプロファイル、読み取り専用のダッシュボード用のプロファイル。実行がうまくいかなかったときも、被害はそのプロファイルが届く範囲に限られ、ディレクトリを捨ててやり直せます。
実行結果を比較可能に保つ
エージェントのデバッグが難しいのは、二つの実行が同じ実行になることがめったにないからです。起動のたびに同じデバイスを、同じ経路から、前回の状態のまま報告するプロファイルは、試行間の違いの要因を一掃します。実行の挙動が変わったとき、環境はもう容疑者の一人ではありません。
線引き
これはどれも、サイトの利用規約、レート制限、robotsポリシーを回避する手段ではなく、そのようなものとして販売されてもいません。エージェントに与えるのは、あなたのものではなくタスクのものであるブラウザです。
