AIエージェント向けプロキシ構成 — browser-use・Computer Use・MCP・Operator

この12か月で、当社の顧客層から見られるエージェントトラフィックは、それ以前の5年間を合算したよりも多くなりました。しかも、その「かたち」も変わっています。2023年の典型的な顧客が、同じ5つのドメインを延々とスクレイピングするPlaywrightのワーカーを動かしていたのに対し、2026年の典型的な顧客は、自らのプランに従ってどこへでも出向くLLM駆動のエージェントを動かしています。十数社の小売サイトを横断する価格比較、SEC提出書類と決算説明会の文字起こしの間を行き来するリサーチ、ロングテールな小規模サイトを相手にしたチェックアウトの自動化、といった具合です。こうしたワークロードに対するプロキシの判断は、2023年のスクレイパー向けに下す判断とはまったく別物であり、多くのエージェント開発者がそこを取り違えています。

この記事は、「ローカルでは動くのに本番で壊れる」と言って相談に来る顧客に対して、私たちが普段伝えている内容を実践的にまとめたものです。エージェントのトラフィックがボット対策スタックに怪しまれる理由、実際に機能するセッション戦略、ターゲットの難易度に応じたプールの選び方、そしてbrowser-use・Anthropic Computer Use・OpenAI Operator・MCP系のツールサーバーについて顧客が落ち着く実装パターンをいくつか取り上げます。どれも机上の理論ではなく、サポート窓口で蓄積したパターンの要約であり、該当する箇所では住宅プロキシ・ISP静的・モバイル・データセンターの各製品へのリンクを添えています。

なぜエージェントのトラフィックはボット対策の餌食になるのか

新品のLLMエージェントを、クリーンな住宅IPのままCloudflareで保護されたサイトに放り込んでみてください。あっさり弾かれます。IPは問題ありません。問題はエージェント側です。理由は、2010年代に初期のSeleniumスクリプトが弾かれたのとまったく同じで、たとえIPは人間らしく見えても、トラフィックが人間らしく見えないからです。

エージェントが確実につまずく挙動が3つあります。

タイミングが一定すぎる。 人間の滞留時間にはばらつきがあります。2秒眺めてクリック、8秒眺めてスクロール、気が散って、また戻ってくる、といった具合です。一方、LLM駆動のエージェントは決まったループを回します。スクリーンショットやDOMを受け取り、数ミリ秒考え、クリックし、ページの読み込みを待ち、それを繰り返す。アクション間の間隔はモデルの応答レイテンシの周辺に密集します。挙動を見る判定モデルはセッションを通じてこれを検知し、10回ほどやり取りしたころには、タイミングのヒストグラムはもう人間には見えません。

ビューポートで足がつく。 Playwrightベースのライブラリで、いまやオープンソースのエージェントスタックの事実上の標準となったbrowser-useは、デフォルトでヘッドレスChromiumを固定ビューポートで起動します。Anthropic Computer Useは、通常1024x768の仮想ディスプレイからスクリーンショットを撮ります。OpenAI OperatorはOpenAIのフィンガープリントを持つリモートインフラ上で動きます。いずれも、ボット対策が実ユーザーから観測するビューポートの分布とは一致しません。

マウスの軌跡が直線的。 Playwrightのエージェントが座標をクリックすると、カーソルはそこへ一直線に飛びます。実際の人間のカーソルは、弧を描き、行き過ぎて、修正し、細かく揺れます。とりわけPerimeterXやAkamaiのセンサー層はマウスの動きを収集しており、直線的な瞬間移動を低く採点します。

user-agentがフレームワークのデフォルト。 browser-useはPlaywrightのUAをそのまま積んでいます。Computer Useにも独自のデフォルトがあります。これらを上書きしないエージェントは、同じ脅威インテリジェンスのフィードに載った何千もの他のエージェントとフィンガープリントを共有することになります。実サイトに向ける頃には、そのデフォルトUAはすでにブロックリスト入りしているのです。

ここで障害モードは2つに分かれます。プレミアムな住宅IPであっても、タイミングとビューポートが「自動化です」と叫んでいるエージェントは救えません。逆に、ステルスをきちんと施したエージェントでも、クリーンなIPはやはり必要です。この2つの層は積み重なって効きます。 どちらか片方にしか投資しない開発者は、なぜ成功率が中途半端なのかと首をかしげることになります。

検出の3層構造という問題

プロキシは3つの層のうちの1つにすぎず、プロキシのことしか考えていない顧客は予算配分を誤っています。

