MCPサーバーとAPIプロキシ：AIエージェントの自動IP切替

従来のパーサーはプロキシのリストを取得し、単純にそれを順番に試し、アンチボットシステムがパターンを検出するとすぐに失敗します。しかし、AIエージェントは異なります。ブロックを検出すると、自らIPを切り替える決定を下し、ヘッダーを変更し、リクエストを遅くします—これらすべてをあなたの介入なしに行います。エージェント、MCPサーバー、APIプロキシを結びつけて、保護されたサイトでもセッションを維持する作業フローを構築する方法を見ていきましょう。

MCPサーバーとは何か、パーサーにとっての必要性

MCP（Model Context Protocol）は、AIエージェント（例えば、Claudeやツールコールをサポートする任意のLLM）が外部ツールにアクセスするためのオープンプロトコルです。以前は、モデルに外部APIへのアクセスを提供するために、各タスクに対してカスタムラッパーを書く必要がありました。MCPサーバーはこれを異なる方法で解決します。エージェントが必要なときに自ら呼び出すことができる「ツール」のセットを定義します。

パースの文脈では、次のようになります。エージェントは「マーケットプレイスから500商品の価格を収集せよ」というタスクを受け取ります。彼はfetch_pageツールを介してリクエストを開始し、403の応答やキャプチャを見て、自らrotate_proxyツールを呼び出し、新しいIPを取得してリクエストを繰り返します—オペレーターの介入なしに。ここでMCPサーバーはエージェントのロジックとプロキシの実際のインフラストラクチャの間の「橋」の役割を果たします。

タイマーによるローテーションの通常のスクリプトとの大きな違いは、エージェントがコンテキストに基づいてIPの切り替えを決定することです—応答コード、ページの内容、特定のドメインのブロック速度に基づいて。彼は認証セッションのために1つのIPを保持し、データ収集の「コールド」リクエストのためにのみIPを変更し、リアルタイムで戦略を組み合わせることができます。

なぜAIエージェントにはIPの切り替えが必要なのか、単なるプロキシリストではない理由

エージェントに静的な50のプロキシのリストを与え、単純にそれを試すように指示すると、通常のスクリプトと同じ結果が得られます。リクエストのパターンは、間隔、ヘッダー、IPの順序によってアンチボットシステムによってすぐに計算されます。Wildberries、Ozon、Avitoなどの大規模なプラットフォームは行動分析を使用しています。彼らはIPだけでなく、User-Agent、クッキー、TLSフィンガープリンティング、特定のアドレスに関連するリクエストの速度の変化も監視しています。

AIエージェントはこの問題を根本的に異なる方法で解決します。彼は：

応答コード（403、429、キャプチャへのリダイレクト）から、現在のIPが「使い古された」と判断し、特定のドメインのために新しいIPを要求することができます;
多段階シナリオのために1つのIPで「スティッキー」セッションを保持します—例えば、認証 + 個人用ダッシュボードのパース;
サイトの反応に応じてリクエストの頻度を調整し、厳密なタイマーに基づいて動作しません;
IPの切り替えをヘッダーの変更や、ヘッドレスブラウザを介したブラウザのエミュレーションと組み合わせます。

これが、エージェント + MCPサーバー + APIプロキシの組み合わせが静的なローテーションに比べてバンの割合を大幅に減少させる理由です。IPの切り替えの決定はブロックの事実に基づいて行われ、スケジュールに基づいて行われません。

アーキテクチャの構成：エージェント → MCP → APIプロキシ → パーサー

作業フローは4つの層で構成されており、それぞれの責任範囲を理解することが重要です：

AIエージェント（ツールコールを持つLLM） — 次にどのページをパースするか、IPを変更する必要があるか、速度を落とすべきかを決定します;
MCPサーバー — エージェントにツールのセットを提供します：get_page、rotate_ip、check_proxy_status;
APIプロキシプロバイダー — 要求に応じて新しいIPを提供し、地理的位置、接続タイプ（住宅、モバイル、データセンター）を表示します;
パーサー/HTTPクライアント — 取得したプロキシパラメータを使用して、ターゲットサイトに実際のリクエストを実行します。

重要な点：MCPサーバーはサイトをパースするわけではなく、エージェントに機能を提供するだけです。「403の場合に何をするか」のロジックはモデルに残り、MCPサーバーはコマンドを実行し、結果を返すだけです。この分離により、エージェントのロジックを再記述することなくプロキシプロバイダーやパーサーを変更できます—MCPサーバー上のツールの実装を更新するだけで済みます。

実践的なアドバイス

