LLMがAIグラウンディングにレジデンシャルプロキシを必要とする理由

この18か月で、あるパターンが定着してきた。実際に本番環境で役立つ仕事をしている興味深いAIシステムは、単にモデルに問い合わせてその回答を返すだけではない。推論時にライブのデータソースから情報を取得し、その取得結果をコンテキストとしてモデルに渡し、モデルには入手可能な最新情報をもとに推論させる。

このパターンにはいくつか名前がついている。最も一般的なのはRAGだ。ツール利用、function-calling、web検索に基づくグラウンディング生成などとも呼ばれる。呼び方はさまざまだが、アーキテクチャは同じである。モデル単体では、学習済みのデータしか知らない。検索機能を備えたモデルは、学習カットオフでカバーされていない質問にも答えられる。

誰も書かないのが、この「検索(retrieval)」の部分だ。具体的には、対象サイトがAIシステムに実際に望むページを提供するかどうかを何が決めているのか、という点である。

検索の失敗モード

「amazon.comでこの商品の現在の価格はいくらか」に答える必要がある本番稼働中のAIエージェントを考えてみよう。エージェントは検索クエリを構築し、検索インデックスにアクセスし、URLを取得し、そのうちの1つを取得(fetch)し、HTMLを解析し、価格を見つけ、それを返す。

この一連の流れには6つのステップがあり、そのどれもが失敗しうる。最も頻繁に失敗し、しかも最もエンジニアリング上の注意を払われていないのが、このfetchの部分だ。対象サイトはリクエストを受け取り、本物のページを返すか、劣化したページを返すか、あるいは何も返さないかを判断し、応答する。この判断は、アップストリームのIPが何であるとサイト側が考えるかに大きく依存している。

リクエストがAWS / GCP / Azureのegress IPから来ている場合、サイト側はそれがボットである確率が高いと事前に判断する。Amazon、Google、Reddit、Xといった主要サイトや、あらゆる大手ニュースメディアは、データセンタートラフィックに対して強力な防御策を講じている。返ってくるページは、空白であったり、CAPTCHAチャレンジであったり、403であったり、あるいは(最も厄介なことに)価格情報も在庫情報も実質的なコンテンツも一切ない簡略化バージョンであったりする。

その下流にあるAIシステムは、受け取ったページが劣化版であることを知らない。得られたものを解析し、有用な情報が見つからないため、回答をでっち上げるか、「その件について現在の情報を持っていません」と返す。どちらの失敗モードも、そもそも検索を行わなかった場合より悪い結果になる。

レジデンシャルがもたらす計算の変化

レジデンシャルIPとは、その構造上、実在の消費者向けISPが実在の家庭に割り当てたIPである。そこには何年分もの通常のトラフィックの履歴がある。動画ストリーミング、ブラウジング、ビデオ通話、モバイルアプリの利用などだ。対象サイトの視点から見ると、そのIPから来るリクエストは、実際に家庭のネットワークから来ているがゆえに、家庭の訪問者からのアクセスと見分けがつかない。

データセンタートラフィックに反応する防御レイヤーは、レジデンシャルに対してはほとんど反応しない。返ってくるページは、家庭の訪問者が目にするページである。fetchの下流にあるAIシステムは、実際のページの実際のコンテンツを手に入れることになる。

これこそが、レジデンシャルプロキシネットワークが製品カテゴリとして存在する理由のすべてだ。そしてこれは、新鮮なウェブデータを必要とする本番のAIシステム、今や何千も存在するそれらのシステムが、公開されているアーキテクチャ図に記載がなくても、静かにレジデンシャルプロキシのインフラにお金を払っている理由でもある。

AIワークロードの3つのクラス、3つの異なる形

検索(retrieval)のパターンは表面的には似て見えるが、プロキシの要件はワークロードのクラスによって大きく異なる。

検索グラウンデッドチャット。 ユーザーが質問をすると、モデルはウェブ検索へ展開し、上位3~10件の結果を並行して取得し、要約する。巨大なレジデンシャルプールにまたがるリクエストごとのローテーションが適切な基本方式であり、fetchごとに新しいIP、セッション不要、地理的・ISP的な多様性を最大化する。ワークロードはバースト的で予測不能だ。総帯域は質問数に応じてスケールするため、帯域課金型のプランが適している。

比較ショッピングエージェント。 エージェントがユーザーに複数のベンダー間の価格比較を手伝う。各ベンダー訪問では、検索結果、商品詳細、レビュー、時には決済シミュレーションなど、複数ページが必要になることがある。スティッキーセッションが適切な基本方式であり、ベンダーのサイトが1000件のスクレイパーではなく一貫した1人の買い物客として認識するよう、ベンダーセッションごとに約5分間、1つのレジデンシャルIPを使う。ベンダーの価格は都市によって変わるため、地理的な精度が重要になる。ユーザーが待っているため、レイテンシも重要だ。

