CAPTCHA MCP が誤ったブラウザーセッションを使用してしまう問題の修正方法

TL;DR

• URL を受け取る CAPTCHA MCP ツールは、エージェントがすでに制御しているブラウザタブ上で自動的に動作するわけではない。
• 検証した capsolver-mcp 0.1.3 のインターフェイスでは、detect_captchas と solve_on_page は page_url を受け取り、既存ページやブラウザセッションを渡す引数は公開されていない。
• 2 つの MCP サーバーが同じブラウザを共有していると決めつける前に、公開されているツールのスキーマを確認する。
• 元のページは、そのブラウザオーナーのまま維持する。そのページを受け取れる統合を使うか、自分のアプリケーション経由で、ドキュメント化されたパラメータと結果を受け渡す。
• サポートされたチャレンジを処理した後は、元のアプリケーションタスクが完了したかを必ず確認する。ツールのレスポンスだけでは、フォーム送信やデータ検索が完了したとは言えない。

あなたのブラウザエージェントがフォームを埋め、CAPTCHA に到達したとする。エージェントは 2 つ目の MCP ツールをページ URL とともに呼び出し、レスポンスを受け取るが、元のタブは何も変わっていないように見える。このとき欠けている接続要素は、ブラウザセッションそのものかもしれない。

MCP はツールを「呼び出し可能」にするが、接続されているサーバー同士のあらゆるライブブラウザオブジェクトを共有させるわけではない。フォームを準備したブラウザと、URL ツールによって開かれたブラウザは別物になり得る。CapSolver は MCP ツールと Python Core SDK の両方を提供しているため、CAPTCHA が既存タスクの途中で現れた場合に、どのインターフェイスを選ぶかが重要になる。

本ガイドでは、その特定のハンドオフを診断する。実際の MCP スキーマチェックと、ローカルに用意したブラウザフィクスチャでの観察結果を含む。有料チャレンジは一切解かず、本番フォームの受理についてもいっさい主張しない。

なぜ CAPTCHA MCP 呼び出しは別のブラウザを使うのか

検証した MCP ブラウザツールは、「エージェントがアクティブにしているページを受け取る」のではなく、「URL から自前のブラウザを新規作成する」。

MCP サービスリファレンス では、URL ベースの検出およびページ解決について説明されている。インストール済みパッケージの公開スキーマとブラウザ起動の実装を確認し、その後ローカルフィクスチャへのリクエストを観察した。これらの結果は境界について一致している：URL を渡しても、すでに動作中のタブにツールがアタッチされることはない。

この違いは、両方のページが同じアドレスを表示している場合でも重要だ。一方のタブではフォームフィールドに未送信の値が入っていても、もう一方では空かもしれない。Cookie も同様で、あるブラウザコンテキストで利用可能だからといって、別のコンテキストに自動で現れるわけではない。Playwright の browser-context ガイダンス は、コンテキスト間の分離について説明している。

アシスタントのサイドバーに 2 つのツールサーバーが並んでいるからといって、状態が共有されていると推測してはならない。ツール自体は同じモデルから利用できても、ブラウザプロセスは独立したままかもしれない。

ワークフローを変える前にツールスキーマを確認する

ツールがどの状態を実際に受け取れるのかを特定するために、ライブスキーマを確認する。

以下の再現可能なチェックには Python 3.12 を使う。検証環境には capsolver-mcp 0.1.3、capsolver-core 0.1.1、MCP Python SDK 1.30.0、Playwright 1.64.1 が含まれていた。公式 MCP リポジトリがサーバーパッケージを示し、MCP Python SDK がこの診断で使うクライアントを提供する。

サーバーを起動するのと同じ Python インタプリタで、次のコマンドを実行する:

python -m pip install "capsolver-mcp[browser]==0.1.3" "capsolver-core==0.1.1" "mcp==1.30.0" "playwright==1.64.1"
python -m playwright install chromium

次の小さな診断スクリプトを inspect_mcp.py として保存し、同じ Python で実行する。これは本物の stdio 接続を初期化し、スキーマを読み出し、サポート種別レジストリを呼び出す。API キーには意図的に空文字を渡し、solve や balance のメソッドは一切呼ばない。本物の有料 solve には有効なキーと認可されたターゲットが必要であり、この診断ではその経路をテストしない。

import asyncio
import json
import sys
from mcp import ClientSession, StdioServerParameters
from mcp.client.stdio import stdio_client

