
Sora Fujimoto
AI Solutions Architect
発行済み Oct 22, 2026
更新されました Oct 22, 2026 · 最小読み取り

get_supported_captchas だけを利用可能なツールとして設定し、その後 Goose のツールメニューを確認して接続を検証する。capsolver にした場合、Goose 上では選択ツールは capsolver__get_supported_captchas と表示される。Goose は開発者向けのオープンソース AI エージェントであり、MCP 拡張を通して外部ツールと連携できる。Goose の CAPTCHA ソルバー拡張は、既に使っているエージェントからソルバーのドキュメント化された操作にアクセスできるようにする拡張機能だ。これは、認可されたブラウザタスクに CAPTCHA 対応を追加し、Goose が実際に必要なツールを見つけられることを確認したい場合に有用である。
CapSolver は、以下で使用する MCP サーバーを提供している。本ガイドでは、インストール、Goose の設定、および CAPTCHA を送信しない接続確認に重点を置く。また、ソルバー用ツールを使う前に追加で必要な作業についても説明する。カスタム MCP サーバーやフレームワークアダプタを書くことなくセットアップを完了できる。
Goose CAPTCHA 拡張は、公式サーバーのツール群を Goose の既存 MCP サポート経由で公開する。Goose は引き続きエージェントクライアントであり、CAPTCHA 処理は Python プロセスが提供する。Goose 拡張ガイドは、拡張ディレクトリに載っていない MCP サーバーであってもサポートしている。
この違いは、すでにブラウザツールを接続している場合に重要となる。ブラウザツールは自分自身のブラウザセッションを制御し、ソルバーツールは入力スキーマで定義された操作を実行する。ソルバーをインストールしても、開いている Chrome タブに自動で接続されたり、他の拡張からページ状態が引き継がれたりするわけではない。
公式 MCP ツールリファレンス では、トークン指向のソルビングと URL ベースのブラウザツールを区別している。既存のワークフローに合うインターフェースを選択すること。本ガイドの初期セットアップでは、サーバーが広告している機能を有料チャレンジタスクを作成せずに確認できる「supported-types」クエリを使用する。
Goose CLI をインストールし、MCP サーバー用に別の Python 環境を用意する。Python 3.10 以上を使用すること。固定された MCP パッケージがそれを要求する。以下のセットアップは、macOS 上で Goose 1.55.0、Python 3.12.14、capsolver-mcp 0.1.3、capsolver-core 0.1.1 を用いて確認したものだ。これらのバージョンはテスト済みの組み合わせを示すものであり、今後のすべてのリリースが同じ動作をすることを約束するものではない。
Goose を初めて使う場合は、OS ごとの公式インストール手順に従い、モデルプロバイダを設定する。後で使用するツール権限の確認には、Goose にプロバイダとモデルが選択済みであることが前提となる。プロバイダ設定は CapSolver のアカウントキーとは別のものである。
macOS または Linux で、新しいプロジェクトディレクトリ内で次を実行する:
python3 -m venv py
py/bin/python -m pip install capsolver-core==0.1.1 capsolver-mcp==0.1.3
py/bin/python -c 'import sys; print(sys.executable)'
最後のコマンドが出力したインタープリターパスを控えておく。Goose はそのインタープリターを直接起動し、その環境にインストールしたパッケージをサーバー側で利用できるようにする。これにより、「ターミナルでは仮想環境を使っているのに、エージェントは別の Python インストールを起動してしまう」というよくある失敗を避けられる。
ここまでの基本インストールだけで、本記事の接続確認には十分である。サーバーのブラウザベースのツールには追加の依存関係があり、ベースパッケージのみのインストールでは Chromium の準備は行われない。supported-types ツールを確認するだけであれば、ブラウザをインストールする必要はない。
以下のコマンドを実行し、Goose の設定ファイルの場所を特定する:
goose info
自分のインストールで表示された設定パスを使用する。デフォルトのパスや、設定されたパスのオーバーライドは環境によって異なるため、決め打ちで場所を想定するより、実行中の CLI で確認する方が信頼できる。ファイルを編集する際は、既存のプロバイダ設定や他の拡張の設定を維持すること。
Goose の YAML 設定ファイル内の既存 extensions マッピングの下にサーバーを追加する。すでに extensions トップレベルキーが存在するファイルに、二つ目の extensions キーをペーストしてはならない。
以下のサンプルのインタープリターパスは、インストール時に出力された絶対パスに置き換えること。これは設定テンプレートであり、初期ディスカバリチェックでローカルマシンごとに変える必要があるのはパスだけである。
extensions:
capsolver:
name: capsolver
type: stdio
enabled: true
cmd: /absolute/path/to/project/py/bin/python
args: ["-m", "capsolver_mcp"]
envs:
CAPSOLVER_API_KEY: ""
env_keys: []
timeout: 60
available_tools: ["get_supported_captchas"]
初回チェックでは、アカウントキーを空にしておくのが意図された設定である。supported-types ツールは有料ソルビングリクエストを必要としない。空の値は、有料操作向けの有効な認証情報にはならない。
Goose の設定リファレンスには、stdio、cmd、args、available_tools が説明されている。ここでの stdio とは、Goose がローカルプロセスを起動し、その標準入力・標準出力を通して MCP メッセージをやり取りすることを意味する。ネットワークポートを公開する必要はない。
available_tools エントリは、この拡張から get_supported_captchas だけを利用可能にする。Goose では空のリストは「すべてのツール」を意味するため、[] だけを残して名前を削除すると、利用可能なツールセットは広がる。
インタープリターとサーバーが正しく起動するかを確認する間は、最初のフィルターを狭く保つこと。接続が動作していることを確認した後で、ワークフローに必要な特定の操作に合わせてリストを調整する。別クライアントのラベルを当て推量するのではなく、公式リファレンスに記載されたリモートツール名を使用する。
タイムアウトは秒単位で表される。例の 60 秒という値は、セットアップ確認のための設定値であり、CAPTCHA ソルビング時間やサービス保証の測定結果ではない。
ブラウザタスクをエージェントに依頼する前に、Goose のツール権限メニューから検出状況を確認する。次を実行する:
goose configure
goose settings → Tool Permission → capsolver を選択する。Goose は設定された拡張に接続し、そのツール一覧を提示する。上記のフィルター設定では、メニューに capsolver__get_supported_captchas が表示され、そのインスタンスでサポートされている CAPTCHA タイプを一覧表示するツールとして説明されるはずだ。
この名前空間付きエントリは、本ガイドの実際の Goose 接続確認でも出現した。二重アンダースコアは、設定した拡張名とサーバー側のツール名を区切る。YAML のフィルターには get_supported_captchas を指定し、Goose のメニューには capsolver__get_supported_captchas が表示される。
ツール選択メニューでエントリを確認した後、そのままキャンセルしてよい。発見されたツールを表示するだけなら、その権限を変更する必要はない。Goose のツール権限コントロールでは、エージェントがどのようにツールを呼び出せるかを別途決めることができる。
ツールが見当たらない場合は、長いプロンプトやターゲット URL を追加する前に、ディスカバリを修正する。クライアントがロードしていないツールをモデルが呼び出すことはできない。また、拡張設定を変更した後は再起動または再接続すること。新しいセッション向けに保存された設定は、既存の会話内のツールを自動的に変更しない場合がある。
CapSolver ボーナスコードを利用する
自動化用の予算をすぐに増やしましょう!
CapSolver アカウントにチャージする際にボーナスコード CAP26 を使用すると、チャージごとに 5% のボーナス が無制限で付与されます。
今すぐ CapSolver ダッシュボード から利用できます。
どの操作を使うかを決め、そのドキュメント化された入力を準備してから CAPTCHA タスクに移る。接続確認は、Goose が実際の MCP サーバーをロードし、フィルターされたツールを検出できることを確認するものだ。モデル選択、有料ソルビング、ページ完了をテストするものではない。
動作しているモデルプロバイダがあれば、次のようなリクエストが有用だ。「CAPTCHA 拡張の supported-types ツールを使用し、その返却する機能一覧を要約してください。ソルビングタスクは送信しないでください。」これは、ガイドの中で実際にモデル駆動のツール呼び出しが実行されたという主張ではなく、推奨されるフォローアッププロンプトである。会話上の回答だけを信用するのではなく、ツール呼び出しと返却データそのものを確認すること。
トークン指向ワークフローの場合、サポートされる CAPTCHA タイプと必要なサイトパラメータを与える準備ができたら solve_captcha を有効にする。拡張の環境変数設定から有効なアカウントキーを構成し、ツール呼び出しには通常の承認コントロールを維持する。共有設定例やソース管理には、本番用の認証情報を含めないこと。
detect_captchas や solve_on_page を使う場合は、まず公式ツールリファレンスに記載されたブラウザ用追加パッケージと Chromium のインストール手順に従う。これらの操作はページ URL を受け取り、別の Goose 拡張が所有するブラウザセッションを自動的に再利用することはない。このセッション境界は、すでにフォーム状態が変化しているページでは特に重要である。
core SDK のページインターフェース は、アプリケーションが既に制御しているページオブジェクトと連携する必要がある場合に検討すべき別の統合面だ。すべての MCP ブラウザツールがタブを共有するという前提ではなく、具体的な要件に基づいて選択する。
API コール と、アプリケーション内アクションの完了は別の成果である。将来的に認可された CAPTCHA ワークフローをテストする際は、ソルバーのレスポンスと、その後のページ結果の両方を確認すること。本記事のセットアップ確認と、本番アプリケーションの受け入れテストは分けて考える。
問題は、失敗しているステップ(インタープリタ起動、パッケージインポート、ツール検出、またはその後のタスク呼び出し)ごとに解決する。以下のチェックにより、多くの場合、原因箇所を特定しやすくなる。
| 症状 | 確認すべきこと |
|---|---|
| Goose がプロセスを起動できない | サンプルの cmd パスを、実際の仮想環境のインタープリターに置き換える。 |
Python が capsolver_mcp が見つからないと報告する |
インストール時に使用した Python 環境が cmd の環境と同じであるか確認する。 |
| supported-types ツールしか表示されない | 例の available_tools フィルターでは想定された挙動である。 |
| 設定を変更しても効果がない | goose info でパスを確認し、その後再接続するか新しいセッションを開始する。 |
| ディスカバリは成功するがソルビングリクエストが失敗する | アカウントキー、選択ツール、タスクパラメータ、およびツール固有の依存関係を確認する。 |
インポートエラーに対処するために、動作しているローカル stdio 設定を任意の HTTP エンドポイントに置き換えないこと。確認すべきなのは、起動コマンドとパッケージ環境である。公式レジストリインストールの手順では、サポートされているパッケージの位置と起動方法に関する追加のコンテキストが提供されている。
ヘルプを求める際は、Goose のバージョン、Python のバージョン、パッケージのバージョン、および失敗したステージを記録しておく。API キーが映り込んだスクリーンショットよりも、パスを一部マスクした起動コマンドやエラーメッセージの方が有用である。拡張が正しくインストールされているかどうかを確かめるためだけに、有料タスクを繰り返し送信することは避ける。
次のステップは、アプリケーションが実際に必要としている CAPTCHA 操作に集中させる。ツールエントリが表示されることは、検証済みのスタート地点を与えてくれるが、正しい入力、認証情報、ブラウザ状態、最終的なアプリケーション検証を伴うテストの代わりにはならない。
CapSolver は、まさにその特定のソルバー処理ステップのために利用し、Goose の役割を明確に保つこと。すなわち、ツールを検出し、許可された操作を要求し、その結果を確認するという役割だ。CapSolver ダッシュボード でアカウントを準備し、自分が所有または操作権限を持つワークフローに対する個別のソルビングテストを行う準備ができた段階で使用する。
Q: Goose の拡張ディレクトリにないサーバーも追加できますか?
はい。Goose はカスタム MCP 拡張をサポートしている。ローカル stdio 設定により、インストール済みの公式 Python サーバーを Goose に指し示す。
Q: ディスカバリチェックに CapSolver のキーは必要ですか?
いいえ。サンプルでは空のキーで supported-types ツールをロードしている。有料 CAPTCHA 操作には有効なアカウントキーと、必要なタスク入力が必要となる。
Q: Goose のツール名に二重アンダースコアが付くのはなぜですか?
Goose はリモートツール名の前に拡張名を付与する。この設定では、capsolver と get_supported_captchas が組み合わさって capsolver__get_supported_captchas となる。
Q: ソルビング用ツールが見当たらないのはなぜですか?
サンプルでは意図的に get_supported_captchas のみを選択している。これらの操作をテストする準備ができたら、available_tools を必要なドキュメント記載のツール名に更新する。
Q: この拡張は既存のブラウザタブを引き継ぎますか?
いいえ。この設定では自動ハンドオフは行われない。別のブラウザ拡張やアプリケーションと組み合わせる前に、選択したツールの入力とブラウザセッションの挙動を確認すること。
Q: ツールが見えていれば CAPTCHA ソルビングが動作している証拠になりますか?
いいえ。それはクライアント–サーバー間の接続とディスカバリが成功していることを示すだけである。有料ソルビングとアプリケーション側の結果については、有効な認証情報と正しいワークフロー入力を伴う別個のテストが必要となる。

Sora Fujimoto
AI Solutions Architect
Connecting agents, browsers, and APIs into one workflow.
著者について
