2026年は、AIエージェントがデモの域を脱した年です。browser-use、OpenAIのOperator型エージェント、Anthropicのcomputer use、そしてPlaywright上に構築された多数のフレームワークが、いまや実際のウェブサイトに対して本物のブラウザを操作しています—予約、購入、調査、監視。そしてそれらはすべて同じ壁にぶつかります。操作対象のサイトは、それらをボットとして扱うのです。なぜなら、実際にボットだからです。
このガイドは、ブラウザを操作するAIエージェントに特化したプロキシ層を扱います。エージェントがブラウザの代わりにHTTPライブラリ（CrewAI内のLangChainツールやスクレイパーなど）を使う場合は、AIエージェント向けプロキシ: LangChain、AutoGPT、CrewAIを参照してください—本記事はフルブラウザを制御するエージェントについてのものです。
直感に反しますが事実です。実際のChromeブラウザを操作するLLMエージェントは、しばしば素のPythonスクレイパーより速くブロックされます。理由は3つあります。
navigator.webdriver、CDP特有のタイミングアーティファクト、ヘッドレスの兆候を探ります。フラグの付いたIPと組み合わさると、スコアは即座にブロック閾値を超えます。IPは3つの中で最も安価に修正でき、それだけ直せばほとんどのブロックは解消します。エージェントを住宅プロキシ経由でルーティングし、IPのストーリーをブラウザのストーリーと一致させるのです。
browser-useはPlaywright上に乗っているため、プロキシのサポートはネイティブです。パターンは、エージェントタスクごとに1つのスティッキーセッションを使うこと。これによりエージェントが作業している間IPは安定し、次のタスクには新しいIPが割り当てられます。
from browser_use import Agent, Browser, BrowserConfig
from langchain_openai import ChatOpenAI
import uuid
task_id = uuid.uuid4().hex[:8]
browser = Browser(config=BrowserConfig(
proxy={
"server": "http://us.jibaoproxy.com:913",
"username": f"USERNAME-session-{task_id}", # sticky: same IP for this task
"password": "PASSWORD",
},
))
agent = Agent(
task="Find the current price of the Sony WH-1000XM6 on the three largest US retailers.",
llm=ChatOpenAI(model="gpt-4o"),
browser=browser,
)
result = await agent.run()重要なポイントはsession-{task_id}サフィックスです。これがないと、ローテーションゲートウェイがタスクの途中でエージェントに新しいIPを渡してしまう可能性があります—カートの中身が消え、ログインが切れ、エージェントはステップをやり直すためにLLM呼び出しを無駄にします。これがあれば、タスクは最初から最後まで1つのIPで実行され、次のタスクにはクリーンなIPが割り当てられます。
Playwright上に独自のエージェントループを構築している場合（ほとんどのOperator型およびcomputer-use実装の背後にあるパターン）、プロキシはブラウザコンテキストに設定します。
from playwright.async_api import async_playwright
async with async_playwright() as p:
browser = await p.chromium.launch(headless=False)
context = await browser.new_context(
proxy={
"server": "http://us.jibaoproxy.com:913",
"username": "USERNAME-session-agent42",
"password": "PASSWORD",
},
viewport={"width": 1366, "height": 768},
locale="en-US",
timezone_id="America/Chicago", # match the proxy country
)
page = await context.new_page()
# ... agent loop: screenshot -> LLM -> action -> repeatlocaleとtimezone_idはプロキシの国に合わせて設定してください。US IPからブラウジングしているのにUTC+8の時計を持つエージェントは、行動分析システムがあなたに不利にスコアリングする不整合です。
コンテキストごとのプロキシは、1つのブラウザで多数のエージェントという利点も与えます。それぞれのnew_context()が独自のセッションサフィックスを持てるため、10個の同時エージェントタスクが10個のChromeプロセスなしに10個の異なる住宅IP上で実行されます。
| エージェントのワークロード | セッション戦略 | 理由 |
|---|---|---|
| 調査 / 価格チェック（ログインなし） | スティッキー、10分、タスクごとに新セッション | タスク内では安定、タスク間では新しいIP |
| ログイン済みアカウントの操作 | スティッキー30分、毎回同じセッションID | サイトはログイン間で国を移動するアカウントにフラグを立てる |
| チェックアウト / 予約フロー | スティッキー30分 | チェックアウト途中のIP変更はセッションを切り、不正レビューを発動させる |
| 大量監視（数百ページ） | ローテーション、セッション固定なし | IPの多様性を最大化、保持すべき状態なし |
住宅トラフィックはGB単位で課金され、ブラウザエージェントはフルページを取得します—画像、フォント、トラッカー—HTTPスクレイパーとは違います。管理しないと、1つのエージェントタスクで20–50 MBを消費しかねません。影響度の大きい順に3つの対策を挙げます。
await context.route("**/*.{png,jpg,jpeg,webp,gif,woff,woff2,mp4}",
lambda route: route.abort())画像ブロックとスコープ付きルーティングを使えば、典型的なブラウザエージェントタスクは2–8 MBの範囲に収まります—$2/GBなら、100タスクあたり数セントです。
正直に書くセクションです。住宅IPはASNの不一致とIPレピュテーションを修正します。これは2026年のアンチボットスコアリングで最も重い単一シグナルです。ただし、以下は修正しません。
requestsを使ってエージェントのリクエストを「そのまま再生」できない理由でもあります。JA3/JA4の解説を参照してください。この3つすべてを住宅IPの上に積み重ねれば、ブラウザエージェントは実際のユーザーが通るのと同じチェックを通過します。最も手強いターゲット（DataDome、PerimeterX）については、DataDome/PerimeterXガイドを参照してください。
timezone_id/localeをプロキシの国に合わせる。新規ユーザーは登録時に500MBを獲得、さらに初回チャージにボーナスが付きます。期間限定オファーです。