async def main():
    server = StdioServerParameters(
        command=sys.executable,
        args=["-m", "capsolver_mcp"],
        env={"CAPSOLVER_API_KEY": ""},
    )
    async with stdio_client(server) as (read, write):
        async with ClientSession(read, write) as session:
            await session.initialize()
            result = await session.list_tools()
            for tool in result.tools:
                if tool.name in {"detect_captchas", "solve_on_page"}:
                    print(json.dumps({
                        "tool": tool.name,
                        "arguments": sorted(tool.inputSchema.get("properties", {})),
                        "required": tool.inputSchema.get("required", []),
                    }))
            registry = await session.call_tool("get_supported_captchas", {})
            print("registry_is_error:", bool(registry.isError))

asyncio.run(main())

検証したバージョンで意味のある出力は次のとおりだった:

{"tool": "detect_captchas", "arguments": ["page_url"], "required": ["page_url"]}
{"tool": "solve_on_page", "arguments": ["autofill", "page_url", "polling_interval", "timeout"], "required": ["page_url"]}
registry_is_error: False

セッション引数が存在しないことは、実装を確認すべき理由であって、すべての MCP サーバーについての普遍的な主張ではない。ここでは、パッケージを調べた結果、URL ベースのブラウザ呼び出しごとに新しいヘッドレスブラウザとページが作成されることが確認できた。バージョンを変更する際には、スキーマと挙動を再確認すること。

ローカルブラウザテストでわかったこと

このローカルテストでは、CAPTCHA を実際に解くことなく、セッション境界を示した。

所有する HTTP フィクスチャを Playwright コンテキストで開き、無害な fixture_session Cookie を設定し、テキストフィールドにカタログ検索クエリを入力した。フィクスチャ側では、各リクエストにその Cookie が含まれているかどうかをログに記録した。その後、同じ URL を使って実際の MCP detect_captchas ツールを呼び出した。

元のブラウザからのリクエストにはマーカ Cookie が含まれていたが、MCP ブラウザからのリクエストには含まれていなかった。ツール呼び出しが完了したあとも、元のページには入力済みのクエリが残っていた。この不活性なフィクスチャに対する検出結果は空リストであり、ライブのプロバイダーチャレンジではないため、検出カバレッジの評価にはならない。

ここで得られた観察結果は、より狭く、かつ有用な点を示している：MCP 呼び出しは URL を独立して取得し、一方で最初のページはそのまま保たれていたということだ。これは、有料 solve、トークン移転、ターゲットサイトによる受理などを証明するものではない。実験には、本番 Cookie、認証情報、機密レコードを一切使っていない。

あなたのアプリケーションでも、同様の区別を、所有するステージングページ上の無害なマーカを使って再現するとよい。どのページをブラウザツールが所有し、どのページをソルバが受け取っているかを記録する。診断ログには、実際の Cookie 内容や CAPTCHA トークンを記録しないようにすること。

CapSolver ボーナスコードを利用しよう

自動化用の予算をすぐに増やしましょう！
チャージの際にボーナスコード CAP26 を使うと、毎回のリチャージに対して 5% 分のボーナス が追加されます — 上限はありません。
今すぐ CapSolver ダッシュボード で利用できます。

ブラウザオーナーに合ったハンドオフを選ぶ

ハンドオフは、「あなたのアプリケーションがアクティブなページオブジェクトにアクセスできるかどうか」に応じて選択する。

Python アプリケーション側が Playwright ページを所有している場合

Core SDK は、ブラウザ指向メソッドに既存の Playwright ページを渡せる。ドキュメントにある detect(page) および get_captcha_info(page) メソッドは、そのページを検査する。solve_on_page(page) は、サポートされたチャレンジについて、ドキュメント化された solve とフィルバックのシーケンスを実行する。Core SDK リファレンス には、これらのインターフェイスと結果フィールドが記載されている。

ページは自分のアプリケーション内で保持し、CAPTCHA チェックポイントで既存オブジェクトを渡す。ハンドラ内で新しいページを作ると、診断しようとしている操作そのものが変わってしまう。これは、ブラウザコードを自前で所有しているアプリケーションにおける実装選択であって、「URL のみの MCP ツールを既存タブにアタッチさせる」ような設定フラグではない。

