Until recently, traffic on the open web came in two broad shapes. Human browsing, episodic, attention-bound, hard-capped by how many pages a person could read in a sitting. And programmatic scraping, high-volume, fan-out, mostly stateless, mostly invisible to the user.
第三の形が急速に台頭している。ブラウザを操作するAIエージェント、AnthropicのComputer Use、OpenAIのOperator、さまざまなオープンソースの自律エージェントは、ユーザーに代わって実際のブラウザを一連のページにわたって操作する。それらが生み出すトラフィックは、これまでの二つのどちらとも異なる。スクレイピングへの対策に成功してきたサイトも、これにどう対処すべきかまだわかっていない。こうしたエージェントの背後にあるインフラプロバイダーも、適切なプリミティブをまだ模索している段階だ。
この記事は、今日の本番環境においてAIエージェントのトラフィックが実際にどのような姿をしているか、そしてそれがそれを支えるインフラスタックをどのように形作ってきたかについてのスナップショットである。
トラフィックが実際にどう見えるか
今日の典型的なAIエージェントのフローはこうだ。ユーザーがエージェントに「8月下旬のニューヨークから東京への最も安い直行便を見つけてほしい」と依頼する。エージェントはヘッドレスのChromiumを起動し、Google Flightsに移動し、フォームに入力して送信し、結果を解析し、最も安い候補をたどって航空会社のサイトに移動し、予約ページに進み、空席を確認して、回答を返す。
これは30〜90秒の間に8〜15件のHTTPリクエストを行うことになり、以下の特性を持つ。
バースト性。 リクエストがゼロの状態か、連続したシーケンスかのどちらかで、その間の定常状態は存在しない。エージェントはユーザーが依頼するまで待機し、その後1分ほど全力で動く。
バースト内ではステートフル。 エージェントのフローにはクッキー、セッション、User-Agentが存在する。リクエストN+1は、対象サイトの視点から見てリクエストNの継続であるように見える必要がある。フローの途中でIPが変わるとセッションが崩れる。
異種のエンドポイント。 エージェントの実行ごとに、検索エンジン、航空会社1、航空会社2、場合によっては比較サイトなど、複数の異なるサイトを訪れる。各サイトはそれぞれ独自のアンチボット対策を持っている。
ユーザーに紐づいた地理的位置。 ユーザーが求めているのはJFKからの便であり、任意のデータセンターからではない。エージェントのトラフィックは、ユーザーが依頼している場所、あるいは少なくとも予約しているように見せたい場所と整合性のある位置情報を持つべきだ。
レイテンシに敏感。 ユーザーはその場で待っている。1リクエストあたりのレイテンシが200msではなく800msになると、12件のリクエストにわたって積み重なり、「エージェントが30秒で答えた」のと「エージェントが1.5分かかって答えた」の差になる。
この形は、人間によるブラウジングのモデル(機械的な速度で速すぎ、ステートフルすぎる)にも、スクレイピングのモデル(セッションあたりのリクエスト数が少なすぎ、セッションに束縛されすぎ、ユーザーに紐づきすぎている)にも当てはまらない。
素朴なインフラがうまくいかない理由
経験豊富なデータチームが成功させているいくつかのパターンは、そのままでは通用しない。
大規模なレジデンシャルプールをリクエストごとにローテーションする。 スクレイピングにおけるデフォルトのパターン。エージェントには適さない。セッションにはIPの一貫性、ログインクッキー、検索状態、フィンガープリントの紐づけが必要だからだ。リクエストごとのローテーションは、2件目のリクエストでセッションを崩壊させる。
速度のためにデータセンタープロキシを使う。 レイテンシの特性から見ると魅力的に思える。しかし、エージェントが訪れる先(Google、航空会社、eコマース、銀行)は、データセンタートラフィックに対して積極的に防御しているため適さない。エージェントの実行の半分がCAPTCHAで失敗する。
単一の静的なレジデンシャルIP。 一貫性があるため魅力的に思える。しかし、複数のエージェントをまたいでIPが早く消耗してしまうため適さない。1つのIPが数千件のエージェントフローを処理すると、最初の100回の実行の後にはスクレイパーのように見えてしまう。
うまくいく形は、レジデンシャル上でのスティッキーセッションに近い。エージェントの実行ごとに新しいセッションを用意し、ユーザーの意図に合致した地理的ターゲティングを行い、セッションをその実行の自然な生存期間に限定する。
うまくいくパターン
多くの本番エージェントのデプロイが収束していくアーキテクチャは次のようなものだ。
user_request → agent.spawn( proxy_session_id=hash(user_id, request_id), # ユーザーと実行のペアごとに一意 proxy_country=user_geo_or_intent, proxy_ttl=longer_than_expected_run, # フローの途中で期限切れにならないように ) → ブラウザがそのセッションを通じて対象サイトに移動する → エージェントが結果を返す → プロキシセッションが自然に期限切れになるプロキシの抽象化は、リクエストごとではなく実行ごとに行われる。1回の実行の中では、エージェントは一貫した1つのレジデンシャルIPを持つ。実行をまたぐと、エージェントの各フローは新しいISPの(通常は)新しい都市からの新しいIPを得る。プールの多様性は、単一のIPが繰り返されるエージェントトラフィックによって消耗することを防ぎ、セッションの一貫性は、対象サイトがフローの途中でエージェントを不審だとフラグ付けすることを防ぐ。
これは機能的には、価格比較ショッピングボットが使用するパターンと同じである。セッションごとのスティッキーなレジデンシャルセッション、安定したsidへの顧客ごとの帰属付けだ。AIエージェントにおける違いは、量が飛躍的に多いこと(エージェントの実行を引き起こすユーザーのクエリはすべてセッションになる)と、持続時間が短いこと(ほとんどのエージェントフローは2分未満である)だ。
帯域幅課金型のレジデンシャルインフラは、これに自然に適合する。エージェントの実行は、同時実行数に制約されるトランザクションではなく、帯域幅に制約されるトランザクションだからだ。エージェントが動かすGB単位で支払いを行う。同時実行数はプロキシの問題ではなく、エージェントのランタイムの問題である。
対象サイト側の動き
今のところ、多くは何もしていない。ほとんどの主要サイトは、AIエージェントのトラフィックをスクレイピングトラフィックと同様に扱い、同じアンチボットルール、同じブロッキングを適用している。これは二つの方向に急速に変化していくだろう。
エージェントトラフィックから利益を得るサイトはそれに対応するようになる。 予約フロー、eコマースのチェックアウト、価格比較ショッピング。エージェントは、自動化の層によって処理されている実際のユーザーであり、コンバージョンは依然として本物だ。賢明なサイトは、エージェントに優しいエンドポイントを公開し始めている。robots形式の宣言で「このUser-Agentとこのヘッダーを持つトラフィックは、人間が介在するエージェントとして扱い、ブロックせず、スロットリングせよ」と伝えるものだ。
エージェントトラフィックによって損失を被るサイトは防御を強化する。 広告収益に依存するものはすべて実際に問題を抱えている。エージェントは広告を見ず、広告をクリックせず、広告主にコンバージョンをもたらさない。ニュースサイト、無料コンテンツサイト、インプレッションで収益化しているものはすべて、エージェントトラフィックを特に検出してブロックする動機を持つ。これはアンチボットの軍拡競争の次の段階になるだろう。そしてスクレイピングの時よりも激しい争いになる。エージェント層には、自社のエージェントがブロックされれば損失を被る強力な企業のバッカーがいるからだ。
その中間にあるインフラ層、つまり私たちやレジデンシャルプロキシネットワークの同業他社は、興味深い立場に置かれている。私たちは、サイト側がまだ歓迎していないエージェントをそのサイトに到達させるアクセス層である。サイトとエージェントプロバイダーの間の交渉が進むにつれ(おそらく契約、支払い関係、改訂されたrobots.txt形式のプロトコルの組み合わせを通じて)、純粋なインフラプロバイダーの役割は「許可された」経路では狭まり、「IPレベルの多様性が必要な」経路では広がっていくだろう。
2026年に注視すべきこと
エージェントの上に何かを構築しているなら、注視する価値のあるいくつかの兆候がある。
フローの途中で再認証を必要とするエージェント実行の割合。 今日、適切なスティッキーセッションを使えばほぼゼロだ。もしこれが上昇し始めたら、対象サイトがエージェントのフィンガープリントを検出する方法を学び、セッションの途中でチャレンジを行っていることを意味する。対策には、エージェント側でのより優れたブラウザフィンガープリンティング、または異なるプロキシ戦略のいずれかが必要になる。
複数ステップのエージェントフローにおけるレイテンシp99。 今日、これは主にネットワークと対象サイトの応答時間によるものだ。同時に発生するエージェント負荷の下でプロキシゲートウェイがボトルネックになるなら、インフラ層はスケールする必要がある。
エージェントトラフィックの地理的分布。 今日、ほとんどのエージェントトラフィックは、エージェントのランタイムがホストされている場所(主にUS-East)に位置情報が結びついている。エージェントが実際のユーザーのトランザクション(ショッピング、予約、銀行取引)を媒介するようになるにつれ、サイトのロジックが正しく機能するためには、トラフィックがユーザーの位置に紐づく必要がある。これは、都市/ASN単位で精密なレジデンシャルインフラがデフォルトになるという楽観的なシナリオの根拠だ。
エージェントに優しいサイトの宣言。 agents.txtのようなものや、「これらの制約のもとでエージェントトラフィックを歓迎する」という構造化された宣言の出現に注目してほしい。それが実現すれば、プロキシ層の役割は狭まる。実現しなければ、プロキシ層はアクセスの媒介者であり続ける。
まとめ
AIエージェントは、実際に新しいトラフィックの形だ。それはスクレイピングでもなく、ブラウジングでもなく、RAGの検索でもない。それぞれと特徴を共有しているが、どれとも完全には一致しない。その下にあるインフラは、スクレイピングと同等の規模の同時実行数で実行ごとのスティッキーセッションを支え、ユーザーに紐づいた地理的位置と、スクレイピングが許容するレイテンシの3分の1という目標を満たすために、柔軟でなければならない。
インフラプロバイダーにとって良い知らせは、正しく構築されたレジデンシャルプロキシネットワークは、すでにまさにこの形をサポートしているということだ。エージェントの実行ごとのスティッキーセッション、セッションごとの新しいIP、地理的な精度、利用量に応じてスケールする帯域幅課金。スクレイパーや価格比較ボットに対応する中で成熟したプリミティブは、エージェントが必要とするものと同じプリミティブなのだ。
今後2年間のプロダクト上の問いは、エージェントトラフィックが実際のカテゴリーになるかどうかではない。それはすでにそうなっている。問いは、インフラスタックと対象サイトのエコシステムが、双方が受け入れられる条件へどれだけきれいに収束していくかだ。来年のローンチ記事では、より鮮明な状況が見えているだろう。