第1層: TLSフィンガープリント。 JA3とJA4は、TLS ClientHello（暗号スイートのリスト、拡張の並び順、サポートするグループ）のハッシュです。本物のChromeは特定のJA4を生成します。デフォルトのurllib3を使ったPythonのrequestsは別のJA4を生成し、それは世界中のあらゆる他のPythonスクリプトときれいに一致してしまいます。TLSフィンガープリントがuser-agentヘッダーと噛み合っていなければ、それは強力な自動化のシグナルです。プロキシはTLSフィンガープリントを変えません。プロキシは透過的で、ClientHelloを生成するのはあくまでクライアント側だからです。つまりこれはエージェントの仕事です。

第2層: IPの種別。 ここがプロキシの活躍する場所です。データセンターのASN（AWS、GCP、主要コロケーション）は、デフォルトで高リスクとしてフラグが立てられます。実在のISPによる住宅ASNはスコアが高くなります。モバイルキャリアが最も高スコアなのは、キャリアIPをブロックした際の誤検知コストがサイトにとって高くつきすぎるためです。ISPクラスのプロキシ（住宅ASN上でデータセンターにホストされたもの）は、その中間に位置します。

第3層: 挙動。 リクエストが通った後も、セッションは時間をかけて採点され続けます。マウスの動き、クリックの間合い、スクロールのパターン、ページ滞在時間。エージェントはデフォルト状態ではこの層が苦手です。

落とし穴は、1つの層だけ直しても、残り2つでフラグが立つことです。Pythonの TLSフィンガープリントを抱えたプレミアム住宅プロキシは失敗します。AWSのIP上で動くチューニング済みのヘッドレスChromeも失敗します。プロキシは答えの一部であって、答えのすべてではありません。

スティッキー対ローテーション: エージェントのセッション問題

これは私たちが目にする最大の設定ミスです。リクエストごとにローテーションするのがデフォルトのスクレイピング畑から来た顧客が、エージェントを同じ設定にしてしまい、状態管理を即座に壊してしまうのです。

エージェントはステートフルです。チェックアウトを行うエージェントには、カート、セッションクッキー、CSRFトークン、UIの状態があり、それらはすべて「同じブラウザが複数のリクエストにわたってサーバーと対話している」ことを前提にしています。「カートに追加」と「チェックアウトへ進む」の間でIPをローテーションさせれば、サイトはセッションを無効化します。無言で無効化することもあれば、IPローテーションをセッションハイジャックの試みとしてフラグを立てることもあります。いずれにせよエージェントは進捗を失って再試行し、それが帯域を浪費してボット対策の疑念を高めます。

ほぼすべてのエージェントのワークロードにとって正しい設定は、スティッキーセッションです。Hell Worldの住宅プロキシでは、スティッキーはユーザー名で設定します。username-session-abc123のようなセッショントークンのサフィックスを付ける方式で、上流のIPがローテーションするまでおおむね30分ほど保持されます。ISP静的は定義上スティッキーです。モバイルのスティッキーは、プールによって通常10〜30分です。

この保持ウィンドウが肝心です。スティッキーが短すぎればフローの途中で状態を失います。住宅プロキシでスティッキーを長く取りすぎても、住宅IPは実在のISP接続でありサイクルするため、いずれにせよ上流側でIPがローテーションしてしまいます。うまくいっている顧客は、自分の最も長いタスクよりわずかに長いウィンドウを選んでいます。5分のチェックアウトなら、10分のスティッキーで余裕があります。数時間に及ぶリサーチセッションなら、下層で何もローテーションしないISP静的の方が安全です。

長時間稼働するエージェント向けには、もう1つのパターンが有効です。それがタスクごとにローテーションし、タスク内ではスティッキーという方式です。エージェントはキューからタスクを取り出し、新しいスティッキーセッションを取得し、完了まで走り、セッションを手放します。次のタスクは新しいセッションを得ます。これは、タスクが互いに独立しているエージェントファーム — リサーチ、価格チェック、モニタリング — に適したかたちです。

ターゲット難易度別のプール選び

すべてのターゲットに同じプロキシが必要なわけではありません。データセンターとモバイルの小売価格差はおよそ30倍にもなり、何でも住宅プロキシをデフォルトにしている顧客は、摩擦の少ないターゲットに対して払いすぎています。