エージェントに「生の」APIプロキシプロバイダーへの直接アクセスを与えないでください—それを制限されたパラメータセット（国、IPタイプ、session_id）を持つ別のMCPツールにラップしてください。これにより、モデルが誤って不正なリクエストを生成し、制限を「消費」するリスクが減ります。

エージェントパーシングに適したプロキシの種類

プロキシの種類は、エージェントがrotate_ipを呼び出す頻度や、ブロックなしで通過するリクエストの数に直接影響します。以下は、エージェントパーシングに関連するタスクの比較です。

プロキシの種類	エージェントが使用するタイミング	利点	欠点
住宅プロキシ	マーケットプレイスやアンチボット保護のあるサイト（Wildberries、Ozon）のパース	実際のユーザーのIP、低いブロック率	データセンターより高価、速度はノードに依存
モバイルプロキシ	エージェントフロー内でのソーシャルメディアや広告ダッシュボードの作業	サイトからの最大の信頼、通信事業者と同じIP	コストが高く、ローテーション速度が制限される
データセンターのプロキシ	厳しいアンチボット保護のないサイトからの大量データ収集	高速、IPあたりの低価格	簡単に検出され、エージェントによるローテーションが頻繁に必要

実際には、エージェントはタイプを組み合わせることができます。住宅プロキシを介してセッションを開始し、「ウォームアップ」し、その後、技術的なレート制限を回避するためにデータセンターのプロキシに切り替えることができます—MCPツールがリクエストパラメータとしてIPタイプを指定できる場合です。

プロキシローテーションを伴うMCPサーバーのステップバイステップ設定

Pythonでの最小限の作業フローを見てみましょう。MCPサーバーは、ページを取得するためのツールと、プロキシプロバイダーを介してIPを切り替えるためのツールを定義します。

from mcp.server.fastmcp import FastMCP
import httpx

mcp = FastMCP("proxy-parser-agent")

# 現在のプロキシセッションのストレージ
current_session = {"proxy_url": None, "country": "ru"}

def get_new_proxy(country: str = "ru") -> str:
    """プロキシプロバイダーのAPIを介して新しいIPを要求します"""
    response = httpx.get(
        "https://api.proxycove.com/v1/get-endpoint",
        params={"country": country, "type": "residential"},
        headers={"Authorization": "Bearer YOUR_API_KEY"},
    )
    data = response.json()
    return f"http://{data['username']}:{data['password']}@{data['host']}:{data['port']}"

@mcp.tool()
def rotate_ip(country: str = "ru") -> str:
    """エージェント用のツール：指定された国から新しいIPアドレスに切り替えます"""
    current_session["proxy_url"] = get_new_proxy(country)
    current_session["country"] = country
    return f"IPが更新されました、地域：{country}"

@mcp.tool()
def fetch_page(url: str) -> dict:
    """エージェント用のツール：現在のプロキシを介してページを取得します"""
    if not current_session["proxy_url"]:
        current_session["proxy_url"] = get_new_proxy(current_session["country"])

    proxies = {"http://": current_session["proxy_url"], "https://": current_session["proxy_url"]}
    try:
        r = httpx.get(url, proxies=proxies, timeout=15)
        return {"status_code": r.status_code, "content": r.text[:3000]}
    except httpx.RequestError as e:
        return {"status_code": 0, "error": str(e)}

if __name__ == "__main__":
    mcp.run()

ロジックはシンプルです。エージェントはfetch_pageを呼び出し、応答でstatus_code: 403を見て、それに基づいて自らrotate_ipを呼び出すことを決定します。「10回のリクエストごとにIPを変更する」というハードコードされたルールはありません—モデルはサーバーの実際の応答に基づいています。

プロダクション用には、このコードに追加すべきことがあります：タイムスタンプ付きの各ローテーションのログ、分あたりのローテーション数の制限（モデルが実際の問題を解決する代わりにIPの切り替えに「ループ」しないように）、およびセッションレベルでのタイムアウトを設定し、「スティッキー」IPが必要以上に保持されないようにします。

Claude、LangChain、AutoGPTとの統合

MCPはもともとClaude DesktopとClaude APIのためのプロトコルとして推進されていますが、オープン仕様のおかげでサードパーティのフレームワークでもサポートされています。LangChainでエージェントを構築する場合、MCPサーバーはlangchain-mcp-adaptersアダプターを介して接続され、MCPツールを通常のLangChainツールに変換します—エージェントはそれらを他の関数と同様に認識します。

MCPのネイティブサポートがないAutoGPTのようなエージェントの場合、ローカルHTTPブリッジを立てることができます。MCPサーバーは通常のRESTサービスとして機能し、エージェントは標準の関数呼び出しメカニズムを介してエンドポイントを呼び出します。これは少しエレガントではありませんが、特定のスタックにすでに依存しているチームにとっては実用的なオプションです。