本ガイドは MCP の境界を検証するものであり、有料 Core SDK solve を検証するものではない。本番環境でページベースの solve を採用する前に、サポートされるチャレンジタイプと、対象アプリケーションでの完了条件について、認可されたターゲット上で別途テストすること。

別の MCP サーバーがブラウザを所有している場合

別のサーバーがブラウザを所有している場合、そのサーバーのドキュメント化された機能を使って現在のページを検査し、外部の結果を適用できるかどうかを判断する。ソルバのスキーマが受け取らない session_id や CDP 引数、ページハンドルを勝手にでっち上げてはならない。

トークンモードの solve は、ドキュメント化されたチャレンジパラメータから結果を返せるが、その結果を元のページに届ける手段がアプリケーション側に必要になる。ブラウザオーナーがそれを行えないなら、能力ギャップを記録するか、人にタスクを引き継ぐ。両方のサーバーをつないだからといって、欠けているブラウザ機能が自動的に生まれるわけではない。

タスクを意図的に新しい URL から開始する場合

URL ベースのツールは、「新しいページからのスタンドアロン検査」が正に目的である場合に適している。そのタスクは、エージェントが一時停止しているフォームとは別名で扱うべきだ。新しいページの検査が成功しても、それを元のフォーム完了として報告すべきではない。

既存の Playwright コンテキスト再利用ガイド では、ストレージスナップショットとライブページについて説明している。ここでの MCP 特有の問題は、そのさらに手前にある：「どのブラウザにその呼び出しが届いているのか」である。

元のタスクを確認してから続行する

次のステップが妥当だと、意図したページとアプリケーションの応答が確認できた場合にのみ、元のタスクを続行する。

ブラウザオーナー、現在の操作、完了条件を一体として扱う。サポートされた solve が完了したら、元のページを再度確認する。フォームやクエリが依然として同じタスクを表していることを確かめてから、ブラウザオーナーの通常インターフェイスを通じて、許可された送信やナビゲーションを行う。

データエージェントの場合、成功とは、期待されるレコード ID や必須フィールドが返却データに含まれていることを意味するかもしれない。フォームワークフローの場合、成功とは、送信した入力に結びついたアプリケーションの確認メッセージかもしれない。空の CAPTCHA 検出結果は、そのどちらでもない。

呼び出し中にページが遷移したりチャレンジが変わったりした場合は、以前の結果を再利用する前に、現在のタスクを検査する。有料 solve を、無関係なタブにウィジェットが残っているというだけの理由で繰り返し発行することは避ける。未解決の状態は「成功」としてモデルに要約させず、明示的に扱う。

CapSolver で信頼できる自動化ワークフローを構築する

ブラウザオーナーシップを、CAPTCHA 統合の一部として扱う。CapSolver はドキュメント化された solve 機能を提供できるが、意図したページと最終タスクに対する責任は依然としてアプリケーション側にある。まずは実際の MCP スキーマを確認し、そのうえでブラウザ環境がサポートするハンドオフをテストすること。

FAQ

Q: CAPTCHA MCP ツールに同じ URL を渡せば、ブラウザタブを再利用できますか？

いいえ。少なくとも検証した capsolver-mcp 0.1.3 の URL ベースツールではそうならない。ライブスキーマとローカルリクエストテストの両方が、別ブラウザによるリクエストであることを示した。

Q: 自分のブラウザサーバーのセッション ID を solve_on_page に渡せますか？

検証したツールスキーマは、そのような引数を受け付けない。インストール済みサーバーが公開している入力のみを使用するべきであり、別ツールからのセッション ID がここで自動的に意味を持つわけではない。

Q: autofill はエージェントの元のタブを更新しますか？

そうだと決めつけないこと。URL ベースツールは、自分で開いたページ上で動作する。そのページでのフィルバックは、別オーナーのタブを変更したことにはならない。

Q: この例では本物の CAPTCHA を解きましたか？

いいえ。ここでは MCP 接続、ツールスキーマ、ブラウザセッションの分離を、所有する不活性フィクスチャを使って検証しただけである。有料 solve やアプリケーションによる受理は、別途テストが必要になる。

Q: ブラウザツールがソルバの結果を適用できない場合はどうすればよいですか？

ブラウザを所有しているアプリケーション内でサポートされたページベース統合を使うか、人に処理を任せる。2 つの MCP 接続があるだけでは、欠けているブラウザ機能を補えるとは主張できない。