ターゲット難易度	例	推奨プール	スティッキーウィンドウ
Tier 1 — ボット対策が低い	公開ドキュメント、ニュースサイト、検索結果ページ、政府オープンデータ、Wikipedia	データセンターまたは住宅ライト	短め、またはリクエストごと
Tier 2 — Cloudflare保護のSaaS・B2B	大半のSaaSダッシュボード、B2Bポータル、中堅EC、クラシファイド	住宅プロキシ	5〜10分
Tier 3 — 摩擦が高く価値も高い	銀行、チケッティング、スニーカーサイト、ソーシャルプラットフォーム、プレミアム配信、アカウント依存の強いワークフロー	ISP静的専用、または4Gモバイル	セッションの全寿命

Tier 1は、エージェント開発者が金を無駄にしている領域です。エージェントがボット対策のないサイトから公開情報をリサーチしているだけなら、データセンタープロキシで十分であり、しかも一桁安く済みます。ここでお金をかける唯一の理由は、データセンターでは得られない地理的カバレッジが必要な場合だけです。

Tier 2は、当社の窓口で見るエージェントトラフィックの大半を占めます。大半のB2B SaaSは、中程度の感度でCloudflare Bot Managementを使っています。5〜10分の住宅スティッキーが標準的な答えです。ここでは、プレミアムなプールが成功する場面でも格安プールは失敗します。その理由はボット対策の現状を解説した記事で述べたとおりで、安価な住宅プロキシはIPの使い回しが速く、直近の不正利用履歴がIPに残り続けるからです。

Tier 3は、エージェントが高コストで成功するか、安く失敗するかの分かれ目です。アカウント依存の強いフロー — ログインを伴うもの、不正対策チームが付いているもの全般 — はIPの変化を容赦なく罰します。ISP静的専用が定番です。特定のIPを月単位でリースすれば、サイトから見てアカウントは常に同じアドレスから来ているように見え、「通常と異なるログイン場所」のアラートも踏みません。スニーカーのドロップやチケッティングなら、モバイルスティッキーがパターンで、詳しくはスニーカープロキシガイドで扱っています。

実装パターン

顧客が実際にデプロイしている構成を3つ、おおまかなかたちで紹介します。

browser-use + 住宅スティッキー

browser-useは、Playwright形式のプロキシ辞書を受け取るBrowserConfigを取ります。

proxy_user = "your_account-session-task42"
proxy = {
  "server": "http://gate.hellworld.io:7777",
  "username": proxy_user,
  "password": "your_password"
}

ユーザー名の中のセッショントークン（-session-task42）がスティッキーウィンドウを保持します。トークンはタスクごとに選び、タスクの間ずっと保持し、タスクが終わったら手放します。エージェントのプランナーはプロキシのことを知る必要はありません。プランナーが見るのはPlaywrightが読み込んだページ、つまりプロキシ経由でルーティングされたページです。これにChrome UAとチューニングしたビューポートを組み合わせれば、機能するTier 2スタックの出来上がりです。

Anthropic Computer Use + ISP専用

Computer Useは、仮想ディスプレイを備えたコンテナ内で動きます。外向きのトラフィックは、OSレベルで設定されたHTTP/HTTPSプロキシ — 典型的には渡されたHTTP_PROXYとHTTPS_PROXYの環境変数経由 — を通ります。アカウント依存の強いワークフロー — SaaSダッシュボードを操作するエージェント、銀行系のフロー — では、これらの環境変数を、月単位でリースしたISP静的プロキシに向けてください。

住宅プロキシに対する利点は2つあります。1つ目は、IPがローテーションしないため、エージェントが走り続ける限りセッションが安定すること。2つ目は、同じターゲットに対する複数回の実行で同じIPを使うことで、毎回ゼロから始めるのではなく、良好なレピュテーションを積み上げられることです。1つのISP IPからSaaSアカウントへ正当なトラフィックを数週間流せば、ボット対策スタックは「そのIPとそのアカウントの組み合わせは正常なペアだ」と学習します。

タスクごとにスティッキー住宅を使うMCPサーバー

MCP（Model Context Protocol）は、ツールサーバーのためのAnthropic標準です。エージェントは、MCPサーバーが公開するfetch_urlやsearch_webといったツールを呼び出します。これらのツールが外向きのHTTPリクエストを行う際、プロキシ設定を持つのはMCPサーバーであり、エージェントはそれを一切見ません。

パターンはこうです。サーバーはエージェントからtask_idを受け取り、そこからセッショントークンを導出し、住宅プロキシ上のusername-session-${task_id}を通じてフェッチをルーティングします。各タスクは固有のスティッキー出口を得て、タスクが終わるとセッションは手放されます。これは本番スタックで見る最もきれいな分離です。エージェントがプランを立て、MCP層がネットワーク上のアイデンティティを扱い、タスクごとの分離によって、あるIPにフラグが立っても相互汚染を抑えられます。