継続的データパイプライン。 監視システムが価格情報、ニュース、規制当局への提出書類、SNS上の言及などをN分ごとに取得する。高ボリュームで予測可能、ほぼ並列処理だ。リクエストごとのローテーション、サイト単位で一貫したセッションが必要な場合には大規模なジョブ単位のsidプール、そして厳格な帯域予算管理。従来型のスクレイピングに最も近いワークロードであり、プロキシスタック上で最も成熟した領域だ。

もしあなたのAIシステムに検索機能があり、自分が今どのワークロード形状で動いているかを意識的に考えていないなら、少なくともそのうちの1つについては、デフォルト設定がおそらく誤っている。

コードで見るとこうなる

レジデンシャルプロキシを使った最小限のグラウンデッドフェッチのラッパーは、次のようになる。

import os, requests
from urllib.parse import urlparse

SHIFTER_USER = os.environ["SHIFTER_USER"]
SHIFTER_PASS = os.environ["SHIFTER_PASS"]

def grounded_fetch(url, country="us", session_id=None, timeout=20):
    """Fetch a URL through a residential IP. Returns response.text or raises."""
    auth_user = f"customer-{SHIFTER_USER}-country-{country}"
    if session_id:
        auth_user += f"-sid-{session_id}"
    proxy = f"http://{auth_user}:{SHIFTER_PASS}@p.shifter.io:443"
    resp = requests.get(
        url,
        proxies={"http": proxy, "https": proxy},
        timeout=timeout,
        headers={"User-Agent": "Mozilla/5.0 (Macintosh) AppleWebKit/537.36"},
    )
    resp.raise_for_status()
    return resp.text

# Use case 1: search-grounded chat, fresh IP per fetch
for url in search_results:
    html = grounded_fetch(url, country="us")
    # ... parse and feed to LLM

# Use case 2: comparative shopping, sticky IP per vendor
for vendor_url in vendors:
    domain = urlparse(vendor_url).netloc
    session = f"agent-{user_id}-{domain}"
    html = grounded_fetch(vendor_url, country="us", session_id=session)
    # ... navigate within session

# Use case 3: continuous pipeline, per-request rotation, country fan-out
for country in ["us", "uk", "de", "jp"]:
    for url in monitoring_urls:
        html = grounded_fetch(url, country=country)
        # ... feed to indexer

この3つのパターンは、パラメータ1つの違いにすぎない。グラウンディングシステム側がプロキシの内部機構を理解している必要はなく、そのワークロードクラスに適したセッション固定性のセマンティクスを指定してgrounded_fetchを呼び出すだけでよい。

注意すべき点

レジデンシャルプロキシネットワークの上にAIグラウンディングを構築するなら、本番環境でのインシデントの大部分は次の3つの失敗モードに起因する。

サイレントなコンテンツ劣化。 対象サイトが200を返すが、それは簡略化されたページだ。パイプラインはエラーを出さず、単にモデルにゴミを食わせることになる。緩和策: LLMに渡す前にレスポンスの形状を検証する。そのドメインの中央値のページと比べて80%短い場合は、ソフトな失敗として扱い、別のIPで再試行する。

Geoドリフト。 country=usで発行したリクエストが米国のレジデンシャルIP経由でルーティングされたが、対象サイトのジオロケーション判定では、その特定のIPがカナダにあると判定された。ページはCADで、カナダの在庫情報とともに返ってきた。緩和策: 地理情報が重要な場合は都市レベルのターゲティングを使い、消費する前にレスポンスがリクエストしたロケールと一致しているか検証する。

フロー途中でのセッション失効。 マルチステップのエージェントフローがレジデンシャルIP Aで開始し、セッションのTTLが失効し、次のリクエストがレジデンシャルIP Bに着地する。対象サイトがそれに気づき、再認証チャレンジを投げてくる。緩和策: 想定される最長フローをカバーできるようセッションTTLを延長するか、再認証チャレンジを検知して意図的にローテーションする。

より大きな論点

AIシステムは今や、レジデンシャルプロキシインフラの最大の顧客カテゴリの一つになっている。その理由は、AIが特別だからではない。AIが不良な検索(retrieval)のコストを増幅させるからだ。チャットボットの回答における1つの誤った価格は、1つの誤った回答にすぎない。100万件のチャットボットの回答における100万件の誤った価格は、顧客の信頼問題になる。

インフラ層はすでにそこに存在していた。スクレイピングのため、広告検証のため、価格インテリジェンスのために構築されてきたものだ。AIグラウンディングは、その上に乗る最も新しく、最大のワークロードクラスだが、その要件は、真剣なデータチームがこの10年間ずっと抱えてきたものと同じである。本物のレジデンシャルIP、本物の地理的分散、本物のセッション制御、予測可能なコスト。

もしあなたのAIシステムがライブのウェブに基づいてグラウンディングされているなら、レジデンシャルプロキシプランを購入することで実際に手に入れているのは、対象サイトがあなたのシステムに見せるページが、実際のユーザーに見せるページと同じであるという、地味だが確かな保証である。それが土台だ。その上にあるすべてのもの、埋め込み、検索(retrieval)、プロンプティング、ファインチューニングは、この土台が機能して初めて機能する。