アンチデテクトブラウザとの組み合わせについても言及する価値があります。パースが直接のHTTPリクエストではなく、ヘッドレスChrome/Playwrightを介して行われる場合（重いJS保護のあるサイトに必要）、MCPサーバーはプロキシだけでなくブラウザプロファイルも管理できます—エージェントにDolphin AntyやOcto Browserでプロキシエンドポイントにバインドされたプロファイルを起動するためのツールを渡します。この場合、エージェントは使用するプロファイルと国を指定するだけで、すべての技術的な部分はMCPツールの背後に隠されています。

実践的なケーススタディ：Wildberries、Ozon、SMM分析

Wildberriesの価格監視。 エージェントは2000 SKUのリストを取得し、商品カードを巡回し、キャプチャや空の応答を受け取ると、自ら住宅プロキシを介してIPを変更し、遅延を伴ってリクエストを繰り返します。固定ローテーションの静的スクリプトとは異なり、このような組み合わせは、プラットフォーム側の保護が強化されても安定した収集速度を維持します—エージェントは単にブロックパターンに「遅れて」反応し、リクエストの頻度を下げることで、すべてのIPを一度にバンされるのを避けます。

Ozon Seller APIおよびウェブインターフェースからのデータ収集。 ここでは、エージェントは2つのモードを組み合わせます。認証されたリクエストは、1日の作業時間を通じて「スティッキー」IPを介して行われ（再度の二要素認証をトリガーしないように）、公開された商品カードのパースは各リクエストごとにローテーションされます。

InstagramおよびTikTokにおける競合のSMM分析。 エージェントは競合アカウントのリストに基づいて公開統計（いいね、コメント、リーチ）を収集し、モバイルプロキシを介してリクエストを分散させ、アプリユーザーの通常のトラフィックを模倣します。データセンターのIPからのボットではありません。

これらの3つのケースすべてにおいて、チームの時間の節約はパース自体ではなく（それは以前から自動化できた）、複雑な手動のリトライ、バックオフ、ローテーションルールのロジックを記述し、維持する必要がなくなることにあります。エージェントはコードを再記述することなく、サイトの保護の変更に適応します。

AIエージェントとプロキシの結合における一般的な誤り

過度のローテーション。 エージェントにIPを毎回変更させると、サイトは異常な速度でアドレスが変わるため、サブネット全体をバンする可能性があります。
IPに対するクッキーのバインディングがない。 エージェントがIPを変更しても、古いセッションのクッキーを使用し続けると、アンチボットシステムはすぐに地理的位置とセッションの不一致を検出します。
ローテーション数に制限がない。 制限がない場合、モデルはエラーのループに陥り、システムの問題（例えば、サイト全体がダウンしている場合）で無駄な試行にトラフィックの制限を「消費」する可能性があります。
TLSフィンガープリンティングを無視する。 HTTPクライアントを変更せずにIPを変更しても、サイトがTLSハンドシェイクのシグネチャでボットを特定する場合は効果がありません—ここではヘッドレスブラウザとの組み合わせが必要です。
エージェントに「生の」プロキシクレデンシャルへの直接アクセスを与える。 モデルにプロキシのログイン/パスワードへの直接アクセスを与えると、対話のログ記録中に漏洩するリスクがあります—MCPツールを仲介として使用してください。

結論

AIエージェントとMCPサーバー、APIプロキシの組み合わせは、パースのロジック自体を変更します。タイマーによる厳格なローテーションルールの代わりに、エージェントはブロックの事実に基づいてIPの切り替えを決定し、「スティッキー」セッションと単発セッションを組み合わせ、特定のサイトに合わせてコードを再記述することなく適応します。これは特に、アクティブなアンチボット保護のあるプラットフォーム—マーケットプレイス、ソーシャルメディア、広告プラットフォーム—で顕著です。

マーケットプレイスや厳しい保護のあるサイトのパースには、最初から<а href="https://proxycove.com/ja/residential-proxies/" style="color:#2563eb;">住宅プロキシを組み込むことをお勧めします—これにより、エージェントはIPの早期枯渇なしにより多くの「余地」を持つことができます。ソーシャルメディアやモバイルアプリに関連するタスクの場合は、<а href="https://proxycove.com/ja/mobile-proxies/" style="color:#2563eb;">モバイルプロキシに注目してください—これらはアンチボットシステムに疑念を抱かれることが少ないです。そして、あまり保護されていないソースからの大量の技術的データ収集には、迅速で手頃な<а href="https://proxycove.com/ja/datacenter-proxies/" style="color:#2563eb;">データセンターのプロキシが適しており、エージェントは予算の最適化のために住宅IPと組み合わせて使用できます。