ジオは、エージェント開発者が思う以上に重要

驚くほど多くのエージェント開発者が、「ドイツの現在価格を調べる」には出口IPがドイツになければならない、という点を忘れています。米国のハーネスから米国の住宅IPでエージェントを走らせると、エージェントはGoogleで検索し、Googleは英語で米国価格のgoogle.comの結果を返し、エージェントはそれを律儀にドイツの価格として報告します。エージェントには分かりようがありません。ユーザーは誤った出力を受け取り、モデルのせいにします。

Hell Worldの住宅プロキシは210か国をカバーし、国・州・市レベルのターゲティングに対応します。ジオセレクタはユーザー名に入れます。ドイツの住宅出口ならusername-country-de-session-task42です。ローカライズされたリサーチを行うエージェントでは、ジオ認識をプランナーに組み込んでください。タスクが「ドイツで」と言ったら、ツール呼び出しがジオを指定するようにするのです。当社が検証した内容を知りたければ、14ブランドのジオカバレッジの内訳を比較ページに載せています。

コストの計算

典型的なエージェントのタスクは、スクリーンショット中心（Computer Use）かDOM中心（browser-use）かに応じて、1時間あたり50〜300 MBの帯域を消費します。当社の住宅プロキシ料金$0.23/GBでは、1時間のエージェント作業のコストは数セント単位です。LLM推論のコストと比べれば無視できる金額です。

急増する数字は再試行です。CAPTCHAに当たって失敗し、プランを立て直して再試行し、また失敗するエージェントは、1つのタスクで帯域を簡単に5〜10倍にしてしまいます。チャレンジの中間ページは画像やJSを読み込み、そのすべてが課金対象になります。効いてくるコスト最適化は再試行を避けることです。最初から正しいプールを選び、スティッキーセッションを正しく保持し、エージェントのステルスをチューニングしてチャレンジを踏まないようにする。格安プールで$0.05/GBを節約しても、タスクの30%を再試行で失えば帳消しどころではありません。

何を監視すべきか

問題を早期に捕まえる指標を、優先度順に挙げます。

ターゲット別の成功率。 タスクを宛先ドメインごとにバケット分けします。あるバケットだけ下がったなら、そのターゲットが対策を強めたか、あなたのプールのIPがそのサイトのブロックリストに入ったということです。局所的なシグナルは、全体の成功率より常に有用です。

フラグが立つまでのセッション寿命。 1つのスティッキーセッションが、チャレンジを受けるまでに何件のリクエストを捌けるか。これが時間とともに下がるなら、プールが劣化しているか、あなたの挙動が漏れています。ターゲットによって差があるなら、ターゲット個別のチューニングが必要だということです。

出口IPの種別構成。 出口をサンプリングし、ASNの分布を確認します。住宅プロキシを買ったのに出口の20%がデータセンターのASNを示すなら、プールが種別を混ぜています。プロバイダーに問い合わせましょう。

プロキシでは直せないこと

私たちはプロキシを売る立場ですが、率直に言います。出来の悪いエージェントは、どんなプロキシでも直せません。TLSフィンガープリントが間違っていれば、IPは関係ありません。タイミングがロボット的なら、IPは関係ありません。ビューポートがフレームワークのデフォルトなら、IPは関係ありません。ステルスとIPレピュテーションは独立した層であり、両方とも正しくなければなりません。

私たちは、チューニング済みのエージェントで格安プールが機能した例も、ずさんなエージェントでプレミアムプールが失敗した例も見てきました。最初のイテレーションはエージェントに費やしてください。user-agent、ビューポート、TLSフィンガープリント、タイミングを正しく整える。その後でプロキシを足すのです。順番が重要なのは、エージェント本体がクリーンだと分かっていれば、デバッグがはるかに速くなるからです。

そこまで来てはじめて、プロキシ層は意味のあるレバーになります。Tier 1の作業はデータセンターに移して節約する。Tier 2は適切な住宅ブランドを選んでCloudflareでの失敗を止める。Tier 3はISPかモバイルに回して、ログイン済みフローでのフラグを止める。プールを選ぶ出発点は比較ページであり、住宅プロキシ・ISP・モバイル・データセンターの各ページに具体的な仕様があります。難易度で選び、スティッキーを正しく設定し、タスクが求める場所ではジオターゲティングし、本番を監視する。それがスタックのすべてです。